Produits de données internes : le guide de terrain des références qui comptent

Pourquoi ce palmarès mérite votre attention : il ne classe pas des entreprises par chiffre d'affaires ou notoriété marketing. Le critère retenu ici est l'influence documentée sur la pratique du terrain, c'est-à-dire les organisations et les personnes dont les choix architecturaux, les écrits ou les modèles organisationnels ont été repris, débattus et adaptés par des équipes data dans d'autres entreprises. Ce sont les références que les CDOs citent en salle de réunion, pas celles que les cabinets de conseil placent en couverturecouvertureThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.Voir la définition complète → de leurs rapports.

Les références incontournables... pardon, les références qui comptent vraiment

1. Spotify et le modèle Backstage

Spotify a ouvert le code de Backstage en 2020 sous licence Apache. Backstage est un portail développeur interne qui centralise catalogues de services, documentation et pipelines. Ce qui le rend remarquable pour les équipes data : il a popularisé l'idée qu'un catalogue de données interne doit être traité comme un produit avec des propriétaires assignés, des SLA et une interface utilisateur soignée. Des dizaines d'entreprises ont adopté Backstage ou s'en sont directement inspirées. La leçon n'est pas technologique, elle est de gouvernance : sans propriété claire, un catalogue reste un répertoire mort.

2. Airbnb et dataportal

Autour de 2017-2019, Airbnb a développé en interne Dataportal, un moteur de recherche des données internes permettant à n'importe quel employé de trouver une table, comprendre sa provenance et identifier son propriétaire. Airbnb a publié des articles de blog techniques détaillant la démarche. Ce qui reste utile aujourd'hui : Airbnb a traité la découverte de données comme une expérience utilisateur, pas comme un problème d'infrastructure. Des ingénieurs data d'autres entreprises ont reproduit cette approche en s'appuyant sur ces publications.

3. Thoughtworks et l'article fondateur de Zhamak Dehghani

En 2019, Zhamak Dehghani, alors directrice de technologie chez Thoughtworks, a publié "How to Move Beyond a Monolithic Data LakeData LakeA data lake is a centralized repository that stores large volumes of raw data in its native format, from structured tables to unstructured files, until needed.Voir la définition complète → to a Distributed Data MeshData MeshData Mesh is a decentralized approach to data architecture and organization where domain teams own and serve their data as products, governed by shared standards.Voir la définition complète →". Ce texte a structuré le débat sur la data mesh pendant plusieurs années. Son apport concret : formaliser l'idée que la donnée doit appartenir aux domaines métier qui la produisent, et que chaque domaine expose ses données comme un produit avec une interface contractualisée. Dehghani a publié un livre chez O'Reilly en 2022 qui développe le cadre complet. Que l'on adhère ou non à la data mesh, ignorer ce travail revient à débattre de plateforme data sans vocabulaire commun.

4. Netflix et la culture de la donnée comme infrastructure interne

Netflix a construit et publié plusieurs outils internes devenus des références : Metacat (catalogue de métadonnées), Atlas (métriques), Conductor (orchestration de workflows). La particularité de Netflix est d'avoir systématiquement open-sourcé ses outils internes tout en rédigeant des articles techniques précis sur les décisions d'architecture prises. Pour un CDO, l'enseignement n'est pas "copiez Netflix" mais : traiter ses propres outils data comme des produits publiables oblige à un niveau de qualité et de documentation que les équipes internes n'atteignent presque jamais si le code reste confiné en interne.

5. Uber et l'architecture Databook

Uber a développé Databook, un système de gestion des métadonnées, et l'a documenté publiquement à partir de 2020. Databook associe chaque table à des métadonnées riches : statistiques de qualité, annotations sémantiques, informations sur l'utilisation réelle. Ce qui distingue Uber dans ce guide : l'entreprise a connecté la qualité des données directement à l'expérience du consommateur interne. Un analyste peut voir si une table est fiable avant de l'utiliser, sans contacter l'équipe productrice. C'est du "platform thinking" appliqué à la gouvernance.

6. LinkedIn et apache atlas / DataHub

LinkedIn a crcrThe percentage of visitors or prospects who complete a desired action (purchase, sign-up, contact form), calculated as conversions divided by total opportunities.Voir la définition complète →éé DataHub, un catalogue de métadonnées open source qui gère la lignée de données à grande échelle. Le projet a été cédé à la Linux Foundation et est maintenu par une communauté active. Ce qui mérite attention : DataHub a résolu un problème que beaucoup d'entreprises rencontrent au-delà d'une certaine taille, soit suivre comment une donnée se transforme de sa source jusqu'au tableau de bord final. La lignée de données n'est pas un luxe analytique, c'est ce qui permet d'identifier rapidement l'origine d'une erreur de reporting.

7. ThoughtSpot et le mouvement "data as a product" côté analytics

ThoughtSpot commercialise des outils d'analytics en self-service. Précision requise ici : ThoughtSpot est un éditeur logiciel, ses publications sur la "data culture" ont un intérêt commercial direct et méritent d'être croisées avec des sources indépendantes. Cela dit, la société a contribué à diffuser le vocabulaire du produit dataproduit dataA data asset managed like a product, with an owner, defined users, guaranteed quality, and measurable business value.Voir la définition complète → auprès des directions métier, pas seulement des ingénieurs. L'effet documenté : des équipes non techniques ont commencé à formuler des exigences en termes de SLA, de qualité et d'interface, ce qui a changé les conversations entre CDOs et directions métier.

Le pattern : ce que ces références partagent

Toutes ces organisations ont traité un actif interne (une table, un catalogue, un pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Voir la définition complète →) comme s'il avait un utilisateur externe à satisfaire. Cela paraît simple. Dans la pratique, cela implique d'affecter un propriétaire nommé, de définir des engagements de qualité mesurables et de concevoir une interface d'accès. La donnée cesse d'être un sous-produit des opérations pour devenir quelque chose que l'on conçoit, que l'on maintient et que l'on améliore en fonction de l'usage réel.

Ce qui ressort aussi : la publication joue un rôle. Spotify, Netflix, Airbnb et LinkedIn ont tous documenté leur démarche publiquement. Cette discipline de documentation a eu deux effets. D'abord, elle a forcé les équipes à clarifier leurs propres choix. Ensuite, elle a créé une pression positive sur la qualité : on ne publie pas un article technique sur un système bancal. Les entreprises qui gardent tout en interne se privent de ce mécanisme de correction externe.

Le troisième point commun : aucune de ces approches n'a commencé par un comité de gouvernance. Elles ont commencé par un problème concret, un catalogue inutilisable, une erreur de reporting répétée, un onboarding analytique trop long, et ont construit une réponse ciblée avant de généraliser.

À surveiller : les équipes data des grandes banques européennes qui, sous pression réglementaire BCBS 239BCBS 239Principe du Basel Committee on Banking Supervision imposant aux grandes banques une traçabilité stricte des données de risque, ayant catalysé la création de nombreux postes de CDO dans le secteur bancaire. et DORA, commencent à formaliser des produits de données internes avec la rigueur contractuelle que les entreprises technologiques ont appliquée à leurs APIs.

Traiter la donnée comme un produit interne n'est pas une métaphore