Articles

Comment écrire des critères d'acceptation qui évitent vraiment le retravail

Équipe agile collaborant autour d'une table avec des post-its et un ordinateur portable, discutant des exigences d'une user story lors d'une session de backlog refinement Les problèmes liés aux exigences causent près de la moitié de tous les défauts logiciels. La plupart remontent au même problème fondamental : l'équipe a construit ce qu'elle pensait avoir compris, et non ce qui était réellement nécessaire. Les critères d'acceptation sont la solution. Ils transforment une user story vague en un contrat testable entre le product owner et l'équipe de développement. Bien rédigés, ils éliminent les conversations « mais je pensais que ça devait... » qui sabotent les sprint reviews. Ce guide couvre les deux principaux formats, des exemples concrets que vous pouvez adapter, et les erreurs qui piègent même les équipes expérimentées.

Ce que sont (et ne sont pas) les critères d'acceptation

Les critères d'acceptation sont les conditions qu'une user story doit satisfaire avant d'être considérée comme terminée. Ils répondent à une seule question : « Comment saurons-nous que cela fonctionne ? » Ils ne sont pas la même chose qu'une definition of done. La DoD est un standard de qualité universel qui s'applique à tout le travail (code revu, tests écrits, déployé en staging). Les critères d'acceptation sont spécifiques à une seule story.

	Critères d'acceptation	Definition of Done
Portée	Une user story	Tous les éléments de travail
Focus	Ce que la fonctionnalité fait pour les utilisateurs	Comment elle est construite
Qui l'écrit	Product Owner + équipe	Toute l'équipe Scrum
Exemple	"L'utilisateur peut filtrer par plage de dates"	"Code revu par au moins 1 dev"

Les deux doivent être satisfaits avant qu'une story soit terminée. Si vous êtes encore en train de construire votre DoD, notre Générateur de Definition of Done peut vous aider à démarrer.

Les deux principaux formats

Format liste de vérification (basé sur des règles)

Une simple liste de conditions réussite/échec. Idéal pour les fonctionnalités simples où le comportement attendu est clair.

Fonctionnalité de réinitialisation de mot de passe :
- Le lien "Mot de passe oublié" apparaît sur la page de connexion
- Cliquer dessus demande une adresse email
- Un email valide reçoit un lien de réinitialisation dans les 60 secondes
- Le lien de réinitialisation expire après 24 heures
- Le nouveau mot de passe doit respecter les exigences de mot de passe existantes
- Après réinitialisation, l'utilisateur est redirigé vers la connexion avec un message de succès
- Un email invalide affiche : "Si cet email existe, un lien de réinitialisation a été envoyé"

Quand l'utiliser : Fonctionnalités simples, exigences d'interface utilisateur, règles métier, logique de validation. La plupart de vos stories utiliseront ce format.

Format Given/When/Then (Gherkin)

Un format de scénario structuré issu du Behavior-Driven Development. Chaque scénario décrit une précondition, une action et un résultat attendu.

Scénario : Application d'un code de réduction valide
Given l'utilisateur a des articles dans son panier totalisant 100€
And un code de réduction valide de 20% "SAVE20" existe
When l'utilisateur entre "SAVE20" dans le champ de réduction
And clique sur "Appliquer"
Then le total du panier se met à jour à 80€
And un message "Réduction appliquée" apparaît

Scénario : Application d'un code de réduction expiré
Given le code de réduction "OLD10" a expiré hier
When l'utilisateur entre "OLD10" et clique sur "Appliquer"
Then le total du panier reste inchangé
And un message d'erreur "Ce code a expiré" apparaît

Quand l'utiliser : Workflows complexes avec plusieurs chemins, ou fonctionnalités que vous prévoyez d'automatiser avec des outils BDD comme Cucumber ou SpecFlow. Deux documents côte à côte montrant le format liste de vérification et le format Given/When/Then pour les critères d'acceptation, avec des annotations colorées soulignant les différences

Quel format choisir ?

La plupart des équipes adoptent une approche hybride : liste de vérification pour les stories simples, Given/When/Then pour tout ce qui comporte des embranchements complexes ou plusieurs parcours utilisateur. Ne vous prenez pas trop la tête. Choisissez le format qui communique le mieux les exigences pour cette story spécifique.

Cinq règles pour écrire de bons critères d'acceptation

1. Définir le quoi, pas le comment

Mauvais : "Utiliser un composant modal avec une animation de fondu de 400ms" Bon : "Une boîte de dialogue de confirmation apparaît avant que l'élément soit supprimé" Les critères décrivent les résultats. L'implémentation est le travail du développeur.

2. Rendre chaque critère testable

Si vous ne pouvez pas répondre "oui" ou "non" pour savoir si un critère est satisfait, il est trop vague. Mauvais : "La page doit charger rapidement" Bon : "Les résultats de recherche se chargent en moins de 2 secondes pour jusqu'à 500 résultats"

3. Couvrir les cas d'erreur

Pour chaque chemin heureux, écrivez au moins un scénario d'erreur. Que se passe-t-il avec une entrée invalide ? Une connexion perdue ? Des permissions manquantes ?

4. Garder les critères indépendants

Chaque critère devrait être vérifiable de manière autonome. Si le critère n°4 n'a de sens qu'après avoir lu les critères n°1 à n°3, vous avez écrit une spec, pas des critères d'acceptation.

5. Les écrire avant le sprint planning

Les critères d'acceptation écrits pendant le développement sont des descriptions, pas des exigences. Écrivez-les pendant le backlog refinement afin que l'équipe puisse estimer avec précision pendant le planning poker.

Exemples concrets

Filtre de recherche e-commerce

User story : "En tant qu'acheteur, je veux filtrer les produits par plusieurs catégories afin de restreindre les résultats à ce que je recherche."

• Les filtres affichent toutes les catégories de produits disponibles
• Les utilisateurs peuvent sélectionner plusieurs catégories à la fois
• Les résultats se mettent à jour en temps réel sans rafraîchissement de page
• Les filtres appliqués s'affichent sous forme de badges supprimables
• Le bouton "Tout effacer" supprime tous les filtres actifs
• Le compteur de résultats se met à jour pour refléter les filtres actifs (ex : "Affichage de 47 résultats")
• Aucun résultat correspondant affiche : "Aucun produit ne correspond à vos filtres. Essayez d'élargir votre sélection."
• L'état des filtres persiste lors de la navigation retour depuis une page de détail produit

Flux d'invitation d'équipe

User story : "En tant que responsable d'équipe, je veux inviter des membres par email afin que nous puissions commencer à collaborer."

Scénario : Invitation réussie
Given je suis sur la page des paramètres d'équipe
When je saisis "alex@company.com" dans le champ d'invitation
And je clique sur "Envoyer l'invitation"
Then un email d'invitation est envoyé dans les 60 secondes
And l'email apparaît dans ma liste "Invitations en attente"
And un message de succès confirme que l'invitation a été envoyée

Scénario : Invitation en double
Given j'ai déjà invité "alex@company.com"
When je saisis le même email et clique sur "Envoyer l'invitation"
Then un avertissement apparaît : "Invitation déjà envoyée à cet email"
And je peux choisir de renvoyer ou d'annuler

Scénario : Format d'email invalide
Given je suis sur la page des paramètres d'équipe
When je saisis "pas-un-email" et clique sur "Envoyer l'invitation"
Then une erreur inline apparaît : "Saisissez une adresse email valide"
And aucune invitation n'est envoyée

Préférences de notifications

User story : "En tant qu'utilisateur, je veux contrôler quelles notifications je reçois afin de ne pas être submergé par les alertes."

• La page de paramètres affiche un bouton à bascule pour chaque catégorie de notification
• Les modifications sont enregistrées automatiquement (pas de bouton "Enregistrer" séparé)
• Désactiver une catégorie arrête toutes les notifications de ce type dans les 5 minutes
• Au moins un canal de notification doit rester actif (empêcher la désinscription accidentelle de tout)
• "Réinitialiser aux valeurs par défaut" restaure les paramètres de notification d'origine
• Les modifications s'appliquent sur tous les appareils

Un développeur examinant une carte de user story avec des critères d'acceptation clairement rédigés, cochant les éléments un par un

Erreurs courantes

Être trop vague. "Le système doit être convivial" n'est pas testable. Remplacez le langage subjectif par des conditions mesurables. Prescrire l'implémentation. "Utiliser Redux pour la gestion d'état" appartient à un tech spike, pas aux critères d'acceptation. Décrivez ce que l'utilisateur expérimente, pas comment le code fonctionne. Écrire seulement le chemin heureux. Si vos critères ne couvrent que le scénario idéal, votre équipe découvrira les cas limites en plein sprint et soit prendra des raccourcis, soit fera exploser l'estimation. Écrire les critères trop tard. Les critères écrits pendant le développement sont des justifications rétroactives, pas des exigences. Définissez-les pendant le refinement, affinez-les pendant le sprint planning. Rendre les critères trop granulaires. Si vos critères ressemblent à un script de test avec 30 étapes, vous êtes allé trop loin. Visez 5 à 10 critères par story. Si vous en avez besoin de plus, la story est probablement trop grande et devrait être divisée en stories plus petites.

Une vérification rapide

Avant de valider une story pour un sprint, passez par cette liste : Si l'un de ces points échoue, la story nécessite un autre tour de backlog refinement avant d'être prête pour le sprint.

Écrire des critères d'acceptation plus rapidement

L'approche des "Trois Amigos" fonctionne : réunissez le product owner, un développeur et un testeur dans la même pièce pour chaque story. Le PO explique l'intention, le développeur repère les cas limites techniques, et le testeur creuse avec des questions "et si... ?". Si vous rédigez des user stories et avez besoin d'un point de départ, notre Générateur de critères d'acceptation peut rédiger des critères initiaux à partir d'une description de story. Il vous donne les premiers 80% rapidement afin que votre équipe puisse consacrer le temps de refinement aux cas limites délicats au lieu de fixer une page blanche.