Les data contracts formalisent les engagements entre producteurs et consommateurs de données. En 2025, c est un sujet d entretien Senior qui différencie les profils avec une vraie culture de gouvernance.
1Définition et valeur ajoutée
Question discriminante
Qu est-ce qu un data contract ? Quel problème concret résout-il ?
- Data contract — accord formel entre le producteur d un dataset et ses consommateurs, spécifiant le schéma, la qualité, la fraîcheur et les SLA
- Problème résolu — sans contract, un Data Engineer peut renommer une colonne sans savoir que 5 dashboards en dépendent. Avec un contract, le changement doit être negocié et communiqué
- Analogie — comme un contrat d API REST (OpenAPI), mais pour les données
- Popularisé par — Chad Sanderson (Data Products), Andrew Jones (Data Contracts book)
2Les 4 composants d un data contract
Question discriminante
Quels éléments doit contenir un data contract complet ?
# data-contract.yaml (format standard emergent)
apiVersion: v2.0.0
kind: DataContract
id: orders-v2
info:
title: Orders Dataset
version: 2.1.0
owner: equipe-commerce
contact: data-commerce@entreprise.com
schema:
type: dbt
path: models/marts/commerce/fct_orders.sql
fields:
- name: order_id
type: string
required: true
unique: true
- name: amount
type: float
minimum: 0
- name: status
type: string
enum: [completed, pending, cancelled]
quality:
freshness: 1h # données fraîches dans l heure
completeness: 99.9% # moins de 0.1% de nulls sur order_id
terms:
usage: Données internes uniquement
noticePeriod: 30 jours avant breaking change
3Implémenter avec dbt
Question discriminante
Comment utilisez-vous dbt pour enforcer un data contract ?
- sources.yml — définir le contrat sur les données sources : fraîcheur, schéma attendu
- Tests YAML — not_null, unique, accepted_values, relationships : les tests dbt sont la forme la plus simple de contract enforcement
- dbt-contracts (package) — package qui formate les tests dbt comme des contrats explicites avec des SLA
- schema.yml — la documentation dbt + les tests = un contract vivant et exécutable
sources:
- name: commerce
freshness:
warn_after: {count: 12, period: hour}
error_after: {count: 24, period: hour}
tables:
- name: orders
loaded_at_field: updated_at
columns:
- name: order_id
tests: [not_null, unique]
- name: status
tests:
- accepted_values:
values: [completed, pending, cancelled]
4Schema versioning : gérer les breaking changes
Question discriminante
Comment gérez-vous une breaking change sur un dataset qui a des consommateurs ?
- Semantic versioning — MAJOR.MINOR.PATCH : breaking change = incrémentation MAJOR
- Backward compatible changes — ajouter une colonne nullable : MINOR. Supprimer ou renommer une colonne : MAJOR
- Dépréciation progressive — maintenir l ancienne colonne avec un flag deprecated pendant 30 jours, documenter la migration
- Communication — notifier tous les consommateurs enregistrés avant toute breaking change
- Consumers registry — tenir un registre des consommateurs de chaque dataset (exposures dbt)
5Processus organisationnel
Question discriminante
Comment convainquez-vous une équipe de mettre en place des data contracts ?
- Commencer par les datasets critiques — les 5-10 tables les plus consommées, pas toute la stack d un coup
- Outiller le producteur — le contract doit être facile à créer et à maintenir. Si c est une corvée, personne ne le fera
- Automatiser la validation — les tests de contract doivent tourner automatiquement en CI à chaque PR
- Data stewards — désigner des responsables par domaine pour valider et maintenir les contracts
6Outils et frameworks en 2025
- Data Contract CLI — outil open source pour créer, valider et publier des data contracts (format YAML standard)
- dbt + tests YAML — la forme la plus répandue et la plus pratique de data contract pour les équipes dbt
- Soda — framework de qualité qui supporte les data contracts avec des SLA explicites
- DataHub / OpenMetadata — catalogues qui peuvent stocker et publier les contracts
# Data Contract YAML (OpenDataContracts standard)
dataContractSpecification: 0.9.3
id: orders-contract-v2
info:
title: Orders Contract
version: 2.1.0
owner: data-platform-team
contact: slack://data-platform
models:
orders:
description: "Table des commandes validées"
fields:
order_id:
type: string
required: true
unique: true
pii: false
amount:
type: number
minimum: 0
maximum: 1000000
status:
type: string
enum: [pending, completed, cancelled, refunded]
created_at:
type: timestamp
required: true
quality:
- rule: freshness
metric: max(created_at) > now() - interval 24 hours
- rule: volume
metric: count(*) BETWEEN 10000 AND 10000000
- rule: completeness
metric: count(order_id is not null) / count(*) > 0.99
sla:
latency: 2h
uptime: 99.5%
- OpenDataContracts — standard ouvert pour décrire les contrats de données en YAML. Compatible avec dbt, Great Expectations, et les outils de monitoring
- Qui définit le contrat — le producteur (équipe source) définit le schéma et les SLAs. Le consommateur valide que le contrat répond à ses besoins. Négociation avant accord
- Versioning sémantique — breaking changes (suppression colonne, changement de type) = bump majeur. Backward-compatible changes (ajout colonne) = bump mineur. Les consommateurs doivent être notifiés avant un bump majeur
- Enforcement automatique — valider le contrat en CI/CD à chaque merge. Si une migration SQL supprime une colonne contractualisée, le pipeline échoue avant d'atteindre la prod
- Data Contract Studio — outil open source de visualisation et validation des contrats. Générer des tests dbt ou Great Expectations depuis un contrat YAML
7Grille par niveau
| Niveau | Maitrise | Signal GO | NO-GO |
|---|
| Confirmé | Comprend le concept, sait qu un test dbt est une forme de contract | Peut expliquer pourquoi les data contracts existent, a mis des tests dbt en place | N a jamais entendu parler de data contracts |
| Senior | A formalisé des contracts YAML, gère le versioning, communique les breaking changes | A mis en place des contracts sur des datasets critiques, gère la dépréciation | Ne sait pas comment gérer une breaking change sans casser les consommateurs |
1Definition and added value
Discriminating question
What is a data contract? What concrete problem does it solve?
- Data contract — formal agreement between a dataset producer and its consumers, specifying the schema, quality, freshness and SLAs
- Problem solved — without a contract, a Data Engineer can rename a column without knowing that 5 dashboards depend on it. With a contract, the change must be negotiated and communicated
- Analogy — like a REST API contract (OpenAPI), but for data
- Popularized by — Chad Sanderson (Data Products), Andrew Jones (Data Contracts book)
2The 4 components of a data contract
Discriminating question
What elements must a complete data contract contain?
# data-contract.yaml (format standard emergent)
apiVersion: v2.0.0
kind: DataContract
id: orders-v2
info:
title: Orders Dataset
version: 2.1.0
owner: equipe-commerce
contact: data-commerce@entreprise.com
schema:
type: dbt
path: models/marts/commerce/fct_orders.sql
fields:
- name: order_id
type: string
required: true
unique: true
- name: amount
type: float
minimum: 0
- name: status
type: string
enum: [completed, pending, cancelled]
quality:
freshness: 1h # données fraîches dans l heure
completeness: 99.9% # moins de 0.1% de nulls sur order_id
terms:
usage: Données internes uniquement
noticePeriod: 30 jours avant breaking change
3Implement with dbt
Discriminating question
How do you use dbt to enforce a data contract?
- sources.yml — define the contract on source data: freshness, expected schema
- YAML Tests — not_null, unique, accepted_values, relationships: dbt tests are the simplest form of contract enforcement
- dbt-contracts (package) — package that formats dbt tests as explicit contracts with SLAs
- schema.yml — dbt documentation + tests = a living and executable contract
sources:
- name: commerce
freshness:
warn_after: {count: 12, period: hour}
error_after: {count: 24, period: hour}
tables:
- name: orders
loaded_at_field: updated_at
columns:
- name: order_id
tests: [not_null, unique]
- name: status
tests:
- accepted_values:
values: [completed, pending, cancelled]
4Schema versioning: managing breaking changes
Discriminating question
How do you handle a breaking change on a dataset that has consumers?
- Semantic versioning — MAJOR.MINOR.PATCH: breaking change = MAJOR increment
- Backward compatible changes — adding a nullable column: MINOR. Deleting or renaming a column: MAJOR
- Progressive deprecation — keep the old column with a deprecated flag for 30 days, document the migration
- Communication — notify all registered consumers before any breaking change
- Consumers registry — maintain a registry of consumers for each dataset (dbt exposures)
5Organizational process
Discriminating question
How do you convince a team to implement data contracts?
- Start with critical datasets — the 5-10 most consumed tables, not the entire stack at once
- Equip the producer — the contract must be easy to create and maintain. If it is a chore, no one will do it
- Automate validation — contract tests must run automatically in CI on every PR
- Data stewards — designate domain owners to validate and maintain contracts
6Tools and frameworks in 2025
- Data Contract CLI — open source tool to create, validate and publish data contracts (standard YAML format)
- dbt + YAML tests — the most widespread and practical form of data contract for dbt teams
- Soda — quality framework that supports data contracts with explicit SLAs
- DataHub / OpenMetadata — catalogs that can store and publish contracts
# Data Contract YAML (OpenDataContracts standard)
dataContractSpecification: 0.9.3
id: orders-contract-v2
info:
title: Orders Contract
version: 2.1.0
owner: data-platform-team
contact: slack://data-platform
models:
orders:
description: "Table des commandes validées"
fields:
order_id:
type: string
required: true
unique: true
pii: false
amount:
type: number
minimum: 0
maximum: 1000000
status:
type: string
enum: [pending, completed, cancelled, refunded]
created_at:
type: timestamp
required: true
quality:
- rule: freshness
metric: max(created_at) > now() - interval 24 hours
- rule: volume
metric: count(*) BETWEEN 10000 AND 10000000
- rule: completeness
metric: count(order_id is not null) / count(*) > 0.99
sla:
latency: 2h
uptime: 99.5%
- OpenDataContracts — open standard for describing data contracts in YAML. Compatible with dbt, Great Expectations, and monitoring tools
- Who defines the contract — the producer (source team) defines the schema and SLAs. The consumer validates that the contract meets their needs. Negotiation before agreement
- Semantic versioning — breaking changes (column deletion, type change) = major bump. Backward-compatible changes (column addition) = minor bump. Consumers must be notified before a major bump
- Automatic enforcement — validate the contract in CI/CD on every merge. If a SQL migration drops a contracted column, the pipeline fails before reaching production
- Data Contract Studio — open source tool for visualizing and validating contracts. Generate dbt or Great Expectations tests from a YAML contract
7Level grid
| Level | Mastery | GO signal | NO-GO |
|---|
| Confirmed | Understands the concept, knows that a dbt test is a form of contract | Can explain why data contracts exist, has set up dbt tests | Has never heard of data contracts |
| Senior | Has formalized YAML contracts, manages versioning, communicates breaking changes | Has implemented contracts on critical datasets, manages deprecation | Does not know how to handle a breaking change without breaking consumers |