Cas d'usage — MDM & intégration
Le même client, dans cinq systèmes différents.
Le CRM en a fait deux fiches, l'ERP en a une troisième avec une raison sociale abrégée, et le facturier utilise encore l'ancien numéro de compte. Tant que ces identités ne sont pas rapprochées, aucun indicateur transverse n'est fiable — et tant que le contexte des sources est perdu au passage, personne ne fait confiance au résultat.
La situation
La même entité, décrite différemment partout
Chaque système a raison dans son périmètre. Le problème apparaît quand on veut compter, comparer ou consolider : les identités ne se recoupent pas, et le rapprochement manuel recommence à chaque exercice.
La tentation est d'écraser les variantes pour produire une fiche unique. C'est précisément ce qui rend le résultat contestable : dès qu'une règle de choix change, plus rien n'est vérifiable, et les systèmes source ne se reconnaissent plus dans la version consolidée.
Ce que beVault apporte
La clé métier comme point de convergence
Dans un Data Vault, l'entité métier existe une seule fois. Chaque système y rattache sa propre référence sans perdre la sienne : le rapprochement s'ajoute, il ne remplace pas.
- Clés métier
- L'identifiant métier retenu — numéro d'entreprise, identifiant national, combinaison de champs — est un arbitrage documenté dans le modèle, pas une convention implicite.
- Rapprochement multi-source
- Les correspondances entre identifiants de systèmes différents sont matérialisées par des structures dédiées (same-as links), révisables et historisées.
- Historisation
- Les valeurs d'origine restent conservées et datées. Une correspondance revue plus tard n'efface pas ce qui a été observé auparavant.
- Règles de survivance
- Quelle source fait foi pour l'adresse, pour la raison sociale : ces règles sont déclarées et appliquées de façon explicite, dans le périmètre validé avec vous.
- Traçabilité
- Chaque attribut de la vue consolidée reste rattaché au système dont il provient, ce qui permet de justifier une valeur plutôt que de la défendre.
La démarche
Un objet métier à la fois
- 01
Choisir l'objet et ses sources
Un seul objet — souvent le client ou le fournisseur — et trois à cinq systèmes contributeurs. Le taux réel de doublons est mesuré avant toute décision.
- 02
Identifier et réconcilier les clés métier
La clé retenue est arbitrée avec le métier, puis les correspondances entre systèmes sont établies et matérialisées dans le modèle.
- 03
Conserver le contexte et l'historique des sources
Les valeurs de chaque système restent stockées telles quelles, datées et rattachées à leur origine. Rien n'est écrasé au profit d'une version unique.
- 04
Appliquer les règles de survivance validées
Là où une règle a été définie et acceptée, elle produit une valeur de référence explicable. Les cas ambigus partent en arbitrage humain, avec le contexte nécessaire pour trancher.
- 05
Exposer une vue gouvernée
La vue de référence est publiée pour les applications et les rapports, accompagnée du lignage de chaque attribut vers son système d'origine.
Le principe
Une vue de référence est une interprétation, jamais une destruction.
Si une règle de survivance change dans six mois, elle est modifiée et les sorties sont régénérées : les données d'origine sont toujours là, intactes et horodatées. C'est ce qui permet de réviser un arbitrage sans reconstruire le référentiel.
Étape suivante