Le Piège du Vibecoding : Votre SaaS codé en 48h court à la catastrophe

ParPhil MAJ

L’Illusion de la Vitesse

Nous vivons l’âge d’or du « Vibecoding ». Avec des outils comme Claude Code, Cursor et v0, n’importe qui peut assembler un MVP (Minimum Viable Product) en un week-end. C’est grisant. Ça marche. Les utilisateurs s’inscrivent.

Puis vient le jour 20. Vous voulez ajouter une feature. Vous demandez à l’IA de modifier la base de données. Vous pushez.Et soudain, la production s’arrête. Les données clients sont corrompues, votre instance n8n a brûlé 500€ de crédits en une heure, et vous n’avez aucun moyen de revenir en arrière.

Ce document est une autopsie d’un cas réel. Il détaille comment nous avons transformé un prototype « codé au feeling » en une architecture d’ingénierie robuste, et les horreurs que nous avons découvertes en soulevant le capot.

I. L’Anatomie du Désastre (Avant-Intervention)

Le projet tournait selon le standard « Vibecoder » classique :

  1. Un seul environnement : La Production (prod_project_ref).
  2. Modifications « Live » : Colonnes ajoutées à la main via le Dashboard Supabase parce que « c’est plus rapide ».
  3. Monolithe d’automatisation : Un workflow n8n géant gérant toute la logique métier.
  4. Confiance aveugle : « L’IA a généré le SQL, ça doit être bon. »

L’objectif de l’intervention de 2.5 jours était simple : Créer un environnement de DEV isolé. Ce qui devait être une formalité a révélé une dette technique critique.

II. Les 3 « Killers » Silencieux découverts

1. Le « Schema Drift » (Le mensonge de votre base de données)

Le symptôme le plus courant du vibecoding est la décorrélation entre le code (les fichiers de migration) et la réalité (la base de données).

Sur ce projet, nous avons découvert que 15% du schéma de production n’existait nulle part dans le code.

  • Tables fantômes (keep_alive, shops) créées à la main.
  • Colonnes critiques (profiles.is_admin, shops.languages) ajoutées via le dashboard UI.
  • Fonctions RPC (is_admin()) existant uniquement en mémoire de la prod.

La conséquence : Impossible de cloner la prod. Si la production avait crashé ce jour-là, la restauration via le code aurait généré une application cassée, manquant de colonnes vitales pour le frontend.

La solution : 6 migrations de « Backfill » (Rétro-ingénierie). Nous avons dû écrire manuellement le SQL pour recréer ce que l’interface graphique avait fait, table par table.

2. La boucle infinie à 3500 exécutions (Le piège n8n)

L’automatisation Low-Code est puissante, mais sans garde-fous, elle est financièrement mortelle.

Lors de la séparation des environnements, un workflow n8n mal configuré (utilisant une expression $json[0].total_productsqui renvoyait undefined à cause d’un changement de structure) est entré en boucle. Sans condition d’arrêt stricte, le nœud a relancé le process 3526 fois en quelques minutes.

Impact : Surcharge CPU de l’instance, pollution des logs, et potentiel coût API massif si des appels LLM avaient été connectés à cette boucle.

Leçon : Ne jamais itérer sans un IF vérifiant explicitement que la limite est un Number > 0. L’IA oublie souvent ce détail.

3. Le RLS (Row Level Security) : « Ça marche sur ma machine »

C’est le classique absolu. En local ou avec un token service_role (admin), tout fonctionne. Mais une fois déployé avec de vrais utilisateurs : Écran blanc.

Nous avons trouvé des tables avec ALTER TABLE ENABLE ROW LEVEL SECURITY activé, mais zéro policies. En PostgreSQL, cela signifie : Verrouillage total. Personne ne passe, même pas pour lire. L’application échouait silencieusement (pas d’erreur 500, juste des tableaux vides) car les requêtes SELECT ne renvoyaient rien.

Leçon : Une migration qui active RLS doit obligatoirement contenir les policies CREATE POLICY associées dans le même fichier.

III. L’Architecture Cible : Le « Crash-Proof » Setup

Pour sortir du mode « Apprenti Sorcier », nous avons déployé une architecture stricte.

Le choix de l’infrastructure : Cloud vs Docker

Nous avons évalué trois approches :

  1. Local Docker : Trop lourd pour cette équipe (RAM, complexité).
  2. Supabase Branching : Encore trop jeune/instable pour la prod critique.
  3. Double Projet Cloud : Retenu.

Un projet PROD et un projet DEV distincts sur Supabase.

  • Avantage : Accessible depuis n’importe quel poste, pas de Docker à maintenir.
  • Coût : Marginal sur le long terme comparé au risque de perte de données.

Le Script de Synchro (supabase-sync.sh)

Pour éviter l’erreur humaine (faire un db push sur la prod en pensant être en dev), nous avons scripté l’interaction.

# Exemple de logique simplifiée du script de protection
./scripts/supabase-sync.sh dev   # Link DEV -> Dry-run -> Push
./scripts/supabase-sync.sh prod  # Link PROD -> Dry-run -> Confirm -> Push -> Re-link DEV

Règle d’or : Le terminal est toujours lié à DEV par défaut. La connexion à PROD est éphémère, le temps de la commande, et se coupe immédiatement après.

Ségrégation n8n

Le monolithe n8n a été découpé en 5 workflows atomiques. Pour gérer le multi-environnement dans n8n (qui supporte mal les variables d’env dynamiques pour les nœuds Supabase natifs), nous avons remplacé les nœuds natifs par des HTTP Requests utilisant des URLs injectées via une « Data Table » de configuration.

IV. Le Manifeste de Survie pour SaaS IA

Si vous codez avec l’IA, voici les règles non-négociables pour ne pas exploser en vol :

  1. L’UI Supabase est en lecture seule : Interdiction formelle de créer une table ou une colonne via le Dashboard. Si ce n’est pas dans un fichier .sql de migration, ça n’existe pas.
  2. Idempotence : Vos scripts SQL doivent pouvoir être lancés 10 fois sans erreur (IF NOT EXISTS est votre meilleur ami).
  3. Parité des Secrets : Les Edge Functions échouent souvent en DEV car vous avez oublié de copier les secrets (.env) de la PROD vers le projet DEV. Chaque projet a son propre vault.
  4. Audit des Policies : Ne jamais commiter un ENABLE RLS sans ses GRANT et POLICY. C’est la cause n°1 des bugs « invisibles » en production.
  5. Stop au Monolithe n8n : Un workflow ne doit faire qu’une seule chose. Si vous avez besoin de scroller pour voir la fin du workflow, il est trop gros.

Conclusion

Le « Vibecoding » permet de démarrer vite. L’ingénierie permet de ne pas s’arrêter brutalement. La transition de l’un à l’autre n’est pas une option, c’est une étape de survie. Ce RETEX montre qu’en 2.5 jours, on peut rattraper des mois de dette technique, à condition d’accepter de regarder la réalité (et le SQL) en face.

Publications similaires