Le débat sur Data Vault est souvent trop théorique. Pour une DSI, la vraie question est de savoir si les bénéfices compensent la complexité supplémentaire dans son contexte, avec ses équipes, ses sources et ses obligations.
À retenir
- Choisir Data Vault lorsque l’historique et l’évolution des sources sont structurants.
- Automatiser les structures répétitives, pas les décisions métier.
- Prévoir la couche de consommation dès le départ.
- Investir dans les standards et les compétences avant le volume.
1. Les contextes favorables
- nombreuses sources qui évoluent indépendamment ;
- besoin d’historique complet et de traçabilité ;
- intégration progressive de domaines ;
- exigences d’audit ou de reconstitution ;
- besoin de séparer ingestion, intégration et règles métier.
2. Les contextes où il peut être excessif
Peu de sources, modèle stable, besoin de restitution simple, équipe réduite ou absence d’outillage peuvent rendre une architecture plus directe préférable. La complexité doit être justifiée par un risque ou une capacité attendue.
3. Le rôle du Raw Vault
Le Raw Vault conserve l’historique des faits intégrés avec une forte traçabilité. Sa valeur dépend de la qualité des clés métier, de la granularité et des métadonnées de chargement.
4. Le Business Vault
Il porte les règles de calcul, rapprochements et objets dérivés. Il ne doit pas devenir une zone indifférenciée. Les règles doivent avoir un owner, une version et des tests.
5. Concevoir la consommation
Les utilisateurs ne doivent pas être exposés à la complexité du modèle central. Marts, vues, produits de données ou couche sémantique doivent être conçus en fonction des usages et des niveaux de service.
6. Ce qu’il faut automatiser
Création des hubs, links, satellites, métadonnées techniques, tests structurels et documentation répétitive. Les choix de clés, la modélisation métier et les règles de calcul restent des décisions d’architecture.
7. Les compétences nécessaires
Modélisation, ingénierie, automatisation, compréhension métier, exploitation et gouvernance. Un petit noyau d’experts doit accompagner les domaines et maintenir les standards.
8. Gouvernance et ownership
Chaque source, clé métier, règle et produit de consommation doit avoir un responsable. Sans dictionnaire et processus de changement, l’auditabilité technique ne garantit pas la compréhension métier.
9. Mesurer la réussite
- délai d’intégration d’une nouvelle source ;
- capacité à reconstituer un état historique ;
- taux d’automatisation ;
- couverture de tests ;
- délai de mise à disposition d’un produit de données ;
- incidents liés aux changements de source.
10. Le cadre de décision
| Critère | Question |
|---|---|
| Historique | Faut-il reconstituer précisément l’état des données dans le temps ? |
| Évolution | Les sources changent-elles souvent et indépendamment ? |
| Audit | La provenance et les règles doivent-elles être démontrables ? |
| Équipe | Dispose-t-on des compétences et d’un cadre d’automatisation ? |
| Consommation | La couche destinée aux usages est-elle prévue et financée ? |
Data Vault est un investissement d’architecture. Sa valeur se mesure dans la capacité à absorber le changement et à expliquer l’histoire des données.