Introduction
Je lis énormément sur le développement assisté par IA, et un refrain revient partout : le vibe coding ne peut pas marcher en production. On génère du code qu'on ne lit pas, on empile des features qu'on ne comprend plus, et un jour tout casse sur de vraies données, avec de vrais utilisateurs.
Je comprends le fond de la pensée, et le risque décrit est réel. Mais je crois que la conclusion qu'on en tire est fausse. La solution n'est pas de renoncer à générer du code. La solution est de construire un système qui permet d'itérer vite et d'envoyer en production sans risque. La différence entre les deux, c'est toute la différence entre une opinion et une méthode.
Mon contexte : la génération n'était pas un confort
Notre plateforme interne a été construite le soir et le week-end, en parallèle d'un travail à temps plein. Sans génération de code, elle n'existerait tout simplement pas : le temps disponible ne le permettait pas. La question « faut-il laisser l'IA écrire du code » ne s'est jamais posée en théorie chez nous. La vraie question a toujours été : qu'est-ce qui me permet de dormir tranquille quand ce code tourne en production sur les données de l'entreprise ?
La réponse n'est pas « relire chaque ligne ». À ce volume, la relecture exhaustive est une illusion de contrôle : on survole, on approuve, on se rassure. La réponse, c'est le système autour du code. Voici le nôtre, tel qu'il tourne aujourd'hui, pièce par pièce.
Un seul chemin vers la production
Chez nous, tout changement passe par une pull request, sans exception. Personne ne pousse directement en production, pas moi, pas l'IA. Et ce n'est pas une discipline d'équipe qui tiendrait tant qu'on y pense : c'est un verrou côté GitHub, la protection de branche rend le merge impossible sans pull request et sans CI verte. Et cette pull request ne peut être fusionnée que si l'intégration continue est entièrement verte : le lint, la vérification de syntaxe, plus de 600 tests automatiques, un audit de sécurité des dépendances, un inventaire complet de ce qui compose l'application, une analyse statique de sécurité du code, et des tests de fumée qui démarrent réellement l'application et cliquent dans l'interface comme le ferait un utilisateur.
Le point central est là : le système ne fait pas confiance à l'auteur, quel qu'il soit. Le code généré par l'IA est soumis exactement aux mêmes contrôles que le code que j'écrirais à la main. Une fois la pull request fusionnée, le déploiement est automatique. Et chaque pull request a son environnement de préversion : une copie jetable de l'application où on clique et on vérifie avant que la production ne voie quoi que ce soit.
Un mot sur les environnements. La chaîne classique est développement, staging, production. À notre taille, on assume plus simple : deux niveaux suffisent, le poste de développement et la production, avec les préversions par pull request comme sas de vérification entre les deux. Un staging permanent partagé aurait un coût d'entretien réel pour un bénéfice marginal à 11 personnes, et il finirait par dériver de la prod. L'important n'est pas le nombre d'environnements, c'est la règle qu'ils imposent : aucun changement n'arrive en production sans avoir tourné ailleurs d'abord.
Chaque incident devient un verrou
Deux règles simples portent l'essentiel de la fiabilité.
La première : chaque fonctionnalité embarque son test, dans la même livraison. Pas de « on testera plus tard ». La logique métier vit dans des fonctions pures, testées sans dépendre de la base de données, donc rapides et impossibles à sauter.
La seconde : chaque bug corrigé devient une garde de régression. Le test décrit l'incident, la date, la cause, et vérifie que la correction est toujours en place. On en a aujourd'hui près de 240, et c'est notre vraie mémoire : le système ne peut que se durcir, comme un cliquet qui ne redescend jamais. Un incident vécu une fois ne peut plus revenir silencieusement.
On a poussé cette logique de cliquet plus loin : certains contrôles de l'intégration continue mesurent une dette (par exemple les vieux styles inline dans l'interface, incompatibles avec une politique de sécurité stricte) et refusent toute pull request qui la ferait remonter. Le stock existant se résorbe chantier par chantier, mais le compteur n'a le droit que de descendre.
Le système contraint aussi l'IA elle-même
C'est peut-être la partie la moins évidente, et la plus importante : les règles du projet vivent dans le dépôt de code, pas dans ma tête.
Un fichier de contexte, versionné avec le code, décrit les invariants du projet : ce qui ne doit jamais être fait, les pièges connus, les décisions actées. L'assistant IA le lit au début de chaque session. Les procédures répétables (comment livrer un changement, la checklist de fin de développement, comment auditer tel sous-système) sont elles aussi versionnées, comme des recettes que chaque session relit au lieu de réinventer. Résultat : que ce soit moi un lundi soir ou une session IA un samedi matin, le travail part des mêmes règles, et les leçons apprises survivent d'une session à l'autre.
On a même une « definition of done » explicite, dans le dépôt : une fonctionnalité n'est pas finie tant qu'elle n'a pas son test, sa documentation mise à jour dans la même pull request, son cycle de vie complet (créer implique modifier et supprimer), et sa décision d'accès (qui a le droit de s'en servir, et comment on l'ouvre à d'autres sans redévelopper). Ce sont des questions qu'on se posait après coup ; maintenant elles bloquent la livraison.
Dernier garde-fou, plus humain : au-delà de deux jours de travail estimé, aucun chantier ne démarre sans un mini-cadrage de cinq lignes validé en amont (le problème, le budget de temps, l'approche, ce qu'on ne fera pas, les risques). Cinq lignes suffisent à éviter les usines à gaz, et l'IA génère d'autant mieux que le périmètre est net.
Même la documentation est sous contrainte
Un détail dont je suis particulièrement content : chaque page de documentation a un budget de mots, vérifié par l'intégration continue. Si une page dépasse, la règle n'est pas d'augmenter le budget, c'est de compresser : élaguer le périmé, fusionner, résumer. L'oubli est une fonctionnalité. Une documentation qui gonfle sans limite devient fausse, et une documentation fausse est pire que pas de documentation, surtout quand c'est une IA qui la relit à chaque session pour comprendre le projet.
Et après le déploiement : détecter vite
Tout ce qui précède agit avant la mise en production. Mais un système honnête assume qu'il laissera passer des choses, et se donne les moyens de les voir en minutes plutôt qu'en semaines. C'est la deuxième moitié du dispositif.
- Des healthchecks au déploiement. La plateforme d'hébergement vérifie que l'application répond avant de basculer le trafic : un déploiement qui ne démarre pas ne remplace jamais celui qui tournait.
- Des alertes opérationnelles dans notre Discord. Quand un flux entrant se met à rejeter des données ou qu'une tâche planifiée prend du retard, l'équipe le voit dans le canal ops en temps réel, pas dans un rapport mensuel.
- Un gardien nocturne d'intégrité. Chaque nuit, un contrôle parcourt la base à la recherche d'incohérences : références orphelines, compteurs qui divergent. Les problèmes de données se signalent avant qu'un humain les rencontre.
- Une évaluation quotidienne de l'IA embarquée. Notre assistant interne passe chaque matin une batterie de questions étalonnées, dont des sondes de droits d'accès : si une réponse expose une donnée à quelqu'un qui ne devrait pas la voir, c'est une alerte rouge immédiate.
- De l'observabilité produit avec PostHog. Session replay avec masquage systématique (jamais un texte saisi ni un numéro à l'écran), suivi des erreurs navigateur, et une poignée d'événements produit aux noms figés. On voit ce que les utilisateurs vivent réellement, pas ce qu'on imagine.
La logique d'ensemble : les contrôles d'avant-merge empêchent, l'observabilité d'après-déploiement détecte. L'un sans l'autre est incomplet ; les deux ensemble font qu'une erreur a très peu d'endroits où se cacher.
Le vrai débat n'est pas celui qu'on croit
Ce que les critiques du vibe coding décrivent, au fond, ce n'est pas un problème d'IA. C'est un problème vieux comme le métier : du code non vérifié en production. Un développeur humain fatigué, pressé, qui pousse sans tests ni revue, produit exactement les mêmes catastrophes. L'IA n'a pas créé ce risque, elle l'a rendu massif et visible, parce qu'elle a démocratisé la production de code.
Du coup, le clivage pertinent n'est pas « code humain contre code généré ». C'est « code vérifié contre code non vérifié ». Et sur ce clivage, ma conviction est simple : une petite structure outillée d'un vrai système de vérification itérera plus vite, et plus sûrement, qu'une grosse équipe qui relit tout à la main.
Par où commencer
Si vous générez du code aujourd'hui et que la production vous fait peur, ne commencez pas par lire plus. Commencez par verrouiller plus :
1. Interdisez le chemin direct vers la production, même pour vous.
2. Mettez une intégration continue qui bloque sur les tests et le lint, même minimale au début.
3. Imposez la règle « une feature, un test, même livraison ».
4. Transformez chaque bug en test de régression, systématiquement.
5. Versionnez vos règles et vos procédures dans le dépôt, pour que l'IA travaille sous les mêmes contraintes que vous.
6. Instrumentez la production : erreurs, replays, alertes. Ce que la CI laisse passer doit se voir en minutes, pas en semaines.
7. Ajoutez le reste, cliquet par cliquet, à chaque incident évité de justesse.
La question à se poser n'est pas « est-ce que je peux faire confiance à l'IA ». C'est : qu'est-ce qui, dans mon système, attrape une erreur avant mes utilisateurs ? Tant que la réponse est « moi, en relisant », vous avez un problème, avec ou sans IA. Le jour où la réponse est « mon système, à chaque livraison », le débat sur le vibe coding devient ce qu'il aurait toujours dû être : une question d'outillage, pas une question de foi.
