Reprise de données ERP : stratégie, mapping et recette

La reprise de données est l'opération qui extrait les données de l'ancien système, les nettoie, les transforme selon les règles du nouvel ERP, puis les charge et les contrôle avant la mise en service. Une stratégie de reprise de données fixe ce qu'on reprend, dans quel ordre, avec quels outils, sous la responsabilité de qui, et comment on prouve que le résultat est juste.

Selon Eurostat, 46,45 % des entreprises de l'Union de 10 salariés ou plus utilisaient un ERP en 2025, en hausse de 3,07 points par rapport à 2023, de 41,08 % pour les petites à 88,71 % pour les grandes. En France, l'Insee mesurait 47 % en 2023. Une partie des migrations part donc d'un ERP existant, avec des années de données accumulées.

Pourquoi traiter la reprise comme un projet à part entière ?

Le guide de mise en œuvre de Dynamics 365 publié par Microsoft qualifie la migration de données de processus « complexe et long », qui demande coordination, tests et validation, et recommande de lui réserver du temps et des personnes dans le plan de projet. Il précise que ces activités perturbent les environnements et ne doivent pas se dérouler en même temps que d'autres tests.

La Cour des comptes a documenté ce qui se passe quand la qualité des données d'entrée est contournée. Dans son référé sur le système de paye Louvois, rendu public le 6 mars 2014, elle relève que les quelque 200 contrôles intégrés de cohérence des données, parce qu'ils bloquaient les traitements, ont été presque tous neutralisés « au lieu d'améliorer la fiabilité des saisies et des données » des SIRH. Le texte du référé ajoute que les architectures de données des SIRH et du calculateur « n'ont pas été conçues de manière cohérente ». Dans une reprise, la situation équivalente se présente quand on désactive un contrôle de chargement pour faire passer des rejets au lieu de corriger la source.

Quelles données reprendre, et lesquelles laisser ?

Microsoft distingue les données de paramétrage (devises, codes de TVA, paramètres) et les données de migration, elles-mêmes divisées en données de base (clients, articles, fournisseurs) et en transactions ouvertes (commandes de vente et d'achat en cours, stock, soldes ouverts). Ce découpage donne l'ordre de chargement : le paramétrage, puis les référentiels, puis les encours qui s'appuient sur eux.

L'historique pose une question distincte. Le reprendre en entier alourdit chaque essai et oblige à transcoder des données anciennes vers des règles nouvelles. Une option consiste à ne reprendre que les soldes et les pièces ouvertes, et à garder l'historique consultable ailleurs : ancien système en lecture seule, export archivé ou entrepôt de données. La contrainte légale demeure : les livres et pièces justificatives comptables se conservent 10 ans à compter de la clôture de l'exercice, selon l'article L123-22 du code de commerce rappelé par Service Public Entreprendre. Conserver n'oblige pas à migrer, mais l'archive doit rester lisible pendant toute cette durée.

Comment nettoyer les données avant la migration ?

Profiler chaque table source : nombre d'enregistrements, champs vides, formats hétérogènes, doublons probables, enregistrements sans mouvement depuis une date fixée.
Faire décider les règles par les propriétaires des données, pas par l'équipe technique : quel doublon garder, quels articles inactifs abandonner, quelle valeur par défaut accepter (voir la gouvernance des données en PME).
Corriger dans la source tant que l'ancien système tourne, pour que chaque nouvel essai reparte de données propres.
Réserver les corrections dans les règles de transformation aux cas impossibles à traiter à la source : changement de codification, regroupement de familles.
Tenir un journal des corrections : qui a décidé, combien d'enregistrements, à quelle date.

Comment construire le mapping ?

Le mapping, ou table de correspondance, décrit champ par champ comment une donnée source devient une donnée cible. Chaque ligne indique :

le champ source et sa table ;
le champ cible et son format ;
la règle de transformation : concaténation, découpage, conversion d'unité ;
la table de transcodage quand les codes changent : familles, conditions de paiement, comptes ;
la valeur par défaut et le traitement des valeurs vides ;
le propriétaire qui a validé la règle.

La liste des champs cibles sans source est la première à produire : elle révèle les données que le nouvel ERP exige et que personne ne saisissait. La cartographie des flux de données indique d'où vient chaque champ, en particulier quand il n'existe que dans un classeur. C'est aussi pour cette raison que l'inventaire des fichiers réels, décrit dans pourquoi nous demandons les fichiers avant les accès, précède la reprise.

Combien d'essais de reprise prévoir ?

Autant qu'il en faut pour que le dernier se déroule sans surprise. Microsoft recommande de tester la migration au moins une fois dans l'environnement d'intégration et dans celui de recette, puis, dans son guide sur la bascule, de répéter la bascule complète plusieurs fois, « aussi près que possible de la réelle », avec les mêmes données, les mêmes outils et les mêmes personnes, jusqu'à ce que tout se passe sans incident.

Chaque essai se mesure : volumes extraits et chargés, rejets par motif, durée de chaque étape. La durée compte parce que la fenêtre est courte : selon le même guide, le « week-end de bascule » dure généralement moins de 48 heures, pendant lesquelles ni l'ancien ni le nouveau système ne sont utilisables.

Comment faire la recette d'une reprise de données ?

La recette prouve que les données chargées sont complètes, exactes et utilisables. Quatre familles de contrôles :

Comptages : nombre d'enregistrements par objet, source contre cible, chaque rejet expliqué.
Totaux de contrôle : balance clients, valeur du stock, montant des commandes ouvertes, identiques de part et d'autre à la date d'arrêté.
Échantillons vérifiés par les métiers, sur des fiches qu'ils choisissent eux-mêmes.
Parcours de processus : une commande passée sur un article repris, livrée, facturée et encaissée dans le nouvel ERP.

Le 20 décembre 2022, la FCA et la PRA britanniques ont infligé à la banque TSB une amende totale de 48,65 millions de livres à la suite de sa migration informatique d'avril 2018. Le communiqué de la FCA précise que « les données elles-mêmes ont migré avec succès », mais que la plateforme a connu des défaillances immédiates, touchant une part importante de ses 5,2 millions de clients, avec un retour à la normale en décembre 2018. Les critères de décision de mise en service portent donc sur deux objets distincts : les données chargées et le fonctionnement des processus. Microsoft recommande de fixer ces critères à l'avance, de nommer qui décide et de prévoir un plan de retour arrière.

Questions fréquentes

Quelle différence entre reprise de données et migration de données ?

Les deux termes désignent le transfert de données d'un système vers un autre. « Reprise » est l'usage courant des projets ERP en France ; « migration » couvre aussi les changements d'infrastructure ou de base sans changement de logiciel.

Qui est responsable de la reprise de données ?

L'intégrateur fournit les outils et exécute les chargements. L'entreprise reste responsable du contenu : règles de nettoyage, validation du mapping, recette et signature.

Faut-il reprendre l'historique dans le nouvel ERP ?

Pas nécessairement. Les soldes et pièces ouvertes suffisent au fonctionnement ; l'historique peut rester consultable dans une archive lisible pendant les durées légales de conservation.

Quels outils utiliser pour la reprise ?

Les éditeurs fournissent des outils d'import ; pour Dynamics 365, Microsoft cite ses assistants d'import et d'export, Azure Data Factory, SSIS ou des produits tiers. Les tables de transcodage peuvent vivre dans un tableur, à condition d'être versionnées et validées par leurs propriétaires.

Sources

Tous les articles

Reprendre les données lors d'une migration d'ERP