Un sprint démarre. L’équipe pioche dans le backlog, choisit ses stories, et se met au travail. En review, tout semble “done” côté dev… sauf que le métier ne peut rien tester. Les maquettes n’étaient pas validées, les cas limites pas prévus, et la QA découvre le problème après coup.
Ce n’est pas un problème de delivery. C’est un problème de clarté :
👉 Ce que l’équipe appelait “Ready” n’était pas vraiment prêt.
👉 Et ce qu’elle appelait “Done” n’était pas vraiment fini.
Dans cet article, on clarifie les différences entre DoR et DoD, on montre comment les construire à l’échelle de votre équipe, et surtout comment les utiliser comme leviers de qualité et de fluidité - pas comme des checklists d’agiliste.
Pourquoi les équipes se perdent entre Ready et Done
Sur le papier, la mécanique est simple :
- la Definition of Ready garantit qu’une story est prête à être développée,
- la Definition of Done qu’elle est terminée et livrable.
⚠️ Mais sur le terrain, c’est souvent flou. Le Product Owner valide des stories “à compléter pendant le sprint”, les devs cochent “Done” dès que le code est mergé, et la QA découvre les trous à la veille de la démo.
Résultat ? Des sprints qui débordent, des stories qui roulent d’une itération à l’autre, et des équipes qui finissent par douter de leurs propres indicateurs.
👉 La cause est rarement un manque de bonne volonté. C’est un problème d’alignement collectif :
- côté produit, on pense “besoin utilisateur” ;
- côté tech, on pense “fonctionnalité codée” ;
- côté métier, on attend “valeur mesurable”.
Sans cadre commun, chacun déclare son “Done” à sa manière.
💡La DoR et la DoD sont là pour ça
Créer un langage partagé sur la complétude.
👉 L’une évite de lancer du travail flou.
👉 L’autre garantit que ce qu’on livre a réellement de la valeur.
Sans elles, le flux produit devient un jeu de ping-pong permanent entre “pas prêt” et “pas fini”.
Definition of Ready : l’assurance qualité avant le sprint
La Definition of Ready (DoR), c’est le garde-fou en amont du sprint.
Elle garantit qu’une User Story est vraiment exploitable par l’équipe avant d’être mise en développement. Autrement dit : on ne code pas dans le flou.
Une story “Ready”, c’est une story que l’équipe peut prendre sans lever la main toutes les deux heures pour poser une question. Les irritants classiques — dépendances non gérées, règles métier manquantes, maquettes incomplètes — sont déjà levés.
👉 Une bonne DoR, c’est un filtre de qualité, pas un frein à la vitesse.
Ce qu’on y retrouve souvent
- Le besoin utilisateur est clair et formulé au bon niveau (“En tant que…, je veux…, afin de…”).
- Les critères d’acceptation sont définis et compris.
- Les maquettes ou cas d’usage clés sont validés.
- Les dépendances techniques ou fonctionnelles sont identifiées.
- L’équipe estime qu’elle peut livrer dans le sprint.
💡 Test simple
Si la story déclenche encore des “ça veut dire quoi, ce point ?” pendant le planning, elle n’était pas Ready.
Anti-pattern courant
Certaines équipes pensent “on affinera pendant le sprint”.
C’est le meilleur moyen de perdre du temps en réunions et de fausser la vélocité. Un ticket non prêt, c’est du risque déguisé.
Une Definition of Ready claire ne ralentit pas la delivery : elle évite juste de commencer sans savoir où l’on va.
Definition of Done : le contrat de qualité à la sortie
La Definition of Done (DoD), c’est la ligne d’arrivée partagée. Elle définit quand une User Story est réellement terminée — pas seulement codée, mais prête à être utilisée, testée, et mise en production sans surprise.
👉 Là où la DoR protège le sprint en entrée, la DoD protège la valeur en sortie. Elle évite que “fait” veuille dire dix choses différentes selon qu’on parle à un dev, un QA ou un sponsor.
Une story “Done”, c’est une story qui :
- a passé ses tests unitaires et fonctionnels ;
- répond aux critères d’acceptation de la story ;
- est intégrée, documentée, et déployable ;
- et surtout, crée la valeur attendue par l’utilisateur final.
🔍 Retour terrain
Une équipe tech déclarait ses stories “Done” dès que le code était mergé.
Le PO découvrait les défauts en démo, et la QA deux jours plus tard.
Après avoir instauré une DoD commune - code revu, QA validée, doc mise à jour - les surprises de review ont chuté de 70 %.
La DoD n’est pas qu’une checklist de contrôle qualité. C’est un contrat d’équipe : une promesse que chaque story livrée correspond à un niveau de qualité reconnu par tous.
Une règle simple : si vous devez encore dire “on réglera ça au prochain sprint”, c’est que la story n’est pas Done.
Ready vs Done : la différence en un coup d’œil
La Definition of Ready et la Definition of Done ne jouent pas sur le même terrain.
L’une sécurise le départ, l’autre valide l’arrivée.
Mais c’est souvent dans ce flou entre les deux que les équipes perdent du temps — et de la confiance.
🔍 Concrètement :
Une story “En tant que gestionnaire RH, je veux filtrer les candidatures par compétence…”
- est Ready quand les critères d’acceptation et les règles de filtrage sont définis ;
- est Done quand le filtre fonctionne, testé, intégré et mesuré en usage réel.
👉 La DoR et la DoD ne sont pas des process de contrôle. Ce sont des contrats de confiance entre produit, tech et métiers. Elles permettent de dire “on peut y aller” ou “on a fini” sans débat.
Sans ces repères, les équipes livrent plus de code que de valeur. Avec, elles gagnent en clarté, en rythme et en crédibilité.
Comment définir sa propre DoR et DoD d’équipe
Il n’existe pas de Definition of Ready ou de Done “universelle”. Chaque équipe a son contexte, ses rituels, ses contraintes techniques. Le piège, c’est de copier une checklist trouvée sur Internet.
Le bon réflexe, c’est de co-construire vos définitions avec l’équipe — pour qu’elles reflètent votre réalité, pas celle d’un manuel agile.
Étape 1 - Partir de l’expérience vécue
Demandez à l’équipe :
“Qu’est-ce qui fait qu’une story se passe bien ?”
“Et qu’est-ce qui fait qu’on galère à la livrer ?”
Listez les irritants : tickets flous, dépendances non gérées, QA tardive, tests manquants…
Vous venez de trouver les premiers éléments de votre DoR et de votre DoD.
Étape 2 - Formaliser ensemble
Traduisez ces constats en critères observables :
- DoR → “les règles métier sont validées”, “la story est estimée et sans dépendance bloquante”.
- DoD → “le code est mergé”, “les tests passent”, “la story répond aux critères d’acceptation”.
Moins de dix points chacun, écrits en langage clair, visibles sur le board.
Étape 3 - Tester et ajuster
Une DoR/DoD figée ne sert à rien.
Revisitez-les à chaque rétro : ce qui devient évident peut sortir, ce qui bloque souvent doit entrer.
C’est une mécanique vivante, pas une norme ISO.
💡 Pro tip
Intégrez vos DoR/DoD directement dans Jira ou votre outil de suivi : les équipes les voient, les cochent, et les vivent.
Elles deviennent un réflexe, pas un poster oublié en salle de réunion.
Exemples concrets de DoR et DoD
Une bonne Definition of Ready ou of Done n’est pas théorique. Elle prend tout son sens quand elle s’ancre dans la réalité du produit et des équipes.
Voici trois exemples concrets pour illustrer comment les adapter selon les contextes.
Cas 1 - Application métier (produit orienté process)
DoR
- Le parcours utilisateur est décrit et validé par le métier.
- Les règles de gestion sont comprises par l’équipe.
- Les dépendances techniques sont levées.
DoD
- Les tests unitaires et fonctionnels passent à 100 %.
- Les données sont disponibles dans l’environnement de recette.
- Le PO a validé la valeur livrée en démo.
👉 Les tickets “pas prêts” chutent de 40 %, et les sprints se déroulent enfin sans blocage de mi-parcours.
Cas 2 — Produit mobile (fort enjeu UX)
DoR
- Les maquettes sont finalisées et testées auprès d’utilisateurs.
- Les critères d’acceptation couvrent les cas d’erreur et de performance.
DoD
- La feature fonctionne sur les deux OS.
- Les crash reports sont à zéro en staging.
- L’équipe UX a validé la cohérence du design system.
👉 Des livraisons plus régulières et moins de retours post-release.
Cas 3 - Projet data / analytics
DoR
- Les sources de données sont identifiées et accessibles.
- Les règles de calcul ont été validées avec le métier.
DoD
- Les dashboards sont alimentés sans erreurs.
- Les écarts entre données brutes et agrégées < 2 %.
- La documentation du modèle est à jour.
👉 La mise en prod des dashboards passe de 3 semaines à 5 jours, avec 0 bug critique en recette et une confiance renforcée des métiers dans les chiffres.
Conclusion — Une DoR et une DoD qui font gagner du temps, pas du reporting
La Definition of Ready et la Definition of Done ne sont pas des gadgets agiles. Bien utilisées, elles sont le garde-fou de votre delivery : elles empêchent de démarrer dans le flou et de finir à moitié.
👉 La DoR protège vos sprints des tickets imprécis.
👉 La DoD protège vos livraisons des fausses “finitions”.
Ensemble, elles créent un cadre de confiance : chacun sait quand une story est prête à démarrer… et quand elle est vraiment terminée.
Mais leur vraie valeur ne vient pas des cases cochées : elle vient de la clarté qu’elles imposent dans les discussions. Moins de zones grises, plus de rythme, et des équipes qui livrent sans débattre à chaque sprint review.
Vous avez l’impression que vos sprints se bloquent entre “pas prêts” et “pas vraiment finis” ?
En quelques ateliers, on aide les équipes à poser des DoR et DoD adaptées à leur contexte - simples, partagées, et surtout efficaces.
