Nettoyer et enrichir des données de prospection sans industrialiser les erreurs

Un export CRM contient souvent plusieurs vérités concurrentes : raison sociale saisie par un commercial, domaine trouvé par un outil, effectif issu d’un fournisseur et adresse récupérée lors d’un formulaire. Une fusion naïve choisit la valeur la plus récente ou la plus longue. Elle peut alors remplacer une donnée exacte par une donnée fraîche mais rattachée à la mauvaise entité.

Le danger grandit avec l’automatisation : une erreur isolée devient une règle appliquée à des milliers de lignes, puis alimente un segment, un score et une campagne. La qualité doit donc être conçue comme une chaîne de décisions réversibles.

Le défaut se propage lorsqu’on écrase la preuve

La première règle est simple : la valeur source ne doit jamais disparaître. Dans cet exemple fictif, une table normalisée peut afficher « ACME INDUSTRIE », mais le système doit encore savoir que le CRM contenait « Acme Ind. », que le répertoire officiel indiquait une autre dénomination à une date donnée et que le domaine web a été rapproché par une règle distincte.

Sans ce journal, trois erreurs deviennent indiscernables :

• erreur de source : l’information était déjà fausse ou périmée ;
• erreur de rapprochement : la bonne information a été attribuée à la mauvaise organisation ;
• erreur de transformation : une règle a mal interprété une valeur correcte.

Chacune exige une correction différente. Réinterroger le fournisseur ne résout pas une jointure incorrecte. Modifier la normalisation ne corrige pas une source obsolète. Un pipeline réparable conserve donc la valeur brute, la règle, sa version, l’horodatage et le résultat.

L’ordre des opérations

L’ordre évite que l’enrichissement ne maquille les défauts :

1. Geler un état d’entrée. Numéro de lot, date, origine, nombre de lignes et empreinte du fichier. Aucun traitement ne modifie directement l’original.
2. Valider la structure. Types, encodage, colonnes attendues, identifiants manifestement invalides et dates impossibles.
3. Normaliser sans décider. Casse, espaces, téléphone ou URL peuvent recevoir une représentation comparable, tout en gardant la valeur initiale.
4. Résoudre les organisations. Utiliser les identifiants fiables, puis seulement des règles probabilistes bornées.
5. Dédupliquer les enregistrements. Regrouper les lignes qui pointent vers la même entité, sans fusionner encore leurs valeurs contradictoires.
6. Appliquer les restrictions. Statut de diffusion, opposition, exclusion et durée d’utilité doivent bloquer les traitements incompatibles avant enrichissement.
7. Enrichir par attribut. Une source et une règle de priorité propres à chaque champ.
8. Calculer les vues d’usage. Segments, scores et files de travail sont reconstruits depuis les données validées ; ils ne sont pas la vérité primaire.

Cette séquence doit être rejouable. Si une règle de rapprochement change, l’équipe doit pouvoir recalculer le résultat depuis les sources sans corriger manuellement des centaines de fiches.

Résoudre l’organisation avant la personne

En B2B, le SIREN identifie une unité légale et le SIRET un établissement. Ils ne sont pas interchangeables. Une entreprise peut avoir plusieurs établissements, fermer un site, déplacer son siège ou changer de dénomination sans devenir nécessairement une nouvelle entité commerciale.

Commencez par une hiérarchie de preuves :

1. SIREN ou SIRET présent et valide dans une source de référence ;
2. identifiant stable fourni par une source contractuelle avec règle de correspondance documentée ;
3. combinaison raison sociale, adresse et domaine avec seuil strict ;
4. revue humaine lorsque plusieurs candidats restent plausibles.

Le domaine ne doit pas être une clé unique. Un groupe peut utiliser le même domaine pour plusieurs sociétés ; un prestataire peut héberger plusieurs marques ; un domaine peut expirer ou rediriger. De même, le nom normalisé ne suffit pas : les formes juridiques, enseignes et homonymes créent des collisions.

Une décision de rapprochement devrait conserver :

Élément	Exemple de contenu	Usage
Candidat A	Identifiant de l’organisation	Entité proposée
Preuves positives	Identifiant exact, adresse cohérente	Pourquoi le lien semble correct
Contradictions	Domaine différent, établissement fermé	Pourquoi la décision reste risquée
Règle et version	match-org-v3	Reproduire le calcul
Issue	Confirmé, rejeté, à revoir	Empêcher la fusion silencieuse

La Base Sirene offre un référentiel d’unités légales et d’établissements. Sa fiche de diffusion rappelle la nécessité de tenir compte du statut le plus récent, particulièrement pour certaines personnes physiques. Le RNE de l’INPI apporte des informations issues des formalités. Ces sources se complètent, mais leurs champs, périmètres et dates doivent rester visibles.

Enrichir champ par champ

Un enrichissement fiable ne remplace pas une fiche entière par celle d’un fournisseur. Il décide séparément pour chaque attribut.

• Identité légale : privilégier le producteur officiel compétent et conserver le millésime.
• Adresse d’établissement : distinguer adresse officielle, adresse postale et lieu d’activité observé.
• Activité : ne pas confondre code NAF, description déclarée et offre réellement visible sur le site.
• Effectif : garder la tranche, l’année de référence et la source ; une estimation actuelle ne doit pas écraser une mesure officielle plus ancienne sans explication.
• Domaine : conserver la méthode d’association, la date de vérification et l’état de la redirection.
• Signal commercial : stocker l’événement, sa preuve, sa date et sa date d’expiration, non une conclusion définitive sur l’intention.

Chaque valeur enrichie peut être représentée comme un petit paquet : value, source, observed_at, valid_from si connu, confidence, rule_version et expires_at. La confiance porte sur le rattachement ou la mesure, pas sur une impression commerciale générale.

Cette granularité rend possible une interface centrale sans créer une vérité artificielle. Notre article sur la centralisation des données dans une seule interface décrit l’enjeu d’usage ; ici, la provenance garantit que cette interface peut expliquer ce qu’elle affiche.

Traiter les conflits et valeurs manquantes

Une valeur manquante n’est pas une valeur nulle. Elle peut signifier « non publié », « non applicable », « collecte échouée », « masqué » ou « pas encore recherché ». Ces états doivent rester distincts, car ils n’autorisent pas les mêmes actions.

Lorsqu’un conflit apparaît, quatre sorties sont préférables à un écrasement automatique :

• priorité déterministe : une source fait autorité pour ce champ précis ;
• valeurs simultanées : les informations décrivent des dates ou périmètres différents ;
• expiration : l’ancienne valeur reste dans l’historique mais sort de la vue active ;
• quarantaine : aucune règle ne permet une décision sûre, une revue est requise.

La quarantaine ne doit pas devenir une corbeille oubliée. Elle a un propriétaire, une cause, une priorité, une date limite et une action de clôture. Les mêmes principes qu’une file de reprise pour les erreurs d’automatisation s’appliquent : reprendre ce qui peut l’être, arrêter ce qui resterait ambigu et apprendre des causes récurrentes.

Exactitude, durée et droits

Obligation : l’article 5 du RGPD prévoit notamment que les données personnelles soient exactes et, si nécessaire, tenues à jour ; les données inexactes doivent être effacées ou rectifiées sans tarder au regard des finalités. Le même article pose la minimisation et la limitation de conservation.

Obligation selon le contexte : en cas de collecte indirecte, l’article 14 prévoit des informations comprenant la source des données, et le cas échéant leur caractère publiquement accessible. Les droits d’accès, de rectification et d’opposition doivent pouvoir être exercés.

Recommandation : relier les demandes de droits au registre de provenance. Une rectification ne doit pas être annulée au prochain import par une source moins récente. Une opposition doit alimenter une liste dédiée avant les exports et les recalculs.

La CNIL indique, dans son référentiel commercial, une durée de trois ans pour les données de prospects utilisées à des fins de prospection à compter de la collecte ou du dernier contact émanant du prospect. Cette référence ne dispense pas de fixer une durée plus courte pour un signal rapidement périssable. La date d’utilité commerciale et la durée de conservation juridique ne sont pas la même chose.

Installer une qualité continue

Les tests doivent couvrir les transformations et les décisions :

• tests de contrat : colonnes, types, valeurs autorisées et schéma de chaque source ;
• tests d’identité : cas exacts, homonymes, établissements multiples, fermetures et fusions ;
• tests de non-régression : un lot de cas validés conserve la même issue après modification ;
• tests de droits : opposition, rectification, suppression et restriction résistent à un nouvel import ;
• tests de reprise : une exécution interrompue peut reprendre sans dupliquer ni perdre les preuves ;
• tests de dérive : une variation brutale du taux de valeurs manquantes ou de conflits déclenche une alerte.

Les cas de test doivent être synthétiques ou anonymisés. Ils représentent les difficultés sans recopier une base réelle. Une revue humaine périodique compare un échantillon au document source et classe les erreurs par cause ; elle ne se contente pas d’un pourcentage global.

Le tableau de bord des erreurs

Un bon tableau de bord de qualité répond à des questions actionnables :

Indicateur	Question	Action possible
Couverture par champ et source	Quelle absence est structurelle ?	Retirer un champ ou changer de source
Âge médian et maximum	Quelle information est trop vieille ?	Rafraîchir ou expirer
Taux de rapprochement ambigu	La clé d’identité est-elle suffisante ?	Durcir la règle ou ajouter une preuve
Conflits par attribut	Quelle priorité de source est défaillante ?	Réviser la règle de fusion
Corrections annulées	Un import réintroduit-il des erreurs ?	Protéger les décisions validées
Quarantaine par cause	Quel défaut consomme le temps humain ?	Corriger à la source ou automatiser prudemment

Ajoutez un indicateur métier : part des fiches réellement utilisables pour la décision prévue. Une base peut être techniquement complète et commercialement inutile. Inversement, quelques champs fiables peuvent suffire pour choisir une recherche manuelle. La fiabilité d’une automatisation se mesure elle aussi au résultat correct, récupérable et produit à temps.

Le nettoyage durable n’est donc pas une opération cosmétique. C’est l’installation d’un système capable de se corriger. Forge Labs peut étudier ponctuellement la conception de ces chaînes de données lorsque l’enjeu porte sur la provenance, la décision et l’exploitation, plutôt que sur l’achat d’un fichier supplémentaire.

Sources

• Union européenne — Règlement (UE) 2016/679, notamment articles 5 et 14.
• data.gouv.fr / Insee — Base Sirene, fiche consultée le 27 septembre 2026.
• INPI — Le Registre national des entreprises.
• CNIL — Référentiel relatif aux traitements de données personnelles aux fins de gestion des activités commerciales.
• CNIL — RGPD, droits de la personne concernée.