Vibe coding : comment passer de prototype à production

Les outils d'IA (Cursor, Lovable, Bolt, Replit, v0) permettent de construire 80% d'un projet en quelques heures. Mais 85% de ces projets ne passent jamais en production. Voici les 6 bloqueurs les plus fréquents — et comment les dépasser.

1. La sécurité de la base de données n'est pas configurée

Les IA génèrent souvent du code sans activer Row Level Security (RLS) sur Supabase. Résultat : en production, n'importe quel utilisateur peut lire toutes les données de tous les autres.

Ce qu'il faut faire :

• Activer RLS sur chaque table dans Supabase Dashboard
• Créer des politiques qui filtrent par auth.uid()
• Tester en incognito avec un compte différent

Les erreurs RLS (infinite recursion, accès refusé, données vides) sont les plus fréquentes et les plus bloquantes. C'est souvent là que 4 jours de travail disparaissent.

2. Les variables d'environnement ne sont pas gérées

En vibe coding, les clés API se retrouvent souvent hardcodées dans le code — ce qui fonctionne en local mais expose tes secrets sur GitHub et ne fonctionne pas en déploiement.

Check rapide :

• Tes clés Supabase, Stripe, OpenAI sont dans .env.local (jamais dans le code)
• .env.local est dans .gitignore
• Les mêmes variables sont configurées dans Vercel/Netlify Settings

3. Le schéma de base de données change en cours de route

Tu modifies les tables, ajoutes des colonnes, changes des types — mais le code généré par l'IA ne suit pas. Les migrations ne sont pas tracées, et en production tu as une version du schéma différente du dev.

Solution pratique : Utilise les migrations Supabase CLI (supabase migration new) pour tracer chaque changement de schéma. Même si tu ne les utilises pas en CI/CD, ça documente ce qui a changé.

4. Les erreurs ne sont pas gérées

Les IA génèrent rarement du code de gestion d'erreurs robuste. En production, une API qui tombe, un timeout réseau, ou une donnée manquante fait planter silencieusement l'application.

Minimum requis :

• Chaque appel API a un try/catch ou une gestion d'erreur explicite
• L'UI affiche un message d'erreur utile (pas juste un écran blanc)
• Les erreurs serveur sont loggées (Sentry, Vercel Logs)

5. Les performances ne sont pas optimisées pour la production

En local avec 10 lignes de données, tout est rapide. En production avec 1000 utilisateurs, les requêtes sans index, les images non optimisées, et les fetches non mis en cache font crasher l'expérience.

Points critiques :

• Index sur les colonnes filtrées fréquemment (CREATE INDEX ON tickets(user_id))
• Images via <Image> de Next.js (pas <img>)
• Limites sur les requêtes (.limit(50) sur Supabase)
• Éviter les N+1 queries (boucle de requêtes dans un map)

6. Le déploiement n'est pas testé correctement

Beaucoup de builders déploient et constatent que ça ne marche pas — sans avoir de processus de vérification. L'écart entre dev et prod crée des dizaines de petits bugs.

Checklist pré-déploiement :

Pourquoi les 20% restants sont les plus difficiles

Les outils d'IA sont excellents pour générer du code qui "fonctionne en démo". Mais la production exige de la robustesse : gestion des cas d'erreur, sécurité, performance, monitoring. Ce sont des problèmes systémiques que l'IA ne voit pas — parce qu'elle génère du code sans contexte de production réel.

C'est exactement le gap que Last 20% comble : des experts humains qui connaissent ces patterns d'erreurs et peuvent les corriger rapidement, avec un rapport qui t'explique ce qui n'allait pas pour que tu ne retombes pas dans le même problème.