Test de réalité en production
Le vibe était parfait. L'application est cassée.
Le prototype est devenu un système avant d'avoir des tests et un processus de release. Un nouveau prompt n'est pas forcément la première étape.
01
Qu'est-ce qui s'est passé ?
Le vibe coding favorise la vitesse ; la production exige la répétabilité. Un prompt large mélange correctif, refactoring, dépendances et migrations.
02
Pourquoi cela arrive
- Aucun petit diff ne sépare les versions bonne et mauvaise.
- Les mocks ou données de preview ont caché une dépendance réelle.
- Chaque tentative modifie une autre zone sans rapport.
03
Ce que vous pouvez vérifier
- Arrêtez les edits et conservez commit, logs et preuve de panne.
- Comparez uniquement les changements après le dernier commit stable.
- Transformez la panne initiale en test de régression.
PAS TECHNIQUE
Vous n'avez pas écrit le code vous-même ? Vous pouvez quand même aider.
La chose la plus utile à faire maintenant n'est pas un meilleur prompt, mais d'arrêter de générer de nouveaux changements.
- Gelez le projet — plus de prompts « essaie ça » tant que quelqu'un n'a pas regardé ce qui a cassé.
- Notez approximativement quand ça marchait encore et ce que vous avez demandé à l'IA de construire ou modifier depuis.
- Sauvegardez (ou demandez à votre outil IA) l'export actuel du projet ou l'accès au dépôt.
- Listez tout ce qui touche de vrais utilisateurs, de l'argent ou des données personnelles — cela change le soin à apporter à la réparation.
Shipvise ou un reviewer senior peut utiliser cet historique pour déterminer quel changement a cassé l'application, sans que vous ayez à comprendre les commits ou les diffs.
04
Comment tester le correctif sans risque
Appliquez le correctif dans une branche dédiée, validez-le sur un staging proche de la production et déployez exactement la version approuvée. Gardez le dernier artefact stable et un rollback testé.
05
Quand faire appel à un développeur
Faites intervenir un reviewer senior quand personne ne peut expliquer l'architecture générée, quand des données risquent d'être perdues, ou quand chaque correctif casse un autre chemin. Shipvise ajoute du staging versionné, des contrôles, une revue et une décision de release explicite sans vous forcer à abandonner votre outil IA. Pas besoin d'une équipe DevOps dédiée pour une seule application.
FAQ
Les questions que l’on se pose vraiment
Le vibe coding est-il toujours dangereux ?
Non. Le risque vient du comportement non revu et des releases non contrôlées, pas de l'étiquette.
Faut-il tout réécrire ?
Pas automatiquement. Délimitez la panne et comparez une réparation contrôlée au risque d'une réécriture.
Que dois-je fournir à un développeur pour qu'il puisse réparer l'application ?
L'accès au dépôt, l'URL où ça échoue, les étapes pour reproduire le problème, les logs, le dernier commit qui fonctionnait, la configuration de déploiement et une description de ce que l'IA a changé.
Comment réparer une application vibe-codée qui s'est soudainement cassée ?
Arrêtez d'abord de demander d'autres changements à l'IA — chaque nouvelle tentative peut masquer ce qui s'est vraiment cassé. Trouvez le dernier point où ça fonctionnait, comparez-le à l'état actuel, et corrigez cette régression précise plutôt que de laisser l'IA reconstruire toute la fonctionnalité.
Pourquoi le vibe coding casse-t-il sans arrêt des fonctionnalités qui marchaient avant ?
Des prompts larges et rapides touchent souvent plus de l'application que la tâche ne l'exigeait, donc corriger une chose peut en casser une autre silencieusement. Sans petits changements vérifiables ni tests, personne ne détecte ces dégâts collatéraux avant qu'un utilisateur ne tombe dessus.
Dois-je continuer à demander à l'IA de réparer, ou est-ce que ça va empirer les choses ?
Un nouveau prompt « corrige ça » peut aider. Il peut aussi casser trois autres choses. Conservez d'abord la version cassée actuelle, déterminez ce qui a vraiment changé, et donnez à l'IA une tâche plus précise et plus ciblée plutôt que de répéter la même demande vague.
Je n'utilise pas Git — comment revenir à une version qui fonctionnait ?
Vérifiez si votre outil IA dispose d'un historique de versions ou de checkpoints, d'un export précédent, ou d'un déploiement antérieur à restaurer. S'il n'y a rien de tout ça, c'est le moment de commencer à en garder un — même une copie manuelle du projet avant chaque changement important vous aidera la prochaine fois.
Un développeur peut-il réparer une application construite avec Lovable, Bolt, Replit ou Cursor même s'il ne l'a pas construite lui-même ?
Oui. Un développeur n'a pas besoin de connaître le même outil — il lui faut l'accès au code, voir le comportement défaillant, et savoir ce qui a changé récemment. L'application obtenue reste du code et des services ordinaires ; l'outil IA qui l'a générée ne change rien à ça.