Definition of Done pour le code IA : des preuves, pas des promesses

Une Definition of Done est la liste des conditions à remplir pour qu'une tâche soit considérée comme achevée. Dans le développement assisté par IA, elle doit ajouter ce qui allait de soi autrefois : que quelqu'un ait compris le code. Et elle exige des preuves plutôt que des promesses : « testé » n'est pas un achèvement, la sortie de l'exécution des tests, si.

Pourquoi le développement assisté par IA exige-t-il une autre Definition of Done ?

Parce que le goulot d'étranglement s'est déplacé. Autrefois, écrire était l'étape coûteuse et vérifier l'étape bon marché. Aujourd'hui, c'est l'inverse : le code naît en quelques minutes, la compréhension prend toujours autant de temps.

Une Definition of Done qui ne reflète pas ce déplacement déclare terminé un travail dont la partie la plus coûteuse reste à faire. La Stack Overflow Developer Survey 2025 montre où cette partie se retrouve : 45 % des personnes interrogées perdent un temps considérable à déboguer du code d'IA, et 66 % citent « presque correct, mais pas tout à fait » comme principale frustration.

À quoi ressemble une Definition of Done pour du code IA ?

Neuf points, séparés selon la personne qui les vérifie. Cette séparation est la véritable astuce : ce qu'une machine peut décider ne doit pas coûter de temps à un humain.

Vérifiable automatiquement — relève du pipeline

• L'exécution des tests est au vert, sans test ignoré.
• La couverture des lignes modifiées n'est pas inférieure à la valeur du projet.
• Aucun nouveau constat de l'analyse statique au-dessus de la gravité fixée.
• Aucune nouvelle dépendance présentant des vulnérabilités critiques connues ; licences vérifiées.
• Aucun identifiant ni secret dans le code source.

Vérifiable uniquement par un humain — relève de la revue

• Une personne nommément désignée peut expliquer la modification sans interroger l'IA.
• Le diff ne contient que ce qui relève de la tâche — aucun effet de bord imprévu.
• Les droits d'accès et les cas d'erreur ont été pris en compte, pas seulement le chemin nominal.
• Rien n'existe dans le projet qui fasse déjà la même chose.

Le dernier point est l'ajout le plus spécifique au code IA. Un modèle duplique ce qu'il ne connaît pas, et le taux de duplication augmente en conséquence depuis des années. Aucun outil ne pose cette question de lui-même.

Comment rendre « terminé » prouvable plutôt qu'affirmé ?

En joignant à l'annonce d'achèvement la preuve et non la promesse. C'est un petit changement aux grands effets, car il écarte toute une classe de malentendus.

• Au lieu de « les tests passent » : les dernières lignes de la sortie des tests avec le nombre et le résultat.
• Au lieu de « je l'ai vérifié » : la commande et sa sortie.
• Au lieu de « c'est déployé » : le code d'état de l'URL appelée.

La raison n'est pas la méfiance. La raison est qu'entre « je l'ai lancé » et « c'est au vert » se trouve une étape que l'on saute dans la précipitation — et la preuve rend ce saut impossible sans que personne n'ait à le contrôler.

Comment introduire une nouvelle Definition of Done sans qu'elle soit ignorée ?

En commençant par la partie automatique et en ajoutant la partie humaine ensuite. Une liste qui exige neuf points dès le premier jour devient une formalité au troisième.

• D'abord les cinq points automatiques dans le pipeline. Ils ne coûtent de temps à personne et ne suscitent aucune discussion : une machine qui interrompt le processus n'est pas vécue comme une mise sous tutelle.
• Ensuite deux points humains, pas quatre. Pour débuter, il est conseillé de prendre : « quelqu'un peut expliquer la modification » et « le diff ne contient que ce qui relève de la tâche ». Tous deux s'évaluent en quelques secondes et interceptent l'essentiel des problèmes.
• Ajouter les deux derniers lorsque les sept premiers sont acquis. Les droits d'accès et la vérification des doublons demandent davantage d'attention et ne valent la peine que lorsque le reste n'est plus discuté.
• Garder la liste visible. Sous forme de modèle dans la pull request, pas de page dans le wiki. Ce qui ne figure pas dans le flux de travail n'existe pas dans le flux de travail.

Une remarque sur ce à quoi s'attendre : les premières semaines semblent plus lentes. Ce n'est pas le signe que la liste est trop stricte — c'est le travail qui était auparavant repoussé et qui se fait désormais à sa place.

Qu'est-ce qui n'a explicitement pas sa place dans la Definition of Done ?

Tout ce qui n'est pas vérifiable ou qui ne concerne pas chaque tâche.

• « Le code est propre ». Formulation non vérifiable. Ce que cela recouvre se trouve dans l'analyse statique et dans la revue.
• « Documentation mise à jour ». Seulement si cela vaut réellement pour chaque tâche — sinon le point est coché par acquit de conscience une tâche sur deux et perd son sens.
• Les points que personne ne vérifie. Un critère rempli depuis un an sans que personne ne le contrôle est de la décoration.

Questions fréquentes sur la Definition of Done

En quoi la Definition of Done diffère-t-elle d'un Quality Gate ?

Le gate est la partie appliquée automatiquement, la Definition of Done est l'accord complet, points humains compris. Idéalement, le gate applique exactement les cinq points du haut — voir Qu'est-ce qu'un Quality Gate.

La même définition vaut-elle pour les prototypes ?

Non, et cela mérite d'être consigné explicitement. Un prototype a sa propre définition, plus courte. L'erreur survient lorsqu'un prototype est ensuite tenu pour terminé sans nouvelle vérification — voir Du prototype à la production.

Combien de points une Definition of Done peut-elle comporter ?

Autant que ce qui est réellement vérifié à chaque tâche. Neuf est à la limite supérieure et ne fonctionne que parce que cinq d'entre eux s'exécutent automatiquement.

Qui décide si la définition est remplie ?

Pour la partie automatique, le pipeline. Pour la partie humaine, la personne qui fait la revue — pas celle qui a soumis la modification.

La différence entre « c'est fait » et une preuve détermine si une Definition of Done tient. Code Guardian clôt chaque modification par un audit dont les constats sont prouvés par la commande — vérifié plutôt qu'affirmé.

Sources

• Stack Overflow Developer Survey 2025, section « AI » (45 % de perte de temps en débogage, 66 % « almost right »).
• GitClear, The Maintainability Gap: 2026 AI Code Quality Research.

Date : 27 juillet 2026. Appréciation technique d'ordre général.