Un contrat de données est un accord formel et versionné entre les producteurs et les consommateurs de données qui définit la structure attendue, la sémantique, les standards de qualité et les garanties de livraison d’un dataset. Le concept a été créé par Andrew Jones chez GoCardless en 2020 et a depuis mûri en une spécification soutenue par la Linux Foundation.
Le cadrage de Jones s’articule autour de l’idée que les bases de données sont traitées comme des « API non consenties ». Les outils ELT se connectent aux bases de données de production pour extraire des données à des fins analytiques, mais les ingénieurs qui possèdent ces bases de données n’ont jamais accepté de fournir des données dans ce format, à cette fréquence, ni avec des garanties de stabilité. Un ingénieur logiciel qui optimise une table de production n’a aucune raison de penser au pipeline analytique en aval — pas tant qu’un contrat ne rend cette dépendance explicite.
La question centrale
En pratique, un contrat de données répond à une question : sur quoi puis-je compter concernant ces données ?
Cette question couvre plusieurs dimensions :
- Structure. Quelles colonnes existent, quels sont leurs types, et si le schéma est stable.
- Sémantique. Ce que signifie chaque champ. Est-ce que
revenueest brut ou net ? Est-ce quecreated_atutilise l’UTC ou l’heure locale ? - Qualité. Taux de nulls acceptables, plages de valeurs, garanties de fraîcheur.
- Livraison. À quelle fréquence les données se mettent à jour. Quel est le SLA de disponibilité.
- Propriété. Qui est responsable quand les données ne respectent pas l’accord.
Sans contrats, les réponses à ces questions sont implicites. Elles existent comme connaissances tacites, enfouies dans des fils Slack, ou — le plus souvent — nulle part. L’analytics engineer découvre les réponses à travers les pannes : un modèle se casse, et l’investigation révèle qu’une équipe en amont a changé quelque chose trois jours plus tôt sans en informer personne.
Comment les contrats diffèrent de ce que vous avez déjà
Si vous utilisez dbt, vous avez probablement des tests de schéma, des vérifications de qualité des données, et peut-être des contrats de modèle. Les contrats de données comme concept plus large ne remplacent aucun de ces éléments — ils constituent une couche supplémentaire qui opère à un point différent dans le cycle de vie des données.
Les tests de schéma (tests génériques dbt comme unique, not_null, accepted_values) valident les propriétés des colonnes après la construction d’un modèle. Ils sont réactifs et structurels : vous découvrez le problème après que les mauvaises données ont déjà atterri dans votre entrepôt.
Les vérifications de qualité des données (surveillance des taux de nulls, validation des plages de valeurs, analyse de distribution via des outils comme Elementary ou dbt-expectations) sont aussi réactives mais couvrent le contenu plutôt que la structure. Elles vous indiquent que quelque chose ne va pas avec les données elles-mêmes, pas seulement avec le schéma.
Les contrats de données sont proactifs. Ils établissent des accords avant que les données ne circulent, de sorte que les violations sont captées ou prévenues à la source plutôt que découvertes en aval. Un contrat peut spécifier qu’un événement payments inclura toujours les champs amount, currency et customer_id, avec amount comme décimal positif et currency comme code ISO à trois lettres. Si un ingénieur logiciel essaie de déployer un changement qui supprime le champ currency, l’enforcement du contrat bloque le déploiement — le pipeline analytique ne voit jamais le changement cassant.
Comme le formule la documentation de Soda : « Les contrats dbt sont mieux compris comme des contrats de schéma pour les transformations. Ils protègent les modèles en aval dans un DAG dbt, offrant une sécurité locale précieuse. Mais ils ne sont pas conçus pour fonctionner comme des contrats de données complets à travers le cycle de vie des données. »
Les trois couches ensemble
Vous avez besoin des trois couches — elles ne sont pas des approches concurrentes :
| Couche | Quand elle agit | Ce qu’elle capture | Exemple |
|---|---|---|---|
| Contrats de données | Avant que les données circulent | Changements cassants à la source | Le producteur renomme une colonne ; le contrat bloque le déploiement |
| Tests de schéma | Après la construction des modèles | Violations structurelles dans les données transformées | La clé primaire a des doublons après une jointure |
| Vérifications de qualité | Après la construction des modèles | Anomalies de contenu dans les données transformées | Le revenu chute de 40% par rapport à la baseline historique |
Les contrats préviennent certaines catégories de problèmes de se produire. Les tests capturent ce que les contrats ne couvrent pas et ce qui passe malgré les contrats. La combinaison est ce qui vous donne une confiance réelle dans vos données.
Un exemple de contrat minimal
En utilisant le format Open Data Contract Standard (ODCS) :
apiVersion: v3.1.0kind: DataContractid: 53581432-6c55-4ba2-a65f-72344a91553aname: seller_payments_v1version: 1.1.0status: activedomain: sellerdataProduct: paymentsdescription: purpose: Views built on top of the seller tables.Si vous avez écrit du YAML dbt, ce format vous semble familier. La spécification complète couvre plus que ce que les contrats dbt gèrent — SLA, propriété, tarification, métadonnées de gouvernance — ce qui explique à la fois la puissance et la complexité supplémentaire d’adopter le standard complet par rapport à l’implémentation focalisée de dbt.
L’histoire des origines
Jones a conçu l’idée chez GoCardless, un prestataire de paiements par prélèvement automatique, où les changements de schéma dans un service cassaient silencieusement les consommateurs de ces données. Il a publié la première description en avril 2021 et un article d’ingénierie détaillé en décembre 2021. En six mois d’implémentation, GoCardless avait déployé environ 30 contrats couvrant 50 à 60% de leurs événements de communication asynchrone.
Chad Sanderson, alors Head of Data chez Convoy, a catalysé l’adoption plus large avec son article d’août 2022 « The Rise of Data Contracts », formulant le problème comme le « Cycle GIGO » : les producteurs ne savent pas comment leurs données sont utilisées en aval, les ingénieurs manquent d’incitation à maintenir la qualité des données au-delà des besoins opérationnels, et les data engineers deviennent des intermédiaires qui gèrent les incidents.
En 2025, deux livres avaient été publiés (le Driving Data Quality with Data Contracts de Jones et le Data Contracts de Sanderson, Freeman et Schmidt), dbt avait livré un enforcement natif des contrats, et les spécifications avaient commencé à se consolider sous la Linux Foundation.
Le concept est passé d’une expérimentation marginale (2021-2022) à une discussion grand public (2023-2024) à une adoption par la majorité précoce (2025-2026). Les outils et les standards sont matures ; le défi restant est organisationnel, pas technique.