Remplacer un logiciel dont l'éditeur a disparu

Ça vous parle ?

L'éditeur a été racheté et la nouvelle version ne nous convient pas

Plus de mises à jour depuis 3 ans, et des failles de sécurité non corrigées

Le logiciel ne tourne que sur Windows 7 ou un vieux serveur

Impossible d'avoir du support : personne ne décroche

Le format de données est propriétaire, on est piégés

On paye encore une licence annuelle pour un produit abandonné

Votre logiciel tourne encore, mais plus personne n’est derrière

C’est un scénario plus courant qu’on ne le croit. Un logiciel métier installé il y a 10 ou 15 ans, qui rend de bons services. Et puis un jour : l’éditeur ne répond plus au téléphone. Le site web a disparu. Ou pire, l’éditeur a été racheté et la “nouvelle version” est un autre logiciel, incompatible, deux fois plus cher.

Vous êtes piégés : le logiciel tourne, mais sur un système d’exploitation en fin de vie. Les failles de sécurité s’accumulent. Et le jour où le serveur lâche, personne ne sait réinstaller.

Les vraies questions à se poser

Avant de foncer tête baissée, il faut déminer le terrain :

1. Où sont vos données ? C’est LA question critique. Un logiciel client-serveur stocke généralement ses données dans une base SQL (SQL Server Express, MySQL, Firebird). Oui, même en 2026, il y a du Firebird en production. Si vous pouvez accéder à la base, vous pouvez récupérer vos données. Si le format est purement propriétaire (fichiers binaires maison), c’est plus compliqué mais rarement impossible : il faut analyser la structure du fichier.

2. Quelles fonctions utilisez-vous vraiment ? Un logiciel métier de 15 ans a accumulé des dizaines de menus, d’écrans, de rapports. Demandez à vos utilisateurs : sur 50 fonctions, combien en utilisent-ils au quotidien ? La réponse est presque toujours entre 8 et 12.

3. Quelles intégrations existent ? Le logiciel envoie-t-il des données vers votre comptabilité ? Importe-t-il des fichiers d’un autre système ? Ces flux doivent être reproduits dans le nouvel outil.

Ce qu’on fait concrètement

L’inventaire technique d’abord : on identifie la base de données, on teste l’extraction, on liste les fonctions réellement utilisées (pas celles du cahier des charges de 2011).

La reconstruction ne vise pas à cloner l’ancien logiciel. On reconstruit les fonctions essentielles dans une application web moderne, avec une interface propre et une base de données ouverte (PostgreSQL). L’objectif : que vous ne soyez plus jamais verrouillés chez un éditeur.

La migration des données est un projet en soi. On écrit des scripts d’extraction et de transformation qui tournent de manière reproductible. On fait des essais avec vos données réelles, on vérifie les résultats ensemble, et on ne bascule que quand tout est validé.

Mini-cas : remplacement d’un logiciel de gestion de parc immobilier

Une société de gestion immobilière utilisait un logiciel DOS (oui, DOS) depuis 1998, migré ensuite vers Windows XP, puis émulé sur Windows 10. L’éditeur avait cessé son activité en 2014. Le logiciel gérait 400 lots, les appels de charges, les états des lieux.

Extraction de données : base Paradox (format Borland des années 90). On a écrit un script Python pour lire les fichiers .DB et reconstituer les relations entre tables. 98 % des données ont été récupérées proprement. Les 2 % restants (des champs de commentaires tronqués) ont été corrigés manuellement avec l’équipe.

Application livrée en 8 semaines. Le propriétaire peut maintenant accéder à ses données depuis son téléphone, ce qui n’avait jamais été possible en 25 ans.

Questions fréquentes

Comment récupérer nos données si le format est propriétaire ?

Dans la majorité des cas, les données sont stockées dans une base SQL (SQL Server, MySQL, PostgreSQL) ou des fichiers structurés qu'on peut lire. Même les formats propriétaires peuvent souvent être rétro-ingénierés. L'échange découverte, gratuit et sans engagement, inclut une analyse de faisabilité de l'extraction.

Faut-il reproduire 100 % des fonctionnalités ?

Non, et c'est rarement souhaitable. Les logiciels accumulaient des fonctions sur 15 ans, dont beaucoup ne sont plus utilisées. On identifie avec vous les 20 % de fonctions qui couvrent 80 % de vos besoins réels, et on livre ça d'abord. Le reste vient ensuite si nécessaire.

On risque de se retrouver dans la même situation dans 10 ans ?

La différence : vous êtes propriétaire du code source et des données. L'application utilise des technologies standards, le code est versionné dans un dépôt Git avec documentation et scripts de déploiement. Si vous changez de prestataire, la reprise est possible sans dépendre de nous.

Combien de temps pour remplacer un logiciel métier complet ?

Le périmètre initial (les fonctions critiques) se livre en 6 à 10 semaines. Les fonctions secondaires s'ajoutent ensuite dans le cadre du forfait maintenance. On ne vise pas le remplacement total au jour 1, on vise le remplacement fonctionnel.