Le 22 juin 2026, Martin Tournoij (arp242) a publié un court article dont le titre ne modifie qu’une lettre par rapport au principe classique — Fence devient Finger. Derrière ce jeu de mots se cache un véritable désastre du génie logiciel. Il a été embauché pour reprendre une base de code vieille de 13 ans, dont tous les développeurs précédents étaient partis avant lui. Le git log contient 295 lignes de messages de commit au total ; après avoir retiré les commits automatiques de dependabot et les « fix typo », il n’en reste que 167, soit environ une par mois. Pas de documents de conception. Pratiquement aucun commentaire dans le code. Des restes de refactorisations inachevées, des vestiges de fonctionnalités supprimées, et des fonctions écrites mais jamais appelées par aucune page.
Tournoij appelle cela le majeur de Chesterton. « Oui, nous avons fait toutes ces choses étranges, et nous n’avons pas l’intention de dire à quiconque pourquoi. Ha ha, va te faire voir. »
Le principe de la clôture de Chesterton est tiré de l’ouvrage de G.K. Chesterton, « The Thing » (1929). La parabole est simple : un réformateur voit un mur au milieu d’une route, le juge inutile et veut le démolir. Chesterton dit : ne te précipite pas — découvre d’abord pourquoi il a été construit. Peut-être que la raison de sa construction t’échappe encore, mais elle a existé. Ce principe est cité à maintes reprises par la communauté du génie logiciel car il décrit avec précision un scénario d’accident fréquent : quelqu’un supprime un code qui « semble inutile », et des mois plus tard, la production plante — ce code gérait un cas limite qui ne se déclenche qu’une fois tous les trois ans. Personne ne sait pourquoi il était là, car la personne qui l’a écrit a quitté l’entreprise deux ans plus tôt.
arp242 n’a pas changé Fence en Finger pour le plaisir du jeu de mots. Dans la base de code que Tournoij a héritée, le problème n’était pas que le code était mal écrit — le mauvais code, on en trouve partout. Le problème était qu’il n’y avait aucune trace du « pourquoi ». Treize années de décisions cumulées — tous les compromis, toutes les contraintes historiques, tous les pièges dans lesquels on était déjà tombé — tout s’était évaporé. La personne qui reprend le code ne « franchit pas un mur » — un mur a au moins une existence physique visible, suggérant que « quelqu’un a pris une décision ici ». Il faisait face à un vide d’information total. C’est bien pire qu’un mur. Le mur est un rappel silencieux ; le majeur est une moquerie silencieuse.
Cette différence touche à la valeur la plus fondamentale des commentaires de code. Le code lui-même dit déjà « ce qui a été fait » — tant que le langage n’est pas volontairement obscur, la logique peut être lue. Mais le code ne peut jamais dire « pourquoi le choix A a été préféré au choix B ». Cette contournement étrange était dû à un bug dans une version spécifique d’une bibliothèque. Cette vérification de nullité apparemment redondante était la conséquence d’un incident P0 un vendredi après-midi de 2019. Cet ordre de tri étrange était imposé par une dépendance matérielle du système aval, elle-même une erreur historique. Si ces informations ne sont ni dans les commentaires ni dans les messages de commit, elles disparaissent à jamais. La question de Tournoij est directe : écrire ces explications n’est pas un travail supplémentaire optionnel, cela fait partie du travail de développement. Ce n’est pas grave si c’est mal écrit, si l’anglais est mauvais, si certains détails sont oubliés — mais il faut au moins « quelque chose ». N’avoir rien, c’est faire un doigt d’honneur à tous ceux qui viendront après.
Dans la discussion sur Lobsters, ChrisDenton (18 votes) a porté le sujet au niveau organisationnel. Il souligne un dilemme plus subtil : parfois, au moment où une décision est prise, personne ne sait quelles informations deviendront importantes plus tard. Si les discussions autour d’une décision ne sont pas enregistrées — que ce soit par courriel, chat ou ticket — l’« archéologie numérique » ultérieure devient presque impossible. Et quand une organisation considère les développeurs comme des pièces interchangeables, cette vulnérabilité est poussée à l’extrême. Personne ne reste assez longtemps, personne n’accumule une compréhension intuitive de l’ensemble du système, les mêmes erreurs sont commises encore et encore, la réinvention de la roue devient la norme. Le ton de ChrisDenton est mesuré, mais la conclusion est tranchante : les organisations qui traitent les développeurs comme des pièces interchangeables sont les plus fragiles.
david_chisnall (8 votes) enfonce le clou du point de vue de la revue de code. Il affirme que la plus grande valeur de la revue de code est de vous forcer à ajouter des commentaires sur les décisions non évidentes — la découverte de bugs est un sous-produit. La plus grande valeur est que « la deuxième personne vous oblige à annoter les décisions non évidentes ». Lui-même écrit des commentaires pour ce qui lui semble peu évident. Le relecteur pose des questions sur ce qui lui semble peu évident. Après deux tours, les commentaires couvrent ce que chacun des deux estime devoir être expliqué. Quand un développeur ultérieur lit ce code, la probabilité de compréhension n’est plus nulle. L’élégance de ce mécanisme est qu’il ne repose pas sur la conscience de l’auteur — il intègre la préservation des connaissances dans un processus qui ne peut être contourné.
Mais faut-il garder tous les murs ? La question a aussi son revers. Steph Tulkens a écrit un article intitulé « La brèche de Chesterton » — construire d’abord le mur, avant même qu’il ne soit nécessaire. Le conservatisme excessif est tout aussi nuisible : chaque équipe connaît ce code hérité que personne n’ose toucher, alors que la logique environnante a déjà changé trois fois, et que le problème que ce code traitait a probablement disparu depuis longtemps — mais parce qu’« on ne sait pas pourquoi il a été écrit », on le conserve. La dette technique ne vient pas seulement d’une modification irréfléchie du code ; ne pas oser modifier le code accumule aussi de la dette technique. Quand faut-il démolir le mur, quand faut-il le garder ? Aucun algorithme ne peut trancher automatiquement. Le jugement ne peut venir que d’une compréhension suffisamment profonde du système — ce qui nous ramène à l’argument de ChrisDenton : si une organisation traite les développeurs comme des pièces interchangeables, elle ne peut même pas développer ce jugement.
Voici un cadre décisionnel simplifié, présenté sous forme de liste de questions :
| Dimension | Plutôt conserver | Plutôt supprimer |
|---|---|---|
| Disponibilité du contexte | L’équipe d’origine a quitté, aucun document ni commentaire | Le décideur d’origine est encore présent, on peut lui demander directement |
| Impact du changement | Concerne un chemin métier critique, conséquences graves en cas d’erreur | Module isolé, couverture de test complète |
| Clarté de l’intention du code | Commentaire expliquant le « pourquoi », logique cohérente | Le commentaire décrit le « quoi » et ne correspond pas au comportement du code |
| Fréquence de déclenchement | Gère un cas limite rare mais à fort impact | Code prouvé comme n’étant jamais exécuté |
| Coût de remplacement | La réécriture nécessite de redécouvrir tous les cas limites | Des spécifications claires existent pour guider la réécriture |
Ce tableau ne résout rien. Il rappelle simplement : décider s’il faut démolir le mur nécessite plus d’informations que de le démolir lui-même.
L’article de Tournoij a obtenu 82 votes sur Lobsters, non pas parce qu’il disait quelque chose de nouveau. La clôture de Chesterton est débattue dans le génie logiciel depuis plus d’une décennie. La résonance vient de l’émotion qu’il a nommée — écrire du mauvais code n’est pas nécessairement malveillant, mais partir sans laisser une seule explication est un mépris pour tous ceux qui suivent. Chaque développeur qui a été réveillé à trois heures du matin par « ce code hérité incompréhensible » reconnaît ce majeur tendu. Le réparer ne nécessite pas plus de procédures ou de processus — il suffit de considérer le message de commit comme faisant partie de la livraison. Ces 167 lignes sur 13 ans — ce chiffre, en lui-même, est l’argument le plus efficace.