Data Contracts : éviter qu'un changement de schéma casse les dashboards

Un développeur ajoute un champ dans une table applicative. Trois jours plus tard, le rapport finance affiche des chiffres absurdes, une alerte ML se déclenche, et l'équipe data passe une semaine à débugger. Ce scénario, des dizaines d'organisations le vivent chaque trimestre. Les Data Contracts structurent l'interface entre producteurs (équipes applicatives, microservices) et consommateurs (BI, ML, analytics) pour que ces régressions soient détectées avant la prod.

Qu'est-ce qu'un Data Contract

Un Data Contract est une spécification versionnée d'un dataset ou d'un flux d'événements. Il décrit :

• Le schéma (champs, types, contraintes, nullabilité).
• La sémantique métier (description, unités, format).
• La fraîcheur attendue (latence d'arrivée, fréquence de mise à jour).
• La qualité attendue (unicité, complétude, valeurs autorisées).
• L'owner et les consommateurs déclarés.
• La politique de versioning et de breaking changes.

C'est l'équivalent d'un contrat d'API REST/gRPC, transposé au monde data.

Le problème que ça résout

Sans contract, les pipelines data reposent sur des hypothèses implicites :

• Le champ amount est en centimes (ou en euros ? selon l'équipe).
• Le champ created_at est toujours rempli (sauf depuis hier).
• Le code pays est ISO-3166 (sauf pour les anciens enregistrements).

Chaque hypothèse implicite est une bombe à retardement. Le contract rend l'implicite explicite, versionné, testable.

Anatomie d'un Data Contract

Exemple de structure (YAML-like, neutre) :

Section	Contenu type
metadata	nom, version, owner, équipe, criticité (SLO)
schema	champs, types, nullabilité, format, contraintes
semantics	description, unités, énumérations, glossaire métier
quality	tests (unicité PK, valeurs autorisées, ranges)
freshness	SLA d'arrivée, fréquence de mise à jour
consumers	systèmes / équipes qui s'abonnent
versioning	stratégie semver, fenêtre de dépréciation

Schema Registry & écosystème

Un Data Contract ne vit pas dans un wiki. Il est stocké et validé automatiquement :

Outil	Rôle
Confluent Schema Registry	Avro/Protobuf/JSON Schema pour Kafka
Apicurio Registry	Alternative open source multi-format
AWS Glue Schema Registry	Schéma + compatibility côté AWS
Buf Schema Registry	Protobuf et gRPC à l'échelle
Data Contract CLI / dbt	Validation côté analytics
DataHub / Atlan	Catalog + lineage incluant les contracts

Mise en œuvre : 5 étapes

1. Identifier les datasets critiques

On ne contractualise pas tout d'un coup. Commencer par les données qui alimentent des décisions (finance, conformité, ML scoring, dashboards exécutifs).

2. Définir le format de contract

Choisir une convention unique (Avro, JSON Schema, format dbt model + contract). Stocker dans Git, à côté du code producteur ou dans un repo dédié.

3. Implémenter la validation côté producteur

• CI : refuser une PR qui casse la compatibilité (linting de schéma).
• Build : générer les modèles typés côté producteur (Avro, Protobuf, Pydantic).
• Run : valider chaque événement émis contre son schéma déclaré.

4. Implémenter la validation côté consommateur

• Tests data : assertions dbt, Great Expectations, Soda à chaque run.
• Alertes : panne immédiate si un champ disparaît, change de type, ou viole une contrainte.

5. Gouverner les changements

• Versionner chaque contract (v1, v2…).
• Distinguer changements compatibles (ajout de champ optionnel) vs breaking (suppression, renommage, type change).
• Fenêtres de dépréciation : v1 reste exposé X mois pendant que v2 est promu.
• Communication : tous les consommateurs sont notifiés avant qu'une version soit supprimée.

Compatibilité : les règles classiques

Type de changement	Compatibilité
Ajout d'un champ optionnel avec valeur par défaut	Backward compatible
Renommage d'un champ	Breaking
Suppression d'un champ	Breaking
Changement de type (int → string)	Breaking
Restriction d'enum (retrait d'une valeur)	Breaking
Élargissement d'enum (ajout d'une valeur)	Backward compatible si consommateurs tolèrent
Changement de sémantique (unité, format)	Breaking métier (souvent invisible)

Patterns d'adoption

Pattern "producer-driven"

Le producteur définit et publie. Les consommateurs s'abonnent à la version qui leur convient. Adapté quand l'équipe applicative a une culture API mature.

Pattern "consumer-driven"

Les consommateurs expriment leurs besoins (champs, qualité, fraîcheur). Le producteur s'engage à respecter cet ensemble agrégé. Adapté quand les consommateurs sont peu nombreux et critiques.

Pattern "shift-left"

La validation du schéma est avancée le plus à gauche possible : dans le code applicatif, avant que la donnée touche le pipeline. Réduit drastiquement les régressions découvertes en aval.

Intégration avec dbt et le warehouse

• dbt supporte nativement les contracts sur les modèles (déclarations de colonnes, types, contraintes).
• Un build dbt en CI échoue si le modèle ne respecte plus son contract.
• Couplé à un Schema Registry côté ingestion, on couvre toute la chaîne event → warehouse → dashboard.

Voir dbt & analytics engineering.

Coûts et organisation

• Coût initial : non négligeable (outillage, formation, refactor des producteurs).
• ROI : forte réduction des incidents data, accélération des projets analytics, confiance accrue des métiers.
• Profils impliqués : data engineers, backend engineers (côté producteurs), analytics engineers, data steward.

Conclusion : transformer les hypothèses implicites en engagements vérifiés

Les Data Contracts ne sont pas un projet outillage, c'est un changement de contrat social entre équipes : on ne livre plus une donnée "à charge du consommateur de la nettoyer", on livre un produit dont la qualité est garantie et vérifiée. Combinés à un Data Mesh ou à une plateforme centralisée, ils sont l'un des plus puissants leviers de fiabilité data.

Pour aller plus loin :

• Data Mesh en pratique
• Data observability : détecter les pipelines silencieusement cassés
• CDC & streaming temps réel
• dbt & analytics engineering

ForTeam IT positionne des data engineers, analytics engineers et architectes data qui maîtrisent les Data Contracts, le Schema Registry et la fiabilisation des pipelines. Si c'est votre terrain, vous êtes au bon endroit.

Rejoindre ForTeam IT