Idée principale

Une compétence que l'usage courant ne sollicite plus ne se maintient pas toute seule. Un développeur qui demande à un assistant de lire, d'expliquer et de corriger à sa place garde l'habileté à piloter l'outil et perd progressivement celle de lire un code inconnu, de tenir un diagnostic ou de simplifier une architecture.

Le remède n'est pas de renoncer à l'outil, c'est de créer des situations où il n'est pas disponible : des dojos sans assistant, des exercices avec assistant bridé, des revues où l'on doit expliquer le code soi-même, des moments pris exprès pour lire, comprendre et simplifier. La même logique est admise ailleurs sans discussion — la calculatrice est utile, mais ne jamais poser une opération soi-même produit une dépendance ; en sport, on ajoute du poids et de la résistance parce que c'est la résistance qui développe le muscle.

Ce n'est pas une nostalgie du développeur qui souffre pour mériter son métier, et l'objectif n'est pas de ralentir partout. Il est de ralentir au bon endroit : produire très vite une partie du temps, et sanctuariser du temps long — une journée d'amélioration continue, des revues d'architecture, des ADR, des refactors lents, des post-mortems de génération ratée — pour comprendre ce qui a été produit.

Pourquoi c'est important

Cela traite un manque qu'aucune règle de production ne couvre : les contre-mesures qui protègent la qualité du système ne protègent pas l'aptitude de ceux qui le tiennent. Une équipe peut appliquer une discipline de merge impeccable et laisser s'éteindre la compétence qui lui permettrait de juger ce qu'elle merge.

Cela donne aussi une lecture d'un problème antérieur à l'outillage : beaucoup de développeurs restaient déjà le nez dans le guidon, à produire sans prendre le recul qui fait monter en compétence. L'accélération aggrave ce travers si elle remplit tout l'espace libéré par davantage de production, et le corrige si elle sert à distinguer le temps du faire et le temps du comprendre.

Nuances et limites

La difficulté ajoutée doit ressembler à celle du métier réel. Un exercice artificiel entretient l'aisance sur l'exercice, pas la compétence visée — et une contrainte mal choisie coûte du temps sans rien former.

Et certaines compétences rendues inutiles méritent de disparaître : personne ne s'entraîne à écrire de l'assembleur pour rester lucide sur son code. Distinguer ce qu'il faut entretenir de ce qu'on peut abandonner est un arbitrage ouvert, que cette idée ne tranche pas.

Questions ouvertes

• À quel signe une équipe s'aperçoit-elle qu'une compétence s'est éteinte, alors même que sa production quotidienne ne la sollicitait plus depuis longtemps et paraissait normale ?