# Definition of Done (DoD) : définition et méthode > Qu'est-ce que la Definition of Done (DoD) en Scrum ? Définition, différence avec la Definition of Ready, et méthode pour la rédiger avec votre équipe. Source: https://asana.com/resources/definition-of-done ## Definition of Done (DoD) : définition, critères et méthode #### Résumé La Definition of Done (DoD) est l'ensemble des critères qu'un incrément de produit doit remplir pour qu'une équipe Scrum le considère comme réellement terminé, à ne pas confondre avec la Definition of Ready, qui s'applique en amont, ni avec les critères d'acceptation, propres à chaque user story. Cet article explique ce qu'est la DoD, pourquoi elle est indispensable en Scrum, comment la rédiger en 5 étapes, et comment la faire vivre au quotidien dans l'équipe, notamment via une checklist matérialisée sur chaque tâche.Lors d'une revue de sprint, un développeur présente un incrément qu'il juge terminé. Le testeur découvre que les tests unitaires n'ont jamais été écrits, et le Product Owner refuse la livraison. Ce désaccord sur ce que « terminé » veut dire est l'un des blocages les plus fréquents en Scrum, et il porte un nom précis : l'absence de Definition of Done partagée. Cet article explique ce qu'est la DoD, comment elle se distingue de la Definition of Ready et des critères d'acceptation, pourquoi elle est indispensable au bon fonctionnement d'une équipe Scrum, et comment la rédiger puis la faire vivre avec votre équipe. ## Qu'est-ce que la Definition of Done (DoD) ? La Definition of Done (DoD) est l'ensemble des critères qu'un incrément de produit doit remplir pour que l'équipe Scrum le considère comme réellement terminé : code testé, documentation à jour, revue de code effectuée. Définie collectivement par l'équipe de développement, elle sert de contrat partagé : un item du [product backlog](https://asana.com/fr/resources/product-backlog) n'est « fini » que s'il coche tous les critères de la DoD, jamais selon le seul jugement individuel d'un développeur. Cette définition provient directement du Scrum Guide, qui présente la DoD comme l'un des trois artefacts Scrum accompagné de son engagement : elle garantit que tous les incréments livrés, quel que soit le sprint ou l'équipe de développement concernée, répondent au même standard de qualité du produit. Cette logique de contrat de qualité partagé n'est pas propre à [Scrum](https://asana.com/fr/resources/what-is-scrum) : toute méthode agile qui organise le travail en itérations peut s'appuyer sur un principe similaire, adapté à son propre vocabulaire. Elle concerne aussi les parties prenantes au sens large : au-delà des équipes de développement, un Product Owner ou un client interne s'appuie sur la DoD pour évaluer objectivement ce qui lui est livré. ## Definition of Done, Definition of Ready et critères d'acceptation : ne pas confondre Ces trois notions interviennent à des moments différents du cycle de vie d'une user story, ce que résume le tableau ci-dessous. **Notion** **S'applique** **Rôle** Definition of Ready (DoR) Avant l'entrée en sprint Vérifie qu'une user story est assez claire et estimable pour être prise en charge Critères d'acceptation Sur une user story donnée Décrivent le comportement attendu de cette fonctionnalité précise Definition of Done (DoD) À la fin, sur tout incrément Vérifie qu'un incrément est réellement terminé, quel que soit l'item concerné La Definition of Ready (DoR) s'applique en amont, avant qu'un item entre dans un [sprint](https://help.asana.com/s/article/sprint-planning) : elle vérifie qu'une [user story](https://asana.com/fr/resources/user-stories)est suffisamment claire et estimable pour être prise en charge par l'équipe agile. Les critères d'acceptation, eux, sont spécifiques à chaque user story et décrivent le comportement attendu de cette fonctionnalité précise. La DoD, à l'inverse, s'applique uniformément à tous les incréments de l'équipe, quel que soit l'item concerné, du product backlog jusqu'à la revue de sprint. Confondre ces trois notions est une source fréquente de désaccords en sprint review : un item peut satisfaire ses critères d'acceptation (la fonctionnalité fait ce qui était demandé) sans pour autant respecter la DoD (les tests automatisés ne sont pas écrits, la documentation n'est pas à jour). Les deux évaluations sont complémentaires, jamais interchangeables. ## Pourquoi la Definition of Done est-elle indispensable en Scrum ? Sans DoD partagée, chaque membre de l'équipe se fait sa propre idée de ce que « terminé » signifie, ce qui génère des désaccords en sprint review et des retours en arrière coûteux. La DoD réduit ce risque, améliore la qualité du produit livré, et facilite les estimations futures. Une équipe qui sait précisément ce qu'implique « terminé » évalue mieux l'effort nécessaire pour les prochains items du product backlog. Elle limite aussi l'accumulation de dette technique. Un incrément livré sans tests automatisés ni revue de code, faute de DoD claire, ajoute un passif que l'équipe devra rembourser plus tard, souvent dans l'urgence. À l'inverse, une DoD respectée à chaque itération maintient un niveau de qualité constant, sprint après sprint, et facilite l'[amélioration continue](https://asana.com/fr/resources/continuous-improvement)portée par le coach agile ou le [Scrum Master](https://asana.com/fr/resources/scrum-master) lors des rétrospectives. Le coût d'une DoD absente se mesure aussi en confiance : un [Product Owner](https://asana.com/fr/resources/product-owner) qui découvre après plusieurs sprints que des incréments annoncés « terminés » nécessitent en réalité des retouches perd confiance dans les estimations de l'équipe, ce qui complique les négociations de périmètre lors des sprint planning suivants. De nombreuses équipes agiles ne formalisent leur DoD qu'après un premier incident de qualité en production, alors qu'elle aurait dû être définie dès la mise en place du framework Scrum. Une DoD posée dès le départ garantit que chaque livrable respecte le même standard, indépendamment du développeur qui l'a produit, et évite cette phase d'apprentissage coûteuse. ## Comment rédiger sa Definition of Done en 5 étapes Rédiger une DoD efficace suit une logique simple, résumée en 5 étapes. - **Réunir l'équipe** : rassembler l'équipe de développement et le Product Owner pour lister collectivement ce qu'implique « terminé » pour cette équipe et ce produit. - **Lister les critères concrets** : code revu, tests unitaires et tests automatisés passés, documentation mise à jour, standards de qualité respectés. - **Formuler des critères mesurables** : préférer des formulations vérifiables (« tests automatisés passés ») à des formulations vagues (« bien testé »). - **Valider collectivement la liste** : s'assurer que chaque membre de l'équipe Scrum, y compris le Scrum Master et le Product Owner, adhère à la DoD retenue. - **Intégrer la DoD aux outils quotidiens** : l'inscrire dans le référentiel de l'équipe et la rendre visible à chaque planification de sprint, puis la réviser régulièrement en rétrospective. Cette DoD s'applique à toutes les user stories traitées par l'équipe durant un sprint, qu'il s'agisse de fonctionnalités mineures ou de composants critiques du [produit minimum viable](https://asana.com/fr/resources/mvp-minimum-viable-product)(MVP) : le niveau d'exigence ne varie pas selon l'importance perçue de l'item. Ce travail se fait généralement lors du sprint planning ou d'un atelier dédié, jamais de façon isolée par une seule personne : une DoD imposée sans adhésion de l'équipe de développement a peu de chances d'être réellement appliquée au quotidien. #### Donnez à votre équipe agile un espace de travail commun Sprints, backlog, rétrospectives : centralisez le travail de votre équipe Scrum dans un outil pensé pour la gestion de projet agile. - [Gérer vos équipes Agile avec Asana](/uses/agile-management) ## Faire vivre sa Definition of Done au quotidien dans l'équipe Une DoD ne sert à rien si elle reste un document oublié dans un wiki d'équipe. Matérialiser ses critères sous forme de sous-tâches ou de checklist directement sur chaque tâche Asana, code revu, tests passés, documentation à jour, permet à l'équipe de vérifier visuellement, avant la revue de sprint, qu'un incrément coche bien tous les critères. Asana ne remplace ni le Scrum Master ni le rôle de l'équipe dans la définition de sa propre DoD : il sert à en garder une trace visible et partagée au fil du sprint. Cette checklist visible facilite aussi l'intégration des nouveaux développeurs, qui découvrent en un coup d'œil les standards de qualité attendus, sans avoir à interroger un collègue à chaque item du product backlog. Elle donne également au Scrum Master un indicateur simple pour objectiver, en rétrospective, les écarts récurrents entre ce qui est annoncé « terminé » et ce qui l'est réellement. Sur un produit porté par plusieurs équipes de développement en parallèle, une DoD commune, formalisée de la même façon dans l'outil de suivi de chacune, évite qu'une équipe livre des incréments à un niveau de qualité différent de celle qui dépend de son travail. Cette cohérence inter-équipes devient particulièrement critique à mesure que le nombre de sprints et d'itérations s'accumule sur un produit de longue durée. ## FAQ - Definition of Done Voici les réponses aux questions les plus fréquentes sur la Definition of Done. #### Quelle est la différence entre la Definition of Done et la Definition of Ready ? La Definition of Ready s'applique avant qu'un item entre en sprint (la user story est-elle assez claire pour être prise en charge ?), tandis que la Definition of Done s'applique à la fin, pour vérifier qu'un incrément est réellement terminé. #### La Definition of Done remplace-t-elle les critères d'acceptation d'une user story ? Non. Les critères d'acceptation sont spécifiques à chaque user story et décrivent le comportement attendu ; la DoD s'applique de façon uniforme à tous les incréments de l'équipe, quelle que soit la user story concernée. #### À quelle fréquence faut-il revoir sa Definition of Done ? Idéalement à chaque rétrospective, ou dès que l'équipe identifie un écart entre ce qui est livré et ce qui était attendu ; la DoD doit évoluer avec la maturité du projet, jamais rester figée. Une équipe junior commencera souvent avec une DoD courte, puis l'enrichira progressivement à mesure que ses standards de qualité montent en exigence. ## Definition of Done : un contrat d'équipe, pas une simple checklist figée La Definition of Done n'est pas une simple checklist figée mais un contrat d'équipe qui évolue avec la maturité du projet ; sans elle, « terminé » veut dire une chose différente pour chaque membre de l'équipe. La distinguer clairement de la Definition of Ready et des critères d'acceptation, la construire collectivement, puis la rendre visible au fil du sprint, transforme un désaccord récurrent en revue de sprint en un standard partagé et vérifiable. Ce standard partagé ne remplace ni le jugement de l'équipe ni le rôle du Product Owner : il leur donne un langage commun pour évaluer, sprint après sprint, ce qui mérite réellement d'être considéré comme terminé. #### Structurez vos sprints avec un modèle prêt à l'emploi Backlog, sprint planning, suivi des tâches : ce modèle Scrum aide votre équipe agile à démarrer rapidement sans repartir d'une page blanche. - [Créer mon modèle](/templates/scrum) - [Gestion du travail](/resources/category/work-management) - [KPI : définition, 25 exemples avec formules et méthode](/fr/resources/key-performance-indicator-kpi) Gestion du travail Planification de projet #### Auteur Les fichiers de suivi finissent souvent par accumuler des dizaines de lignes que plus personne ne consulte. Le problème vient rarement de l'outil. Il vient du fait que ces chiffre ... - [Gestion commerciale : définition, processus et bonnes pratiques](/fr/resources/sales-management) Gestion du travail #### Auteur Un devis part chez le client un vendredi, la commande est validée le lundi suivant, la livraison s'organise en deux temps parce que la moitié du stock est en rupture, et il faut e ... - [Vente B2B : définition, processus et bonnes pratiques](/fr/resources/b2b-sales) Gestion du travail #### Auteur Un compte grand groupe négocie une solution logicielle depuis six mois. Trois personnes côté client doivent valider l'achat, le service achats compare les offres, la DSI vérifie l ... - [Les 11 meilleurs logiciels Kanban: comparatif complet](/fr/resources/best-kanban-boards-software) Planification de projet Gestion du travail #### Rédactrice de contenu Multiplier les outils pour suivre le travail en cours, un tableur ici, une messagerie là, un fichier partagé ailleurs, dilue la visibilité de l'équipe et fait perdre du temps à ch ... - [Definition of Done (DoD) : définition, critères et méthode](/fr/resources/definition-of-done) Gestion du travail - [Auteur](/author/lydia-rajteric) Lors d'une revue de sprint, un développeur présente un incrément qu'il juge terminé. Le testeur découvre que les tests unitaires n'ont jamais été écrits, et le Product Owner refus ...