Critères d'acceptation : le cahier de recette par story
En agile, chaque user story embarque ses critères d'acceptation : les conditions précises qui disent qu'elle est terminée et conforme. Ce sont les cas de test du cahier de recette, mais rédigés au moment d'écrire la story, pas après. Le format Given/When/Then aide : étant donné un panier avec un article, quand je supprime cet article, alors le panier est vide et affiche un message. C'est vérifiable, sans ambiguïté, et ça sert à la fois au développeur, au testeur et au product owner qui valide.
La recette se fait à chaque sprint, pas à la fin
Le grand intérêt de l'agile, c'est de tuer l'effet tunnel. Plutôt qu'une phase de recette unique en fin de projet, où tous les bugs remontent en même temps trop tard, on valide les stories à la fin de chaque sprint, pendant la revue. Le product owner accepte ou refuse chaque story sur ses critères d'acceptation. Une story refusée retourne au backlog. Donc la qualité se contrôle par petits lots, en continu, et un défaut se découvre à un moment où il coûte encore peu à corriger.
La Definition of Done, le PV de recette distribué
La Definition of Done est la liste des conditions qu'une story doit remplir pour être considérée comme finie, au-delà de ses critères propres : code revu, tests passés, responsive vérifié, accessibilité contrôlée, documentation à jour. C'est l'équivalent du PV de recette, mais appliqué à chaque story plutôt qu'au projet entier. Une checklist transverse comme notre modèle de recette nourrit directement la Definition of Done : tu y pioches les contrôles qui doivent valoir pour toute story livrée.
Definition of Ready et Definition of Done, ne pas les confondre
Deux check-lists encadrent une story, à deux moments différents. La Definition of Ready dit quand une story est prête à entrer dans un sprint : besoin clair, critères d'acceptation écrits, maquette disponible, dépendances levées, story assez petite pour tenir dans le sprint. La Definition of Done dit quand elle est finie : développée, testée, revue, conforme à ses critères. La première protège l'entrée du sprint, la seconde protège sa sortie. Les confondre est l'erreur classique : on embarque une story floue parce que la Definition of Ready a été bâclée, puis on la déclare terminée sans l'avoir vraiment vérifiée parce que la Definition of Done l'est tout autant. Côté recette, une Definition of Ready sérieuse évite les allers-retours en plein sprint, et une Definition of Done tenue évite de livrer du presque-fini que le client renverra au sprint suivant.
Le suivi des anomalies reste le nerf de la guerre
Agile ou pas, un bug trouvé en revue de sprint doit devenir un ticket tracé, pas une remarque orale qui s'évapore. La différence, c'est le rythme : les anomalies entrent dans le backlog et sont priorisées au sprint suivant, ou corrigées dans le sprint si elles sont bloquantes. Un outil de feedback visuel qui capture le contexte technique reste précieux, surtout quand le product owner ou un client teste une démo : il clique sur le souci, le ticket part reproductible, et il atterrit là où l'équipe priorise déjà son travail.
Questions fréquentes
L'agile supprime-t-il vraiment le cahier de recette ?
Non, il le décompose. La rigueur reste la même (un résultat attendu vérifiable, un statut clair), mais au lieu d'un document figé validé en fin de projet, elle vit dans les critères d'acceptation de chaque story et dans la Definition of Done. Sur des projets avec une exigence contractuelle forte, on garde souvent en plus une recette globale finale, plus légère, pour acter la livraison.
Critères d'acceptation et Definition of Done, quelle différence ?
Les critères d'acceptation sont spécifiques à une story : ils décrivent ce que cette fonctionnalité précise doit faire. La Definition of Done est transverse : c'est le standard de qualité commun à toutes les stories (tests, revue de code, responsive, accessibilité). Une story est terminée quand elle remplit à la fois ses critères d'acceptation propres et la Definition of Done de l'équipe.
Qui valide la recette en agile ?
Le product owner porte l'acceptation des stories pendant la revue de sprint, au nom du métier ou du client. Sur des projets clients, le client lui-même teste souvent les démos de fin de sprint et signale ce qui cloche. L'équipe de développement reste responsable de la Definition of Done. C'est un contrôle partagé et continu, là où la recette en cycle classique concentre la validation sur une phase finale unique.
Qui rédige la Definition of Done ?
L'équipe de développement, collectivement, pas le product owner seul. C'est un standard que l'équipe se donne à elle-même et tient à jour : il reflète ce qu'elle estime nécessaire pour qu'une story soit vraiment livrable. Le scrum master facilite, l'équipe décide. Une Definition of Done imposée d'en haut et jamais relue se transforme en formalité ignorée ; une Definition of Done écrite et révisée par ceux qui font le travail reste vivante et respectée. Relis-la à chaque rétrospective : ce qui te coûtait du temps en recette mérite d'y entrer.