BaaS
Définition
Backend-as-a-Service. Service tout-en-un qui couvre auth, base de données, storage et fonctions serveur, pour démarrer vite sans monter son infra. Exemples : Supabase, Firebase.
Comment ça marche
Un Backend-as-a-Service expose les briques d'un backend via une API ou un SDK : authentification, base de données, stockage de fichiers, fonctions serveur, temps réel, notifications push. Vous écrivez du code frontend qui appelle directement ces services, sans serveur intermédiaire à coder. Le fournisseur gère le scaling, la sécurité, les mises à jour de l'infrastructure, les sauvegardes. Le pricing est typiquement à l'usage : nombre de requêtes, taille de stockage, nombre d'utilisateurs actifs. Les acteurs phares sont Supabase, Firebase, AWS Amplify, Appwrite, Pocketbase, chacun avec sa philosophie et son écosystème propre.
À quoi ça sert
Le BaaS résout le problème classique du démarrage d'un projet : il faut une auth, une base, un stockage, mais on ne veut pas y passer trois semaines. En quelques heures, on a un backend complet pour un MVP, une app mobile, un SaaS en phase de validation. Sur la durée, il évite la maintenance infra (mises à jour OS, certificats SSL, sécurité) qui draine du temps sans créer de valeur métier. Les développeurs frontend gagnent en autonomie : ils livrent une fonctionnalité de bout en bout, du design au déploiement, sans dépendre d'une équipe backend séparée.
Quand l'utiliser
Le BaaS brille sur les MVP et POC où la rapidité prime sur le contrôle. Sur les apps mobiles avec offline-first et notifications push (Firebase excellent ici). Sur les SaaS B2B classiques jusqu'à plusieurs milliers d'utilisateurs (Supabase imbattable avec sa RLS). Sur les outils internes qui n'ont pas vocation à devenir des produits complexes. Et sur les projets avec équipe réduite ou solo, où chaque heure compte. Le code applicatif reste portable : un projet Supabase peut migrer vers un PostgreSQL classique avec un effort modéré, parce que SQL est SQL.
Quand ne pas l'utiliser
Le BaaS devient limitant sur les architectures complexes : workflows métier longs, intégrations multiples avec d'autres systèmes, logique stateful, calculs intensifs. Dès qu'on a besoin de jobs de fond longs (au-delà de quelques minutes), de WebSocket persistants à grand volume, ou d'orchestrer plusieurs services, on bascule sur une vraie API backend. Idem pour les projets avec contraintes strictes de souveraineté ou de certification : un BaaS public en SaaS n'est généralement pas qualifié pour HDS, SecNumCloud ou certains BAA. Dans ces cas, on auto-héberge ou on bâtit son propre backend.
Open-source vs propriétaire
Firebase est propriétaire Google : excellent produit, mais vous êtes verrouillé, et migrer ailleurs coûte cher. Supabase, Appwrite et Pocketbase sont open-source : vous pouvez auto-héberger, votre code reste portable. Pour un projet B2B ou un produit dont la durée de vie dépassera trois ans, on penche systématiquement vers l'open-source. Le SaaS managé reste utilisé pour démarrer vite, mais on garde l'option de basculer en self-hosted si les coûts grimpent ou si les contraintes de souveraineté apparaissent. Cette portabilité est un actif technique sous-estimé, qui pèse réellement au moment des arbitrages.
Les coûts
Le free tier de la plupart des BaaS couvre largement un POC ou un MVP de quelques utilisateurs. Le premier palier payant (typiquement 25$/mois) couvre une petite production. Au-delà, on entre dans du pay-as-you-go qui peut s'envoler : 100 000 utilisateurs actifs, plusieurs téraoctets de stockage, millions de requêtes mensuelles coûtent vite plusieurs milliers d'euros par mois. On compare alors à un VPS Hetzner + PostgreSQL auto-hébergé + n8n self-hosted : facture divisée par 5 ou 10, contre un coût DevOps à intégrer. Le bon arbitrage dépend de la taille de l'équipe et de ses compétences.
Les pièges à éviter
Le verrouillage est le piège principal : on construit avec les abstractions du BaaS, et migrer ailleurs demande de réécrire des pans entiers. On le limite en gardant le code applicatif simple, en utilisant SQL standard quand le BaaS le permet, et en évitant les fonctionnalités trop spécifiques. La sécurité est l'autre piège : exposer une base directement au frontend impose une RLS irréprochable, sinon on fuit les données. On teste systématiquement les permissions avec des comptes utilisateurs réels. Et on surveille les coûts avec des alertes, pour ne pas découvrir une facture surprise après un pic de trafic.