Système legacy : le garder, le moderniser ou le remplacer ? Le guide du fondateur non technique

Un système legacy n’est pas une question d’âge, c’est une question de risque. Comment diagnostiquer le vôtre en quatre questions et choisir entre garder, encapsuler, moderniser par étapes ou remplacer.

L’an dernier, nous avons parlé avec le COO d’une entreprise de distribution de l’intérieur de l’État de São Paulo, 40 salariés, opération rentable. Toute la facturation de l’entreprise passait par un système qu’un développeur freelance avait construit en 2018. Le développeur est parti en 2021. Depuis, personne n’a modifié une ligne. Quand Pix, le réseau de paiement instantané brésilien, a changé une règle de rapprochement, l’équipe s’est mise à corriger les écritures à la main, tous les jours, parce que toucher au code était jugé trop risqué. Le système fonctionnait. Et il commandait l’entreprise. C’était un système legacy dans tous les sens qui comptent.

Un système legacy, ce n’est pas seulement le mainframe bancaire qui tourne sous COBOL depuis 1985. C’est aussi le logiciel vieux de sept ans que plus personne ne sait modifier en sécurité. Si vous avez fondé ou dirigez une entreprise de 5 à 50 personnes, votre version du problème ressemble bien plus au distributeur qu’à la banque.

Ce guide définit ce qu’est vraiment un système legacy, montre comment il apparaît dans une petite entreprise, ce que coûte le fait de vivre avec, et organise la décision qui compte : garder, encapsuler, moderniser par étapes ou remplacer.

Ce qu’est un système legacy

Un système legacy est un logiciel qui reste en service parce que l’activité en dépend, mais dont la technologie, l’architecture ou l’absence de documentation rendent toute modification risquée et coûteuse. La partie importante de cette définition est la seconde moitié. L’âge n’est pas le critère. Le risque, oui.

Un système de 15 ans, bien documenté, testé, connu à fond par deux personnes, n’est pas legacy au sens qui compte. Une app de 3 ans bricolée sur une plateforme no-code, sans documentation, dont l’unique auteur a quitté l’entreprise, est profondément legacy. Le terme décrit une relation entre le système et votre capacité à le changer, pas une date de naissance.

Le test pratique tient en une question : si l’activité avait besoin que ce système change d’ici la fin du trimestre, quelqu’un pourrait-il le faire avec confiance ? Si la réponse passe par un soupir, vous avez un système legacy.

Il vaut la peine de séparer le concept d’un proche voisin : la dette technique est l’ensemble des raccourcis accumulés dans un système que quelqu’un maintient encore. Le système legacy est l’étape suivante, quand la capacité de maintenir s’est perdue. Toute entreprise porte de la dette technique ; toute entreprise ne porte pas un legacy. Nous avons écrit un guide séparé sur comment diagnostiquer la dette technique avant qu’elle n’atteigne ce stade.

Comment un système devient legacy dans une petite entreprise

Dans les entreprises que nous servons, de 5 à 50 personnes, le legacy ne naît presque jamais d’une mauvaise décision. Il naît de trois schémas, tous rationnels sur le moment.

Le freelance qui est parti. Le schéma du distributeur. Un développeur compétent construit le système, l’entreprise grandit dessus, le développeur passe à autre chose. Le code peut même être bon. Sans importance : personne d’autre ne peut lire les décisions qui ne vivent que dans sa tête. L’entreprise n’a pas perdu un prestataire, elle a perdu l’accès à son propre système. Ce cas est si courant que nous lui avons dédié un guide entier : le bus factor, le risque qu’un seul dev porte tout le codebase.

Le no-code qui s’est ossifié. Bubble, Glide, un tableur truffé de macros, des Zapier empilés. D’excellents outils pour valider ; de très mauvais choix à oublier en production pendant quatre ans. Le coût de la plateforme grimpe avec l’usage, les contournements s’accumulent, et un jour « l’automatisation provisoire » est devenue le système d’exploitation de l’entreprise, et personne ne se souvient pourquoi la règle de la cellule G14 existe.

L’ERP customisé de 2018. L’entreprise a engagé un cabinet pour adapter un ERP du commerce. Le cabinet a livré, puis a quitté la scène. Les customisations n’ont jamais été documentées, la version de l’ERP a été gelée (la mettre à jour les casserait), et désormais l’éditeur facture cher pour toucher à ce que l’entreprise elle-même a payé pour construire.

Dans les trois schémas, la séquence est la même : le système était la bonne décision au moment où il a été fait, l’activité a changé, et la capacité à faire évoluer le système n’a pas suivi. Legacy est le nom de ce décalage.

Ce que coûte la vie avec un legacy

L’argument pour ne pas y toucher est toujours le même : « ça marche ». C’est vrai, et c’est pour cela que le coût du legacy trompe. Il n’apparaît pas comme une facture. Il se répartit sur quatre lignes que personne n’additionne.

La taxe d’intégration. Chaque nouvel outil doit parler à l’ancien système, et n’y parvient pas. Alors la conversation devient des gens : quelqu’un exporte un CSV, quelqu’un ressaisit, quelqu’un vérifie. Chez le distributeur, c’était trois heures par jour de rapprochement manuel. Douze mille reais par mois de salaire à faire le travail qu’une intégration ferait, sans apparaître dans aucun rapport comme un coût du système.

La taxe de recrutement. Les bons développeurs évitent les stacks mortes et le code sans documentation. Quand vous décidez enfin d’embaucher quelqu’un pour s’occuper du système, vous découvrez que le marché facture une prime pour hériter d’un problème, quand il accepte d’en hériter.

Le risque concentré. La question que nous posons à chaque dirigeant dans cette situation : que devient l’activité si le système tombe un vendredi et reste hors service 48 heures ? Si la réponse est « tout s’arrête », le système est un point unique de défaillance sans plan de reprise. Ce risque ne coûte rien par mois. Il coûte tout, une fois.

Le coût d’opportunité. La fonctionnalité qu’on ne peut pas lancer, le canal de vente qu’on ne peut pas intégrer, le rapport demandé par l’investisseur qui prend une semaine à assembler à la main. C’est le coût le plus difficile à mesurer et presque toujours le plus élevé.

Le schéma n’est pas réservé aux petites entreprises. Le GAO, la cour des comptes américaine, audite depuis des années les systèmes legacy du gouvernement fédéral et a trouvé des systèmes critiques de plus de 50 ans, qui consomment l’essentiel du budget informatique juste pour rester debout. L’échelle est différente ; la mécanique, l’argent qui part dans le maintien plutôt que dans l’évolution, est identique.

Pour creuser la partie récurrente de cette facture, notre guide du coût de maintenance d’un logiciel détaille ce qu’on paie après le lancement.

Le diagnostic : quatre questions avant de choisir une voie

Vous n’avez pas besoin d’un audit de six mois pour connaître la taille du problème. Vous avez besoin de réponses honnêtes à quatre questions. Convoquez l’équipe des opérations, pas seulement la technique, et répondez par écrit.

1. Le système sert-il le processus, ou le processus se contorsionne-t-il pour servir le système ? Comptez les contournements : tableurs parallèles, ressaisie, « ça, on le règle sur WhatsApp ». Chaque contournement, c’est le processus qui cède. Jusqu’à deux, vivez avec. Au-delà, le système dicte la façon dont l’entreprise travaille.

2. Combien de personnes peuvent modifier le système en sécurité ? Deux ou plus : vous avez de la maintenance. Une : vous avez un risque à échéance indéterminée. Zéro : vous n’avez pas un système, vous avez une boîte scellée dont dépend l’opération.

3. Que se passe-t-il s’il tombe pendant 48 heures ? S’il existe un contournement manuel raisonnable, le risque est gérable. Si l’entreprise cesse de facturer, cette réponse fixe l’urgence indépendamment des trois autres.

4. Combien coûte-t-il par an à maintenir en vie, taxes invisibles comprises ? Licences et serveur, plus les heures de travail manuel qu’il génère, plus la prime payée pour le support. La plupart des dirigeants n’ont jamais fait la somme. La somme tranche généralement la conversation.

Deux mauvaises réponses ou plus : continuez à lire. Les quatre sereines : votre système est vieux, pas legacy. Gardez ce guide pour dans deux ans.

Les quatre voies : garder, encapsuler, moderniser par étapes, remplacer

Chaque prestataire consulté recommandera la voie qu’il vend. Le cabinet d’intégration recommande d’intégrer, le studio de réécriture recommande de réécrire, le vendeur d’ERP recommande son ERP. Aucune des quatre voies n’est juste en général. Chacune est juste pour un diagnostic.

Garder, délibérément. Si le système est stable, que le risque se concentre sur les personnes plutôt que sur la technologie, et que l’activité n’exige pas de changements fréquents, la bonne réponse peut être de ne pas toucher à l’architecture et de n’attaquer que le risque : documenter ce qui existe, garantir des sauvegardes et un environnement de reprise testés, et avoir plus d’une personne (interne ou partenaire) capable d’opérer le code. C’est la voie la moins chère et la plus sous-estimée, parce qu’aucun prestataire ne la défend.

Encapsuler et intégrer. Le système reste le moteur, mais cesse d’être le mur. On construit une couche par-dessus, généralement des API ou de petits services autour, qui laisse les nouveaux outils lui parler sans que personne ne touche à ses entrailles. Cela règle la taxe d’intégration sans le risque d’un changement de moteur. La limite : l’encapsulation ne rajeunit pas le noyau. Si le noyau doit changer souvent, cela ne fait qu’acheter du temps, ce qui, dans bien des cas, est exactement ce qu’on veut acheter.

Moderniser par étapes. Remplacer le système morceau par morceau, en commençant par les zones de plus forte friction, l’ancien et le nouveau cohabitant pendant la transition. C’est le motif que Martin Fowler a baptisé strangler fig, le figuier étrangleur qui pousse autour de son hôte jusqu’à le remplacer. La vertu, c’est le risque dilué : chaque étape livre de la valeur et peut être arrêtée sans désastre. Le prix, c’est la gestion : cohabiter avec deux systèmes exige une discipline de périmètre, et les projets sans propriétaire clair dégénèrent en trois systèmes.

Remplacer d’un coup. La réécriture complète. Il existe des cas où c’est la bonne voie : la plateforme va être abandonnée, le coût du maintien a dépassé celui de la refonte, ou la question 3 du diagnostic a répondu « tout s’arrête » sans contournement. Mais c’est la voie la plus risquée des quatre, et elle a tendance à arriver sur la table trop tôt, emballée comme inévitable. Avant de signer toute proposition de réécriture, lisez notre guide sur pourquoi la réécriture logicielle est presque toujours la mauvaise question, il existe précisément pour ce moment-là.

La règle pratique que nous utilisons avec nos clients : commencez par la voie la moins chère qui règle le risque pointé par le diagnostic, pas par la plus complète. On peut monter d’un cran ensuite ; redescendre coûte cher.

L’erreur la plus chère : traiter la décision comme technique

Le piège final n’est pas dans les voies, il est dans qui décide. Les dirigeants non techniques ont tendance à déléguer cette décision entière « à qui s’y connaît », et qui s’y connaît porte presque toujours un biais : le dev interne préfère réécrire (personne ne rêve de maintenir le code d’un autre), le prestataire préfère le projet le plus gros, le cabinet préfère l’outil maison.

La décision sur un système legacy est une décision business avec des intrants techniques, de la même famille que build vs buy et qu’embaucher en interne ou travailler avec un partenaire. Le diagnostic en quatre questions est délibérément non technique parce que la personne qui doit y répondre est celle qui ressent le coût : vous. Le rôle du partenaire technique est de présenter des options avec des prix et des risques honnêtes dans chaque voie, pas de choisir la destination.

C’est le genre de conversation qui sépare un partenaire d’un fournisseur : le partenaire montre l’arbitrage, le fournisseur montre le devis.

Questions fréquentes

Qu’est-ce qu’un système legacy ?
C’est un logiciel qui reste en service parce que l’activité en dépend, mais dont la technologie, l’architecture ou l’absence de documentation rendent les modifications risquées et coûteuses. Le critère n’est pas l’âge du système, c’est la capacité (perdue) de le changer en sécurité.

Qu’est-ce qu’un programme legacy ?
Le même concept au niveau d’une application précise : un programme encore en usage, mais que personne ne peut mettre à jour en sécurité, faute de documentation, à cause d’une technologie abandonnée, ou parce que celui qui l’a construit n’est plus disponible.

Qu’est-ce qu’un modèle legacy ?
Le terme apparaît dans deux sens : un ancien modèle de données que les nouveaux systèmes doivent respecter pour parler au legacy, et, plus récemment, d’anciennes versions de modèles d’IA maintenues en production. Dans les deux cas, la logique est celle du système legacy : quelque chose d’ancien qui reste parce que le remplacer coûte plus cher que de vivre avec, jusqu’au jour où ce n’est plus vrai.

Un système legacy est-il toujours mauvais ? Quand vaut-il la peine de le remplacer ?
Non. Un système ancien, stable et qui sert le processus est un actif, pas un problème. Il faut agir quand le diagnostic montre un risque concentré (une ou zéro personne capable de le maintenir), des contournements qui se multiplient ou un coût annuel invisible supérieur à celui de la modernisation. Et le remplacement d’un coup est la dernière voie à considérer, après garder, encapsuler et moderniser par étapes.