Quand l'éditeur ferme la porte et part avec la clé
Un mardi matin, un e-mail de trois lignes. « Nous vous informons que la solution X ne fera plus l'objet de mises à jour à compter du 31 décembre. » Signature automatique, pas de numéro de téléphone, pas de contact nommé. Voilà comment commence, la plupart du temps, l'une des séquences les plus stressantes de la vie d'une PME.
Parce que ce logiciel-là, celui dont plus personne ne veut s'occuper, il fait tourner la facturation. Ou les stocks. Ou le planning des quinze techniciens qui partent en tournée chaque matin. Il contient douze ans d'historique client, les tarifs négociés, les références croisées que personne n'a jamais documentées ailleurs. Et il tourne sur un serveur que l'informaticien du coin regarde avec méfiance depuis deux ans.
Autant le dire tout de suite : ce n'est pas un projet informatique. C'est un sujet de continuité d'exploitation. La nuance n'est pas cosmétique, elle change la façon dont on priorise, dont on budgète et dont on choisit qui accompagne l'opération.
Ce qui suit propose une méthode de sortie en cinq temps, de l'audit de l'existant jusqu'à la décommission de l'ancien système. Avec, au passage, les pièges juridiques et techniques qui coûtent le plus cher quand on les découvre trop tard.
Reconnaître un logiciel en fin de vie avant qu'il ne soit trop tard
Les signaux officiels, ceux qu'on ne peut pas rater
Annonce d'End of Life, End of Support, arrêt de la commercialisation aux nouveaux clients. Rachat de l'éditeur par un concurrent qui a déjà sa propre gamme. Ou cette pratique devenue courante : la bascule forcée vers l'offre SaaS maison, présentée comme une modernisation, souvent accompagnée d'une multiplication du coût annuel par deux ou trois.
Ces signaux-là ont un mérite. Ils sont datés. On sait combien de temps il reste.
Les signaux silencieux, beaucoup plus fréquents
Ce sont les plus dangereux, justement parce qu'ils ne déclenchent aucune alerte. Les correctifs s'espacent. La roadmap, qui affichait fièrement trois versions à venir, n'a pas bougé depuis dix-huit mois. Le support met quinze jours à répondre, puis vingt, puis renvoie vers une FAQ qui date de 2019.
Le forum communautaire s'éteint doucement. L'équipe technique fond, on le devine aux profils LinkedIn qui changent d'employeur. La documentation n'évolue plus. Et puis, un jour, un détail : l'application refuse de s'installer sur la dernière version de Windows Server. Ou elle réclame une version de PHP que l'hébergeur ne propose plus. Ou l'interface s'affiche de travers sur les navigateurs récents.
Chacun de ces signes, pris isolément, se laisse ignorer. Ensemble, ils racontent une histoire assez claire.
Une grille de décision simple
Reste la vraie question : on tient encore dix-huit mois, ou on lance la sortie maintenant ?
Quatre critères permettent de trancher sans se raconter d'histoires. Le risque de sécurité d'abord : le logiciel est-il exposé au réseau, traite-t-il des données personnelles, reçoit-il encore des correctifs ? La dépendance matérielle ensuite : tout repose-t-il sur une machine unique, non réinstallable ? La conformité, qui devient un sujet dès que la donnée est sensible. Et enfin le coût de maintien, qui grimpe de façon insidieuse, entre les contournements manuels et les interventions d'urgence.
Quand trois critères sur quatre virent au rouge, la discussion est close.
Évaluer le risque réel avant de bouger quoi que ce soit
Sécurité et conformité
Un logiciel qui ne reçoit plus de correctifs devient, mécaniquement, une porte d'entrée. Les failles publiées restent ouvertes. Les scanners automatisés qui balaient internet en permanence ne font pas dans le sentiment.
Le point que beaucoup de dirigeants découvrent tard : le RGPD impose une obligation de sécurité du traitement au responsable de traitement, c'est-à-dire à l'entreprise. Pas à l'éditeur. Que celui-ci ait disparu, fusionné ou déposé le bilan ne change rien à la responsabilité. Ajoutons les obligations d'archivage légal et les durées de conservation, qui supposent que les données restent lisibles, et pas seulement stockées quelque part sur une bande.
Le risque d'exploitation, plus prosaïque mais plus violent
Le serveur tombe un jeudi soir. On ressort le CD d'installation, et là, plusieurs scénarios, tous désagréables. La licence est liée à une empreinte matérielle qui n'existe plus. La clé d'activation devait être validée en ligne sur un serveur éteint depuis deux ans. Le support qui pouvait régénérer une clé ne répond plus.
Il arrive aussi qu'une application entière tienne sur un poste unique, sous le bureau de quelqu'un, avec un partage réseau bricolé. Ça se voit encore. Souvent.
Le vrai coût de ne rien faire
Le statu quo paraît gratuit. Il ne l'est jamais.
Il se paie en contournements manuels, en ressaisies d'un outil à l'autre, en exports Excel retravaillés chaque mois par une personne qui y consacre deux jours. Il se paie en retards, en erreurs de saisie, en non-conformité potentielle. La dette technique, à ce stade, a changé de nature : elle est devenue une dette d'exploitation, qui ponctionne du temps de travail réel, tous les mois, sans ligne budgétaire dédiée.
Mettre ce coût noir sur blanc est souvent le déclic qui débloque la décision.
Première urgence absolue : sécuriser l'accès aux données
Avant de choisir une nouvelle solution, avant même de consulter le moindre prestataire, il y a une chose à faire. Et elle ne souffre aucun report.
Ce qu'il faut mettre à l'abri, tout de suite
Une sauvegarde froide complète du serveur et de la base, stockée hors du système. La documentation d'installation, si elle existe encore, y compris les vieux PDF traînant dans un dossier réseau. Les clés de licence, les comptes administrateurs, les mots de passe applicatifs.
Idéalement, une machine virtuelle figée : une image complète du serveur, capable de redémarrer des années plus tard sur n'importe quel hyperviseur. C'est l'assurance vie du projet. Et des dumps de base à un instant T, datés, vérifiés, dont on aura testé la restauration au moins une fois. Une sauvegarde jamais restaurée n'est pas une sauvegarde, c'est une hypothèse.
Où vivent réellement les données
Une erreur classique consiste à croire que tout se trouve dans la base. Rarement le cas.
Les données se répartissent entre la base relationnelle, des fichiers plats posés dans des répertoires, des pièces jointes sur disque référencées par un chemin absolu, parfois des blobs encapsulés directement en table. Sans oublier les index de recherche, les historiques d'audit et, point souvent négligé, le paramétrage métier stocké dans des tables de configuration. Ce paramétrage, c'est douze ans de règles de gestion affinées. Le perdre, c'est repartir de zéro sur la logique métier.
Formats fermés et bases propriétaires
C'est là que ça se corse. Les logiciels métier anciens s'appuient sur un éventail de technologies dont certaines ont disparu des radars : Paradox, dBase, Interbase, Access, Btrieve, Pervasive, FoxPro, HyperFileSQL. Et parfois des formats maison, développés en interne, documentés nulle part.
Plusieurs voies d'extraction existent. Les pilotes ODBC historiques, quand on arrive encore à les installer sur une machine compatible. Des outils tiers spécialisés, dont certains sont maintenus par des passionnés depuis vingt ans. Le reverse engineering du schéma, plus long, mais faisable dès lors qu'on dispose de la base et d'un peu de méthode. Et, en dernier recours, l'export via l'interface applicative elle-même, écran par écran, ce qui n'est ni élégant ni rapide, mais reste préférable à la perte.
Un point à garder en tête : la faisabilité de l'extraction doit être validée avant de signer quoi que ce soit sur la solution cible. Découvrir en cours de projet qu'une table est illisible transforme un planning en fiction.
Quand l'éditeur ne répond plus du tout
Le cadre juridique est plus favorable qu'on ne le croit. Les données appartiennent à l'entreprise, pas à l'éditeur. Le RGPD consacre un droit à la portabilité pour les données personnelles. Et beaucoup de contrats comportent une clause de réversibilité, parfois oubliée, qui oblige le prestataire à restituer les données dans un format exploitable.
Certains contrats prévoient même un séquestre de code source auprès d'un tiers de confiance, activable en cas de défaillance de l'éditeur. C'est rare, mais ça se vérifie en dix minutes de relecture.
En cas de liquidation judiciaire, le mandataire devient l'interlocuteur. Il n'a aucun intérêt à bloquer l'accès aux données de clients qui, par ailleurs, figurent souvent au passif. Une demande écrite, argumentée, aboutit plus souvent qu'on ne l'imagine.
Reste un principe : accéder à ses propres données, sur un serveur dont on est propriétaire, avec une licence acquise, ne pose pas de difficulté juridique particulière. Contourner une protection technique, en revanche, mérite un avis avant de se lancer.
Cartographier l'existant : l'audit qui évite les catastrophes
Inventaire fonctionnel : ce que le logiciel fait vraiment
Attention, nuance importante. Il ne s'agit pas de lister ce que la brochure commerciale promettait en 2011. Il s'agit de documenter les usages réels.
Trois catégories émergent toujours. Les fonctions utilisées quotidiennement, que tout le monde connaît et qui figureront naturellement au cahier des charges. Les fonctions utilisées une fois par an, et celles-ci sont perfides : la clôture, le bilan, l'inventaire annuel, la campagne saisonnière. Personne n'y pense en mars. Tout le monde s'en souvient en décembre, quand le nouvel outil ne sait pas faire. Et enfin les fonctions mortes, présentes dans les menus, plus jamais ouvertes depuis six ans, qu'il serait absurde de redévelopper.
Inventaire des flux
Un logiciel métier ne vit jamais seul. Il échange avec la comptabilité, parfois via un export FEC, parfois via un fichier texte au format négocié en 2014. Avec l'EDI des grands comptes. Avec la caisse, les automates de production, les balances, les imprimantes d'étiquettes qui ne parlent qu'un dialecte propriétaire.
Ajoutons le site e-commerce, les remises bancaires, les fichiers transporteurs, les téléversements vers les organismes de tutelle. Chacune de ces interfaces représente un chantier à part entière. Les oublier au chiffrage, c'est garantir un dépassement.
Les usages non documentés, là où tout se joue
Voici le point que l'expérience terrain place tout en haut de la liste.
Dans chaque entreprise, il existe une couche invisible : des exports Excel maison, des macros écrites par un ancien salarié parti en 2017, des requêtes SQL enregistrées dans un fichier texte sur le bureau de la comptable. Des champs détournés de leur usage d'origine, parce qu'il manquait une zone et qu'on a recyclé « commentaire 2 » pour y stocker le code chantier. Des conventions de nommage internes que personne n'a jamais écrites mais que tout le monde respecte.
C'est là que se cachent la grande majorité des blocages de fin de projet. Pas dans la technique. Dans ces petites habitudes qui structurent le travail quotidien sans figurer dans aucun document.
Comment les débusquer ? En s'asseyant à côté des utilisateurs et en les regardant travailler une demi-journée. Pas en leur envoyant un questionnaire.
Qualité des données : trier avant de déménager
Une migration est une excellente occasion de faire le ménage. Doublons clients, champs libres remplis n'importe comment, données obsolètes, encodages mélangés au fil des versions, tables abandonnées depuis trois refontes.
Trois décisions à prendre, table par table : ce qui se reprend intégralement, ce qui s'archive dans un espace consultable mais non migré, ce qui se jette. Attention à ne pas surcharger le projet : reprendre vingt ans d'historique quand cinq suffisent, c'est multiplier les risques et les délais pour un bénéfice discutable.
Choisir la cible : quatre scénarios, pas un seul
La réaction réflexe consiste à chercher « le » remplaçant. C'est réducteur. Quatre voies méritent d'être examinées.
Scénario A, la solution du marché
Un éditeur établi, une base installée, une communauté. La maintenance est assurée, les évolutions réglementaires suivies, le coût d'entrée reste maîtrisé.
Les limites ? Il faut adapter les processus internes à l'outil, et non l'inverse. Ce qui se passe plutôt bien sur les fonctions standard, beaucoup moins sur les spécificités qui font la différence de l'entreprise. Et puis, une question de fond : n'est-on pas en train de reconstruire exactement la même dépendance, pour la revivre dans dix ans ?
Scénario B, le développement sur mesure
Pertinent quand le processus métier est le différenciateur concurrentiel. Quand aucune solution du marché ne colle sans contorsions coûteuses.
Mais à conditions fermes, posées dès la première réunion. Propriété du code au client, écrite noir sur blanc. Technologies courantes et documentées, pas un framework confidentiel maintenu par trois personnes. Documentation technique livrée et maintenue. Dépôt de code accessible au client à tout moment, pas seulement en fin de contrat.
Sans ces quatre garde-fous, on refabrique le piège dont on essaie précisément de sortir.
Scénario C, la reprise et modernisation de l'existant
Souvent oublié, parfois le plus pertinent. Quand le code source est disponible, récupérable par séquestre ou négociable auprès du mandataire, il devient possible de remettre à niveau le socle technique sans toucher au fonctionnel.
Migration de base de données, portage vers un langage maintenu, sécurisation, mise en compatibilité avec les systèmes actuels. Les utilisateurs ne changent pas d'outil, la formation est quasi nulle, et le paramétrage métier accumulé pendant des années reste intact. Le calcul mérite d'être fait avant de l'écarter.
Scénario D, l'approche hybride
Le cœur métier sur mesure, les fonctions périphériques sur des briques du marché : comptabilité, paie, gestion documentaire, CRM. Le tout relié par des interfaces documentées et testées.
C'est fréquemment le meilleur compromis. On investit là où ça compte, on achète le reste, et on limite la dépendance à un seul fournisseur. À condition, évidemment, de prendre les interfaces au sérieux, parce que c'est par là que les ennuis arrivent.
Les critères de choix qui comptent vraiment
Le prix d'achat est le pire critère de sélection. Ce qui compte se mesure ailleurs.
La réversibilité contractuelle, avec un coût fixé dès la signature. Le format d'export natif, testé pendant la démonstration commerciale et non promis pour plus tard. L'existence d'une API documentée et publique. La santé financière de l'éditeur, qui se consulte en quelques clics. Les modalités d'hébergement et, question centrale, qui détient les accès. Et le coût total sur cinq ans, licences, maintenance, hébergement, évolutions et interfaces comprises.
Un tableau comparatif des quatre scénarios sur ces axes, monté avant les rendez-vous fournisseurs, change complètement la nature des discussions.
La migration des données : le cœur technique de l'opération
La règle des trois environnements
Elle ne se négocie pas. L'ancien système reste en production, intouché. Un environnement de recette isolé accueille les essais. Le nouvel environnement cible se construit à part.
On ne teste jamais sur la production. Jamais. Pas « une petite fois pour vérifier ». La tentation existe, surtout quand le calendrier serre. Elle s'est déjà soldée par des bases corrompues un vendredi après-midi.
Le mapping de données, table par table
Le travail est fastidieux, et c'est précisément pour ça qu'on cherche à l'éviter. Mauvaise idée.
Chaque table de l'ancien système, chaque champ, trouve sa correspondance dans le nouveau. Ou pas. Et les cas sans équivalent constituent le vrai sujet : création de champs personnalisés, concaténation de plusieurs zones en une seule, tables de correspondance pour les codifications qui changent, mise en archive consultable pour ce qui ne se reprend pas.
Le livrable de cette phase porte un nom : le dictionnaire de données. Il se relit avec les utilisateurs métier, pas seulement avec les informaticiens. Ce sont eux qui savent que la zone « TYPE3 » contient en réalité le code du transporteur depuis 2015.
Les migrations à blanc, répétées jusqu'à l'ennui
Une seule répétition ne suffit pas. Il en faut plusieurs, complètes, chronométrées.
La première dure huit heures et révèle quarante anomalies. La deuxième, cinq heures et douze anomalies. La troisième, trois heures et deux anomalies mineures. C'est à ce moment-là, et seulement là, qu'on peut planifier la bascule avec un horaire crédible.
Point capital : la dernière répétition doit être rigoureusement identique à la bascule réelle. Mêmes scripts, même ordre, mêmes contrôles, même équipe. Toute variation introduite « parce que ce sera plus propre le jour J » est une prise de risque gratuite.
La réconciliation, le contrôle qui protège tout le monde
Comment sait-on qu'une migration a réussi ? Pas au ressenti.
Les contrôles sont chiffrés : nombre d'enregistrements par table, sommes comptables, soldes clients et fournisseurs, stocks valorisés, en-cours. Auxquels s'ajoute un échantillonnage manuel sur les dossiers les plus complexes, ceux que les utilisateurs désignent eux-mêmes comme des cas tordus.
Et surtout, une règle qui évite bien des disputes : les seuils d'acceptation se définissent avant la migration. Écart toléré sur les soldes, traitement des arrondis, gestion des dossiers historiques incomplets. Après, chacun défend sa position et l'ambiance se dégrade.
Le procès-verbal de réconciliation, signé des deux côtés, clôt la phase proprement.
Les pièges classiques, tous connus, tous rencontrés
Les encodages, en premier lieu. Latin-1 contre UTF-8, et voilà les accents transformés en hiéroglyphes sur trente mille lignes. Les dates au format américain, qui inversent joyeusement jours et mois pour tout ce qui tombe avant le 13. Les séparateurs décimaux, virgule contre point, qui multiplient un montant par mille.
Puis les identifiants réutilisés après suppression, qui rattachent une facture au mauvais client. Les clés étrangères orphelines, pointant vers des enregistrements disparus. Les champs tronqués parce que la zone cible fait 50 caractères là où la source en acceptait 255.
Rien d'exotique. Ces six familles d'erreurs représentent l'essentiel des incidents constatés. Elles se détectent par des contrôles automatisés, à condition d'y avoir pensé.
Basculer sans arrêter l'entreprise
Trois stratégies, trois profils de risque
Le big bang sur période creuse : on arrête tout, on migre, on redémarre sur le nouveau système. Rapide, net, et sans filet si ça déraille. Adapté aux périmètres maîtrisés avec une fenêtre d'arrêt confortable.
Le fonctionnement en parallèle : les deux systèmes tournent simultanément pendant deux à six semaines, avec double saisie sur le périmètre critique. Rassurant, mais épuisant pour les équipes, et il faut une date de fin ferme sous peine de voir la situation s'éterniser.
La bascule progressive par périmètre : un site, puis un autre. Un service, puis le suivant. Une famille de produits, puis le reste. Le risque est fractionné, chaque vague profite des enseignements de la précédente. En contrepartie, il faut gérer une période de coexistence avec des interfaces temporaires, ce qui a un coût.
Aucune de ces trois options n'est supérieure dans l'absolu. Le choix dépend de la tolérance à l'arrêt, de la complexité des flux et des ressources disponibles.
Choisir la fenêtre, sujet moins trivial qu'il n'y paraît
À éviter absolument : les clôtures mensuelles et annuelles, les pics saisonniers, les inventaires, les périodes de congés où la moitié des référents sont injoignables.
À privilégier : un week-end prolongé, une période creuse repérée dans l'historique réel de l'activité. Pas dans le ressenti du dirigeant, dans les chiffres. Beaucoup d'entreprises découvrent à cette occasion que leur période calme n'est pas celle qu'elles croyaient.
Le plan de bascule, minute par minute
Un vrai document, pas une note d'intention. Chaque étape y figure avec un responsable nommé, une durée estimée et un critère de réussite vérifiable.
Gel des saisies à une heure précise, communiquée à tous. Dernier export. Migration. Contrôles automatiques. Validation métier par les référents. Ouverture aux utilisateurs.
Ce document se relit à voix haute en réunion, une semaine avant. C'est souvent à ce moment-là qu'on s'aperçoit que personne n'a prévu qui coupe l'accès à l'ancien système, ni comment on prévient les commerciaux en déplacement.
Le plan de repli, qu'on espère ne jamais ouvrir
Il faut définir un point de non-retour explicite : passé telle heure, si tel contrôle n'est pas validé, on annule et on rouvre l'ancien système. Cette décision se prend à froid, pendant la préparation, pas à deux heures du matin dans la fatigue générale.
La procédure de retour arrière se teste, comme le reste. Et l'ancien système reste accessible en lecture pendant plusieurs mois après la bascule : trois mois minimum, davantage si des obligations d'archivage l'imposent. Cette consultation résiduelle rassure les équipes et règle les litiges historiques.
Assurer la continuité pendant l'indisponibilité
Même une bascule bien préparée génère quelques heures de creux. Il faut les couvrir.
Procédures papier ou tableur pour les opérations critiques, prêtes et distribuées à l'avance. Organisation de la ressaisie, avec les personnes désignées et le créneau prévu. Information des clients et fournisseurs si les délais risquent d'être affectés, ce qui vaut toujours mieux qu'un silence suivi d'une réclamation.
Accompagner les utilisateurs, sinon rien ne tient
Un projet techniquement irréprochable peut échouer complètement. Ça arrive plus souvent qu'on ne le raconte.
Identifier les référents métier, très tôt
Un utilisateur clé par service, impliqué dès la phase de cartographie. Pas convoqué la veille de la formation pour valider ce qui a déjà été décidé sans lui.
Ces référents jouent trois rôles : ils détiennent la connaissance des usages non documentés, ils valident les choix de paramétrage, et ils deviennent les relais naturels auprès de leurs collègues. Leur temps doit être dégagé officiellement, sinon il ne le sera pas.
Former sur des cas réels
Les jeux de démonstration des éditeurs sont propres, cohérents, et ne ressemblent à rien de ce que les équipes rencontreront. Mieux vaut travailler sur les vrais dossiers de l'entreprise, y compris les plus pénibles.
Des sessions courtes valent mieux qu'une journée intensive dont il ne restera rien. Rapprochées de la bascule, pour que l'information soit fraîche. Et rejouées trois à quatre semaines après le démarrage, quand les questions deviennent enfin pertinentes parce qu'elles naissent de l'usage réel.
Gérer la résistance au changement, sans la mépriser
Elle est légitime. Quelqu'un qui maîtrisait son outil depuis huit ans redevient débutant du jour au lendemain, avec les mêmes objectifs de production. Il y a de quoi être contrarié.
Ce qui fonctionne : expliquer pourquoi on part, ce qu'on gagne, et surtout ce qu'on perd temporairement. Assumer les régressions ponctuelles plutôt que de les nier. Un utilisateur à qui on a annoncé qu'un écran serait moins pratique pendant deux mois l'accepte. Le même, à qui on a promis que tout serait mieux, se braque au premier accroc.
Le support renforcé des premières semaines
Présence sur site les premiers jours, quand c'est possible. Un canal de remontée dédié, simple, où chacun sait qu'il sera lu. Une priorisation quotidienne des irritants, avec communication publique sur ce qui a été corrigé.
Ce dernier point pèse lourd. Voir ses remarques traitées et annoncées transforme un utilisateur sceptique en allié. L'inverse produit exactement l'effet contraire.
Ce qu'un prestataire digital doit réellement apporter
Les compétences à réunir
Aucune de ces expertises ne suffit seule. Il faut une maîtrise des bases de données et de l'extraction de formats anciens, ce qui relève parfois de l'archéologie. Une compréhension du métier du client, faute de quoi le mapping n'a aucun sens. Une vraie conduite de projet, avec des jalons et des arbitrages. Du développement d'interfaces. Et des compétences d'infrastructure et d'hébergement.
Le profil isolé qui coche toutes les cases n'existe pratiquement pas. Une équipe, oui.
Les livrables non négociables
Cartographie de l'existant, fonctionnelle et technique. Dictionnaire de données complet. Scripts de migration versionnés et rejouables, avec le code source remis au client. Procès-verbal de réconciliation chiffré. Plan de bascule détaillé. Documentation d'exploitation du nouveau système.
Ces six documents ont un point commun : ils rendent l'entreprise autonome. Un prestataire qui rechigne à les produire construit sa propre indispensabilité, ce qui est exactement le problème dont on cherche à sortir.
Les questions à poser avant de signer
Avez-vous déjà extrait ce format de base précis, et sur quel projet ? Qui est propriétaire des scripts de migration une fois le projet terminé ? Quelle est votre procédure de retour arrière, et l'avez-vous déjà déclenchée ? Comment mesurez-vous qu'une migration est réussie, avec quels indicateurs ? Que se passe-t-il, contractuellement, si la fenêtre de bascule déborde ?
Les réponses sont souvent plus instructives que les références commerciales. Un prestataire qui a déjà connu une bascule difficile en parle avec précision. Celui qui n'a jamais eu de problème n'a probablement pas fait beaucoup de projets.
Les signaux d'alerte, côté prestataire
Un forfait global sans phase d'audit préalable. La promesse d'une migration « automatique » ou « clé en main » sur une base propriétaire de vingt ans. Le refus de réaliser plusieurs migrations à blanc, pour des raisons de coût. L'absence d'engagement écrit sur la réconciliation. Et la dépendance à un intervenant unique, qui fait tenir tout le projet sur un agenda et une santé.
Chacun de ces signaux, pris seul, mérite une question. Deux d'entre eux réunis justifient de consulter ailleurs.
Verrouiller l'après pour ne jamais revivre ça
Le vrai gain du projet ne se situe pas dans le nouvel outil. Il se situe dans le fait de ne plus jamais se retrouver piégé.
Les clauses contractuelles de réversibilité
Quatre éléments à négocier avant la signature, quand on a encore du pouvoir de négociation. Format d'export garanti, décrit précisément, pas « un format standard ». Délai de restitution chiffré en jours. Coût de la réversibilité fixé dès la signature, faute de quoi il sera fixé le jour du divorce. Assistance à la migration sortante, avec un volume d'heures prévu.
Pour les développements spécifiques, ajoutons le séquestre du code source auprès d'un tiers, activable en cas de défaillance. Ça coûte quelques centaines d'euros par an. À comparer au coût d'une reconstruction complète.
La maîtrise technique du nouveau système
Six points à vérifier dès la mise en service, et à revérifier chaque année. Accès à la base de données, en lecture au minimum. Documentation du schéma. API ouverte et documentée. Sauvegardes récupérables, dans un format lisible hors du système. Restauration testée au moins une fois. Et détention des accès d'hébergement par l'entreprise, pas uniquement par le prestataire.
Ce dernier point se révèle souvent au pire moment. Beaucoup d'entreprises découvrent à l'occasion d'une brouille que le nom de domaine et l'hébergement sont au nom de leur agence.
Surveiller la santé de l'éditeur
Une revue annuelle, une heure suffit. Fréquence des mises à jour sur les douze derniers mois. Roadmap publiée et respectée. Situation financière, consultable gratuitement. Mouvements capitalistiques, rachats, changements de direction.
Quand deux indicateurs virent au rouge, on ne panique pas. On commence simplement à préparer le terrain, ce qui laisse deux ans pour agir sereinement plutôt que trois mois pour agir dans l'urgence.
L'export régulier, l'assurance la moins chère du marché
Une extraction périodique et automatisée des données au format ouvert, CSV, XML ou JSON, stockée en dehors du système et sauvegardée. Mensuelle ou hebdomadaire selon le volume.
Le coût ? Quelques heures de mise en place, puis plus rien. Le bénéfice ? Le jour où l'éditeur ferme, où le SaaS coupe l'accès pour impayé, ou où une panne rend la base inaccessible, les données sont là. Lisibles. Immédiatement.
C'est probablement le meilleur rapport coût/protection de toute la démarche. Et c'est aussi le plus souvent négligé, parce qu'il ne sert à rien... jusqu'au jour où il sert à tout.
Pour conclure
Une sortie de logiciel abandonné se pilote comme un projet de continuité d'activité. Pas comme un achat de licence, pas comme un chantier informatique parmi d'autres.
L'ordre des priorités mérite d'être répété, parce que l'inverse se pratique tous les jours. Sécuriser les données d'abord, avant même de savoir vers quoi on ira. Comprendre l'existant ensuite, dans le détail, y compris les usages que personne n'a documentés. Choisir la cible seulement après, une fois qu'on sait ce qu'on doit vraiment reprendre.
Les entreprises qui traversent cette épreuve sans dommage ont toutes un point commun : elles ont pris le temps de l'audit. Celles qui en gardent un mauvais souvenir ont, presque toujours, commencé par choisir le nouveau logiciel.
Vous êtes dans cette situation, ou vous la sentez venir ? La première étape ne consiste pas à consulter des éditeurs. Elle consiste à faire établir un audit de l'existant, une évaluation sérieuse de la récupérabilité de vos données, et un plan de sortie chiffré. Avant tout engagement sur une nouvelle solution. Un accompagnement sur ces trois volets coûte une fraction du budget total et détermine, dans les faits, la réussite ou l'échec de tout ce qui suivra.
