Vous avez pris la décision de migrer vers un ERP cloud. Le contrat avec l’intégrateur est signé, le kick-off a eu lieu, le projet est lancé. Et là, une réalité s’impose que peu de documents projet avaient vraiment anticipée : pendant les prochains dix-huit à trente-six mois, vous allez faire tourner deux systèmes ERP en parallèle.
Ce n’est pas un échec. C’est la norme. Les projets de migration ERP de grande envergure ne basculent jamais en big bang du jour au lendemain. La plupart s’échelonnent sur plusieurs années, avec une phase de coexistence où l’ancien système reste en production sur certains périmètres pendant que le nouveau monte en charge sur d’autres. Selon les données de Panorama Consulting (rapport ERP 2024), 68 % des projets ERP dépassent leur calendrier initial. Une grande partie de ce dépassement se passe précisément pendant cette période de coexistence, souvent mal planifiée.
La plupart des articles couvrent la décision de migrer, le choix de l’éditeur, ou le go-live. Cet article couvre ce qui vient après le go-live partiel : les quatre phases de la coexistence, les risques concrets, et les décisions de gouvernance qui déterminent si la transition se passe en douceur ou si elle dure cinq ans au lieu de deux.
La coexistence bimodale : une réalité structurelle, pas une anomalie
Le terme “bimodal” vient du cabinet Gartner, qui l’a théorisé dès 2014 pour désigner une organisation IT gérant en parallèle deux modes : un Mode 1 stable, tourné vers la fiabilité des systèmes coeur, et un Mode 2 agile, dédié à l’innovation et aux nouvelles capacités. Dans le contexte d’une migration ERP, la bimodalité prend une forme très concrète : votre ERP on-premise reste le système de référence pour la comptabilité et la logistique, tandis que le nouveau cloud ERP prend en charge la gestion commerciale ou les ressources humaines.
Le problème n’est pas de faire tourner deux systèmes. C’est de les faire tourner sans que personne ne soit certain, à un instant donné, de quel système est la source de vérité pour telle ou telle donnée.
Bien piloter la coexistence, c’est répondre à cette question en permanence, pour chaque processus, chaque module, chaque flux de données. Ce que cet article propose, c’est un cadre en quatre phases pour y répondre de façon méthodique.
Phase 1 (mois 0-3) : cartographier la coexistence avant de la subir
La première erreur est de commencer le projet de migration sans avoir produit de document dédié à la coexistence. Le plan de migration décrit l’état cible. Le plan de coexistence décrit l’état de transition, qui durera bien plus longtemps que prévu.
La matrice de coexistence : votre boussole pour 24 mois
Le livrable principal de cette phase est une matrice de coexistence. Elle croise trois dimensions : les processus (achats, ventes, compta, logistique, RH, etc.), le système qui les héberge (legacy, cloud, ou les deux en parallèle), et la date de bascule cible. Cette matrice doit être validée par le comité de pilotage et mise à jour à chaque phase review.
Elle permet de répondre immédiatement à des questions du type : “Où crée-t-on un nouveau fournisseur en septembre ?” ou “Dans quel système voit-on le stock disponible en temps réel en mars ?”. Sans cette matrice, les équipes métier improvisent. Et l’improvisation dans un contexte bimodal produit des doublons, des incohérences de données et des escalations inutiles.
Décision iPaaS ou connecteur natif
Une fois la matrice établie, la deuxième décision de phase 1 est l’architecture d’intégration entre les deux systèmes. Deux options principales :
- Connecteur natif : la plupart des éditeurs cloud proposent des connecteurs préconfigurés vers les ERP les plus répandus (SAP ECC, Oracle E-Business Suite, Microsoft Dynamics AX). Ces connecteurs couvrent les flux standards mais montrent leurs limites sur les processus très personnalisés.
- iPaaS (Integration Platform as a Service) : des plateformes comme Boomi, MuleSoft ou Workato permettent de construire des flux d’intégration sur mesure. Elles donnent plus de flexibilité mais exigent des compétences d’intégration et un budget supplémentaire (licences et mise en oeuvre de 60 000 à 200 000 euros selon la complexité).
La règle de décision est simple : si plus de 30 % de vos processus ont été personnalisés dans le legacy, le connecteur natif sera insuffisant. Vous aurez besoin d’un iPaaS.
Identifier les données en double dès le départ
La troisième tâche de phase 1 : recenser les entités qui vont exister dans les deux systèmes pendant la coexistence. Typiquement : le référentiel tiers (clients, fournisseurs), les produits et tarifs, les commandes en cours à la date de bascule partielle, et les comptes analytiques.
Pour chaque entité en double, vous devez décider immédiatement : quel système est maître (source de vérité) ? Quel système est esclave (il reçoit une copie en lecture seule) ? Cette décision doit être documentée et non-négociable pendant toute la phase de coexistence.
Phase 2 (mois 3-12) : deux systèmes en production, zéro chaos
C’est la phase la plus longue et la plus risquée. Les deux systèmes sont en production sur des périmètres différents. Les équipes apprennent le nouveau système tout en maintenant l’ancien. Les incidents surviennent précisément dans les flux qui traversent les deux environnements.
Architecture de synchronisation : temps réel ou batch ?
Toutes les données ne nécessitent pas une synchronisation en temps réel. Savoir où mettre le curseur est une décision qui impacte directement les coûts d’infrastructure et la complexité des interfaces.
En règle générale, les processus opérationnels à fort impact immédiat exigent du temps réel ou du quasi-temps réel (synchronisation toutes les 5 à 15 minutes) : disponibilité des stocks pour les prises de commandes, statut des expéditions, tarifs et conditions commerciales actifs. Un délai de 24h sur ces flux produit des erreurs visibles par les clients.
En revanche, les données de pilotage et de reporting tolerent un batch quotidien ou hebdomadaire : indicateurs de gestion, budget vs réalisé, portefeuille de projets. La plupart des directions financières acceptent un arrêté de gestion avec un décalage de J-1.
L’architecture recommandée pour la phase 2 : désignez le nouveau système cloud comme “golden record” pour toutes les entités dont il est maître. Le legacy reçoit des copies en lecture seule. Jamais l’inverse. Cette asymétrie, une fois respectée rigoureusement, élimine 80 % des problèmes de réconciliation.
Gouvernance des droits d’accès : le détail qui fait tout
La question “qui peut créer un client dans quel système ?” semble banale. Elle est en réalité source de la majorité des doublons tiers constatés en phase de coexistence.
La règle à appliquer dès le premier jour de phase 2 : chaque processus de création ou de modification d’une entité maître ne peut se faire que dans un seul système, avec un workflow de validation unique. Si un commercial crée un client dans Salesforce, et que ce client est automatiquement synchronisé dans le legacy ERP en lecture seule, le legacy ne doit plus permettre la création manuelle d’un nouveau tiers avec le même nom ou le même numéro SIRET.
Cette gouvernance exige un paramétrage fin des droits d’accès dans le legacy. C’est souvent là que les projets font l’économie qu’il ne faut pas faire : désactiver la modification dans le legacy est politiquement difficile car les équipes legacy ont l’habitude de travailler en autonomie. C’est pourtant non-négociable pour éviter les doublons.
Clôture financière bimodale : les trois pièges comptables
La clôture mensuelle avec deux ERP en parallèle est le moment de vérité de la phase 2. Trois pièges comptables récurrents :
Piège 1 : les charges constatées d’avance (CCA) et factures à recevoir (FAR). Si une facture fournisseur est enregistrée dans le legacy mais concerne un service livré dans le périmètre du nouveau système, le rattachement analytique et le lettrage peuvent diverger entre les deux bases. Solution : définir une règle de rattachement unique dès la phase 1 et la faire valider par le commissaire aux comptes avant la première clôture bimodale.
Piège 2 : les provisions inter-systèmes. Les provisions sur litiges ou sur stocks peuvent être saisies dans l’un ou l’autre système selon le périmètre du responsable comptable. Sans règle explicite, elles risquent d’être saisies deux fois, ou oubliées dans les deux. La règle à poser : les provisions sont toujours saisies dans le système qui héberge la charge opérationnelle sous-jacente.
Piège 3 : la consolidation des données. Avec deux bases de données distinctes, la consolidation des tableaux de bord financiers exige un outil de reporting capable de requêter les deux systèmes. Si votre outil de BI actuel ne supporte qu’un seul connecteur, anticipez ce besoin dès le début de phase 2, pas deux semaines avant la clôture annuelle.
Phase 3 (mois 12-24) : réduire le périmètre legacy, module par module
La phase 3 est celle où la migration progresse réellement. Chaque module basculé dans le nouveau système réduit la surface de coexistence et simplifie les interfaces.
Quel module migrer en premier ?
Il n’y a pas de réponse universelle, mais deux logiques s’affrontent :
Logique “comptabilité d’abord” : migrer la comptabilité générale et analytique en premier donne un référentiel financier unique. La clôture mensuelle redevient simple. En contrepartie, les interfaces avec le legacy opérationnel (achats, logistique) sont complexes pendant la phase de transition.
Logique “opérations d’abord” : migrer la logistique et les achats en premier réduit les risques opérationnels visibles par les clients et fournisseurs. La comptabilité reste en legacy temporairement, avec une interface vers le cloud pour les mouvements de stock et les factures.
En pratique, les entreprises de services migrent souvent la comptabilité en premier car leur logistique est simple. Les industriels et les distributeurs migrent les opérations en premier pour ne pas perturber la chaîne de valeur.
Les 5 signaux qui indiquent qu’un module legacy est prêt à être éteint
Avant d’éteindre un module dans le legacy, vérifiez ces cinq conditions :
- Zéro transaction ouverte : toutes les commandes en cours, factures non lettrées et provisions actives ont été transférées ou soldées dans le nouveau système.
- Données historiques accessibles : les données des cinq dernières années sont consultables en lecture seule depuis le nouveau système ou depuis un archivage structuré (voir phase 4).
- Interfaces désactivées : aucun flux automatique n’écrit encore dans le module legacy. Vérifiez dans les logs d’intégration, pas seulement dans la documentation.
- Utilisateurs formés et autonomes : le taux d’adoption dans le nouveau système est supérieur à 80 % sur les fonctions concernées. En dessous, le module legacy sera réactivé sous la pression des utilisateurs.
- Validation DSI + DAF : co-signature obligatoire avant extinction. Le DSI valide la faisabilité technique, le DAF valide l’absence de risque comptable ou fiscal.
Phase 4 (mois 24-36) : bascule finale et période de filet de sécurité
À partir du mois 24 environ, la majorité des processus opérationnels tournent dans le cloud ERP. Le legacy est en mode résiduel : quelques modules comptables, les données historiques, et une poignée d’utilisateurs qui “vérifient dans l’ancien système” par habitude ou par besoin réel.
Le legacy en lecture seule : combien de temps le garder ?
La réponse n’est pas technique, elle est réglementaire. En France, les données comptables doivent être conservées et consultables pendant 10 ans (article L.123-22 du Code de commerce). Les pièces justificatives (factures fournisseurs, notes de frais) doivent être accessibles pendant la durée de prescription fiscale, soit en principe 3 ans, mais 6 ans en cas de contrôle fiscal approfondi.
En pratique, conserver le legacy en lecture seule pendant 12 à 18 mois après la bascule finale est une durée raisonnable pour permettre les requêtes ad hoc des équipes métier et les éventuels audits. Au-delà, l’archivage structuré (exportation des données dans un format pérenne avec index de recherche) est plus économique que le maintien d’une infrastructure complète.
Checklist de décommissionnement (phase 4)
Avant d’éteindre définitivement le legacy :
- Données archivées selon le référentiel légal (comptabilité 10 ans, contrats 5 ans, paie 5 ans)
- Format d’archivage ouvert et documenté (CSV structuré, XML avec XSD, ou plateforme SAE certifiée NF Z42-013)
- Contrats éditeur et de maintenance résiliés avec les préavis requis
- Serveurs décommissionnés selon la politique RGPD (effacement sécurisé des données personnelles)
- Audit de fin de projet documenté : scope effectif vs scope initial, coûts réels vs budget, incidents de coexistence recensés
Les 3 incidents les plus fréquents en J+30 à J+90 après la bascule finale
Même après une bascule réussie, trois incidents reviennent régulièrement dans les premières semaines :
Incident 1 : les données manquantes. Un utilisateur cherche un document de 2023 et ne le trouve pas dans le nouveau système parce que la migration historique était limitée à 3 ans. Solution préventive : documenter précisément le périmètre de la migration historique et former les utilisateurs à utiliser l’interface d’archivage pour les données antérieures.
Incident 2 : les interfaces non documentées. Une interface avec un système tiers (EDI, portail client, logiciel de paie) continue d’envoyer des données au legacy. L’intégration a été omise du périmètre de migration car personne ne la connaissait. Solution préventive : cartographier toutes les interfaces en phase 1 depuis les logs réseau, pas seulement depuis la documentation SI.
Incident 3 : la régression sur les états réglementaires. Un export TVA ou un état de réconciliation produit par le nouveau système ne correspond pas exactement au format attendu par l’administration fiscale ou par l’auditeur. Solution préventive : tester les états réglementaires en double avec le legacy au moins trois mois avant la bascule finale.
Budget et ressources : ce que coûte vraiment la coexistence
La coexistence bimodale a un coût direct qu’il faut budgéter explicitement, et non absorber dans le budget de migration.
Coût de la double infrastructure
Tant que le legacy est en production (mode actif) ou en mode lecture seule supervisé, il génère des coûts : licences éditeur, infrastructure serveur ou hébergement, supervision et support. Sur un ERP on-premise d’une ETI de taille moyenne, ces coûts se situent souvent entre 80 000 et 200 000 euros par an (infrastructure + support, hors coût de l’équipe interne qui le maintient). Multiplié par deux à trois ans de coexistence, cela représente un poste non négligeable que le business case du nouveau système ERP doit intégrer pour être honnête.
L’étude ERP Today (source) recommande d’allouer explicitement 15 à 20 % du budget total du projet de migration au décommissionnement du legacy, incluant les coûts de coexistence et d’archivage. Les organisations qui n’anticipent pas ce poste prolongent souvent la période de coexistence par contrainte budgétaire, ce qui accroît paradoxalement les coûts totaux.
Ressources humaines dédiées à la coexistence
Au pic de la phase 2 (mois 3-12), une organisation bien pilotée alloue généralement :
- 0,5 à 1 ETP dédié à la supervision des interfaces entre les deux systèmes (vérification des logs, gestion des rejets, réconciliation des données divergentes)
- 0,25 ETP comptabilité pour la gestion des clôtures bimodales et la production des états consolidés
- Un point hebdomadaire de 1 heure entre le chef de projet migration, le responsable legacy et le responsable cloud pour arbitrer les incidents de coexistence
Ces ressources sont souvent absorbées par les équipes existantes sans être comptabilisées. L’absence de traçabilité de ce coût produit une sous-estimation systématique du ROI du projet de migration : on oublie le coût de la période de transition dans le calcul du retour sur investissement.
Conclusion : la coexistence est un projet dans le projet
La transition bimodale n’est pas une anomalie temporaire que vous traversez en vous pinçant le nez. C’est une phase de projet à part entière, avec ses livrables (matrice de coexistence, architecture d’intégration, gouvernance des droits d’accès), ses risques propres (doublons tiers, clôtures bimodales, interfaces non documentées), et son budget dédié.
Les organisations qui réussissent leur migration ERP ne sont pas celles qui l’ont exécutée le plus vite. Ce sont celles qui ont traité la coexistence comme un sous-projet structuré, avec un responsable identifié, des KPI de suivi et un budget explicite. Nommer un “responsable de la coexistence” distinct du chef de projet migration n’est pas un luxe. C’est un facteur de succès documenté.
Pour approfondir les stratégies pour votre système actuel avant de migrer, lisez notre guide Moderniser un ERP vieillissant sans le remplacer : 5 stratégies pour DSI en 2026. Pour préparer l’étape d’après, notre plan Décommissionner un ERP legacy en 8 étapes couvre les aspects archivage, résiliation des licences et conformité. Et si votre priorité est l’adoption des équipes dans le nouveau système, notre plan de conduite du changement ERP en 8 étapes vous donnera la structure opérationnelle pour maximiser le taux d’adoption post-bascule.
