Migrer son ERP en PME sans big bang
La majorité des projets de migration ERP qui déraillent ont un point commun : on a voulu tout basculer en une fois. La méthode progressive, qui maintient le legacy en service pendant qu'on construit le nouveau périmètre, change radicalement le profil de risque. Voici ce qu'elle implique et pourquoi elle fonctionne.
Donatien Lefranc
Fondateur & Président, Leando
Le big bang comme réflexe, et pourquoi il échoue si souvent
L'attrait du coup d'un seul
L'idée est séduisante : on remplace tout l'ancien système en une fois, on forme les équipes sur le nouveau, on bascule à date fixe, et on ne gère plus deux systèmes en parallèle. Le big bang promet la clarté. Un seul projet, une seule date, une seule interface à former.
En pratique, cette clarté se retourne contre le projet. Un big bang nécessite que tout soit parfait au moment du basculement : les données migrées, les règles métier codées, les équipes formées, les processus testés. C'est rarement le cas. Et quand ce n'est pas parfait, il n'y a plus de retour en arrière possible. L'organisation entière est exposée au risque d'un projet qui n'est pas prêt.
Ce qui se passe vraiment dans un big bang raté
Le big bang raté suit un scénario prévisible. Le projet est lancé avec une date de go-live ambitieuse. Les équipes découvrent pendant les tests des règles métier que personne n'avait formalisées. Les corrections génèrent des allers-retours entre métier et technique. La date de go-live glisse. Le budget dépasse. On livre avec des fonctionnalités manquantes ou contournées par des Excel. Les équipes perdent confiance dans le nouveau système. L'ancien est maintenu officieusement.
Ce scénario n'est pas exceptionnel. Il est statistiquement le cas le plus fréquent. Les études sur les projets ERP estiment que plus de 50% dépassent le budget initial de façon significative, et que les délais glissent en moyenne de 30 à 50% par rapport aux prévisions initiales. La cause n'est pas le manque de compétences techniques. C'est l'exposition simultanée à trop d'inconnues.
Pourquoi le legacy est une ressource, pas un fardeau
Le legacy reçoit une mauvaise presse. On en parle comme d'un boulet dont il faut se débarrasser le plus vite possible. Cette vision est inexacte. Un legacy en production, même imparfait, assure la continuité de service. Il est connu des équipes. Ses limites sont documentées par l'expérience, même si elles ne sont pas écrites.
Dans une migration progressive, le legacy joue le rôle de filet de sécurité. Il continue à couvrir les processus qui n'ont pas encore été migrés. Les équipes ne basculent sur le nouveau système que lorsqu'il est stable sur son périmètre et validé en conditions réelles. On ne crée pas de point de non-retour.
L'objection classique : gérer deux systèmes en parallèle coûte cher. C'est vrai, mais cette coexistence est temporaire et maîtrisée. Elle coûte moins cher qu'un big bang raté qui force à maintenir indéfiniment un système à moitié migré, avec des équipes démotivées et des processus hybrides qui ne correspondent ni à l'ancien ni au nouveau système.
La migration progressive : les trois principes qui changent tout
Principe 1 : construire à côté, pas par-dessus
La migration progressive ne modifie pas le legacy. Elle construit le nouveau système à côté, sur un périmètre délimité. Les deux coexistent, parfois avec une synchronisation légère sur les données partagées. On ne touche pas à ce qui fonctionne. On construit ce qui manque, sur la stack cible, avec les standards qu'on veut appliquer. La bascule se fait périmètre par périmètre, validée sur le terrain avant chaque extension.
Principe 2 : identifier la brique embryonnaire
La migration progressive commence par le processus le plus en tension, pas par le plus simple. C'est là que la valeur est la plus forte et que la pression pour résoudre est la plus grande. Cette première brique a une propriété particulière : elle doit s'inscrire naturellement dans le quotidien des équipes dès la livraison, et constituer la fondation sur laquelle les processus adjacents s'appuieront ensuite.
C'est ce que nous appelons « construire une trottinette, pas une Ferrari ». La trottinette roule dès le jour 1. Elle ne couvre pas tous les besoins. Mais elle prouve que l'approche fonctionne, elle libère de la bande passante sur le processus critique, et elle crée la confiance nécessaire pour continuer.
Principe 3 : documenter les règles métier avant de coder
La migration progressive impose une discipline que le big bang saute souvent : formaliser les règles métier avant le développement. C'est la condition pour que la brique embryonnaire soit correcte dès la livraison. Sans cette formalisation, on code quelque chose qui ne correspond pas aux cas réels, on découvre les exceptions pendant les tests, et on réitère à coût élevé.
Cette formalisation prend du temps en amont. Elle en fait gagner beaucoup en aval. Chaque règle formalisée est une itération de développement évitée. Chaque scénario non nominal identifié avant le code est une correction d'urgence évitée en production.
Ce qu'on a construit avec un fournisseur d'énergie ETI
« Identifier une trottinette, pas construire une Ferrari. »
En novembre 2025, nous avons démarré avec un fournisseur d'énergie ETI, filiale française d'un groupe suisse. La situation initiale : une stack legacy PHP avec un datalake, des règles métier non documentées (soutirage, injection, TURPE, règles propres à Enedis), et une tentative de migration avec des freelances qui avait produit des projets partant dans toutes les directions, sans vision organisationnelle ni technique cohérente. L'audit interne du groupe en 2024 avait été décevant.
L'approche : on a maintenu le legacy PHP en place. On a formalisé les règles métier du processus commercial en tension (recueil du besoin client, contractualisation, onboarding, facturation). On a documenté les scénarios nominaux et les scénarios non nominaux spécifiques au secteur énergie. On a construit le MVP commercial sur la stack cible, en parallèle du legacy, sur ce périmètre restreint.
La deuxième verbatim qui illustre le mieux la vertu de cette approche :
« Cette trottinette, elle avait une vraie vertu de s'inscrire vraiment dans le quotidien des équipes tout en étant la brique embryonnaire qui allait pouvoir ensuite permettre de développer tout ce qu'il y avait en amont. »
Au printemps 2026, l'audit interne du groupe par un cabinet suisse indépendant a validé la documentation et la méthode : résultat « jour et nuit » par rapport à l'audit 2024. La migration n'est pas terminée. Mais la trajectoire est claire, les équipes sont confiantes, et chaque phase suivante s'appuie sur des fondations solides.
Pour approfondir les options de modernisation SI en PME, le guide ERP sur mesure pour PME couvre les avantages et les arbitrages selon votre situation. Si vous êtes encore en phase de diagnostic, les 6 signes d'un SI qui freine la croissance permet de qualifier la situation avant de choisir une approche. Et pour le comparatif entre logiciel standard et sur mesure, le comparatif logiciel de gestion PME détaille les critères de choix.
La première action concrète si vous envisagez une migration ERP : avant de contacter un intégrateur, cartographiez les processus que votre legacy couvre correctement et ceux qu'il couvre mal. Cette cartographie détermine votre périmètre de première phase, et elle prend moins de deux jours avec les bonnes personnes dans la pièce.
Une migration progressive se déroule en plusieurs phases successives. La première phase, qui couvre le processus le plus critique, prend généralement 3 à 5 mois. Les phases suivantes s'enchaînent ensuite sur 6 à 18 mois selon l'étendue du périmètre. Au total, le projet complet dure souvent 12 à 24 mois, mais chaque phase livre de la valeur indépendamment. C'est très différent d'un big bang qui mobilise les ressources 18 mois sans rien livrer entre le kickoff et le go-live.
Vous avez un legacy à migrer sans tout casser ?
On cadre le périmètre de première phase, on maintient la continuité de service, et on livre une première brique qui prouve l'approche avant d'aller plus loin. Échange exploratoire sans engagement.
Parler de ma migration