Modèles de propriété des contrats de données

La première question lors de l’implémentation des contrats de données est la propriété : qui définit le contrat ? La réponse détermine si le contrat crée une responsabilité réelle ou devient une documentation de référence que personne ne maintient.

Trois modèles existent. Chacun porte des hypothèses organisationnelles différentes.

Contrats définis par le producteur

Dans ce modèle, le propriétaire des données — généralement l’équipe de génie logiciel qui construit et maintient le système source — fixe les termes. Le producteur décide quels champs existent, quels types il utilise, quelles garanties il est prêt à offrir et quel est son SLA.

C’était le cadrage original d’Andrew Jones chez GoCardless. Le producteur s’engage sur un schéma et un ensemble de garanties, et les consommateurs construisent contre cet engagement. Les changements du contrat passent par un processus de versionnement, et les changements cassants nécessitent une coordination explicite.

Points forts :

Le producteur comprend la provenance et les limites des données mieux que quiconque
Les garanties sont réalistes parce que l’équipe qui les formule contrôle le système
S’aligne avec le fonctionnement des contrats d’API en génie logiciel (le serveur définit l’interface)

Points faibles :

Les producteurs ne savent pas comment leurs données sont utilisées en aval — ils peuvent s’engager sur les mauvaises choses
Sans l’apport des consommateurs, les contrats peuvent garantir des champs dont personne ne se soucie tout en omettant des champs critiques
Les producteurs ont peu d’incitation à maintenir des contrats pour des données qu’ils considèrent comme un sous-produit de leur service

Le problème d’incitation est réel. Un ingénieur logiciel qui construit un service de paiements se soucie du traitement correct des paiements. Le fait que ses tables de base de données soient extraites chaque nuit pour des dashboards analytiques est, de son point de vue, le problème de quelqu’un d’autre. Sans pression organisationnelle, les contrats définis par le producteur ont tendance à être minimaux et génériques.

Contrats définis par le consommateur

La position évoluée de Chad Sanderson, développée à partir de son expérience chez Convoy, inverse le modèle : les consommateurs articulent leurs exigences, et les producteurs s’engagent à les satisfaire. Le raisonnement de Sanderson : « un développeur d’application ne comprendra jamais de façon exhaustive comment les données sont utilisées en aval ».

Dans ce modèle, l’équipe d’analytics engineering (ou tout consommateur en aval) enregistre un contrat contre les données d’un producteur. Le contrat spécifie : « Je dépends de ces champs, avec ces types, à cette fraîcheur, et j’ai besoin d’être notifié avant tout changement cassant. » Le producteur examine le contrat et accepte l’engagement ou négocie des ajustements.

Points forts :

Les contrats reflètent les besoins réels en aval plutôt que les suppositions du producteur
Crée de la visibilité — les producteurs apprennent qui dépend de leurs données et comment
Les exigences des consommateurs sont concrètes et testables
Alignement naturel avec le fonctionnement des produits de données du data mesh

Points faibles :

Les consommateurs peuvent demander des garanties que le producteur ne peut pas fournir de façon réaliste
Plusieurs consommateurs peuvent avoir des exigences contradictoires pour le même dataset
Nécessite un processus de négociation et de résolution des conflits

L’insight le plus révélateur de Sanderson sur Convoy : le retour numéro un des ingénieurs logiciels était « je ne savais pas que quelqu’un utilisait mes données de cette façon ». La visibilité créée par les contrats définis par les consommateurs avait de la valeur en elle-même, indépendamment de tout mécanisme d’enforcement. Quand un consommateur enregistre un contrat contre vos données, vous apprenez quelque chose sur votre propre système que vous ne saviez pas auparavant.

Contrats collaboratifs

La plupart des implémentations pratiques atterrissent quelque part entre pur producteur-défini et pur consommateur-défini. Les consommateurs articulent ce dont ils ont besoin. Les producteurs évaluent ce qu’ils peuvent livrer. Le contrat émerge de la négociation.

Ce modèle ressemble à :

Le consommateur enregistre son intérêt. L’équipe analytics dit : « Nous avons besoin que l’événement payments inclue amount, currency, customer_id et payment_method, mis à jour dans les 4 heures, avec moins de 1% de taux de null sur les champs obligatoires. »
Le producteur examine. L’équipe de paiements répond : « Nous pouvons garantir que amount et currency sont toujours présents. customer_id est renseigné pour 98% des événements — les 2% restants sont des achats invités. payment_method est déprécié dans la v3 de notre API au profit d’un objet payment_details plus détaillé. Nous pouvons nous engager sur un SLA de 6 heures, pas 4. »
Négociation. Le contrat est ajusté. Peut-être que l’équipe analytics accepte 98% de complétude sur customer_id et ajoute une vérification de qualité pour les 2% restants. Peut-être que l’équipe de paiements priorise l’amélioration du SLA. L’essentiel est que la conversation a lieu avant que le pipeline se casse, pas après.
Codification. Les termes convenus deviennent un contrat ODCS en contrôle de version, avec enforcement CI/CD.

# Le contrat qui émerge de la collaboration
schema:
  - name: customer_id
    isNullable: true  # Taux d'achats invités de 2% reconnu
    description: "ID client. Null pour les achats invités (~2% des événements)."
quality:
  - name: customer_id_completeness
    rule: "COUNT(CASE WHEN customer_id IS NULL THEN 1 END) / COUNT(*) < 0.05"
    severity: warning
slaProperties:
  - property: latency
    value: "6h"

Patterns d’architecture organisationnelle

La façon dont les contrats sont stockés et enforced varie selon la stack. Trois patterns issus d’implémentations réelles :

GoCardless stocke les contrats sous forme de fichiers Jsonnet dans Git, avec déploiement automatisé vers BigQuery et PubSub. C’est une architecture centrée sur le producteur où l’équipe qui possède le service possède aussi la définition du contrat. Les changements de contrat passent par le même processus de revue de code que les changements de service.

Convoy utilisait Protobuf avec Kafka Schema Registry et Debezium. Cette architecture intègre les contrats dans la couche de streaming d’événements. Les changements de schéma sont validés au moment de la publication — si un producteur essaie d’émettre un événement qui ne correspond pas au schéma enregistré, la publication échoue. C’est protecteur pour les consommateurs : cela empêche les changements cassants d’atteindre les systèmes en aval.

PayPal utilisait des contrats basés sur YAML intégrés dans leur implémentation Data Mesh. Les contrats faisaient partie de la définition du produit de données, aux côtés des métadonnées de propriété et des SLA de qualité. C’est le modèle le plus complet : chaque produit de données a un contrat complet qui couvre la structure, la qualité, la livraison et la gouvernance.

Il n’existe pas d’architecture unique correcte. Le pattern dépend du fait que vos données circulent via des flux d’événements (Kafka + Schema Registry est naturel), des extractions batch (contrats basés sur Git avec validation CI), ou les deux (vous aurez probablement besoin de contrats à plusieurs points d’enforcement).

L’argument de la visibilité

Quel que soit le modèle de propriété choisi, la valeur la plus immédiate des contrats de données est souvent non pas l’enforcement mais la visibilité.

Avant les contrats, le graphe de dépendances entre les producteurs et les consommateurs est invisible. L’équipe de paiements ne sait pas que l’équipe analytics dépend d’une colonne spécifique. L’équipe analytics ne sait pas qu’une dépréciation est prévue. Personne n’a une vue complète.

Les contrats rendent ces dépendances explicites et lisibles par machine. Même avant d’ajouter l’enforcement automatisé, le fait d’écrire « je dépends de X de l’équipe Y » crée de la valeur organisationnelle. Cela permet l’analyse d’impact avant les changements. Cela route les alertes de qualité des données vers les bonnes personnes. Cela transforme les suppositions implicites en accords explicites.

Le défi culturel est d’amener les équipes à investir dans cette visibilité. L’étude de cas Convoy suggère que le retour sur investissement est rapide : une fois que les ingénieurs voient qui dépend de leurs données, leur intérêt à maintenir la qualité des données augmente. Les contrats rendent les dépendances visibles aux producteurs tout en protégeant les consommateurs.