RCU B2B : relier entreprises, établissements et comptes clients sans tout confondre

Commencer par trois questions : qui achète, qui reçoit, qui paie ?

Le commerce compte 800 clients, la finance 1 150 comptes et les opérations 1 600 lieux desservis. Ces chiffres peuvent être simultanément corrects. Une même société peut disposer de plusieurs comptes de facturation, commander pour plusieurs établissements et appartenir à un groupe suivi par un responsable commercial unique. Nettoyer les doublons avant de comprendre ces différences risque de supprimer des distinctions nécessaires.

Le référentiel client unique, ou RCU, doit rendre les relations explicables. Pour chaque usage, précisez l’objet compté et le rôle recherché : cocontractant, donneur d’ordre, payeur, destinataire ou groupe commercial. Ces rôles peuvent être portés par des entités différentes. Une adresse de livraison n’identifie pas automatiquement le débiteur d’une facture.

Commencez par un parcours concret, de l’opportunité au règlement. Sur quelques dossiers réels, demandez aux équipes de désigner chaque acteur et de montrer les identifiants utilisés. Le premier livrable utile est un modèle d’identité partagé, accompagné de cas ambigus arbitrés ; la liste des champs à centraliser vient ensuite.

SIREN, SIRET et compte client : trois niveaux différents

L’Insee attribue un SIREN de neuf chiffres à une unité légale, qui peut être une personne morale ou un entrepreneur individuel. Cette unité juridique se distingue de l’entreprise au sens statistique, laquelle peut combiner plusieurs unités légales. Le SIRET, composé de quatorze chiffres dont les neuf premiers correspondent au SIREN, identifie un établissement rattaché à cette unité légale.

Un compte client est, lui, un objet de votre organisation : il peut représenter une relation commerciale, un périmètre de facturation ou une organisation de vente. Il n’existe pas de correspondance universelle entre un compte CRM et un SIREN. Décrivez le niveau de chaque compte avant de le rapprocher, surtout si les commerciaux utilisent parfois une fiche pour un groupe entier.

Distinguez aussi établissement administratif et site opérationnel. Un campus peut accueillir plusieurs exploitants ; un périmètre de maintenance peut couvrir plusieurs établissements. Modélisez ces correspondances explicitement. À l’international, conservez le pays, le registre émetteur et le type d’identifiant ; n’exigez pas artificiellement un SIREN pour toute organisation.

Conserver les comptes sources dans un modèle de correspondance

Attribuez des identifiants internes distincts aux unités légales, établissements et autres objets maîtrisés. Les identifiants administratifs sont des références externes, avec leur provenance et leur statut de vérification. Gardez les comptes CRM et ERP comme des objets reliés au référentiel : plusieurs comptes valides peuvent désigner une même unité légale sans devoir fusionner dans leurs applications.

Une correspondance exploitable contient au minimum le système, son périmètre local — société ERP ou instance CRM, par exemple —, le type d’objet, son code, la cible RCU, le rôle du lien et sa validité. Le code 0042 seul ne suffit pas : il peut désigner deux clients différents dans deux ERP. Un code réutilisé nécessite également une gestion temporelle.

Séparez la décision d’identité du choix des attributs de référence. Deux comptes peuvent désigner la même société tout en conservant des adresses de facturation ou des conditions commerciales différentes. La dénomination administrative, l’enseigne, le nom commercial saisi et l’adresse opérationnelle remplissent des fonctions distinctes. Documentez leur autorité attribut par attribut, au lieu d’écraser les données avec une fiche supposée meilleure sur tous les champs.

Exemple fictif : deux CRM, un ERP et plusieurs comptes à préserver

Imaginons Atelier Boréal SAS, avec deux établissements. Les repères SIREN-A, SIRET-A1 et SIRET-A2 ci-dessous sont des symboles fictifs, pas des numéros administratifs. Le CRM historique suit la société ; un second CRM suit son établissement de Lyon ; l’ERP dispose de deux comptes de facturation. Le résultat attendu conserve chacun de ces objets et expose leurs liens.

Une autre société, Boréal Services SAS, utilise la même marque et le même standard téléphonique. Son SIREN distinct interdit de conclure à une identité juridique commune sur ces seuls signaux. Elle peut rejoindre le même périmètre commercial, mais reste une unité légale séparée.

• Trois comptes au niveau de l’unité légale — CRM-A/0042, C100 et C900 — sont conservés ; la fiche CRM-B/0042 décrit un établissement et reste également distincte.
• Si C100 porte 80 000 € et C900 20 000 € de factures distinctes, sur la même période et selon la même définition, le total d’UL-A est 100 000 €. Ces montants sont illustratifs.
• La jointure aux établissements ne doit pas dupliquer les factures : rattachez chaque transaction à ses rôles, sans distribuer automatiquement le chiffre d’affaires sur tous les sites.
• Une facture adressée à UL-B pour un service rendu à UL-A conserve séparément la partie facturée, le bénéficiaire et, s’il diffère, le payeur. Le regroupement commercial ne change pas ces rôles.

Calibrer les rapprochements contre le risque de fausse fusion

Un SIREN identique, vérifié dans le registre et cohérent avec la fiche, est une preuve forte pour rapprocher deux unités légales ; il ne justifie pas de fusionner leurs établissements ou comptes. Un SIRET identique se traite au niveau établissement. Une clé syntaxiquement correcte peut être celle d’un tiers, ou avoir été copiée par défaut : contrôlez sa cohérence avec le contexte métier.

Sans identifiant fiable, combinez nom, adresse, pays et autres éléments disponibles pour proposer des candidats. Les homonymes, franchises, domiciliations et enseignes partagées doivent figurer dans le jeu de validation. Un score de similarité ne devient une probabilité de correspondance qu’après une calibration démontrée ; aucun seuil numérique ne convient universellement.

Distinguez validation automatique, revue humaine et maintien séparé. Les contradictions d’identifiants bloquent une fusion automatique et déclenchent une enquête. Mesurez la justesse sur des cas annotés indépendamment des règles, par source et population. Vérifiez aussi les groupes de fiches : si A ressemble à B et B à C, cela ne prouve pas que A et C désignent la même société.

Conservez la preuve, la version de règle et l’auteur de chaque rapprochement. Une défusion doit restaurer les liens sources et produire des corrections vers les consommateurs ; elle nécessite aussi d’identifier les décisions déjà prises sur l’identité erronée.

Séparer contrôle capitalistique et regroupement commercial

L’Insee définit un groupe de sociétés à partir d’une société contrôlante et des sociétés qu’elle contrôle. Une marque commune, un accord commercial ou un réseau de franchise ne prouve pas cette relation. Le SIREN de la société mère identifie cette unité légale, pas à lui seul l’ensemble du groupe.

Maintenez donc des hiérarchies nommées : contrôle juridique, négociation commerciale, organisation territoriale ou périmètre de service. Une centrale peut négocier pour des adhérents juridiquement indépendants. Ce regroupement est utile au commerce, mais ne suffit pas pour déterminer une solidarité de paiement ou une exposition juridique.

Chaque relation porte un type, une source, un responsable et une période de validité. Signalez les rattachements non confirmés et contrôlez les cycles. Si plusieurs regroupements se chevauchent, leur chiffre d’affaires ne s’additionne pas sans règle d’allocation. L’écran et le rapport doivent annoncer la hiérarchie utilisée, plutôt qu’afficher un ambigu « chiffre d’affaires groupe ».

Historiser les changements sans transformer une reprise en doublon

Le SIREN n’est pas réattribué après la disparition de l’unité légale. L’Insee distingue aussi un transfert d’activité, qui conduit à un nouveau SIRET, d’une simple renumérotation de voie, qui conserve le SIRET. Une variation d’adresse n’autorise donc ni une fusion ni une création systématique d’identité : qualifiez l’événement.

Lors d’une acquisition, d’une fusion ou d’une reprise d’établissement, vérifiez quelles entités subsistent et quelles relations changent. Une succession n’est pas une égalité d’identité. Conservez les anciens identifiants pour lire les transactions historiques et créez les relations nécessaires vers les successeurs, avec leurs dates d’effet et leurs justificatifs.

Distinguez date d’effet métier et date de réception de l’information. Une acquisition effective le 1er juillet mais chargée le 10 juillet doit pouvoir être analysée selon le périmètre historique ou le périmètre actuel, explicitement choisi. La seconde vue constitue une relecture : elle ne doit pas remplacer silencieusement les chiffres déjà publiés. Tester un événement tardif est aussi important que tester le chargement initial.

Enrichir avec Sirene sans confondre absence et incohérence

Conservez la date de consultation, le statut administratif et le statut de diffusion des données externes. Une information absente peut résulter d’une diffusion partielle : l’Insee précise que certains éléments d’identification ou de localisation peuvent être masqués, tandis que des identifiants et d’autres informations restent visibles. Ne classez pas automatiquement ces fiches comme erronées et ne réinjectez pas une ancienne valeur masquée sans examiner son usage et les restrictions applicables.

Les contacts professionnels constituent un domaine distinct : une personne peut changer d’employeur, représenter plusieurs organisations ou partager une adresse fonctionnelle avec une équipe. Modélisez le lien entre personne, organisation et fonction avec sa validité. Un rapprochement de sociétés n’emporte pas une fusion des contacts ni une autorisation commune de prospection.

La CNIL rappelle que l’accessibilité publique de données personnelles ne rend pas leur réutilisation libre de contraintes. Définissez les finalités, accès, durées et modalités d’exercice des droits avec les responsables compétents. Le besoin d’identifier une partie à un contrat et celui d’alimenter une campagne commerciale doivent être examinés séparément.

Mesurer les erreurs évitées et organiser leur traitement

Le responsable du domaine arbitre les règles d’identité ; les gestionnaires de données traitent les exceptions avec la finance, le commerce et les opérations. Une ambiguïté sur le débiteur nécessite une validation adaptée à la facturation, tandis qu’un regroupement commercial relève d’un autre arbitrage. Réservez une capacité de traitement et priorisez selon le risque opérationnel.

Un taux de rapprochement élevé peut cacher des fusions abusives. Combinez couverture et justesse, puis segmentez les résultats : comptes français ou étrangers, sources, unités légales ou établissements. Les cas encore en revue restent visibles dans le dénominateur pertinent ; les exclure embellirait artificiellement la performance.

Préparer la mise en service comme une migration de relations

Lancez un pilote sur un périmètre représentatif, incluant comptes multiples, clients étrangers, identifiants absents, établissements fermés et changements de groupe. Comparez les résultats avec les équipes qui utilisent effectivement les contrats, factures et rapports. Le succès se mesure dans leur capacité à retrouver les bons objets et à expliquer les écarts.

Documentez le contrat de données fourni aux applications : sens de chaque identifiant, rôles, cardinalités, dates d’effet, version de schéma et traitement des rejets. Un rattachement RCU est une information de référence ; il ne transfère pas, à lui seul, un contrat ni une créance entre entités. Toute modification opérationnelle de ce type suit la validation métier appropriée.

• Inventorier les contrats et comptes concernés, avec parties, payeurs, bénéficiaires et identifiants sources préservés.
• Réconcilier factures, encours et montants sur un périmètre et une date identiques ; expliquer chaque écart.
• Tester création, changement d’adresse, fermeture, succession, rattachement tardif et annulation d’une fusion.
• Vérifier la propagation dans chaque consommateur, les reprises sans doublons et les restrictions d’usage.
• Prévoir retour arrière, file d’exceptions attribuée et suivi après bascule ; conserver les preuves de validation.

Questions fréquentes