Le premier import de clients affiche 98 % de lignes chargées. Deux jours plus tard, le service client découvre pourtant des comptes fusionnés, la finance ne rapproche plus certains avoirs et le commerce corrige à la main les adresses écrasées. Le taux de chargement était exact, mais il ne disait rien de la capacité à facturer, livrer puis expliquer chaque dossier.
Une donnée « sale » n’est pas seulement vide ou mal orthographiée. Elle peut être plausible et pourtant fausse pour le processus cible : un code client recyclé, une unité incohérente, un pays déduit d’une adresse libre, un article actif sans règle fiscale ou deux identités historiques qui représentent le même établissement à des dates différentes. L’ERP rend ces ambiguïtés visibles parce qu’il applique des contraintes et produit des effets comptables.
Le vrai enjeu consiste donc à réduire l’incertitude, pas à promettre un nettoyage total. Contre-intuitivement, corriger toutes les lignes avant de concevoir l’intégration peut aggraver le risque : les règles changent sans trace et l’on perd le lien entre source, transformation et résultat. La bonne préparation distingue ce qui doit être réparé, isolé, enrichi, assumé ou refusé.
Dans une démarche de développement web sur mesure, le flux ERP devient un produit exploitable : contrat de données, propriétaires, journalisation, seuils locaux, reprise et preuves métier. Ce guide permet de cadrer ces décisions sans attendre un historique parfait ni contaminer le nouveau système.
Mesurer la dette avant de choisir le remède
Partir des effets métier, pas d’un score global
Le profilage commence par les objets qui déclenchent une action : tiers, articles, tarifs, commandes, stocks, factures et règlements. Pour chacun, l’équipe relie une anomalie à son effet possible. Une TVA absente peut bloquer la facture ; un téléphone non normalisé gêne surtout le support ; une unité erronée peut multiplier un besoin d’approvisionnement. Ces défauts n’ont ni la même urgence ni le même owner.
Un tableau utile compte les lignes concernées, mais montre surtout leur concentration par source, période, entité et parcours. Si 4 % des articles n’ont pas d’unité, ce chiffre ne commande aucune décision seul. Si ces articles représentent un flux courant et empêchent la valorisation, le go peut être bloqué. S’ils sont archivés et sans écriture ouverte, une quarantaine documentée peut suffire. Le seuil dépend donc de l’exposition, pas d’une norme universelle.
Échantillonner les longues traînes
Les dix valeurs les plus fréquentes révèlent rarement le danger principal. Il faut explorer doublons rares, anciennes périodes, caractères inattendus, dates impossibles, valeurs sentinelles comme 999999 et relations orphelines. Le profil combine distributions, contraintes de domaine et tests de jointure. Une inspection manuelle ciblée complète l’automatisation pour comprendre pourquoi la valeur existe.
Chaque résultat garde la requête, la date d’extraction et la version de source. Sans cette traçabilité, deux campagnes produisent des nombres incompatibles et l’équipe discute de la mesure au lieu du risque. Le diagnostic devient une ligne de base reproductible, rafraîchie après chaque correction afin de distinguer amélioration réelle, déplacement du défaut et régression.
Attribuer la vérité champ par champ
Éviter le propriétaire unique fictif
Dire que « l’ERP est maître du client » reste trop vague. Le CRM peut posséder le contact commercial, l’ERP la condition de paiement et un référentiel groupe l’identifiant légal. La propriété s’écrit au niveau du champ ou du sous-objet, avec l’événement qui autorise son évolution. Elle précise aussi qui valide une correction et quel système reçoit le résultat.
Cette matrice sépare trois notions souvent confondues : la source d’origine, la source opposable à un instant donné et l’interface autorisée à modifier. Un IBAN importé d’un ancien outil peut rester la source d’origine, mais devenir non opposable tant qu’un contrôle n’est pas passé. Une adresse saisie dans le portail peut être proposée sans être directement appliquée à la fiche de facturation.
Mettre les transformations sous contrat
Chaque règle décrit entrée, sortie, précondition et motif de rejet. « Nettoyer le pays » devient par exemple : accepter un code ISO reconnu, mapper une liste versionnée de synonymes, puis isoler toute autre valeur. Les transformations tacites — suppression d’accents, troncature, valeur par défaut — sont dangereuses, car elles donnent une ligne techniquement valide dont le sens a changé.
Le contrat doit pouvoir être testé sur un jeu stable et relu par le métier. Il conserve la valeur brute à côté de la valeur canonique et de la version de règle. Cette approche rejoint le principe d’anti-corruption layer documenté par Microsoft : protéger le modèle cible des concepts et ambiguïtés d’un système hérité au moyen d’une couche explicite.
Profiler sur des parcours métier réels
Tester les relations autant que les colonnes
Une ligne peut respecter son schéma et casser le parcours. Le client existe, l’adresse existe et la commande existe ; pourtant l’adresse appartient à une autre entité juridique. Le profilage vérifie donc unicité, cardinalité, cohérence temporelle et relations transverses. Il rejoue aussi les calculs sensibles : taxe, conversion d’unité, arrondi, disponibilité et rapprochement comptable.
Les contrôles sont rangés par moment d’apparition. Certains s’exécutent à l’extraction, d’autres après normalisation, d’autres seulement lorsque plusieurs objets ont été rapprochés. Cette chronologie évite d’attribuer au fichier source un défaut créé par le mapping. Elle permet également de montrer à chaque propriétaire l’endroit exact où sa décision intervient.
Le jeu de preuve inclut des dossiers nominaux et des cas limites réels anonymisés : compte fermé avec facture ouverte, article sans successeur, avoir daté avant la facture, adresse modifiée après commande. On ne cherche pas à inventer tous les accidents, mais à couvrir les familles capables de produire un effet irréversible.
Classer défauts, corrections et rejets
Choisir une politique par famille d’anomalies
Une typologie simple distingue défaut syntaxique, incohérence de domaine, identité ambiguë, relation orpheline, conflit de propriété et information manquante. À chaque famille correspond une action autorisée : correction déterministe, enrichissement validé, fusion proposée, quarantaine, import avec avertissement ou rejet bloquant. Le traitement ne dépend jamais d’un message libre saisi au fil du lot.
La correction automatique est réservée aux règles déterministes et réversibles. Transformer FRANCE en FR peut être sûr si la table est versionnée ; choisir une filiale depuis un nom proche ne l’est pas. L’équipe conserve valeur avant/après, règle, date et identifiant de lot. Elle peut ainsi reconstruire un dossier et annuler une transformation sans restaurer toute la base.
La quarantaine n’est pas une poubelle. Elle possède motif, propriétaire, priorité métier et date de revue. Un dossier peut poursuivre le parcours sans une donnée secondaire, alors qu’un autre doit attendre. Le seuil de backlog acceptable est fixé selon la capacité de traitement et l’exposition ; il n’est fiable que s’il déclenche une action, par exemple suspendre le lot suivant lorsque les cas critiques vieillissent.
Reconstruire les identités sans fusion dangereuse
Séparer rapprochement et fusion
Le rapprochement propose que deux enregistrements représentent la même réalité ; la fusion décide de leur identité cible et déplace leurs dépendances. Les confondre rend l’opération irréversible. Les candidats sont calculés à partir de signaux expliqués — identifiant légal, adresse normalisée, domaine, contrat — puis classés selon une confiance qualifiée par le métier.
Aucun score générique ne décide seul. Une similarité forte sur le nom peut être trompeuse pour des franchises, tandis qu’un identifiant légal identique peut refléter plusieurs établissements qu’il faut conserver. La règle précise les champs discriminants, les exclusions et l’autorité de validation. Les cas ambigus reçoivent un identifiant de corrélation temporaire plutôt qu’une fusion forcée.
Une table de correspondance garde tous les identifiants historiques, leur source, leur période de validité et l’identifiant ERP cible. Elle ne remplace pas les données métier : elle garantit la continuité des références. Les contraintes d’unicité et de référence du modèle cible s’appuient sur les mécanismes documentés dans les contraintes PostgreSQL, mais la base ne peut pas inventer la décision de fusion.
Installer un sas entre héritage et ERP
Conserver une zone brute immuable
Le sas reçoit un export identifié, horodaté et contrôlé par somme. La zone brute n’est jamais corrigée en place. Une zone normalisée applique ensuite les règles versionnées, puis une zone candidate prépare le modèle ERP. Cette séparation permet de relancer une version de mapping sur la même entrée et de comparer précisément les sorties.
Le sas protège aussi l’ERP d’un débit irrégulier et d’une structure héritée. Il ne doit cependant pas devenir une seconde application maître. Sa rétention, ses accès et sa purge sont définis. Les données personnelles y restent minimisées et chiffrées selon le contexte, et les opérateurs ne disposent que des droits nécessaires à l’analyse des anomalies qui leur sont attribuées.
Publier par lots identifiables
Chaque lot possède un périmètre, une version de contrat et un statut. L’écriture vers l’ERP utilise une clé idempotente afin qu’un retry ne crée pas un second tiers ou une seconde commande. La réponse stocke l’identifiant cible, le verdict et le motif technique. Un lot partiellement refusé n’est jamais marqué « réussi » parce que le transport HTTP a répondu.
La reprise sélectionne des éléments par état explicite, pas par date approximative. Elle distingue erreur transitoire, rejet métier et dépendance manquante. Une file de retry bornée traite les indisponibilités, tandis que les rejets métier attendent une correction ou une décision. Cela empêche une donnée fausse de tourner sans fin et de masquer les pannes nouvelles.
Prouver le résultat par rapprochement
Comparer quantités, montants et états
Un rapprochement complet ne compare pas seulement le nombre de lignes. Il contrôle les sommes sensibles, les distributions de statuts, les relations et les effets produits. Pour une migration de factures, le nombre peut coïncider alors que les taxes divergent. Pour un stock, le total global peut être identique tout en déplaçant des unités entre dépôts.
La balance associe chaque écart à une cause connue : rejet accepté, transformation attendue, donnée corrigée ou anomalie inconnue. Les écarts inconnus bloquent selon leur impact local. Une différence de quelques centimes peut être acceptable sur un calcul qualifié et inadmissible sur une écriture légale ; le seuil est écrit par le propriétaire métier, testé et lié à une action de repli.
Le rapport de lot montre entrée, acceptés, corrigés, quarantaines, rejets et sorties ERP. Ces catégories se recomposent sans trou ni double compte. Un échantillon peut alors être remonté depuis l’écran ERP jusqu’à la donnée brute, et inversement. Cette double traçabilité transforme la recette en preuve exploitable pendant le support.
Cas concret : deux clients deviennent un compte
Une fusion plausible qui déplace des factures
Cas concret hypothétique : deux fiches partagent le même numéro légal, mais représentent un siège et un établissement facturé séparément. Le rapprochement automatique propose une fusion. Si elle est exécutée, les commandes historiques basculent vers une condition de paiement différente et le portail n’affiche plus le bon encours. La donnée semblait dupliquée ; la relation métier ne l’était pas.
La recette conserve les deux identités ERP, relie leur personne morale commune et migre les factures avec leur compte contractuel. Un opérateur nouveau doit retrouver la proposition, comprendre son refus et vérifier les soldes sans tableur privé. Si le mapping ou le motif manque, l’import du segment reste en pause. La preuve attendue est la continuité de la commande à la facture, pas la disparition maximale des doublons.
Pour qui cette méthode est-elle nécessaire ?
Elle concerne les équipes qui remplacent un ERP, connectent un historique hétérogène ou absorbent plusieurs filiales. Les rôles minimum sont un propriétaire métier par objet, data ou intégration, sécurité, exploitation et support. Le métier décide le sens ; l’équipe technique rend la décision exécutable et observable. Aucun responsable unique ne peut certifier identité, fiscalité, droits et reprise.
Une petite migration peut appliquer le même raisonnement avec des outils simples : requêtes versionnées, table de correspondance et rapport de lot. Une consolidation multi-entités demandera orchestration, sas et workflow de validation. Le niveau d’industrialisation dépend du nombre de sources, de la fréquence des échanges et du coût d’une erreur, pas du prestige de la plateforme.
Erreurs fréquentes face aux données sales
La première erreur attend un grand nettoyage sans définir le modèle cible. La deuxième corrige directement la source sans trace. La troisième confond valeur obligatoire et valeur vraie. La quatrième importe une valeur par défaut pour faire passer la contrainte. La cinquième mesure uniquement les rejets techniques, alors que les erreurs les plus coûteuses sont souvent des lignes acceptées avec un mauvais sens.
Autres pièges : supprimer les identifiants historiques, fusionner au score, relancer tout un lot après une panne partielle ou laisser une quarantaine sans owner. Enfin, la recette sur un échantillon trop propre donne une fausse sécurité. Les cas rares, anciennes périodes et corrections tardives doivent être joués avant que l’ERP produise des écritures difficiles à annuler.
Mettre en œuvre des flux rejouables
Rendre chaque étape observable
L’entrée est un lot immuable accompagné de son contrat ; la sortie est un ensemble de verdicts reliés aux identifiants ERP. Chaque dépendance possède timeout, stratégie de retry et seuil d’alerte. La journalisation conserve corrélation, version de mapping et cause, sans recopier inutilement les données sensibles. Le monitoring sépare débit, latence, rejets fonctionnels et erreurs techniques.
Le runbook indique qui agit lorsqu’un seuil est franchi. Une indisponibilité ERP déclenche une pause et un retry borné ; un conflit d’identité passe à l’owner métier ; un rapprochement inconnu bloque le périmètre concerné. Le repli peut désactiver la publication tout en gardant le sas alimenté. Il ne consiste jamais à supprimer silencieusement les lignes déjà créées.
Tester la reprise avant le volume
La recette interrompt le flux après l’écriture ERP mais avant l’accusé de réception. Au redémarrage, l’idempotence doit retrouver l’objet existant et compléter le journal sans doublon. Un second test modifie une règle de mapping : l’équipe rejoue sur une copie, compare les verdicts et décide explicitement quels objets déjà publiés nécessitent compensation.
Les tests incluent perte de réseau, fichier incomplet, dépendance lente, ordre inversé et correction concurrente. Chacun possède entrée, sortie attendue, owner et preuve. La capacité à diagnostiquer avec les mêmes droits qu’en production fait partie du résultat. Un flux que seul son développeur sait reprendre n’est pas prêt, même si tous les scénarios nominaux passent.
Décider ce qui bloque vraiment le go
Le comité classe les écarts en bloquants, acceptables temporairement et différables. Bloque ce qui peut produire un effet légal faux, perdre une relation essentielle, exposer un autre périmètre ou empêcher la reprise. Une anomalie secondaire peut être acceptée si son volume est borné, son owner nommé, sa correction possible et son impact visible. Cette règle évite le « zéro défaut » irréaliste comme le « on verra après » dangereux.
Le verdict s’appuie sur tendances et scénarios : stabilité des rapprochements, âge des cas critiques, réussite des reprises et autonomie du support. Si le même défaut réapparaît après correction, l’équipe revoit la règle plutôt que d’augmenter la capacité manuelle. Le calendrier n’annule pas le seuil ; il impose de réduire le périmètre ou de choisir un mode transitoire explicite.
Plan d’action en huit semaines
Semaines 1 et 2 : fermer modèle et responsabilités
L’équipe choisit trois parcours critiques et dresse les objets, champs, relations et effets. Elle désigne la propriété champ par champ, extrait un lot reproductible et documente les contraintes ERP. Les premières requêtes mesurent identités ambiguës, références orphelines et incohérences de domaine. Le résultat est une carte de risque, pas un backlog indifférencié de nettoyage.
Semaines 3 à 5 : construire le sas et les preuves
Le sas conserve brut, normalisé et candidat. Les règles déterministes sont testées, les ambiguïtés rejoignent la quarantaine et les identifiants croisés sont versionnés. Un lot pilote traverse l’ERP, puis la balance vérifie quantités, montants, statuts et relations. L’équipe provoque une panne partielle et confirme l’idempotence avant d’augmenter le volume.
Semaines 6 à 8 : exercer le support et décider
Des utilisateurs métier exécutent les parcours de bout en bout. Le support reçoit un dossier sans explication orale, retrouve sa chronologie et applique le runbook. Les écarts critiques sont corrigés ou retirés du périmètre. Le go/no-go relit balance, quarantaine, incidents et capacité de repli avec les responsables qui devront agir après bascule.
Le rapport final conserve hypothèses, règles, seuils et dettes acceptées. Il précise aussi comment absorber les nouvelles écritures produites entre extraction et bascule. D’abord, stabiliser le modèle et l’identité ; ensuite, prouver le flux sur un lot contradictoire ; puis seulement élargir. Une date ne devient confirmée que lorsque le retour arrière est réalisable dans le temps accordé par le métier.
- D’abord, nommer les propriétaires et refuser les transformations sans trace.
- Ensuite, tester identité, relations et calculs sur un lot représentatif.
- Puis, contrôler rapprochement, quarantaine, idempotence et reprise.
- Enfin, décider l’extension selon les effets métier et l’autonomie du support.
Guides complémentaires pour fiabiliser l’intégration
Relier propriété et synchronisation
Le guide de la synchronisation bidirectionnelle aide à limiter les champs modifiables des deux côtés, tandis que l’idempotence des intégrations sécurise les reprises après une réponse perdue.
Éprouver l’exploitation
Les tests de workflows à exceptions structurent les cas dégradés, et l’observabilité métier relie incidents, objets et décisions.
- Relire la propriété des champs avant toute correction automatique.
- Rapprocher chaque lot avant de publier le suivant.
- Conserver une reprise testée pour chaque effet externe.
Conclusion : intégrer sans maquiller la donnée
Une intégration ERP fiable ne transforme pas un historique ambigu en vérité par simple import. Elle expose les défauts, préserve leur provenance et applique des décisions explicites. Le sas, la matrice de propriété et le rapprochement empêchent la contrainte technique de masquer une erreur métier.
La priorité va aux identités, relations et effets irréversibles. Le reste peut être corrigé progressivement si la quarantaine est gouvernée et si le périmètre demeure lisible. Une solution plus étroite, prouvée sur un cycle réel, vaut mieux qu’un chargement complet dont personne ne sait expliquer les écarts.
Dawap peut cadrer ce diagnostic, construire les flux rejouables et accompagner la bascule dans une stratégie de développement web sur mesure. L’objectif est concret : que métier, support et exploitation puissent retrouver chaque décision, corriger sans improviser et étendre seulement lorsque les preuves le permettent.
