Data catalog moderne & lineage : Atlan, Collibra, DataHub, OpenMetadata

Dans une plateforme data mature, la question la plus posée n'est pas "comment construire un pipeline" — c'est "où est cette donnée ?" et "d'où vient ce chiffre ?". Un data catalog moderne répond à ces deux questions en automatisant la découverte, le lineage et la documentation. Il transforme une gouvernance subie ("remplis le wiki") en gouvernance utilisée parce qu'utile. Voici comment choisir et adopter Atlan, Collibra, DataHub, OpenMetadata ou Unity Catalog.

Du catalog "wiki" au catalog "automatique"

Génération 1 (2010-2018) : wikis statiques, métadonnées renseignées à la main, jamais à jour. Personne ne s'en sert.

Génération 2 (2018+) : catalogs automatiques qui :

• Scannent les warehouses, lakehouses, BI, orchestrateurs.
• Génèrent le lineage depuis le SQL des transformations.
• Détectent les PII, classifient.
• Calculent un score de popularité.
• S'intègrent à dbt, Airflow, Snowflake, BigQuery, Databricks, Tableau, Power BI, Looker.

Le catalog devient un produit interne utilisé pour discovery, troubleshooting et conformité.

Cartographie des outils

Outil	Positionnement	Forces
Atlan	Catalog moderne tout-en-un	UX moderne, intégrations larges, governance + active metadata
Collibra	Leader entreprise / gouvernance	Cycle de vie metadata complet, conformité, glossaire métier puissant
DataHub (LinkedIn)	Open source phare	Très extensible, fortes intégrations dbt/Airflow, communauté
OpenMetadata	Open source montant	Lineage automatique, observability légère intégrée
Unity Catalog	Catalog natif Databricks	Forte intégration Databricks, multi-cloud, partage de données
Snowflake Horizon	Catalog natif Snowflake	Couvert nativement si la plateforme est Snowflake-centric
Microsoft Purview	Catalog Azure	Forte intégration Azure / Fabric
Alation	Catalog historique	Adoption grande entreprise, glossaire, recherche
Informatica EDC / IDMC	Catalog enterprise data management	Maturité, lien MDM/qualité

Les capacités attendues d'un catalog moderne

Discovery

• Recherche full-text sur datasets, tables, colonnes, dashboards, modèles dbt.
• Recommandations basées sur popularité, équipe, usage.
• Vues sectorielles / par domaine (compatible Data Mesh).

Lineage end-to-end

• Lignée column-level quand possible.
• Couverture : ingestion → transformation → warehouse → BI / ML.
• Visualisation en graphe, capacité à parcourir amont/aval.

Active metadata

• Métadonnées mises à jour automatiquement.
• API pour pousser de la métadonnée custom.
• Triggers / workflows sur événements (nouveau dataset, drift, classification PII).

Glossaire métier

• Définitions partagées (KPI, dimensions).
• Mapping glossaire ↔ datasets techniques.
• Approbation et versioning.

Gouvernance et conformité

• Classification automatique PII / sensible.
• Politiques d'accès lisibles.
• Audit, conformité (RGPD, DORA, secteur régulé).

Intégrations

• Snowflake / BigQuery / Databricks / Redshift.
• dbt, Airflow, Dagster, Prefect.
• Tableau, Power BI, Looker, Hex.
• Slack / Teams pour la collaboration.

Lineage automatique : pourquoi c'est central

Sans lineage automatique, impossible de répondre rapidement à :

• "Si je modifie cette table, qu'est-ce qui casse ?"
• "Ce KPI vient d'où précisément, en passant par quels modèles ?"
• "Quel pipeline alimente ce dashboard finance ?"

Les catalogs modernes parsent le SQL (warehouse query history, dbt manifest, BI metadata) pour reconstruire le graphe de dépendances sans intervention humaine.

Voir Data Mesh en pratique et Data observability.

Gouvernance "pull" vs "push"

Gouvernance "push" (ancien modèle)

• L'équipe gouvernance impose des règles et des saisies.
• Les utilisateurs doivent remplir des fiches dans un wiki.
• Adoption faible, métadonnées qui dérivent.

Gouvernance "pull" (catalog moderne)

• L'équipe gouvernance automatise la métadonnée (scans, classification, lineage).
• Les utilisateurs viennent au catalog parce qu'il leur sert (discovery, troubleshooting).
• Adoption forte, métadonnées qui restent à jour parce qu'utilisées.

Le succès d'un catalog tient à la valeur perçue par le consommateur, pas à la rigueur perçue par le gouverneur.

Critères de sélection

Critère	Question à se poser
Stack data	Snowflake / Databricks / BigQuery / multi ?
Périmètre	Catalog seul ou + observability + qualité ?
Cloud / on-prem	SaaS accepté ou pas ?
Maturité gouvernance	Forte exigence conformité (Collibra, Purview) ou self-serve (Atlan, OpenMetadata) ?
Open source vs SaaS	Équipe pour opérer ? Budget ?
Multi-équipes	Combien de domaines, gouvernance fédérée ?
TCO 3 ans	Licences + infra + équipe d'adoption

Démarche d'adoption

Phase 1 : MVP

• Scanner un warehouse et un BI principal.
• Activer le lineage automatique.
• Onboarder 10-20 utilisateurs pilotes.

Phase 2 : extension

• Ajouter sources d'ingestion (Fivetran/Airbyte), orchestrateur (Airflow/Dagster), dbt.
• Démarrer le glossaire métier sur 30-50 termes critiques.
• Activer la classification automatique des PII.

Phase 3 : industrialisation

• Couvrir tous les domaines.
• Brancher l'observability (alerting via catalog).
• Cas d'usage avancés : impact analysis dans CI/CD, conformité automatisée.

Phase 4 : ancrage culturel

• Mesurer l'usage (utilisateurs actifs, recherches, contributions).
• Onboarding produit pour chaque nouvel arrivant data.
• Boucles de feedback continues.

Pièges fréquents

• Choisir un catalog trop lourd pour la maturité de l'organisation.
• Catalog sans owner : pas d'évangélisation, adoption nulle.
• Ne brancher qu'une partie du SI : lineage incomplet, valeur limitée.
• Wiki bis : remettre de la saisie manuelle au lieu d'automatiser.
• Confondre catalog et observability : ce sont des disciplines complémentaires.
• Ignorer la performance (un scan trop lourd peut perturber le warehouse).

Profils mobilisés

• Data Steward / Owner : porte le glossaire métier et la qualité.
• Data Platform Engineer : déploie, intègre, gouverne techniquement.
• Data Governance Lead : pilote l'ensemble.
• Data Engineer / Analytics Engineer : consommateurs et contributeurs.

Conclusion : un catalog qui sert vraiment, ou rien

Le bon data catalog n'est pas le plus exhaustif — c'est celui que les équipes data utilisent tous les jours. Atlan, Collibra, DataHub, OpenMetadata, Unity Catalog ont chacun leur cible. Le choix dépend moins du produit que de la maturité de l'organisation et de la stratégie data globale. Les organisations qui réussissent traitent le catalog comme un produit interne avec un owner, des utilisateurs, des roadmaps — pas comme un outil de conformité passive.

Pour aller plus loin :

• Data Mesh en pratique
• Data Contracts
• Data observability
• dbt & analytics engineering

ForTeam IT positionne des data governance leads, data platform engineers et data stewards capables de déployer et d'animer un catalog moderne (Atlan, DataHub, OpenMetadata, Collibra, Unity Catalog). Si c'est votre terrain, vous êtes au bon endroit.

Rejoindre ForTeam IT