Critères d'acceptation
Les critères d'acceptation sont les conditions qu'un travail doit remplir pour que les utilisateurs et l'entreprise puissent le considérer comme terminé. On les écrit avant le développement, rattachés à une user story ou à une spec, et formulés pour que chacun puisse les vérifier par oui ou par non. Un format courant est Given / When / Then (étant donné, quand, alors) : une situation de départ, une action, un résultat observable.
Pourquoi c’est important pour un PM
C'est dans les critères d'acceptation que l'ambiguïté d'une spec se résout, avant de se transformer en reprise. Ils donnent aux développeurs et aux testeurs une définition partagée du terminé, et servent tout autant aux agents de code IA, qui suivent bien mieux des conditions explicites et vérifiables que des intentions. Pour le PM, les écrire est aussi un moyen de découvrir tôt les cas limites.
Exemple
Pour une story de réinitialisation du mot de passe : « Étant donné un utilisateur à l'e-mail vérifié, quand il demande une réinitialisation, alors il reçoit un lien valable 30 minutes. » Un autre critère couvre le cas limite : « Étant donné un e-mail inconnu, quand quelqu'un demande une réinitialisation, alors la page affiche le même message neutre. »
Points clés
- Chaque critère décrit un comportement observable, pas une implémentation.
- Couvrir le parcours principal, les cas limites (vide, trop long, sans permission) et les états d'erreur.
- Les attentes de rapidité ou d'accessibilité demandent des seuils mesurables.
- Des critères écrits en Given / When / Then se transposent directement en tests automatisés.
Erreurs fréquentes
- Écrire des critères invérifiables, comme « la page est intuitive ».
- Décrire la solution en détail et oublier le résultat attendu.
- Ajouter des critères une fois le développement lancé, sans discuter de l'impact sur le périmètre.
Pour aller plus loin dans Module
Les formations et les leçons qui traitent cette notion :