Un ticket fermé la veille au soir peut vouloir dire deux choses très différentes : « le code fonctionne et j’ai vérifié son comportement » ou « le code compile et je l’ai regardé une fois à l’écran ». Sans définition partagée de ce que signifie « terminé », une équipe navigue entre ces deux réalités sans jamais s’en rendre compte, jusqu’au jour où une régression atteint la production.
La Definition of Done (DoD) est un accord d’équipe qui fixe, une fois pour toutes, la liste des conditions qu’un développement doit remplir avant d’être considéré comme terminé. Ce billet montre comment y intégrer la preuve testée sans se transformer en processus lourd, et laisse de côté le choix d’un outil de gestion de projet particulier.
Ce qu’une Definition of Done change concrètement
Sans DoD, chaque développeur applique implicitement son propre standard, ce qui produit une équipe où la qualité perçue d’un ticket dépend de qui l’a fermé plutôt que de ce qu’il contient réellement. Une DoD explicite déplace la question : ce n’est plus « ai-je le sentiment que c’est fini » mais « ai-je coché chaque ligne de la liste convenue ».
Definition of Done — équipe extension WordPress
1. Le code respecte les standards de codage du projet (WPCS)
2. Un test automatisé couvre le comportement métier ajouté ou modifié
3. La suite de tests complète passe en local avant ouverture de la pull request
4. La documentation du changelog est mise à jour
5. Un second développeur a relu et approuvé la pull request
Le deuxième critère est celui qui manque le plus souvent dans les équipes qui débutent cette démarche : sans lui, un ticket peut être fermé sur la seule base d’un test manuel effectué une fois par le développeur, sans qu’aucune trace n’en subsiste pour l’avenir.
Formaliser sans alourdir : la règle des cinq critères
Une DoD qui dépasse une dizaine de critères finit presque toujours ignorée, parce que personne ne relit une liste aussi longue à chaque ticket. Cinq critères, mémorisables sans effort, suffisent en général à couvrir l’essentiel : standards de code, test automatisé, suite verte, documentation, revue croisée.
L’intégrer dans le gabarit de ticket, pas dans un document séparé
Une DoD écrite dans un document oublié après sa rédaction ne sert à rien. L’intégrer directement dans le gabarit utilisé pour créer chaque ticket, sous forme de cases à cocher, rend la vérification quasi automatique :
- Chaque case cochée engage la personne qui ferme le ticket, pas seulement celle qui l’a ouvert.
- Une case non cochable honnêtement (« aucun test ajouté ») doit déclencher une discussion, pas une fermeture silencieuse.
- La liste doit rester identique pour tous les tickets d’un même type, sans exception tacite.
Le cas des correctifs urgents
Un correctif urgent en production tente souvent de contourner la DoD au nom de la vitesse. C’est justement le cas où l’absence de test coûte le plus cher : un correctif appliqué sans test qui reproduit d’abord le bug risque de masquer le symptôme sans traiter la cause, et de laisser le même problème resurgir sous une autre forme quelques semaines plus tard.
Un correctif urgent mérite un test qui reproduit le bug avant la correction, pas après : c’est souvent le seul moyen de prouver que le correctif traite la bonne cause.
Faire vivre la règle en revue de code, pas seulement à l’écrit
Une Definition of Done qui existe uniquement sur le papier s’érode en quelques semaines si personne ne la fait respecter en pratique. La revue de pull request est le moment naturel pour vérifier chaque critère, en particulier la présence effective d’un test, avant d’accepter la fusion :
- Le relecteur ouvre le diff et cherche d’abord le fichier de test associé au changement.
- En son absence, la pull request reste ouverte, avec une demande explicite plutôt qu’un refus silencieux.
- Une exception acceptée une fois, sans justification écrite, devient vite la nouvelle norme tacite de l’équipe.
En résumé
Une Definition of Done qui inclut la preuve testée transforme la fermeture d’un ticket en engagement vérifiable, plutôt qu’en déclaration de confiance. Cinq critères courts, intégrés au gabarit de ticket et vérifiés en revue de code, suffisent à installer durablement cette discipline sans ajouter de lourdeur au quotidien de l’équipe.
