« On n’a pas le budget pour refaire ça. » Cette phrase revient dans presque toutes les réunions budgétaires sur une application legacy. Elle sonne, en effet, comme une décision raisonnable. En réalité, elle cache une dette technique invisible. Personne ne la voit sur un tableau de bord. Cependant, elle s’accumule chaque mois. Ne pas décider, c’est donc décider quand même — sauf que cette décision-là n’a pas de ligne dans le budget.
Le développeur qui connaît le système est déjà parti
Chaque application legacy a eu, un jour, un développeur qui la connaissait par cœur. Souvent, il est parti depuis longtemps. Sa connaissance du système est ainsi partie avec lui, et il ne reste que du code sans contexte. À la prochaine panne critique, quelqu’un doit déchiffrer une logique qu’il n’a jamais vue. Ce travail coûte donc plus cher, prend plus de temps, et le risque d’erreur augmente d’autant.
Les dépendances obsolètes : la dette technique invisible qui explose en sécurité
Une bibliothèque jamais mise à jour n’est pas un problème théorique. En effet, selon le rapport OSSRA 2025 de Black Duck, 86 % des bases de code commerciales analysées contiennent des composants open source vulnérables. Par ailleurs, 81 % présentent des failles à risque élevé ou critique, et neuf composants sur dix accusent plus de quatre ans de retard. Ce n’est donc pas une hypothèse : c’est une question de moment. Et quand la faille est exploitée, le coût n’est plus technique. Il devient réputationnel, parfois même contractuel avec vos propres clients.
Les bugs non corrigés ne restent jamais stables
Un bug qu’on ne corrige pas ne reste pas isolé. Il se propage, car chaque nouvelle fonctionnalité posée sur une base fragile s’appuie, en partie, sur ce même défaut. La surface de risque grandit ainsi à chaque livraison, même quand l’équipe ne touche pas directement à la zone concernée. C’est pourquoi un audit du legacy commence toujours par cartographier les zones à risque, et non par traiter les demandes dans leur ordre d’arrivée.
Vous n’avez pas suivi notre article sur la migration WinDev vers .NET ? Il aborde la même logique : cartographier avant de trancher, pas l’inverse.
Le coût que personne ne met dans un slide
Au-delà des risques techniques, il y a un coût plus discret. C’est le temps que vos équipes passent à contourner les limites de l’outil, plutôt qu’à avancer sur leur cœur de métier. Cependant, ce temps ne figure dans aucun tableau de reporting. Il se voit seulement dans la vélocité qui baisse, projet après projet, sans qu’on sache toujours pourquoi.
Chiffrer la dette technique invisible avant de décider
La bonne question n’est donc pas « faut-il tout refaire ? », mais « que coûte l’inaction, aujourd’hui ? ». Chez Mahé Technologies, on commence systématiquement par cet état des lieux. Cartographie des modules critiques, âge des dépendances, niveau de dépendance aux compétences internes, temps perdu en contournements : tout est passé en revue. Cette photo de l’existant permet ensuite de comparer deux chiffres concrets : le coût du projet, et le coût de l’inaction. Ainsi, la décision ne se prend plus à l’instinct.
Dans certains cas, néanmoins, la conclusion est de tout refaire. Dans d’autres cas, elle est de sécuriser l’existant sans réécriture totale. Mise à jour ciblée des dépendances critiques, documentation du système par l’équipe qui le reprend, correction priorisée des bugs à fort impact : voilà à quoi ça ressemble concrètement.
Le projet a un devis. L’inaction, elle, n’en a pas — jusqu’au jour où la facture arrive d’un coup. Vous voulez connaître l’état réel de votre application legacy avant de décider ? On peut regarder ça ensemble.
