Reprise de données ERP : les incohérences entre tables à chercher avant le premier chargement

Une reprise de données ERP suit presque toujours le même chemin : extraction, nettoyage, tables de correspondance, chargement, contrôle. Le premier chargement de test est le moment de vérité. C'est là que tombent les rejets d'import, les fiches en double et les totaux qui ne bouclent pas.

Cet article liste les incohérences entre tables à chercher avant ce premier chargement, dans l'ordre où il vaut mieux les chercher. Puis il montre ce que les contrôles habituels ne voient pas.

Qu'est-ce qu'une incohérence entre tables ?

Une base ERP n'est pas une liste de tableaux indépendants. Une ligne de commande renvoie à une commande, à un article et, par la commande, à un client. Une facture renvoie à un tiers, à des lignes, à des comptes. Une incohérence entre tables, c'est un de ces liens qui ne tient pas : cassé, en double, ou faux.

Prise seule, chaque table peut sembler propre. La colonne « code article » d'une ligne de commande peut être remplie partout, au bon format, sans valeur aberrante. Elle peut quand même pointer vers des articles qui n'existent plus.

Dans une reprise de données ERP, les contrôles colonne par colonne ne voient pas les incohérences entre tables : il faut suivre les liens.

Quels contrôles font déjà les équipes de reprise ?

Les guides publiés par les intégrateurs et les cabinets décrivent tous la même boîte à outils. Elle est utile, et il faut la faire.

• Les comptages. Nombre de lignes par table avant et après l'import, nombre d'articles exportés contre importés.
• Les orphelins. Une facture sans tiers, une commande vers un produit supprimé.
• L'unicité. Deux fiches avec le même code client, deux articles avec la même référence.
• Les totaux. La somme des lignes contre le montant de l'en-tête ; la balance comptable reprise compte à compte. Un écart de balance bloque la bascule.
• Quelques vraisemblances. Les stocks négatifs, des fiches témoins vérifiées à la main (unités, tarifs, prix de revient).

Ces contrôles sont décrits, par exemple, par Hayot Expertise, Octura et Orisha. Ils s'écrivent le plus souvent en requêtes, une clé après l'autre.

Comptages, orphelins, doublons de clés et totaux attrapent les liens cassés ; ils n'attrapent pas les liens faux.

Que faire quand l'export n'a pas de clés étrangères ?

Les requêtes clé par clé supposent qu'on sait quelle colonne pointe vers quelle table. Dans une base récente, la structure le dit. Dans l'export d'un ancien ERP, souvent non : des fichiers à plat, des colonnes aux noms génériques, des codes stockés comme du texte, aucune contrainte déclarée.

Il faut alors reconstruire les liens à partir des données elles-mêmes : les noms, les formats, les valeurs qui se recoupent d'une table à l'autre. Tant que ce travail n'est pas fait, les contrôles d'orphelins ne couvrent que les liens auxquels on a pensé.

Sans clés étrangères dans l'export, un contrôle d'orphelins ne couvre que les liens qu'on a su retrouver.

Qu'est-ce qu'un lien valide mais faux ?

C'est le cas que les requêtes clé par clé ne voient jamais. La clé existe, la ligne visée existe, le contrôle passe. Mais le lien n'a pas de sens. Quelques cas types, fictifs, que l'on retrouve dans toute base ancienne :

• une commande client rattachée à un tiers qui n'est que fournisseur ;
• une date de livraison antérieure à la date de la commande qu'elle livre ;
• un prix unitaire de ligne cohérent avec le carton alors que l'article est vendu à la pièce ;
• une ligne de stock sur un article de type « prestation » ;
• deux fiches clients sans identifiant commun, aux noms proches et à la même adresse : le même client, saisi deux fois.

Aucun de ces cas ne provoque de rejet à l'import. Ils passent le chargement, puis ressortent en recette, ou après la bascule, sur une facture ou un inventaire.

Un lien entre tables peut être valide et absurde : seule une lecture du sens des données le voit avant le chargement.

Dans quel ordre chercher les incohérences ?

Un ordre simple, à reprendre dans un plan de reprise.

1. Compter. Lignes par table, valeurs vides par colonne. Sans cette base, on ne saura pas dire ce que l'import a perdu.
2. Nettoyer les référentiels d'abord. Tiers et articles : doublons exacts, puis doublons proches. Toutes les autres tables pointent vers eux.
3. Retrouver et vérifier les liens. Quelle colonne pointe vers quelle table, puis les orphelins sur chacun de ces liens.
4. Faire boucler les totaux. Lignes contre en-têtes, sous-totaux contre comptes, balance d'ouverture.
5. Lire le sens. Dates dans le bon ordre, unités et prix plausibles pour la famille d'articles, types de tiers cohérents avec les documents qui les citent.

Avant une reprise de données ERP, on nettoie les tiers et les articles en premier, parce que toutes les autres tables pointent vers eux.

Quand faire ces contrôles dans le projet ?

Le plus tôt possible : sur l'export de l'ancien système, avant le premier chargement de test. C'est le moment où une correction côté source coûte le moins, et où le planning de reprise peut encore l'absorber.

Puis à nouveau avant la répétition générale. Les corrections ont-elles tenu ? De nouvelles saisies ont-elles recréé les mêmes erreurs ? Un export de plus suffit à le dire.

Comment Gimlo AI aborde ces contrôles ?

Gimlo AI audite une base exportée, sans accès à la production, et vérifie le sens des données et les liens entre tables, pas seulement le format. Il travaille sur l'export tel qu'il est, même sans clés étrangères ni contraintes déclarées, et livre un rapport priorisé : quoi corriger d'abord, table par table, prêt pour l'équipe de reprise.

Il se mesure sur un banc d'essai : trois bases synthétiques (distribution, industrie, services), des erreurs injectées avec vérité terrain. Au niveau de corruption 20, sur un export sans clés, plus de 98 % de ses constats sont de vraies erreurs (précision de 98,8 à 99,6 % selon la base), et il en retrouve de 70,3 à 84,8 %. Voir les résultats et leur source.

Ce que le banc ne dit pas : les erreurs sont injectées par nous, les bases sont construites par nous, et le moteur n'est pas encore mesuré sur un export client réel. Pour voir à quoi ressemble le rapport, ouvrez un rapport d'exemple.

Gimlo AI est proposé en programme d'audit pilote accompagné, pour les ETI en préparation de migration ERP et les intégrateurs qui préparent leur reprise.