Data contracts : le nouveau standard des accords de qualité entre équipes

Vos pipelines de données cassent. Pas à cause de bugs. Parce que personne ne s'est mis d'accord sur ce à quoi la donnée devait ressembler avant de la construire.

Le data contractdata contractAccord formel entre l'équipe qui produit les données et celles qui les consomment, fixant structure, sens, qualité et responsabilité en cas de rupture.Voir la définition complète → est la solution, et c'est l'une des innovations de gouvernance les plus pratiques des cinq dernières années.

Le problème que les data contracts résolvent

Dans une organisation data classique, le trajet de la donnée depuis la source jusqu'au consommateur ressemble à ceci :

1. Un ingénieur de production ajoute un nouveau champ à la réponse de l'APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → de checkout
2. Il oublie (ou ignore) qu'un pipeline de donnéespipeline de donnéesSéquence automatisée d'étapes qui déplace les données de la source vers la destination : ingestion, transformation, validation et chargement, pour qu'elles arrivent propres et prêtes à l'emploi.Voir la définition complète → en aval dépend du schémamaUtiliser un logiciel pour automatiser les tâches et campagnes marketing répétitives, afin de personnaliser à grande échelle sur des canaux comme l'email, le web et le social.Voir la définition complète → existant
3. Le pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète → casse silencieusement : il traite la donnée mais produit des résultats incorrects
4. Trois semaines plus tard, un analyste métier remarque que les chiffres de revenus semblent faux
5. L'équipe data passe deux jours à débugger sur six systèmes pour trouver la source

Cela arrive partout, chaque semaine, dans toute organisation dotée d'une infrastructure data non triviale. Ce n'est pas un problème humain. C'est un problème d'architecture : il n'existe aucun accord formel entre les producteurs de données (les équipes d'ingénierie qui construisent les systèmes sources) et les consommateurs de données (les équipes data qui construisent les pipelines et l'analytics).

Un data contract est cet accord. Il précise :

• Schéma : la structure de la donnée, les noms de champs, les types, le caractère nullable
• Sémantique : ce que signifie chaque champ, les définitions métier, pas seulement les noms techniques
• SLA de qualité : les seuils minimaux de qualité, complétude, fraîcheur, validité
• Ownership : qui est responsable de la donnée (producteur) et qui la consomme
• Gestion du changement : comment et quand les changements de schéma seront communiqués

Quand l'ingénieur de production ajoute ce nouveau champ, le data contract est mis à jour. Le changement déclenche des tests automatisés. Le pipeline est mis à jour avant de casser. Le dashboard de l'analyste ne voit jamais le problème.

Anatomie d'un data contract

Un data contract est le plus souvent un fichier YAML ou JSON stocké dans le gestionnaire de versions (Git), aux côtés du code qui produit la donnée. Un exemple simplifié préciserait :

• contract.name : checkout_events
• contract.owner : ecommerce-platform-team
• contract.consumers : data-analytics-team, marketing-team
• contract.schema : order_id (string, required), order_amount_eur (decimal, required, "Total en EUR TTC hors livraison")
• contract.quality_sla : complétude 99,5 %, fraîcheur ≤15 min, aucune valeur order_id nulle
• contract.change_policy : préavis de 14 jours, les breaking changes requièrent consumer_approval

Quand ce contrat est violé, que order_amount_eur contient des valeurs nulles, ou que la fraîcheur dépasse 15 minutes, une alerte se déclenche. L'équipe productrice est notifiée. Les consommateurs ne sont pas surpris par une qualité de données dégradée : ils sont notifiés de la violation.

Le programme interne de data contracts de Shopify

Shopify a déployé un programme interne de data contracts à l'échelle de toute sa plateforme data. Leur approche : tout jeu de données servi par leur plateforme data interne doit avoir un contrat. Les équipes qui consomment de la donnée sans contrat ne peuvent pas tenir les producteurs pour responsables de la qualité. Les équipes qui produisent de la donnée sans contrat ne peuvent pas prétendre que les consommateurs en aval l'utilisent correctement.

Le résultat : une réduction significative des incidents de pipeline causés par le schema drift, un modèle de responsabilité plus clair sur la qualité des données, et une analyse des causes racines plus rapide quand un problème survient.

Mettre en place des data contracts : par où commencer

N'essayez pas de tout contractualiser d'un coup. Identifiez les cinq flux de données les plus critiques pour le business, ceux dont la défaillance fait le plus mal. Contractualisez ceux-là d'abord. Servez-vous de l'expérience pour affiner votre template de contrat et votre processus de gestion du changement. Puis passez à l'échelle.

Les outils du domaine : Soda (test de contrats), Great Expectations (validation de la qualité des données), Gable.ai (plateforme de gestion de data contracts), dbt contracts (intégré à dbt pour la couche de transformation). L'outillage mûrit vite, choisissez selon l'endroit de votre stack où vous voulez faire appliquer les contrats.