Legacy & dette technique : mesurer, prioriser, rembourser sans arrêter le business

Le “legacy” a mauvaise presse. Dans les présentations, il est décrit comme un boulet, un frein à l’innovation, une menace cyber, une source de coûts. Dans la réalité, le legacy est surtout… ce qui fait tourner la boutique. Facturation, production, logistique, RH, laboratoire, relation client : la plupart des organisations reposent sur des briques historiques qui ont survécu parce qu’elles sont utiles, parce qu’elles sont stables, ou parce qu’on n’a jamais trouvé mieux au bon coût.

Le problème n’est pas d’avoir du legacy. Le problème, c’est de le laisser se transformer en dette technique incontrôlée. Quand la dette devient invisible, elle produit trois symptômes : une vitesse qui chute, des incidents qui augmentent, et une capacité de changement qui se fragilise. À ce stade, le débat n’est plus “moderniser ou pas”, mais “comment éviter la panne sèche”.

La bonne nouvelle, c’est qu’on peut rembourser sans arrêter le business. La mauvaise, c’est qu’il faut arrêter de parler de dette comme d’un concept moral et la traiter comme un portefeuille d’investissements : mesurer, prioriser, exécuter, vérifier.

La dette technique n’est pas un problème “de développeurs”

La dette technique n’est pas seulement du code “pas propre”. C’est une accumulation de choix qui ont un coût futur : versions obsolètes, dépendances non maintenues, architecture trop couplée, données mal gouvernées, automatisation absente, tests insuffisants, documentation fragile, sécurité bricolée, exploitation non outillée. C’est aussi de la dette process : gouvernance floue, validation lente, ownership incertain, run sous-staffé, connaissances concentrées sur deux personnes.

Elle devient critique quand elle empêche deux choses simples : changer vite et rester stable. Le paradoxe, c’est qu’une organisation peut être stable pendant des années… jusqu’au jour où elle doit bouger. C’est souvent là que le legacy se révèle : migration, acquisition, nouvelle réglementation, audit cyber, rupture fournisseur, incident majeur, ou pression business. La dette ne se voit pas quand on roule sur l’autoroute. Elle se voit quand on doit freiner et tourner.

Mesurer : remplacer les opinions par un score de risque et de valeur

La plupart des entreprises “savent” qu’elles ont de la dette. Peu savent où elle est, combien elle coûte, et quel risque elle porte. Sans mesure, on modernise à l’intuition, donc au bruit politique. Et le bruit politique modernise rarement le bon périmètre.

La mesure utile tient en deux axes : risque et valeur.

Côté risque, on peut objectiver sans faire une thèse : obsolescence (versions non supportées), exposition (surface internet, identités, secrets), fragilité (incidents, MTTR, recours aux experts rares), dépendances (éditeur unique, techno abandonnée), conformité (traçabilité, rétention, RGPD), et opérabilité (monitoring, sauvegarde testée, automatisation). Ce sont des critères simples à coter, même de façon imparfaite, mais répétable.

Côté valeur, il faut être brut : combien de chiffre d’affaires, de continuité opérationnelle, de conformité, ou de productivité dépend de ce service ? Qui l’utilise ? Combien de parcours critiques passent par lui ? Quelle est l’alternative ? Quel est le coût d’une heure d’arrêt à un moment clé ? Le legacy qui porte le cash mérite une modernisation différente du legacy qui sert un usage marginal.

En croisant risque et valeur, on obtient un portefeuille. Et un portefeuille, ça se pilote.

Prioriser : arrêter les grands programmes “big bang”, cibler les goulots

La modernisation échoue rarement par manque d’idées. Elle échoue parce qu’elle vise trop large, trop vite, avec une promesse de refonte totale qui devient vite ingérable. Les projets big bang finissent souvent par un compromis : on a dépensé beaucoup, on a déplacé le problème, et le business a perdu confiance.

Une approche plus efficace consiste à identifier les goulots qui coûtent le plus : ceux qui génèrent des incidents, qui bloquent les évolutions, ou qui exposent la sécurité. La priorité n’est pas “réécrire”, c’est réduire le risque et récupérer de la capacité.

Trois types de chantiers reviennent presque toujours en tête, parce qu’ils paient vite.

D’abord, les mises à niveau obligatoires : technologies en fin de support, OS, bases de données, middlewares, bibliothèques critiques. Ce n’est pas sexy, mais c’est souvent la source n°1 de risque cyber et d’incidents.

Ensuite, la stabilisation opérable : monitoring digne de ce nom, logs exploitables, alerting, sauvegardes testées, automatisation des déploiements, runbooks. On peut gagner énormément sans toucher au code métier, simplement en rendant le système observable et maîtrisable.

Enfin, le découplage : là où une application est un “bloc” qui empêche de changer, on cible des interfaces, des API, des contrats de données, des événements. L’objectif n’est pas de tout microserviciser, mais de rendre possible le changement par morceaux.

La priorité se résume en une phrase : on répare ce qui bloque et ce qui met en danger, avant de réinventer ce qui fonctionne.

Rembourser sans arrêter : transformer la dette en backlog “produit”

Le piège classique est de traiter la dette comme un projet parallèle. On ouvre un programme “dette technique”, on le dote d’un budget, et il se heurte immédiatement aux urgences business, donc il est dépriorisé. Au bout de six mois, on conclut que “le business ne veut pas”. En réalité, c’est l’organisation qui a mal cadré : la dette n’est pas un projet, c’est une partie de la production.

Le remède est connu mais rarement assumé : intégrer la dette dans le backlog, au même niveau que les features. Pas en supplément, pas “quand on aura le temps”, mais comme un engagement régulier. Une règle simple, variable selon la maturité : réserver une part fixe de capacité à la dette et à la fiabilisation. Ce n’est pas du luxe. C’est de l’entretien.

La dette devient alors visible, priorisée, estimée, et surtout livrée. Et quand elle est livrée, on peut mesurer l’effet : moins d’incidents, plus de vitesse, moins de tickets, moins de dépendance à des experts, moins de risques.

La méthode qui marche : des “tranches” courtes avec bénéfice immédiat

Rembourser sans arrêter implique une discipline : livrer par petits incréments, avec un bénéfice immédiat et mesurable. Cela ressemble à de l’ingénierie pragmatique : on attaque les causes principales, on sécurise, on simplifie, on automatise, et on valide.

Une tranche efficace répond à trois questions : qu’est-ce qu’on réduit comme risque, qu’est-ce qu’on débloque comme capacité, et comment le vérifie-t-on ?

Exemple : mise à niveau d’une base obsolète. Le bénéfice mesurable n’est pas “on est à la dernière version”. C’est : correctifs de sécurité applicables, performance stabilisée, outils de sauvegarde compatibles, réduction des incidents liés aux corruptions, capacité à migrer ensuite. On documente l’avant/après, on rend visible.

Autre exemple : automatiser un déploiement. Le bénéfice n’est pas “CI/CD”. C’est : fréquence de release plus élevée, moins d’erreurs humaines, rollback maîtrisé, temps de mise en production réduit, disponibilité renforcée. Là aussi, avant/après.

Cette logique “tranches” change la politique interne : le business voit des résultats, donc il accepte de continuer.

Faire accepter au business : parler en risque, en coût d’opportunité, en continuité

La dette technique devient un sujet Comex quand elle se traduit en trois risques concrets.

Le risque d’arrêt : la panne ou l’incident qui bloque une activité critique, avec un coût direct, une perte de confiance, parfois une exposition réglementaire.

Le risque de sécurité : des technologies non supportées, des vulnérabilités non patchables, des comptes partagés, des secrets mal gérés. Quand un audit ou une attaque survient, le legacy devient brutalement visible.

Le risque de stagnation : le coût d’opportunité. Quand chaque évolution prend trois fois plus de temps, le business perd en vitesse, en compétitivité, en capacité à intégrer une acquisition ou à lancer un produit.

Présenter la dette comme une “hygiène” ne suffit pas. Il faut la présenter comme un assurance-vie opérationnelle et un levier de vitesse. Et surtout, proposer un plan qui n’arrête pas l’activité, mais qui réduit le risque progressivement.

Gouvernance : une règle simple pour éviter la rechute

Rembourser une dette sans changer la gouvernance, c’est comme écoper un bateau sans réparer la fuite. La fuite, c’est souvent : arbitrages courts-termistes, absence de standards, manque d’ownership, pression time-to-market sans garde-fous.

Une gouvernance minimale tient sur un principe : pas d’évolution sans critères de maintenabilité. Pas de nouvelle feature sans tests minimum, sans observabilité, sans runbook, sans ownership, sans conformité de base. Cela ne veut pas dire ralentir : cela veut dire industrialiser. Et l’industrialisation accélère.

La dette doit aussi avoir un propriétaire clair, un reporting simple, et une conséquence. Quand une zone dépasse un seuil de risque, on déclenche un plan de fiabilisation. Sinon, le sujet revient tous les ans sous forme de “grand programme”.

Le vrai enjeu : récupérer de la capacité, pas “faire du neuf”

Au final, moderniser le legacy n’est pas une quête esthétique. C’est une stratégie de capacité. Une organisation qui maîtrise sa dette peut livrer plus vite, absorber les chocs, sécuriser son SI, et investir dans l’innovation sans peur.

C’est exactement l’inverse des KPI cosmétiques : on ne cherche pas à raconter une histoire de transformation, on cherche à rendre le système plus fiable et plus changeable. Et cela se fait rarement par une refonte totale. Cela se fait par une série de décisions pragmatiques, pilotées par des mesures, et répétées dans le temps.

La dette technique ne disparaît jamais. Elle se gère. Et c’est une excellente nouvelle : parce que tout ce qui se gère peut s’améliorer — sans arrêter le business.