SAFe : Definition of Done et critères d’acceptation

En bref

Dans SAFe, la Definition of Done désigne les conditions partagées de qualité et d’achèvement à satisfaire pour considérer un travail comme terminé. Elle complète les critères d’acceptation propres à chaque story: répondre au besoin ne suffit pas si les exigences de qualité restent insatisfaites, selon Scaled Agile, articles Built-In Quality et Story.

La Definition of Done rend la qualité vérifiable

La Definition of Done (DoD), ou définition de terminé, regroupe les conditions explicites et partagées qui permettent de considérer un travail comme achevé. Elle rend les exigences de qualité vérifiables, au-delà du seul comportement fonctionnel attendu.

Dans l’article officiel Built-In Quality, Scaled Agile explique que la qualité se construit pendant la réalisation, plutôt que d’être contrôlée uniquement à la fin. Son article Story décrit les critères d’acceptation qui précisent le besoin spécifique à satisfaire. Ces deux repères sont complémentaires.

Repère	Definition of Done	Critères d’acceptation
Question posée	Le travail respecte-t-il les conditions communes d’achèvement et de qualité ?	Cette story satisfait-elle le besoin décrit ?
Portée	Conditions partagées pour les travaux concernés	Conditions propres à une story
Exemple illustratif	Tests requis réussis et intégration vérifiée	Le comportement attendu par l’utilisateur fonctionne dans le scénario décrit
Utilisation	Vérifier la qualité et l’achèvement	Vérifier la satisfaction du besoin spécifique

Ces exemples ne constituent pas une liste universelle imposée par SAFe.

Cas pédagogique fictif: vous préparez SAFe Agilist en France et examinez une story permettant à un client de modifier son adresse de livraison. Le comportement demandé fonctionne, mais un contrôle d’intégration exigé par la DoD reste en échec.

Les critères d’acceptation sont satisfaits; le travail n’est pourtant pas terminé, puisque les conditions communes d’achèvement ne sont pas toutes respectées. Pour votre préparation, retenez ce raisonnement: vérifier le besoin spécifique et les conditions communes de qualité. Ce cas illustre le principe et ne reproduit pas une question officielle d’examen.

Que vérifier avant de déclarer un travail terminé ?

Vous préparez SAFe Agilist et analysez une story dont le développement est achevé, mais dont les tests d’intégration restent à exécuter. Pour décider si elle est terminée, examinez les exigences applicables, et pas seulement l’état du code.

La Definition of Done (DoD) explicite les conditions d’achèvement et la qualité attendue. Les critères d’acceptation précisent, eux, le comportement attendu pour la story: leur satisfaction ne remplace pas celle de la DoD.

Clarifiez les conditions applicables. Sont-elles explicites, comprises par l’équipe et adaptées au travail concerné ? Une liste locale de contrôles n’est pas une règle officielle universelle de SAFe.
Distinguez story et intégration. Identifiez les vérifications propres à la story et celles qui dépendent de son intégration avec d’autres travaux. Un fonctionnement isolé ne démontre pas que l’ensemble fonctionne.
Exigez des preuves d’achèvement. « Développement fini » ne signifie pas « travail terminé ». Une validation fonctionnelle seule ne suffit pas si la DoD exige d’autres contrôles; un contrôle requis encore à réaliser empêche de déclarer le travail terminé.
Séparez achèvement et mise à disposition. Terminer un travail et décider de sa disponibilité en production sont des questions distinctes. Le déploiement immédiat n’est pas une condition universelle.

Pour le cadre de référence, consultez les articles officiels Built-In Quality et Story de Scaled Agile.

Pouvez-vous montrer que les critères d’acceptation et les exigences de la DoD sont satisfaits ? Pour situer cette notion dans une préparation plus large, la formation SAFe Agilist Elitek est proposée à 1 390 € TTC, examen inclus, sur 14 h (fiche formation Elitek, grille vérifiée le 28 octobre 2026).

FAQ

Une story acceptée peut-elle rester inachevée ?

Satisfaire les critères d’acceptation ne suffit pas si une condition de la Definition of Done reste insatisfaite. Vous devez vérifier le besoin spécifique et les exigences communes de qualité avant de considérer le travail comme terminé.

SAFe impose-t-il une liste unique de contrôles qualité ?

Ne présentez pas une liste d’exemples comme une Definition of Done universelle imposée par SAFe. Les contrôles retenus doivent rendre explicites les conditions de qualité et d’achèvement applicables au travail concerné.

Quel rapport entre Built-In Quality et Definition of Done ?

Built-In Quality exprime le principe d’intégrer la qualité à la réalisation du travail. La Definition of Done contribue à le rendre concret en explicitant les conditions à vérifier pour déclarer ce travail terminé.

Une story terminée doit-elle être immédiatement mise en production ?

La Definition of Done et la décision de mise à disposition en production ne se confondent pas. Vous devez vérifier les conditions d’achèvement applicables sans supposer que toute story terminée entraîne une publication immédiate.

Se former avec Elitek

Elitek, organisme certifié Qualiopi, propose une formation dédiée à ce sujet, éligible CPF et disponible en distanciel comme en présentiel. Découvrez la formation Elitek correspondante et son accompagnement vers la certification.