Base de données et backend open source

Supabase : le socle derrière vos applications IA

La base de données, l'authentification et le stockage de fichiers que la plupart des outils qui génèrent une application à partir d'un texte branchent par défaut. Un socle solide — à condition d'en régler correctement les accès.

  • Éditeur · Supabase (États-Unis) — cœur open source auto-hébergeable
  • Catégorie · Base de données et backend open source
  • Prix · Offre gratuite limitée, puis abonnements par paliers d'usage — consulter le site officiel

C’est quoi ?

La brique qui fait tourner la base de données derrière une appli générée par IA

Supabase fournit à une application trois briques qu'il faudrait sinon assembler soi-même : une base de données PostgreSQL complète, un système de comptes utilisateurs (authentification) et un espace de stockage de fichiers, accessibles via une API générée automatiquement. C'est devenu le choix par défaut des outils qui génèrent une application à partir d'une description en français — v0, Lovable et Bolt en tête : décrire « une appli avec des comptes clients et leurs commandes » produit, en coulisses, une base Supabase qui stocke exactement cela.

La région d'hébergement se choisit à la création du projet, parmi une liste qui inclut plusieurs villes européennes — Paris, Francfort, Dublin, Londres, Zurich, Stockholm. Elle ne se modifie pas ensuite : en changer impose de créer un nouveau projet et d'y migrer les données. Un responsable qui valide un projet construit avec un outil d'IA générative a donc intérêt à demander où ce choix a été fait, avant la mise en service.

Le cœur de la plateforme — base de données, authentification, API, stockage — est publié en open source (licence Apache 2.0) et peut être auto-hébergé sur un serveur de l'entreprise. Les données reposent alors sur du PostgreSQL standard, reprenable chez un autre hébergeur. Dans le cas le plus courant — l'offre gérée —, les données restent chez Supabase, dans la région choisie.

Pour qui ?

Quiconque fait développer une application avec de l'IA générative

  • Dirigeant qui fait construire un outil interne

    Un prestataire ou un collaborateur assemble une application avec un outil d'IA générative de code. Supabase est très probablement la base de données derrière cet outil — autant savoir ce qu'elle contient et qui peut y accéder.

  • Responsable technique ou DSI

    Vous évaluez une option auto-hébergée pour garder la main sur l'infrastructure, ou vous validez la configuration d'un projet géré avant sa mise en production.

  • Direction qui valide un prototype avant déploiement

    Avant d'autoriser la bascule d'un prototype « vibe codé » en production, un contrôle des règles d'accès à la base est une étape à exiger, pas une option.

Cas d’usage en PME

Trois moments où Supabase entre en jeu

Supabase travaille en coulisses : la décision d'un dirigeant porte rarement sur l'outil lui-même, mais sur ce qu'on accepte de lui confier et comment on vérifie qu'il est bien réglé.

  1. Un portail client généré par un outil d'IA

    Un commercial décrit un portail de suivi de commandes à un générateur d'applications IA ; celui-ci crée, sans intervention humaine sur le code, une base Supabase avec les comptes clients et leurs commandes. La rapidité de mise en place déplace le vrai travail vers la vérification des règles d'accès, pas vers l'écriture du code.

  2. Évaluer l'auto-hébergement pour des données sensibles

    Un responsable technique compare l'offre gérée par Supabase à la version open source installée sur un serveur de l'entreprise. Le choix de la région ne se pose plus : les données ne quittent pas l'infrastructure choisie par l'entreprise elle-même.

  3. Faire auditer les règles d'accès avant la mise en ligne

    Avant d'ouvrir un outil interne construit avec l'IA à l'ensemble des équipes, un développeur ou un prestataire vérifie que chaque table sensible applique une règle d'accès stricte. Cette vérification ciblée évite une fuite ouverte à quiconque connaît l'adresse du projet.

Limites & vigilance

Ce qu'un dirigeant doit vérifier avant de dire oui

  • Le risque n° 1 porte un nom précis : les règles d'accès — la sécurité d'une base Supabase repose sur le RLS (Row Level Security, des règles qui filtrent ligne par ligne ce qu'un utilisateur a le droit de lire). En 2025, des chercheurs ont trouvé plus de 170 applications construites avec l'outil Lovable dont les données étaient lisibles par quiconque connaissait l'adresse du projet, faute de ces règles (CVE-2025-48757, signalée en mars 2025).

  • Un défaut qui ne se limite pas à un seul générateur d'applications — un scan indépendant publié en septembre 2026 a recensé plusieurs milliers de bases Supabase accessibles en lecture pour la même raison, tous outils confondus : le défaut tient à la configuration du projet, pas à un éditeur en particulier.

  • Le serveur MCP élargit la surface de risque — en juillet 2025, des chercheurs ont montré qu'une consigne cachée dans un message de ticket de support pouvait détourner un assistant connecté à ce pont entre IA et base de données, avec des droits qui contournent le RLS, pour lui faire recopier une table sensible dans sa réponse. Supabase a depuis publié des mesures de réduction du risque, en précisant qu'elles le réduisent sans l'annuler.

  • Le choix de région se fait une fois, au tout début — la région d'hébergement se sélectionne à la création du projet et ne se modifie pas ensuite : en changer impose de migrer vers un nouveau projet. Un lancement précipité fige ce choix pour longtemps.

  • L'auto-hébergement transfère la charge de sécurité à l'entreprise — s'affranchir de l'infrastructure de l'éditeur veut dire assumer soi-même mises à jour, sauvegardes et supervision, sans l'équipe dédiée que l'offre gérée fournit en arrière-plan.

Vos données

Où sont hébergées les données d’une application Supabase ?

Dans l'offre la plus courante — gérée par Supabase —, les données d'un projet sont hébergées chez cet éditeur américain, sur une infrastructure cloud, dans la région choisie à la création du projet. Plusieurs régions européennes existent (Paris, Francfort, Dublin, Londres, Zurich, Stockholm), ce qui permet de garder les données dans l'Union européenne si ce choix est fait dès le départ — mais l'hébergeur de la base reste une société américaine, avec les conditions contractuelles que cela suppose. Le risque le plus concret n'est toutefois pas la localisation : c'est le réglage des règles d'accès à l'intérieur de chaque table, comme le montre l'incident Lovable de 2025.

L'alternative souveraine : le cœur de Supabase étant publié en open source, une entreprise qui veut garder ses données entièrement chez elle peut auto-héberger la même base sur son propre serveur — avec, en contrepartie, la responsabilité complète de sa sécurité et de sa maintenance.

Mon avis

Supabase n'est presque jamais le sujet de discussion avec un dirigeant — c'est l'outil qui l'a généré (un assistant de code, un no-code IA) qui attire l'attention. C'est le problème : une application peut sembler fonctionner parfaitement, avec un design soigné, tout en laissant chaque table de sa base ouverte à quiconque connaît son adresse. L'incident documenté chez Lovable en 2025 ne vient pas d'un bug caché dans Supabase ; il vient de projets où personne n'a vérifié une case cochée ou non.

Mon conseil : avant d'accepter la livraison d'une application construite avec un générateur IA, demandez une preuve écrite que les règles d'accès (RLS) sont actives sur chaque table contenant des données de clients ou de salariés — pas seulement « activées », mais testées avec un compte sans droit. Si un assistant doit se connecter directement à la base via son serveur MCP, exigez la lecture seule et une validation manuelle de chaque action. Et posez la question de la région avant le lancement, pas après : en changer ensuite impose une migration.

— Nicolas

Comment sont écrites ces fiches

D’autres fiches