Quand faut-il remplacer un logiciel existant — et quand ne faut-il pas ?

Quelque part dans l'organisation tourne un système qui est là depuis des années. Il est lent, il est laid, et plus personne ne sait vraiment comment il fonctionne — peut-être sauf un employé qui a essayé de partir à la retraite trois fois. Mais le système tourne. Les commandes arrivent. Les factures sortent.

La question de savoir s'il faut remplacer ce système est l'une des décisions les plus difficiles en IT, parce qu'agir trop tôt comme trop tard coûte de l'argent. Les entreprises qui remplacent trop tôt gaspillent du capital dans une migration qui n'était pas nécessaire. Les entreprises qui remplacent trop tard paient pendant des années une taxe invisible en perte de productivité, en dette technique et en opportunités manquées.

Voici un cadre honnête pour prendre la décision.

Les signaux qui disent : remplacez-le

Le système crée sa propre charge de travail

Si les employés passent structurellement plus de deux heures par jour sur des solutions de contournement pour le système — saisie manuelle de données entre systèmes, fichiers Excel comme couche intermédiaire, copier-coller qui devrait se faire automatiquement — le système n'est plus un outil facilitateur. Il est devenu une partie de la charge de travail.

Calculez cela concrètement. Quatre employés qui passent chacun deux heures par jour sur des solutions de contournement : c'est huit heures-homme par jour, quarante par semaine, plus de deux mille par an. À un niveau de coût moyen de 40 € de l'heure, c'est 80 000 € par an en coûts systèmes cachés — avant les coûts des erreurs générées par le travail manuel.

L'intégration avec les outils modernes n'est plus possible

Pratiquement chaque processus commercial touche aujourd'hui à plusieurs systèmes : CRM, logiciel de comptabilité, plateforme e-commerce, logistique, outils de communication. Si votre système legacy n'a pas d'API, ou ne parle qu'un protocole obsolète que les outils modernes ne prennent pas en charge, vous payez des coûts d'intégration disproportionnellement élevés — ou vous acceptez des silos d'information qui font obstacle à de meilleures prises de décisions.

Ce point est particulièrement critique lorsque vous grandissez. Une entreprise de vingt personnes peut peut-être vivre avec une synchronisation manuelle. Une entreprise de cent personnes ne peut pas.

Le fournisseur a abandonné le système

Les logiciels en fin de vie représentent un risque sous-estimé. Si le fournisseur ne publie plus de mises à jour de sécurité, vous exécutez un système avec des vulnérabilités connues qui ne sont pas corrigées. Pour les systèmes qui traitent des données clients, c'est aussi un risque RGPD. Les assureurs commencent à poser des questions sur les logiciels en fin de vie dans leurs polices cyber.

Un système sans support actif du fournisseur est techniquement en fin de vie. La question est seulement combien de temps il continuera à fonctionner avant que quelque chose d'inattendu le fasse tomber.

Une seule personne est la seule à le comprendre

On appelle cela dans les couloirs le « bus factor un » : si cette personne est renversée par un bus, le système devient incompréhensible. Ce n'est pas un risque hypothétique — c'est un risque de continuité qui est signalé lors des due diligences par les acheteurs et investisseurs.

Les systèmes sans documentation, avec du code qui n'est lisible que par le constructeur original, deviennent chaque année plus difficiles et plus coûteux à maintenir. Chaque ajustement coûte plus que le précédent.

Les problèmes de sécurité ne sont structurellement pas solubles

Parfois, les vulnérabilités ne sont pas des bugs logiciels mais des problèmes architecturaux. Un système conçu sans couche d'authentification, qui stocke des mots de passe en clair, ou qui tourne sur un environnement serveur obsolète ne prenant pas en charge les standards de sécurité modernes : ce ne sont pas des problèmes que vous résolvez avec un patch. Ce sont des problèmes qui nécessitent une nouvelle conception.

Les signaux qui disent : attendez

Le système fonctionne — juste pas joliment

Il y a une différence entre un système qui cause des problèmes et un système qui est vieux mais qui fonctionne. Un tableau de bord laid n'est pas une raison de remplacer un système. Un flux de travail lent mais fiable n'est pas une raison de remplacer un système. La question est toujours : que coûte le système dans son état actuel, et que coûte son remplacement ? Si les coûts du système sont inférieurs aux coûts de migration plus les risques d'une transition, attendre est le choix judicieux.

Le retour sur investissement dépasse trois ans

Une migration logicielle coûte du temps, de l'argent et une perturbation opérationnelle. Si les économies annuelles d'un nouveau système sont inférieures à un tiers des coûts de migration, le business case est faible. Trois ans est une règle empirique — pour les entreprises à croissance rapide, deux ans peut être acceptable, pour les organisations stables, quatre ans peut encore être raisonnable. Mais si le retour sur investissement est de cinq ans ou plus, il y a de bonnes chances que l'organisation ait déjà changé avant cela.

Il n'y a pas de capacité interne pour la transition

Une migration n'est pas seulement un projet IT. Elle demande l'implication des personnes qui utilisent le système quotidiennement, pour définir les exigences, tester la nouvelle solution et supporter les inconforts initiaux. Si l'organisation traverse actuellement une autre grande transition, si des employés clés sont surchargés, ou s'il est impossible d'organiser une appropriation interne, la probabilité d'une migration réussie est faible — quelle que soit la qualité du nouveau système.

Le juste milieu : envelopper le système legacy

Il y a une troisième option souvent négligée : ne pas remplacer le système existant, mais construire une couche moderne autour de lui.

On appelle cela dans le monde de l'architecture logicielle une approche « strangler fig » — d'après le figuier qui entoure lentement un autre arbre et le prend en charge. Vous construisez de nouvelles fonctionnalités dans un système moderne, et vous vous assurez que ce système communique via une API avec le système legacy. Avec le temps, de plus en plus de fonctions migrent vers la nouvelle couche, jusqu'à ce que l'ancien système fasse si peu qu'il peut être éteint en toute sécurité.

C'est particulièrement utile lorsque :

• Le système legacy dispose de modèles de données centraux stables qui valent la peine d'être conservés
• Un remplacement complet est trop risqué opérationnellement
• Vous voulez moderniser étape par étape sans une migration « big bang »

L'inconvénient : une couche API sur un système legacy mal conçu est temporairement du plomb recyclé. Cela donne de l'air, mais ne résout pas les problèmes d'architecture sous-jacents.

Deux stratégies de migration comparées

Big bang : tout en même temps

Vous construisez un système entièrement nouveau, migrez toutes les données à une date fixée, et éteignez l'ancien système. Avantage : vous ne payez pas pendant des années pour deux systèmes côte à côte. Inconvénient : le risque est élevé. Si le nouveau système ne fonctionne pas bien à la date de lancement, vous n'avez pas de solution de repli.

Les migrations big bang fonctionnent mieux pour les systèmes plus petits, les processus bien documentés et les organisations qui peuvent absorber la perturbation opérationnelle.

Strangler fig : remplacement progressif

Vous remplacez le système module par module, le nouveau système prenant progressivement en charge les fonctions de l'ancien. Avantage : moins de risque par phase, courbe d'apprentissage continue, rendement plus rapide sur les sous-systèmes. Inconvénient : coûts totaux plus élevés, délai plus long, complexité d'exploiter deux systèmes côte à côte.

Pour les grands systèmes critiques pour l'entreprise, l'approche strangler fig est presque toujours le choix le plus judicieux — même si les coûts totaux sont plus élevés.

La décision

Le remplacement est le bon choix si deux ou plusieurs des signaux « remplacez-le » sont présents ET si le business case sur trois ans est positif. Attendre est le bon choix si la douleur opérationnelle est gérable et que l'organisation n'a pas la capacité de migration maintenant.

Ce qui n'est jamais le bon choix : ne rien décider parce que la décision est difficile. Chaque année qu'un système legacy problématique continue de tourner, les coûts de la dette technique s'accumulent. Cette dette sera payée un jour — la question est seulement quand, et dans quelles circonstances.