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 couverturecouvertureLe nombre de personnes uniques exposées à votre message sur une période donnée. Contrairement aux impressions, le reach compte chaque personne une seule fois, quel que soit le nombre d'expositions.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 LakeUn data lake est un référentiel centralisé qui stocke de grands volumes de données brutes dans leur format d'origine, des tables structurées aux fichiers non structurés, jusqu'à ce qu'on en ait besoin.Voir la définition complète → to a Distributed Data MeshData MeshLe Data Mesh est une approche décentralisée de l'architecture et de l'organisation des données, où les équipes métier possèdent et exposent leurs données comme des produits, encadrées par des standards partagés.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 crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.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 dataUn actif de données géré comme un produit : un owner, des utilisateurs identifiés, une qualité garantie et une valeur business mesurable.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 pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.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