On va être direct. Dans 90 % des organisations, la donnée est un sous-produit. Un truc qui sort d'un pipeline, qui atterrit dans un data warehouse, et que personne ne possède vraiment. Pas de SLA. Pas de documentation digne de ce nom. Pas de propriétaire identifié. Et après, on s'étonne que l'adoption soit à 20 %.
Chez Bomzai, on a une conviction forte : la donnée doit être traitée exactement comme un produit digital. Avec un owner, une roadmap, des utilisateurs ciblés, des SLA explicites, et un cycle de vie documenté. C'est un changement de mentalité, pas un changement d'outil.
Ce qu'on entend par "data product"
Un data product, c'est un actif complet. Il a une source identifiée, des transformations versionnées, une sortie exploitable - table, API, dashboard. Il a surtout un propriétaire nommé. Pas "l'équipe data". Une personne. Avec des responsabilités claires : définir la roadmap, gérer les SLA, collecter le feedback des utilisateurs, itérer.
Prenons un exemple concret. Un data product "Customer 360" : sources CRM, transactions, interactions. Sortie : table consolidée de 50 champs. Propriétaire : VP Revenue. SLA : 99,5 % de disponibilité, moins d'une heure de latence, précision supérieure à 98 %. Version 3.2, changelog documenté. Utilisateurs identifiés : ventes, marketing, service client, analytics. C'est une structure commerciale. Pas un bout de SQL qui traîne.
Les SLA : le contrat de confiance
Sans SLA, personne ne fait confiance aux données. Point. Un SLA data, c'est une promesse mesurable : "Ce dataset est disponible à 99,5 %, avec une latence inférieure à 2 heures, une couverture supérieure à 99 % des clés, et une précision mesurée à plus de 95 % contre la source de vérité."
Quatre dimensions critiques. La disponibilité - quand les données sont accessibles. La latence - quand elles sont à jour. La complétude - quel pourcentage de lignes est couvert. La précision - quel pourcentage de valeurs est correct. Chaque dimension est monitorée en continu. Dashboard dédié, alertes en cas de dépassement. Et des conséquences réelles : un SLA non respecté déclenche un incident prioritaire, une analyse de cause racine, un plan de correction.
Les résultats mesurables sont là : les organisations qui publient des SLA clairs sur leurs data products constatent une hausse d'adoption de 40 %. Parce que la confiance, ça ne se décrète pas. Ça se mesure.
Discoverabilité : le problème invisible
Saviez-vous que 85 % des utilisateurs passent plus de 30 minutes à chercher les bonnes données ou à demander à l'équipe data ? C'est une perte de productivité massive et pourtant personne n'en parle.
La solution, c'est l'UX data. Un catalogue avec une recherche puissante, des tags, des descriptions claires. Chaque fiche de data product doit être auto-suffisante : titre explicite, description en une ligne, cas d'usage concrets ("Utilisé pour : prévisions de ventes, allocation géographique, pricing"), schéma documenté, exemples de requêtes, contact du propriétaire. L'utilisateur ne devrait jamais avoir besoin de demander. Si quelqu'un envoie un message Slack pour trouver une donnée, c'est un échec de discoverabilité.
Chez Bomzai, on recommande d'investir 20 % de l'effort d'un data product dans la documentation et l'UX. C'est le meilleur ROI qu'on ait observé sur nos cas d'usage en production.
L'ownership : pas de propriétaire, pas de produit
Un data product sans owner est un orphelin. Et les orphelins, personne ne s'en occupe. L'owner est un rôle explicite - Product Manager à 40 % du temps, Analytics Engineer à 40 %, ou une combinaison selon la nature du produit.
Si c'est un KPI critique pour la vente : le propriétaire est le CRO ou le VP Sales. Si c'est un dataset technique : c'est l'Engineering Manager du domaine. L'owner décide quelles colonnes ajouter, comment documenter, quand introduire des changements majeurs. Et surtout, l'owner est responsable. Si les utilisateurs ne sont pas satisfaits, c'est son problème. Pas celui de l'infra.
Le versioning : évoluer sans tout casser
Les data products évoluent. Nouvelles colonnes, changements de définition, améliorations de qualité. La question, c'est comment évoluer sans casser les dépendances.
La réponse : le versioning sémantique. Version majeure (v4.0) pour les changements cassants - colonne supprimée, définition de métrique modifiée - avec trois mois de notification et migration assistée. Version mineure (v3.5) pour les ajouts non cassants. Patch (v3.2.1) pour les corrections de bugs. À chaque version majeure, un changelog précis. "Le CA incluait les remboursements jusqu'en v3, exclusif à partir de v4." C'est de la rigueur industrielle appliquée à la donnée.
Le passage au mindset produit, ce n'est pas de la théorie. C'est ce qui fait la différence entre une équipe data qui tourne en rond et une équipe qui co-construit avec le métier des actifs qui produisent des résultats mesurables. Chez Bomzai, on accompagne cette transition comme un partenaire opérationnel - pas avec un audit de six mois, mais avec un premier data product en production sous 30 jours.