Définition de terminé : ce que c’est et comment l’utiliser

Galen Low

on Jun 15, 2026

J’ai appris que la plupart des débats sur la définition de « terminé » ne portent pas sur le travail, mais sur les attentes. Voici comment créer une définition de terminé qui aligne qualité, confiance et livraison.

Key Takeaways

Cohérence de la qualité: Établir une définition de terminé partagée prévient la confusion et améliore la qualité du travail au sein de l’équipe.

Prévision améliorée: Une définition claire aide à prévoir précisément la vélocité et à mieux planifier le projet.

Pièges courants: Évitez de rendre la définition trop détaillée ou de ne pas l’appliquer, car cela peut entraîner des problèmes.

Étapes pratiques: L’article détaille les étapes concrètes pour créer une définition de terminé efficace pour les équipes agiles.

La définition de terminé (DoD) est la norme partagée qui détermine quand un travail est réellement achevé. Elle aide à éviter les manques de qualité, les reprises et les mauvaises surprises à la fin du sprint. J’ai vu des équipes de développement perdre la confiance, rater des échéances et créer des conflits inutiles parce que chacun avait une interprétation différente du mot « terminé ».

Dans ce guide, vous apprendrez à créer une définition de terminé qui aligne votre équipe agile, améliore la prévisibilité et renforce la qualité, avec des exemples pratiques, des modèles et les erreurs courantes à éviter.

Qu’est-ce que la Définition de Terminé ?

La définition de terminé est un ensemble formel et partagé de critères qu’un élément du carnet de produit ou un incrément doit satisfaire avant que l’équipe ne le considère comme achevé et potentiellement livrable. Considérez-la comme le contrat qualité que votre équipe s’engage à respecter pour chaque tâche, quelle que soit sa taille ou sa complexité.

Voici les principales caractéristiques d’une définition de terminé efficace :

Transparence : Tous les membres de l’équipe et les parties prenantes clés peuvent la consulter, la lire et s’y référer à tout moment.
Mesurable : Chaque critère est binaire. Le travail le respecte ou non, mais les seuils choisis pour les critères quantitatifs méritent une vraie réflexion. Un objectif de couverture de code à 80 % s’applique de manière binaire, mais le choix entre 80 %, 70 % ou 90 % relève du jugement que vous devez prendre de façon délibérée.
Compréhensible par tous : Chaque membre de l’équipe Scrum doit pouvoir interpréter chaque élément de la même manière.
Appliquée de façon cohérente : La même liste de contrôle doit être appliquée à chaque livrable et à chaque élément du carnet de produit.
Réaliste dans un sprint : Les critères doivent être suffisamment réalistes pour que l’équipe puisse les atteindre dans un même sprint ou itération.

Dans les projets de développement logiciel, ce sont généralement les développeurs qui possèdent la définition de terminé car ils sont responsables de son respect. Cela dit, le Product Owner et le Scrum Master doivent également y contribuer.

Si votre organisation possède ses propres standards de définition de terminé, chaque équipe Scrum doit les respecter au minimum. Les équipes sont toujours libres d’ajouter des critères plus exigeants, mais ne peuvent pas descendre en-dessous du niveau fixé par l’organisation.

Pourquoi la Définition de Terminé est Importante

Une définition de terminé claire est importante car elle empêche que des travaux partiellement achevés passent entre les mailles du filet et fournit une norme partagée de qualité.

Voici d’autres raisons pour lesquelles une définition de terminé partagée compte :

Agit comme un garde-fou qualité : Chaque élément doit répondre aux mêmes exigences avant d’être considéré comme terminé. Cela empêche le travail à moitié fini de s’infiltrer dans l’incrément de produit et de s’accumuler sous forme de dette technique.
Élimine les ambiguïtés : Lorsque l’équipe partage une même définition, vous ne vous retrouvez pas dans des situations où des définitions conflictuelles affectent la vitesse ou la qualité du travail. Une définition de terminé partagée signifie moins de conflits, moins de surprises et des démonstrations plus propres.
Améliore la prévision : Lorsque « terminé » veut dire la même chose à chaque sprint, vous pouvez prévoir la vélocité avec confiance et planifier les versions sans gonfler les estimations pour anticiper les reprises.
Renforce la confiance des parties prenantes : Lorsque les Product Owners, la direction et les parties prenantes externes peuvent voir que votre équipe applique une norme de qualité claire, ils font confiance à vos livrables.
Évite le chaos de l’intégration : Si vous travaillez d’une manière qui nécessite que l’équipe intègre son travail dans un incrément commun, une compréhension partagée de la définition de terminé offre la base pour des incréments cohérents et livrables.

Comment créer une Définition de Terminé

Voici les étapes clés pour créer une définition de terminé.

Auditez votre workflow actuel : Cartographiez chaque étape que votre travail suit déjà avant d’atteindre la production. Discutez avec les développeurs, les testeurs, les designers et toutes les personnes impliquées dans le processus. Vous découvrirez des étapes informelles de contrôle qualité qui devraient être formalisées.
Identifiez les critères de qualité incontournables : Déterminez quelles activités doivent absolument être effectuées pour chaque tâche. Il s’agit généralement de la relecture de code, des tests automatisés, de la mise à jour de la documentation et des analyses de sécurité. Soyez honnête sur ce que vous négligez actuellement.
Rédigez la checklist de manière collaborative : Réunissez toute l’équipe et établissez-la ensemble à l’aide d’un tableau blanc ou d’un document partagé où chacun peut ajouter, contester et améliorer les éléments en temps réel. Une définition du terminé élaborée par consensus résiste beaucoup mieux à la pression qu’une version imposée malgré des objections.
Validez avec les normes de l’organisation : Croisez votre brouillon avec les politiques qualité établies, les exigences réglementaires ou les normes de votre secteur auxquelles votre produit doit répondre. Si votre organisation possède déjà une définition de base du terminé, partez de là et enrichissez-la.
Rendez-la visible : Affichez la définition là où votre équipe travaille au quotidien. Cela peut être une affiche au mur, un message épinglé dans Slack ou un panneau dans votre outil de gestion de projet.
Engagez-vous à l’appliquer : Une définition du terminé qui est écartée à l’approche des délais est pire que de ne pas en avoir, car elle donne une fausse impression de qualité.

Exemples de définitions du terminé

Voici quelques exemples de définitions du terminé selon différents types de projets :

Définition du terminé pour les projets de développement logiciel

Les projets logiciels sont confrontés à une grande variété de risques qualité : bugs, failles de sécurité, pertes de performance et problèmes d’intégration. La définition du terminé pour une équipe de développement doit couvrir l’ensemble du processus, du code à un état publiable.

Cela pourrait ressembler à :

Tous les codes écrits et relus par au moins un autre développeur
Tests unitaires réussis avec le niveau de couverture convenu
Tests d’intégration validés dans le pipeline CI/CD
Aucun bug ouvert de criticité élevée ou critique
Documentation technique mise à jour pour refléter les changements
Code fusionné avec la branche principale
Travail relu et validé par le Product Owner
Bénéfices de performance atteints selon les seuils convenus

Définition du terminé pour les projets marketing

Le travail marketing comporte souvent des dimensions de conformité, de marque et de mesure qui diffèrent du logiciel.

Voici à quoi pourrait ressembler la définition du terminé pour un projet marketing :

Contenu relu et approuvé par l’équipe juridique
Checklist SEO validée, incluant les meta descriptions, textes alternatifs et liens internes
Tous les assets téléchargés dans le CMS et correctement formatés
Suivi d’analytics configuré et vérifié dans l’environnement de préproduction
Dernière version du texte relue par un deuxième membre de l’équipe
Checklist de lancement de la campagne validée par le responsable d’équipe

Définition du terminé pour les projets design

Les équipes design ont besoin d’une définition du terminé qui fasse le lien entre l’intention créative et la transmission technique. Sans cela, les designs sont remis au développement de façon incomplète, avec des spécifications manquantes, des comportements réactifs non testés ou des écarts d’accessibilité découverts trop tard.

Voici un exemple de définition du terminé pour un projet design :

Design revu selon les normes d’accessibilité WCAG 2.2
Fichier de transfert préparé dans l’outil convenu avec toutes les spécifications, ressources et annotations
Validation et signature des parties prenantes reçues et documentées
Composants du design system mis à jour si de nouveaux patterns ont été introduits
Comportement réactif validé sur tous les points de rupture convenus

Définition du terminé vs. critères d’acceptation

La définition du terminé représente le standard qualité de votre équipe, tandis que les critères d’acceptation sont des exigences fonctionnelles au niveau d’une fonctionnalité.

Pensez à la définition de terminé comme à la base qui s’applique universellement, tandis que les critères d’acceptation sont propres à chaque sprint backlog ou élément du backlog produit. Un élément du backlog produit est terminé lorsqu’il répond à la fois à ses critères d’acceptation et à la définition de terminé de l’équipe.

Aspect	Définition de Terminé	Critères d’acceptation
Périmètre	S’applique à chaque élément du backlog produit et à chaque incrément	Spécifique à une user story ou un élément du backlog
Responsabilité	Détenue par les développeurs, avec l’apport de toute l’équipe Scrum	Rédigés par ou avec le product owner
Spécificité	Normes générales de qualité pour tout le travail	Exigences fonctionnelles détaillées pour une tâche spécifique
Fréquence de changement	Change rarement ; mis à jour lors des rétrospectives de sprint	Évolue avec chaque nouvelle user story
Point de vérification	Vérifié avant qu’un élément ne soit marqué comme terminé	Vérifié lors de la revue de la story ou des tests d’acceptation

Écueils et erreurs fréquents

Voici quelques erreurs courantes à éviter lors de la création de définitions de terminé :

Sauter des étapes pour aller plus vite : Sous la pression des délais, les équipes omettent souvent des critères comme la revue de la sécurité, les tests d’accessibilité ou la documentation. Cela génère une dette technique cachée qui se manifeste plus tard sous forme de bugs, de retours en arrière ou de problèmes de conformité.
Rendre la liste trop détaillée : Une définition de terminé trop granulaire devient une corvée bureaucratique. Si votre checklist contient 30 items et que les développeurs passent plus de temps à cocher des cases qu’à produire, vous êtes allés trop loin. Soyez suffisamment précis pour que ce soit utile, mais assez général pour rester pratique.
Changer la définition à chaque story : Toute la logique de la définition de terminé repose sur sa cohérence. Les conditions propres à une fonctionnalité doivent être intégrées dans les critères d’acceptation, pas dans la définition de terminé.
Ne jamais la réviser : Une définition de terminé doit évoluer avec la maturation de vos pratiques, les changements d’outils ou l’évolution de votre produit. Je recommande de la revoir au moins une fois par trimestre lors des rétrospectives et de l’ajuster lorsque des lacunes ou des irritants apparaissent.
Ne pas l’appliquer : Une définition systématiquement ignorée à la demande de quelqu’un d’influent est inutile. Le rôle du Scrum master est de la protéger, même si un acteur souhaite livrer ce qui ne répond pas aux exigences. Si les critères sont régulièrement outrepassés, l’équipe perd confiance dans la norme et cesse de la prendre au sérieux.
Confondre « terminé » et « déployé » : La définition de terminé détermine si un incrément est livrable, pas s’il a été effectivement déployé. Un élément du backlog produit peut être terminé sans être déployé. N’ajoutez pas « déployé en production » à votre définition de terminé sauf si votre équipe gère réellement tout le processus de bout en bout.
Ne pas la consulter : De nombreuses équipes disposent théoriquement d’une définition de terminé, mais si personne ne l’a relue depuis sa création il y a six mois, elle ne joue plus du tout son rôle de référentiel qualité.

Quelle est la suite ?

Renforcez vos processus agiles et vos méthodes de travail avec des outils, modèles et conseils d’experts pratiques grâce à une adhésion DPM gratuite, et consolidez les systèmes qui aident vos équipes à livrer du travail de qualité, régulièrement.