Community
Il y a quelques semaines, nous avons participé à un webinaire consacré au Data as a Product et au rôle du Data Product Manager.
Les échanges ont porté sur des sujets devenus familiers dans l'industrie. Une équipe centrale devient un goulet d'étranglement dès lors qu'elle est la seule autorisée à prendre les décisions concernant les données. Les organisations passent davantage de temps à réconcilier leurs indicateurs qu'à prendre des décisions, parce que certains choix ne sont jamais tranchés. Le Shadow IT apparaît quand un utilisateur cesse d'attendre qu'un système, qui n'a jamais été conçu pour répondre à son besoin, évolue.
Une organisation se tourne vers une approche Data as a Product lorsqu'elle accepte qu'une donnée sans propriétaire, sans utilisateur et sans contrat n'est rien d'autre qu'une infrastructure qui n’a pas été conçue pour la servir.
Un Data Product n'est pas simplement une donnée mise à disposition. C'est une donnée que l'on peut découvrir, comprendre, utiliser et à laquelle on peut faire confiance. C’est une donnée qui existe pour soutenir une capacité métier, et non une capacité technique.
« Même quand je suis membre d'une équipe data, je n’oublie jamais que je conçois avant tout un système. Je m’inspire des équipes logicielles qui se sont posées ces questions avant moi. » Gaëlle
Le webinaire portait essentiellement sur le Data Product Management, mais rapidement une autre réalité est apparue.
Toutes les questions posées par l'audience, « Qui est finalement responsable de la donnée ? », « Comment gouverner entre plusieurs domaines ? », « Comment embarquer durablement les membres du COMEX comme sponsors ? », étaient en réalité des questions d'organisation. Des questions sur les responsabilités, leur périmètre, les relations entre les acteurs et le niveau d'autorité nécessaire pour les exercer.
Nous étions venus présenter un rôle et expliquer ce qu'il changeait. La salle avait déjà compris le rôle. Ce qu'elle voulait réellement comprendre, c'était comment l'organisation rend ce rôle possible.
Ce qui suit est ce que nous n’avons pas eu le temps d’expliquer. Non pas le rôle lui-même, mais tout ce qui doit exister autour de lui.
Lorsqu'une équipe data atteint ses limites, le premier réflexe consiste presque toujours à regarder sa capacité de production.
« L'équipe data reçoit 350 % de demandes de plus que ce qu'elle est capable d'absorber. Les équipes métier sont paralysées : elles ne réagissent plus assez vite aux évolutions du marché. Le COMEX passe davantage de temps à réconcilier des indicateurs divergents qu'à piloter réellement l'entreprise. » Annie
La réponse semble évidente : recruter davantage. Ajouter un Data Product Manager.
Mais le symptôme n'est pas le diagnostic. Une équipe submergée par les demandes n'est pas forcément une équipe qui manque d'effectifs. C'est une équipe qui évolue dans un système qui n'a jamais été conçu pour répartir les responsabilités.
La majorité des demandes qui arrivent jusqu'à l'équipe centrale sont des sujets qui n'appartiennent à personne ailleurs.
Chaque réunion passée à réconcilier des chiffres est le symptôme d'un conflit de définition qui n'a jamais été résolu. Chaque processus utilisant excel est une preuve que le métier a renoncé à attendre qu’on réponde à son besoin. Chaque migration technique qui n’est pas motivée par un vrai besoin fait également partie du diagnostic. Lorsque le problème organisationnel reste sans réponse, la recherche d'une solution technique s'accélère.
L'outil devient le substitut d'une conversation que personne ne souhaite réellement avoir.
La vraie question n'est donc pas : « Combien de Data Product Managers nous faut-il ? »
La vraie question est : « Que doit changer l'organisation pour que ce rôle puisse réellement fonctionner ? »
Avant de parler du rôle, il faut être précis sur ce que nous appelons un Data Product.
Car le mot produit est loin d'être anodin.
« Un export brut issu d'un topic Kafka n'est pas un Data Product. Il expose de l'information, mais crée une dépendance au lieu de la supprimer. L'équipe consommatrice ne peut pas interpréter ces données sans revenir vers l'équipe source. On promettait de l'autonomie. On crée une dépendance. » Célia
Un Data Product est une donnée conçue autour de ses consommateurs : qui ils sont, quelles décisions ils doivent prendre grâce à cette donnée et quel niveau de confiance ils doivent avoir pour agir sans devoir appeler l'équipe source afin d'obtenir des explications.
Concrètement, cela implique :
« Un Data Product doit pouvoir être découvert par les autres équipes, être utilisable par tous et respecter les exigences de sécurité. Découvrabilité, compréhension, confiance, sécurité et interopérabilité. Dans cet ordre. » Annie
Un Data Product mérite véritablement son statut lorsque les mêmes données servent plusieurs consommateurs, qu'ils soient opérationnels ou analytiques.
Comme le résume Gaëlle, à partir du moment où une donnée exige des engagements de qualité et de maintenance sur l'ensemble de sa chaîne de valeur, elle devient un produit. En dessous de ce seuil, elle reste un simple jeu de données.
Cette distinction est essentielle, car elle redéfinit complètement la raison d'être du Data Product Manager.
Le rôle chargé de maintenir cette chaîne de valeur n'est ni un rôle technique, ni un simple rôle de coordination.
C'est un rôle transversal, responsable de la livraison de valeur. Un rôle qui travaille avec les équipes tout en disposant du levier stratégique nécessaire pour transformer un écosystème entier.
Les systèmes d'information dérivent naturellement au fil du temps. C'est le comportement normal de tout système qui évolue au rythme des années, des équipes et d'une complexité croissante.
« Les processus métier sont transverses. Les organisations, elles, le sont rarement. Lorsqu'un produit traverse plusieurs domaines, commerce, supply, finance, logistique, alors aucune équipe ne possède une vision complète. Chacune construit sa propre interprétation des données et ces interprétations finissent par diverger. La divergence devient un conflit et le conflit devient une paralysie. » Célia
L'ambiguïté n’est pas superficielle mais structurelle. Elle permet de décrire le fait que le « chiffre d'affaires » n'est pas un indicateur simple mais le résultat d'une négociation permanente entre trois départements, chacun défendant une vision parfaitement légitime. Elle montre que la question « Que devons-nous construire ensuite ? » ne peut être résolue sans répondre d'abord à une autre question : qu'essaie réellement de décider l'organisation ?
Les Data Product Managers existent pour gérer cette ambiguïté de manière active et continue.
Leur rôle consiste à réduire la multiplication des interprétations qui apparaît naturellement dans toute organisation. Cela veut dire qu’ils influencent les décisions stratégiques, car au fond les décisions organisationnelles et sur la donnée sont une seule et même décision.
Lorsque ce travail est bien réalisé, les équipes techniques cessent de se demander si un problème mérite d'être résolu ou en quoi il s'inscrit dans la stratégie globale. Elles reçoivent des problèmes clairement formulés, compris par le métier, alignés avec les priorités de l'entreprise et prêts à être résolus.
Le Data Product Manager n'ajoute pas simplement une couche supplémentaire à l'organisation. Il agit comme un multiplicateur. Chaque heure que les équipes d'ingénierie ne consacrent plus à arbitrer des conflits de définition devient une heure investie dans la construction de solutions utiles.
Les dirigeants, eux aussi, changent de posture. Ils peuvent enfin arbitrer leurs investissements avec un langage métier plutôt qu'essayer de gérer entre eux l'ambiguïté. Ils savent ce dans quoi ils investissent réellement : quelles hypothèses sont testées, quelles hypothèses soutiennent l'ensemble du système et quels paris sont suffisamment solides pour justifier un investissement. Le Data Product Manager apporte ainsi aux décideurs une véritable capacité de maîtrise du risque.
« La véritable valeur d'un Data Product Manager réside dans sa capacité à clarifier qui produit, expose et maintient chaque donnée, tout en alignant les parties prenantes autour d'une compréhension commune. » Célia
Dans les organisations où nous observons ce rôle produire de véritables résultats, une caractéristique revient systématiquement : le Data Product Manager est profondément ancré dans un domaine métier. Il n’est pas simplement responsable d'une liste de livrables. Il est responsable d'une vision fonctionnelle vivante, qu'il devra faire évoluer dans la durée.
Les participants avaient déjà compris le rôle. La question est donc la suivante : Comment introduire ce rôle sans qu'il devienne flou, insuffisamment soutenu et qu'il disparaisse dix-huit mois plus tard ?
La réponse commence bien avant le recrutement.
L'organisation doit d'abord accepter de résoudre un problème stratégique clairement identifié et considérer que cette résolution a plus de valeur que le coût de l'alignement qu'elle exige. Un domaine fonctionnel n'est pas une frontière dessinée sur un organigramme. C'est un problème suffisamment douloureux pour que l'organisation accepte les efforts nécessaires afin de s'aligner collectivement. Lorsque cet engagement existe, le domaine peut être défini avant même que le poste soit pourvu. Dans le cas contraire, le Data Product Manager arrive sur un territoire sans contours et passe sa première année à négocier les limites de son propre mandat.
C'est également ce qui détermine si la gouvernance soutiendra le rôle ou finira par le fragiliser. Lorsque deux domaines possèdent légitimement des définitions différentes d'un même concept, « client actif », « chiffre d'affaires net » ou « commande livrée », le Data Product Manager ne peut pas résoudre seul ce conflit. Ce qui doit exister, c'est une boucle de rétroaction entre la livraison de valeur et la gouvernance. Les conflits de définition émergent au fil du travail opérationnel. Ils remontent ensuite vers une gouvernance dont la vocation est de faciliter les décisions plutôt que d'imposer du contrôle. Ils sont arbitrés avec un niveau d'autorité suffisant pour que ces décisions s'inscrivent durablement dans l'organisation.
« L'équipe centrale ne produit plus les analyses. Elle agit comme facilitatrice en mettant à disposition une plateforme self-service standardisée. Les règles sont automatisées dans l'infrastructure. À l'intérieur de ce cadre, les domaines métier disposent d'une autonomie complète pour concevoir leurs Data Products. »
Annie
Une équipe de gouvernance qui se demande : « Comment protéger nos standards ? » referme mal cette boucle. Une équipe qui se demande : « Comment aider les équipes à prendre les bonnes décisions ? » l'utilise correctement.
L'ingénierie logicielle a déjà résolu ce problème. Une architecture fédérée fonctionne non pas parce que les domaines sont totalement autonomes, mais parce que les mécanismes d'escalade sont clairement définis et que l'autorité chargée de trancher ne fait pas débat.
La gouvernance des données a besoin de la même architecture. Non pas une architecture des systèmes, mais une architecture de la décision.
Le Data Product Manager est celui qui opère au sein de cette structure. Et, bien souvent, celui qui doit la construire avant même de pouvoir s'appuyer dessus.
Si le rôle est difficile à pourvoir, ce n'est pas parce que les profils n'existent pas. C'est parce que les organisations ne savent pas les identifier.
Les responsables data voient le potentiel du rôle, mais manquent souvent des réflexes issus du produit : partir des usages, raisonner en retour sur investissement, structurer les décisions avec les dirigeants.
Les responsables produit, à l'inverse, comprennent les utilisateurs, mais peinent parfois à voir comment ce rôle peut les aider, par exemple en identifiant les conséquences qu'une décision de modélisation peut avoir en aval.
Chacun recrute naturellement dans sa propre discipline. Le résultat est un vide organisationnel que certains collaborateurs compensent sans même s'en rendre compte. Ils absorbent une charge qui n'a jamais été officiellement attribuée. Un travail qui n'a ni titre, ni mandat, et encore moins de protection.
Cette personne existe dans la plupart des organisations. C'est parfois un ingénieur doté d'une forte vision systémique et d'une excellente compréhension du métier. Parfois un architecte qui tente d’influencer la manière dont les responsabilités sont affectées aux différentes équipes. Ou bien un analyste épuisé de produire des livrables sans jamais comprendre pourquoi ils sont réellement nécessaires.
Le point commun de ces profils n'est pas leur parcours. C'est leur capacité à raisonner sur l'ensemble de la chaîne de valeur, plutôt que sur leur seule partie du système.
Les compétences nécessaires au rôle sont aujourd'hui bien documentées. En revanche, aucune documentation ne peut produire le changement de perspective qui permet réellement d'endosser ce rôle.
Le Data Product Manager n'est pas une liste de compétences à acquérir. C'est une posture.
Et cette posture apparaît dans un contexte bien particulier. Elle se révèle lorsqu'une personne reçoit un mandat pour porter une responsabilité stratégique : un domaine. Un domaine dont elle devient réellement responsable, avec l'autorité et la responsabilité qui l'accompagnent. À partir du moment où vous devez porter une vision, et non plus simplement exécuter celle d'un autre, vous devenez un entrepreneur au sein même de votre organisation.
Cette posture ne s'acquiert pas avant la responsabilité. Elle est révélée par cette responsabilité. C'est pourquoi la meilleure manière de faire émerger un Data Product Manager n'est pas de multiplier les formations. C'est plutôt de confier à quelqu'un un véritable problème stratégique, un mandat clair et de lui laisser suffisamment de temps pour que le rôle puisse réellement prendre forme.
Lorsqu'un Data Product Manager commence à exercer pleinement son rôle, la réaction est rarement neutre.
Réduire l'ambiguïté est inconfortable : moins de définitions concurrentes signifie davantage de conversations difficiles. Par exemple, des priorités explicites signifient également que certaines demandes cessent d'être prioritaires.
Les organisations interprètent souvent ces tensions comme un problème lié au rôle, ou à la personne qui l'occupe. La plupart du temps, ce n'est ni l'un ni l'autre. C'est simplement le signe que quelque chose d'important est en train de changer.
Mais toutes les frictions ne sont pas bénéfiques. Le véritable indicateur qui montre qu'une démarche doit être arrêtée ou repensée n'est pas l'intensité des résistances rencontrées.
C'est le fait que le problème soit, ou non, reconnu comme un problème. Si les discussions portent sur la manière de résoudre le sujet, alors le Data Product Manager fait son travail.
En revanche, si les discussions portent encore sur l'existence même du problème, c'est que le rôle est arrivé trop tôt ou au mauvais niveau de l'organisation.
« Une équipe devient mature sur un sujet lorsqu'elle a vécu le problème, pas lorsqu'elle a compris la solution. Avant même de réduire l'ambiguïté, le rôle du Data Product Manager consiste parfois à rendre le coût de cette ambiguïté suffisamment visible pour que l'organisation accepte enfin qu'il existe un véritable problème. » Gaëlle
Ce qui détermine si cette friction devient un moteur de transformation ou un simple rejet, c'est le leadership.
« Une transformation doit être portée par le sommet de l'organisation, même si la valeur apparaît d'abord sur le terrain. Adoptez une démarche d'enquête : cartographiez les processus, les applications et les données afin de matérialiser les problèmes et les opportunités. Rendez les enjeux visibles avant de demander aux équipes de s'aligner. » Célia
Sans un soutien explicite et visible des dirigeants, capables d'affirmer que ces débats sont nécessaires, l'organisation revient naturellement à ses anciens réflexes et l'ambiguïté réapparaît.
Trois convictions pour conclure cet article.
« Financer de nouveaux outils ne suffit pas. Il faut aussi investir du temps, former les équipes métier et avoir le courage managérial de rendre explicites des responsabilités qui, jusque-là, étaient implicites. »
Annie
« Les données révèlent la manière dont l'organisation collabore réellement, et non celle décrite par l'organigramme. »
Célia
« Les dirigeants sont les garants de la culture qui rend cette transformation durable. L'objectif n'est pas de ‘terminer la transformation’. L'objectif est de construire des fondations suffisamment solides pour que, lorsque le contexte changera à nouveau, l'organisation puisse reconstruire à partir de ce qu'elle a appris plutôt que de repartir de zéro. Vous avez réussi lorsque le nouveau bâtiment réutilise les fondations de l'ancien. »
Gaëlle
Nous ajouterions une dernière conviction. Certaines définitions floues entretiennent des rapports de pouvoir informels. Les conflits qui apparaissent lorsque vous essayez de de mettre en œuvre le data as a product ne sont pas des problèmes de données. Ce sont des problèmes d'organisation que les données rendent enfin visibles. Réussir cette transformation nécessite une bonne dose de courage managérial.
Cet article est issu d'un webinaire consacré aux Data Products et à la maturité organisationnelle, organisé par Crème de la Crème en mai 2026. https://watch.getcontrast.io/register/creme-de-la-creme-data-as-a-product-vers-de-nouveaux-modeles-de-gouvernance
Un immense merci à Anna Bergevin, Annie Voskanian, Célia Hocine, Gaëlle Seret et Juha Korpela pour leurs contributions aux réflexions théoriques et aux retours d'expérience qui ont nourri cet article.
Vous retrouverez les fondements théoriques développés avec Juha Korpela et Anna Bergevin dans les publications de Clean Data Architecture. [Clean Data Architecture](https://cleandataarchitecture.substack.com). https://cleandataarchitecture.substack.com/p/there-are-not-enough-data-product
Pour une présentation détaillée des compétences, des livrables et de l'évolution de carrière d'un Data Product Manager, consultez The Skill-Set to Master Your Data PM Role, publié par Modern Data 101. [The Skill-Set to Master Your Data PM Role](https://www.moderndata101.com/blogs/the-skill-set-to-master-your-data-pm-role-a-practicing-data-pms-guide).
