Les volets précédents ont installé un déplacement : l'IA produit une part croissante du code, et le métier glisse vers spécifier, vérifier, décider. Un fait nouveau accélère ce mouvement — générer du code est devenu bon marché. Une fonction, un module, une batterie de tests s'obtiennent en quelques secondes. Mais dès lors que produire ne coûte presque plus rien, la valeur se déporte vers ce qui, lui, reste rare et durable : l'intention précise. Ce que vous voulez, sous quelles contraintes, avec quels critères de réussite et quels cas limites — la spécification. C'est elle que vous relisez le code contre elle, c'est elle qui survit quand le code généré est jeté et régénéré. Spécifier avant de générer n'est pas une politesse : c'est là que se joue désormais l'essentiel.
Générer est devenu bon marché — spécifier, non
Quand la génération coûtait cher, le goulot d'étranglement était la production de lignes. Ce mur est tombé : l'IA écrit vite, et la contrainte se déplace en amont, vers la formulation de ce qu'on veut vraiment. Or un vieux principe du logiciel reprend ici toute sa force, amplifié — garbage in, garbage out. Une intention floue ne bloque plus la machine ; elle produit désormais, très vite, un code plausible mais à côté de la cible. Ce n'est pas un défaut de réglage, c'est une propriété du procédé. La grande synthèse « A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions » (Huang, Yu, Ma et al., arXiv 2311.05232) le pose d'entrée : les modèles « sont sujets à l'hallucination, générant un contenu plausible mais non factuel ». Sous-spécifiez, et vous obtenez un rendu net, fluide, convaincant — et faux là où vous n'avez rien précisé (Fig. 1). Le levier n'est donc plus la vitesse de production ; c'est la précision de ce que vous demandez. Ce déplacement prolonge exactement celui posé dès « écrivons-nous encore du code ? » : moins produire à la main, davantage spécifier avec l'esprit.
Cet article porte sur la spécification comme artefact que vous rédigez et possédez avant de générer : l'intention, les contraintes, les critères d'acceptation, les cas limites. Deux sujets voisins vivent ailleurs dans la série et ne se confondent pas avec lui. Ce que le modèle a sous les yeux au moment de répondre — quels documents, quelles données à jour, dans quel ordre — relève du context engineering : c'est une décision sur ce que le modèle voit à l'exécution, pas sur ce que vous voulez. Et le cadre général du déplacement du métier — pourquoi produire n'est plus le cœur — est le fil rouge posé dans « écrivons-nous encore du code ? ». Ici, ni l'un ni l'autre : le sujet est l'acte d'exprimer une intention précise, et de le faire avant la génération.
Le coût d'une spécification floue se paie en aval
Pourquoi spécifier avant, et non corriger après ? Parce qu'un défaut d'intention ne coûte pas le même prix selon le moment où on le rattrape. C'est l'un des résultats les mieux établis du génie logiciel. Le rapport de la NASA « Error Cost Escalation Through the Project Life Cycle » (Stecklein, Dabney, Dick, Haskins, Lovell, Moroney, NASA Johnson Space Center, INCOSE 2004) le chiffre sans détour : si corriger une erreur d'exigences au moment où elle naît vaut « 1 unité », la corriger en phase de conception coûte « 3 à 8 unités », à la fabrication « 7 à 16 unités », à l'intégration et aux tests « 21 à 78 unités », et en exploitation « de 29 à plus de 1500 unités ». Le même rapport rappelle le résultat fondateur de Boehm : « trouver et corriger un problème logiciel après livraison peut coûter jusqu'à 100 fois plus cher » qu'au stade des exigences.
Ce que la génération bon marché change n'est pas cette courbe, c'est sa vitesse. Autrefois, une exigence floue mettait du temps à devenir du code coûteux à défaire ; aujourd'hui, elle devient instantanément un module entier, plausible, qu'on intègre sans y regarder. Le défaut d'intention traverse les phases plus vite qu'avant — et se paie donc plus loin en aval, là où il coûte le plus. Générer sans spécifier, c'est court-circuiter précisément l'étape où l'erreur est la moins chère à corriger. Et l'on valide alors un code dont on ne maîtrise plus les raisons, ce qui nourrit directement la dette de compréhension : plus le code arrive vite et fini, plus la tentation est grande de sauter la spécification qui aurait dit s'il était juste.
La spécification est l'oracle qu'on relit
Une intention précise n'est pas seulement une bonne pratique en amont : c'est ce qui rend le code vérifiable en aval. Pour juger si un code fait ce qu'il doit, il faut une référence qui dise ce qui est correct — sans quoi « vérifier » n'a pas de sens. Le génie logiciel nomme cette référence l'oracle. La grande synthèse « The Oracle Problem in Software Testing: A Survey » (Barr, Harman, McMinn, Shahbaz, Yoo, IEEE Transactions on Software Engineering, vol. 41, 2015) le définit ainsi : « distinguer le comportement désiré et correct d'un comportement potentiellement incorrect » est ce qu'on appelle « le problème de l'oracle de test » — et, précisent les auteurs, « sans automatisation de l'oracle de test, c'est à l'humain de déterminer si le comportement observé est correct ». La spécification — intention, contraintes, critères d'acceptation, cas limites — est cet oracle : ce que vous relisez le code contre lui (Fig. 2). Sans elle, une revue n'a rien à quoi confronter la sortie ; c'est le prolongement direct de la revue de code assistée par l'IA et des tests à l'ère de l'IA : on ne juge bien que ce dont on a spécifié ce qu'on attendait.
Un critère d'acceptation est une condition vérifiable qui dit à l'avance ce que « réussi » signifie pour un changement : une entrée donnée doit produire telle sortie, tel cas limite doit être géré de telle façon, telle contrainte de sécurité ou de performance doit tenir. Écrire ces critères avant de générer, c'est fixer l'oracle : la référence à laquelle on confrontera le code, quel que soit celui qui l'a produit. Un prompt dit « fais ceci » ; un critère d'acceptation dit « voici comment on saura que c'est bien fait ». Le premier lance la génération ; le second permet de la juger — et de la refaire tant qu'elle n'y satisfait pas.
La génération bon marché crée une tentation nouvelle : lancer un prompt vague, obtenir un code plausible, l'intégrer, et ne formuler l'intention — au mieux — qu'après coup, pour « expliquer » ce qui a été produit. C'est l'ordre inversé, et il coûte cher. Quand la spécification vient après le code, elle épouse ce que l'IA a fait au lieu de dicter ce qu'elle devait faire : on ne vérifie plus rien, on justifie. Le prompt n'est pas la spécification. Formuler « écris une fonction qui valide un e-mail » ne dit ni quels formats accepter, ni comment traiter l'invalide, ni quelle contrainte de sécurité tenir — et tout ce qui n'est pas spécifié sera deviné, plausiblement, parfois faux. Spécifier après génération, c'est écrire l'énoncé une fois qu'on a copié la réponse.
- Nommez l'intention, pas seulement la tâche. Non pas « écris ceci », mais « voici ce que ce code doit accomplir, et pour qui ». Ce que vous ne dites pas, le modèle le devine.
- Écrivez les critères d'acceptation d'abord. Comment saurez-vous que c'est réussi ? Fixez l'oracle avant la génération, pas après.
- Rendez les contraintes explicites. Sécurité, performance, compatibilité, dépendances à ne pas toucher : ce qui reste implicite ne sera pas respecté par hasard.
- Énumérez les cas limites. L'entrée vide, la valeur nulle, le débordement, l'accès refusé : les nommer dans la spec, c'est les faire exister pour la vérification.
- Traitez la spec comme l'artefact durable. Le code se régénère ; la spécification, vous la gardez, la versionnez, la relisez. C'est elle qui a de la valeur dans le temps.
Spécifier reste un acte humain
Le déplacement est le même que dans toute cette série, et il devient ici très concret : la production de code se délègue ; l'expression de l'intention, non. Décider ce que le système doit faire, sous quelles contraintes, et à quoi on reconnaîtra que c'est juste — c'est un acte de spécification, et il engage la responsabilité de qui l'écrit. Le droit rejoint le génie logiciel sur ce point. Le règlement européen sur l'IA, à son article 14, impose que les personnes chargées de superviser un système à haut risque puissent « décider […] de ne pas utiliser le système, ou d'ignorer, passer outre ou inverser sa sortie », et restent conscientes de « la tendance à se fier ou à trop se fier automatiquement » à ce qu'il produit. Transposé à la génération : ce que l'IA produit reste une proposition à confronter à une intention que, elle, vous détenez. Le code généré est jetable et régénérable ; la spécification est ce qui survit — et ce dont vous répondez.
La leçon vaut au-delà du code que l'on fait écrire. Dès qu'on demande à l'IA de déboguer un code existant, la même règle joue : sans une attente précise de ce que le programme devrait faire, un correctif plausible peut masquer le vrai problème au lieu de le résoudre. Spécifier avant de générer, c'est refuser de laisser la facilité de production décider à votre place de ce qui est juste. La génération n'est jamais l'intention ; elle est une réponse à l'intention que vous avez su formuler.
- La thèse : générer est devenu bon marché ; la valeur se déplace vers l'intention précise. La spécification est l'artefact durable — c'est elle qu'on relit et qui survit au code jeté.
- Le risque amplifié : « garbage in, garbage out » — une intention floue produit vite un code « plausible mais non factuel » (survey hallucination, arXiv 2311.05232).
- Pourquoi avant : un défaut d'intention coûte « jusqu'à 100 fois » plus cher corrigé tard que tôt (NASA, INCOSE 2004, d'après Boehm) — et la génération le propage plus vite.
- La spec = l'oracle : « sans oracle, c'est à l'humain de déterminer si le comportement est correct » (Barr et al., IEEE TSE 2015) ; les critères d'acceptation fixent cette référence.
- Le fil rouge : spécifier reste un acte humain, imputable, et le relecteur peut toujours « ignorer, passer outre ou inverser » la sortie (règlement européen, art. 14).
Le fil rouge de la série : écrivons-nous encore du code ?. Ce que le modèle voit à l'exécution, à ne pas confondre avec la spec : le context engineering. Ce qu'on ne juge bien que si on l'a spécifié : les tests à l'ère de l'IA et la revue de code assistée par l'IA. Ce qui se creuse quand on saute la spécification : la dette de compréhension. Côté outils, pourquoi une intention précise change tout : déboguer son code avec l'IA.
Onzième volet de notre série « Le métier dev change avec l'IA ». Pour situer l'IA sans céder au discours magique, téléchargez l'Atlas IA 2026 et abonnez-vous à la newsletter AISKILLSPRO.
Au-delà de l'IA, retrouvez nos guides, tutoriels et modules Odoo sur OdooSkills, le blog Odoo ↗ (nouvel onglet).