Quand j'accompagne des équipes produit ou des dirigeants sur la gouvernance des données, une question revient souvent : par où commencer sans être paralysé par la taille du chantier ? J'ai adopté depuis plusieurs années une approche pragmatique : construire un catalogue de données minimal viable (MDVC) qui soit utile immédiatement, automatisé autant que possible et évolutif. Dans cet article, je partage comment j'assemble ce MDVC autour de dbt et d'un data catalog open source — une combinaison qui permet d'aller vite, d'embarquer les équipes et d'établir des bases solides pour la gouvernance.

Pourquoi un catalogue minimal plutôt qu'un catalogue "complet" dès le départ ?

Beaucoup d'organisations attendent d'avoir un inventaire parfait avant de lancer la gouvernance. Résultat : le projet stagne, la dette technique augmente et les usages ne changent pas. A contrario, un MDVC permet de :

  • livrer de la valeur rapidement (recherche, compréhension, confiance) ;
  • automatiser les mises à jour via les pipelines existants (moins de maintenance) ;
  • tester les workflows de gouvernance (revue, certification, contrats de données) sur un périmètre restreint ;
  • itérer selon les retours des utilisateurs métiers.

    • Concrètement, je cible d'abord les tables/jeux de données critiques pour le business (KPIs, rapports financés, sources prioritaires), puis j'essaie d'apporter un maximum d'informations automatiquement — et d'ajouter progressivement des métadonnées manuelles utiles.

    Pourquoi dbt comme point d'ancrage ?

    dbt (data build tool) est devenu en pratique un « source of truth » pour le code transformant les données. Deux atouts majeurs :

  • dbt contient déjà de la documentation (descriptions de modèles, tests, dépendances) qui peut être exposée ;
  • la linéarité et la traçabilité des modèles dbt fournissent une lineage exploitable.

    • En centralisant la documentation et les tests dans dbt, on réduit le duplicata et l'effort. Donc je commence toujours par maximiser la qualité de la documentation dbt : descriptions, tests, tags et owners. Ensuite, j'extrais ces métadonnées vers le catalogue open source choisi.

    Choix du data catalog open source

    Il existe plusieurs solutions matures : Amundsen (Lyft), DataHub (LinkedIn), OpenMetadata, Metacat... Mon choix dépend du contexte technique et des besoins :

  • DataHub est puissant pour le lineage, très orienté graph et intègre bien la recherche ;
  • OpenMetadata est simple à intégrer, propose une API REST et prend en charge les workflows de gouvernance ;
  • Amundsen est léger, bon pour la découverte et l'intégration avec Airflow/Metastore.

    • Pour un MDVC j'opte souvent pour DataHub ou OpenMetadata parce qu'ils offrent :

  • des connecteurs prêts à l'emploi (Snowflake, BigQuery, Postgres, Kafka, dbt) ;
  • de la recherche full-text et des interfaces pour éditer les métadonnées ;
  • la possibilité d'automatiser l'ingestion depuis dbt.

    • Étapes concrètes pour construire le MDVC

    Voici le plan que j'applique habituellement, avec des actions simples et répétables.

  • Définir le périmètre MVP

    • Sélectionnez 10-50 entités critiques : tables de reporting, modèles dbt clés, vues consumées par le produit. Documentez l'objectif du catalogue (recherche, confiance, onboarding).

  • Standardiser les métadonnées dans dbt

    • Ajoutez dans vos fichiers .yml dbt :

  • description, owner (email), tags (sensibilité, domaine), tests (not null, unique), freshness/checks

    • Exemple de champs que je privilégie (que je synchroniserai ensuite) :

    ChampPourquoi
    nomidentification unique
    descriptionusage attendu / KPI
    ownerresponsable pour questions
    sensibilitéGDPR / confidentialité
    testsqualité minimale attendue
    lineagedépendances de transformation
  • Générer la documentation dbt automatiquement

    • J'intègre dbt docs generate au pipeline CI/CD pour produire la documentation et le manifest.json. Ce manifest contient les descriptions, tests et le graphe de dépendances — ressources précieuses pour l'ingestion dans le catalogue.

  • Choisir le connecteur d'ingestion

    • DataHub et OpenMetadata possèdent des connectors pour consommer le manifest dbt et les métadonnées des entrepôts. Configurez l'ingestion périodique (par exemple toutes les nuits ou après chaque déploiement dbt) pour garder le catalogue à jour.

  • Automatiser l'enrichissement

    • Au-delà du manifest, j'extrais :

  • schémas, partitions, statistiques (row count, null pct) depuis l'entrepôt ;
  • logs de pipeline (freshness, échecs) ;
  • résultats de tests dbt pour indiquer la santé des assets.
  • Mettre en place la recherche et la navigation par domaine

    • Je configure des filtres métiers : domaine (finance, marketing), sensibilité, owner. La search doit répondre vite et fournir un aperçu utile : description, owner, dernier run, tests failing.

  • Déployer des workflows de gouvernance légers

    • Pour le MVP, je limite les workflows à :

  • certification manuelle des jeux de données par un responsable ;
  • commentaires/questions sur les assets ;
  • alertes quand un test critique échoue.
  • Mesurer l'adoption

    • Suivez : nombre de recherches, assets consultés, tickets posés via le catalogue, et réduction du temps pour trouver une source fiable. Ces KPIs guident l'itération.

    Bonnes pratiques et pièges à éviter

    Quelques retours d'expérience que j'applique systématiquement :

  • Prioriser l'automatisation : moins on demande d'entrées manuelles, plus l'outil reste à jour. Exploitez dbt, les métriques d'entrepôt et les connecteurs natifs.
  • Commencer petit et livrer de la valeur visible : une recherche efficace et des owners clairs changent déjà beaucoup d'usages.
  • Ne pas confondre catalogue et politique de sécurité : limitez la visibilité des métadonnées sensibles si nécessaire (masking, ACLs).
  • Mettre en place des conventions de nommage et des tags domain-driven pour faciliter la recherche.
  • Assurer un feedback loop avec les métiers : les descriptions doivent être compréhensibles par des non-data ingénieurs.

    • Exemple d'intégration technique (schéma simplifié)

    Flux typique que j'implante :

  • dbt (manifest.json + catalog.json) -> ingestion automatisée -> DataHub/OpenMetadata
  • Entrepôt (Snowflake/BigQuery/Postgres) -> connecteur -> stats/colonnes/partitions
  • CI/CD -> trigger d'ingestion après déploiement dbt
  • Alerting -> notifications Slack/Email quand tests critiques échouent

    • Ce que j'ai appris en le faisant

    La mise en place d'un MDVC est autant un projet humain que technique. Les bénéfices réels viennent quand :

  • les équipes apprennent à documenter dans dbt parce qu'elles voient l'impact ;
  • les propriétaires prennent la responsabilité de certifier leurs sources ;
  • les workflows de QA deviennent partie intégrante du développement de pipelines.

    • En résumé, partir d'un catalogue minimal, exploiter dbt comme source de vérité, automatiser l'ingestion vers un catalogue open source et itérer avec les utilisateurs permet d'accélérer considérablement la gouvernance. Si vous souhaitez, je peux partager un exemple de pipeline d'ingestion dbt -> DataHub ou un template de fichier .yml dbt adapté au MDVC pour démarrer rapidement.