« Notre éditeur ne répond plus » : les quatre sorties

« Notre éditeur ne répond plus. » Cette phrase arrive rarement seule. Elle vient avec une version qui n'a pas été mise à jour depuis trois ans, un serveur que plus personne n'ose redémarrer, et un calendrier métier qui, lui, n'a pas bougé d'un jour. Le réflexe est de chercher immédiatement le remplaçant. C'est presque toujours l'ordre inverse qu'il faut suivre : sécuriser d'abord ce que vous avez, choisir ensuite par quelle porte sortir.

Quatre situations, une seule phrase

La même formule recouvre quatre situations très différentes, qui n'appellent pas les mêmes premiers gestes.

• L'éditeur a cessé son activité : liquidation, radiation, plus personne à appeler. Votre contrat de maintenance ne vaut plus rien, mais vos licences et vos accès techniques peuvent continuer à fonctionner pendant des années.
• L'éditeur a été racheté. Le produit existe toujours, mais il est en maintenance de convergence : le repreneur ne corrige plus que la sécurité et pousse ses clients vers sa propre plateforme, généralement avec une hausse tarifaire à la clé.
• La fin de vie a été annoncée. Vous avez une date — ce qui en fait la meilleure des quatre situations, parce que vous pouvez planifier.
• Le développeur d'origine est parti. C'est le cas le plus fréquent dans les structures qui ont fait développer un outil interne il y a dix ans : le code existe quelque part, personne ne sait le compiler, et la seule documentation tenait dans la tête d'une personne.

Le point commun n'est pas technique : c'est que la décision vous a échappé. Tant que l'éditeur répondait, le rythme des évolutions se négociait. Il est désormais subi — par un bulletin de sécurité, par un système d'exploitation qui sort du support, par une banque qui change un format de fichier. Vous n'exploitez plus un logiciel : vous attendez de savoir ce qui cassera en premier.

Avant de choisir : trois choses à faire dans la quinzaine

Aucune de ces trois actions ne dépend de la sortie que vous retiendrez, et toutes les trois deviennent nettement plus chères le jour où le système s'arrête.

1. 1

   Reprendre la main sur les données et les sauvegardes

   Obtenez un export complet dans un format lisible, localisez physiquement la base, et identifiez qui détient les comptes administrateurs — hébergement et nom de domaine compris. Puis restaurez une sauvegarde sur une machine séparée et ouvrez l'application. Une sauvegarde jamais restaurée n'est pas une sauvegarde, c'est un fichier.

2. 2

   Lire ce que le contrat dit réellement de la propriété

   Entre une licence d'utilisation perpétuelle et une cession des droits patrimoniaux, il y a un monde : la première vous autorise à utiliser, la seconde à faire modifier par un tiers. S'il existe une clause d'entiercement du code source, vérifiez deux points — que le dépôt a été alimenté récemment, et que le contrat définit un cas de déclenchement. Un dépôt qui date de 2016 vous rend le logiciel de 2016.

3. 3

   Documenter l'existant tant que quelqu'un s'en souvient

   Recensez les processus portés par le système, ses interfaces, ses imports et exports, ses éditions, ses comptes utilisateurs et surtout ses exceptions — l'adhérent traité à part depuis 2019, le barème rattrapé à la main. Cette cartographie est le seul actif qui vaut la même chose dans les quatre sorties.

Sortie 1 — rester et sécuriser

Ne rien remplacer, et transformer un logiciel abandonné en actif géré : figer une version, sortir le serveur de tout réseau ouvert, mettre en place une sauvegarde vérifiée, et faire reprendre la maintenance corrective par un tiers si le code est disponible. Cette sortie n'a rien de valorisant et elle est fréquemment la bonne.

C'est le bon choix quand le logiciel couvre le besoin, qu'aucune évolution réglementaire ou contractuelle n'est attendue dans les deux ans, et que l'obsolescence est technique plutôt que fonctionnelle. Comptez quelques milliers d'euros de mise en sécurité, puis un contrat annuel de maintenance corrective. Ce que vous portez, c'est un risque différé et non traité : chaque année ajoute une couche de dette d'environnement — système non supporté, base de données en fin de vie — et le jour où une évolution devient obligatoire, la marche est plus haute qu'aujourd'hui.

Sortie 2 — migrer vers un progiciel du marché

C'est la sortie que les studios de développement sur mesure présentent le moins volontiers, et c'est la bonne réponse dans un nombre de cas non négligeable. Si le processus est réellement standard — comptabilité, paie, gestion de maintenance, CRM, cycle commande-facture classique — alors votre manière particulière de le traiter n'est pas un avantage, et payer pour la reconstruire revient à payer pour conserver une habitude.

• Un export de données documenté, exécutable par vous, et non une prestation de migration chiffrée le jour où vous partez.
• La capacité à reproduire vos règles par paramétrage — parce qu'à la seconde où la réponse devient « cela demandera un développement spécifique », vous êtes revenu au point de départ, mais dans le produit d'un autre.
• Le coût réel d'intégration de première année, qui dépasse régulièrement le montant de la licence annuelle.
• Un engagement écrit de réversibilité, avec un délai et une liste de livrables.

Le risque que vous prenez n'est pas technique mais organisationnel : vous changez vos processus, pas seulement votre logiciel, et la résistance se manifeste au sixième mois. Vous ne sortez pas non plus de la dépendance, vous en changez — pour une dépendance plus liquide, auprès d'un éditeur qui a de meilleures chances d'exister encore dans dix ans.

Sortie 3 — réécrire sur mesure

La réécriture se justifie quand le logiciel porte une mécanique métier qu'aucun progiciel ne modélise : barème à tranches négocié fournisseur par fournisseur, prorata temporis sur les adhésions en cours d'année, assiette qui exclut certaines familles de produits, arrêté annuel avec régularisation. Un progiciel ne refuse pas ces règles — il les absorbe au prix d'un développement spécifique, qui vous remet en position captive, avec cette fois une licence à payer en plus.

Le coût se compte en centaines de jours, et le prix n'est pas le vrai risque. Le vrai risque, c'est le big bang : douze à dix-huit mois sans rien en production, un cahier des charges qui vieillit pendant qu'on le développe, et des utilisateurs qui découvrent l'outil en recette. Si vous choisissez cette sortie, achetez deux choses au contrat — le code source et la documentation remis, et une équipe projet nommée.

Sortie 4 — découper et remplacer par lots

L'hybride : le système existant reste en service et on lui retire un processus complet à la fois, le nouveau lisant la base de l'ancien pendant la transition. Le premier processus part en production en semaines et non en trimestres, et chaque lot referme une part du risque. C'est le montage retenu pour le groupement lyonnais de plus de 60 sociétés associées dont nous avons refondu le système de gestion : les fenêtres de déclaration et l'arrêté annuel ne pouvaient pas être suspendus le temps d'une bascule.

Le coût total est comparable à celui d'une réécriture, mais étalé. Ce que vous portez, c'est la période de double exploitation : interfaces temporaires, données à deux endroits, et une équipe permanente qui travaille dans deux outils pendant plusieurs mois. Ce coût est réel et il est systématiquement nié dans les plannings. Budgétez-le, nommez-le, et donnez-lui une date de fin.

Le comparatif que personne ne vous met par écrit

S'il faut retenir une seule chose : le pire choix n'est aucun des quatre. C'est de rester exactement où vous êtes sans le nommer — un logiciel que personne ne maintient, un code que personne ne possède, un sujet évoqué à chaque comité et tranché à aucun. Les quatre sorties ont un prix. L'attente aussi, à ceci près qu'elle n'apparaît sur aucune ligne budgétaire.