Qu'est-ce que les Data Contracts et pourquoi sont-ils importants ?
Qu'est-ce que les Data Contracts et pourquoi sont-ils importants ?
6 janv. 2026
Fabiana Ferraz
Fabiana Ferraz
Fabiana Ferraz
Rédacteur technique chez Soda
Rédacteur technique chez Soda
Rédacteur technique chez Soda
Table des matières
Si vous avez entendu le terme « data contracts » partout, mais que vous n'avez toujours pas de voie claire du concept à la mise en œuvre, vous n'êtes pas seul. Les data contracts gagnent en popularité à mesure que les écosystèmes de données distribués s'étendent, mais le chemin de la théorie à la pratique est loin d'être simple. La plupart des équipes comprennent l'idée des data contracts, mais ont du mal à transformer des attentes partagées en quelque chose qui est réellement appliqué en production.
Aujourd'hui, l'application de la qualité est généralement mise en œuvre par le biais de vérifications dans les pipelines de données qui valident le schéma, la nullabilité et les plages de base. Les ingénieurs ajoutent ces vérifications à mesure que les données traversent les étapes d'ingestion et de transformation. Bien que utiles, ces validations opèrent localement : chaque pipeline applique ses propres règles, basées sur le contexte local et le jugement individuel. Aucun système unique n'a de visibilité sur l'ensemble des attentes placées sur un jeu de données.
Lorsque les règles de qualité sont dispersées dans les pipelines, les équipes perdent une compréhension commune de ce que signifie réellement « bonne donnée ». Les consommateurs ne peuvent pas voir facilement ce qui a été validé, les producteurs ne savent pas sur quelles garanties s'appuient les utilisateurs en aval, et les métadonnées s'éloignent rapidement de la réalité. Ce qui fonctionne pour les pipelines individuels échoue au niveau de l'organisation, où la confiance doit s'étendre aux équipes, aux domaines et aux cas d'utilisation.
Les data contracts comblent cet écart en introduisant un accord partagé et applicable entre les producteurs de données et les consommateurs de données. Au lieu de s'appuyer sur des vérifications dispersées spécifiques aux pipelines, ils fournissent un moyen structuré de rendre les attentes explicites, visibles et fiables entre équipes et systèmes.
Cet article explique ce que sont les data contracts, pourquoi ils deviennent essentiels, ce qu'ils contiennent, et comment ils transforment le flux de travail entre producteurs et consommateurs. Il se termine par une vue d'ensemble de la manière dont Soda soutient le développement piloté par les contrats pour les utilisateurs techniques et non techniques afin que le concept de data contracts puisse être traduit en application réelle.
Qu'est-ce qu'un Data Contract?
Un data contract est un accord applicable entre les producteurs et les consommateurs de données qui définit comment les données doivent être structurées, validées et gérées à mesure qu'elles traversent un pipeline.
Il agit comme une couche d'interface, définissant explicitement quelles données sont fournies, sous quelles conditions, et avec quelles garanties. Semblable à une API dans le développement logiciel.
Dans l'ingénierie logicielle, les APIs définissent la structure, les garanties et le comportement sur lesquels les systèmes en aval peuvent s'appuyer. Elles encapsulent la logique interne et exposent uniquement des interfaces intentionnelles et stables. Les data contracts appliquent le même principe à l'ingénierie des données en définissant les règles que les producteurs doivent respecter et les conditions sur lesquelles les consommateurs peuvent compter.
Dans le même temps, les data contracts transforment ces attentes en spécifications exécutables qui peuvent être vérifiées en continu par rapport aux données de production.
Le data contract devient une interface partagée que les deux parties, producteurs et consommateurs, peuvent accéder, comprendre et valider, créant une source commune de vérité et transformant les attentes en règles explicites, réutilisables et applicables.
En conséquence, le schéma, la nullabilité, la fraîcheur, les plages et les contraintes de domaine cessent d'être des directives informelles et deviennent des garanties explicites soutenues par une validation automatisée avant que les données ne se déplacent en aval.
Un data contract passe de la gouvernance des données d'une documentation descriptive à des attentes exécutables.
Un data contract n'est pas une documentation statique ponctuelle, une définition de schéma ou simplement une liste d'exigences. C'est un système d'enregistrement pour les métadonnées qui est lisible par machine, exécutable et vérifiable automatiquement. Avant tout, il est autoritaire : une interface partagée unique où les règles sont définies, convenues, versionnées et appliquées tout au long du cycle de vie des données.
En bref, un data contract sépare deux préoccupations connexes et les réunit de manière contrôlée :
En tant qu'interface pour les données, il définit ce que les producteurs promettent de livrer et ce que les consommateurs peuvent s'appuyer en termes de structure, de sémantique et d'utilisation.
En tant que spécification exécutable, il vérifie en continu des propriétés clés — telles que le schéma et les règles de qualité critiques — sur chaque nouveau lot de données.
En créant un registre pour les métadonnées et en testant ce qui est testable, les data contracts empêchent les métadonnées de s'éloigner de la réalité et créent une source fiable de la vérité qui reste en synchronisation avec les données elles-mêmes.
Pourquoi avons-nous besoin de Data Contracts?
Le défi principal dans tout écosystème de données est de livrer les bonnes données, au bon endroit, au bon moment, et avec des garanties auxquelles les consommateurs peuvent faire confiance. À mesure que les organisations se développent, les données deviennent plus distribuées entre les domaines, les équipes et les systèmes. Pourtant, la manière dont les données sont validées et publiées évolue rarement au même rythme.
En pratique, la plupart des organisations considèrent la production de données comme une préoccupation d'ingénierie interne plutôt qu'un processus de publication. De nouveaux lots de données sont mis à disposition des consommateurs sans vérifier systématiquement s'ils correspondent toujours aux attentes dont les utilisateurs en aval dépendent. Cette déconnexion crée trois problèmes systémiques.
Des attentes mal alignées entre producteurs et consommateurs, causées par l'absence d'une interface partagée et explicite pour les données.
Une validation fragmentée et incohérente, où les vérifications de qualité dépendent des pipelines individuels et des pratiques d'ingénierie plutôt que des normes appliquées.
Aucune source de vérité autoritaire, laissant les consommateurs incapables de vérifier si les données correspondent réellement à ses attentes publiées.
Attentes mal alignées entre les équipes
Les producteurs optimisent les performances opérationnelles et la rapidité de livraison, tandis que les consommateurs optimisent la continuité analytique et l'interprétabilité. Les ingénieurs de données se situent entre les deux, essayant de concilier des incitations incompatibles tout en gardant les pipelines fiables et évolutifs.
Bien souvent, les producteurs n'ont pas de visibilité sur ce dont les consommateurs dépendent, et les consommateurs n'ont aucune garantie que les changements en amont ne les feront pas échouer.
Un producteur pourrait renommer ou supprimer un champ parce que le changement fait sens dans l'application qu'ils maintiennent, ignorant que le même champ alimente des modèles de prévision, des tableaux de bord opérationnels ou des rapports de conformité.
Sans un contrat explicite et partagé, les attentes restent implicites et fragiles. La solution nécessite une interface formelle qui déclare clairement ce que les producteurs s'engagent à livrer et ce sur quoi les consommateurs peuvent se fier.
Validation fragmentée et incohérente
Lorsque les attentes ne sont pas partagées ou explicites, les changements se propagent de manière imprévisible, et les équipes découvrent les problèmes seulement après que la logique en aval a déjà échoué. Les ingénieurs peuvent ajouter des vérifications à leurs pipelines, mais que les données soient testées ou non, et dans quelle mesure, dépend du jugement individuel et des pratiques locales. En conséquence, certains jeux de données sont bien validés, tandis que d'autres sont à peine vérifiés.
D'un point de vue organisationnel, cela rend impossible de garantir un niveau minimum de qualité. Pour les consommateurs découvrant des données dans des catalogues ou des outils de découverte, il n'y a pas de moyen fiable de savoir si un jeu de données a été vérifié ou quelles garanties il offre réellement.
Par conséquent, personne ne peut voir l'ensemble des attentes, et aucun mécanisme ne garantit qu'elles sont appliquées de manière cohérente entre les jeux de données ou les environnements.
Si chaque nouveau lot de données est effectivement une publication, alors la validation ne peut pas être optionnelle. Elle doit être appliquée systématiquement avant que les données ne soient publiées aux consommateurs. Cela nécessite des flux de travail et des lignes directrices qui garantissent que le test est une condition préalable à la disponibilité des données.
Absence de source de vérité autoritaire
Même lorsqu'elles documentent les attentes, cette documentation est généralement descriptive plutôt qu'applicable. Parce qu'elle est déconnectée de l'exécution, elle devient obsolète dès que les données sous-jacentes changent. Les équipes finissent alors par s'appuyer sur des alignements informels et un débogage réactif plutôt que sur des accords explicites.
Les producteurs ne savent souvent pas quelles attentes sont réellement importantes, et les consommateurs ne peuvent pas vérifier si les données qu'ils reçoivent respectent encore ce qui a été promis. Le problème fondamental est l'absence d'une source unique, autoritaire de vérité qui reflète à la fois les attentes prévues et le comportement réel des données.
Ce qui est nécessaire, c'est un système d'enregistrement exécutable, qui reste aligné avec la réalité en validant continuellement les données par rapport aux attentes publiées.
En savoir plus sur Pourquoi les Data Contracts : 5 Raisons pour lesquelles les Leaders devraient commencer maintenant
Pour simplifier, des attentes mal alignées, une validation fragmentée et l'absence d'une source partagée de vérité pointent tous vers le même problème sous-jacent : les données sont publiées sans une interface clairement définie et appliquée. En conséquence, les changements se propagent de façon imprévisible, et les défaillances sont souvent découvertes seulement après l'échec des systèmes en aval.
Un développement piloté par contrat aborde les problèmes ci-dessus en traitant le data contract comme l'API des données, rendant ainsi visibles, examinables et testables les changements avant qu'ils n'atteignent les consommateurs.
Développement piloté par contrat
Alors, comment fonctionne réellement un data contract en pratique, et comment prévient-il les ruptures au fil du temps ?
En pratique, le développement piloté par contrat introduit un flux de travail partagé :
Les consommateurs définissent les attentes sur lesquelles ils s'appuient pour créer des rapports, des modèles et des applications.
Les producteurs mettent en œuvre et appliquent le contrat, en s'engageant à fournir des données qui répondent aux attentes des consommateurs.
Les pipelines appliquent automatiquement le contrat, en validant chaque nouveau lot de données avant qu'il ne soit disponible en aval.
La validation des contrats est intégrée dans le pipeline comme une barrière de sécurité automatisée. Chaque nouveau lot de données est traité comme une publication et vérifié par rapport au contrat publié avant de parvenir aux consommateurs. Les changements perturbateurs sont détectés tôt, les mises à jour incompatibles sont identifiées rapidement, et la confiance est maintenue entre les équipes.
Par conséquent, les data contracts génèrent :
un accord partagé et explicite entre producteurs et consommateurs.
une spécification unifiée, appliquée de manière cohérente
une spécification unique et autoritaire qui définit, versionne et applique ce que signifie la qualité
Qui détient le Data Contract ?
La propriété d'un data contract ne signifie pas la responsabilité de la mise en œuvre. Au lieu de cela, elle reflète qui définit les exigences par rapport à qui est responsable de les appliquer en production.
Effectivement, la propriété du data contract devrait appartenir aux consommateurs de données, et non aux producteurs. Parce que les producteurs optimisent pour des préoccupations opérationnelles et ne voient souvent pas l'impact analytique en aval, si les producteurs définissent seuls les attentes des contrats, les contrats tendent à refléter ce qui est facile à produire, et non ce qui est sûr à consommer.
Les consommateurs sont idéalement placés pour définir les exigences du contrat car ils comprennent l'impact analytique et commercial des échecs de qualité des données. Ils sont les seuls à savoir vraiment :
quels champs sont critiques pour l'entreprise
quelles plages de valeurs sont acceptables
quelles garanties de fraîcheur, de complétude et de fiabilité sont nécessaires
Cela ne signifie pas que les consommateurs appliquent eux-mêmes les contrats. L'application appartient au pipeline, généralement détenue par les ingénieurs de données et les producteurs. Les consommateurs fixent les attentes, les producteurs s'engagent à les respecter, et les pipelines se assurent automatiquement qu'elles sont respectées.
Que contient un Data Contract ?
En pratique, les data contracts peuvent inclure de nombreux éléments : propriété, documentation, versioning et garanties de compatibilité. Chez Soda, nous nous concentrons sur le cœur exécutable d'un data contract : les attentes de qualité qui peuvent être continuellement validées par rapport aux données de production.
La mise en œuvre des data contracts signifie aborder la qualité des données comme du code. Les équipes peuvent créer une couche de qualité reproductible, testable et appliquée en continu en définissant des attentes dans un contrat contrôlé par version et en les exécutant directement dans le pipeline.
Bien que les implémentations varient, un data contract inclut généralement les éléments de base suivants :
Informations sur le jeu de données :
Le contrat est explicitement lié à un jeu de données unique ou à un produit de données et définit où ces données résident.
Vérifications au niveau du jeu de données :
Ce sont des attentes qui s'appliquent à l'ensemble du jeu de données, telles que les seuils de comptage des lignes, la fraîcheur, l'exhaustivité ou les contraintes inter-colonnes.
Il inclut aussi généralement des garanties de schéma et de structure qui appliquent les noms des colonnes, les types de données et les champs requis.
Vérifications au niveau des colonnes :
Ces règles définissent des valeurs acceptables, des plages, des motifs ou des distributions qui s'appliquent à des colonnes spécifiques, comme les valeurs manquantes, les valeurs valides (par exemple, regex, plage), et les agrégations (par exemple, moyenne, somme).
Voir l'exemple de contrat de données au format YAML ci-dessous :
Lorsque les vérifications échouent, elles mettent en lumière des problèmes qui devraient être examinés. Lorsqu'ils sont intégrés dans des pipelines CI/CD, les contrats peuvent déclencher des notifications aux équipes responsables ou même arrêter le flux jusqu'à ce que le problème soit trouvé et résolu.
Il n'y aura plus de garanties partielles enfouies dans les transformations, de documentation déconnectée ou de conjectures sur ce que signifie "bonnes données". Le pipeline respecte soit le contrat, soit il ne le respecte pas, et lorsqu'il ne le respecte pas, les échecs sont documentés avec des origines claires et un contexte exploitable.
En commençant par les jeux de données les plus importants, les équipes peuvent progressivement étendre l'utilisation d'approches collaboratives où les parties prenantes proposent des vérifications, décident des seuils et définissent ensemble les normes de qualité des données.
Soda Collaborative Data Contracts
Un data contract est plus qu'un ensemble de vérifications de qualité, mais sa valeur ne se matérialise que lorsque les attentes sont exécutables. Soda se concentre sur cette couche exécutable.
Collaborative Data Contracts sont similaires aux tests unitaires pour le test de logiciel, entièrement exécutables et applicables. Ils prennent en charge le versionnage, l'intégration CI et l'évolution coordonnée entre les producteurs et les consommateurs.
Aussi, afin de combler le fossé entre les utilisateurs techniques et commerciaux, les contrats Soda peuvent être rédigés, versionnés, vérifiés et surveillés de trois manières complémentaires afin qu'ils ne perturbent pas le flux de travail de votre équipe :
Data Contracts en tant que code
Git-Managed Contracts offre une manière orientée code de définir et d'appliquer les attentes de qualité des données. En utilisant Soda Core (le moteur open-source de Soda) et le Soda CLI, vous pouvez :
Définir des contrats en YAML + Soda Contracts Language.
Effectuer des vérifications de contrats dans CI/CD.
Envoyer les résultats des vérifications dans Soda Cloud pour la visibilité.
Utiliser Git comme source de vérité pour le contrôle de version, la collaboration et l'examen.
Nous fournissons un exemple d'implémentation technique en utilisant Soda Core dans notre blog précédent, Mise en œuvre des Data Contracts à grande échelle.
Data Contracts sans code
Cloud-Managed Contracts vous permettent de définir et de gérer des attentes de données directement dans l'interface Soda Cloud. Cette approche est idéale pour les analystes de données, les chefs de produit, et les parties prenantes qui préfèrent des interfaces intuitives au code. Sans nécessité de configuration ou de code, l'interface vous permet :
Proposer ou ajouter des règles de qualité avec un éditeur sans code
Publier des contrats d'un clic
Planifier ou exécuter des vérifications de contrats à la demande
Collaborer avec votre équipe et demander des modifications
Tous les résultats des vérifications seront stockés et visualisés dans Soda Cloud. En cas d'échec de vérification d'un contrat, des notifications peuvent être envoyées, ou les nouvelles données peuvent être empêchées de être publiées à des utilisateurs.
Data Contract Copilot
Contract Copilot est une fonctionnalité assistée par AI à l'intérieur de Soda Cloud.
Lorsque vous cliquez pour créer un contrat, le Copilot peut aider en analysant la structure du schéma, et à partir de là, vous pouvez ajouter toutes les vérifications pertinentes.
Demandez en anglais simple et laissez le Contract Copilot générer des vérifications de qualité pour vous. Cela pourrait être aussi simple que d'ajouter des vérifications pour les valeurs manquantes à toutes les colonnes ou de créer des requêtes SQL plus complexes.
Exemple de requête : définir une vérification de qualité qui vérifie si la valeur de la TVA correspond à 21% du prix, en permettant une tolérance jusqu'à un cent.
L'avantage principal est que les utilisateurs non techniques n'ont besoin d'aucune compétence de codage ou de passer par de nombreux clics pour proposer des modifications au contrat.
Cette approche hybride permet la collaboration entre les équipes où les utilisateurs du secteur apportent leur expertise dans le contrat, tandis que les ingénieurs assurent la précision, la cohérence et la gouvernance.
Avec YAML, Soda UI ou Copilot, en quelques minutes, vous pouvez créer des vérifications qui garantissent :
L'intégrité du schéma
L'exactitude, la complétude et la cohérence des données
Fraîcheur, disponibilité et latence
L'absence de violations de logique commerciale
Bonnes pratiques pour des Data Contracts efficaces
Un data contract répond à la lutte que la gouvernance des données a longtemps menée pour amener les normes et la documentation des données du "papier" au code. Il ne définit pas seulement ce que devraient ressembler les données, mais vérifie également systématiquement les spécifications ajoutées afin que les équipes concernées puissent être alertées lorsqu'une condition échoue.
L'intégration de ces pratiques dans le flux de travail de l'ingénierie des données conduit à améliorer l'écosystème des données, résultant en des données riches en contexte, bien gouvernées et de confiance. Cependant, la mise en œuvre des data contracts ne devrait pas nécessiter (pas obligatoirement) (vous?) une réorganisation complète de votre architecture de données. Vous pouvez commencer petit, démontrer la valeur, puis étendre progressivement.
Commencez avec des données critiques
Mettre chaque jeu de données sous contrat est impraticable. Commencez par les tableaux de bord critiques pour l'entreprise et les entrées ML qui nécessitent de la cohérence, afin que l'effort soit dirigé là où il est le plus efficace. Ensuite, étendez la couverture en fonction des points faibles et de la valeur ajoutée.
Favorisez la collaboration interéquipes
Les contrats réussissent lorsque les producteurs comprennent la valeur et que les consommateurs expriment leurs besoins. Les deux parties devraient travailler ensemble pour définir le data contract.
Formalisez la communication
Traitez les changements de contrat comme des événements de premier ordre. Utilisez des tickets, des journaux de modifications ou des demandes de tirage pour documenter les mises à jour. Une bonne communication réduit les surprises et augmente la confiance de l'équipe.
Définissez clairement la propriété
Assurez-vous que lorsque les choses se cassent, quelqu'un est averti et peut approuver les changements.
Automatisez l'application
Automatisez les vérifications du pipeline CI et configurez des alertes de violation.
Versionnez délibérément les contrats
Contrôlez les mises à jour de contrat, y compris les nouvelles versions et les vérifications de compatibilité rétroactive.
Surveillez au fil du temps
Configurez une surveillance des contrats clés pour détecter les anomalies ou les dérives au fil du temps.
Que ce soit pour vérifier les comptages de lignes, les valeurs manquantes ou invalides, ou l'intégrité du schéma, l'objectif est de détecter les problèmes tôt, de réduire les incidents et de rassurer les consommateurs de données. En introduisant des règles de validation et en clarifiant les attentes, les data contracts améliorent la transparence et rendent l'écosystème de données intrinsèquement plus robuste.
Foire aux Questions
Les Data Contracts de Soda sont-ils compatibles avec l'ODCS (Open Data Contract Standard) ?
Oui, nous supportons l'OCDS. OCDS est une couche de documentation d'un data contract. Soda est une couche d'exécution. Vous pouvez écrire votre data contract en syntaxe OCDS, et Soda l'exécutera en le traduisant en Soda Contract Language. C'est ainsi que nous rendons l'OCDS applicable dans les pipelines de données réels.
Pourquoi YAML est-il le langage de Soda pour les Data Contracts?
YAML est un format compatible avec tout contrôle de version basé sur Git, permettant le versionnage, les demandes de tirage et l'intégration dans un flux de travail d'ingénierie. De plus, il offre une lisibilité et ne nécessite aucune connaissance en codage, permettant à toutes les personnes (analystes, experts de domaine, utilisateurs commerciaux) de lire et de comprendre le contrat.
Les data contracts sont-ils un processus ou un changement technique ?
Les deux. Techniquement, ils introduisent des spécifications exécutables, une validation automatisée et l'application de contrats dans les pipelines. Au niveau organisationnel, ils formalisent la collaboration entre producteurs et consommateurs en rendant les attentes explicites, versionnées, et révisables.
Les data contracts remplacent-ils les outils d'observabilité des données ?
Non. Les data contracts et l'observabilité des données résolvent des problèmes différents et complémentaires.
Les data contracts sont des mesures préventives qui définissent et appliquent des attentes connues (schéma, contraintes, fraîcheur et règles, commerciales) avant la consommation des données.
L'observabilité des données est une technique de détection qui surveille les jeux de données en production pour identifier des problèmes inconnus tels que les dérives, les anomalies ou les changements de distribution inattendus.
Que se passe-t-il lorsque une vérification de contrat échoue en production ?
Lorsque une vérification de contrat échoue, le résultat dépend de la configuration du pipeline.
Les actions courantes incluent : rediriger les enregistrements échoués vers une table de quarantaine ou d'erreurs; déclencher des alertes pour enquête sans arrêter le pipeline; empêcher la propagation de données invalides vers les systèmes en aval; ou faire échouer le pipeline entièrement pour des violations critiques.
Comment les data contracts s'intègrent-ils aux pipelines CI/CD?
Les définitions de contrat sont stockées sous forme de code (par exemple, en YAML) et versionnées dans Git. Lors des exécutions CI/CD, les vérifications de contrat s'exécutent en tant qu'étapes d'ingestion, de transformation ou de déploiement.
Pour voir comment les Data Contracts de Soda peuvent être validés automatiquement lors de l'exécution du pipeline, regardez la vidéo tuto ci-dessous.
Data Contracts de Soda en action
Nous avons récemment organisé un webinaire sur la mise en œuvre des Data Contracts. Regardez la vidéo : Data Contracts et Test de Données dans les Pipelines de Données Modernes
Si vous avez entendu le terme « data contracts » partout, mais que vous n'avez toujours pas de voie claire du concept à la mise en œuvre, vous n'êtes pas seul. Les data contracts gagnent en popularité à mesure que les écosystèmes de données distribués s'étendent, mais le chemin de la théorie à la pratique est loin d'être simple. La plupart des équipes comprennent l'idée des data contracts, mais ont du mal à transformer des attentes partagées en quelque chose qui est réellement appliqué en production.
Aujourd'hui, l'application de la qualité est généralement mise en œuvre par le biais de vérifications dans les pipelines de données qui valident le schéma, la nullabilité et les plages de base. Les ingénieurs ajoutent ces vérifications à mesure que les données traversent les étapes d'ingestion et de transformation. Bien que utiles, ces validations opèrent localement : chaque pipeline applique ses propres règles, basées sur le contexte local et le jugement individuel. Aucun système unique n'a de visibilité sur l'ensemble des attentes placées sur un jeu de données.
Lorsque les règles de qualité sont dispersées dans les pipelines, les équipes perdent une compréhension commune de ce que signifie réellement « bonne donnée ». Les consommateurs ne peuvent pas voir facilement ce qui a été validé, les producteurs ne savent pas sur quelles garanties s'appuient les utilisateurs en aval, et les métadonnées s'éloignent rapidement de la réalité. Ce qui fonctionne pour les pipelines individuels échoue au niveau de l'organisation, où la confiance doit s'étendre aux équipes, aux domaines et aux cas d'utilisation.
Les data contracts comblent cet écart en introduisant un accord partagé et applicable entre les producteurs de données et les consommateurs de données. Au lieu de s'appuyer sur des vérifications dispersées spécifiques aux pipelines, ils fournissent un moyen structuré de rendre les attentes explicites, visibles et fiables entre équipes et systèmes.
Cet article explique ce que sont les data contracts, pourquoi ils deviennent essentiels, ce qu'ils contiennent, et comment ils transforment le flux de travail entre producteurs et consommateurs. Il se termine par une vue d'ensemble de la manière dont Soda soutient le développement piloté par les contrats pour les utilisateurs techniques et non techniques afin que le concept de data contracts puisse être traduit en application réelle.
Qu'est-ce qu'un Data Contract?
Un data contract est un accord applicable entre les producteurs et les consommateurs de données qui définit comment les données doivent être structurées, validées et gérées à mesure qu'elles traversent un pipeline.
Il agit comme une couche d'interface, définissant explicitement quelles données sont fournies, sous quelles conditions, et avec quelles garanties. Semblable à une API dans le développement logiciel.
Dans l'ingénierie logicielle, les APIs définissent la structure, les garanties et le comportement sur lesquels les systèmes en aval peuvent s'appuyer. Elles encapsulent la logique interne et exposent uniquement des interfaces intentionnelles et stables. Les data contracts appliquent le même principe à l'ingénierie des données en définissant les règles que les producteurs doivent respecter et les conditions sur lesquelles les consommateurs peuvent compter.
Dans le même temps, les data contracts transforment ces attentes en spécifications exécutables qui peuvent être vérifiées en continu par rapport aux données de production.
Le data contract devient une interface partagée que les deux parties, producteurs et consommateurs, peuvent accéder, comprendre et valider, créant une source commune de vérité et transformant les attentes en règles explicites, réutilisables et applicables.
En conséquence, le schéma, la nullabilité, la fraîcheur, les plages et les contraintes de domaine cessent d'être des directives informelles et deviennent des garanties explicites soutenues par une validation automatisée avant que les données ne se déplacent en aval.
Un data contract passe de la gouvernance des données d'une documentation descriptive à des attentes exécutables.
Un data contract n'est pas une documentation statique ponctuelle, une définition de schéma ou simplement une liste d'exigences. C'est un système d'enregistrement pour les métadonnées qui est lisible par machine, exécutable et vérifiable automatiquement. Avant tout, il est autoritaire : une interface partagée unique où les règles sont définies, convenues, versionnées et appliquées tout au long du cycle de vie des données.
En bref, un data contract sépare deux préoccupations connexes et les réunit de manière contrôlée :
En tant qu'interface pour les données, il définit ce que les producteurs promettent de livrer et ce que les consommateurs peuvent s'appuyer en termes de structure, de sémantique et d'utilisation.
En tant que spécification exécutable, il vérifie en continu des propriétés clés — telles que le schéma et les règles de qualité critiques — sur chaque nouveau lot de données.
En créant un registre pour les métadonnées et en testant ce qui est testable, les data contracts empêchent les métadonnées de s'éloigner de la réalité et créent une source fiable de la vérité qui reste en synchronisation avec les données elles-mêmes.
Pourquoi avons-nous besoin de Data Contracts?
Le défi principal dans tout écosystème de données est de livrer les bonnes données, au bon endroit, au bon moment, et avec des garanties auxquelles les consommateurs peuvent faire confiance. À mesure que les organisations se développent, les données deviennent plus distribuées entre les domaines, les équipes et les systèmes. Pourtant, la manière dont les données sont validées et publiées évolue rarement au même rythme.
En pratique, la plupart des organisations considèrent la production de données comme une préoccupation d'ingénierie interne plutôt qu'un processus de publication. De nouveaux lots de données sont mis à disposition des consommateurs sans vérifier systématiquement s'ils correspondent toujours aux attentes dont les utilisateurs en aval dépendent. Cette déconnexion crée trois problèmes systémiques.
Des attentes mal alignées entre producteurs et consommateurs, causées par l'absence d'une interface partagée et explicite pour les données.
Une validation fragmentée et incohérente, où les vérifications de qualité dépendent des pipelines individuels et des pratiques d'ingénierie plutôt que des normes appliquées.
Aucune source de vérité autoritaire, laissant les consommateurs incapables de vérifier si les données correspondent réellement à ses attentes publiées.
Attentes mal alignées entre les équipes
Les producteurs optimisent les performances opérationnelles et la rapidité de livraison, tandis que les consommateurs optimisent la continuité analytique et l'interprétabilité. Les ingénieurs de données se situent entre les deux, essayant de concilier des incitations incompatibles tout en gardant les pipelines fiables et évolutifs.
Bien souvent, les producteurs n'ont pas de visibilité sur ce dont les consommateurs dépendent, et les consommateurs n'ont aucune garantie que les changements en amont ne les feront pas échouer.
Un producteur pourrait renommer ou supprimer un champ parce que le changement fait sens dans l'application qu'ils maintiennent, ignorant que le même champ alimente des modèles de prévision, des tableaux de bord opérationnels ou des rapports de conformité.
Sans un contrat explicite et partagé, les attentes restent implicites et fragiles. La solution nécessite une interface formelle qui déclare clairement ce que les producteurs s'engagent à livrer et ce sur quoi les consommateurs peuvent se fier.
Validation fragmentée et incohérente
Lorsque les attentes ne sont pas partagées ou explicites, les changements se propagent de manière imprévisible, et les équipes découvrent les problèmes seulement après que la logique en aval a déjà échoué. Les ingénieurs peuvent ajouter des vérifications à leurs pipelines, mais que les données soient testées ou non, et dans quelle mesure, dépend du jugement individuel et des pratiques locales. En conséquence, certains jeux de données sont bien validés, tandis que d'autres sont à peine vérifiés.
D'un point de vue organisationnel, cela rend impossible de garantir un niveau minimum de qualité. Pour les consommateurs découvrant des données dans des catalogues ou des outils de découverte, il n'y a pas de moyen fiable de savoir si un jeu de données a été vérifié ou quelles garanties il offre réellement.
Par conséquent, personne ne peut voir l'ensemble des attentes, et aucun mécanisme ne garantit qu'elles sont appliquées de manière cohérente entre les jeux de données ou les environnements.
Si chaque nouveau lot de données est effectivement une publication, alors la validation ne peut pas être optionnelle. Elle doit être appliquée systématiquement avant que les données ne soient publiées aux consommateurs. Cela nécessite des flux de travail et des lignes directrices qui garantissent que le test est une condition préalable à la disponibilité des données.
Absence de source de vérité autoritaire
Même lorsqu'elles documentent les attentes, cette documentation est généralement descriptive plutôt qu'applicable. Parce qu'elle est déconnectée de l'exécution, elle devient obsolète dès que les données sous-jacentes changent. Les équipes finissent alors par s'appuyer sur des alignements informels et un débogage réactif plutôt que sur des accords explicites.
Les producteurs ne savent souvent pas quelles attentes sont réellement importantes, et les consommateurs ne peuvent pas vérifier si les données qu'ils reçoivent respectent encore ce qui a été promis. Le problème fondamental est l'absence d'une source unique, autoritaire de vérité qui reflète à la fois les attentes prévues et le comportement réel des données.
Ce qui est nécessaire, c'est un système d'enregistrement exécutable, qui reste aligné avec la réalité en validant continuellement les données par rapport aux attentes publiées.
En savoir plus sur Pourquoi les Data Contracts : 5 Raisons pour lesquelles les Leaders devraient commencer maintenant
Pour simplifier, des attentes mal alignées, une validation fragmentée et l'absence d'une source partagée de vérité pointent tous vers le même problème sous-jacent : les données sont publiées sans une interface clairement définie et appliquée. En conséquence, les changements se propagent de façon imprévisible, et les défaillances sont souvent découvertes seulement après l'échec des systèmes en aval.
Un développement piloté par contrat aborde les problèmes ci-dessus en traitant le data contract comme l'API des données, rendant ainsi visibles, examinables et testables les changements avant qu'ils n'atteignent les consommateurs.
Développement piloté par contrat
Alors, comment fonctionne réellement un data contract en pratique, et comment prévient-il les ruptures au fil du temps ?
En pratique, le développement piloté par contrat introduit un flux de travail partagé :
Les consommateurs définissent les attentes sur lesquelles ils s'appuient pour créer des rapports, des modèles et des applications.
Les producteurs mettent en œuvre et appliquent le contrat, en s'engageant à fournir des données qui répondent aux attentes des consommateurs.
Les pipelines appliquent automatiquement le contrat, en validant chaque nouveau lot de données avant qu'il ne soit disponible en aval.
La validation des contrats est intégrée dans le pipeline comme une barrière de sécurité automatisée. Chaque nouveau lot de données est traité comme une publication et vérifié par rapport au contrat publié avant de parvenir aux consommateurs. Les changements perturbateurs sont détectés tôt, les mises à jour incompatibles sont identifiées rapidement, et la confiance est maintenue entre les équipes.
Par conséquent, les data contracts génèrent :
un accord partagé et explicite entre producteurs et consommateurs.
une spécification unifiée, appliquée de manière cohérente
une spécification unique et autoritaire qui définit, versionne et applique ce que signifie la qualité
Qui détient le Data Contract ?
La propriété d'un data contract ne signifie pas la responsabilité de la mise en œuvre. Au lieu de cela, elle reflète qui définit les exigences par rapport à qui est responsable de les appliquer en production.
Effectivement, la propriété du data contract devrait appartenir aux consommateurs de données, et non aux producteurs. Parce que les producteurs optimisent pour des préoccupations opérationnelles et ne voient souvent pas l'impact analytique en aval, si les producteurs définissent seuls les attentes des contrats, les contrats tendent à refléter ce qui est facile à produire, et non ce qui est sûr à consommer.
Les consommateurs sont idéalement placés pour définir les exigences du contrat car ils comprennent l'impact analytique et commercial des échecs de qualité des données. Ils sont les seuls à savoir vraiment :
quels champs sont critiques pour l'entreprise
quelles plages de valeurs sont acceptables
quelles garanties de fraîcheur, de complétude et de fiabilité sont nécessaires
Cela ne signifie pas que les consommateurs appliquent eux-mêmes les contrats. L'application appartient au pipeline, généralement détenue par les ingénieurs de données et les producteurs. Les consommateurs fixent les attentes, les producteurs s'engagent à les respecter, et les pipelines se assurent automatiquement qu'elles sont respectées.
Que contient un Data Contract ?
En pratique, les data contracts peuvent inclure de nombreux éléments : propriété, documentation, versioning et garanties de compatibilité. Chez Soda, nous nous concentrons sur le cœur exécutable d'un data contract : les attentes de qualité qui peuvent être continuellement validées par rapport aux données de production.
La mise en œuvre des data contracts signifie aborder la qualité des données comme du code. Les équipes peuvent créer une couche de qualité reproductible, testable et appliquée en continu en définissant des attentes dans un contrat contrôlé par version et en les exécutant directement dans le pipeline.
Bien que les implémentations varient, un data contract inclut généralement les éléments de base suivants :
Informations sur le jeu de données :
Le contrat est explicitement lié à un jeu de données unique ou à un produit de données et définit où ces données résident.
Vérifications au niveau du jeu de données :
Ce sont des attentes qui s'appliquent à l'ensemble du jeu de données, telles que les seuils de comptage des lignes, la fraîcheur, l'exhaustivité ou les contraintes inter-colonnes.
Il inclut aussi généralement des garanties de schéma et de structure qui appliquent les noms des colonnes, les types de données et les champs requis.
Vérifications au niveau des colonnes :
Ces règles définissent des valeurs acceptables, des plages, des motifs ou des distributions qui s'appliquent à des colonnes spécifiques, comme les valeurs manquantes, les valeurs valides (par exemple, regex, plage), et les agrégations (par exemple, moyenne, somme).
Voir l'exemple de contrat de données au format YAML ci-dessous :
Lorsque les vérifications échouent, elles mettent en lumière des problèmes qui devraient être examinés. Lorsqu'ils sont intégrés dans des pipelines CI/CD, les contrats peuvent déclencher des notifications aux équipes responsables ou même arrêter le flux jusqu'à ce que le problème soit trouvé et résolu.
Il n'y aura plus de garanties partielles enfouies dans les transformations, de documentation déconnectée ou de conjectures sur ce que signifie "bonnes données". Le pipeline respecte soit le contrat, soit il ne le respecte pas, et lorsqu'il ne le respecte pas, les échecs sont documentés avec des origines claires et un contexte exploitable.
En commençant par les jeux de données les plus importants, les équipes peuvent progressivement étendre l'utilisation d'approches collaboratives où les parties prenantes proposent des vérifications, décident des seuils et définissent ensemble les normes de qualité des données.
Soda Collaborative Data Contracts
Un data contract est plus qu'un ensemble de vérifications de qualité, mais sa valeur ne se matérialise que lorsque les attentes sont exécutables. Soda se concentre sur cette couche exécutable.
Collaborative Data Contracts sont similaires aux tests unitaires pour le test de logiciel, entièrement exécutables et applicables. Ils prennent en charge le versionnage, l'intégration CI et l'évolution coordonnée entre les producteurs et les consommateurs.
Aussi, afin de combler le fossé entre les utilisateurs techniques et commerciaux, les contrats Soda peuvent être rédigés, versionnés, vérifiés et surveillés de trois manières complémentaires afin qu'ils ne perturbent pas le flux de travail de votre équipe :
Data Contracts en tant que code
Git-Managed Contracts offre une manière orientée code de définir et d'appliquer les attentes de qualité des données. En utilisant Soda Core (le moteur open-source de Soda) et le Soda CLI, vous pouvez :
Définir des contrats en YAML + Soda Contracts Language.
Effectuer des vérifications de contrats dans CI/CD.
Envoyer les résultats des vérifications dans Soda Cloud pour la visibilité.
Utiliser Git comme source de vérité pour le contrôle de version, la collaboration et l'examen.
Nous fournissons un exemple d'implémentation technique en utilisant Soda Core dans notre blog précédent, Mise en œuvre des Data Contracts à grande échelle.
Data Contracts sans code
Cloud-Managed Contracts vous permettent de définir et de gérer des attentes de données directement dans l'interface Soda Cloud. Cette approche est idéale pour les analystes de données, les chefs de produit, et les parties prenantes qui préfèrent des interfaces intuitives au code. Sans nécessité de configuration ou de code, l'interface vous permet :
Proposer ou ajouter des règles de qualité avec un éditeur sans code
Publier des contrats d'un clic
Planifier ou exécuter des vérifications de contrats à la demande
Collaborer avec votre équipe et demander des modifications
Tous les résultats des vérifications seront stockés et visualisés dans Soda Cloud. En cas d'échec de vérification d'un contrat, des notifications peuvent être envoyées, ou les nouvelles données peuvent être empêchées de être publiées à des utilisateurs.
Data Contract Copilot
Contract Copilot est une fonctionnalité assistée par AI à l'intérieur de Soda Cloud.
Lorsque vous cliquez pour créer un contrat, le Copilot peut aider en analysant la structure du schéma, et à partir de là, vous pouvez ajouter toutes les vérifications pertinentes.
Demandez en anglais simple et laissez le Contract Copilot générer des vérifications de qualité pour vous. Cela pourrait être aussi simple que d'ajouter des vérifications pour les valeurs manquantes à toutes les colonnes ou de créer des requêtes SQL plus complexes.
Exemple de requête : définir une vérification de qualité qui vérifie si la valeur de la TVA correspond à 21% du prix, en permettant une tolérance jusqu'à un cent.
L'avantage principal est que les utilisateurs non techniques n'ont besoin d'aucune compétence de codage ou de passer par de nombreux clics pour proposer des modifications au contrat.
Cette approche hybride permet la collaboration entre les équipes où les utilisateurs du secteur apportent leur expertise dans le contrat, tandis que les ingénieurs assurent la précision, la cohérence et la gouvernance.
Avec YAML, Soda UI ou Copilot, en quelques minutes, vous pouvez créer des vérifications qui garantissent :
L'intégrité du schéma
L'exactitude, la complétude et la cohérence des données
Fraîcheur, disponibilité et latence
L'absence de violations de logique commerciale
Bonnes pratiques pour des Data Contracts efficaces
Un data contract répond à la lutte que la gouvernance des données a longtemps menée pour amener les normes et la documentation des données du "papier" au code. Il ne définit pas seulement ce que devraient ressembler les données, mais vérifie également systématiquement les spécifications ajoutées afin que les équipes concernées puissent être alertées lorsqu'une condition échoue.
L'intégration de ces pratiques dans le flux de travail de l'ingénierie des données conduit à améliorer l'écosystème des données, résultant en des données riches en contexte, bien gouvernées et de confiance. Cependant, la mise en œuvre des data contracts ne devrait pas nécessiter (pas obligatoirement) (vous?) une réorganisation complète de votre architecture de données. Vous pouvez commencer petit, démontrer la valeur, puis étendre progressivement.
Commencez avec des données critiques
Mettre chaque jeu de données sous contrat est impraticable. Commencez par les tableaux de bord critiques pour l'entreprise et les entrées ML qui nécessitent de la cohérence, afin que l'effort soit dirigé là où il est le plus efficace. Ensuite, étendez la couverture en fonction des points faibles et de la valeur ajoutée.
Favorisez la collaboration interéquipes
Les contrats réussissent lorsque les producteurs comprennent la valeur et que les consommateurs expriment leurs besoins. Les deux parties devraient travailler ensemble pour définir le data contract.
Formalisez la communication
Traitez les changements de contrat comme des événements de premier ordre. Utilisez des tickets, des journaux de modifications ou des demandes de tirage pour documenter les mises à jour. Une bonne communication réduit les surprises et augmente la confiance de l'équipe.
Définissez clairement la propriété
Assurez-vous que lorsque les choses se cassent, quelqu'un est averti et peut approuver les changements.
Automatisez l'application
Automatisez les vérifications du pipeline CI et configurez des alertes de violation.
Versionnez délibérément les contrats
Contrôlez les mises à jour de contrat, y compris les nouvelles versions et les vérifications de compatibilité rétroactive.
Surveillez au fil du temps
Configurez une surveillance des contrats clés pour détecter les anomalies ou les dérives au fil du temps.
Que ce soit pour vérifier les comptages de lignes, les valeurs manquantes ou invalides, ou l'intégrité du schéma, l'objectif est de détecter les problèmes tôt, de réduire les incidents et de rassurer les consommateurs de données. En introduisant des règles de validation et en clarifiant les attentes, les data contracts améliorent la transparence et rendent l'écosystème de données intrinsèquement plus robuste.
Foire aux Questions
Les Data Contracts de Soda sont-ils compatibles avec l'ODCS (Open Data Contract Standard) ?
Oui, nous supportons l'OCDS. OCDS est une couche de documentation d'un data contract. Soda est une couche d'exécution. Vous pouvez écrire votre data contract en syntaxe OCDS, et Soda l'exécutera en le traduisant en Soda Contract Language. C'est ainsi que nous rendons l'OCDS applicable dans les pipelines de données réels.
Pourquoi YAML est-il le langage de Soda pour les Data Contracts?
YAML est un format compatible avec tout contrôle de version basé sur Git, permettant le versionnage, les demandes de tirage et l'intégration dans un flux de travail d'ingénierie. De plus, il offre une lisibilité et ne nécessite aucune connaissance en codage, permettant à toutes les personnes (analystes, experts de domaine, utilisateurs commerciaux) de lire et de comprendre le contrat.
Les data contracts sont-ils un processus ou un changement technique ?
Les deux. Techniquement, ils introduisent des spécifications exécutables, une validation automatisée et l'application de contrats dans les pipelines. Au niveau organisationnel, ils formalisent la collaboration entre producteurs et consommateurs en rendant les attentes explicites, versionnées, et révisables.
Les data contracts remplacent-ils les outils d'observabilité des données ?
Non. Les data contracts et l'observabilité des données résolvent des problèmes différents et complémentaires.
Les data contracts sont des mesures préventives qui définissent et appliquent des attentes connues (schéma, contraintes, fraîcheur et règles, commerciales) avant la consommation des données.
L'observabilité des données est une technique de détection qui surveille les jeux de données en production pour identifier des problèmes inconnus tels que les dérives, les anomalies ou les changements de distribution inattendus.
Que se passe-t-il lorsque une vérification de contrat échoue en production ?
Lorsque une vérification de contrat échoue, le résultat dépend de la configuration du pipeline.
Les actions courantes incluent : rediriger les enregistrements échoués vers une table de quarantaine ou d'erreurs; déclencher des alertes pour enquête sans arrêter le pipeline; empêcher la propagation de données invalides vers les systèmes en aval; ou faire échouer le pipeline entièrement pour des violations critiques.
Comment les data contracts s'intègrent-ils aux pipelines CI/CD?
Les définitions de contrat sont stockées sous forme de code (par exemple, en YAML) et versionnées dans Git. Lors des exécutions CI/CD, les vérifications de contrat s'exécutent en tant qu'étapes d'ingestion, de transformation ou de déploiement.
Pour voir comment les Data Contracts de Soda peuvent être validés automatiquement lors de l'exécution du pipeline, regardez la vidéo tuto ci-dessous.
Data Contracts de Soda en action
Nous avons récemment organisé un webinaire sur la mise en œuvre des Data Contracts. Regardez la vidéo : Data Contracts et Test de Données dans les Pipelines de Données Modernes
Si vous avez entendu le terme « data contracts » partout, mais que vous n'avez toujours pas de voie claire du concept à la mise en œuvre, vous n'êtes pas seul. Les data contracts gagnent en popularité à mesure que les écosystèmes de données distribués s'étendent, mais le chemin de la théorie à la pratique est loin d'être simple. La plupart des équipes comprennent l'idée des data contracts, mais ont du mal à transformer des attentes partagées en quelque chose qui est réellement appliqué en production.
Aujourd'hui, l'application de la qualité est généralement mise en œuvre par le biais de vérifications dans les pipelines de données qui valident le schéma, la nullabilité et les plages de base. Les ingénieurs ajoutent ces vérifications à mesure que les données traversent les étapes d'ingestion et de transformation. Bien que utiles, ces validations opèrent localement : chaque pipeline applique ses propres règles, basées sur le contexte local et le jugement individuel. Aucun système unique n'a de visibilité sur l'ensemble des attentes placées sur un jeu de données.
Lorsque les règles de qualité sont dispersées dans les pipelines, les équipes perdent une compréhension commune de ce que signifie réellement « bonne donnée ». Les consommateurs ne peuvent pas voir facilement ce qui a été validé, les producteurs ne savent pas sur quelles garanties s'appuient les utilisateurs en aval, et les métadonnées s'éloignent rapidement de la réalité. Ce qui fonctionne pour les pipelines individuels échoue au niveau de l'organisation, où la confiance doit s'étendre aux équipes, aux domaines et aux cas d'utilisation.
Les data contracts comblent cet écart en introduisant un accord partagé et applicable entre les producteurs de données et les consommateurs de données. Au lieu de s'appuyer sur des vérifications dispersées spécifiques aux pipelines, ils fournissent un moyen structuré de rendre les attentes explicites, visibles et fiables entre équipes et systèmes.
Cet article explique ce que sont les data contracts, pourquoi ils deviennent essentiels, ce qu'ils contiennent, et comment ils transforment le flux de travail entre producteurs et consommateurs. Il se termine par une vue d'ensemble de la manière dont Soda soutient le développement piloté par les contrats pour les utilisateurs techniques et non techniques afin que le concept de data contracts puisse être traduit en application réelle.
Qu'est-ce qu'un Data Contract?
Un data contract est un accord applicable entre les producteurs et les consommateurs de données qui définit comment les données doivent être structurées, validées et gérées à mesure qu'elles traversent un pipeline.
Il agit comme une couche d'interface, définissant explicitement quelles données sont fournies, sous quelles conditions, et avec quelles garanties. Semblable à une API dans le développement logiciel.
Dans l'ingénierie logicielle, les APIs définissent la structure, les garanties et le comportement sur lesquels les systèmes en aval peuvent s'appuyer. Elles encapsulent la logique interne et exposent uniquement des interfaces intentionnelles et stables. Les data contracts appliquent le même principe à l'ingénierie des données en définissant les règles que les producteurs doivent respecter et les conditions sur lesquelles les consommateurs peuvent compter.
Dans le même temps, les data contracts transforment ces attentes en spécifications exécutables qui peuvent être vérifiées en continu par rapport aux données de production.
Le data contract devient une interface partagée que les deux parties, producteurs et consommateurs, peuvent accéder, comprendre et valider, créant une source commune de vérité et transformant les attentes en règles explicites, réutilisables et applicables.
En conséquence, le schéma, la nullabilité, la fraîcheur, les plages et les contraintes de domaine cessent d'être des directives informelles et deviennent des garanties explicites soutenues par une validation automatisée avant que les données ne se déplacent en aval.
Un data contract passe de la gouvernance des données d'une documentation descriptive à des attentes exécutables.
Un data contract n'est pas une documentation statique ponctuelle, une définition de schéma ou simplement une liste d'exigences. C'est un système d'enregistrement pour les métadonnées qui est lisible par machine, exécutable et vérifiable automatiquement. Avant tout, il est autoritaire : une interface partagée unique où les règles sont définies, convenues, versionnées et appliquées tout au long du cycle de vie des données.
En bref, un data contract sépare deux préoccupations connexes et les réunit de manière contrôlée :
En tant qu'interface pour les données, il définit ce que les producteurs promettent de livrer et ce que les consommateurs peuvent s'appuyer en termes de structure, de sémantique et d'utilisation.
En tant que spécification exécutable, il vérifie en continu des propriétés clés — telles que le schéma et les règles de qualité critiques — sur chaque nouveau lot de données.
En créant un registre pour les métadonnées et en testant ce qui est testable, les data contracts empêchent les métadonnées de s'éloigner de la réalité et créent une source fiable de la vérité qui reste en synchronisation avec les données elles-mêmes.
Pourquoi avons-nous besoin de Data Contracts?
Le défi principal dans tout écosystème de données est de livrer les bonnes données, au bon endroit, au bon moment, et avec des garanties auxquelles les consommateurs peuvent faire confiance. À mesure que les organisations se développent, les données deviennent plus distribuées entre les domaines, les équipes et les systèmes. Pourtant, la manière dont les données sont validées et publiées évolue rarement au même rythme.
En pratique, la plupart des organisations considèrent la production de données comme une préoccupation d'ingénierie interne plutôt qu'un processus de publication. De nouveaux lots de données sont mis à disposition des consommateurs sans vérifier systématiquement s'ils correspondent toujours aux attentes dont les utilisateurs en aval dépendent. Cette déconnexion crée trois problèmes systémiques.
Des attentes mal alignées entre producteurs et consommateurs, causées par l'absence d'une interface partagée et explicite pour les données.
Une validation fragmentée et incohérente, où les vérifications de qualité dépendent des pipelines individuels et des pratiques d'ingénierie plutôt que des normes appliquées.
Aucune source de vérité autoritaire, laissant les consommateurs incapables de vérifier si les données correspondent réellement à ses attentes publiées.
Attentes mal alignées entre les équipes
Les producteurs optimisent les performances opérationnelles et la rapidité de livraison, tandis que les consommateurs optimisent la continuité analytique et l'interprétabilité. Les ingénieurs de données se situent entre les deux, essayant de concilier des incitations incompatibles tout en gardant les pipelines fiables et évolutifs.
Bien souvent, les producteurs n'ont pas de visibilité sur ce dont les consommateurs dépendent, et les consommateurs n'ont aucune garantie que les changements en amont ne les feront pas échouer.
Un producteur pourrait renommer ou supprimer un champ parce que le changement fait sens dans l'application qu'ils maintiennent, ignorant que le même champ alimente des modèles de prévision, des tableaux de bord opérationnels ou des rapports de conformité.
Sans un contrat explicite et partagé, les attentes restent implicites et fragiles. La solution nécessite une interface formelle qui déclare clairement ce que les producteurs s'engagent à livrer et ce sur quoi les consommateurs peuvent se fier.
Validation fragmentée et incohérente
Lorsque les attentes ne sont pas partagées ou explicites, les changements se propagent de manière imprévisible, et les équipes découvrent les problèmes seulement après que la logique en aval a déjà échoué. Les ingénieurs peuvent ajouter des vérifications à leurs pipelines, mais que les données soient testées ou non, et dans quelle mesure, dépend du jugement individuel et des pratiques locales. En conséquence, certains jeux de données sont bien validés, tandis que d'autres sont à peine vérifiés.
D'un point de vue organisationnel, cela rend impossible de garantir un niveau minimum de qualité. Pour les consommateurs découvrant des données dans des catalogues ou des outils de découverte, il n'y a pas de moyen fiable de savoir si un jeu de données a été vérifié ou quelles garanties il offre réellement.
Par conséquent, personne ne peut voir l'ensemble des attentes, et aucun mécanisme ne garantit qu'elles sont appliquées de manière cohérente entre les jeux de données ou les environnements.
Si chaque nouveau lot de données est effectivement une publication, alors la validation ne peut pas être optionnelle. Elle doit être appliquée systématiquement avant que les données ne soient publiées aux consommateurs. Cela nécessite des flux de travail et des lignes directrices qui garantissent que le test est une condition préalable à la disponibilité des données.
Absence de source de vérité autoritaire
Même lorsqu'elles documentent les attentes, cette documentation est généralement descriptive plutôt qu'applicable. Parce qu'elle est déconnectée de l'exécution, elle devient obsolète dès que les données sous-jacentes changent. Les équipes finissent alors par s'appuyer sur des alignements informels et un débogage réactif plutôt que sur des accords explicites.
Les producteurs ne savent souvent pas quelles attentes sont réellement importantes, et les consommateurs ne peuvent pas vérifier si les données qu'ils reçoivent respectent encore ce qui a été promis. Le problème fondamental est l'absence d'une source unique, autoritaire de vérité qui reflète à la fois les attentes prévues et le comportement réel des données.
Ce qui est nécessaire, c'est un système d'enregistrement exécutable, qui reste aligné avec la réalité en validant continuellement les données par rapport aux attentes publiées.
En savoir plus sur Pourquoi les Data Contracts : 5 Raisons pour lesquelles les Leaders devraient commencer maintenant
Pour simplifier, des attentes mal alignées, une validation fragmentée et l'absence d'une source partagée de vérité pointent tous vers le même problème sous-jacent : les données sont publiées sans une interface clairement définie et appliquée. En conséquence, les changements se propagent de façon imprévisible, et les défaillances sont souvent découvertes seulement après l'échec des systèmes en aval.
Un développement piloté par contrat aborde les problèmes ci-dessus en traitant le data contract comme l'API des données, rendant ainsi visibles, examinables et testables les changements avant qu'ils n'atteignent les consommateurs.
Développement piloté par contrat
Alors, comment fonctionne réellement un data contract en pratique, et comment prévient-il les ruptures au fil du temps ?
En pratique, le développement piloté par contrat introduit un flux de travail partagé :
Les consommateurs définissent les attentes sur lesquelles ils s'appuient pour créer des rapports, des modèles et des applications.
Les producteurs mettent en œuvre et appliquent le contrat, en s'engageant à fournir des données qui répondent aux attentes des consommateurs.
Les pipelines appliquent automatiquement le contrat, en validant chaque nouveau lot de données avant qu'il ne soit disponible en aval.
La validation des contrats est intégrée dans le pipeline comme une barrière de sécurité automatisée. Chaque nouveau lot de données est traité comme une publication et vérifié par rapport au contrat publié avant de parvenir aux consommateurs. Les changements perturbateurs sont détectés tôt, les mises à jour incompatibles sont identifiées rapidement, et la confiance est maintenue entre les équipes.
Par conséquent, les data contracts génèrent :
un accord partagé et explicite entre producteurs et consommateurs.
une spécification unifiée, appliquée de manière cohérente
une spécification unique et autoritaire qui définit, versionne et applique ce que signifie la qualité
Qui détient le Data Contract ?
La propriété d'un data contract ne signifie pas la responsabilité de la mise en œuvre. Au lieu de cela, elle reflète qui définit les exigences par rapport à qui est responsable de les appliquer en production.
Effectivement, la propriété du data contract devrait appartenir aux consommateurs de données, et non aux producteurs. Parce que les producteurs optimisent pour des préoccupations opérationnelles et ne voient souvent pas l'impact analytique en aval, si les producteurs définissent seuls les attentes des contrats, les contrats tendent à refléter ce qui est facile à produire, et non ce qui est sûr à consommer.
Les consommateurs sont idéalement placés pour définir les exigences du contrat car ils comprennent l'impact analytique et commercial des échecs de qualité des données. Ils sont les seuls à savoir vraiment :
quels champs sont critiques pour l'entreprise
quelles plages de valeurs sont acceptables
quelles garanties de fraîcheur, de complétude et de fiabilité sont nécessaires
Cela ne signifie pas que les consommateurs appliquent eux-mêmes les contrats. L'application appartient au pipeline, généralement détenue par les ingénieurs de données et les producteurs. Les consommateurs fixent les attentes, les producteurs s'engagent à les respecter, et les pipelines se assurent automatiquement qu'elles sont respectées.
Que contient un Data Contract ?
En pratique, les data contracts peuvent inclure de nombreux éléments : propriété, documentation, versioning et garanties de compatibilité. Chez Soda, nous nous concentrons sur le cœur exécutable d'un data contract : les attentes de qualité qui peuvent être continuellement validées par rapport aux données de production.
La mise en œuvre des data contracts signifie aborder la qualité des données comme du code. Les équipes peuvent créer une couche de qualité reproductible, testable et appliquée en continu en définissant des attentes dans un contrat contrôlé par version et en les exécutant directement dans le pipeline.
Bien que les implémentations varient, un data contract inclut généralement les éléments de base suivants :
Informations sur le jeu de données :
Le contrat est explicitement lié à un jeu de données unique ou à un produit de données et définit où ces données résident.
Vérifications au niveau du jeu de données :
Ce sont des attentes qui s'appliquent à l'ensemble du jeu de données, telles que les seuils de comptage des lignes, la fraîcheur, l'exhaustivité ou les contraintes inter-colonnes.
Il inclut aussi généralement des garanties de schéma et de structure qui appliquent les noms des colonnes, les types de données et les champs requis.
Vérifications au niveau des colonnes :
Ces règles définissent des valeurs acceptables, des plages, des motifs ou des distributions qui s'appliquent à des colonnes spécifiques, comme les valeurs manquantes, les valeurs valides (par exemple, regex, plage), et les agrégations (par exemple, moyenne, somme).
Voir l'exemple de contrat de données au format YAML ci-dessous :
Lorsque les vérifications échouent, elles mettent en lumière des problèmes qui devraient être examinés. Lorsqu'ils sont intégrés dans des pipelines CI/CD, les contrats peuvent déclencher des notifications aux équipes responsables ou même arrêter le flux jusqu'à ce que le problème soit trouvé et résolu.
Il n'y aura plus de garanties partielles enfouies dans les transformations, de documentation déconnectée ou de conjectures sur ce que signifie "bonnes données". Le pipeline respecte soit le contrat, soit il ne le respecte pas, et lorsqu'il ne le respecte pas, les échecs sont documentés avec des origines claires et un contexte exploitable.
En commençant par les jeux de données les plus importants, les équipes peuvent progressivement étendre l'utilisation d'approches collaboratives où les parties prenantes proposent des vérifications, décident des seuils et définissent ensemble les normes de qualité des données.
Soda Collaborative Data Contracts
Un data contract est plus qu'un ensemble de vérifications de qualité, mais sa valeur ne se matérialise que lorsque les attentes sont exécutables. Soda se concentre sur cette couche exécutable.
Collaborative Data Contracts sont similaires aux tests unitaires pour le test de logiciel, entièrement exécutables et applicables. Ils prennent en charge le versionnage, l'intégration CI et l'évolution coordonnée entre les producteurs et les consommateurs.
Aussi, afin de combler le fossé entre les utilisateurs techniques et commerciaux, les contrats Soda peuvent être rédigés, versionnés, vérifiés et surveillés de trois manières complémentaires afin qu'ils ne perturbent pas le flux de travail de votre équipe :
Data Contracts en tant que code
Git-Managed Contracts offre une manière orientée code de définir et d'appliquer les attentes de qualité des données. En utilisant Soda Core (le moteur open-source de Soda) et le Soda CLI, vous pouvez :
Définir des contrats en YAML + Soda Contracts Language.
Effectuer des vérifications de contrats dans CI/CD.
Envoyer les résultats des vérifications dans Soda Cloud pour la visibilité.
Utiliser Git comme source de vérité pour le contrôle de version, la collaboration et l'examen.
Nous fournissons un exemple d'implémentation technique en utilisant Soda Core dans notre blog précédent, Mise en œuvre des Data Contracts à grande échelle.
Data Contracts sans code
Cloud-Managed Contracts vous permettent de définir et de gérer des attentes de données directement dans l'interface Soda Cloud. Cette approche est idéale pour les analystes de données, les chefs de produit, et les parties prenantes qui préfèrent des interfaces intuitives au code. Sans nécessité de configuration ou de code, l'interface vous permet :
Proposer ou ajouter des règles de qualité avec un éditeur sans code
Publier des contrats d'un clic
Planifier ou exécuter des vérifications de contrats à la demande
Collaborer avec votre équipe et demander des modifications
Tous les résultats des vérifications seront stockés et visualisés dans Soda Cloud. En cas d'échec de vérification d'un contrat, des notifications peuvent être envoyées, ou les nouvelles données peuvent être empêchées de être publiées à des utilisateurs.
Data Contract Copilot
Contract Copilot est une fonctionnalité assistée par AI à l'intérieur de Soda Cloud.
Lorsque vous cliquez pour créer un contrat, le Copilot peut aider en analysant la structure du schéma, et à partir de là, vous pouvez ajouter toutes les vérifications pertinentes.
Demandez en anglais simple et laissez le Contract Copilot générer des vérifications de qualité pour vous. Cela pourrait être aussi simple que d'ajouter des vérifications pour les valeurs manquantes à toutes les colonnes ou de créer des requêtes SQL plus complexes.
Exemple de requête : définir une vérification de qualité qui vérifie si la valeur de la TVA correspond à 21% du prix, en permettant une tolérance jusqu'à un cent.
L'avantage principal est que les utilisateurs non techniques n'ont besoin d'aucune compétence de codage ou de passer par de nombreux clics pour proposer des modifications au contrat.
Cette approche hybride permet la collaboration entre les équipes où les utilisateurs du secteur apportent leur expertise dans le contrat, tandis que les ingénieurs assurent la précision, la cohérence et la gouvernance.
Avec YAML, Soda UI ou Copilot, en quelques minutes, vous pouvez créer des vérifications qui garantissent :
L'intégrité du schéma
L'exactitude, la complétude et la cohérence des données
Fraîcheur, disponibilité et latence
L'absence de violations de logique commerciale
Bonnes pratiques pour des Data Contracts efficaces
Un data contract répond à la lutte que la gouvernance des données a longtemps menée pour amener les normes et la documentation des données du "papier" au code. Il ne définit pas seulement ce que devraient ressembler les données, mais vérifie également systématiquement les spécifications ajoutées afin que les équipes concernées puissent être alertées lorsqu'une condition échoue.
L'intégration de ces pratiques dans le flux de travail de l'ingénierie des données conduit à améliorer l'écosystème des données, résultant en des données riches en contexte, bien gouvernées et de confiance. Cependant, la mise en œuvre des data contracts ne devrait pas nécessiter (pas obligatoirement) (vous?) une réorganisation complète de votre architecture de données. Vous pouvez commencer petit, démontrer la valeur, puis étendre progressivement.
Commencez avec des données critiques
Mettre chaque jeu de données sous contrat est impraticable. Commencez par les tableaux de bord critiques pour l'entreprise et les entrées ML qui nécessitent de la cohérence, afin que l'effort soit dirigé là où il est le plus efficace. Ensuite, étendez la couverture en fonction des points faibles et de la valeur ajoutée.
Favorisez la collaboration interéquipes
Les contrats réussissent lorsque les producteurs comprennent la valeur et que les consommateurs expriment leurs besoins. Les deux parties devraient travailler ensemble pour définir le data contract.
Formalisez la communication
Traitez les changements de contrat comme des événements de premier ordre. Utilisez des tickets, des journaux de modifications ou des demandes de tirage pour documenter les mises à jour. Une bonne communication réduit les surprises et augmente la confiance de l'équipe.
Définissez clairement la propriété
Assurez-vous que lorsque les choses se cassent, quelqu'un est averti et peut approuver les changements.
Automatisez l'application
Automatisez les vérifications du pipeline CI et configurez des alertes de violation.
Versionnez délibérément les contrats
Contrôlez les mises à jour de contrat, y compris les nouvelles versions et les vérifications de compatibilité rétroactive.
Surveillez au fil du temps
Configurez une surveillance des contrats clés pour détecter les anomalies ou les dérives au fil du temps.
Que ce soit pour vérifier les comptages de lignes, les valeurs manquantes ou invalides, ou l'intégrité du schéma, l'objectif est de détecter les problèmes tôt, de réduire les incidents et de rassurer les consommateurs de données. En introduisant des règles de validation et en clarifiant les attentes, les data contracts améliorent la transparence et rendent l'écosystème de données intrinsèquement plus robuste.
Foire aux Questions
Les Data Contracts de Soda sont-ils compatibles avec l'ODCS (Open Data Contract Standard) ?
Oui, nous supportons l'OCDS. OCDS est une couche de documentation d'un data contract. Soda est une couche d'exécution. Vous pouvez écrire votre data contract en syntaxe OCDS, et Soda l'exécutera en le traduisant en Soda Contract Language. C'est ainsi que nous rendons l'OCDS applicable dans les pipelines de données réels.
Pourquoi YAML est-il le langage de Soda pour les Data Contracts?
YAML est un format compatible avec tout contrôle de version basé sur Git, permettant le versionnage, les demandes de tirage et l'intégration dans un flux de travail d'ingénierie. De plus, il offre une lisibilité et ne nécessite aucune connaissance en codage, permettant à toutes les personnes (analystes, experts de domaine, utilisateurs commerciaux) de lire et de comprendre le contrat.
Les data contracts sont-ils un processus ou un changement technique ?
Les deux. Techniquement, ils introduisent des spécifications exécutables, une validation automatisée et l'application de contrats dans les pipelines. Au niveau organisationnel, ils formalisent la collaboration entre producteurs et consommateurs en rendant les attentes explicites, versionnées, et révisables.
Les data contracts remplacent-ils les outils d'observabilité des données ?
Non. Les data contracts et l'observabilité des données résolvent des problèmes différents et complémentaires.
Les data contracts sont des mesures préventives qui définissent et appliquent des attentes connues (schéma, contraintes, fraîcheur et règles, commerciales) avant la consommation des données.
L'observabilité des données est une technique de détection qui surveille les jeux de données en production pour identifier des problèmes inconnus tels que les dérives, les anomalies ou les changements de distribution inattendus.
Que se passe-t-il lorsque une vérification de contrat échoue en production ?
Lorsque une vérification de contrat échoue, le résultat dépend de la configuration du pipeline.
Les actions courantes incluent : rediriger les enregistrements échoués vers une table de quarantaine ou d'erreurs; déclencher des alertes pour enquête sans arrêter le pipeline; empêcher la propagation de données invalides vers les systèmes en aval; ou faire échouer le pipeline entièrement pour des violations critiques.
Comment les data contracts s'intègrent-ils aux pipelines CI/CD?
Les définitions de contrat sont stockées sous forme de code (par exemple, en YAML) et versionnées dans Git. Lors des exécutions CI/CD, les vérifications de contrat s'exécutent en tant qu'étapes d'ingestion, de transformation ou de déploiement.
Pour voir comment les Data Contracts de Soda peuvent être validés automatiquement lors de l'exécution du pipeline, regardez la vidéo tuto ci-dessous.
Data Contracts de Soda en action
Nous avons récemment organisé un webinaire sur la mise en œuvre des Data Contracts. Regardez la vidéo : Data Contracts et Test de Données dans les Pipelines de Données Modernes
Trusted by the world’s leading enterprises
Real stories from companies using Soda to keep their data reliable, accurate, and ready for action.
At the end of the day, we don’t want to be in there managing the checks, updating the checks, adding the checks. We just want to go and observe what’s happening, and that’s what Soda is enabling right now.
Sid Srivastava
Director of Data Governance, Quality and MLOps
Investing in data quality is key for cross-functional teams to make accurate, complete decisions with fewer risks and greater returns, using initiatives such as product thinking, data governance, and self-service platforms.
Mario Konschake
Director of Product-Data Platform
Soda has integrated seamlessly into our technology stack and given us the confidence to find, analyze, implement, and resolve data issues through a simple self-serve capability.
Sutaraj Dutta
Data Engineering Manager
Our goal was to deliver high-quality datasets in near real-time, ensuring dashboards reflect live data as it flows in. But beyond solving technical challenges, we wanted to spark a cultural shift - empowering the entire organization to make decisions grounded in accurate, timely data.
Gu Xie
Head of Data Engineering
4,4 sur 5
Commencez à faire confiance à vos données. Aujourd'hui.
Trouvez, comprenez et corrigez tout problème de qualité des données en quelques secondes.
Du niveau de la table au niveau des enregistrements.
Adopté par
Trusted by the world’s leading enterprises
Real stories from companies using Soda to keep their data reliable, accurate, and ready for action.
At the end of the day, we don’t want to be in there managing the checks, updating the checks, adding the checks. We just want to go and observe what’s happening, and that’s what Soda is enabling right now.
Sid Srivastava
Director of Data Governance, Quality and MLOps
Investing in data quality is key for cross-functional teams to make accurate, complete decisions with fewer risks and greater returns, using initiatives such as product thinking, data governance, and self-service platforms.
Mario Konschake
Director of Product-Data Platform
Soda has integrated seamlessly into our technology stack and given us the confidence to find, analyze, implement, and resolve data issues through a simple self-serve capability.
Sutaraj Dutta
Data Engineering Manager
Our goal was to deliver high-quality datasets in near real-time, ensuring dashboards reflect live data as it flows in. But beyond solving technical challenges, we wanted to spark a cultural shift - empowering the entire organization to make decisions grounded in accurate, timely data.
Gu Xie
Head of Data Engineering
4,4 sur 5
Commencez à faire confiance à vos données. Aujourd'hui.
Trouvez, comprenez et corrigez tout problème de qualité des données en quelques secondes.
Du niveau de la table au niveau des enregistrements.
Adopté par
Solutions
Trusted by the world’s leading enterprises
Real stories from companies using Soda to keep their data reliable, accurate, and ready for action.
At the end of the day, we don’t want to be in there managing the checks, updating the checks, adding the checks. We just want to go and observe what’s happening, and that’s what Soda is enabling right now.
Sid Srivastava
Director of Data Governance, Quality and MLOps
Investing in data quality is key for cross-functional teams to make accurate, complete decisions with fewer risks and greater returns, using initiatives such as product thinking, data governance, and self-service platforms.
Mario Konschake
Director of Product-Data Platform
Soda has integrated seamlessly into our technology stack and given us the confidence to find, analyze, implement, and resolve data issues through a simple self-serve capability.
Sutaraj Dutta
Data Engineering Manager
Our goal was to deliver high-quality datasets in near real-time, ensuring dashboards reflect live data as it flows in. But beyond solving technical challenges, we wanted to spark a cultural shift - empowering the entire organization to make decisions grounded in accurate, timely data.
Gu Xie
Head of Data Engineering
4,4 sur 5
Commencez à faire confiance à vos données. Aujourd'hui.
Trouvez, comprenez et corrigez tout problème de qualité des données en quelques secondes.
Du niveau de la table au niveau des enregistrements.
Adopté par
Solutions