Dans un projet agile, une tâche n’est pas terminée parce qu’elle est simplement codée, testée à moitié ou validée oralement. La definition of done sert justement à fixer un niveau d’achèvement partagé: chacun sait quand un incrément peut vraiment être considéré comme fini, livré et exploitable. C’est un outil très concret pour éviter les malentendus, sécuriser la qualité et mieux piloter un projet IT.
Les points essentiels à garder avant de formaliser une checklist agile
- La DoD définit les critères communs qui permettent de dire qu’un travail est réellement terminé.
- Elle s’applique à l’incrément et protège à la fois la qualité, la traçabilité et la capacité de livraison.
- Une bonne DoD reste courte, testable et visible par toute l’équipe.
- Elle ne remplace pas les critères d’acceptation ni le niveau de préparation d’un élément du backlog.
- Sa valeur dépend moins de sa longueur que de son usage réel en sprint, en revue et en rétrospective.
Pourquoi la definition of done change le pilotage d’un projet agile
Je considère souvent la DoD comme un petit texte qui change beaucoup de choses. Le Scrum Guide 2020 la décrit comme une description formelle de l’état de l’incrément lorsqu’il satisfait les mesures de qualité requises pour le produit, et il précise qu’un travail qui ne la respecte pas ne peut pas être considéré comme faisant partie de l’incrément. Dit autrement, on ne parle pas seulement de “terminé”, on parle de terminé selon un standard partagé.
Dans la gestion de projet, cet effet est loin d’être théorique. Sans cadre commun, chaque acteur entend quelque chose de différent: le développeur pense “code mergé”, le testeur pense “scénarios validés”, le métier pense “résultat exploitable”, le sponsor pense “prêt à être diffusé”. La DoD réduit cet écart de perception et rend le pilotage plus fiable, surtout quand plusieurs équipes contribuent au même produit.
Je vois aussi un bénéfice très pragmatique: une bonne DoD améliore la prévisibilité. Si l’équipe sait qu’un élément n’est compté comme fini qu’après revue, tests, documentation et validation, elle calcule mieux sa vraie capacité de livraison. La suite logique, c’est de comprendre ce que cette checklist doit contenir pour rester utile sans devenir bureaucratique.
Ce que doit contenir une checklist vraiment utile
Une DoD n’est pas une wishlist. Si elle devient trop longue, trop vague ou trop ambitieuse, l’équipe finit par la contourner. À l’inverse, si elle est trop minimale, elle ne protège ni la qualité ni le projet. Je conseille donc de viser une checklist courte, observable et vérifiable.
- Validation fonctionnelle : le besoin métier est couvert et les critères attendus sont respectés.
- Revue de code : la modification a été relue par un pair, avec corrections si nécessaire.
- Tests passés : les tests unitaires, d’intégration ou de non-régression pertinents sont au vert.
- Documentation mise à jour : note de version, guide utilisateur ou documentation technique ont été ajustés.
- Déploiement maîtrisé : le chemin de mise en production est connu, avec retour arrière si besoin.
- Sécurité et conformité : les contrôles utiles au contexte ont été réalisés, surtout en environnement sensible.
- Observabilité : les journaux, alertes ou indicateurs nécessaires existent pour suivre l’effet du changement.
Le point clé, c’est que chaque critère doit pouvoir être vérifié sans débat interminable. Si un élément n’est ni testable ni observable, il n’a probablement pas sa place dans la DoD. Il faut alors le déplacer vers un autre document, ou le reformuler. C’est exactement ce travail de tri qui permet ensuite de construire une checklist vraiment opérationnelle.
Construire une DoD sans alourdir l’équipe
Je préfère une démarche simple plutôt qu’un grand atelier de plus qui produit un livrable oublié au bout de deux semaines. Le plus efficace, à mes yeux, consiste à partir des problèmes réels rencontrés dans le projet: défauts récurrents, retours en recette, incidents de mise en production, flous sur les validations. La DoD doit corriger ces angles morts, pas ajouter du papier pour le principe.
Voici l’enchaînement que j’utilise le plus souvent:
- Identifier les sources de non-qualité les plus fréquentes.
- Traduire chaque problème en critère concret et vérifiable.
- Écarter les critères trop généraux ou impossibles à contrôler.
- Définir un socle commun pour tous les éléments du projet.
- Ajouter, si besoin, des exigences supplémentaires selon le type de livraison.
- Faire valider la checklist par l’équipe, puis la revoir régulièrement.
La règle que je garde en tête est simple: si personne n’utilise la DoD, elle n’existe pas. Elle doit donc vivre dans l’outillage courant de l’équipe, sur le tableau de sprint, dans Jira, Azure DevOps ou tout autre support réellement consulté. La suite logique est de passer d’une méthode à un exemple concret.
Un exemple de checklist pour une équipe produit ou IT
Un bon exemple aide plus qu’une longue théorie. Celui-ci n’est pas universel, mais il couvre les bases que j’attends souvent d’une équipe produit ou d’une DSI sur un projet numérique.
| Dimension | Critère de fin | Pourquoi je le garde |
|---|---|---|
| Fonctionnel | Les critères d’acceptation sont validés. | On vérifie que la valeur métier attendue est bien livrée. |
| Technique | Le code a été revu et intégré sur la branche cible. | On limite les erreurs et les écarts de version. |
| Tests | Les tests automatisés pertinents sont passés. | On sécurise le comportement du produit avant livraison. |
| Documentation | La documentation utile a été mise à jour. | Le support, les utilisateurs et les équipes internes ne travaillent pas à l’aveugle. |
| Exploitation | Le déploiement, le monitoring et le retour arrière sont prêts. | On réduit le risque opérationnel lors de la mise en production. |
| Sécurité | Les contrôles de sécurité adaptés au sujet ont été réalisés. | On évite de livrer quelque chose de techniquement correct mais fragile. |
| Métier | La validation finale du métier ou du Product Owner est obtenue. | On ferme la boucle entre livraison technique et usage réel. |
Dans un projet moins critique, cette base peut suffire. Dans un contexte bancaire, santé, assurance ou secteur public, j’ajoute presque toujours des points de traçabilité, d’audit, de conformité ou de séparation des responsabilités. L’idée n’est pas de surcharger tout le monde, mais d’ajuster le niveau d’exigence au risque réel. Cette logique amène naturellement à distinguer la DoD des autres listes que l’on confond trop souvent avec elle.
Bien distinguer la DoD des critères d’acceptation et du DoR
Une grande partie des blocages que je rencontre vient d’une confusion entre trois notions proches, mais différentes. Si on les mélange, la gouvernance devient floue et les équipes discutent de la mauvaise chose au mauvais moment. Le tableau ci-dessous clarifie les rôles.
| Notion | Périmètre | Question posée | Exemple |
|---|---|---|---|
| DoD | Applicable à tous les éléments livrés | Peut-on considérer le travail comme terminé ? | Tests passés, revue faite, documentation à jour. |
| Critères d’acceptation | Propres à une user story ou à un besoin précis | La fonctionnalité répond-elle au besoin métier ? | Un filtre affiche bien les résultats attendus selon trois cas d’usage. |
| DoR | Avant le démarrage du travail | L’élément est-il prêt à être pris en charge ? | Le besoin est compris, testable et suffisamment découpé. |
Je résume souvent la différence ainsi: les critères d’acceptation définissent ce que l’on attend d’une fonctionnalité, la DoD définit ce que l’on exige pour la considérer finie, et le DoR dit si l’on peut la démarrer sans se mettre en difficulté. Un bug peut parfaitement répondre aux critères d’acceptation, mais échouer la DoD si la correction n’est ni testée ni documentée. Cette distinction évite beaucoup de débats stériles en réunion, à condition de ne pas la laisser s’éroder avec le temps.
Ce que je surveille pour qu’elle reste utile dans la durée
La DoD échoue rarement parce qu’elle est mal écrite au départ. Elle échoue surtout parce qu’elle n’est pas entretenue. Je vois revenir les mêmes erreurs: une checklist trop longue, des critères impossibles à vérifier, une version cachée dans un outil que personne ne consulte, ou une règle qui change sans explication. Dans ces cas-là, l’équipe ne la contourne pas par mauvaise volonté, mais parce qu’elle n’aide plus vraiment à travailler.
Il y a aussi un point de méthode important dans les organisations multi-équipes. Si plusieurs Scrum Teams travaillent sur un même produit, elles doivent partager au moins une base commune de DoD. Le Scrum Guide est très clair sur ce principe: un standard commun crée de la transparence et évite que chaque équipe livre avec son propre niveau d’exigence. Ensuite, chaque contexte peut ajouter des critères spécifiques, mais la base doit rester stable.
- Je la revis à chaque rétrospective si le projet a changé de rythme, de risque ou de périmètre.
- Je retire les critères décoratifs qui ne servent ni la qualité ni la décision.
- Je renforce la checklist après un incident, une fuite de qualité ou un retour utilisateur significatif.
- Je la garde visible pour qu’elle soit utilisée au quotidien, pas seulement citée en réunion.
Au fond, une bonne DoD sert à protéger la qualité sans ralentir inutilement le flux de livraison. Si je devais en retenir une seule discipline, ce serait celle-ci: la relire régulièrement, la simplifier dès qu’elle devient lourde, et l’aligner sur la réalité du projet plutôt que sur une idée abstraite du “travail bien fait”. C’est ce qui transforme une checklist en vrai outil de pilotage.
