« Ça marche — n’y touche pas » — définition, essence du principe et risques

Qu’est-ce que le principe « ça marche — n’y touche pas »?

« Ça marche — n’y touche pas » — une règle empirique qui met en garde les développeurs contre la modification du code qui fonctionne sans raisons suffisantes. Le principe repose sur des statistiques simples : la grande majorité des défauts sont introduits lors de la modification du code existant.

Le principe n’est pas un dogme — c’est plutôt une heuristique qui aide à prendre des décisions dans des conditions d’incertitude. Plus la base de code est complexe et embrouillée, plus la probabilité qu’un changement « innocent » casse quelque chose que personne ne s’attendait à casser est élevée.

Selon une étude de Microsoft Corporation (2024), environ 60 % de tous les incidents critiques en production sont liés à des modifications récentes du code qui ont été apportées avec de bonnes intentions mais n’ont pas été suffisamment testées dans des conditions de charge réelle.

Histoire et origine du principe

L’expression « Si ce n’est pas cassé, ne le répare pas » remonte à la culture de l’ingénierie américaine du milieu du XXe siècle. L’utilisation documentée la plus ancienne est attribuée à Bert Lance (1977), qui travaillait au Comité des Finances du Sénat américain et s’opposait à une réglementation excessive.

En programmation, le principe vient de l’ingénierie matérielle, où remplacer une puce fonctionnelle par une nouvelle pouvait entraîner des conséquences imprévisibles. Dans le contexte du logiciel, ce principe a gagné une popularité particulière avec la complexité croissante des systèmes logiciels et l’émergence du code legacy.

Il est intéressant de noter qu’en programmation, le principe a aussi un revers — « ça marche, mais mieux vaut ne pas y toucher » devient souvent une excuse pour éviter le remaniement, ce qui à long terme conduit à une accumulation critique de dette technique. Selon le cabinet de conseil Thoughtworks (2023), environ 40 % des projets rencontrent de sérieux problèmes en raison d’un conservatisme excessif vis-à-vis des changements.

Quand appliquer le principe

Le principe « ça marche — n’y touche pas » est particulièrement pertinent dans certaines situations où le coût d’une erreur dépasse le bénéfice potentiel des changements.

Projets legacy sans tests

Dans le code legacy qui n’est pas couvert par des tests, tout changement est une roulette russe. Si un développeur ne peut pas vérifier que le changement n’a pas cassé les modules adjacents, la meilleure stratégie est de ne pas toucher au code qui fonctionne. L’exception concerne uniquement les bogues critiques ou les exigences de sécurité.

Systèmes critiques

Dans les systèmes où les temps d’arrêt sont inacceptables ou le coût d’une erreur est énorme — logiciels médicaux, avionique, transactions financières — le principe « ça marche — n’y touche pas » est la norme de facto. Tout changement passe par une approbation et des tests à plusieurs étapes.

Délais serrés

Si la livraison est demain et que le code fonctionne — n’essayez pas d’améliorer son architecture. Modifiez uniquement ce qui affecte directement les fonctionnalités de la livraison. Reportez le remaniement au prochain sprint (mais ne l’oubliez pas).

Risques à suivre le principe

Suivre aveuglément le principe « ça marche — n’y touche pas » comporte des risques non moins importants qu’un remaniement sans fin. Examinons les principaux dangers.

Accumulation de dette technique

Si chaque développeur suit ce principe, la base de code se transforme rapidement en un « gâteau à plusieurs couches » de solutions obsolètes, de rustines et d’algorithmes sous-optimaux. Tôt ou tard, la dette technique devient insoutenable — tout changement nécessite des semaines d’analyse.

Opportunités d’optimisation manquées

Parfois, un changement qui semble risqué améliore en réalité considérablement les performances ou la sécurité. Le principe « ça marche — n’y touche pas » ne devrait pas bloquer les changements qui apportent des bénéfices mesurables — réduire les coûts serveur, accélérer le chargement des pages, améliorer la sécurité.

Perte de compétences

Lorsqu’une équipe ne touche pas certaines parties du code pendant des années, elle perd la compréhension de leur fonctionnement. Le développeur clé s’en va — et le code devient un legacy sans possibilité de maintenance. Le principe doit être appliqué en tenant compte de la maintenabilité à long terme du projet.

Le juste milieu : remaniement sans fanatisme

La stratégie optimale n’est pas de suivre le principe aveuglément, mais de l’appliquer consciemment, en tenant compte du contexte. Le remaniement est nécessaire, mais il doit être sécurisé.

La règle du scout

La règle du scout en programmation : « Laisse le code plus propre que tu ne l’as trouvé. » Si un développeur apporte une modification à un module, il doit améliorer sa structure, mais dans des limites raisonnables. Ne pas tout réécrire de zéro, mais au moins renommer les variables illisibles et ajouter des commentaires.

Remaniement sous protection de tests

Les tests sont le seul moyen d’appliquer le principe « ça marche — n’y touche pas » en toute sécurité. Si le code est couvert par des tests, tout remaniement devient prévisible : le développeur modifie le code, exécute les tests et voit si quelque chose s’est cassé. Sans tests — n’y touche pas. Avec des tests — remanie en toute confiance.

// Exemple : remaniement sûr sous couverture de tests
class PriceCalculator {
    fun calculatePrice(basePrice: Double, discount: Double): Double {
        // Code ancien mais fonctionnel
        return basePrice - (basePrice * discount / 100.0)
    }
}

// Test qui protège contre la régression
class PriceCalculatorTest {
    fun testCalculatePrice() {
        val calc = PriceCalculator()
        assertEquals(90.0, calc.calculatePrice(100.0, 10.0))
    }
}

Cet exemple montre la bonne approche : d’abord le test, ensuite le remaniement. Si le test réussit, le changement est sûr. Le principe « ça marche — n’y touche pas » se transforme en « ça marche sous tests — remanie avec audace. »

Exemples réels de la pratique

Examinons des scénarios réels où le principe « ça marche — n’y touche pas » s’est avéré aussi bien salvateur que destructeur.

Cas salvateur : un problème de type Y2K

Un développeur a découvert que le code de traitement des dates utilisait le format JJ/MM/AA au lieu de AAAA. Le code fonctionnait correctement de 2000 à 2025. Malgré l’envie de le « corriger », il a laissé le code tel quel, se limitant à un commentaire. En 2026, l’entreprise a mis à jour le système, et la nouvelle solution traitait correctement les siècles. Un changement prématuré aurait cassé la logique fonctionnelle.

Cas destructeur : perte de données due à une « amélioration »

Un ingénieur a décidé d’« améliorer » l’ancien code d’importation de données, qui fonctionnait, en le remplaçant par une bibliothèque moderne. Il n’a pas tenu compte du fait que l’ancienne bibliothèque traitait un cas particulier spécifique qui n’était pas documenté. Après la mise en production — perte massive de données. Le principe « ça marche — n’y touche pas » a été violé, et le coût de l’erreur a été de deux semaines de travail d’équipe pour la récupération.