Une équipe à qui l’on dit «le TDD est obligatoire» écrit des tests. Elle les écrit après le code, pour que la revue passe. Une équipe à qui l’on fixe 80% de couverture atteint 80% de couverture, souvent avec des tests sans aucune assertion. Les indicateurs bougent, l’habitude reste la même: on conçoit d’abord, on vérifie ensuite, quand il reste du temps.
Je ne crois pas qu’une règle change la façon dont une équipe écrit du code. Une règle dit ce qu’il faut obtenir. Elle ne montre pas le geste qui y mène, et c’est le geste qui manque. Personne n’apprend le TDD en lisant une charte; on l’apprend en écrivant un test qui échoue, puis le code qui le fait passer, puis en recommençant jusqu’à ce que l’ordre inverse paraisse étrange.
C’est ce que fait un kata.
Un geste, pas un résultat
Le mot vient des arts martiaux: une suite de mouvements que l’on répète jusqu’à ce qu’ils ne demandent plus de réflexion. En code, un kata est un exercice court, au sujet connu d’avance, que l’on refait pour la manière et non pour la solution. Le résultat compte peu; on le jette à la fin de la séance. Ce qui reste, c’est la façon de l’avoir obtenu.
Trois propriétés font sa force.
- Rien ne part en production. Personne ne risque une régression, personne n’attend la livraison. On peut essayer une approche, la rater, en essayer une autre. Le droit à l’erreur n’est pas une politesse, c’est la condition de l’apprentissage.
- Le sujet est petit. Il tient dans une séance. L’attention va au geste, pas à la compréhension d’un domaine métier complexe.
- On pratique ensemble. À deux ou en groupe, chacun voit comment l’autre découpe le problème, nomme les choses, choisit le test suivant. La moitié de l’apprentissage se fait là, en regardant.
Préparer les sujets avec les référents
Un kata trouvé sur internet apprend un geste. Un kata préparé pour l’équipe apprend le geste dont elle a besoin.
La différence tient à qui prépare le sujet. Dans les équipes avec lesquelles je travaille, ce sont les référents techniques de l’équipe, avec moi, qui le construisent à partir de ce qui fait mal sur le projet: une classe que personne n’ose toucher, des conditions imbriquées sur quatre étages, des tests qui cassent à chaque refactoring. Le sujet garde la taille d’un exercice, mais il parle de leur code.
Un principe simple aide: un sujet, une pratique. Un kata sur les conditionnelles imbriquées travaille le refactoring par petits pas. Un kata sur un calcul de tarif travaille le TDD. Mélanger les deux dans la même séance, c’est rendre les deux flous.
Préparer les sujets avec les référents a un second effet, moins visible: ce sont eux qui animent ensuite. Le savoir ne reste pas chez celui qui anime, il s’installe dans l’équipe.
Avancer par niveaux
Les katas ne sont pas une liste de sujets au hasard. Ils suivent un parcours, et l’ordre compte: on ne pratique pas l’architecture hexagonale avec une équipe qui ne sait pas encore isoler une dépendance dans un test.
Le parcours que j’utilise compte six niveaux.
- Le code propre: nommage, fonctions courtes, principes SOLID, object calisthenics, un peu de programmation fonctionnelle.
- Les tests: la pyramide de tests, le TDD, le BDD, et une première rencontre avec l’architecture hexagonale, parce qu’elle rend le code testable.
- L’architecture applicative: hexagonale approfondie et clean architecture.
- Le découpage: DDD, passage d’un monolithe à des microservices, strangler pattern, micro-frontends.
- Les patterns distribués: saga, API, sécurité, observabilité, outbox.
- CQRS et event sourcing.
La plupart des équipes n’ont pas besoin d’aller au bout. Maîtriser le troisième niveau change déjà le quotidien: un code testable, des tests écrits avant, une architecture qui sépare le métier de la technique. Les niveaux suivants concernent les équipes dont le produit l’exige.
Du kata au vrai code
Un kata qui reste un exercice ne change rien. L’équipe pratique le mardi, puis retourne le mercredi à un code où le geste n’a pas sa place: pas de tests, des dépendances partout, une échéance qui presse. Au bout de quelques semaines, le kata devient une parenthèse sympathique.
Le pont, c’est le binôme sur le vrai projet. Après une séance sur le TDD, un référent et un développeur prennent un ticket réel et le développent en TDD. Après une séance sur l’architecture hexagonale, on extrait ensemble un premier adaptateur du code existant, par petits pas, sans tout réécrire. Le kata montre le geste dans un cadre sûr; le binôme le pose là où il compte.
Les effets se voient alors dans le projet lui-même: une couverture qui monte parce que les tests arrivent avec le code, des anomalies relevées par l’analyse statique qui diminuent, des dépendances enfin mises à jour. Et, souvent, une meilleure relation avec le métier, parce qu’il y a moins d’imprévus.
Pourquoi le rituel s’effondre
La première raison que donnent les équipes qui décrochent est toujours la même: «pas le temps». Elle est vraie. Une séance de kata prend du temps à une équipe qui a déjà trop de tickets. Si ce temps n’est pas prévu, il disparaît à la première échéance.
Il n’y a qu’une réponse, et elle n’est pas technique: le temps doit être donné. Des demi-journées bloquées dans le calendrier de toute l’équipe, que personne ne remplit par une réunion. Du temps dédié pour les référents, qui préparent les sujets et accompagnent les binômes, et pour les équipes, qui pratiquent; un jour par semaine et par personne est un bon ordre de grandeur. Ce temps n’est pas un coût caché de la qualité, c’est son budget visible.
La seconde raison est plus lente: l’essoufflement. Quand la démarche repose toujours sur les mêmes référents, avec peu de temps dédié, la pratique finit par entrer en hibernation. Faire tourner les référents, tous les trimestres ou tous les quatre mois, change cela: chacun porte une pratique pendant une période, puis passe la main et prend une autre responsabilité. La démarche ne repose plus sur les mêmes volontaires.
Ce que les katas ne règlent pas
Les katas ne remboursent pas la dette technique d’un projet existant. Un code sans tests, couplé de partout, reste tel quel tant que personne n’y touche. Les katas donnent aux développeurs les gestes pour l’assainir; ils ne le font pas à leur place.
Ils ne remplacent pas non plus une décision de l’encadrement. Une équipe ne peut pas écrire ses tests d’abord si chaque ticket est estimé comme s’ils n’existaient pas. Le rituel tient quand le management le protège: du temps, des objectifs qui mesurent autre chose que la vitesse brute, et la patience de laisser le geste s’installer.
Le geste avant la règle
Une règle peut venir plus tard, quand elle décrit ce que l’équipe fait déjà. Alors elle ne contraint plus personne: elle protège une habitude acquise.
Imposée avant le geste, la règle produit des indicateurs. Le geste d’abord produit des développeurs qui écrivent le test en premier parce qu’ils ne savent plus faire autrement.