Remplacer un ERP obsolète ou un logiciel propriétaire abandonné
Un logiciel de gestion ne meurt pas d'un coup. Il devient lentement impossible à faire évoluer : l'éditeur ne répond plus, le développeur qui l'a écrit est parti, la version du langage n'est plus maintenue. La question n'est alors plus technique, elle est de savoir quelle sortie coûte le moins cher.
3 semaines
cadrage et prototype avant tout engagement de refonte
Code livré
source, schéma de données et procédure de déploiement remis à chaque lot
0 régie
forfait ferme, reprise des données de l'ancien système comprise
La plupart des dossiers de remplacement d'un logiciel propriétaire abandonné commencent par une alerte anodine : un serveur qui ne redémarre plus, un navigateur qui refuse une page, un salarié qui part avec la seule connaissance du système. La douleur est ancienne, elle a simplement fini par devenir visible depuis la direction.
Les phrases qui ouvrent ces dossiers
Elles se ressemblent d'une entreprise à l'autre, quel que soit le secteur. Elles décrivent moins un problème informatique qu'une perte de contrôle sur un outil dont dépend l'exploitation quotidienne.
- « Notre éditeur ne répond plus depuis six mois, et le contrat de maintenance court toujours. »
- « Le développeur qui a fait l'outil est parti ; personne n'a jamais vu le code. »
- « Le logiciel tourne sur une version de PHP qui n'est plus maintenue, notre hébergeur nous demande de migrer. »
- « L'éditeur a été racheté et la nouvelle direction annonce la fin du produit dans dix-huit mois. »
- « On paie une licence annuelle pour un logiciel qui n'a pas reçu de mise à jour depuis 2019. »
Aucune de ces situations n'impose de tout jeter. Elles imposent seulement d'arrêter de décider par défaut : ne rien faire est un choix, avec un coût, et ce coût augmente chaque trimestre. La première erreur consiste à sauter directement au remplacement sans avoir mesuré ce que l'outil actuel fait réellement.
Remplacer un ERP obsolète : quatre sorties, pas une
Il existe quatre issues à ce type de dossier. Un prestataire de développement a intérêt à ne vous en présenter qu'une : celle qu'il vend. Les voici toutes les quatre, avec les cas où chacune est la bonne réponse.
| Sortie | Quand c'est la bonne réponse | Ce que cela coûte réellement | Le risque |
|---|---|---|---|
| Rester et sécuriser | L'outil couvre le besoin métier ; la douleur est technique — hébergement fragile, version de langage non maintenue, sauvegardes jamais restaurées. | Quelques semaines : mise à niveau de l'environnement, sauvegardes testées pour de vrai, journalisation, réduction de l'exposition. | Repousser l'échéance sans la traiter. Deux ou trois ans plus tard, la même décision se pose avec moins de marge. |
| Migrer vers un progiciel du marché | Votre besoin est standard : comptabilité, paie, gestion commerciale classique, caisse, e-commerce. Aucun de ces processus n'est un avantage concurrentiel. | Des licences annuelles, un intégrateur, et surtout l'adaptation de vos pratiques à celles de l'éditeur. | Le tunnel de paramétrage : les 10 % non couverts finissent en développements spécifiques rarement chiffrés au départ. |
| Réécrire sur mesure | Le processus est le métier lui-même : calcul de ristournes, référencement fournisseurs, tarification particulière, règles qu'aucun progiciel ne modélise sans les déformer. | Un projet de plusieurs mois, un budget de refonte assumé, et un porteur métier réellement disponible. | Réécrire à l'identique un système dont plus personne ne sait justifier la moitié des règles. |
| Découper et remplacer par lots | Le système est gros et hétérogène, certaines parties sont saines, et l'activité ne supporte pas un arrêt ni un big bang. | Un peu plus cher au total : il faut faire cohabiter l'ancien et le nouveau, avec des ponts de données temporaires. | Ne jamais finir. L'ancien système survit des années parce que le dernier lot n'est jamais prioritaire. |
Le choix ne se joue pas sur la technologie mais sur une question unique : votre processus est-il une spécificité qui vous distingue, ou une commodité que tout le monde exécute de la même façon ? Une gestion de paie est une commodité. Un moteur de bonifications de fin d'année propre à votre groupement ne l'est pas.
Récupérer le code source et les données quand l'éditeur est défaillant
C'est la partie que personne n'anticipe et qui bloque le plus souvent le calendrier. Menez-la dans cet ordre, et commencez avant d'annoncer quoi que ce soit à votre prestataire actuel.
- Relisez le contrat d'origine : clause de propriété intellectuelle, éventuelle clause d'entiercement du code, conditions de réversibilité et de restitution des données. Ce que vous pouvez exiger en dépend entièrement.
- Inventoriez les accès techniques que vous détenez déjà : compte d'hébergement, registrar du nom de domaine, accès à la base, comptes d'administration, certificats. Beaucoup d'entreprises découvrent à ce moment que tout est au nom du prestataire.
- Prenez une copie complète de la base et des fichiers avant toute discussion tendue. Un serveur coupé pour facture impayée ne se rallume pas parce que vous en avez besoin.
- Demandez formellement, par écrit et avec un délai, un export intégral des données dans un format standard ainsi que la remise des sources. Une demande verbale ne produit rien, et la trace écrite compte si le dossier finit chez un avocat.
- Si les sources restent inaccessibles, documentez le schéma de la base par rétro-ingénierie. Dans un logiciel de gestion, l'essentiel de la règle métier se relit dans les données et dans les écrans, même sans le code.
- Ne débranchez rien tant qu'une sauvegarde complète n'a pas été restaurée sur une machine que vous contrôlez, et vérifiée en l'ouvrant réellement.
Dans les cas les plus dégradés, le code n'est jamais récupéré et ce n'est pas rédhibitoire : ce qui a de la valeur, c'est l'historique des données et la connaissance des règles, pas quinze mille lignes écrites dans un framework mort.
L'audit de l'existant, avant la décision
Inventaire fonctionnel réel
Ce que le logiciel fait aujourd'hui, pas ce que le cahier des charges de 2011 prévoyait. On mesure l'usage écran par écran : dans un outil maison de dix ans, une part significative des fonctions n'est plus utilisée par personne, et la réécrire serait payer pour du vide.
État technique et exposition
Versions du langage et de la base, dépendances non maintenues, exposition sur internet, sauvegardes testées ou seulement planifiées. C'est ce volet qui tranche entre « urgent » et « seulement inconfortable ».
État des données
Volumétrie, doublons, champs détournés de leur usage d'origine, historiques incomplets. C'est ce qui détermine le coût de reprise, et c'est le poste le plus systématiquement sous-estimé dans les devis de refonte.
Décision chiffrée
Un document court qui applique les quatre sorties à votre cas, avec une fourchette budgétaire, un ordre de bataille et les conséquences de ne rien faire. La décision vous appartient — y compris celle de ne pas travailler avec nous.
MEKANO est un studio de développement lyonnais spécialisé dans les applications de gestion métier, en particulier celles des groupements et réseaux d'entreprises. Nous travaillons au forfait ferme, par lots livrés en sprints de deux semaines, sur une stack Go, React et PostgreSQL, et nous remettons le code source. Le point d'entrée habituel est un cadrage avec prototype en trois semaines, entre 6 000 et 10 000 € HT : c'est la façon la moins chère de savoir si une refonte est justifiée.
Quand nous ne sommes pas la bonne réponse
- Votre besoin est une comptabilité, une paie ou une gestion commerciale standard : un progiciel du marché coûtera moins cher et sera mieux maintenu qu'un développement spécifique.
- Vous cherchez une régie pour renforcer une équipe interne : nous intervenons au forfait, sur un périmètre défini, pas en assistance technique.
- Le système actuel fonctionne et la seule gêne est esthétique. Refaire les écrans d'un outil sain est rarement l'investissement le plus rentable.
- Personne côté métier ne peut consacrer une demi-journée par semaine au projet. Sans porteur disponible, une refonte reproduit l'ancien système avec de nouvelles couleurs.
- Vous voulez une décision demain matin. Un audit sérieux prend deux à trois semaines, et sauter cette étape est la cause la plus fréquente des refontes qui déraillent.
Questions fréquentes
- Combien coûte l'audit avant décision ?
- Notre offre d'entrée est un cadrage avec prototype sur trois semaines, entre 6 000 et 10 000 € HT selon la taille du système à examiner. Elle produit l'inventaire fonctionnel, l'état technique, l'état des données et une recommandation chiffrée sur les quatre sorties. Elle est facturée seule : rien ne vous engage à poursuivre avec nous, et le document reste exploitable par un autre prestataire.
- Et si l'éditeur refuse de restituer les données ?
- Commencez par vérifier ce que dit le contrat sur la restitution : la plupart des contrats d'édition prévoient une obligation de réversibilité, même sommaire. En pratique, la donnée est souvent récupérable sans lui, par un accès direct à la base ou par les exports que l'application propose déjà à ses utilisateurs. Nous avons rarement besoin des sources : le schéma de données et les écrans suffisent à reconstituer la règle métier. Le blocage est plus souvent juridique que technique.
- Peut-on remplacer par lots sans arrêter l'activité ?
- Oui, et c'est la méthode que nous privilégions sur les systèmes qui portent l'exploitation. Chaque lot est mis en service séparément, avec des ponts de données temporaires entre l'ancien et le nouveau système, souvent une synchronisation nocturne. Cela coûte un peu plus cher au total et impose de fixer dès le départ la date d'extinction de l'ancien outil, faute de quoi il survit indéfiniment.
- Que devient l'historique des données de l'ancien système ?
- Il est repris, et c'est un poste à chiffrer explicitement dans le forfait, pas une variable d'ajustement. Nous distinguons trois traitements : les données actives, migrées et retravaillées ; l'historique utile aux comparaisons, migré tel quel ; les archives rarement consultées, conservées en lecture dans un format exportable. Décider ce qui tombe dans chaque catégorie prend une demi-journée d'atelier et évite des semaines de reprise inutile.
- Le code de la nouvelle application nous appartient-il ?
- Oui. Le code source, le schéma de données et la procédure de déploiement vous sont remis à chaque lot, et la réversibilité est une clause du contrat. C'est le point le plus important pour une entreprise qui sort d'un logiciel propriétaire abandonné : le but n'est pas de changer de dépendance, mais de ne plus en avoir.
- Combien de temps prend un remplacement complet ?
- Cela dépend surtout du nombre de processus critiques, rarement du volume de code. Pour un système de gestion métier d'une PME, comptez trois à neuf mois de la décision à l'extinction de l'ancien outil, en remplacement par lots, avec un premier lot en production sous deux à trois mois. Un big bang serait plus court sur le papier, et considérablement plus risqué.
À lire ensuite
Réussir la refonte du système de gestion d'un groupement
Un groupement ne refond pas son système parce qu'il est vieux, mais parce qu'un processus critique déborde : l'arrêté des bonifications, la collecte des déclarations, le renouvellement des contrats de référencement. Le projet a donc une date limite réelle, un calendrier annuel qu'il ne peut pas déplacer, et quinze ans de données à reprendre.
Lire la suiteRéversibilité et propriété du code source : ce que la clause doit dire
« Le code source vous appartient » est la phrase la plus répandue et la moins vérifiée des propositions de développement. Entre une cession de droits opposable et une licence d'utilisation habilement formulée, l'écart ne se voit qu'au moment où vous voulez partir — c'est-à-dire trop tard.
Lire la suiteLivraison par lots avec recette formelle : comment se déroule un projet
Un projet informatique ne se juge pas sur son planning initial mais sur ce qui se passe au quatrième mois, quand une règle oubliée apparaît et que la date de bascule approche. Le découpage en lots et la recette formelle existent pour rendre ce moment gérable plutôt que conflictuel.
Lire la suiteCadrage et prototype d'application métier en 3 semaines : décider sur pièces
Décider d'engager plusieurs centaines de milliers d'euros sur la foi d'une proposition commerciale est un exercice inconfortable, surtout sans DSI pour arbitrer. Cette offre existe pour transformer cette décision en constat : voir le logiciel fonctionner sur votre cas réel, et connaître son prix, avant de signer le projet.
Lire la suiteParlons de votre situation
Trente minutes, sans engagement. Vous repartez avec un avis franc sur la faisabilité, un ordre de grandeur de budget et les prochaines étapes.
Réserver l'appel