Supabase est le piège du vibe coding Image: AI generated

La magie des 30 secondes

« Crée-moi un backend. » L’IA recommande Supabase. Une seule URL suffit pour brancher PostgreSQL, l’authentification, le stockage et les abonnements en temps réel. La connexion fonctionne en 30 secondes. Le CRUD est terminé en 2 minutes.

Trois mois plus tard, plus personne ne sait qui a écrit ces politiques RLS (Row Level Security).

Pourquoi l’IA le recommande

Si Supabase est devenu le choix par défaut du vibe coding, ce n’est pas pour sa supériorité technique. C’est parce que les données d’entraînement regorgent de tutoriels.

Cursor, Bolt, v0, Lovable — quel que soit l’outil de codage IA, tapez « crée-moi un backend » et Supabase apparaît. L’IA recommande le pattern qu’elle a le plus souvent vu. Pas le meilleur pattern.

Zhang et al. (ACL 2025) ont démontré empiriquement que 7 LLM favorisent systématiquement certains fournisseurs sans instruction explicite et modifient le code en entrée de manière autonome pour y insérer ce fournisseur privilégié. L’utilisateur croit que ce que l’IA recommande est optimal. L’IA recommande ce qui est le plus fréquent dans ses données d’entraînement. C’est la version infrastructure du biais de flatterie.

Quand on cache la logique dans une boîte noire

Le vrai problème de Supabase n’est pas Supabase lui-même. Le problème, c’est que la logique métier entre dans une boîte noire.

1. Les politiques RLS = logique métier cachée

Row Level Security est une fonctionnalité puissante. Le problème, c’est que quand l’IA génère des politiques RLS, où vivent-elles ?

  • Pas dans le code. Elles se trouvent dans le tableau de bord Supabase.
  • Pas dans git. Pas de versionnage.
  • Pas dans les tests. Pas de validation en CI.

La réponse à « qui peut accéder à cette table ? » n’existe pas dans le codebase. Il faut se connecter à la console Supabase pour le vérifier. Un agent ne peut pas lire ça.

Si l’IA modifie une politique RLS pour « faire le ménage » ? L’authentification est compromise. Personne ne le sait, car il n’y a pas de tests. On le découvre après que les données client ont été exposées en production.

Ce n’est pas une hypothèse. En 2025, la CVE-2025-48757 a révélé que plus de 170 applications générées par Lovable ont exposé l’intégralité de leur base de données Supabase à cause de RLS manquantes. 303 endpoints vulnérables, des e-mails, des clés API et des informations de paiement ont été divulgués. En janvier 2026, le réseau social IA Moltbook a été déployé avec RLS désactivées, exposant 1,5 million de tokens API et 35 000 e-mails.

2. Edge Functions = deuxième boîte noire

La logique métier vit à deux endroits. Le code frontend et les Supabase Edge Functions. L’IA doit décider quelle logique va où. L’IA se trompe dans cette décision.

Le calcul de remise pour les paiements se trouve dans une Edge Function. Lors d’un refactoring du frontend, l’IA recrée le même calcul côté frontend. La remise est maintenant appliquée deux fois. On le découvre trois semaines plus tard dans le rapport de revenus.

3. Migration = coût de sortie

Quitter Supabase exige de démanteler quatre choses simultanément :

  1. Auth — structure JWT liée à Supabase Auth, callbacks OAuth, gestion des sessions
  2. Storage — structure des buckets, politiques d’accès, signature des URLs
  3. Realtime — abonnements WebSocket, canaux Presence
  4. Politiques RLS — toutes les règles métier non documentées

Chaque élément semble gérable en une journée, mais les quatre sont imbriqués. Changer l’Auth casse les RLS, les RLS cassées libèrent l’accès au Storage, les URLs Storage changées cassent le frontend.

C’est ça, le vendor lock-in. Entrer prend 30 secondes, sortir prend 3 mois.

La version cloud de l’enfer des ports

L’enfer des ports que vit le vibe coder en local — l’IA démarre des serveurs, ne les arrête pas, les ports se brouillent, on ne sait plus ce qui tourne — monte ici au niveau de l’infrastructure avec Supabase.

Enfer des ports local : les processus sont invisibles. Enfer Supabase : la logique métier est invisible.

Les deux ont la même structure. Ce que l’agent a créé, l’agent ne peut pas le tracer.

Quelle est l’alternative ?

Il ne s’agit pas de ne pas utiliser Supabase. Il s’agit de ne pas mettre la logique métier dans une boîte noire.

Principe : toutes les décisions doivent vivre dans le codebase.

  • Règles d’authentification → déclarées en code, validées par des tests
  • Politiques d’accès → déclarées en DDL + Rego, vérifiées en CI
  • Logique métier → un seul endroit, pas de duplication
  • Configuration d’infrastructure → déclarée en Terraform/IaC, versionnée dans git

Utiliser Supabase pour le prototypage est raisonnable. Mais au moment d’amener un prototype en production, la logique enfermée dans la boîte noire doit en sortir et migrer vers une couche déclarative.

Pour ne pas transformer la magie des 30 secondes en 3 mois de souffrance.

Vos politiques RLS sont-elles dans git ?

Vos Edge Functions ont-elles des tests ?

Êtes-vous certain que si l’IA fait « le ménage », l’authentification ne sera pas compromise ?

Supabase n’est pas le problème. Cacher des décisions là où elles ne sont pas visibles, voilà le problème.

Articles associés

Sources

  • Zhang, Y. et al. (2025). “The Invisible Hand: Unveiling Provider Bias in Large Language Models for Code Generation.” ACL 2025. arxiv.org/abs/2501.07849
  • CVE-2025-48757 (2025). Lovable 생성 앱 170+ RLS 누락으로 Supabase DB 노출. ameeba.com
  • OG William (2026). “Moltbook Hack: Supabase Vibe Coding.” 1.5M API 토큰 + 35K 이메일 노출. blog.ogwilliam.com
  • Willison, S. (2025). “Supabase MCP can leak your entire SQL database.” simonwillison.net
  • Cursino, D. et al. (2026). “Speed at the Cost of Quality? The Impact of AI Coding on Software.” MSR 2026. arxiv.org/abs/2511.04427
  • Storey, M.-A. (2026). “From Technical Debt to Cognitive and Intent Debt.” arxiv.org/abs/2603.22106
  • Encore (2026). “Backend as a Service (BaaS) in 2026: Providers, Tradeoffs, and Migration Paths.” encore.dev