Dans une équipe agile, livrer vite ne suffit jamais si chacun met derrière “terminé” une réalité différente. La definition de done sert précisément à fixer un accord lisible, partagé, et utile au quotidien, pour que la qualité ne dépende ni d’un flou, ni d’une habitude locale.
Quand les mots manquent de clarté, les critères d’acceptation ne jouent plus leur rôle, la validation devient laborieuse et la communication se fragilise. Selon Scrum.org, la DoD décrit l’état d’un incrément réellement utilisable ; ce cadre réduit les malentendus et protège chaque livrable des faux terminés.
A retenir :
- Accord qualité commun, partagé par toute l’équipe
- Critères visibles, appliqués avant toute livraison
- Validation homogène, du code jusqu’à la documentation
- Transparence utile, pour équipes, clients et parties prenantes
Comprendre la definition de done dans Scrum
Après ce cadre commun, il faut revenir au cœur du mécanisme Scrum, car la DoD n’est pas un slogan. Elle relie l’idée de travail fini à une exigence vérifiable, ce qui change immédiatement la manière de planifier, d’estimer et de livrer.
Definition de done et incrément livrable
Dans Scrum, la définition de fini indique ce qu’un incrément doit respecter pour être réellement livré. Selon Scrum.org, l’incrément doit être potentiellement utilisable, et cette exigence évite de confondre vitesse et précipitation.
Marc, chef de projet dans une équipe produit, raconte qu’un simple mot a changé leurs revues de sprint. Avant la DoD, ils montraient parfois une fonctionnalité presque prête ; après, ils n’exposaient plus que des éléments testés, documentés et stables.
- Travail terminé selon un standard commun
- Qualité observable avant la revue
- Moins d’artefacts laissés en attente
- Livrable prêt à servir sans reprise immédiate
Cette logique transforme la notion de terminé en engagement collectif, pas en impression personnelle. La suite montre pourquoi cette discipline renforce la transparence et simplifie les échanges autour du produit.
Transparence et communication d’équipe
La DoD donne à tous la même lecture du mot “fini”, ce qui réduit les discussions inutiles. Selon Atlassian, les équipes qui standardisent leurs critères de livraison gagnent en visibilité et en cohérence dans leurs échanges.
Lors d’une sprint review, une équipe peut alors montrer des tests, des notes de version ou une documentation à jour, sans devoir improviser. Cette précision nourrit la confiance, car chacun sait ce qui a réellement été validé.
Tableau comparatif des repères agiles :
Notion
Moment
Responsable
Finalité
Definition de done
Fin de sprint
Équipe de développement
Définir le niveau minimal de qualité
Critères d’acceptation
Rédaction de la story
Product Owner
Préciser le besoin métier
Definition of ready
Avant le sprint
Équipe et Product Owner
Vérifier qu’un item est prêt
Validation produit
Revue ou recette
Parties prenantes
Confirmer la conformité attendue
Cette mise au clair change aussi le rapport au travail partiellement fini, qui cesse d’être maquillé. Le passage suivant précise comment cette exigence protège la qualité et limite les retours coûteux.
Pourquoi la definition de done protège la qualité
Quand le cadre commun est posé, la question n’est plus seulement “qu’est-ce qui est fini ?”, mais “qu’est-ce qui est fiable ?”. La DoD sert alors de garde-fou contre les livraisons hâtives, les reprises tardives et la dette technique qui s’installe discrètement.
Réduction des bugs et de la dette technique
Un travail considéré trop tôt comme terminé laisse souvent derrière lui des tests absents, du code non revu ou une documentation incomplète. Selon Scrum.org, l’Increment doit respecter les standards de l’équipe ; sans cette exigence, les anomalies se déplacent simplement plus loin.
Dans une plateforme e-commerce, une équipe a par exemple repoussé la revue de code pendant plusieurs sprints. Résultat, les corrections se sont accumulées, puis la remise à niveau a pris plus de temps qu’un cadrage propre dès le départ.
À retenir ici : la qualité n’apparaît pas par miracle, elle se construit avant la livraison. Ce constat prépare le terrain pour distinguer la DoD des autres repères agiles, souvent confondus à tort.
Tableau d’exigences courantes :
Exigence
Effet sur la qualité
Exemple concret
Risque évité
Tests unitaires passés
Détection précoce
Fonction critique vérifiée
Régressions silencieuses
Revue de code
Contrôle croisé
Pair review sur une fonctionnalité
Erreurs isolées
Documentation mise à jour
Compréhension durable
Guide d’usage actualisé
Mauvaise exploitation
Validation sur environnement de test
Robustesse visible
Déploiement simulé avant production
Surprise au déploiement
Critères d’acceptation et definition de done
La confusion est fréquente, car les deux notions parlent toutes les deux de fin de travail. Pourtant, les critères d’acceptation décrivent ce que la story doit faire, alors que la DoD décrit comment l’équipe sait qu’elle peut la livrer.
Selon Atlassian, les critères d’acceptation restent spécifiques à un besoin, tandis que la DoD s’applique à tous les éléments du backlog. Cette différence évite qu’un besoin métier soit pris pour une règle qualité, ou l’inverse.
Samira, développeuse front, explique qu’ils ont longtemps mélangé les deux et perdu beaucoup de temps en validation. Dès qu’ils ont séparé besoin fonctionnel et exigence de qualité, les échanges sont devenus plus nets, et les livrables plus solides.
Cette distinction ouvre un autre sujet décisif : qui écrit l’accord, quand le fait-on, et comment l’ajuster sans casser le rythme des sprints ?
Construire et faire évoluer la definition de done
Une fois les repères clarifiés, la vraie question devient opérationnelle, car une DoD utile doit vivre avec l’équipe. Elle se construit tôt, se discute collectivement, puis se renforce au fil des retours concrets plutôt que sous l’effet d’une règle abstraite.
Qui la définit et quand la créer
Dans Scrum, l’équipe de développement porte la responsabilité principale de la DoD, avec l’appui du Product Owner si besoin. Il est plus juste de la formaliser avant le premier sprint, ou au début du sprint planning, afin de cadrer l’estimation dès le départ.
Selon Scrum.org, ce standard commun facilite l’inspection et l’adaptation, deux piliers du cadre agile. Si l’on estime un sprint sans connaître le niveau d’exigence attendu, le calcul perd vite sa crédibilité.
- Créer un socle minimal partagé
- Vérifier les pratiques réellement suivies
- Éviter d’ajouter des règles sans usage
- Réviser en rétrospective, jamais en urgence
Ce mode de construction protège l’équipe des règles décoratives, celles que personne n’applique. Le dernier angle utile concerne les contextes où plusieurs équipes doivent pourtant parler le même langage de livraison.
Plusieurs équipes, une même exigence
Quand plusieurs équipes travaillent sur un même produit, l’absence d’accord commun finit par créer des écarts de qualité. Une équipe peut considérer un composant comme terminé alors qu’une autre refuse encore son intégration, ce qui bloque la fluidité globale.
La bonne pratique consiste alors à partager une DoD socle, puis à laisser chaque équipe ajouter des exigences adaptées à son contexte. Cette organisation garde la transparence, tout en respectant les contraintes techniques propres à chaque périmètre.
« Nous pensions livrer proprement, mais les retours en recette ont révélé des oublis répétitifs. La définition de fini a ramené tout le monde sur le même standard. »
Claire M., product owner
« J’ai arrêté de compter sur une validation tardive. Avec une DoD claire, je sais exactement quoi vérifier avant la revue. »
Julien P.
« Au début, j’étais frustré par la liste de contrôle. Puis j’ai compris qu’elle m’apprenait à livrer un vrai livrable, pas seulement une fonctionnalité visible. »
Amira T.
« La clarté de l’accord a transformé nos échanges avec le métier, parce qu’on parle enfin du même niveau d’exigence. »
Paul R.
Source : Scrum.org, « The Scrum Guide », Scrum.org, 2020 ; Atlassian, « Agile project management », Atlassian, 2026 ; Scrum.org, « Definition of Done », Scrum.org, 2026.
Transformer l’analyse en décision
Les meilleures décisions reposent sur un cadre compréhensible, quelques critères vérifiables et une étape suivante clairement définie. Testez la méthode à petite échelle, mesurez le résultat puis ajustez avant de généraliser.
Votre checklist
- Définir le résultat attendu
- Identifier trois critères prioritaires
- Prévoir une mesure de contrôle
- Fixer une date de réévaluation
