Créer des Critères d'Acceptation Clairs

Les exigences vagues mènent aux malentendus, reprises et frustrations. Des critères d'acceptation clairs définissent exactement ce qui doit être vrai pour qu'une tâche soit complète. Les tâches GitScrum avec des critères bien définis sont complétées correctement du premier coup.

Pourquoi les Critères d'Acceptation Comptent

Formats de Critères d'Acceptation

Format Given-When-Then

GIVEN-WHEN-THEN (Syntaxe Gherkin)
═════════════════════════════════

FORMAT :
ÉTANT DONNÉ [précondition/contexte]
QUAND [action/déclencheur]
ALORS [résultat attendu]

EXEMPLE : Connexion Utilisateur
─────────────────────────────────────
ÉTANT DONNÉ un utilisateur inscrit sur la page login
QUAND il entre des identifiants valides
ALORS il est redirigé vers le dashboard
ET il voit un message de bienvenue avec son nom

ÉTANT DONNÉ un utilisateur sur la page login
QUAND il entre un mot de passe invalide
ALORS il voit un message d'erreur "Identifiants invalides"
ET le champ mot de passe est vidé
ET la tentative de connexion est loguée

ÉTANT DONNÉ un utilisateur déjà connecté
QUAND il navigue vers la page login
ALORS il est redirigé vers le dashboard
─────────────────────────────────────

Format Checklist

FORMAT CHECKLIST
════════════════

EXEMPLE : Fonctionnalité Recherche

Critères d'Acceptation :
- [ ] Utilisateur peut entrer termes recherche dans la barre
- [ ] Recherche s'exécute quand Entrée ou clic Rechercher
- [ ] Résultats s'affichent en moins de 2 secondes
- [ ] Résultats montrent titre, extrait et date pour chaque match
- [ ] Message "Aucun résultat" s'affiche si pas de correspondance
- [ ] Minimum 2 caractères requis pour rechercher
- [ ] Termes recherche surlignés dans résultats
- [ ] Utilisateur peut effacer recherche et retourner vue par défaut
- [ ] Recherche fonctionne sur mobile (responsive)
- [ ] Historique recherche n'est pas sauvé (confidentialité)

Format Basé sur des Règles

FORMAT RÈGLES
═════════════

EXEMPLE : Exigences Mot de Passe

Règles :
1. Mot de passe doit avoir 8-64 caractères
2. Doit contenir au moins une majuscule
3. Doit contenir au moins une minuscule
4. Doit contenir au moins un chiffre
5. Doit contenir au moins un caractère spécial (!@#$%^&*)
6. Ne peut pas contenir d'espaces
7. Ne peut pas correspondre aux 5 derniers mots de passe
8. Ne peut pas contenir le nom d'utilisateur
9. Indicateur de force se met à jour en temps réel
10. Messages d'erreur expliquent quelle règle échoue

Rédiger des Critères de Qualité

Bons vs Mauvais Exemples

QUALITÉ DES CRITÈRES D'ACCEPTATION
══════════════════════════════════

MAL (vague) :
✗ "Utilisateur peut rechercher"
✗ "Rendre rapide"
✗ "Gérer les erreurs correctement"
✗ "Doit fonctionner sur mobile"
✗ "Valider les entrées"

BIEN (spécifique et testable) :
✓ "Utilisateur peut rechercher en entrant texte et appuyant Entrée"
✓ "Résultats recherche s'affichent en moins de 2 secondes pour 10 000 enregistrements"
✓ "Email invalide affiche erreur : 'Veuillez entrer email valide'"
✓ "Formulaire pleinement fonctionnel à 320px de largeur viewport"
✓ "Champ email accepte uniquement format email valide (user@domain.ext)"

Zones de Couverture

QUOI COUVRIR DANS LES CRITÈRES D'ACCEPTATION
════════════════════════════════════════════

CAS NOMINAL :
├── Flux de succès normal
├── Comportement utilisateur attendu
└── Cas d'usage principal

CAS LIMITES :
├── États vides
├── Valeurs limites
├── Entrées inhabituelles mais valides
└── Actions concurrentes

SCÉNARIOS D'ERREUR :
├── Entrée invalide
├── Échecs réseau
├── Permission refusée
├── Gestion timeout
└── Erreurs système

NON-FONCTIONNEL :
├── Exigences performance
├── Accessibilité (niveau WCAG)
├── Support navigateur/appareil
├── Exigences sécurité
└── Besoins localisation

Template pour User Stories

USER STORY AVEC CRITÈRES D'ACCEPTATION
══════════════════════════════════════

STORY :
En tant que [type d'utilisateur]
Je veux [action/objectif]
Afin de [bénéfice/valeur]

CRITÈRES D'ACCEPTATION :

Cas Nominal :
- [ ] [Scénario succès principal 1]
- [ ] [Scénario succès principal 2]

Cas Limites :
- [ ] [Cas limite 1]
- [ ] [Cas limite 2]

Gestion Erreurs :
- [ ] [Scénario erreur 1]
- [ ] [Scénario erreur 2]

Non-Fonctionnel :
- [ ] [Exigence performance]
- [ ] [Exigence accessibilité]

Hors Scope :
- [Explicitement ce qui N'EST PAS inclus]
- [Pour éviter dérive de scope]

Exemples Concrets

Exemple Panier E-commerce

TÂCHE : Fonctionnalité Ajouter au Panier

CRITÈRES D'ACCEPTATION :

Ajout d'Articles :
- [ ] Utilisateur peut ajouter produit au panier depuis page produit
- [ ] Utilisateur peut spécifier quantité avant ajout (1-99)
- [ ] Icône panier montre compte mis à jour immédiatement
- [ ] Confirmation "Ajouté au panier" s'affiche 3 secondes
- [ ] Produit avec options sélectionnées (taille, couleur) est ajouté

Comportement Panier :
- [ ] Ajouter même produit augmente quantité (pas de doublon)
- [ ] Panier persiste entre sessions (utilisateurs connectés)
- [ ] Panier persiste 30 jours (invités via cookie)

Cas Limites :
- [ ] Ajouter plus que stock disponible affiche message stock
- [ ] Produits en rupture affichent "Me notifier" au lieu d'"Ajouter"
- [ ] Taille max panier est 50 articles uniques

Erreurs :
- [ ] Erreur réseau affiche "Impossible d'ajouter. Réessayez."
- [ ] Produit plus disponible affiche message approprié

Performance :
- [ ] Ajout au panier termine en <500ms
- [ ] Panier se met à jour sans rechargement page

HORS SCOPE :
- Fonctionnalité liste de souhaits (tâche séparée)
- Checkout invité (géré dans tâche checkout)

Exemple Endpoint API

TÂCHE : Créer Endpoint Inscription Utilisateur

CRITÈRES D'ACCEPTATION :

Requête :
- [ ] POST /api/v1/users/register
- [ ] Accepte body JSON : email, password, name
- [ ] Content-Type: application/json

Validation :
- [ ] Email : format valide, unique dans système
- [ ] Password : 8+ chars, majuscule, minuscule, chiffre
- [ ] Name : 2-100 caractères, alphanumérique + espaces

Succès (201) :
- [ ] Retourne ID utilisateur, email, nom
- [ ] Ne retourne PAS mot de passe
- [ ] Crée utilisateur en base avec mot de passe hashé
- [ ] Envoie email de vérification
- [ ] Logue événement inscription

Erreurs :
- [ ] 400 : Entrée invalide (avec erreurs par champ)
- [ ] 409 : Email existe déjà
- [ ] 422 : Validation échouée
- [ ] 429 : Rate limité (5 tentatives par IP par minute)

Sécurité :
- [ ] Mot de passe jamais logué
- [ ] Utilise bcrypt avec cost factor 12
- [ ] HTTPS uniquement
- [ ] CORS configuré pour origines autorisées

Meilleures Pratiques

Pour Rédiger les Critères

1. Être spécifique — Nombres, messages exacts, comportement précis
2. Être testable — Peut vérifier réussite/échec objectivement
3. Focus sur quoi, pas comment — Exigences, pas implémentation
4. Inclure cas négatifs — Ce qui ne doit PAS arriver
5. Définir "fait" — Pas d'ambiguïté sur complétion

Refinement Collaboratif

PROCESSUS DE REFINEMENT
═══════════════════════

1. BROUILLON : Product owner rédige critères initiaux
2. REVUE : Équipe revoit en session refinement
3. CLARIFIER : Développeurs posent questions clarification
4. ÉTENDRE : Ajouter cas limites et scénarios erreur
5. CONFIRMER : QA valide que critères sont testables
6. FINALISER : Tous s'accordent que critères sont complets

QUESTIONS À POSER :
├── "Que se passe-t-il si... ?"
├── "Y a-t-il un maximum/minimum ?"
├── "Comment gérer les erreurs ?"
├── "Qu'est-ce qui est explicitement hors scope ?"
└── "Comment QA vérifiera-t-il ceci ?"

Anti-Patterns

ERREURS CRITÈRES D'ACCEPTATION :
✗ Trop vague ("doit bien fonctionner")
✗ Trop détaillé (spécificités implémentation)
✗ Cas d'erreur manquants
✗ Pas de critères performance
✗ Non revu par développeurs
✗ Non revu par QA
✗ Changé en milieu de sprint sans discussion
✗ Pas de section hors scope

Solutions Connexes

• Créer une definition of done efficace
• Découper les epics en tâches gérables
• Améliorer la précision des estimations