← Retour au blog

Penser la donnée comme un produit

Lucian BLETAN

Arrêtons de traiter la donnée comme un sous-produit chaotique des applications. La penser comme un produit change radicalement la donne. Dans cette approche, inspirée du data mesh, chaque équipe métier (domaine) devient propriétaire de ses données. Elle les publie sous forme de produits de données : des assets fiables, documentés, faciles à trouver et à utiliser. L’objectif n’est plus de tout centraliser, mais de responsabiliser les équipes pour qu’elles fournissent aux autres des données de qualité, avec un contrat clair et un cycle de vie maîtrisé.

Produit de données

Domaine métier

Publie & maintient

Gouverné par

Sert

Équipe propriétaire

Dataset fiable & versionné (ex: cpa_daily_v)

Contrat de données (schéma, qualité, SLA)

Consommateurs (BI, ventes, produit)

prérequis

  • Cartographie des domaines: Avoir identifié les grands domaines fonctionnels de l’entreprise (ventes, marketing, etc.) et nommé un propriétaire pour chacun.
  • Stack data moderne: Disposer d’un entrepôt de données (warehouse/lakehouse) qui supporte la CI/CD pour automatiser les tests et les déploiements.
  • Gestion des accès: Avoir un système de contrôle d’accès basé sur des rôles (RBAC) pour gérer qui peut voir et utiliser quoi.

idées clefs

  • Propriété décentralisée: Chaque domaine est responsable de ses produits de données, de la source à la publication. Fini le “syndrome du ticket” à une équipe data centrale.
  • Contrat de données public: Chaque produit de données est accompagné d’un contrat qui définit son schéma, sa fraîcheur, ses garanties de qualité et ses règles d’accès. C’est son API.
  • Standards globaux, implémentation locale: Une équipe centrale définit les règles du jeu (comment nommer, gérer les dates, les unités) mais chaque domaine les implémente pour ses propres produits.
  • Observabilité intégrée: Chaque produit de données doit exposer des métriques simples sur sa santé : fraîcheur, volume, anomalies.
  • Pilotage par l’usage: Les décisions d’évolution ou de dépréciation d’un produit de données sont basées sur son utilisation réelle par les consommateurs.

pas à pas

étape 1: découper en domaines et nommer les owners

La première étape est organisationnelle. Le découpage doit suivre la logique métier de l’entreprise, pas la structure des bases de données techniques.

- **Domaine Ventes** (Owner: Alice)
  - Produits: `commandes_v1`, `clients_v1`
- **Domaine Marketing** (Owner: Bob)
  - Produits: `campagnes_v2`, `cpa_daily_v1`
- **Domaine Produit** (Owner: Chris)
  - Produits: `events_v3`, `retention_weekly_v1`

étape 2: définir un contrat minimal par produit

Le contrat est un simple fichier YAML qui vit à côté du code qui génère la donnée. Il doit être concis et actionnable.

# data_products/marketing/cpa_daily_v1.yml
dataset_id: marketing.cpa_daily_v1
owner: marketing-team
description: "Coût par acquisition (CPA) journalier par pays, en Euros."

schema:
  - name: d
    type: date
    time_zone: "UTC"
  - name: country
    type: string
  - name: cpa_eur
    type: numeric(10, 2)

quality_checks:
  - "cpa_eur >= 0"
  - "cpa_eur < 10000" # Seuil de plausibilité

access_policy: "Accès autorisé aux rôles: bi, marketing"

slo:
  freshness_hours: 6

étape 3: automatiser le build et les tests

Un produit de données doit être construit, testé et déployé automatiquement. La CI/CD est non-négociable. dbt est un excellent outil pour ça.

# Commande dans un pipeline de CI
# 1. Construit le produit de données (la vue ou table)
dbt run --models marketing.cpa_daily_v1
# 2. Exécute les tests de qualité définis sur le produit
dbt test --models marketing.cpa_daily_v1

étape 4: instrumenter l’observabilité

Une fois le produit en production, il faut monitorer sa santé. Des requêtes simples peuvent être exécutées régulièrement pour vérifier que les garanties du contrat sont respectées.

-- Test de fraîcheur
SELECT MAX(d) AS derniere_donnee FROM marketing.cpa_daily_v1;
-- -> Alerte si la date est trop ancienne par rapport au SLO

-- Test de validité sur les bornes
SELECT COUNT(*) AS nb_invalides
FROM marketing.cpa_daily_v1
WHERE cpa_eur < 0 OR cpa_eur > 10000;
-- -> Alerte si le compte est > 0

exemples

cas: Le produit de données “retention_v1”

L’équipe Produit publie une vue agrégée qui calcule la rétention hebdomadaire des nouveaux utilisateurs.

  • Produit: produit.retention_weekly_v1
  • Owner: L’équipe “Core Product”.
  • Description: Calcule le pourcentage d’utilisateurs encore actifs 7 jours après leur semaine d’inscription.
  • Contrat: Le schéma est simple (semaine_cohorte, activation_j7_pct), la fraîcheur est hebdomadaire, et les tests vérifient que le pourcentage est toujours entre 0 et 100.
  • Code: 
    CREATE OR REPLACE VIEW produit.retention_weekly_v1 AS
SELECT
    DATE_TRUNC('week', signup_date)::date AS semaine_cohorte,
    ROUND(100.0 * COUNT(CASE WHEN is_active_j7 THEN 1 END) / COUNT(*), 1) AS activation_j7_pct
FROM
    produit.users_daily_aggregates
WHERE
    signup_date >= CURRENT_DATE - INTERVAL '180 day'
GROUP BY 1
ORDER BY 1 DESC;

pièges fréquents

  • Symptôme: On passe des mois à construire un catalogue de données parfait, mais personne ne l’utilise.

    • Cause: Se concentrer sur l’outil plutôt que sur la valeur.
    • Correctif: Commencer par publier deux produits de données à forte valeur pour chaque domaine. L’adoption créera le besoin pour le catalogue.

  • Symptôme: Les contrats de données sont des documents Word de 20 pages que personne ne lit.

    • Cause: Vouloir tout documenter de manière exhaustive.
    • Correctif: Le contrat doit être un fichier de config simple, versionné avec le code, et ne contenant que les informations essentielles.

  • Symptôme: Les données sont publiées, mais leur qualité est médiocre.

    • Cause: L’absence de tests automatisés.
    • Correctif: Chaque produit de données doit avoir au minimum des tests de fraîcheur et de validité (bornes, valeurs non nulles).

  • Symptôme: Un changement sur un produit de données casse 10 dashboards en aval.

    • Cause: Changements silencieux et non coordonnés.
    • Correctif: Mettre en place un changelog public pour chaque produit et, pour les changements cassants, maintenir l’ancienne et la nouvelle version en parallèle pendant une période de dépréciation.

faq

  • Est-ce que chaque équipe métier doit avoir son propre data engineer ? Pas nécessairement. L’objectif est l’autonomie du domaine. Cela peut être atteint si une équipe de plateforme centrale fournit des outils en self-service (ex: un template de projet dbt, des pipelines de test standardisés) que les analystes du domaine peuvent utiliser facilement.

  • Quelle est la différence avec une simple vue SQL dans un data warehouse ? La différence est l’engagement. Une vue SQL est juste un morceau de code. Un produit de données est un engagement de service : il a un propriétaire identifié, un contrat qui définit des garanties, un cycle de vie, et il est traité avec la même rigueur qu’un produit logiciel destiné à des clients.

tags