Data Contracts : Accords de Schéma entre Producteurs et Consommateurs
Le Problème que Résolvent les Data Contracts
Dans la plupart des organisations, les producteurs de données (équipes applicatives) et les consommateurs (équipes analytics, ML) n'ont aucun accord formel. L'équipe applicative change un nom de colonne, ajoute un champ ou modifie une valeur d'enum, et les pipelines en aval cassent silencieusement.
Les data contracts établissent un accord explicite entre producteurs et consommateurs sur la forme, la sémantique et la qualité des données.
Contenu d'un Data Contract
| Élément | Description | Exemple |
|---|---|---|
| Schéma | Noms des champs, types, nullabilité | user_id: string, not null |
| Sémantique | Sens métier de chaque champ | "user_id est l'identifiant unique global du système d'auth" |
| Garanties de qualité | SLOs pour fraîcheur, complétude, validité | "Mis à jour sous 1h, < 0,01% de nulls" |
| Propriété | Équipe responsable du contrat | "Équipe: Plateforme Utilisateur" |
| Versioning | Comment le contrat évolue | "Versioning sémantique" |
| Politiques d'accès | Qui peut consommer, sous quelles conditions | "Champs PII restreints" |
Changements Cassants vs Non-Cassants
| Type de Changement | Cassant | Non-Cassant |
|---|---|---|
| Supprimer un champ | Oui | -- |
| Renommer un champ | Oui | -- |
| Changer le type d'un champ | Oui | -- |
| Ajouter un champ optionnel | -- | Oui |
| Élargir un type (int32 vers int64) | Dépend | Généralement oui |
| Ajouter une valeur d'enum | Dépend | Si les consommateurs gèrent les valeurs inconnues |
| Rendre non-nullable un champ nullable | Oui | -- |
Les changements cassants nécessitent une coordination avec les consommateurs.
Extrait de la fiche « Data Contracts » · Demander la fiche complète
Registres de Schémas
Les registres de schémas appliquent la conformité des contrats à l'exécution :
| Registre | Formats Supportés | Intégration |
|---|---|---|
| Confluent Schema Registry | Avro, Protobuf, JSON Schema | Kafka-natif |
| AWS Glue Schema Registry | Avro, JSON Schema | Écosystème AWS |
| Apicurio Registry | Avro, Protobuf, JSON Schema, OpenAPI | Open source |
| Buf | Protobuf | Workflows gRPC/Protobuf |
| Mode | New schema can read | Safe change | Deploy first |
|---|---|---|---|
| BACKWARD | data written with the previous schema | delete a field, add an optional field with a default | consumers |
| FORWARD | old schema can read new data | add a field, delete an optional field | producers |
| FULL | both directions | add or delete optional fields with defaults only | either |
| *_TRANSITIVE | same, against all earlier versions | same, checked against every version | - |
| NONE | no check | anything (breaks consumers silently) | - |
Extrait de la fiche « Event Streams and Kafka » · Demander la fiche complète
Test de Contrats
Le test de contrats vérifie que les données sont conformes. Cela peut se faire :
- À l'écriture : le registre de schémas rejette les messages non conformes
- En CI/CD : les changements de schéma validés avant le merge
- À l'exécution du pipeline : dbt tests ou Great Expectations valident les specs
- En continu : les outils d'observabilité surveillent la conformité aux SLOs
Extrait de la fiche « Data Contracts » · Demander la fiche complète
Implications Organisationnelles
Les data contracts modifient la dynamique de pouvoir :
- Les producteurs ne peuvent plus faire de changements cassants silencieux
- Les consommateurs obtiennent de la prévisibilité
- Un processus de négociation de contrat est nécessaire
- Les politiques de versioning et de dépréciation doivent être définies
C'est un défi de gouvernance, pas seulement technique.
Quand Introduire les Data Contracts
- Vous avez des cassures de pipeline récurrentes dues aux changements de schéma amont
- Plusieurs équipes consomment les mêmes données avec des attentes différentes
- Vous adoptez le Data Mesh et avez besoin de garanties d'interopérabilité
- Les exigences réglementaires demandent du lignage et de l'auditabilité