Idée principale

Merger du code qu'aucun membre de l'équipe ne saurait expliquer n'est pas une négligence de revue : c'est un emprunt. L'équipe obtient la fonctionnalité tout de suite, et s'engage à payer plus tard en incapacité de diagnostic — au moment où il faudra modifier, sécuriser ou reprendre ce code sans savoir pourquoi il est écrit ainsi.

Le passif reste invisible tant que rien ne casse : l'application tourne, les écrans répondent, les tests passent. Des dizaines de pull requests ouvertes dans la nuit par un assistant et intégrées sans que personne n'ait vérifié les impacts ressemblent à de l'avance ; ce sont des intérêts qui courent.

D'où une règle de merge simple, presque brutale : ne pas intégrer de code que personne ne peut expliquer. Elle ne demande pas une documentation interminable — un petit budget de compréhension par fonctionnalité suffit : le contrat, les tests, la décision d'architecture, les limites connues. Juste assez pour que le raisonnement reste humainement transmissible.

Pourquoi c'est important

Cela remet un prix immédiat sur l'incompréhension, à l'endroit et au moment où la décision se prend. Tant que le coût est différé, chaque intégration isolée paraît raisonnable, et le passif s'accumule sans qu'aucun arbitrage ne l'ait accepté.

Cela donne aussi un critère de revue qui ne dépend pas du niveau technique du relecteur : la question n'est pas « ce code est-il bon ? » mais « quelqu'un ici sait-il dire pourquoi il est ainsi ? ».

Nuances et limites

La règle se heurte à une zone grise : expliquer à quel niveau ? Personne n'explique ligne à ligne le code d'une bibliothèque tierce, et une équipe qui exigerait ce degré sur tout n'intégrerait plus rien. L'objet de l'explication est l'intention et les frontières, pas chaque instruction.

Et elle ne vaut que si quelqu'un a l'autorité de bloquer une intégration. Dans une équipe où le délai prime, elle devient une formalité déclarative, et l'explication se réduit à la case cochée.

Questions ouvertes

• Sur quel périmètre l'explication doit-elle porter — la fonctionnalité, le module, la ligne — pour que la règle reste applicable sans devenir un rituel ?