Idée principale

Se dispenser de la revue d'un développeur sur un outil qu'on s'est fabriqué a une contrepartie qui n'est pas facultative : quand cet outil casse, personne d'autre n'est engagé. Celui qui a choisi de le construire mange sa propre nourriture, et le dépannage lui revient.

C'est là que la promesse se fissure. Un assistant de code a supprimé la barrière d'entrée — écrire la fonctionnalité — sans supprimer la compétence de sortie : comprendre pourquoi ce qui marchait hier ne marche plus, lire une trace d'erreur, isoler une régression, distinguer un problème de données d'un problème de logique. Beaucoup de Product Managers savent désormais faire produire un écran et ne savent pas résoudre le bug qu'ils viennent de créer.

L'asymétrie est le cœur du sujet : la production est devenue accessible, l'exploitation ne l'est pas devenue au même rythme.

Pourquoi c'est important

Cela donne un critère d'entrée plus honnête que le niveau de code : non pas « saurais-tu l'écrire ? », mais « sauras-tu t'en dépatouiller quand ça cassera, sans mobiliser quelqu'un d'autre ? ». Un outil qu'on ne saurait pas dépanner n'est pas un outil personnel, c'est une dette posée chez le voisin.

Cela nomme aussi ce qui se cache derrière beaucoup de demandes de revue : moins un contrôle qualité qu'une manière de transférer d'avance la responsabilité du dépannage.

Nuances et limites

L'assistant reprend une partie de la charge — il lit la trace, propose une correction, explique ce qu'il a fait. La limite n'est donc pas absolue ; elle porte sur les cas où comprendre le problème est le préalable à la question qu'on devrait lui poser.

Et la règle suppose que l'outil reste personnel. Dès qu'une équipe en dépend, la panne cesse d'être un problème privé, et la responsabilité individuelle ne suffit plus à l'absorber.

Questions ouvertes

• Quelle compétence minimale de diagnostic — lire une trace, consulter un log, rejouer une requête — faut-il exiger avant d'autoriser quelqu'un à mettre en service un outil qu'il a fait produire ?