La Rétrospective pour la Gueule de Bois du Codage aux Vibes

Quelque part dans votre base de code se trouve un module que personne ne veut toucher. Il a été livré en mars, rapidement, avec un assistant IA qui a fait la majeure partie de la saisie. Il a fonctionné lors de la démo. Il a été réécrit deux fois depuis, il apparaît dans les chronologies d'incidents, et l'ingénieur qui l'a « écrit » ne peut pas l'expliquer complètement.

Ce module a maintenant un nom. L'industrie a passé 2025 à débattre pour savoir si les outils de codage IA rendent les équipes plus rapides. En 2026, le débat est terminé et la facture est arrivée — non pas en dollars, mais en churn, files d'attente de révision et canaux d'incidents. Autonoma appelle cela le « règlement de comptes des 90 jours » : le moment où la vitesse du premier mois devient la dette du troisième mois. Gizmodo a rapporté en septembre dernier que des entreprises embauchent des ingénieurs spécifiquement pour corriger les erreurs du vibe-coding. Toute une économie de nettoyage se forme autour d'un problème que la plupart des équipes pourraient détecter elles-mêmes, quatre sprints plus tôt, dans une cérémonie qu'elles ont déjà au calendrier.

Cet article porte sur l'exécution appropriée de cette cérémonie.

La gueule de bois est mesurable

Le choc n'est pas un sentiment. Le rapport AI Engineering 2026 de Faros AI — deux ans de télémétrie provenant de 22 000 développeurs répartis dans plus de 4 000 équipes — a mis des chiffres sur les deux moitiés : l'accélération que tout le monde a célébrée, et la détérioration qui l'a suivie en aval.

Source : Faros AI, « AI Engineering Report 2026 », avril 2026.

Lisez les deux premières lignes et l'IA fonctionne. Lisez les cinq dernières et vous pouvez voir la gueule de bois se former en temps réel : le code est jeté presque neuf fois plus souvent, les incidents par PR ont plus que triplé, et près d'un tiers de changements supplémentaires atteignent la production sans qu'un seul humain ne les lise.

Le rapport DORA 2025, maintenant intitulé « State of AI-Assisted Software Development », a trouvé la même forme à l'échelle de l'enquête : 90 % des développeurs utilisent l'IA au travail, contre 76 % l'année précédente, et l'adoption de l'IA est maintenant positivement liée au débit. Mais elle « continue d'avoir une relation négative avec la stabilité de la livraison logicielle ». Plus rapide et plus instable, en même temps, dans toute l'industrie.

Il s'agit d'un échec de processus, pas d'un échec d'outil

L'IA a fait exactement ce qu'on lui a demandé de faire. Elle a produit du code plausible à un rythme pour lequel aucun processus de révision n'a été conçu. Ce qui a échoué, c'est tout ce qui l'entoure : personne n'a décidé de la quantité de vérification qu'un diff écrit par une machine mérite, de la taille de lot qui maintient la révision honnête, ou de qui possède le code qu'aucun humain n'a écrit.

Ce sont des accords de travail. Les accords de travail sont un processus. Et les preuves indiquent que le processus est précisément là où se trouve le levier. Le modèle de capacités IA de DORA identifie sept conditions qui déterminent si l'IA amplifie une équipe ou amplifie son dysfonctionnement — et elles sont toutes organisationnelles : une position IA claire et communiquée, des pratiques de contrôle de version solides, travailler en petits lots, des écosystèmes de données sains. Aucune d'entre elles n'est « acheter un meilleur modèle ».

Le rapport ROI 2026 de DORA a ajouté le côté coût. Les équipes adoptant l'IA rencontrent une courbe en J (la productivité baisse avant de grimper), et un facteur majeur est ce que le rapport appelle la taxe de vérification : les heures humaines passées à vérifier la sortie de la machine. L'enquête 2025 de Stack Overflow auprès de plus de 49 000 développeurs explique pourquoi cette taxe est si élevée. La confiance dans la précision de l'IA est passée de 40 % à 29 % en un an, et la frustration numéro un, citée par 45 % des répondants, est « les solutions IA qui sont presque correctes, mais pas tout à fait ». Le code presque correct est le type le plus coûteux. Le code incorrect échoue rapidement ; le code presque correct passe la révision et échoue en production.

Un problème d'outil aurait une solution d'outil. Un problème d'accord de travail a exactement un lieu où les équipes renégocient leur façon de travailler.

Qu'est-ce qu'une rétro de gueule de bois du vibe-coding ?

Une rétro de gueule de bois du vibe-coding est une rétrospective qui examine comment votre équipe produit du code avec l'IA, pas seulement ce qu'elle a livré. Elle remplace les opinions par les propres données de livraison de l'équipe — churn de code, latence de révision, liens d'incidents, fusions non révisées — et son résultat est un petit ensemble d'accords de travail pour les changements écrits par machine, chacun mesurable dans le sprint suivant.

Elle diffère de votre rétro régulière par la portée, pas par le format. Une rétro normale demande « comment s'est passé le sprint ? » Celle-ci pose une question plus précise : « quelle est notre relation réelle avec le code que nous n'avons pas écrit ? » Mêmes modèles, même vote, même limite de temps. Preuves différentes sur la table.

Et elle devrait avoir lieu bientôt, pas éventuellement. Les données de Faros indiquent que la détérioration se compose : le churn alimente les incidents, les incidents alimentent la charge de révision, la charge de révision alimente la tentation de fusionner sans révision. Chaque sprint sans correction de trajectoire rend la correction plus importante.

Exécutez-le sur des données, pas sur des impressions

Il y a une vraie ironie à tenir une rétrospective sur le codage à l'impression et à la mener sur des impressions. Si le mode d'échec était « nous avons fait confiance à une sortie plausible sans vérification », la cérémonie qui le corrige ne peut pas elle-même fonctionner sur des impressions plausibles. Vos intégrations détiennent déjà les preuves — vos dépôts connaissent le remaniement, votre outil de suivi connaît le retravail, votre canal d'incidents connaît la trace.

Mettez cinq questions au tableau, chacune ancrée à un nombre que vous pouvez extraire avant la réunion :

1. Quelles PR des 90 derniers jours avons-nous déjà réécrites ? Le remaniement est la mesure honnête de la vitesse. Une fonctionnalité que vous avez livrée deux fois n'a pas été livrée rapidement.
2. Où va réellement la revue ? Si le délai jusqu'à la première revue augmente pendant que les fusions sans revue augmentent avec lui, votre processus de revue se rationne discrètement. Décidez du rationnement intentionnellement.
3. Quels incidents remontent à des changements que personne n'a complètement lus ? Pas pour blâmer : pour mesurer la taxe de vérification que vous payez déjà au pire moment possible, en production.
4. Quel est notre accord de travail pour les diffs générés par machine ? Si la salle ne peut pas l'énoncer en une phrase, vous n'en avez pas. Vous avez une impression.
5. Le dernier ensemble d'actions a-t-il tenu ? Deux tiers des actions de rétro meurent. Si les vôtres l'ont fait, c'est la première correction. Rien d'autre que vous décidez aujourd'hui n'a d'importance si ça s'évapore d'ici jeudi.

Faites survivre les corrections au contact du prochain sprint

Le résultat de cette rétro n'est pas un résumé de sentiments. Ce sont deux ou trois accords de travail, chacun formulé de sorte que les données du prochain sprint puissent le confirmer ou le nier. Le modèle qui fonctionne : une règle concrète, un nombre qui bouge si elle est suivie, et un point de contrôle nommé.

• « Les PR générées par agent de plus de 400 lignes sont divisées avant revue. » Vérification : distribution de la taille des PR, prochaine rétro.
• « Rien ne fusionne sans une approbation humaine, CI vert ou pas. » Vérification : nombre de fusions sans revue, hebdomadaire.
• « Chaque revue d'incident demande si le changement déclencheur était généré par IA, et nous suivons le ratio. » Vérification : modèle de post-mortem d'incident, cette semaine.

Petits lots, revue obligatoire, traçabilité des incidents — vous remarquerez que ce sont les capacités IA de DORA, traduites en phrases sur lesquelles une équipe peut réellement s'entendre un mardi. C'est le but. La recherche nomme les capacités ; la rétro est l'endroit où une équipe les installe.

Ensuite, la boucle se ferme comme nous avons toujours soutenu qu'elle devrait le faire : la prochaine rétro s'ouvre en vérifiant si les accords ont tenu et si les nombres ont bougé. Le remaniement a-t-il diminué ? La latence de revue s'est-elle rétablie ? Est-ce que ça a tenu ? L'amélioration que vous ne pouvez pas vérifier n'est qu'une autre impression.

L'essentiel

La gueule de bois n'a jamais été le prix de l'utilisation de l'IA. C'est le prix de l'adoption d'une nouvelle façon de construire des logiciels sans jamais s'asseoir en équipe pour renégocier comment vous construisez des logiciels. Les équipes qui prennent de l'avance en 2026 ne sont pas celles qui utilisent le plus d'IA ou le moins. Ce sont celles qui ont remarqué le coup du lapin dans leurs propres données, ont convoqué la réunion et ont écrit les règles — pendant que tout le monde débattait encore de quelle impression était la bonne.

Vous n'avez pas besoin d'un spécialiste du nettoyage. Vous avez besoin de quatre-vingt-dix minutes et de vos propres chiffres.

Pas moins d'IA. Plus de réflexion.

Sources

• Faros AI — « Dix points à retenir du rapport AI Engineering 2026 : Le coup du lapin de l'accélération » (avril 2026)
• DORA — État du développement logiciel assisté par IA 2025 et annonce de Google Cloud (septembre 2025)
• Modèle de capacités IA DORA (2025)
• InfoQ — « Un nouveau rapport DORA affirme que des fondations d'ingénierie solides génèrent un retour sur investissement de l'IA » (mai 2026)
• Stack Overflow — Résultats de l'enquête développeurs 2025 (décembre 2025)
• Gizmodo — « Après que l'IA a conduit à des licenciements, des codeurs sont embauchés pour corriger les bévues du 'codage à l'impression' » (septembre 2025)
• Autonoma — « Dette technique du codage à l'impression : Le règlement de comptes de 90 jours » (avril 2026)

Lectures complémentaires

• Pourquoi 2/3 des actions de rétrospective meurent (et comment y remédier) — le problème de suivi dont dépend cette rétro pour être résolu.
• Mesurer ce que l'IA fait réellement à votre équipe — comment voir l'impact réel de l'IA sur votre équipe sans surveillance.
• Livrer et tenir : Comment mesurer si l'IA fonctionne réellement — le cadre de résultat derrière « est-ce que ça a tenu ? »
• Au-delà des sprints : Amélioration continue pour les équipes natives IA — pourquoi la cadence de réflexion compte plus quand le déploiement est continu.