Definition of Done (DoD)

Qu’est-ce que la Definition of Done (DoD) ?

La Definition of Done (souvent abrégée DoD) est un concept fondamental des méthodologies Agiles (comme Scrum ), mais son utilité dépasse largement ce cadre. Elle désigne une liste explicite de critères techniques et fonctionnels qui doivent être impérativement remplis pour qu'une tâche ou une fonctionnalité soit considérée comme réellement terminée.

C'est un cadre de référence partagé entre l'équipe technique (développeurs) et le métier (Product Owner / Client). Il permet d'aligner tout le monde sur la réponse à une question simple mais source de nombreux conflits : "Est-ce que c'est fini ?".

L'analogie du restaurant

Pour comprendre la nuance, imaginez une cuisine de restaurant. Le cuisinier pourrait dire "le plat est prêt" dès que la cuisson est terminée. Mais pour le chef de salle, le plat n'est "fini" que lorsqu'il est dressé dans l'assiette, la sauce nettoyée sur le bord, et posé sur le passe-plat.

En développement web, la situation est similaire. Une fonctionnalité peut sembler terminée du point de vue du développement, tout en étant encore inutilisable ou risquée à livrer. La Definition of Done permet précisément de définir ce qui doit être vérifié au-delà de l’écriture du code, afin qu’une fonctionnalité soit réellement prête à être mise à disposition des utilisateurs.

Le problème résolu : Le syndrome du "90% terminé"

Pourquoi formaliser cette liste ? Pour éviter le piège classique du développement logiciel : l'illusion de l'avancement.

Sans DoD claire, un développeur peut considérer sa tâche terminée dès qu'il a écrit le code. Mais il reste souvent tout le travail invisible : la documentation, les tests, le déploiement, la vérification sur mobile... C'est ce qui crée le syndrome du "90% terminé" : le projet semble avancer très vite au début, mais stagne indéfiniment à la fin car on accumule une "dette de finition".

La DoD agit comme un garde-fou. Elle empêche de marquer une tâche comme terminée si ce travail invisible n'est pas effectué. Cela rend la vélocité de l'équipe réaliste et transparente : on ne masque pas la complexité réelle du travail.

Concrètement, que contient une DoD ?

La Definition of Done n'est pas une liste universelle, elle s'adapte à chaque contexte.

Cependant, pour une application web moderne de qualité, on y retrouve généralement les standards suivants :

• Le code est produit et respecte les standards de l'équipe.
• La Code Review a été effectuée et validée par un pair.
• Les Tests Unitaires sont écrits et passent avec succès.
• Le code ne casse pas l'existant (pas de régression détectée par le CI/CD).
• La fonctionnalité est déployée sur l'environnement de recette (staging).
• L'affichage est vérifié sur mobile et desktop.

Note : Cette liste est illustrative. Chaque projet doit définir ses propres exigences.

Distinction critique : DoD vs Critères d'Acceptation

C'est la confusion la plus fréquente. Ces deux notions sont complémentaires mais distinctes :

1. La Definition of Done

Elle est générique et s'applique à toutes les fonctionnalités du projet, sans exception.

• Exemple : "Tout développement doit être testé et validé par une revue de code."
• Analogie : C'est comme le Code de la route (mettre sa ceinture, respecter les limitations). Cela s'applique à tous les trajets.

2. Les Critères d'Acceptation

Ils sont spécifiques à une fonctionnalité précise (User Story).

• Exemple : "Le bouton 'Ajouter au panier' doit être bleu et rediriger vers la page commande."
• Analogie : C'est votre itinéraire GPS pour ce trajet précis (tourner à gauche, s'arrêter au numéro 12).

Une fonctionnalité n'est validée que si elle respecte à la fois l'itinéraire (Critères d'Acceptation) et le code de la route (DoD).

Un levier de prévisibilité et de maîtrise des coûts

Imposer une DoD stricte peut sembler ralentir le développement au quotidien. C'est en réalité un outil de rentabilité à moyen terme.

• Réduction de l'Effet Boomerang : Une tâche qui respecte la DoD a très peu de chances de revenir pour un bug ou un oubli. On évite les allers-retours épuisants entre le client et les développeurs.
• Mise en production sereine : Si la DoD est respectée tout au long du sprint, la mise en ligne n'est plus une source de stress. On sait que tout ce qui est "Done" a déjà été testé, validé et déployé en pré-production. On supprime l'improvisation finale.

L’avis de notre expert

Chez Hexium, nous ne voyons pas la Definition of Done comme une contrainte administrative, mais comme un langage commun.

Lorsqu'une équipe entière s'accorde sur ce terme, la relation devient transparente. Il n'y a plus de mauvaises surprises ou de fonctionnalités "livrées mais pas testées".

La DoD ne doit jamais être imposée unilatéralement. Elle doit être co-construite par l'équipe technique et métier. C'est cet accord mutuel qui garantit que le niveau de qualité attendu est bien celui qui sera livré.