Definition of done :
le document d'une page qui supprime les allers-retours

Dans beaucoup d'équipes produit, le même dialogue revient à chaque fin de sprint. « C'est fini. » Puis, quelques questions plus tard : fini, sauf les tests de bout en bout. Fini, mais pas encore en production. Fini, mais le support ne sait pas que ça existe. Fini, mais personne n'a vérifié que ça marchait sur mobile. Le ticket repart, revient, repart encore, et la revue de sprint présente des choses que personne ne peut utiliser.

Le problème n'est pas la vitesse de l'équipe.

C'est que le mot « fini » n'a pas le même sens pour le développeur, pour le responsable produit, pour le commercial et pour le dirigeant. Chacun a raison dans sa définition, et c'est précisément pour ça que les allers-retours ne s'arrêtent jamais : on ne se dispute pas sur le travail, on se dispute sur un mot. Le remède tient sur une page, et c'est l'un des documents les plus rentables qu'une équipe produit puisse écrire. Voici comment je l'aborde, de ce qu'il contient à la façon de le faire vivre.

Qu'est-ce qu'une definition of done, concrètement ?

C'est une liste courte de conditions vérifiables que tout élément livré doit remplir avant d'être déclaré terminé, quel que soit l'élément. Le Scrum Guide (version de novembre 2020, consultée le 29 octobre 2026) la décrit comme la description formelle de l'état de l'incrément quand il atteint les mesures de qualité requises pour le produit, et lui donne une fonction précise : créer de la transparence, en donnant à tout le monde la même compréhension de ce qui a réellement été terminé.

Retenez surtout le mot « tout le monde ». Une definition of done n'est pas une checklist technique que l'équipe tient pour elle-même. C'est un contrat entre ceux qui livrent et ceux qui reçoivent, et c'est pour ça qu'elle concerne directement celui qui décide.

1. Ce que coûte un « fini » qui ne veut rien dire

Le coût d'une definition of done absente ne se voit jamais sur une ligne budgétaire. Il est dilué partout, ce qui le rend à la fois énorme et invisible.

• Les tickets rouverts. Un élément « fini » qui revient deux sprints plus tard n'a pas été livré deux fois : il a été livré zéro fois, et payé deux fois.
• Les revues de sprint décoratives. On montre une démonstration sur le poste d'un développeur, tout le monde applaudit, et rien n'est utilisable par un client. La revue devait servir à décider, elle sert à se rassurer.
• Les promesses commerciales sur du sable. Un commercial qui entend « c'est fini » l'annonce à un client. Quand le client ne le trouve pas, c'est la crédibilité de toute l'équipe qui paie, pas celle de la personne qui a dit « fini ».
• La roadmap qui glisse sans que personne ne sache pourquoi. Chaque reliquat de travail « presque fini » se reporte en silence sur le sprint suivant. Au bout d'un trimestre, l'écart entre ce qui était annoncé et ce qui est disponible est devenu un sujet de comité de direction.

Aucun de ces symptômes ne se règle en demandant aux gens de travailler plus soigneusement. Ils se règlent en écrivant, une fois, ce que « fini » veut dire, et en le rendant opposable.

2. Definition of done, critères d'acceptation, definition of ready : trois documents à ne pas confondre

La moitié des definitions of done ratées le sont parce qu'elles essaient de faire le travail d'un autre document. Il y en a trois, et ils ne répondent pas à la même question.

• La definition of done répond à « qu'est-ce qui est vrai de tout ce que nous livrons ? ». Elle est transversale : la même pour chaque élément, chaque sprint, sans exception négociée au cas par cas.
• Les critères d'acceptation répondent à « qu'est-ce que cet élément-ci doit faire ? ». Ils sont propres à une demande : le bon calcul de remise, le message d'erreur attendu, le cas limite à couvrir. Ils changent à chaque ticket.
• La definition of ready, quand une équipe en utilise une, répond à « qu'est-ce qui doit être clair avant de commencer ? ». Utile pour éviter de démarrer à l'aveugle, dangereuse quand elle devient une barrière que l'équipe oppose à toute demande imparfaite.

Le test pour savoir où va une ligne est simple : si elle s'applique à tous les éléments, elle va dans la definition of done ; si elle ne s'applique qu'à un seul, elle va dans ses critères d'acceptation. Une definition of done qui contient « le bouton exporte bien en CSV » est un ticket égaré, pas une règle.

3. Que doit contenir une definition of done d'une page ?

Quatre blocs, pas plus, chacun de trois ou quatre lignes vérifiables par oui ou par non. Voici le squelette que j'utilise, à adapter au produit plutôt qu'à recopier.

• Construit correctement. Le code est relu par une autre personne que son auteur, les tests automatisés passent, rien de connu n'est laissé cassé ailleurs dans le produit. C'est le bloc que l'équipe technique écrit presque seule, et celui qui existe déjà le plus souvent.
• Vérifié dans son comportement. Les critères d'acceptation de l'élément ont été vérifiés par quelqu'un d'autre que la personne qui l'a construit, sur un environnement proche de la production, sur les navigateurs et les appareils que vos clients utilisent vraiment.
• Mis à disposition. L'élément est en production, ou prêt à y aller sans intervention supplémentaire, éventuellement masqué derrière un interrupteur que le responsable produit peut actionner. Ce qui reste sur une branche ou sur un poste n'est pas fini, quelle que soit sa qualité.
• Connu de ceux qui en dépendent. Le support sait que ça existe et comment répondre aux premières questions, la documentation utilisateur est à jour si elle doit l'être, la note de version est écrite, et les données de suivi qui permettront de savoir si la fonctionnalité sert à quelque chose sont en place.

Le quatrième bloc est celui qui manque presque toujours, et c'est celui qui intéresse le plus un dirigeant. Une fonctionnalité que personne ne sait vendre, supporter ou mesurer a coûté tout son prix de développement pour une valeur proche de zéro. Ce n'est pas un détail de finition, c'est la moitié de la livraison.

4. Comment l'écrire en une séance, sans en faire un chantier

Une definition of done ne s'écrit pas à partir d'un modèle trouvé en ligne. Elle s'écrit à partir des derniers allers-retours réels de votre équipe, parce que ce sont eux qui disent ce que « fini » oublie chez vous.

1. Listez les derniers éléments rouverts ou contestés. Pas de jugement, juste la liste : ce qui est revenu, ce qui a surpris le support, ce qui a été annoncé trop tôt.
2. Pour chacun, nommez la condition qui aurait dû être vérifiée. « Testé sur mobile », « support prévenu », « déployé et pas seulement fusionné ». Chaque aller-retour produit au plus une ligne candidate.
3. Rangez les lignes dans les quatre blocs et supprimez les doublons. Ce qui ne rentre dans aucun bloc est presque toujours un critère d'acceptation égaré.
4. Reformulez chaque ligne pour qu'elle se vérifie par oui ou par non. « Code de qualité » ne se vérifie pas. « Relu par une autre personne que l'auteur » se vérifie.
5. Coupez jusqu'à tenir sur une page. La règle que j'applique : si une ligne ne peut pas être vérifiée en moins d'une minute au moment de clore un élément, elle sort, ou elle devient un contrôle automatique.

Cette séance a la même logique que le cadrage écrit avant de démarrer une mission : on ne cherche pas le document parfait, on cherche le document que tout le monde a lu, compris et accepté, et qui peut donc être cité quand le désaccord arrivera.

5. Qui écrit la definition of done, et qui la signe ?

L'équipe qui livre l'écrit, le responsable produit la contresigne, et la direction la protège. Les trois rôles sont nécessaires, et aucun ne peut remplacer les deux autres.

L'équipe l'écrit parce qu'elle est la seule à savoir ce que chaque ligne coûte à respecter. Une definition of done dictée d'en haut est soit irréaliste, et elle sera contournée en silence, soit si vague qu'elle ne contraint rien. Le Scrum Guide est explicite sur ce point : les développeurs sont tenus de s'y conformer, et si l'organisation n'impose pas de standard, c'est à l'équipe de créer celle qui convient au produit.

Le responsable produit la contresigne parce que le quatrième bloc, celui qui concerne le support, la documentation et la mesure, est le sien. C'est lui qui sait ce que « disponible pour un client » veut dire.

La direction, elle, n'écrit rien, mais elle a un rôle que personne d'autre ne peut tenir. Quand plusieurs équipes travaillent sur le même produit, le Scrum Guide prévoit qu'elles définissent ensemble et respectent la même definition of done ; et quand elle fait partie des standards de l'organisation, toutes les équipes doivent la suivre au minimum. Dit autrement : dès que vous avez deux équipes, la definition of done devient un sujet d'organisation, et c'est une décision de conduite du produit, pas une préférence d'équipe.

6. Que fait-on d'un élément qui n'est pas fini ?

Il n'est ni livré, ni présenté comme terminé, et il retourne dans le backlog : c'est la partie de la règle que tout le monde connaît et que presque personne n'applique. Le Scrum Guide le dit sans nuance : un élément qui ne respecte pas la definition of done ne peut pas être publié, ni même présenté en revue de sprint, et retourne dans le Product Backlog pour être reconsidéré.

Le « fini à 90 % » n'existe pas.

C'est là que la definition of done cesse d'être un document d'équipe et devient un test pour le management. La pression pour faire une exception arrive toujours d'en haut, et toujours avec une bonne raison : un client qui attend, une démonstration prévue, une échéance annoncée. Chaque exception accordée enseigne à toute l'équipe que la règle est négociable, et une règle négociable redevient un mot.

La sortie honnête n'est pas de livrer quand même. C'est de rendre visible ce qui manque et de décider en connaissance de cause : réduire le périmètre pour que la partie livrée soit réellement finie, décaler l'annonce, ou assumer explicitement un risque nommé, écrit et daté. C'est la même discipline que pour dire non à une demande de fonctionnalité : une décision écrite tient, une exception orale se répète.

7. La faire vivre sans la transformer en procédure

Une definition of done n'est pas gravée. Elle doit durcir quand le produit grandit, et elle peut s'alléger quand une ligne ne sert plus à rien. Trois règles suffisent à la garder utile.

• Une ligne s'ajoute après un incident réel, jamais par précaution. C'est ce qui l'empêche de gonfler. Une équipe qui commence à coder avec l'IA, par exemple, a de bonnes raisons de durcir sa definition of done sur la relecture et les tests de comportement, parce que le risque a changé.
• Une ligne qui n'a rien attrapé depuis longtemps se discute. Soit elle est devenue un automatisme et peut passer dans un contrôle automatique, soit elle ne sert plus. Dans les deux cas, elle libère de la place sur la page.
• Le document est daté et versionné. On sait quelle version s'appliquait à quel sprint, et une modification se décide en rétrospective, pas au détour d'un ticket litigieux.

Le signe qu'elle est morte est facile à repérer : plus personne ne la cite. Une definition of done vivante revient dans les conversations, « ça ne passe pas la DoD », « il manque le bloc support ». Une definition of done morte n'est plus mentionnée que lors de l'arrivée d'un nouveau, comme une curiosité historique.

Ce qu'il faut vraiment retenir

La definition of done n'est pas un document de développeurs. C'est la définition commune d'un mot que toute l'entreprise utilise, et sans laquelle chaque livraison se renégocie.

• Une page, quatre blocs. Construit correctement, vérifié dans son comportement, mis à disposition, connu de ceux qui en dépendent. Le dernier est celui qui manque le plus souvent.
• Ne la confondez pas avec les critères d'acceptation. Ce qui s'applique à tout va dans la definition of done, ce qui s'applique à un seul élément va dans son ticket.
• Écrivez-la à partir de vos allers-retours réels, avec des lignes vérifiables par oui ou par non, et coupez jusqu'à tenir sur une page.
• L'équipe l'écrit, le produit la contresigne, la direction la protège. Dès deux équipes sur un produit, c'est un sujet d'organisation.
• Pas d'exception. Un élément qui n'est pas fini retourne dans le backlog. Réduisez le périmètre plutôt que la règle.

Une équipe ne devient pas fiable en promettant plus prudemment. Elle devient fiable quand « fini » veut dire la même chose pour celui qui le dit et pour celui qui l'entend.

À lire aussi

• L'art de dire non à une demande de fonctionnalité, la même logique en amont : une décision écrite contre une exception négociée.
• Une équipe qui code avec l'IA : quels rituels Scrum ajuster, où la definition of done est le rituel qu'il faut durcir plutôt qu'alléger.

Une definition of done ne rend pas une équipe plus rapide. Elle rend ses livraisons croyables, et c'est la condition pour que le reste, la roadmap, la priorisation, les promesses faites aux clients, cesse de se renégocier à chaque sprint.