Quand on apprend le developpement en formation, la question de l'infrastructure est souvent mise de cote. On code en local, on livre un ZIP, ou on pousse sur GitHub. La question de comment ca tourne en production reste abstraite pendant longtemps.
En travaillant sur mon portfolio, j'ai du y repondre concretement. Et j'ai realise qu'il existait des categories tres differentes de solutions, avec des compromis tres differents.
Le BaaS, Backend as a Service, represente des outils comme Supabase ou Firebase. Ils fournissent une base de donnees, une API, de l'authentification, parfois du stockage fichiers, le tout configure en quelques clics. La force : on deploie vite, sans gerer de serveur. La limite : on depend d'un service tiers, et la personnalisation profonde peut se heurter aux contraintes de la plateforme.
Le PaaS, Platform as a Service, comme Vercel, Railway ou Render, est une couche au-dessus du serveur brut. On pousse son code, la plateforme s'occupe du build, du deploiement, de la scalabilite. On garde la maitrise du code, mais pas de l'infrastructure sous-jacente. C'est le bon compromis pour beaucoup de projets web.
Le self-hosted, c'est tout gerer soi-meme : louer un VPS, configurer le serveur, installer les dependances, gerer les mises a jour et la securite. C'est ce que j'aurais du faire pour utiliser Supabase avec PostgreSQL. Le cout en temps et en competences est plus eleve, mais la maitrise est totale.
Ce que j'ai compris en vivant ces choix plutot qu'en les lisant : il n'y a pas de meilleure option en absolu. Il y a une option adaptee a un contexte. Pour un prototype rapide, un BaaS. Pour un projet avec du code metier complexe, un PaaS. Pour une infrastructure critique ou specifique, le self-hosted. Connaitre ces categories, c'est pouvoir poser les bonnes questions avant de commencer a coder.