Definition of Done et Ready en pratique Agile

Combien de fois avez-vous entendu un développeur déclarer une User Story terminée, pour découvrir deux sprints plus tard qu’elle n’était ni testée, ni documentée, ni validée par le Product Owner ? Selon une étude du Project Management Institute, 37 % des projets IT échouent à cause d’objectifs mal définis dès le départ. Un chiffre qui interpelle.

Deux outils Agile permettent de s’attaquer directement à ce problème : la Definition of Done (DoD) et la Definition of Ready (DoR). Mal comprises, elles restent des formalités administratives. Bien appliquées, elles transforment radicalement la fluidité de vos sprints et la qualité de vos livraisons.

Dans cet article, nous allons vous expliquer ce que ces concepts signifient réellement, comment les construire avec votre équipe, quelles erreurs éviter et comment les faire vivre dans la durée. Un guide pensé pour les managers IT, Product Owners, Scrum Masters et décideurs tech qui veulent des résultats concrets.

Definition of Done et Definition of Ready : deux concepts à ne pas confondre

La confusion entre ces deux notions est extrêmement fréquente, même dans des équipes qui pratiquent Scrum depuis plusieurs années. Pourtant, elles répondent à des questions radicalement différentes.

La Definition of Ready : est-ce qu’on peut commencer ?

La Definition of Ready (DoR) est une liste de critères qu’une User Story doit respecter avant d’entrer dans un sprint. Elle répond à la question : sommes-nous suffisamment prêts pour travailler sur cet élément ?

Concrètement, une User Story est considérée comme ‘Ready’ lorsqu’elle remplit des conditions précises. Voici un exemple de DoR utilisé par une équipe produit dans une scale-up française :

• La User Story est rédigée au format standard (En tant que… je veux… afin de…)
• Les critères d’acceptation sont définis et compris par tous
• Les dépendances techniques sont identifiées et levées
• La Story est estimée par l’équipe de développement
• Les maquettes ou wireframes associés sont disponibles

Sans DoR solide, les développeurs passent un temps précieux à clarifier des besoins flous en plein sprint, ce qui fragmente leur concentration et rallonge les délais.

La Definition of Done : est-ce qu’on peut livrer ?

La Definition of Done (DoD) s’applique, elle, à la fin du travail. Elle garantit qu’un incrément de produit est réellement terminé, au sens où il respecte un niveau de qualité partagé par toute l’équipe.

La DoD évite le piège du ‘c’est développé mais pas vraiment fini’. Elle s’applique à chaque User Story, voire à chaque sprint ou chaque release selon le niveau de maturité de l’équipe.

Exemple de DoD pour une équipe web en contexte de développement continu :

• Le code est revu par au moins un pair (code review)
• Les tests unitaires couvrent 80 % du nouveau code
• Les tests d’intégration sont passés avec succès
• La documentation technique est mise à jour
• Le Product Owner a validé la fonctionnalité en recette
• Le déploiement en environnement de staging est effectif

En résumé : la DoR protège l’entrée dans le sprint, la DoD protège la sortie. L’une sans l’autre crée des failles de qualité.

Comment construire une DoD et une DoR efficaces avec votre équipe

Le piège classique consiste à copier-coller une DoD ou une DoR trouvée sur internet et à l’imposer à l’équipe. Résultat : personne ne s’y identifie, personne ne l’applique. La co-construction est indispensable.

Partir du terrain, pas d’un template

Organisez un atelier dédié, idéalement en dehors d’un sprint en cours. Réunissez développeurs, testeurs, Product Owner et Scrum Master. Posez cette question simple : qu’est-ce qui nous a causé le plus de problèmes lors de nos dernières livraisons ?

Les réponses alimentent naturellement votre DoD. Si les bugs en production sont fréquents, ajoutez un critère de tests end-to-end. Si la documentation est systématiquement en retard, intégrez-la dans la définition.

Des critères mesurables, pas des voeux pieux

Un critère de Done comme ‘le code est de bonne qualité’ ne sert à rien. En revanche, ‘la couverture de tests est supérieure à 75 %’ ou ‘aucun bug bloquant ou critique en recette’ sont des critères objectifs et vérifiables.

Voici un comparatif entre critères faibles et critères forts :

• Faible : ‘Les tests sont effectués’ / Fort : ‘Les tests unitaires, d intégration et de recette sont passés sans erreur’
• Faible : ‘La doc est à jour’ / Fort : ‘Le README et le changelog sont mis à jour avant la merge request’
• Faible : ‘Le PO a regardé’ / Fort : ‘Le PO a validé les critères d acceptation en environnement de staging’

Faire évoluer la DoD au fil des sprints

Une DoD n’est pas gravée dans le marbre. Elle doit être revue régulièrement en rétrospective, au minimum une fois par trimestre. À mesure que l’équipe monte en compétence, les standards peuvent être rehaussés : ajout d’un critère d’accessibilité RGAA, intégration d’une étape de scan de sécurité automatique, etc.

Chez plusieurs clients accompagnés par TechWise Solutions, nous avons constaté qu’une DoD évolutive permet de réduire le taux de bugs post-livraison de 40 % en moyenne sur six mois.

Les erreurs les plus fréquentes et comment les corriger

Même les équipes expérimentées tombent dans certains pièges récurrents. Les identifier en amont vous épargnera beaucoup de frustrations.

Erreur n°1 : une DoD trop longue ou trop ambitieuse

Certaines équipes rédigent une DoD de 20 critères dès le premier sprint. Résultat : impossible à respecter, systématiquement ignorée. Il vaut mieux démarrer avec 5 à 7 critères réalistes et les enrichir progressivement.

La règle empirique : si votre équipe ne peut pas valider 90 % des critères de la DoD pour une Story donnée, c’est que la DoD est soit trop ambitieuse, soit que la Story est mal découpée.

Erreur n°2 : une DoR qui n’est jamais appliquée en Backlog Refinement

Beaucoup d’équipes définissent une DoR mais ne l’utilisent pas concrètement lors du refinement. Les User Stories entrent alors dans le sprint sans être réellement prêtes, ce qui génère des blocages et des dépendances non résolues.

La solution : intégrer une checklist DoR explicite dans votre outil de gestion (Jira, Azure DevOps, Linear…). Chaque Story ne peut pas être placée dans le sprint backlog si la checklist n’est pas complète.

Erreur n°3 : confondre DoD et critères d’acceptation

Les critères d’acceptation décrivent le comportement attendu d’une fonctionnalité spécifique. La DoD, elle, s’applique à toutes les User Stories de manière transverse. Ce sont deux niveaux de qualité complémentaires, non substituables.

Exemple concret : ‘L’utilisateur peut filtrer les produits par catégorie’ est un critère d’acceptation. ‘Le code est couvert à 80 % par des tests unitaires’ est un critère de Done.

Erreur n°4 : ne pas afficher la DoD visiblement

Une DoD enfouie dans Confluence que personne ne consulte ne sert à rien. Affichez-la dans votre espace de travail physique ou digital, discutez-en en Sprint Planning, évoquez-la en Daily si nécessaire. La visibilité est la clé de l’appropriation.

Faire vivre la DoD et la DoR dans la durée : bonnes pratiques terrain

Mettre en place une DoD et une DoR est une chose. Les faire respecter et évoluer dans la durée en est une autre. Voici les pratiques qui font vraiment la différence.

Ancrer la DoD dans les cérémonies Scrum

La DoD doit être un réflexe, pas une formalité. En Sprint Review, le Scrum Master pose systématiquement la question : chaque Story livrée respecte-t-elle la DoD ? Si ce n’est pas le cas, l’incrément n’est pas considéré comme terminé et ne peut pas être présenté.

En rétrospective, analysez les écarts : quels critères de la DoD ont été difficiles à tenir ? Pourquoi ? Quels ajustements apporter pour le prochain sprint ?

Automatiser ce qui peut l’être

Les critères techniques de la DoD peuvent et doivent être automatisés au maximum. Une pipeline CI/CD bien configurée peut vérifier automatiquement la couverture de tests, le respect des normes de code (linting), l’absence de vulnérabilités de sécurité connues.

Cela réduit la charge cognitive de l’équipe et garantit une application systématique sans dépendre de la vigilance humaine. Plusieurs équipes que nous accompagnons ont réduit leur temps de validation manuelle de 30 % grâce à l’automatisation des critères DoD.

Adapter la DoD au contexte organisationnel

Une startup de 8 développeurs n’a pas la même DoD qu’une DSI de 200 personnes. Le niveau de formalisme, les exigences de conformité (RGPD, ISO 27001, accessibilité RGAA) et les contraintes métier varient considérablement.

Dans un contexte réglementé comme la banque ou la santé, la DoD intégrera des critères de traçabilité, de sécurité et d’audit spécifiques. Dans une équipe produit en mode exploration, elle sera plus légère pour préserver la vélocité.

Former et sensibiliser en continu

Chaque nouveau membre de l’équipe, qu’il soit développeur, testeur ou Product Owner, doit être onboardé sur la DoD et la DoR dès son arrivée. Ces outils ne sont utiles que si l’ensemble de l’équipe les comprend et les partage.

Prévoyez un moment dédié lors de l’onboarding, et désignez un référent (souvent le Scrum Master) chargé de veiller à leur bonne application au quotidien.

Conclusion

La Definition of Done et la Definition of Ready ne sont pas de simples formalités Agile. Ce sont des leviers puissants pour améliorer la qualité de vos livraisons, fluidifier vos sprints et aligner votre équipe sur des standards communs.

Pour résumer les points clés de cet article :

• La DoR protège l’entrée dans le sprint, la DoD protège la sortie.
• Co-construisez ces outils avec votre équipe pour garantir leur appropriation.
• Privilégiez des critères mesurables et automatisables.
• Faites évoluer votre DoD en rétrospective, au minimum chaque trimestre.
• Ancrez ces outils dans chaque cérémonie Scrum pour qu’ils deviennent des réflexes.

Vous souhaitez mettre en place ou renforcer vos pratiques Agile au sein de votre organisation ? TechWise Solutions accompagne les équipes IT françaises dans la transformation de leurs méthodes de travail, avec un regard pragmatique et orienté résultats. Contactez nos experts dès aujourd’hui pour un premier échange personnalisé.