Une migration ERP consiste à remplacer le système qui porte la comptabilité, les achats, les stocks, la production et les ventes de l’entreprise, ou à le faire passer à une version majeure plus récente. C’est l’un des projets les plus sensibles d’une PME ou d’une ETI : on déplace en même temps des données, des habitudes et des responsabilités, sans pouvoir arrêter la facturation ni l’expédition.
Ce guide s’adresse aux dirigeants, DAF et DSI belges qui envisagent de changer d’ERP. Il explique comment décider, comment organiser la bascule, comment réussir la reprise de données ERP et comment se protéger si quelque chose tourne mal. Si vous n’avez pas encore de vision d’ensemble, commencez par comprendre ce qu’est un ERP et par les étapes d’un projet ERP.
Quand faut-il remplacer son ERP ?
Un ERP ne se remplace pas par lassitude. Le changement se justifie quand le coût de la situation actuelle dépasse, de façon durable, celui d’un projet de migration. Plusieurs signaux reviennent chez les entreprises belges.
Les signaux qui justifient un changement
- Des contournements permanents : tableurs parallèles pour les marges, les stocks ou le suivi de production, ressaisies d’un module à l’autre, clôtures mensuelles qui dépendent de la mémoire de deux personnes.
- Un produit qui n’évolue plus : l’éditeur ne publie plus de mises à jour fonctionnelles, ou la version utilisée n’est plus prise en charge.
- Des besoins qui ont changé : ouverture d’une boutique en ligne, nouvelle filiale, activité de production ajoutée à une activité de négoce, exigences de facturation électronique entre entreprises.
- Une dépendance à un prestataire ou à un développeur unique : personne d’autre ne sait modifier ni corriger le système.
- Des coûts d’exploitation qui dérivent : serveurs vieillissants, licences difficiles à faire évoluer, interventions facturées pour des évolutions simples.
- Un système qui ne s’intègre plus : l’échange de données avec le transporteur, la banque, la plateforme de vente ou l’outil de paie passe par des fichiers manuels.
Les faux motifs
Certaines raisons ne justifient pas à elles seules une migration. Un utilisateur mécontent d’un écran, un changement de direction qui veut « moderniser », ou l’attrait d’un produit vu en démonstration ne suffisent pas. Souvent, un paramétrage corrigé, une formation ou un module complémentaire règlent le problème à moindre risque. Posez-vous la question honnêtement : l’ERP actuel est-il mal adapté, ou mal exploité ?
Changer d’ERP ou migrer vers une nouvelle version ?
Le mot « migration » recouvre deux projets très différents.
| Situation | Nature du projet | Point d’attention principal |
|---|---|---|
| Passage à une version majeure du même ERP | Montée de version | Compatibilité des développements spécifiques, des extensions et des intégrations |
| Passage d’une solution sur site vers une solution cloud du même éditeur | Migration d’hébergement et de modèle | Licences, performances, accès, sauvegardes, responsabilités |
| Remplacement par un autre ERP | Projet complet de remplacement | Reprise de données, refonte des processus, formation, bascule |
| Fusion de plusieurs outils en un seul ERP | Consolidation | Harmonisation des référentiels et des règles de gestion |
La montée de version est en général plus simple, parce que le modèle de données reste proche. Elle reste un vrai projet : les adaptations spécifiques doivent être relues, les fonctions modifiées par l’éditeur retestées. Le remplacement par un autre ERP est plus lourd mais offre l’occasion de remettre à plat des processus accumulés au fil des années.
Cadrer le projet avant de choisir une bascule
Une migration réussie se prépare par un cadrage sérieux. Ce travail précède le choix de la méthode de bascule et le choix de l’outil.
Établir l’existant
Dressez la liste de ce que fait réellement l’ERP actuel : modules utilisés, développements spécifiques, interfaces avec d’autres outils, états et documents imprimés, droits d’accès. Interrogez les utilisateurs, pas seulement la direction : ils connaissent les contournements que personne n’a documentés.
Définir ce que le nouvel ERP doit faire
Reprenez votre cahier des charges ERP ou rédigez-le si vous n’en avez pas. Distinguez ce qui est indispensable de ce qui est souhaitable. Précisez les exigences belges : plan comptable adapté, déclarations de TVA, listings clients, échanges via le réseau Peppol, gestion multilingue lorsque vos clients, fournisseurs ou équipes travaillent en français, en néerlandais ou en allemand.
Choisir la solution et l’intégrateur
Le choix de l’outil dépend de la taille, du secteur et de la complexité de l’entreprise. Parmi les solutions courantes en Belgique figurent Odoo, Microsoft Dynamics 365 Business Central, Exact Online, SAP Business One et Oracle NetSuite. Les comparatifs ERP aident à situer chaque produit, et le guide pour choisir un ERP détaille la méthode. Quant au partenaire, choisir un intégrateur ERP demande autant de soin que choisir le logiciel : c’est lui qui conduira la reprise des données et la bascule.
Big bang ou bascule par lots : choisir la stratégie
C’est la décision structurante d’une migration. Elle conditionne le planning, le risque, la charge des équipes et le budget.
Le big bang
Tous les modules et tous les utilisateurs passent sur le nouvel ERP à une date unique. L’ancien système est arrêté, ou conservé en lecture seule.
Avantages
- Une seule période de transition, un seul changement pour les équipes.
- Pas de passerelles temporaires entre ancien et nouveau système.
- Une vision claire : à partir de la date, il n’y a qu’une source de vérité.
Inconvénients
- Le risque est concentré sur un seul moment.
- Toute anomalie non détectée aux essais touche l’ensemble de l’entreprise.
- La charge de support juste après la bascule est élevée.
Cette approche convient à une entreprise avec un périmètre limité, un seul site, peu de variantes de processus et une équipe disponible pour absorber la période de démarrage.
La bascule par lots
La migration est découpée : par société, par site, par pays, par module ou par flux. Chaque lot est stabilisé avant de passer au suivant.
Avantages
- Le risque est réparti et les enseignements du premier lot profitent aux suivants.
- La charge de support est lissée.
- Une erreur de conception est détectée sur un périmètre restreint.
Inconvénients
- Il faut des interfaces temporaires entre l’ancien et le nouveau système, qui coûtent et qui peuvent elles-mêmes générer des erreurs.
- La période de transition dure plus longtemps, avec deux outils à maintenir.
- Les consolidations et les rapports de groupe sont plus délicats pendant la cohabitation.
Cette approche convient aux groupes avec plusieurs sociétés, aux entreprises multisites ou aux projets où la finance et la logistique ne peuvent pas être touchées en même temps.
Comment trancher
| Critère | Penche vers le big bang | Penche vers les lots |
|---|---|---|
| Nombre de sites et de sociétés | Un seul | Plusieurs |
| Complexité des flux | Faible à moyenne | Élevée |
| Tolérance à l’arrêt | Réelle, avec une fenêtre dédiée | Très faible |
| Capacité des équipes | Disponibles ensemble | Mobilisables par vagues |
| Intégrations avec d’autres outils | Peu nombreuses | Nombreuses |
| Budget d’interfaces temporaires | Non souhaité | Acceptable |
Il existe aussi des approches hybrides : on bascule d’abord la comptabilité, puis les achats et les stocks, puis la production. Un bon intégrateur vous recommandera la stratégie en fonction de votre contexte, pas de son habitude.
La reprise de données : le cœur du risque
Dans la plupart des projets difficiles, la cause est rarement le logiciel : c’est la qualité des données reprises. Une reprise de données ERP suit une méthode rigoureuse en plusieurs temps.
Décider de ce que l’on reprend
Tout ne doit pas être migré. Reprendre l’intégralité de l’historique alourdit le projet, allonge les essais et importe des erreurs anciennes. Distinguez :
- Les données de référence : clients, fournisseurs, articles, nomenclatures, gammes, plan comptable, conditions de paiement, tarifs, comptes bancaires.
- Les soldes et encours : soldes comptables d’ouverture, factures ouvertes clients et fournisseurs, commandes en cours, stocks valorisés, immobilisations.
- L’historique : transactions passées, utiles pour les statistiques, la traçabilité ou les obligations légales de conservation.
Pour l’historique, une alternative courante consiste à conserver l’ancien système en consultation, ou à l’archiver dans un outil dédié, plutôt que de tout recharger. Vérifiez avec votre expert-comptable et votre conseil les obligations de conservation applicables à votre activité.
Nettoyer avant de migrer
Migrer des données sales dans un système neuf, c’est reproduire les problèmes anciens avec une interface plus récente. Le nettoyage porte sur :
- les doublons de clients et de fournisseurs, fréquents après des années de saisie ;
- les articles obsolètes ou jamais vendus ;
- les adresses incomplètes, les numéros d’entreprise et de TVA manquants ou erronés ;
- les unités de mesure incohérentes, les codes en double, les libellés contradictoires ;
- les comptes comptables inutilisés.
Ce nettoyage appartient aux métiers, pas à l’informatique seule. Seul le service achats sait si un fournisseur est encore actif ; seul le service commercial sait si un client est à fusionner avec un autre. Prévoyez un responsable de données par domaine.
Établir la correspondance, ou mapping
Le mapping décrit, champ par champ, comment une donnée de l’ancien ERP se retrouve dans le nouveau. Il traite notamment :
- la correspondance du plan comptable de l’ancien système avec celui du nouveau, en respectant le plan comptable minimum normalisé et les besoins de reporting de l’entreprise ;
- la transformation des codes (familles d’articles, conditions de livraison, taxes) ;
- les champs qui existent d’un côté mais pas de l’autre, et la décision à prendre : créer un champ, fusionner, abandonner ;
- les règles de gestion qui changent : numérotation des documents, gestion des lots et des numéros de série, calcul du coût de revient.
Documentez ce mapping dans un fichier partagé et validé par les métiers. C’est la référence en cas de contestation après la bascule.
Réaliser plusieurs chargements d’essai
On ne réussit pas une reprise de données du premier coup. La méthode éprouvée consiste à répéter les chargements :
- Un premier chargement d’essai révèle les erreurs de format, les champs manquants et les écarts de mapping.
- Des chargements suivants corrigent ces anomalies et mesurent la durée réelle du traitement.
- Une répétition générale rejoue la bascule complète dans les conditions réelles, chronomètre en main, avec l’équipe qui sera présente le jour J.
Après chaque chargement, vérifiez par des contrôles de réconciliation : le total des soldes comptables correspond-il ? Les factures ouvertes sont-elles identiques ? La valeur du stock est-elle la même dans les deux systèmes ? Ces contrôles chiffrés, menés par la finance, valent plus que n’importe quelle impression.
Gérer les données au moment de la bascule
Le jour de la bascule, les données bougent encore : factures émises, mouvements de stock, paiements reçus. Il faut définir une date de gel, un moment où l’on cesse de saisir dans l’ancien système, puis recharger les soldes et les encours à cette date. Cette période de gel doit être annoncée à tous, y compris aux clients et fournisseurs si elle perturbe les livraisons ou la facturation.
Les essais et la recette avant la bascule
Une migration sans essais sérieux est un pari. Plusieurs niveaux se combinent.
- Les tests de processus déroulent les cycles complets : de la commande client à l’encaissement, de la demande d’achat au paiement fournisseur, de l’ordre de fabrication à l’entrée en stock.
- Les tests d’intégration vérifient les échanges avec la banque, la boutique en ligne, le transporteur, la paie ou l’outil de facturation électronique. Sur ce point, le guide sur l’ERP et la facture électronique détaille ce qu’il faut contrôler.
- La recette utilisateur fait valider le résultat par les futurs utilisateurs, sur leurs propres cas réels et non sur des exemples simplifiés.
- Les tests de charge et de performance s’assurent que le système tient avec le volume réel de données et d’utilisateurs.
Formalisez des critères d’acceptation avant la recette : ce qui doit fonctionner, ce qui peut rester en réserve, ce qui bloque la mise en production. Sans ces critères, la décision de bascule se prend à l’émotion.
Former et accompagner les équipes
La technique ne fait pas tout. Un ERP neuf mal compris produit des erreurs de saisie plus coûteuses que l’ancien système imparfait.
- Formez par rôle et sur les cas concrets de l’entreprise, pas uniquement sur des démonstrations génériques.
- Désignez des utilisateurs clés dans chaque service : ils relaient, répondent aux questions de leurs collègues et remontent les anomalies.
- Prévoyez des supports courts et accessibles : fiches de procédure, vidéos internes.
- Organisez un renfort de support pendant la période qui suit la bascule, avec des canaux clairs pour signaler un problème.
La conduite du changement est une des causes les plus fréquentes de difficultés. Le guide sur les erreurs d’un projet ERP revient sur ces écueils.
Les risques d’une migration et comment les réduire
| Risque | Conséquence possible | Parade |
|---|---|---|
| Données mal nettoyées | Erreurs de facturation, stocks faux, doublons | Nettoyage par les métiers, contrôles de réconciliation |
| Périmètre qui s’élargit en cours de route | Retards, dépassement du budget | Cadrage écrit, comité de pilotage, arbitrage formel des demandes |
| Intégrations non testées | Commandes, paiements ou expéditions bloqués | Tests d’intégration de bout en bout avant la bascule |
| Indisponibilité des équipes | Recette bâclée, décisions tardives | Libérer du temps des utilisateurs clés dès le cadrage |
| Résistance au changement | Contournements, retour aux tableurs | Implication précoce, formation, relais dans les services |
| Bascule à une période critique | Perturbation de la clôture ou de la haute saison | Choisir la date avec la finance et les opérations |
| Dépendance à une seule personne | Savoir perdu en cas d’absence | Documentation, suppléants désignés, transfert de connaissances |
Un projet de migration s’inscrit enfin dans un budget et un calendrier réalistes. Pour comprendre ce qui fait varier le coût, consultez le guide sur le prix d’un ERP : l’effort de reprise de données et de formation y pèse souvent davantage que la licence elle-même.
Prévoir un plan de retour arrière
Le retour arrière est la police d’assurance du projet. Il se prépare avant la bascule, jamais pendant.
Ce que le plan doit contenir
- Les critères de déclenchement : quelles anomalies imposent de revenir à l’ancien système (facturation impossible, écarts comptables non expliqués, blocage logistique).
- La personne qui décide, et jusqu’à quel moment le retour reste possible. Il existe un point de non-retour, à partir duquel trop d’opérations ont été saisies pour revenir proprement.
- La conservation de l’ancien système en état de fonctionner, avec ses données figées à la date de gel et ses sauvegardes vérifiées.
- La méthode pour réinjecter les opérations saisies dans le nouvel ERP si l’on revient à l’ancien, afin de ne rien perdre.
- La communication vers les équipes, les clients et les fournisseurs en cas de retour.
Garder l’ancien système après la bascule
Même quand tout se passe bien, ne coupez pas l’ancien ERP immédiatement. Gardez-le accessible en lecture pendant une période adaptée à vos clôtures, à vos contrôles et à vos obligations de conservation. Il sert de référence en cas de litige sur une écriture ou un document passé. Vérifiez les conditions de licence et d’hébergement de cette conservation avec l’éditeur ou l’intégrateur actuel.
Après la bascule : stabiliser et mesurer
La mise en production n’est pas la fin du projet. Les semaines qui suivent servent à stabiliser.
- Suivez une liste d’anomalies priorisées, avec un responsable et une échéance pour chacune.
- Réalisez la première clôture comptable avec un accompagnement renforcé.
- Comparez les chiffres clés avec ceux de l’ancien système : chiffre d’affaires, marge, stock, créances, dettes.
- Recueillez le retour des utilisateurs et ajustez le paramétrage et les formations.
- Planifiez les évolutions repoussées après la bascule, plutôt que de les empiler dans la phase critique.
Un bilan de projet, quelques mois plus tard, permet de mesurer ce qui a été gagné : fiabilité des données, délais de clôture, suppression des ressaisies, qualité du pilotage.
Spécificités à surveiller selon l’activité
Les points d’attention varient selon le secteur. Une entreprise industrielle devra soigner la reprise des nomenclatures, des gammes et des stocks en cours de fabrication : voir l’ERP pour l’industrie. Une entreprise de négoce portera son attention sur les articles, les tarifs et les conditions fournisseurs : voir l’ERP pour le négoce et la distribution. Une activité de vente en ligne devra tester minutieusement les synchronisations de catalogue, de stock et de commandes.
Pour une PME qui découvre le sujet, le guide sur l’ERP pour PME donne les repères généraux, et la page sur le cloud ou le sur site aide à trancher le mode d’hébergement, un choix qui influence fortement la méthode de migration.
Trouver l’intégrateur pour conduire votre migration
Une migration réussie repose sur un partenaire qui a déjà mené des reprises de données dans des contextes comparables au vôtre : même taille, même secteur, mêmes contraintes belges. Notre service est gratuit : nous décrivons votre projet, puis nous vous mettons en relation avec un intégrateur adapté. Le détail figure sur la page comment fonctionne la mise en relation. Nous ne réalisons pas le projet nous-mêmes : c’est l’intégrateur qui prend en charge la migration, avec vous.
Avant de le rencontrer, préparez quelques éléments : la liste des modules utilisés, les interfaces existantes, les volumes de données, les contraintes de calendrier (clôtures, haute saison) et vos objectifs. Plus votre demande est précise, plus la proposition sera pertinente.
Questions fréquentes
Quand faut-il changer d’ERP ?
Lorsque l’outil actuel freine l’entreprise de façon durable : processus contournés dans des tableurs, éditeur qui ne fait plus évoluer le produit, impossibilité d’intégrer la boutique en ligne, la facturation électronique ou un nouvel entrepôt. Un simple désagrément ne justifie pas un projet. Comparez d’abord le coût de la situation actuelle à celui d’un changement, puis demandez un avis à un intégrateur.
Big bang ou bascule par lots : que choisir ?
Le big bang convient aux périmètres modestes, avec peu de sites et peu de variantes de processus. La bascule par lots, par société, par site ou par module, réduit le risque et l’effort de support simultané, mais elle impose des passerelles temporaires entre l’ancien et le nouvel ERP. Le bon choix dépend de votre tolérance à l’arrêt et de la complexité des flux.
Quelles données faut-il reprendre dans le nouvel ERP ?
Reprenez les données de référence (clients, fournisseurs, articles, nomenclatures, plan comptable), les soldes d’ouverture et les documents en cours. L’historique complet n’est pas toujours utile : une partie peut rester consultable dans une archive. Ce qui est repris doit être nettoyé, dédoublonné et validé par les métiers.
Que se passe-t-il si la bascule échoue ?
Un plan de retour arrière doit être écrit avant la bascule : conditions qui déclenchent le retour, personne qui décide, ancien système conservé en lecture et en écriture, et méthode pour réinjecter les opérations saisies entre-temps. Sans ce plan, un incident se transforme vite en crise d’exploitation.
Migrer vers une nouvelle version du même ERP est-il plus simple ?
Souvent oui, car le modèle de données est proche, mais ce n’est pas un simple clic. Les développements spécifiques, les extensions et les intégrations doivent être revus et testés, et certaines fonctions changent d’une version à l’autre. Traitez cette montée de version comme un projet, avec essais et recette.
Les noms de logiciels cités sont des marques de leurs éditeurs respectifs, mentionnées à titre d’information. Ce site est indépendant et n’est affilié à aucun éditeur.