Migrer un logicielmétier vieillissant

La réponse courte

Un logiciel métier doit être migré quand son éditeur a disparu, que sa technologie n'est plus maintenue ou qu'il bloque toute évolution. La stratégie la plus sûre est une réécriture progressive, centrée sur le cœur du processus plutôt que sur la copie de tous les écrans. Comptez 6 000 à 15 000 € pour la réécriture d'un outil métier, sur devis pour un système complexe.

Les signaux qu'il faut migrer

Un vieux logiciel ne prévient pas avant de devenir un problème. Les signaux qui reviennent chez presque tous nos clients :

• L'éditeur a disparu : société fermée, rachetée, ou support qui ne répond plus. Le jour où le logiciel casse, personne ne peut le réparer.
• La technologie est morte : Windows XP obligatoire, vieux serveur qu'on n'ose plus redémarrer, langage que plus aucun développeur ne pratique.
• La sécurité n'est plus assurée : plus de mises à jour, failles connues non corrigées, mots de passe stockés en clair. Si l'outil traite des données personnelles, c'est aussi un problème de conformité RGPD.
• Les licences coûtent de plus en plus cher : maintenance annuelle qui augmente sans contrepartie, facturation par poste devenue absurde.
• Impossible à faire évoluer : chaque demande de modification reçoit un refus, un délai de six mois ou un devis dissuasif. L'équipe compense avec des fichiers Excel autour du logiciel, ce qui recrée les problèmes décrits dans notre guide sur le remplacement d'Excel par un outil métier.

Un seul de ces signaux mérite une surveillance. Deux ou trois réunis signifient que la question n'est plus « faut-il migrer » mais « quand et comment ».

Réécriture progressive ou big bang

Deux stratégies existent, et elles ne se valent pas.

Le big bang consiste à développer le nouveau logiciel en parallèle, puis à tout basculer un lundi matin : ancien outil éteint, nouveau allumé. C'est simple à raconter et risqué à vivre. Tout repose sur un seul jour : si une fonction critique manque ou si la migration de données a raté un cas, toute l'activité est bloquée. Le big bang ne se justifie que pour de petits outils au périmètre simple et bien connu.

La réécriture progressive remplace le logiciel morceau par morceau. On identifie le cœur du processus, on le reconstruit dans le nouvel outil, on le met en production pendant que l'ancien continue de gérer le reste. Puis on migre le module suivant. À chaque étape, le risque est limité à un périmètre restreint, et l'équipe s'approprie le nouvel outil au fur et à mesure. C'est l'approche que nous recommandons dans la quasi-totalité des projets de développement logiciel sur-mesure.

Le strangler pattern, expliqué simplement

La réécriture progressive porte un nom chez les développeurs : le strangler pattern, du nom du figuier étrangleur qui pousse autour d'un arbre jusqu'à le remplacer entièrement. L'image dit tout :

• Le nouveau logiciel pousse autour de l'ancien, pas à côté dans un projet parallèle qui ne sort jamais.
• Chaque fonctionnalité migrée est définitivement prise en charge par le nouvel outil : les utilisateurs ne font plus l'aller-retour.
• L'ancien logiciel perd ses responsabilités une à une, jusqu'au jour où on peut l'éteindre sans que personne ne s'en aperçoive.

Concrètement, cela demande un point de passage entre les deux systèmes pendant la transition : un export régulier, une synchronisation, ou simplement une règle d'organisation claire (« les devis se font désormais ici, la facturation reste là pour l'instant »). Ce pont temporaire a un coût, mais il est très inférieur au risque d'un big bang raté.

La reprise de données : un lot à part

C'est le chantier le plus sous-estimé des migrations. Une base de données qui a quinze ans contient des doublons, des champs détournés de leur usage d'origine (« on met le numéro de téléphone dans le champ fax depuis 2014 »), des formats de dates incohérents et des enregistrements orphelins. Trois règles pour ne pas transformer ce chantier en naufrage :

• Le chiffrer séparément : la reprise de données n'est pas une ligne du devis de développement, c'est un lot avec son propre périmètre et son propre budget.
• Faire une migration à blanc : migrer une copie des données, comparer les totaux et les cas particuliers avec l'ancien système, corriger, recommencer. La bascule réelle ne doit être que la répétition d'un scénario déjà validé.
• Décider quoi laisser derrière : tout l'historique n'a pas besoin de vivre dans le nouvel outil. Les données mortes peuvent rester consultables dans un export d'archive, ce qui simplifie énormément la migration.

Les risques classiques, et comment les éviter

Les migrations qui échouent échouent presque toujours pour les mêmes raisons :

• Vouloir copier 100 % de l'ancien outil. Après des années d'usage, une partie des écrans ne sert plus à rien. La V1 de remplacement doit couvrir le cœur du processus, pas la totalité des menus. Reproduire l'existant à l'identique, c'est payer pour re-développer des fonctions mortes.
• Migrer sans les utilisateurs. Les personnes qui utilisent le logiciel chaque jour connaissent les cas particuliers qu'aucune spécification ne mentionne. Les impliquer dès le cadrage évite de découvrir en production que « le champ commentaire sert en fait à gérer les urgences ».
• Sous-estimer la période de transition. Pendant quelques semaines ou mois, deux systèmes cohabitent. Sans règle claire sur qui saisit quoi et où, les données divergent et la confiance dans le nouvel outil s'effondre.
• Choisir une technologie exotique. Le nouveau logiciel doit être maintenable dans dix ans. Des fondations éprouvées comme Symfony ou Next.js garantissent qu'on trouvera toujours des développeurs pour le faire évoluer, contrairement à la techno qui vous a coincé la première fois.

Combien coûte la migration d'un logiciel métier

Pour la réécriture d'un outil métier classique (gestion interne, suivi d'activité, planning, facturation), comptez 6 000 à 15 000 €, en cadrant le périmètre de la V1 sur le cœur du processus, comme détaillé dans notre article sur le prix d'une application web sur-mesure. La reprise de données s'ajoute comme un lot séparé, chiffré après un examen de la base existante. Un système complexe (nombreux modules, interconnexions avec d'autres logiciels, fort volume de données) relève d'un devis sur mesure, établi après audit de l'existant. Dans tous les cas, le vrai comparatif n'est pas « migration contre statu quo gratuit » : le statu quo coûte déjà en licences, en temps perdu et en risque de panne définitive.

Votre logiciel métier montre des signes de fin de vie ? Décrivez-nous votre situation, nous vous disons en 24 h par où commencer.