Vibe coding : que faire quand ton app construite avec l'IA se bloque avant le lancement

Le schéma qui se répète

Chaque semaine je parle à quelqu'un bloqué au même endroit. L'histoire varie, mais la courbe est toujours similaire :

1. Tu as commencé à construire avec Cursor, Lovable, Bolt, Replit ou un mélange d'IA et de code collé à la main
2. En 48 heures tu avais quelque chose qui ressemblait à un produit
3. Chaque nouveau prompt cassait quelque chose qui marchait avant
4. Le déploiement en production a révélé des problèmes invisibles en local
5. Ça fait trois semaines que tu tournes en rond et tu ne sais pas s'il faut patcher, refactorer ou tout brûler

Si tu te reconnais, tu n'es pas seul. Ça s'appelle le vibe coding : construire vite par intuition et prompts, sans carte technique claire. Ça marche très bien jusqu'aux derniers 20 %.

---

Les quatre blocages typiques

1. La boucle de prompts

Tu demandes un petit changement, l'assistant réécrit des parties que tu n'avais pas demandé de toucher. Tu corriges ça, un autre bug apparaît ailleurs. Tu as l'impression d'avancer et reculer en même temps.

Pourquoi ça arrive : Les modèles n'ont pas de vision globale de ton code. Quand ils « aident », ils remplacent parfois une logique qui marchait par une version générique qui casse des cas d'usage réels.

Comment s'en sortir :

• Utilise le contrôle de version de façon obsessionnelle (git commit à chaque fois que ça marche)
• Réduis la portée de chaque prompt : « ne change que ce fichier, ne touche pas au reste »
• Quand l'assistant réécrit sans qu'on lui demande, fais marche arrière avec git reset avant d'accepter

2. Les pièces critiques fonctionnent presque

Login, paiements, emails, intégrations tierces, permissions de base de données. En démo elles ont l'air prêtes. En production, avec un vrai utilisateur, elles cassent.

Pourquoi ça arrive : Ces systèmes ont des détails que l'IA ne gère pas bien par défaut :

• Auth : vérification du state, expiration des tokens, cookies httpOnly et secure, gestion des redirections
• Stripe : vérification de la signature du webhook, gestion test/live, événements en double
• Email : SPF/DKIM/DMARC, distinction transactionnel vs marketing, gestion des bounces
• DB : row-level security, index, migrations réversibles

Comment s'en sortir : Ces pièces ne se vibe-codent pas. Elles ont besoin d'une revue humaine avec un œil expert. C'est le dernier 20 % qui fait le plus mal.

3. Le déploiement qui marche en local mais casse en prod

Variables d'environnement mal configurées, pipelines de build qui ne reproduisent pas l'environnement local, dépendances qui se comportent différemment en serverless, temps de cold-start.

Pourquoi ça arrive : Les environnements Vercel, Render, Railway, Supabase et Firebase ont des comportements subtilement différents du dev local. L'assistant IA ne les voit pas.

Comment s'en sortir :

• Lis les vrais logs du fournisseur, ne suppose pas
• Compare les variables d'environnement ligne par ligne entre local et production
• Si tu utilises Next.js : sépare proprement server-side et client-side
• Déploie tôt et souvent, n'accumule pas de changements sans valider en production

4. La sensation que « ce n'est plus maintenable »

Le code a grandi vite, il y a des fichiers énormes, de la logique dupliquée, des noms incohérents, et tu ne comprends plus ce que fait chaque partie. Chaque changement te fait peur.

Pourquoi ça arrive : L'IA optimise pour « que ça marche maintenant », pas pour « que ce soit lisible dans 3 mois ». Si tu n'imposes pas l'ordre, l'ordre n'apparaît pas.

Comment s'en sortir :

• Ne réécris pas tout, refactore par couches : d'abord les noms et la structure des fichiers, puis la logique
• Ajoute des tests pour les flux critiques (auth, paiements) avant de toucher au reste
• Si c'est trop cassé, décide honnêtement ce qui vaut le coup d'être sauvé et ce qu'il faut remplacer

---

Décisions honnêtes : patcher, refactorer ou refaire

Il n'y a pas de réponse universelle, mais voici les critères que j'utilise :

Patche quand :

• Le bug est local et isolé
• Le reste du code est raisonnablement sain
• Le produit est déjà en production avec des utilisateurs

Refactore quand :

• Il y a 2 ou 3 zones problématiques mais l'idée principale fonctionne
• Tu as le temps et tu n'es pas encore en production avec beaucoup d'utilisateurs
• Tu vois un schéma clair qui, bien répété, résout la majeure partie

Refais depuis zéro seulement quand :

• Le stack de base est incompatible avec ce dont tu as besoin (par ex. construire un SaaS multi-tenant sur Firebase sans penser l'auth dès le départ)
• Le code est inintelligible même pour toi
• Tu vas passer plus de temps à corriger qu'à reconstruire proprement

La plupart des projets bloqués que je vois n'ont pas besoin d'être refaits. Ils ont besoin de deux semaines de mains expertes pour débloquer des pièces précises.

---

Ce qui fonctionne dans le vibe coding

Je ne veux pas que ça sonne comme un discours anti-IA. La réalité est que construire avec Cursor, Lovable ou Bolt te donne un super-pouvoir : une vitesse initiale brutale.

Ce qui marche :

• Valider une idée produit en jours, pas en semaines
• Construire des prototypes pour obtenir du feedback tôt
• Monter des landing pages, des dashboards internes et des outils non critiques
• Rester dans le flow sans batailler avec le boilerplate

Ce qui ne marche PAS complètement :

• Mettre en production avec paiements, données sensibles ou beaucoup d'utilisateurs sans revue humaine
• Maintenir le code à long terme sans quelqu'un qui comprend ce qu'il y a dessous
• Résoudre les bugs d'intégration, de déploiement ou de sécurité uniquement à coups de prompts

La clé est de savoir où l'IA accélère et où l'IA cache de la dette technique.

---

Si tu es à ce point en ce moment

Si tu es bloqué depuis des semaines à demander des changements et voir chacun en apporter un nouveau, considère ces trois options :

Option 1 : retente seul Applique les conseils ci-dessus, engage-toi sur la discipline git, réduis la portée des prompts, et donne-toi 1-2 semaines de plus. Parfois il suffit de changer de méthode.

Option 2 : demande une revue rapide Que quelqu'un d'expérimenté regarde ton code pendant une heure et te dise objectivement où tu en es, ce qui peut être sauvé et ce qu'il faut remplacer. Une revue bien faite te fait gagner des mois.

Option 3 : travaille côte à côte avec un dev senior Particulièrement utile si ton app est proche du lancement mais que les pièces critiques (auth, paiements, déploiement) ne se ferment pas. Ce n'est pas déléguer le projet : c'est avoir quelqu'un à tes côtés pendant que tu restes aux commandes.

Pour cette troisième option j'ai un site dédié : rescuevibe.dev. Il est pensé spécifiquement pour les builders qui ont construit avec l'IA et ont besoin d'aide d'un dev senior pour atteindre la production. Diagnostic honnête d'abord, sprint focalisé ensuite si ça vaut le coup de continuer.

---

Conclusion

Se bloquer sur une app construite avec l'IA n'est pas le signe que tu fais quelque chose de mal. C'est le signe que tu as atteint le point où le vibe coding ne suffit plus et où tu as besoin d'un autre niveau de rigueur technique.

La bonne nouvelle : ces derniers 20 % qui font si mal ont des chemins clairs. Il faut juste reconnaître où tu es, quel blocage précis t'arrête, et quel type d'aide tu as besoin (si tu en as besoin).

Ton app peut atteindre la production. La question n'est pas de savoir si c'est possible, mais quelle est la route la plus courte et la plus honnête pour que ça arrive.