Cette note couvre les anti-patterns structurels qui font échouer les initiatives de contrats de données, distincts du défi d’adoption organisationnel. Le mode d’échec le plus courant : des contrats dbt existent sur des modèles de mart appartenant à l’équipe data, mais aucune autre équipe ne les a adoptés, et les modèles appartenant à d’autres se cassent encore sans avertissement.
Des contrats au mauvais endroit
Chad Sanderson et Mark Freeman soutiennent dans Data Contracts: Developing Production-Grade Pipelines at Scale (O’Reilly, 2025) que « la plupart des équipes data placent leurs contrats exactement au mauvais endroit ». Les équipes data implémentent des contrats sur les modèles qu’elles contrôlent, parce que c’est là qu’elles ont de l’autorité. Mais les contrats sur les modèles de mart ne capturent les problèmes qu’après que les mauvaises données ont déjà pénétré dans l’entrepôt. Ce sont des filets de sécurité, pas des mécanismes de prévention.
Salma Bakouk de Sifflet résume le résultat brutalement : « Après quatre ans d’adoption généralisée, nous nous retrouvons avec des fichiers YAML qui deviennent obsolètes, des définitions de schéma qui dérivent de la logique métier, et des équipes qui traitent les contrats comme de la documentation plutôt que comme des accords exécutables. »
Le point d’enforcement idéal est aussi proche que possible de la source de données. Pour les flux d’événements, cela signifie un schema registry. Pour les pipelines batch, cela signifie les modes de contrat de schéma dans votre outil EL. Pour tout le reste, une couche de validation post-chargement comme Soda comble le fossé avant même que dbt s’exécute. Les contrats dbt au niveau de la couche mart ont encore de la valeur, mais ils sont le dernier rempart, pas le premier.
Les quatre couches d’échec de Sanderson
Sanderson décompose l’échec des contrats en quatre couches. Chacune aggrave les autres.
Les contrats sont socio-techniques, donc ils échouent quand ils sont traités comme un problème purement technique. Vous pouvez avoir la spécification YAML parfaite et la validation CI la plus rigoureuse, mais si l’équipe qui produit les données ne comprend pas pourquoi elle devrait s’en soucier, le contrat est un document qu’un côté a rédigé et que l’autre ignore. Le modèle de propriété détermine si les contrats créent de la responsabilité ou juste de la paperasse.
La friction d’adoption tue les contrats silencieusement. Sans une attention obsessionnelle à la facilité d’onboarding, le soutien s’estompe. Si adopter des contrats signifie que les ingénieurs doivent apprendre un nouvel outil, écrire du YAML peu familier et ajouter une étape de déploiement, cela n’arrivera pas quelle que soit la qualité du pitch. Les équipes qui réussissent font en sorte que l’adoption des contrats ressemble à une extension naturelle des workflows existants, pas à un nouveau processus ajouté par-dessus.
La prolifération technologique aggrave le problème. Chaque nouvel outil ou base de données ajoute une complexité d’intégration. Un contrat qui fonctionne pour les événements Kafka ne s’applique pas proprement aux extraits batch BigQuery. Un framework de validation qui couvre Snowflake peut ne pas supporter Databricks. Plus la stack est hétérogène, plus il est difficile de maintenir une pratique de contrat cohérente.
La gestion des versions est négligée. Les contrats doivent s’aligner avec les bons déploiements historiques, pas seulement avec l’état actuel. Si votre contrat dit « cet événement a cinq champs » mais que les données chargées hier ont été produites par une version du service qui n’en avait que quatre, vous générerez de fausses violations contre les données historiques. La gestion des versions à travers les contrats, les schémas et l’historique des déploiements est opérationnellement complexe et rarement adressée dès le départ.
Les anti-patterns récurrents
Ces modes d’échec spécifiques apparaissent dans toutes les organisations :
Les contrats sur papier uniquement vivent dans des wikis ou des pages Confluence mais rien ne les enforce. Quelqu’un rédige une description du schéma attendu, peut-être avec un tableau de noms de colonnes et de types. Ça ressemble à de la gouvernance. Ça n’offre aucune protection réelle. La première fois qu’un changement de schéma se produit, personne ne vérifie le wiki. Six mois plus tard, la documentation décrit un dataset qui n’existe plus sous cette forme.
Les implémentations uniformes forcent un format de contrat unique sur des patterns de données fondamentalement différents. Les schémas d’événements ont des caractéristiques différentes des domaines à forte charge batch. Les données en streaming depuis Kafka nécessitent l’enforcement du schema registry. Les exports SaaS depuis Salesforce ne peuvent pas avoir de contrats du tout parce que vous ne contrôlez pas la source. Essayer d’appliquer le même template de contrat aux trois crée de la friction pour chaque équipe sans convenir à aucune.
La propriété non financée donne aux équipes la responsabilité des contrats sans le budget pour maintenir ce qu’elles possèdent. Une équipe de génie logiciel se voit dire « vous possédez maintenant le contrat pour vos événements de paiements » mais personne n’ajuste leur capacité de sprint ou leur rotation d’astreinte. Le contrat est un mandat non financé, et les mandats non financés reçoivent l’attention qu’ils méritent : aucune.
La portée qui veut tout faire en même temps essaie de mettre des contrats sur tous les datasets à la fois. C’est le « déploiement à l’échelle de l’organisation » qui ne réussit presque jamais à la première tentative. La meilleure approche est de commencer avec deux datasets à fort impact, de démontrer la valeur, et d’étendre à partir d’un succès démontré plutôt que d’un mandat descendant.
Le problème des contrats obsolètes
Le pire résultat est des contrats qui existent mais ne reflètent pas la réalité. Une équipe rédige des contrats lors d’une poussée initiale, les maintient pendant quelques mois, puis arrête de les mettre à jour à mesure que les données sous-jacentes évoluent. De nouvelles colonnes apparaissent qui ne sont pas dans le contrat. Des changements de type se produisent sans mises à jour des contrats. Le contrat dit que les données ont certaines garanties de qualité que personne ne vérifie réellement.
Les contrats obsolètes sont pires que pas de contrats. Au moins sans contrats, les gens savent qu’ils doivent être prudents. Les contrats obsolètes créent une fausse confiance. Quelqu’un fait confiance au schéma documenté, construit un modèle dessus, et découvre trop tard que le contrat ne correspondait plus aux données réelles depuis six mois.
La prévention est l’enforcement. Quand un contrat est validé en CI/CD, il ne peut pas devenir obsolète parce que toute dérive entre le contrat et les données réelles casse le pipeline. L’investissement dans l’infrastructure d’enforcement est ce qui sépare les contrats qui durent de ceux qui se dégradent. C’est le même fossé entre contrat comme documentation et contrat comme enforcement qui détermine si l’ensemble de l’initiative réussit.