Le CRM connaît « Dupont Industrie », l’outil de facturation « Dupont SAS » et la maintenance « Site Dupont Nord ». Un commercial corrige l’adresse, mais la facture suivante repart vers l’ancienne. Une fusion automatique serait risquée : l’organisation, le compte de facturation et le site opérationnel ne représentent peut-être pas le même objet.
Créer un référentiel commun semble alors évident. Pourtant, centraliser trop tôt peut ajouter une quatrième base et un nouveau point de blocage. Le problème n’est pas le nombre de systèmes ; c’est l’absence d’identité partagée, d’autorité explicite et de règles de propagation. Un référentiel ne crée pas cette gouvernance par sa seule présence.
Le vrai enjeu est de partager une décision, pas de posséder une base de plus. Le bon chantier commence donc par une question concrète à rendre cohérente : où livrer, qui facturer, quel produit vendre, quel contrat appliquer. Il définit l’objet, les attributs de référence, les copies nécessaires et les propriétaires. L’architecture vient ensuite, dimensionnée par les volumes, les délais et la tolérance au mode dégradé.
Dans une trajectoire de développement web sur mesure, le référentiel devient utile s’il réduit les arbitrages manuels tout en restant exploitable. Ce guide couvre le choix, l’implémentation et le run.
Reconnaître un problème de référence
Les symptômes sont les rapprochements récurrents, les corrections annulées par un import, les identifiants traduits dans des tableurs et les rapports impossibles à recoller. Cherchez surtout l’impact : contrat appliqué au mauvais client, catalogue incohérent, intervention sur un ancien site ou droit accordé à la mauvaise entité.
Mesurez sur un flux : nombre de créations, doublons candidats, conflits d’attribut, interventions et délai de propagation. Un problème de reporting seul peut relever d’une vue analytique. Un problème qui change une décision opérationnelle et se reproduit dans plusieurs systèmes justifie davantage un contrat de référence.
Distinguer copie et autorité
Une copie locale n’est pas fautive si elle porte l’identifiant canonique, la version source et une politique de fraîcheur. Elle devient une vérité concurrente quand elle accepte des corrections sans règle de retour. Le référentiel doit dire quelles écritures sont autorisées, pas interdire toute donnée locale.
Choisir le bon objet métier
Clients, produits, contrats et sites n’ont pas les mêmes cycles. Un client peut être une personne, une organisation, un groupe ou un compte commercial. Un produit générique se décline en variantes et offres. Un contrat relie parties, périmètre et période. Un site possède adresse, équipements et rattachements qui évoluent.
Écrivez la décision servie par chaque objet. L’adresse de facturation appartient-elle au client, au contrat ou au compte payeur ? Le prix appartient-il au produit, à l’offre ou à la négociation ? Tant que ces questions restent ouvertes, centraliser les champs figera les ambiguïtés au lieu de les résoudre.
Ne pas créer un objet universel
Une table « tiers » peut partager une identité technique sans confondre fournisseur, partenaire et client. Les rôles, relations et obligations restent explicites. Un modèle trop générique déplace le sens dans des codes, des extensions et des conventions que chaque consommateur interprète différemment.
Définir identité et granularité
L’identifiant interne reste stable et sans signification. Les codes externes deviennent des aliases liés à une source, un périmètre et une période. Une référence peut être unique par fournisseur ou par filiale, pas globalement. Les contraintes techniques reflètent exactement ce périmètre.
Pour PostgreSQL, les contraintes UNIQUE et multicolonnes peuvent protéger les clés certaines ; NULLS NOT DISTINCT traite explicitement certains cas nuls. Elles ne prouvent pas que deux noms proches sont la même organisation. Le rapprochement probabiliste reste une proposition explicable et revue.
Conserver aliases et fusions
Une fusion garde les anciennes références, le motif, l’auteur et une redirection vers l’objet canonique. Les relations sont comptées avant et après. Une défusion préparée protège les faux positifs. Supprimer immédiatement le perdant crée des objets orphelins et rend les anciens messages incompréhensibles.
Attribuer l’autorité par attribut
Un système n’est pas maître de tout un objet par décret. Le CRM peut proposer le nom d’usage, la facturation posséder l’identité légale et le terrain maintenir les coordonnées d’accès. La matrice d’autorité précise attribut, source, validation, date d’effet et mécanisme de conflit.
La récence ne gagne pas automatiquement. Une importation tardive peut être plus récente mais moins fiable qu’une validation officielle. Conservez provenance et version. Lorsqu’une source perd son autorité, migrez le contrat et les consommateurs ; ne changez pas silencieusement l’ordre de priorité dans un job.
Organiser la contribution
Les systèmes locaux soumettent une proposition avec motif et preuve. Le référentiel accepte, refuse ou met en revue selon l’attribut. Cette boucle rend la correction visible à tous. Elle évite que les utilisateurs créent une copie parallèle parce qu’ils ne peuvent pas signaler une erreur.
Choisir registre, service ou fédération
Un registre rapproche les identités et garde les références tandis que les attributs restent dans leurs systèmes. Un référentiel consolidé maintient une vue canonique. Un service transactionnel devient l’unique point d’écriture pour un objet. Une fédération expose des contrats communs tout en laissant plusieurs domaines propriétaires.
Choisissez selon la décision et le couplage acceptables. Un appel synchrone obligatoire sur chaque écran rend le référentiel critique pour toute l’entreprise. Des projections locales améliorent la résilience mais exigent versions, fraîcheur et réconciliation. Le mode dégradé est une décision métier : lecture d’une copie, file d’attente d’écriture ou blocage explicite.
Éviter le nouveau monolithe de données
Le référentiel ne doit pas absorber commandes, paiements et interventions parce qu’ils « concernent le client ». Il porte identité et attributs réellement partagés. Les domaines conservent leurs décisions, reliées par identifiant. Cette frontière réduit les déploiements coordonnés et les modèles sans propriétaire.
Dimensionner disponibilité et sécurité
Classez les usages entre création critique, consultation interactive, traitement en lot et analyse. Une indisponibilité de quelques minutes n’a pas la même conséquence sur l’ouverture d’un contrat et sur l’enrichissement d’un tableau. Pour chaque classe, précisez délai admissible, copie autorisée et comportement d’écriture. Cette matrice commande réplication, files, cache et astreinte. Elle évite de financer une disponibilité uniforme tout en oubliant un parcours réellement bloquant.
Le modèle d’accès suit l’objet et le périmètre. Un identifiant partagé ne donne pas accès à tous ses attributs. Chiffrez les données sensibles, limitez les exports et journalisez les lectures à risque. Les projections ne doivent contenir que ce dont le consommateur a besoin. La révocation d’un droit ou l’effacement applicable se propage selon un contrat testé, y compris dans les caches et environnements non productifs.
Cas concret : référentiel de sites clients
Une entreprise de maintenance reçoit des demandes par CRM, portail et téléphone. Chaque outil crée une adresse. Les techniciens rencontrent des portails, zones et horaires différents pour un même établissement. L’équipe définit le site comme un lieu opérationnel stable, distinct de l’organisation cliente et du contrat de service.
Le référentiel attribue un identifiant au site, conserve les codes CRM et ERP, et versionne nom, coordonnées et accès. Le contrat rattache une période de couverture ; les équipements ont leurs propres identités. Une nouvelle adresse déclenche une revue si elle se trouve au-delà d’un seuil géographique qualifié sur les sites pilotes, sans fusion automatique.
Le pilote porte cinquante sites et trois flux. La recette cherche chaque site par ancien code, vérifie les interventions et provoque une correction concurrente. Le go local exige zéro intervention orpheline, une balance complète des relations et une explication du conflit par le support. Ces seuils protègent ce périmètre ; ils ne promettent pas une qualité universelle.
Publier des contrats de données
Le contrat expose schéma, sémantique, unités, valeurs possibles, optionalité, version et erreurs. Il décrit les commandes autorisées et les événements émis. Les consommateurs savent si une nouvelle propriété est compatible et comment traiter une valeur inconnue. Une description OpenAPI ou JSON Schema aide, mais le sens métier reste documenté.
Versionnez les changements incompatibles et annoncez une période de transition mesurée par l’usage réel. Les projections portent la version canonique. Les événements sont immuables ; une correction produit un nouvel événement ou une nouvelle version, pas une réécriture qui change l’histoire du consommateur.
Fermer les garanties de livraison
Avec une boîte de sortie transactionnelle, la modification et le message sont validés ensemble. Le consommateur est idempotent, journalise la version et ignore une répétition. Une réconciliation périodique compare identifiants, versions et totaux. Elle reste nécessaire même lorsque la messagerie est fiable.
Construire sans big bang
Les entrées initiales sont inventaire des sources, règles d’identité, matrice d’autorité et échantillon de conflits. La première sortie est un service étroit sur un objet et quelques attributs. Les dépendances sont explicites ; chaque lot possède journalisation, monitoring, retry, idempotence et procédure de rollback.
Commencez en observation : produisez identifiants et décisions sans remplacer les flux. Comparez aux usages existants, puis migrez une écriture et une projection. Le rollback suspend la nouvelle autorité sans perdre les identifiants créés. Un fichier de réconciliation compte objets, aliases, relations et conflits avant chaque extension.
Le service reçoit comme entrées l’identifiant externe, le périmètre, la version attendue et la contribution signée. Il renvoie l’identifiant canonique, les attributs autorisés, leur provenance et une version. Les dépendances sont isolées par adaptateur. Chaque commande journalise corrélation et résultat ; le monitoring mesure latence, refus, conflits, retries et retard des projections. Un contrat de fichier existe pour les reprises massives avec manifeste, checksum et accusé de traitement.
Traiter l’existant par catégories
Les cas certains sont rattachés automatiquement, les ambiguïtés vont en revue et les anomalies bloquantes sont corrigées à la source. La migration reste rejouable et reprend depuis un curseur. Chaque décision conserve la règle et sa version afin qu’un changement de seuil n’altère pas les fusions passées.
Exploiter qualité et synchronisation
Le tableau de santé suit créations, candidats, conflits, âge des projections, messages en erreur et anciennes références encore appelées. Chaque mesure a un propriétaire et une action. Un taux de complétude sans file de correction ne pilote rien. Un seuil d’arrêt est qualifié à partir de l’impact du flux local.
Contre-intuitivement, la meilleure preuve n’est pas la baisse rapide du nombre de doublons. Une fusion agressive peut masquer des identités légitimes. Observez surtout les recréations, les défusions, les relations perdues et le temps nécessaire au support pour expliquer l’autorité d’un attribut.
Pour qui un référentiel est pertinent
Le chantier devient pertinent quand plusieurs domaines prennent une décision sur la même identité, quand les traductions d’identifiants se multiplient ou quand une correction doit revenir vers plusieurs outils. Il mobilise sponsor métier, propriétaires de données, produit, architecture, sécurité, intégration et support.
Une seule application avec peu d’échanges peut se contenter d’un modèle propre et de contraintes. Un entrepôt analytique peut consolider pour lire sans devenir maître transactionnel. Ne créez un référentiel partagé que si une responsabilité commune et un run durable sont financés.
Erreurs fréquentes de centralisation
Acheter l’outil avant l’identité
La plateforme automatise les règles qu’on lui donne. Sans granularité ni autorité, elle produit une vue consolidée contestée. Fermez d’abord les décisions sur un objet et un parcours.
Rendre toute écriture synchrone
Cette centralisation augmente le rayon de panne. Distinguez les actions qui exigent une réponse immédiate des contributions qui peuvent être mises en file, puis testez réellement le mode dégradé.
Confondre source et copie parfaite
Une projection aura un délai. Exposez sa fraîcheur et réconciliez-la. Promettre une simultanéité absolue conduit à masquer les écarts et à multiplier les corrections manuelles.
Décision : créer ou ne pas créer
Créez un référentiel si l’objet possède une identité partagée, si plusieurs systèmes doivent prendre une décision cohérente et si une équipe peut assumer autorité, contrats et run. Préférez une vue analytique si le besoin est seulement de lire. Préférez une fédération si les attributs ont des propriétaires durables différents.
Si une erreur touche argent, droits ou sécurité, alors commencez par ce périmètre. En revanche, différez le service central si l’objet reste mal défini. À éviter : annoncer une « source unique de vérité » sans préciser chaque attribut et chaque mode dégradé.
- Commencer par une décision et un objet clairement nommés.
- Documenter identité, autorité, contrats et projections.
- Tester conflit, panne, reprise et réconciliation.
- Élargir seulement après avoir fermé les recréations.
Plan d’action sur six semaines
Semaines un à trois : définir et observer
Choisissez un objet et deux décisions coûteuses. Inventoriez sources, créations, corrections, exports et identifiants. Rejouez trente dossiers sains et vingt conflits. Fermez granularité, clés, aliases, attributs partagés et matrice d’autorité avec les métiers concernés.
Comparez registre, service et fédération sur disponibilité, latence, cohérence, sécurité et charge de run. Écrivez contrats, erreurs et mode dégradé. Préparez les métriques, la balance de migration et la file de revue. Le sponsor accepte le coût des projections et de la réconciliation.
Semaines quatre à six : piloter et transférer
Créez les identifiants en observation puis rattachez une source. Publiez une projection avec version et fraîcheur. Provoquez message doublonné, source indisponible, modification concurrente, code ancien et conflit d’autorité. Le support exécute recherche et correction avec ses droits réels.
Migrez une écriture et mesurez le cycle complet. La réconciliation compte objets, aliases et relations ; chaque écart reçoit cause et action. Le rollback repasse l’ancienne source en autorité sans supprimer les identifiants ni les traces du pilote.
Après deux cycles, examinez recréations, défusions, âge des projections et temps de diagnostic. Étendez seulement si les seuils locaux sont tenus, si les consommateurs traitent les versions et si une astreinte sait restaurer le service. Sinon, réduisez les attributs ou revenez à un simple registre.
- Nommer l’objet, l’identité et la décision partagée.
- Attribuer l’autorité et choisir l’architecture.
- Observer, migrer et perturber un premier flux.
- Réconcilier puis élargir depuis les preuves du run.
Approfondir doublons et migration
Gouverner le catalogue des consommateurs
Maintenez la liste des producteurs et consommateurs par objet, version, finalité et contact. Une API détectée dans les logs mais sans propriétaire reste un risque de retrait. Avant une évolution, fournissez exemples, environnement de contrat et date de fin. Après la bascule, mesurez les anciennes versions au lieu de supposer leur disparition. Ce catalogue n’a pas besoin d’être exhaustif dès le premier jour ; il doit couvrir les flux dont une rupture changerait une décision ou immobiliserait l’activité.
La revue de service rapproche ensuite coût, qualité et usage. Elle examine les attributs rarement lus, les contributions toujours refusées, les projections trop riches et les règles sans propriétaire. Une donnée partagée peut retourner dans son domaine si plus aucun autre consommateur n’en dépend. Le référentiel reste ainsi un contrat vivant et réduit son périmètre lorsque la valeur commune disparaît, plutôt que de devenir un entrepôt par défaut.
Prévoyez enfin la transmission du service. Le dossier d’exploitation contient topologie, dépendances, objectifs locaux, files, requêtes de diagnostic, procédures de reprise et contacts métiers. Une garde rejoue la perte d’un consommateur, la saturation d’une file et le retour d’un message ancien. Les résultats sont rapprochés par identifiant canonique. Cette répétition révèle les autorisations manquantes et les hypothèses de disponibilité avant l’astreinte réelle. Un référentiel ne devient commun que lorsque l’équipe suivante peut l’expliquer et le restaurer sans son concepteur.
Retrouver une identité canonique
Le guide sur les données métier dupliquées détaille matching, aliases, fusion et prévention des recréations.
Préparer les données existantes
Avant le premier chargement, poursuivez avec le nettoyage avant migration. Appliquez les deux méthodes à un objet, pas à une base abstraite.
- Une identité stable.
- Une autorité par attribut.
- Une réconciliation exploitable.
Conclusion : partager une décision
Un référentiel commun n’est ni une base universelle ni une promesse de données parfaites. Il fournit une identité, des responsabilités et des contrats aux décisions qui traversent plusieurs systèmes. Sa frontière doit rester aussi précise que l’objet qu’il sert.
Les projections, aliases, versions et balances rendent la distribution exploitable. L’observation et le pilote évitent le big bang. Le run ferme les conflits et les recréations au lieu de seulement surveiller un taux de qualité.
Commencez par l’objet qui oblige aujourd’hui deux équipes à se téléphoner pour savoir quelle donnée croire. Nommez la décision, attribuez l’autorité et testez un flux. L’architecture juste apparaîtra dans ces contraintes.
- Une décision commune.
- Un contrat explicite.
- Un service réconcilié.
Dawap peut accompagner ce chantier de développement web sur mesure : cadrage du référentiel, architecture, contrats, migration, pilote, observabilité et préparation du run.
