Data Contracts #1 : Découvrez le standard ouvert ODCS

#

Si vous travaillez avec des données en entreprise, vous avez probablement déjà vécu ce scénario :

Un tableau de bord critique affiche soudainement des chiffres absurdes. Après deux heures d’investigation, l’équipe data découvre la cause : l’équipe application a renommé le champ statut_commande en etat_commande lors de la dernière mise à jour du site e-commerce.

Personne n’a été prévenu. Le pipeline a cassé.

Dans le monde du logiciel, on n’imagine pas deux systèmes communiquer sans un contrat d’interface (une API). Pourquoi continue-t-on à le faire avec la data ?

C’est là qu’interviennent les Data Contracts (contrats de données). Et pour éviter que chacun ne réinvente la roue dans son coin, un standard ouvert a émergé : ODCS (Open Data Contract Standard).

Le concept : traiter la donnée comme un produit

#

Un Data Contract est un document simple et déclaratif (au format YAML) qui décrit formellement la promesse d’un jeu de données.

Il répond à 4 piliers essentiels :

• Sémantique & Schéma : Quelles sont les colonnes, leurs types (texte, nombre, date) et ce qu’elles représentent métier.
• Qualité (SLO) : Les règles strictes à respecter (absence de doublons, pas de valeurs NULL sur les identifiants).
• Service (SLA) : Les engagements de fraîcheur (ex: la donnée arrive avec max 30 min de retard).
• Gouvernance : Qui est le propriétaire (owner) de la donnée et quel canal contacter en cas d’anomalie.

L’idée clé : le contrat est commité dans Git, versionné et testé. Le producteur s’engage sur ce contrat, et les consommateurs s’y réfèrent en toute confiance.

Pourquoi un standard comme ODCS ?

#

Jusqu’ici, chaque entreprise créait son propre format de contrat dans un coin. Le problème ? Un format propriétaire empêche les outils de communiquer entre eux.

Porté par l’initiative Bitol (désormais hébergée par la Linux Foundation), l’Open Data Contract Standard (ODCS) vise à devenir le « OpenAPI » du monde de la donnée :

• Un langage universel en YAML : lisible immédiatement par un humain et interprétable par un ordinateur.
• Platform-agnostic : indépendant de tout éditeur ou cloud provider.
• Axé sur l’automatisation : pensé pour s’intégrer nativement dans votre écosystème d’outils data (CI/CD, catalogues, moteurs de test).

À vous de jouer : Décodez votre premier contrat ODCS

#

Pas besoin d’être développeur. Lisez cet extrait YAML simplifié d’un contrat ODCS décrivant une table de commandes e-commerce :

apiVersion: v3.1.0
kind: DataContract

id: orders-contract-v1
name: orders
version: 1.0.0
status: active
domain: ecommerce

# 1. Gouvernance & Propriété
team:
  name: Equipe Checkout
  description: Propriétaire des données de vente
  members:
    - username: dev-checkout@entreprise.com
      role: Owner

# 2. Schéma & Sémantique
schema:
  - name: orders
    logicalType: object
    properties:
      - name: order_id
        logicalType: string
        required: true
        unique: true
        description: Identifiant unique de la commande (UUID)

      - name: amount
        logicalType: number
        required: true
        description: Montant total TTC en euros

      - name: created_at
        logicalType: timestamp
        required: true
        description: Horodatage de validation de la commande

# 3. Engagements de Qualité & SLA
slaProperties:
  - property: latency
    value: 30
    unit: min
    description: La donnée doit être disponible au plus 30 min après la vente

Ce que ce fichier apporte concrètement :

#

• Transparence : Le métier sait exactement ce que contient amount (un montant TTC en euros).
• Collaboration : Les évolutions du contrat se discutent sereinement dans Git via des Pull Requests.
• Sécurité automatisée : Un script peut lire ce fichier pour valider la structure des données et bloquer l’ingestion en cas d’écart.

Les limites : soyons honnêtes

#

Un contrat de données reste un outil, pas une baguette magique :

• La culture avant tout : Si l’équipe de développement ne se sent pas responsable de la qualité des données qu’elle produit, le fichier YAML deviendra un cimetière de bonnes intentions.
• Pas de miracle sur la source : Le contrat ne corrige pas une valeur saisie à l’envers dans l’application, mais il permet de détecter l’erreur immédiatement à l’entrée du pipeline.
• Un écosystème jeune : Bien que l’adoption d’ODCS accélère rapidement, l’outillage autour du standard continue de mûrir.

En résumé

#

L’Open Data Contract Standard (ODCS) apporte aux données ce que le développement logiciel utilise depuis des années : des règles claires, explicites, versionnées dans Git et vérifiables par des outils automatisés.