Outils

Comment Supabase est devenu le backend par défaut

Une alternative open source à Firebase, bâtie sur Postgres, est devenue le backend vers lequel se tournent d’abord les générateurs d’applications par IA. Ce qu’elle fait bien, ce qu’elle coûte, là où les projets dérapent.

  • Review
  • 28.09.2026
  • 5 min de lecture

Demandez à un générateur d’applications par IA une application avec comptes utilisateurs et base de données, et les données finiront souvent dans Supabase. En juin, l’entreprise indiquait que plus de 60 pour cent des nouvelles bases de données sur sa plateforme sont lancées « par un outil d’IA ou un autre ».

Précisons d’où nous parlons. Werk, notre plateforme d’applications, utilise Supabase lorsqu’un projet s’y prête : nous le connaissons donc par la pratique quotidienne. Voici comment il en est arrivé là, ce qui est bon, ce qui ne l’est pas, et notre verdict.

Ce que c’est

Supabase a été fondé en 2020 par Paul Copplestone et Ant Wilson et a fait ses débuts chez Y Combinator. Sa promesse : une alternative open source à Firebase, de Google, bâtie non pas sur un stockage propriétaire mais sur Postgres, la base de données que beaucoup de développeurs connaissent déjà et à laquelle ils font confiance. Autour s’ajoute ce dont une application a besoin ensuite : la connexion, des API générées à partir des tables, le stockage de fichiers et une boîte à outils pour la recherche vectorielle.

Aujourd’hui, il se décrit en une ligne : « Supabase est la plateforme de développement Postgres. » Le code est public, sous licence Apache 2.0. Il s’adresse à ceux qui veulent une vraie base de données sans avoir à l’exploiter : fondateurs avec une première version, équipes produit, agences, et désormais les outils qui écrivent des applications pour eux tous.

Comment les générateurs IA en ont fait le choix par défaut

Les générateurs d’applications avaient besoin exactement de cela : un seul service pour la base de données, la connexion et le stockage d’une application générée. Lorsque Lovable a lancé Lovable Cloud en septembre 2025, Supabase écrivait : « Chaque projet créé dans Lovable Cloud tourne en coulisses sur Supabase. » Plus de 40'000 nouvelles bases de données étaient lancées chaque jour sur sa plateforme, précisait-il. Quelques jours plus tard, en rendant compte de sa levée de fonds suivante, TechCrunch citait Lovable et Bolt parmi les outils de vibe coding dont les backends l’utilisent.

Puis sont arrivés les agents de code. En juin 2026, Supabase annonçait que les lancements de bases de données avaient progressé de 600 pour cent en un an, et que près de 10 millions de développeurs construisent sur sa plateforme, plus de deux fois plus que huit mois auparavant. La croissance s’est accélérée depuis janvier, écrivait-il, à mesure que « Claude Code et Codex élargissent le cercle des personnes capables de construire ».

L’argent

Supabase a levé 80 millions de dollars en série C en 2024, 200 millions pour une valorisation de 2 milliards en 2025, puis 100 millions à 5 milliards en octobre 2025, un tour lors duquel les membres de sa communauté pouvaient eux aussi acheter des actions. En juin 2026, il a levé 500 millions de dollars sur une valorisation de 10 milliards avant l’apport des nouveaux fonds, un tour mené par GIC, Stripe investissant pour la deuxième fois et Salesforce Ventures faisant son entrée. Une partie sert à offrir de la liquidité aux employés, qui peuvent céder à chaque tour certaines de leurs actions déjà acquises.

Ce qui est vraiment bon

Le meilleur atout de Supabase, c’est qu’il s’agit de Postgres. Le schéma est du simple SQL, les données vivent dans des tables avec de vraies relations et de vraies transactions, et les compétences comme les outils dont une équipe dispose déjà restent valables. D’après notre expérience, cela en fait aussi un bon terrain pour les agents : un schéma écrit sous forme de migrations SQL est explicite, lisible et vérifiable, ce qui convient mieux à du code écrit par l’IA qu’un stockage de documents peu structuré.

On démarre vite. L’offre gratuite comprend une base de données de 500 Mo et 50'000 utilisateurs actifs par mois, de quoi tester une idée auprès de vraies personnes. Et c’est ouvert. La plateforme est open source et peut être auto-hébergée, et comme la base de données est du Postgres standard, une équipe peut emmener ses données ailleurs avec des outils ordinaires.

Les points de vigilance

La sécurité d’abord. La clé présente dans le navigateur est censée être publique. Ce qui protège les données, c’est la sécurité au niveau des lignes (RLS) : des règles dans la base de données qui décident qui peut lire ou écrire chaque ligne. La documentation de Supabase est précise sur le réglage par défaut : « Les tables créées via le Supabase Dashboard ont la RLS activée par défaut. » Les tables créées dans l’éditeur SQL ou « via un autre outil » exigent qu’on l’active explicitement, et c’est ainsi que les agents et les migrations les créent généralement.

Le problème s’est déjà concrétisé. En mai 2025, le chercheur Matt Palmer a signalé que 170 des 1'645 applications mises en avant par Lovable avaient une sécurité au niveau des lignes absente ou mal configurée, exposant des données telles qu’adresses e-mail, numéros de téléphone et informations de paiement. Lovable a contesté l’avis de vulnérabilité qui en a découlé, estimant que chaque client est responsable de la protection de ses propres données.

En septembre 2026, la société de sécurité UpGuard a trouvé plus de 16'000 bases de données Supabase dont les tables étaient lisibles par n’importe qui, plus de la moitié contenant des données personnelles. BleepingComputer en voyait la cause dans « des politiques de sécurité au niveau des lignes absentes ou inefficaces et une mauvaise utilisation des clés publiques », même si les analyses n’ont pas établi que chaque site avait été construit avec un agent IA. Le responsable de la sécurité de Supabase, Bil Harmer, a déclaré à TechCrunch que les projets sont « sécurisés par défaut » et que les clients maîtrisent la configuration de leurs propres projets.

Le coût vient ensuite. L’offre Pro démarre à 25 dollars par mois et inclut 10 dollars de calcul, assez pour la plus petite instance. Chaque projet supplémentaire paie l’intégralité de son calcul, de 10 dollars par mois pour la plus petite taille à 3'730 dollars pour la plus grande affichée, et le transfert de données au-delà de 250 Go coûte 0,09 dollar par Go. Un plafond de dépenses est activé par défaut sur Pro, et l’offre Team commence à 599 dollars. À notre avis, les prix sont justes et clairement publiés, mais la facture suit le calcul et le trafic, et beaucoup de petits projets, mis bout à bout, finissent par peser.

La dépendance, selon nous, est plus faible qu’avec la plupart des plateformes de ce type. La base de données se déplace facilement. C’est par la connexion, le stockage et les bibliothèques clientes qu’une application s’enracine dans Supabase, et c’est là qu’un déménagement demanderait un vrai travail.

Notre verdict

Supabase mérite sa place de backend par défaut pour les nouvelles applications web et mobiles qui ont besoin de comptes et de données, et la raison n’a rien de glamour : c’est du Postgres, avec de bons outils, des prix justes et publiés, et une porte de sortie. Sa faiblesse est celle de tous les outils rapides. Il rend facile une application qui fonctionne, et fait d’une application sûre une étape à part, qu’un agent ne franchira pas toujours.

Utilisez-le donc, et considérez la sécurité comme partie intégrante du développement : sécurité au niveau des lignes sur chaque table accessible de l’extérieur, des politiques testées plutôt que présumées, des clés secrètes uniquement sur le serveur, et un plafond de dépenses tant que vous ne connaissez pas votre trafic. C’est ainsi que nous l’utilisons dans Werk, où Supabase est l’une des briques que nous choisissons projet par projet, aux côtés de Next.js, React et Expo. L’IA écrit l’essentiel du code, des personnes valident chaque mise en production, et les rôles, la connexion, le chiffrement et les tests automatisés sont là dès la première version.