06.10.2026 · Signal Titans Editorial

La règle de Brian Kernighan pour un meilleur code : trop malin, il devient impossible à déboguer

Brian Kernighan parlant devant un micro au Vintage Computer Festival East en 2025.

Brian Kernighan a passé des décennies au contact de certains des logiciels les plus influents de l’histoire de l’informatique. Une règle revenait sans cesse dans ses conseils, presque embarrassante de simplicité : si votre code est trop malin, vous ne serez peut-être plus assez malin pour le réparer plus tard.

Brian Kernighan a travaillé trente ans aux Bell Labs, dans le groupe informatique associé au développement d’Unix, avant de rejoindre la faculté d’informatique de Princeton. Il a coécrit The C Programming Language avec Dennis Ritchie et signé certains des ouvrages les plus influents sur le style de programmation, les outils et les langages.

Pour quelqu’un avec ce parcours, son conseil sur le code est étonnamment peu spectaculaire.

« Déboguer est deux fois plus difficile qu’écrire le code la première fois. »

La suite de l’idée découle presque naturellement : si vous utilisez toute votre ingéniosité en écrivant un programme, il vous reste très peu de marge pour le comprendre lorsque quelque chose casse.

Cela ressemble à une blague sur les programmeurs. C’est en réalité une règle sur la complexité.

La solution brillante a un prix caché

Tant que le code fonctionne, l’ingéniosité peut ressembler à de l’efficacité. Une expression dense remplace dix lignes ordinaires. Une abstraction générique traite six cas à la fois. Une astuce compacte économise une boucle, une allocation ou une fonction.

Puis trois mois passent.

La personne qui relit le code n’a plus tout le problème en mémoire. Les hypothèses d’origine se sont effacées. Un bug de production apparaît dans un cas que personne n’avait prévu. Et la personne qui doit lire le code sous pression n’est peut-être même pas celle qui l’a écrit.

C’est à ce moment-là que le vrai coût de l’ingéniosité apparaît.

La question n’est plus « Combien de lignes ai-je économisées ? », mais « Combien d’idées dois-je garder simultanément en tête pour comprendre ce que ce code peut faire ? ».

Les premiers travaux de Kernighan sur le style de programmation allaient précisément dans ce sens. L’objectif n’était pas de rendre les programmeurs moins sophistiqués. Il s’agissait de rendre les programmes plus faciles à raisonner pour d’autres humains.

Un code lisible n’est pas un code de débutant

On entend parfois « rester simple » comme « éviter les techniques avancées ». Ce n’est pas le sujet.

Un système sophistiqué peut exiger des idées sophistiquées. La discipline consiste à empêcher cette sophistication de se répandre partout.

Si une partie du système a vraiment besoin d’un algorithme difficile, isolez-la. Donnez-lui un nom qui révèle ce qu’elle fait. Placez les hypothèses à côté. Testez les limites. Laissez le reste du programme aussi ennuyeux que possible.

Un bon code ne prouve pas combien son auteur sait de choses. Il réduit ce que le prochain lecteur doit savoir en même temps.

C’est pourquoi la clarté passe mieux à l’échelle que l’ingéniosité. Une personne brillante peut comprendre une astuce. Une équipe, un mainteneur futur, quelqu’un en pleine réponse à incident et votre propre cerveau à deux heures du matin ont besoin de quelque chose de plus durable.

Une grande partie du débogage commence avant le bug

Dans leurs écrits ultérieurs sur le débogage, Kernighan et Rob Pike rappellent que la plupart des bugs sont ordinaires et qu’un bon débogage commence par l’examen des faits, puis un raisonnement à rebours à partir de ce que le programme a réellement fait.

Ce processus devient beaucoup plus simple lorsque le code possède des frontières claires.

De petites fonctions réduisent la zone de recherche. Un état explicite rend visibles les mauvaises transitions. De bons noms préservent l’intention. Les tests transforment des hypothèses en exemples exécutables. Un bon logging peut réduire des heures de devinettes à quelques minutes.

Aucune de ces techniques n’est spectaculaire.

C’est précisément pour cela qu’elles fonctionnent.

L’ère de l’IA rend cette règle plus importante, pas moins

L’IA peut désormais produire du code qui semble fonctionner plus vite que la plupart des équipes ne peuvent le relire. Cela déplace le goulot d’étranglement.

Écrire du code devient moins cher. Comprendre du code ne l’est pas.

Une fonction générée peut compiler. Elle peut passer le happy path. Elle peut même sembler élégante. Mais le problème de maintenance reste humain : quelles hypothèses a-t-elle faites ? Que se passe-t-il lorsqu’elle échoue ? Cette abstraction est-elle nécessaire ? Quel comportement est intentionnel, et lequel n’est qu’un accident de l’implémentation générée ?

Si un outil peut produire 500 lignes en quelques secondes, il est tentant de mesurer le progrès à la quantité de sortie. Mais un logiciel n’a pas de valeur parce que beaucoup de lignes existent. Il en a parce que le système reste suffisamment compréhensible pour être modifié en sécurité.

Plus le code est produit vite, plus l’illisibilité devient coûteuse.

Quatre questions pour chaque pull request

Puis-je expliquer cette section sans exécuter mentalement chaque ligne ? Sinon, l’abstraction cache peut-être trop de choses, ou pas assez.

Quand cela cassera, où regarderai-je d’abord ? Si la réponse est « partout », les frontières sont faibles.

La version ordinaire pourrait-elle être un peu plus longue mais beaucoup plus facile à vérifier ? Quelques lignes supplémentaires coûtent parfois moins cher que plusieurs couches de raisonnement.

La prochaine personne comprendra-t-elle pourquoi ceci existe ? Le code conserve le comportement. Les noms, la structure et les commentaires conservent l’intention.

Il y aura toujours des moments où une solution ingénieuse est réellement la bonne.

Mais l’ingéniosité devrait être une ressource qu’un système dépense volontairement, pas quelque chose qu’un programmeur affiche par défaut.

L’avertissement de Kernighan a survécu parce que le matériel a changé, les langages ont changé et maintenant l’IA change la façon dont le code est produit — mais la personne qui débogue au bout de la chaîne dispose toujours d’un cerveau limité.

Quelle part du code dont vous êtes le plus fier aujourd’hui semblera encore évidente à la personne qui devra le réparer dans un an ?