dbt Mesh dispose de trois fonctionnalités de gouvernance : les contrats, les contrôles d’accès et les versions de modèle. Chacun résout un problème spécifique indépendamment. Appliqués ensemble, ils transforment des tables internes en data products avec des interfaces définies, des limites de consommation explicites et une évolution gérée.
Les Trois Fonctionnalités, Chacune à sa Tâche
Les contrats garantissent la forme. Quand contract: {enforced: true} est défini, dbt refuse de matérialiser un modèle si ses colonnes de sortie et types ne correspondent pas à la déclaration YAML. Les consommateurs downstream savent quelles colonnes et types ils obtiendront, imposés à chaque construction. La garantie est structurelle : si le modèle se construit, il a le schéma que vous avez déclaré. Consultez Mécanique des contrats de modèle dbt pour les détails techniques.
Les contrôles d’accès définissent qui peut référencer un modèle. Les modèles public sont disponibles pour tout autre projet dbt. Les modèles protected restent dans leur propre projet. Les modèles private sont restreints à leur groupe de répertoire. Dans une configuration Mesh multi-projets, les contrôles d’accès déterminent quelles sorties sont intentionnellement exposées comme API versus lesquelles sont des détails d’implémentation interne sur lesquels d’autres équipes ne devraient pas construire.
Les versions de modèle gèrent l’évolution. Quand un changement cassant est nécessaire — supprimer une colonne, changer un type — vous créez une nouvelle version plutôt que de modifier l’existante. L’ancienne version et la nouvelle se matérialisent toutes deux comme des tables séparées (mrt__analytics__customers_v1, mrt__analytics__customers_v2). Les consommateurs sur v1 continuent de fonctionner pendant qu’ils migrent. L’ancienne version reçoit une deprecation_date pour que dbt avertisse quiconque la référence encore. Consultez Versionnage des modèles dbt pour le pattern complet.
Individuellement, chaque fonctionnalité est utile. Un modèle avec contrat sans contrôles d’accès reste un bloc de construction fiable pour votre propre projet. Les contrôles d’accès sans contrats sont utiles pour la structure du projet. Le versionnage sans contrats gère l’évolution du schéma sans garanties formelles.
Ce qui Change Quand On les Combine
Un modèle avec contrat, contrôle d’accès et version ressemble à autre chose qu’une table interne — non seulement dans sa configuration, mais dans ce qu’il représente dans votre organisation.
Quand une autre équipe utilise ref('your_project', 'mrt__analytics__customers') dans une configuration dbt Mesh, elle obtient trois choses à la fois :
- Le contrat définit exactement quelles colonnes et types attendre
- Le contrôle d’accès (
public) confirme qu’ils sont autorisés à dépendre de ce modèle - La version (
latest_version: 2) signifie qu’ils peuvent compter sur la stabilité même si l’implémentation sous-jacente change
Cette combinaison transforme un ref() cross-projet d’un accord informel en une interface imposable. L’équipe consommatrice n’a pas besoin de se coordonner avec vous à chaque refactorisation. Elle n’a pas besoin de vérifier si vous avez renommé une colonne. Le contrat détecte les ruptures structurelles à la compilation — dans leur projet, en CI, avant que quoi que ce soit ne soit déployé.
Cela correspond directement aux principes du data mesh, rendus opérationnels plutôt que théoriques :
- Propriété par domaine : chaque équipe gère son propre projet dbt et définit ses propres contrats
- Les données comme produit : les modèles avec contrat, versionnés et à accès contrôlé servent de sorties vers d’autres domaines avec des interfaces définies
- Gouvernance fédérée : les contrats et contrôles d’accès imposent la cohérence sans qu’une équipe centrale révise chaque modification
Quels Modèles Méritent Vraiment Ce Traitement
Tous les modèles n’ont pas besoin d’être des data products. La surcharge est réelle — chaque colonne et type doit être déclaré en YAML, chaque changement cassant nécessite une nouvelle version, les niveaux d’accès doivent être délibérés. Appliquer ce traitement universellement signifie dépenser cet effort sur des modèles dont personne d’autre ne dépend.
Les bons candidats, approximativement par ordre de priorité :
Les modèles mart qui franchissent les frontières d’équipe. Si le projet dbt d’une autre équipe a un ref() pointant vers votre modèle, ce modèle devrait avoir les trois. Vous ne savez pas quand ils s’exécutent, vous ne pouvez pas coordonner chaque modification, et casser leurs constructions a des coûts organisationnels au-delà des aspects techniques.
Les modèles alimentant des dashboards critiques. Les dashboards exécutifs et les rapports avec SLA ont un large rayon de souffle quand ils se cassent. Un modèle que 20 personnes consultent chaque matin mérite la garantie structurelle qu’un contrat fournit.
Les modèles intermédiaires aux frontières cross-équipe. Même dans un seul projet, si une équipe produit des données qu’une autre équipe consomme, traiter cette frontière comme une interface publique prévient la source la plus courante de surcoût de coordination intra-équipe : “quelqu’un a refactorisé quelque chose et mes modèles ne se construisent plus.”
Les modèles base sur des sources volatiles. Quand un schéma source change fréquemment — API volatile, équipe upstream qui déploie sans avertir — un modèle base avec contrat vous donne le signal le plus précoce possible. Le contrat échoue à la compilation, avant qu’aucune transformation ne s’exécute.
Ce qui n’a pas besoin de ce traitement : les modèles intermédiaires internes que personne en dehors de votre équipe ne référence, les modèles base sur des sources stables, les modèles utilitaires qui simplifient la logique pour d’autres modèles de la même couche. Pour ceux-là, les contrats ajoutent une surcharge YAML sans bénéfice de gouvernance significatif.
La Connexion avec le Data Mesh
Pour les équipes qui cherchent à comprendre concrètement ce que signifie “data product” en pratique, la triade de gouvernance le rend concret. Un data product n’est pas une philosophie ni un changement d’organigramme — c’est un modèle avec :
- Une interface définie (le contrat dit exactement ce que vous fournissez)
- Des limites de consommation explicites (les contrôles d’accès disent qui peut l’utiliser)
- Une évolution gérée (les versions permettent à l’interface de changer sans casser les consommateurs)
La spécification ODCS va plus loin — elle ajoute des SLA, des métadonnées de propriété et des règles de qualité à la définition de l’interface. La gouvernance native de dbt couvre la couche structurelle ; l’ODCS couvre la couche organisationnelle. Pour la plupart des équipes, la triade native dbt est suffisante pour commencer. Le passage à l’ODCS prend sens quand vous devez formaliser des accords avec des équipes entièrement en dehors de votre projet dbt — des équipes d’ingénierie logicielle produisant des données sources, des équipes ML consommant vos sorties, des partenaires externes recevant des flux de données.
Un seul modèle mart public avec contrat est plus accessible qu’une “initiative data mesh” à l’échelle de l’organisation. Commencer par le modèle dont le plus de personnes dépendent et appliquer les trois fonctionnalités de gouvernance est un point d’entrée pratique.