En production, l'IA met à nu ce qui était déjà fragile dans votre organisation.
Il y a trois mois, nos PO se sont mis à livrer des démonstrations qui tournaient : du logiciel qui fonctionne, écrit sans passer par un développeur. Une démo, on ne la maintient pas, et c'est très bien ainsi. Le sujet devient différent lorsque cette même facilité sert à écrire le code qui part en production, ce code que nous ferons vivre et évoluer pendant plusieurs années.
Le vibe coding fonctionne, nous l'avons constaté, souvent très bien au premier abord. Reste à savoir ce qu'il coûte sans cadre approprié.
Vous vivez déjà le paradoxe
Le terme vient d'Andrej Karpathy, en février 2025 : se laisser porter par « les vibes » et « oublier que le code existe ». Il parlait de projets jetables, bricolés un week-end. Collins en a fait le mot de l'année. Depuis, le vibe coding a quitté le bac à sable pour entrer en production, là où il n'était pas attendu.
Ici, deux constats s'affrontent. La vitesse, d'abord : le rapport DORA de Google 2025 recense 90 % d'équipes techniques équipées d'IA, dont plus de 80 % déclarent un gain de productivité. Un prototype qui prenait des jours sort désormais en quelques heures. La stabilité ensuite, qui recule sur ces mêmes projets : le même rapport DORA de Google établit une corrélation négative entre l'adoption de l'IA et la fiabilité des livraisons. Le temps gagné à écrire, vous le repassez à auditer et à corriger en aval. Les deux mouvements sont simultanés, sur les mêmes projets.
La formule clé du rapport DORA de Google tient en une ligne : l'IA amplifie ce qui existe déjà. Une équipe déjà outillée, tests en place et déploiements maîtrisés, accélère en gardant sa stabilité. Une équipe fragile voit ses failles grossir au rythme de sa production.
D'où l'erreur du débat « opportunité ou dette » : tout se joue chez vous, dans ce que l'IA rencontre en arrivant. Le vibe coding ne fabrique pas la dette technique ; il révèle si vous aviez de quoi la contenir.
Trois risques qui ne se voient pas tout de suite
Pour une équipe qui met en production, les vrais risques sont discrets.
D'abord, l'instabilité. Ce que mesure le rapport DORA de Google, vu du terrain : générer plus vite sans filet, c'est casser plus vite. Le code sort à un rythme que vos garde-fous n'ont jamais eu à encaisser, et chaque accélération non couverte par l'intégration continue se paie en régressions.
Vient ensuite la perte de maîtrise, un signe déjà bien visible. Le volume de code généré dépasse ce qu'un humain peut relire seul, et la documentation produite par la machine ne garantit pas que les équipes comprennent ce qu'elles livrent. L'enquête Stack Overflow 2025 le mesure autrement : la première frustration des développeurs, c'est le code « presque juste, mais pas tout à fait » (66 %), et 45 % passent désormais plus de temps à déboguer du code produit par l'IA qu'auparavant. Vos équipes finissent par livrer du code qu'elles comprennent de moins en moins.
Le dernier risque se paie plus tard : la qualité sur la durée. Une étude de GitClear, éditeur d'outils d'analyse de code, a passé au crible 211 millions de lignes écrites entre 2020 et 2024. Le code repris ou corrigé dans les deux semaines suivant son écriture y est passé de 3,1 % en 2020 à 5,7 % en 2024. Sur la même période, la part des lignes consacrées au refactoring est tombée de 25 % à moins de 10 %, et le copier-coller a dépassé le code réutilisé pour la première fois. Rien de tout ça ne se voit le jour de la démo. La facture arrive au premier changement d'envergure.
Mettre le test au centre du projet
Ces trois risques se traitent avec des méthodes que certaines équipes appliquent depuis plus de dix ans : le test devient le centre de gravité du projet, à la place du développement. Il prouve le comportement à chaque changement, y compris lorsque personne ne maîtrise plus les milliers de lignes en jeu.
Encore faut-il s'entendre sur le mot « test ». Le test unitaire vérifie une fonction isolée : rapide à écrire, l'IA en produit volontiers, au point d'atteindre facilement 100 % de couverture. Il ne dit pourtant rien de ce qui compte en production : le comportement réel de la fonctionnalité, du clic de l'utilisateur jusqu'à la base de données. Le test de bout en bout est le seul à trancher vraiment cette question. L'automatiser reste difficile : ces tests sont longs à construire et coûteux à maintenir, sensibles au moindre changement d'écran ou de contrat d'API. Le vrai travail est là, et la maîtrise se gagne à ce niveau. Le travail principal des développeurs bascule : de l'écriture du produit vers la construction de ces tests et leur tenue dans le temps.
Les plus gros cherchent la parade. Après une série d'incidents de production liés à du code généré, Amazon a durci sa règle en mars 2026 : ses ingénieurs juniors et confirmés doivent faire valider par un senior tout code assisté par IA avant la mise en production, à commencer par les zones sensibles comme le paiement ou la gestion des stocks. Le garde-fou est sain, mais seul il ne tient pas : le volume généré déborde vite une file de revues humaines. Le test automatisé prend la première ligne, il filtre à l'échelle, et laisse à la revue humaine ce qu'aucun test ne sait encore trancher.
Le reste suit une fois cette couche en place. Un pipeline qui rejoue ces tests à chaque changement pose le filet avant la vitesse : le code généré échoue tôt, là où l'erreur coûte le moins cher, au lieu de casser en prod. Les dérives que vous pouvez mesurer, du taux de code repris à la duplication, deviennent des signaux à suivre au fil de l'eau, bien avant que la facture n'arrive.
Le vibe coding excelle sur un prototype, un script interne, une démo. Le cœur métier en production, lui, réclame ce filet complet avant d'accueillir les lignes générées. L'IA garde sa vitesse, et la preuve se déplace du code relu vers le comportement observé.
Pour aller plus loin sur les pratiques d'ingénierie avec l'IA : assistants IA pour développeurs et pratiques software engineering pour les équipes data.
Et maintenant ?
Un mot sur notre propre recul. Nos premiers codes assistés par IA ont six mois, et deux effets se voient déjà. Le premier, c'est la vitesse de construction et de déploiement. Le second, c'est la perte de maîtrise : dès que les tests de bout en bout ne couvrent pas 100 % du périmètre, les surprises arrivent. Or ces tests sont difficiles à maintenir, surtout quand les projets évoluent. Le test automatisé reste notre première ligne ; pour le reste, ce qu'il ne couvre pas encore, nous gardons, comme Amazon, une revue humaine ciblée. C'est un résidu que nous cherchons à réduire, à mesure que nos tests progressent.
Le problème n'a jamais été l'outil : c'est l'absence de cadre. Autorisez l'IA, à condition de mettre le test au centre d'abord. Concrètement, voici le pipeline que nous faisons tourner.
Aucun code, écrit par une IA ou par un humain, n'atteint la production sans franchir cette porte. C'est ce qui laisse entrer l'IA sans laisser entrer sa dette.
Sources : Andrej Karpathy, définition du vibe coding (février 2025) · Collins Dictionary, mot de l'année 2025 · Stack Overflow Developer Survey 2025 (adoption 84 %, confiance 29 %, « presque juste » 66 %, débogage 45 %) · rapport DORA de Google, State of AI-assisted Software Development 2025 · étude GitClear, AI Copilot Code Quality (211 M de lignes analysées, 2020-2024) · Amazon, validation senior obligatoire du code assisté par IA (mars 2026), rapportée par The Decoder et TechRadar.
