Idée principale

Un développeur qui reprend un défaut qu'il a lui-même introduit ne fait pas que réparer. Il est la seule personne en position de comparer ce qu'il croyait livrer avec ce qui s'est réellement produit. Il voit où sa compréhension du besoin était incomplète, si le test qui aurait attrapé le cas n'existait pas, si la spécification laissait l'ambiguïté qu'il a tranchée tout seul, si l'architecture rendait l'erreur probable.

Un autre développeur qui corrige à sa place trouve la cause technique, pas la cause de la décision. Il répare le symptôme sans que l'information remonte à l'endroit où elle aurait changé quelque chose.

C'est cette boucle — livrer, rencontrer la conséquence, reconnaître ce qui manquait — qui produit l'amélioration. Elle n'est pas un effet secondaire de la correction : c'est sa valeur principale.

Pourquoi c'est important

Cela donne un critère de conception aux politiques de qualité : une politique qui optimise le délai de correction sans se demander qui corrige achète de la rapidité en supprimant l'apprentissage.

Cela explique aussi la répétition des mêmes erreurs de conception dans une équipe. Elles ne viennent pas d'un manque de compétence mais d'un circuit d'information qui ne revient jamais à l'auteur.

Nuances et limites

La boucle ne se ferme que si le défaut est rattaché à sa cause, et pas seulement à sa ligne de code : corriger sans nommer ce qui a manqué en amont produit une réparation de plus.

Et elle a un délai : plus le défaut apparaît tard, moins l'auteur se souvient de ce qu'il croyait faire au moment de livrer.

Questions ouvertes

• Où consigner ce que la correction révèle — test manquant, spécification ambiguë, architecture fragile — pour que cela agisse sur la livraison suivante plutôt que de rester dans la tête de celui qui a corrigé ?