Les 4 principes du data ownership

Le data ownership est probablement le grand problème non résolu de la gestion des données. Résolvons-le.

Seules les données dont quelqu'un se sent responsable sont des données sur lesquelles nous pouvons construire nos processus et nos décisions métier. Ce quelqu'un nettoie les incohérences et veille à ce que les données soient complètes. Ce quelqu'un s'assure que tous les pipelines sont au vert. Ce quelqu'un soigne la documentation. Ce quelqu'un est une personne à qui vous pouvez parler quand vous avez des questions. Et ce quelqu'un récolte le mérite de la valeur que les autres créent avec ses données.

Êtes-vous ce quelqu'un ?

Félicitations. Vous faites un excellent travail. Mais soyons honnêtes : il y a tellement plus de données dans votre organisation où ce quelqu'un manque, ou dont vous ne savez pas s'il existe.

Bien sûr, tout est une question d'ownership. L'ownership des données est difficile. Mais heureusement, il existe aujourd'hui des méthodes et des outils qui peuvent aider.

Les 4 principes du data ownership

Voici quelques principes que nous avons trouvés utiles pour aborder le data ownership :

OK, voyons ce que nous entendons par là :

You build it, you own it

Quand des données entrent dans votre domaine, vous en devenez l'owner. Vous définissez les champs des formulaires, vous construisez les API, vous contrôlez le pipeline entrant. Vous savez ce que signifie un enum de statut. Vous connaissez la signification des six colonnes de timestamp différentes. Vous savez ce qui se passe dans les cas d'erreur et les cas limites. Vous construisez le système, ce sont donc vos données. C'est votre travail de le savoir. Vous êtes le data owner. Pas d'excuses.

Nous recommandons généralement un ownership d'équipe plutôt que des personnes individuelles. Cela évite les difficultés quand quelqu'un est en congé ou quand la composition de l'équipe change. Dans certaines organisations, on observe une séparation entre équipes IT et équipes métier. Nous recommandons alors que l'équipe qui travaille le plus avec les données prenne le rôle d'owner principal : pour les produits de données source-aligned, c'est souvent l'équipe IT ; pour les produits de données consumer-aligned, c'est souvent l'équipe métier ou une équipe proxy.

Publiez des produits de données

Nous avons tous déjà regardé dans les catalogues de données d'entreprise (Collibra, Informatica, DataHub, etc.), et après avoir vu le nombre de data assets indexés automatiquement (par exemple 2 321 021 tables et fichiers) et les détails très techniques (sérialisation, formats de fichiers, encodages), une chose devient très claire : ces assets crawlés automatiquement n'aident pas à prendre l'ownership. Trop techniques et trop nombreux.

Introduisons donc les produits de données. S'il est difficile de trouver une définition générique d'un produit de données (est-ce une table, un schéma, un modèle sémantique Power BI, un topic Kafka, une API, un projet dbt, ...), concentrons-nous sur la valeur : des données que quelqu'un veut utiliser. Ce quelqu'un peut être vous ou votre équipe. Ce peut être une autre unité métier. Et ce peut être un agent IA.

Le point important à propos des produits de données : des données ne deviennent un produit de données que si quelqu'un prend le rôle d'owner pour ces données. Il n'y a pas de produit de données sans owner. Point.

Cela signifie aussi : dans les entreprises, il n'y a pas des millions de produits de données. Typiquement, il n'y en a que quelques centaines. Moins, c'est mieux : nous obtenons un nombre gérable d'objets que les owners peuvent maintenir et organiser.

Pour que les produits de données soient trouvables par les autres, l'owner les publie activement dans une marketplace de données organisée, pas dans un catalogue technique de data assets.

Appliquez les Data Contracts

Parlons maintenant des Data Contracts. Les Data Contracts spécifient ce qu'un Data Consumer (là encore, une personne ou un agent) peut attendre de la consommation des données. Ils sont les API du produit de données.

C'est-à-dire :

• Conditions d'utilisation
• Schéma
• Sémantique
• Qualité des données
• SLA
• Endpoints

Les conditions d'utilisation comprennent la description métier, la finalité des données, l'usage acceptable et les limitations d'un point de vue technique, conformité et Data Governance. Avec les cas d'usage agentiques, c'est extrêmement utile pour indiquer aux agents IA quels produits de données ils peuvent utiliser pour quelles tâches, et dans quels contextes ces données sont pertinentes.

Le schéma comprend la structure des tables et des colonnes, ainsi que des détails logiques et de gouvernance, comme les classifications de données, les marqueurs PII, les descriptions sémantiques, les données d'exemple et le data lineage.

Les tables et les colonnes peuvent aussi être liées à un modèle de données métier conceptuel ou à des standards sectoriels pour ajouter des informations sémantiques, formant un véritable graphe de connaissances pour trouver des données liées (là encore, très utile pour les cas d'usage agentiques).

Les règles de qualité des données et les SLA définissent des garanties sur les données et des attentes métier, comme des exigences de non-nullité, des règles au niveau des lignes, des plages de valeurs valides, la fraîcheur, etc. Des moteurs de qualité peuvent lire ces règles, se connecter aux endpoints des bases de données et valider les données. L'outil open source Data Contract CLI est un tel moteur de qualité des données.

Il existe un standard sectoriel : l'Open Data Contract Standard (ODCS), géré par Bitol, un projet Linux Foundation AI & Data. ODCS définit un format YAML pour les Data Contracts. En voici un exemple compact :

apiVersion: v3.1.0
kind: DataContract
id: orders
name: Orders
version: 1.0.0
status: active
description:
  purpose: Order data for analytics, reporting, and AI use cases.
  usage: Analyze order volumes and revenue, build dashboards, train forecasting models.
  limitations: Not suitable for real-time use cases. Contains PII, do not use for marketing without consent.
schema:
  - name: orders
    physicalType: TABLE
    description: One row per order. Includes successful and cancelled orders.
    properties:
      - name: order_id
        logicalType: string
        description: Internal order ID. Do not show this to a customer.
        primaryKey: true
        required: true
        unique: true
        examples:
          - 99e8bb10-3785-4634-9664-8dc79eb69d43
      - name: order_timestamp
        logicalType: timestamp
        description: The time when the order payment was successfully confirmed.
        required: true
      - name: order_total
        logicalType: integer
        description: The order total amount in cents, including tax, after discounts.
        required: true
        quality:
          - type: library
            metric: nullValues
            mustBe: 0
    quality:
      - type: library
        metric: rowCount
        mustBeGreaterThan: 100000
        description: If there are less than 100k rows, something is wrong.
slaProperties:
  - property: freshness
    value: "24"
    unit: hours
    description: New orders are available within 24 hours.
team:
  name: sales
  description: This data product is owned by the "Sales" team
servers:
  - server: production
    type: snowflake
    account: my-account
    database: sales
    schema: dp_orders_v1

Un Data Contract peut être défini pour un jeu de données existant. Ou il peut être écrit contract-first, pour définir les exigences d'un nouveau produit de données avant même que des données existent. Très puissant. Mais les deux approches conviennent.

Alors, qui est responsable du Data Contract ? Typiquement, le Data Product Owner possède le Data Contract de son produit de données. Mais la spécification du contrat peut être un effort collaboratif : organisez un atelier avec vos Data Consumers et discutez de leurs attentes sur les données, champ par champ. Et notez ce dont les experts du domaine discutent : c'est la sémantique que vous voulez capturer.

Soyez votre premier client

OK, nous savons maintenant comment spécifier des produits de données avec des Data Contracts. Mais la question centrale reste ouverte : pourquoi quelqu'un prendrait-il le rôle d'owner d'un produit de données ?

Eh bien, une réponse est : parce que votre chef vous le demande. Et c'est de bonne guerre. Le soutien et l'attention du management sont une partie importante du processus d'adoption.

Mais parlons aussi de motivation intrinsèque : la finalité. Quelle finalité votre produit de données pourrait-il avoir pour vous ? Oui. Construisez le premier produit de données pour votre propre équipe, avec vos propres données de domaine et un beau tableau de bord. Pour prendre de meilleures décisions et construire de belles fonctionnalités IA dans votre domaine. Connectez Claude à votre produit de données pour dialoguer avec vos données. Construisez une boucle agentique avec vos données pour recevoir un message Slack quand quelque chose d'important se passe dans votre application.

Vous voyez l'idée. Construisez un produit de données pour vous-même afin de générer de la valeur. C'est une excellente finalité ! Itérez jusqu'à en être satisfait. Quand vous en êtes fier, publiez-le dans la marketplace de données pour les autres. Récoltez la reconnaissance. Votre produit de données crée de la valeur pour votre métier. Aider les autres est aussi une excellente finalité.

Les outils qui aident

Quelques outils vous aident à prendre l'ownership.

D'abord, pour spécifier le produit de données, deux outils sont intéressants :

ODCS Excel Template. Oui, utilisez Excel pour rédiger un brouillon de Data Contract. C'est probablement l'outil avec la meilleure expérience utilisateur pour les utilisateurs métier. Envoyez-le par e-mail et itérez. Quand vous êtes satisfait, utilisez le convertisseur de la Data Contract CLI pour convertir vers et depuis YAML.

Data Contract Editor. Si vous préférez un éditeur web, utilisez le Data Contract Editor open source, qui apporte aussi un éditeur visuel de diagrammes entité-association, des champs de formulaire pour toutes les propriétés ODCS et du linting. Entièrement personnalisable avec des propriétés et des sections spécifiques.

Data Product Builder. Pour implémenter le produit de données, utilisez des coding agents comme Claude Code et OpenAI Codex. Le Data Contract leur dit quoi construire. Des skills décrivent comment, selon la stack technique et les règles de Data Governance de votre organisation. Une marketplace de données leur dit quels produits de données amont utiliser. Une fois le Data Contract prêt, implémenter un produit de données conforme ne prend que quelques minutes.

Data Contract CLI. Pour tester que le produit de données implémenté respecte la spécification et les promesses du Data Contract, utilisez l'outil open source Data Contract CLI. Intégrez-le dans Airflow, GitHub Actions, Databricks Jobs, etc. pour vérifier que votre produit de données livre toujours la qualité de données promise.

Entropy Data. Notre outil commercial qui réunit tous ces outils pour aider les Data Product Owners à prendre leur rôle d'owner au sérieux. Entropy Data fournit aussi une marketplace de données neutre vis-à-vis des fournisseurs, dans une application web simple à utiliser.

Commencez gratuitement, ou explorez la démo interactive.