Votre IA n'écrit pas du mauvais code. Vous écrivez de mauvaises spécifications.

L'automatisation tournait depuis 10 minutes quand la notification est arrivée. Un email envoyé à un contact que tout mon système évitait soigneusement depuis 6 mois. Merde. Trop tard...

J'ai relu les spécifications. Elles disaient : « relancer les prospects actifs ». C'est tout. Pas de liste d'exclusion, pas de filtres de statut, aucune contrainte sur qui ne pas contacter. Claude a exécuté exactement ce que j'avais écrit, sans hésitation, sans rien omettre.

Le problème, c'est la spec, pas le modèle, pas le prompt.

J'ai Oublié Une Ligne. Claude a Fait le Reste.

L'agent avait accès à toute la liste de contacts. Tous : prospects actifs, leads dormants, un distributeur avec qui on avait discrètement cessé de travailler 6 mois plus tôt, et 2 ou 3 personnes d'un partenariat qui s'était terminé d'une façon que personne ne voulait revivre par email automatisé. La spec ne mentionnait rien de tout ça. Elle disait « prospects actifs », ce qui dans ma tête avait un sens construit sur des mois de contexte, 12 décisions informelles, et au moins 1 conversation gênante que j'avais complètement oublié de documenter quelque part.

Claude ne savait rien de tout ça. Claude savait ce que disait la spec.

Alors il a relancé. Tout le monde qui n'était pas explicitement exclu. Professionnellement, rapidement, exactement dans le ton que j'avais demandé. La liste de contacts n'avait pas de flag « ne pas emailer » parce que je n'avais jamais pensé à en ajouter un. La spec n'avait pas de règles d'exclusion parce que je supposais que c'était évident. L'agent a tourné sur ce qui existait, pas sur ce que j'avais l'intention de faire.

C'est ça qui change avec la vitesse d'exécution de l'IA : un dev humain avec la même spec aurait peut-être posé une question de clarification, ou pris une décision, ou au moins hésité sur le cas limite. Un agent n'hésite pas. Il livre. (En C, on appelle ça du comportement indéfini. Avec les agents IA, on appelle ça « la spec que j'ai écrite ».)

Claude n'a pas fait d'erreur. J'ai laissé une porte ouverte.

(Et oui, après ça j'ai relu toutes les autres specs que j'avais écrites pour ce pipeline. J'ai trouvé 4 autres contraintes manquantes dès le premier passage.)

GIGO a Toujours Été la Règle.

GIGO : Garbage In, Garbage Out. Le principe date de 1957, inventé sur des mainframes militaires quand les programmeurs ont découvert qu'alimenter un ordinateur avec des données incorrectes produisait des sorties incorrectes avec une parfaite constance. La machine exécutait correctement. Le problème était toujours en amont.

Ce n'étaient pas des unités avec du jugement. C'étaient des IBM 709 qui lisaient des cartes perforées. L'ambiguïté n'était pas une option. L'entrée était binaire, la sortie était binaire, et l'écart entre les deux était toujours l'humain.

Pendant 60 ans, GIGO décrivait un problème de qualité des données. Mauvaises données d'entraînement en entrée, mauvaises prédictions du modèle en sortie. Ce cadrage s'applique toujours. Ce qui a changé, c'est la couche où les déchets entrent.

Avec les agents IA, les déchets entrent au niveau de la spec, pas au niveau des données. L'entrée n'est pas un fichier CSV corrompu. C'est une spécification incomplète : une règle écrite trop vaguement, un périmètre défini trop largement, une liste d'exclusion qui n'existe que dans la tête de quelqu'un. L'agent n'absorbe pas l'ambiguïté. Il l'exécute, à la vitesse que vous lui avez donnée, contre toutes les données auxquelles il a accès.

J'ai remarqué cette semaine que mon IDE sauvegarde automatiquement toutes les 2 secondes. J'ai activé et désactivé ce paramètre au moins 5 fois au fil des ans, et je ne me souviens vraiment pas de ce que je voulais réellement. Le paramètre semble assez important pour exister en tant que paramètre mais pas assez important pour noter la raison. Bref, on est nuls pour documenter les petites décisions.

Google a Nommé le Nouveau Goulot d'Étranglement le Mois Dernier

En mai 2026, un livre blanc de Google d'Osmani, Saboo et Kartakis a atterri sur Kaggle et est resté relativement discret pendant quelques semaines avant que la communauté dev rattrape. L'argument principal : le changement qu'on vit n'est pas un nouveau langage ou un nouveau framework. C'est un passage de l'écriture de code à l'expression d'intention, et la plupart des échecs qui apparaissent comme des « problèmes d'IA » sont en fait des problèmes d'intention en amont.

Selon leurs chiffres, environ 85% des développeurs professionnels utilisent maintenant régulièrement des agents de codage IA, avec environ 41% de tout le nouveau code généré par IA. À cette échelle, une spec vague tourne à la vitesse du générateur contre des données client en direct. La revue de code n'en attrape rien. Et les maths se composent rapidement : si même une fraction de ces bases de code générées tournent sur des specs incomplètes, la surface d'attaque pour des incidents comme mon automatisation d'outreach cesse d'être du territoire de cas limite. Ça devient la norme.

Le cadrage central du papier : « La plupart des échecs d'agent, examinés honnêtement, sont des échecs de configuration ». Pas des lacunes de capacité dans le modèle. Des échecs de configuration dans le harnais. Osmani a écrit séparément sur son blog après le livre blanc que quand un agent fait quelque chose d'inattendu, son premier réflexe est de vérifier le harnais, pas de questionner le modèle. Habituellement c'est un outil manquant, une règle qu'il a écrite trop vaguement, ou un garde-fou qu'il a oublié d'ajouter. Ça correspond exactement à ce qui est arrivé à mon pipeline d'outreach.

L'article Bloomberg précédent a fini par diagnostiquer la mauvaise maladie : ils ont vu les symptômes correctement (panique de productivité, sorties IA buggées, dérive de périmètre) et ont blâmé les outils. Le livre blanc est plus précis. Les échecs de capacité et les échecs de configuration sont des problèmes différents qui pointent vers des corrections différentes. Une correction est un meilleur modèle. L'autre est d'écrire la spec que vous auriez dû écrire avant de faire tourner quoi que ce soit.

Votre Spec d'App To-Do Casse Ici.

Essayez ça. Écrivez une spec pour une app to-do qui cause un vrai incident de production. Ajouter une tâche, compléter une tâche, supprimer une tâche, lister les tâches. Il n'y a nulle part où la spec peut mal tourner d'une façon qui endommage quelque chose de réel. Le pire cas est un élément marqué complet alors qu'il ne devrait pas l'être.

Maintenant écrivez une spec pour une automatisation d'outreach touchant des contacts partenaires et des comptes actifs. Qui est contacté, sous quelles conditions, exclu quand, de quelle liste, basé sur quel champ de statut, avec quel override pour les comptes en attente, et qu'en est-il des 2 partenaires actuellement en renégociation de contrat que vous gérez personnellement depuis 3 semaines ? Chacune de ces contraintes manquantes est une porte par laquelle l'agent va passer.

C'est basiquement la différence entre la zone tutoriel et le premier vrai donjon. Mêmes mécaniques, ensemble de conséquences complètement différent. La plupart des specs codées à l'instinct sont écrites pour la zone tutoriel et déployées dans le donjon.

La plupart des builders appliquent la discipline de spec d'app to-do à des outils de production avec des effets dans le monde réel. « Relancer les prospects actifs » laisse ouvert ce que « actif » signifie exactement, quels contacts sont en pause volontaire, et lesquels sont gérés personnellement par quelqu'un qui ne sera pas content de voir un email automatisé arriver. « Synchroniser le catalogue produit avec le flux partenaire » ne dit rien sur les références actuellement en révision de contrat. « Traiter les commandes entrantes » ne donne à l'agent aucune guidance sur quoi faire avec une commande déjà gérée par l'exécution précédente.

Chaque contrainte manquante est quelque chose que l'agent va interpréter de la façon que les données rendent possible, à la vitesse que vous lui avez donnée. À l'échelle du flux partenaire, à l'échelle de l'outreach, à toute échelle où l'outil touche de vrais comptes ou de l'argent réel, laisser des trous dans la spec n'est pas une négligence que vous allez attraper en QA. C'est un incident de production qui attend la bonne combinaison de données et de timing.

L'agent construit les deux avec la même confiance. La complexité du domaine ne se transfère pas automatiquement en complexité de spec. Vous devez l'écrire.

Ce Que J'ai Construit pour Attraper les Trous.

Après l'incident d'outreach, j'ai mis une couche de raffinement de spec entre le builder et l'agent sur toute nouvelle automatisation. Rien de compliqué : un dialogue guidé par Claude qui tourne avant la première ligne de code. Il n'écrit pas la spec. Il pose des questions auxquelles vous devez répondre.

Des questions comme : qui ou quoi cet agent ne devrait-il pas toucher, sous aucune condition ? Quelles règles business implicites gouvernent ce domaine que vous n'avez jamais écrites nulle part ? Qu'est-ce qui compte comme « fini », et qu'est-ce qui compte comme « ne jamais commencer » ? Que se passe-t-il aux limites : un compte expiré, un contact en dispute, un produit signalé par le juridique, une commande déjà traitée par l'exécution précédente ?

La première fois que je l'ai utilisé sur une nouvelle automatisation de distribution, l'entrée initiale était « synchroniser le catalogue produit avec le flux partenaire ». Première question générée par l'outil : « Y a-t-il des catégories de produits qui devraient être exclues de cette sync ? » Je suis resté assis là pendant environ 5 secondes. Puis j'ai ouvert un doc d'il y a 4 mois et j'ai trouvé 12 références produit signalées comme en révision de contrat. Je n'avais jamais une seule fois pensé à les mettre dans la spec.

Ce silence après la question est son propre diagnostic. Hésitation de plus de 2 secondes = contrainte manquante. Même instinct que d'appuyer sur « merge to main » quand vous avez sauté le test run. Votre instinct sait avant votre cerveau.

La valeur n'est pas le document de sortie. C'est les 10 minutes d'inconfort avant que l'agent tourne. Je pense que ça n'attrape que ce dont vous êtes déjà à moitié conscient à un certain niveau. Si une contrainte n'a jamais traversé votre esprit du tout, aucune question ne la fera remonter. C'est le plafond honnête.

Spécifier Est la Compétence. Prompter Est un Sous-Ensemble.

L'ingénierie de prompt est la compétence d'obtenir une meilleure sortie d'un modèle dans une conversation donnée. Spécifier est la compétence de définir ce que l'agent est autorisé à faire, qui il peut toucher, sur quelles données il peut agir, et où il s'arrête. Ce sont des disciplines différentes opérant à différents niveaux de la stack.

Un prompt propre vous donne une meilleure réponse dans le périmètre que l'agent a déjà. Une spec soigneuse définit ce qu'est le périmètre. Le builder qui écrit des prompts propres contre une spec lâche livre vite et casse des choses en production. Le builder qui spécifie soigneusement livre plus lentement au début et récupère de moins d'incidents plus tard. Avec l'IA qui compresse les délais de livraison de semaines en heures, « plus tard » signifie maintenant le même après-midi.

Si vous voulez opérer au niveau projet et pas juste au niveau conversation, le framework complet des contrats de prompt couvre exactement ça : ce que l'agent peut générer, ce qu'il peut modifier, ce qui nécessite une validation humaine explicite. C'est vers quoi j'ai migré après assez d'incidents comme celui de l'email.

L'approche que je détaille dans Vibe Coding, For Real couvre l'étape antérieure : avant que toute génération de code commence, définir les conditions limites du domaine, pas juste la liste des fonctionnalités. Ce que le système ne devrait jamais faire et quelles règles business n'ont jamais été écrites parce que tout le monde supposait qu'elles étaient évidentes.

Un agent n'a aucune intuition sur ce que vous vouliez dire. Seulement sur ce que vous avez écrit.

3 Questions Avant Que Claude Ait Accès.

L'email d'incident n'aurait pas été empêché par un meilleur modèle, ou un meilleur prompt. Il aurait été empêché par 10 minutes supplémentaires de travail de spec avant que l'agent tourne.

3 questions que je pose maintenant avant que tout agent ait accès à des données live :

Qui ou quoi cet agent ne devrait-il pas toucher, sous aucune condition ? Pas « qui est exclu de ce batch » mais qui est définitivement hors limites peu importe le statut, peu importe l'appartenance à une liste, peu importe ce que montrent les données. Ces exclusions doivent être explicites dans la spec, pas implicites par le contexte.

Quelles règles business implicites n'avez-vous jamais écrites nulle part ? Pensez : le partenariat que vous avez discrètement mis en pause en novembre, les références produit qui traînent dans un doc de révision juridique que personne n'ouvre, les 2 ou 3 contacts à qui vous avez personnellement dit « je vais m'occuper de celui-là » et que vous n'avez jamais signalés nulle part dans le système. Chacune de ces choses est une contrainte que l'agent ne connaît pas à moins que vous l'écriviez.

Quel est le niveau de risque réel de ce projet ? Pas ce que vous espérez que le risque soit, mais ce qui arrive si l'agent tourne sur tout ce à quoi il a accès. Une tâche mal catégorisée dans une app to-do vous coûte 30 secondes. Un email au mauvais partenaire vous coûte une relation et une matinée. Une commande modifiée dans un flux ecommerce live vous coûte un incident de facturation et possiblement un client. Le niveau de détail dans la spec doit correspondre au niveau de risque dans le domaine, pas juste au nombre de fonctionnalités.

---

L'email d'incident m'a coûté 1 matinée et 1 relation professionnelle à réparer. L'agent a tourné exactement comme spécifié. J'ai juste oublié d'écrire la contrainte.

C'est comme ça que ça marche maintenant. L'IA exécute ce que vous écrivez, pas ce que vous pensez.

va falloir apprendre à être explicite maintenant...

Sources

• Osmani, A., Saboo, S., Kartakis, S. (2026, May). The New SDLC With Vibe Coding. Google / Kaggle. https://www.kaggle.com/whitepaper-the-new-SDLC-with-vibe-coding
• Osmani, A. (2026, June). The New Software Lifecycle. https://addyosmani.com/blog/new-sdlc-vibe-coding/
• Eveilleau, P. (2026). Vibe Coding, For Real. Amazon Kindle. https://a.co/d/0d7xiVlX

Ce post peut contenir des liens d'affiliation. Si vous cliquez dessus, je pourrais gagner une petite commission (ça ne vous coûte rien, et ça m'aide à continuer à livrer des articles de qualité chaque jour pour votre plaisir de lecture).