Backlog & agile

Critères d'acceptation : le guide complet avec exemples

Maîtrisez les critères d'acceptation : formats Given/When/Then et checklist, exemples concrets par type de story, qui les écrit et erreurs à éviter.

Par l’équipe RoadmapHero · Mis à jour le 26 juin 2026 · 8 min de lecture

Les critères d'acceptation sont le moment où une user story cesse d'être un vœu pour devenir un contrat. Ils répondent à une seule question — « comment saurons-nous que c'est fini ? » — dans des termes que tout le monde lit pareil : produit, développeurs, QA, parties prenantes. Les équipes qui s'en passent ne gagnent pas de temps : elles déplacent le débat sur le « fini » du refinement (bon marché) vers la sprint review (hors de prix).

À quoi servent les critères d'acceptation

Une story comme « En tant qu'abonné, je veux mettre à jour mon moyen de paiement, afin de ne pas voir mon service interrompu » est volontairement courte. Les critères d'acceptation comblent l'écart entre l'intention et l'implémentation. Ils remplissent quatre rôles à la fois :

• Une définition partagée du « fini » — développeur, PM et testeur s'accordent sur la ligne d'arrivée avant le départ.

• Une clôture de périmètre — ce qui n'est pas dans les critères est explicitement hors scope : votre meilleure défense contre le scope creep silencieux.

• Un plan de tests — chaque critère se traduit presque directement en cas de test, manuel ou automatisé.

• Une aide à l'estimation — on estime bien mieux quand les cas limites sont écrits plutôt que découverts en plein sprint.

Distinguez-les de la Definition of Done : la DoD est globale (code relu, tests verts, déployé en staging) et s'applique à toutes les stories ; les critères d'acceptation sont locaux à une story. Une story part en production quand elle satisfait les deux.

Les deux formats qui fonctionnent

Format 1 : Given / When / Then

Emprunté au Behavior-Driven Development (BDD), ce format exprime chaque critère comme un scénario :

Étant donné [un contexte initial], quand [une action se produit], alors [un résultat observable].

Sa force, c'est la précision : il oblige à énoncer l'état de départ et le résultat attendu — exactement là où l'ambiguïté se cache. Utilisez-le pour les stories riches en comportements (paiements, permissions, workflows) et quand la QA veut automatiser les scénarios : des outils comme Cucumber exécutent cette syntaxe telle quelle.

Format 2 : la checklist de règles

Une liste vérifiable, sans cérémonie : « l'export contient les colonnes X, Y, Z », « le fichier se télécharge en moins de 5 secondes pour 10 000 lignes », « les dates utilisent le fuseau horaire du workspace ». Plus rapide à écrire et à lire, idéale pour les stories simples où des scénarios complets seraient du théâtre. Beaucoup d'équipes mixent : checklist par défaut, Given/When/Then pour les flux délicats.

Exemples concrets par type de story

Une story formulaire (la checklist suffit)

Story : « En tant que nouvel utilisateur, je veux créer un compte avec mon email, afin d'essayer le produit. »

• Le format de l'email est validé à la sortie du champ, avec un message d'erreur en ligne.

• Le mot de passe exige 12 caractères minimum ; un indicateur de robustesse se met à jour en direct.

• Un email d'activation part en moins d'une minute.

• Soumettre un email déjà enregistré affiche « Cet email est déjà utilisé » sans révéler de détails du compte.

Une story paiement (Given/When/Then se justifie)

• Étant donné un abonné avec une carte valide, quand il confirme le changement d'offre, alors le plan change immédiatement et une facture au prorata est émise.

• Étant donné une carte refusée par le prestataire, quand l'utilisateur confirme le paiement, alors aucun changement de plan n'a lieu et le motif exact du refus s'affiche.

• Étant donné un paiement en attente de validation 3-D Secure, quand l'utilisateur ferme la fenêtre, alors l'abonnement reste inchangé et la tentative est journalisée.

Une story reporting (format mixte)

• L'export CSV contient une ligne par ticket avec statut, assigné, story points et dates.

• Étant donné un filtre « dernier trimestre », quand l'utilisateur exporte, alors seuls les tickets correspondants figurent dans le fichier.

• Un export de 50 000 lignes aboutit en moins de 30 secondes, ou passe en asynchrone avec un lien par email.

Le point commun de ces exemples : chaque ligne est binaire. Un relecteur répond « conforme » ou « non conforme » sans interprétation. « Le formulaire doit être ergonomique » n'est pas un critère ; « toutes les erreurs sont annoncées aux lecteurs d'écran » en est un.

Qui les écrit, et quand

Le PM ou le product owner est responsable des critères d'acceptation, mais les rédiger en solo est un mode d'échec connu. L'approche éprouvée, ce sont les three amigos : le produit apporte l'intention, la technique apporte la faisabilité et les cas limites, la QA apporte le réflexe « qu'est-ce qui peut casser ». Trente minutes par lot de stories pendant le backlog refinement suffisent.

Le moment compte autant que l'auteur :

1. À la création de la story — un brouillon de 2-3 critères évidents capture l'intention à chaud.

2. Pendant le refinement — les three amigos durcissent la liste, ajoutent les cas limites, suppriment les doublons. C'est là que la valeur se crée.

3. Avant le sprint planning — les critères sont gelés. Une story sans critères finalisés n'est pas prête pour le sprint, point. C'est un maillon essentiel du cycle de vie d'une user story bien rédigée.

4. Pendant le sprint — les critères ne changent que par une conversation explicite avec le PM, jamais par réinterprétation silencieuse.

Critères d'acceptation, QA et tests

Des critères bien écrits réduisent à presque rien la distance entre spécification et vérification :

• La QA manuelle lit les critères comme sa feuille de route de test — plus besoin de deviner l'intention à partir de l'interface.

• Les tests automatisés se calquent un pour un sur les scénarios Given/When/Then ; les frameworks BDD les exécutent comme une documentation vivante.

• Le script de démo en sprint review suit la liste des critères, ce qui concentre le feedback des parties prenantes sur les résultats plutôt que sur les pixels.

Règle pratique : si la QA ouvre un bug qu'aucun critère ne couvre, demandez-vous si le critère manquait (corrigez l'habitude de refinement) ou si l'exigence est réellement nouvelle (faites-en une story). Cette boucle de feedback améliore durablement la rédaction des critères — et la fiabilité de votre sprint planning avec.

Les erreurs qui les rendent inutiles

• Les critères techniques — « utilise Redis pour le cache » décrit le comment, pas le quoi. Les choix d'implémentation vont dans la tâche, pas dans les critères, qui doivent rester observables de l'extérieur.

• Viser l'exhaustivité — impossible d'énumérer tous les états possibles ; essayer produit des listes de 25 lignes que personne ne lit. Couvrez le chemin nominal, les cas limites risqués et les modes d'échec ; pour le reste, faites confiance à la DoD et au jugement de l'équipe.

• Le vocabulaire subjectif — « rapide », « intuitif », « propre » sont des opinions. Remplacez par des chiffres ou des comportements observables.

• Le critère-maquette — figer couleurs de boutons et positions au pixel gèle le design trop tôt. Liez la maquette à la place.

• Le boilerplate copié-collé — « fonctionne sur tous les navigateurs » collé sur chaque story relève de la Definition of Done, pas des critères de la story.

• Les écrire après le développement — des critères rédigés pour coller à ce qui a été construit ne vérifient rien. Si ça arrive souvent, vos stories entrent en sprint sans être prêtes.

Les critères d'acceptation dans RoadmapHero

Les tickets RoadmapHero sont conçus pour ce workflow : rédigez les critères d'acceptation en checklist directement sur chaque story, à côté des story points, des dépendances, des champs personnalisés et du feedback client relié via Customer Voice — les critères se rattachent ainsi à ce que les utilisateurs ont réellement demandé. Le ticket health signale les stories entrées en sprint sans critères, et les intégrations Jira, Linear et GitHub transportent vos tickets vers le delivery sans ressaisie. À la livraison, la génération IA de release notes transforme le travail terminé en changelog lisible par vos clients. Essai gratuit, tarifs transparents en euros, sans engagement.