Critères d’acceptation : Quand l’agent sait que c’est terminé

L’un dit que c’est prêt dès que le code compile. Un autre dit que c’est prêt quand il y a des tests. Le troisième affirme que c’est prêt lorsqu’il a passé la revue de code. Le quatrième affirme que c’est prêt lorsqu’il est en production. Le cinquième dit qu’il n’est jamais réellement prêt, ouvre une bière et passe à autre chose.

Maintenant, imaginez la même question posée à un agent d’IA. Il n’a pas de bière à ouvrir, il n’a pas la notion de « suffisamment bon », et surtout, il n’a pas de capteur interne qui dit « arrête, c’est fini ». Sans ce capteur, il fait l’un des deux choix: s’arrêter trop tôt ou ne jamais s’arrêter.

Le problème du « prêt » sans définition

Quand un humain travaille sans critères d’acceptation clairs, deux scénarios classiques se produisent.

Le premier est le under-delivery. Le dev implémente le chemin tout simple, ignore les cas limites, oublie la validation d’erreur et marque le tout comme terminé. Techniquement, ça fonctionne. En pratique, ça casse dès la première utilisation réelle, un mardi.

Le second est le gold-plating. L’dev s’emballe. Le login qui était supposé être simple obtient une authentification biométrique. Le formulaire de contact reçoit un chatbot. La fonctionnalité devient un produit. Trois semaines plus tard, quelqu’un demande « pourquoi avons-nous passé autant de temps là-dedans ? » et la réponse est un silence gêné.

Les agents d’IA connaissent exactement les mêmes problèmes, mais amplifiés.

Le under-delivery d’un agent passe subrepticement inaperçu. Il livre quelque chose qui paraît complet à la surface. Le code compile, les noms des fonctions ont du sens, il y a même des commentaires. Mais si l’on regarde de près, on voit que la fonction de suppression ne vérifie pas les permissions, que l’endpoint de listing n’a pas de pagination, que la validation d’email accepte «abc@» comme valide. L’agent s’arrête parce qu’il croit avoir accompli la tâche, et techniquement il l’a faite — de manière très superficielle.

Le gold-plating d’un agent est spectaculaire. Vous vous souvenez de l’exemple de l’article sur les contraintes ? Vous demandez une page de profil et vous obtenez un système d’identité complet. C’est du gold-plating pur. L’agent ne sait pas qu’il devrait s’arrêter après le nom, l’email et la biographie. Sans signal explicite de « c’est tout ce dont j’ai besoin », il continue d’ajouter ce qu’il juge pertinent. Et un modèle entraîné sur des millions de dépôts considère énormément de choses comme pertinentes.

La définition de prêt qui fonctionne

Dans toute RFC bien rédigée, il existe une section qui résout ce problème dès la base: les critères d’acceptation.

Ne confondez pas avec les exigences. Les exigences décrivent ce qu’il faut construire. Les critères d’acceptation décrivent comment savoir que ce qui a été construit est bien fait. C’est la différence entre « implémente le login » et « l’utilisateur peut se connecter avec son email et son mot de passe, reçoit une erreur claire lorsque le mot de passe est incorrect, et la session expire après 60 jours ».

Pour les humains, les critères d’acceptation servent de contrat entre celui qui demande et celui qui réalise. Si tous les critères sont remplis, la fonctionnalité est prête. Pas de discussion, pas de subjectivité, pas de « mais j’estimais qu’il fallait ajouter ceci ».

Pour les agents d’IA, ils servent de signe d’arrêt. L’agent sait qu’il a terminé lorsqu’il peut vérifier chaque élément de la liste et confirmer que tout est satisfait. Sans cette liste, il s’appuie sur son intuition – et l’intuition d’un modèle de langage est « faire tout ce que j’ai vu faire dans des contextes similaires ».

La différence entre vague et précise

Prenons un exemple concret. Imaginez que vous demandez à un agent d’implémenter l’enregistrement d’utilisateurs d’une application.

Critère vague :

L’utilisateur peut s’inscrire et se connecter.

Que livre l’agent avec ça ? Cela dépendra de l’humeur du modèle ce jour-là. Peut-être un formulaire avec email et mot de passe. Peut-être un système avec OAuth, vérification d’email, récupération de mot de passe, authentification à deux facteurs, et connexion sociale. Les deux interprétations répondent à « l’utilisateur peut s’inscrire et se connecter ». Le critère est si vaste que n’importe quoi passe.

Critère précis : Critères d’acceptation :

• Utilisateur peut s’inscrire avec un email et un mot de passe
• Le mot de passe doit comporter au moins 8 caractères, avec une validation côté client et côté serveur
• L’email doit être unique dans le système (erreur claire s’il existe déjà)
• Après l’inscription, l’utilisateur reçoit un email de confirmation en moins de 30 secondes
• L’utilisateur ne peut se connecter qu’après avoir cliqué sur le lien de confirmation
• La connexion avec des identifiants invalides renvoie « Email ou mot de passe incorrect » (sans préciser lequel)
• La session persiste pendant 60 jours d’inactivité
• La déconnexion invalide immédiatement la session

Ainsi se révèlent les différences. Le premier critère laisse l’agent dans le noir. Le second allume tous les voyants. Chaque élément est vérifiable, spécifique et testable. L’agent sait exactement quand il a cessé d’implémenter trop tôt (si un élément manque) et quand il va trop loin (si quelque chose n’est pas demandé par un élément).

Le truc de la triple utilité

Voici la partie qui relie tout. Relisez ces critères précis. Maintenant, essayez de les voir sous trois angles différents.

Angle 1 — Définition de prêt dans le RFC. Chaque élément est un critère d’acceptation que l’équipe d’ingénierie utilise pour déterminer si la fonctionnalité est complète. Le chef de produit lit la liste, vérifie chaque point, signe. C’est standard.

Angle 2 — Spécification des tests. Chaque élément devient un cas de test. « Le mot de passe doit contenir au moins 8 caractères » se transforme en test "rejette les mots de passe avec moins de 8 caractères". « L’email doit être unique » devient test "renvoie une erreur lorsque l’email existe déjà". La liste de critères est, en pratique, votre suite de tests rédigée en langage naturel.

Angle 3 — Instructions du prompt. Chaque élément est une contrainte destinée à l’agent. « La session persiste pendant 60 jours » dit exactement ce qu’il faut configurer. « La connexion avec des identifiants invalides renvoie un message d’erreur générique » précise exactement le comportement d’erreur. L’agent lit cela et sait quoi faire, ce qu’il ne faut pas faire et quand s’arrêter.

Trois documents. Le même texte. Cela illustre l’efficacité de la communication.

J’appelle cela le modèle triple utilité : des critères d’acceptation rédigés avec une précision suffisante qui servent simultanément de définition de prêt, de spécification de test et d’instructions de prompt. On écrit une fois, on réutilise trois fois.

Comment écrire des critères qui fonctionnent dans les trois contextes

Après des mois à affiner cette approche, j’ai identifié quatre règles qui font la différence.

1. Chaque critère doit pouvoir être vérifié par une personne sans contexte. Si quelqu’un qui n’a jamais vu le projet peut lire le critère et dire « oui, cela fonctionne » ou « non, cela ne fonctionne pas », le critère est bon. « L’expérience utilisateur doit être bonne » échoue à ce test. « Le formulaire d’inscription se charge en moins de 2 secondes » passe.

2. Utilisez des chiffres lorsque c’est possible. « Le mot de passe doit être fort » est subjectif. « Le mot de passe doit comporter au moins 8 caractères, et comprendre une lettre majuscule et un chiffre » est objectif. Les agents répondent très bien aux chiffres car cela élimine l’ambiguïté. Les humains aussi, mais ils aiment râler davantage.

3. Incluez les scénarios d’erreur. La plupart des critères d’acceptation ne couvrent que le chemin heureux. Cela ouvre la porte au under-delivery, car l’agent (et le dev) se concentre sur ce qui passe et ignore ce qui échoue. « La connexion avec des identifiants invalides renvoie le code 401 avec un message d’erreur générique » est aussi important que « la connexion avec des identifiants valides crée une session ».

4. Séparez le comportement de l’implémentation. Le critère décrit ce que le système fait, pas comment il le fait. « La session persiste pendant 60 jours » est un comportement. « Utiliser JWT avec une expiration de 60 jours stockée dans un cookie HttpOnly » est une implémentation. Les critères d’acceptation décrivent le quoi. Les contraintes techniques (comme mentionné dans l’article précédent) décrivent le comment.

Critères en pratique : avant et après

Voyons cela dans un prompt réel. Imaginez que vous vouliez qu’un agent implémente un système de favoris (bookmarks).

Avant — sans critères d’acceptation :

Créez un système de bookmarks pour enregistrer des liens.

L’utilisateur doit pouvoir ajouter, modifier et supprimer des bookmarks.
Utiliser Phoenix LiveView.

Que va se passer ? L’agent va implémenter quelque chose. Peut-être que ça va fonctionner, peut-être pas. Peut-être y aura-t-il des validations, peut-être pas. Peut-être qu’il gérera des URLs en double, peut-être pas. Vous le découvrirez au moment des tests, et là commencera le cycle de corrections.

Après — avec critères d’acceptation :

Créer un système de bookmarks pour enregistrer des liens.

## Critères de acceptation

• L’utilisateur peut ajouter un bookmark avec URL et titre (les deux obligatoires)

• L’URL est validée au format (doit commencer par http:// ou https://)

• Les URLs en double pour le même utilisateur renvoient une erreur claire

• Le titre a une limite de 200 caractères (il est tronqué silencieusement si dépassé)

• L’utilisateur peut modifier le titre d’un bookmark existant

• L’utilisateur peut supprimer un bookmark avec confirmation (soft delete)

• La liste des bookmarks affiche le titre, l’URL et la date de création

• La liste est triée par date de création (les plus récents en premier)

• La liste a une pagination de 20 éléments par page

• L’utilisateur ne voit que ses propres bookmarks (jamais ceux des autres)

## Hors du périmètre

• Étiquettes ou catégories

• Recherche ou filtres

• Importation/exportation

• Aperçu des liens (unfurl)

• Partage

Avec cette deuxième version, l’agent dispose d’une check-list. Chaque élément est un comportement vérifiable. Lorsque tous sont implémentés, il s’arrête. S’il commence à ajouter des balises ou une recherche, il viole le périmètre. S’il n’implémente pas la pagination, il manque un critère. La frontière est nette des deux côtés.

Le signe d’arrêt dont les agents ont besoin

Voilà l’un des points les plus subtils de tout l’article. Les humains possèdent un mécanisme interne de « assez bon ». On sent quand quelque chose est prêt. Parfois on se trompe en trop, parfois en pas assez, mais il y a une sorte d intuition.

Les agents n’ont pas cela. Ce sont des optimiseurs sans frein. Si l’invite dit « créez un système de bookmarks », ils vont optimiser pour « le meilleur système de bookmarks que je peux générer » — ce qui comprend tout ce qu’ils savent sur les bookmarks. Et ils savent énormément de choses.

Les critères d’acceptation constituent le frein. Ils représentent le signe d’arrêt que l’agent n’a pas naturellement. Ils font la différence entre un agent qui produit exactement ce dont vous avez besoin et un agent qui produit tout ce qu’il sait faire.

Et ce qui est encore plus beau: le même frein marche aussi pour les humains. La même liste qui dit à l’agent « arrête-toi ici » dit au développeur « termine ici » et au QA « teste ceci ».