Il y a une phrase que tout le monde a déjà entendue, sous une forme ou une autre : « laisse le code dans un meilleur état que celui dans lequel tu l’as trouvé ». Derrière cette formule presque trop simple se cache l’un des leviers les plus puissants, et les plus négligés, de la pérennité d’une base de code. C’est la Boy Scout Rule, popularisée par Robert C. Martin (Uncle Bob), et son intérêt ne tient pas à ce qu’elle prescrit, mais à la manière dont elle transforme le rapport d’une équipe à la qualité.
À l’origine, la règle n’a rien à voir avec le code. Les boy scouts avaient pour principe de laisser un campement plus propre qu’ils ne l’avaient trouvé : ramasser un déchet qui n’était pas le sien, remettre une bûche en place, éteindre proprement un feu. Transposée au logiciel, cette discipline devient une routine d’hygiène qui change tout, précisément parce qu’elle ne demande aucun héroïsme.
Capitaliser sur le travail en cours, pas dédier un projet
L’erreur la plus répandue consiste à penser l’amélioration du code comme un effort distinct : un créneau qu’il faudrait réserver, une tâche qu’il faudrait planifier, un « projet de refactoring » qu’il faudrait vendre à la roadmap. La Boy Scout Rule prend exactement le contre-pied de cette logique.
L’idée n’est pas de dédier du temps à une amélioration intensive et ciblée de certaines parties du code. L’idée est de capitaliser sur les besoins de développement déjà en cours et d’introduire des améliorations comme des effets de bord de l’ajout d’une fonctionnalité. Plus besoin de planifier des tâches ou des projets pour s’autoriser à entretenir la base de code. On se laisse simplement la liberté, ou plutôt on se contraint, à améliorer les composants connexes et les parties du code que l’on traverse en travaillant sur des fonctionnalités qui apportent de la valeur.
Cette nuance est décisive. Tant que l’amélioration reste un sujet à part, elle entre en compétition avec le business, et elle perd presque toujours. Quand elle devient un sous-produit naturel du delivery, elle cesse d’être un arbitrage pour devenir un réflexe.
L’écho de l’Opportunistic Refactoring
Cette approche fait directement écho au principe d’Opportunistic Refactoring évoqué par Martin Fowler : saisir chaque opportunité de refactoring, aussi petite soit-elle, au moment où l’on a déjà le contexte en tête et le fichier sous les yeux. C’est précisément lorsqu’on travaille sur un morceau de code que l’on en comprend le mieux les défauts, et donc que le coût de l’améliorer est le plus faible. Repousser à plus tard, c’est s’obliger à recharger tout ce contexte une seconde fois, un effort qui, le plus souvent, ne sera jamais consenti.
Faire de l’amélioration continue un non-événement
L’objectif à atteindre tient en une idée : faire en sorte que l’amélioration continue du code soit un non-événement et un non-sujet pour vos équipes produit, au même titre que devrait l’être une mise en production un vendredi soir. Pas un débat, pas une autorisation à demander, pas une ligne dans un ticket. Juste quelque chose qui se fait, en continu, parce que c’est la manière normale de travailler.
Et par « amélioration », il faut entendre quelque chose de très vaste, qui va du simple au complexe :
- du refactoring au sens large, ou la simple amélioration du nommage et de la documentation ;
- la suppression, mise à jour ou remplacement d’une dépendance au regard des nouveaux standards de l’industrie ;
- la suppression du code mort, qui n’est plus utilisé mais continue de mobiliser de la charge cognitive ;
- les performances, la complexité algorithmique, ou un meilleur monitoring (logging, tracing, métriques).
Aucune de ces actions n’a besoin d’être spectaculaire. Leur force vient de leur accumulation, pas de leur ampleur individuelle.
Pourquoi les grandes améliorations échouent et les petites passent
Trop souvent, je vois des améliorations ciblées, purement techniques, soigneusement décrites dans un backlog, et systématiquement repoussées jusqu’à être abandonnées. Elles seront toujours jugées moins prioritaires que les sujets business, et elles le resteront indéfiniment, parce qu’une amélioration technique isolée ne trouve jamais de fenêtre où elle pèse plus lourd qu’une demande produit.
Les petites améliorations, elles, passent beaucoup plus facilement et génèrent infiniment moins de friction. Elles ne réclament pas d’arbitrage, ne créent pas de débat de priorisation, n’exigent pas de justification. Elles se glissent dans le flux de travail existant et, mises bout à bout, produisent un résultat qu’aucun « grand projet de refactoring » n’atteint jamais.
C’est là tout le paradoxe : la stratégie la plus efficace pour améliorer une base de code n’est pas celle qui vise grand, mais celle qui vise petit, partout, tout le temps.
Un marathon, pas un sprint
L’amélioration du code, ou la préservation de sa qualité, est un marathon et non un sprint. On ne sauve pas une base de code par un effort ponctuel et intense ; on la maintient saine par une régularité qui ne faiblit pas.
Il est donc primordial d’adopter des routines quotidiennes d’hygiène du code au sens large, pour assurer la pérennité des logiciels et éviter de voir le rythme de delivery ralentir au fil du temps. Une base de code ne se dégrade jamais d’un coup : elle s’érode par petites négligences successives, chacune anodine. La Boy Scout Rule oppose à cette érosion une force inverse, faite elle aussi de petits gestes, mais orientés dans le bon sens.
Adopter cette discipline, ce n’est pas ajouter une contrainte de plus à des équipes déjà sous pression. C’est, au contraire, se débarrasser d’un faux dilemme : celui qui oppose la livraison de valeur à l’entretien du code. Bien comprise, la règle du scout réconcilie les deux. On livre, et en livrant, on laisse derrière soi un terrain un peu plus propre qu’on ne l’a trouvé.