Le vrai danger pour un code n’est pas l’erreur, mais l’habitude de la laisser passer.

Présentation

La règle des Boy Scouts trouve son origine dans une maxime attribuée à Robert Stephenson Smyth Baden-Powell, fondateur du scoutisme :

Try and leave this world a little better than you found it.

Dans le monde du développement logiciel, cette idée a été reprise et popularisée par Robert C. Martin :

Leave the code a little better than you found it.

Appliquée au développement logiciel, cette règle concerne les interventions sur du code existant, lorsqu’un développeur corrige un bug, fait évoluer une fonctionnalité ou ajuste un comportement. Elle s’exerce dans un périmètre limité, au cœur d’un code déjà en place, et engage la responsabilité du développeur sur ce qu’il modifie, aussi local que soit le changement.

La règle des Boy Scouts ne vise pas la dette au sens strict. Dans sa définition première, la dette concerne la modélisation du domaine métier : elle résulte de choix conceptuels imparfaits ou incomplets, souvent connus, et dont la correction nécessite des échanges, des arbitrages et une validation explicite avec le métier. Elle engage une réflexion collective et dépasse largement le cadre d’une intervention locale.

La règle des Boy Scouts s’intéresse à un autre registre : celui du passif technique. Elle cible ces dégradations plus discrètes qui apparaissent au fil des modifications quotidiennes. Code dupliqué, méthodes trop longues, conditions inutilement complexes, responsabilités mal découpées, noms approximatifs ou non alignés avec le métier, noms abscons, coquilles, incohérences de style, non respect de certaines pratiques de développement… Autant de petits défauts qui, pris isolément, semblent anodins, mais qui finissent par s’installer et former un passif technique diffus.

La règle des Boy Scouts s’inscrit précisément à ce niveau. Elle encadre ces gestes ordinaires afin d’éviter que les petits compromis s’accumulent sans contrôle et finissent par rendre le code opaque. Elle ne demande pas de tout corriger, mais de s’assurer que chaque intervention laisse le code légèrement meilleur qu’elle ne l’a trouvé.

Pourquoi cette règle est importante

L’importance de la règle des Boy Scouts ne tient pas à l’ampleur des changements qu’elle encourage, mais à l’effet cumulatif de leur absence. Lorsqu’aucune discipline n’encadre les petites dégradations du quotidien, le code ne se dégrade pas brutalement. Il s’érode lentement, presque imperceptiblement, jusqu’à perdre sa cohérence interne.

Ce phénomène est bien connu dans d’autres domaines et a été formalisé sous le nom de théorie de la vitre brisée. Appliquée à l’urbanisme, cette théorie explique qu’un environnement négligé — une vitre cassée laissée en l’état, un mur tagué, un espace dégradé — envoie un signal implicite : ici, le désordre est toléré. Ce signal suffit à encourager d’autres dégradations, souvent mineures au départ, mais qui finissent par transformer durablement le lieu.

Le code fonctionne de la même manière. Un premier écart, même minime, modifie la perception de ce qui est acceptable. Et ce changement de perception est bien plus dangereux que l’écart lui-même.

Imaginons un code parfaitement structuré. Les conventions sont claires, le nommage est précis, les responsabilités bien délimitées. Un développeur intervient pour ajouter une petite fonctionnalité. Pressé, distrait ou simplement moins attentif, il introduit une variation : une méthode écrite différemment, un nom un peu vague, une structure légèrement bancale. Rien de dramatique. Le code fonctionne. La modification passe.

Un second développeur arrive plus tard sur ce même module. Il ne connaît pas l’intention initiale, mais il observe ce qu’il a sous les yeux. Il voit ce bout de code et en déduit, naturellement, que c’est ainsi que les choses se font ici. Il ne copie pas le code, mais il en reproduit le style, la forme, les choix implicites. Pour lui, c’est désormais une référence locale.

Un troisième développeur intervient alors. Il observe deux façons différentes de structurer le code. À partir de là, plusieurs options s’offrent à lui. Il peut essayer de revenir à la version “idéale”, au risque de créer une rupture avec ce qu’il voit autour. Il peut suivre l’une des deux approches existantes, sans savoir laquelle est réellement la bonne. Ou il peut en introduire une troisième, puisqu’aucune règle claire ne semble s’imposer.

À ce stade, le problème n’est plus l’erreur initiale. Le véritable dommage est ailleurs : le design interne de l’application a perdu sa cohérence. Les règles implicites ont disparu. Chaque nouvelle intervention ajoute un peu plus d’entropie, non par malveillance, mais par adaptation au contexte perçu.

C’est précisément ce mécanisme que la règle des Boy Scouts cherche à enrayer. En imposant de corriger — ou au minimum de ne pas aggraver — les petits écarts visibles lors d’une intervention, elle empêche qu’une variation locale devienne une norme implicite. Elle maintient un signal clair : ici, la qualité est intentionnelle, même à petite échelle.

La règle ne garantit pas un code parfait. Elle protège quelque chose de plus fragile encore : la cohérence du design dans le temps.

Responsabilité collective et détection du désalignement

Adoptée collectivement, la règle des Boy Scouts ne se limite pas à contenir le passif technique. En maintenant une attention constante sur la qualité locale du code, elle permet aussi de faire émerger plus tôt des problèmes plus profonds, relevant du désalignement conceptuel.

Lorsqu’un développeur ajoute une fonctionnalité ou fait évoluer un comportement, il peut constater que celle-ci ne s’exprime pas proprement dans le modèle existant. Pour “faire rentrer” le changement, il devient nécessaire d’introduire un cas particulier, de tordre une abstraction ou d’ajouter une structure artificielle. Le code reste techniquement correct, mais le modèle résiste.

À ce stade, la tentation est grande de se contenter d’une implémentation fonctionnelle et de passer à la suite. Une équipe imprégnée de l’esprit “boy scout” adopte une autre posture : sans chercher à corriger seule le modèle, elle reconnaît ce signal et le rend visible.

Cette vigilance ne relève pas directement de la règle elle-même, mais de la responsabilité collective qu’elle encourage. Le passif technique peut être corrigé localement ; la dette, liée au modèle métier, nécessite des échanges et des arbitrages avec le métier. La règle des Boy Scouts ne traite pas cette dette, mais elle évite qu’elle s’installe silencieusement, masquée par des bricolages successifs.

En ce sens, elle ne garantit pas l’alignement du modèle, mais elle en devient un révélateur précoce.

Conclusion

La règle des Boy Scouts n’est ni une technique de refactoring, ni une solution miracle face à la dette. C’est une discipline simple, presque triviale, dont l’exigence réside dans sa constance. Appliquée collectivement, elle empêche le passif technique de s’imposer comme une norme et préserve la cohérence interne du code dans le temps.

En maintenant un haut niveau d’attention sur les détails, elle permet aussi de rendre visibles les points de friction du modèle, sans prétendre les résoudre seule. La dette, lorsqu’elle apparaît, peut alors être abordée explicitement, avec le métier, plutôt que s’installer silencieusement sous la forme de compromis locaux.

La règle des Boy Scouts ne garantit pas un code parfait. Elle garantit mieux que cela : que chaque intervention laisse le système dans un état intentionnel, et que sa dégradation, lorsqu’elle existe, soit toujours le résultat d’un choix conscient, jamais d’un abandon progressif.

"Do a Good Turn Daily !"

Boy scouts of America - Slogan