Vous êtes Product Owner, Chef de Projet ou Business Analyst ou Projet Manager, et l'idée de piloter un projet data vous semble intimidante ? Entre le vocabulaire technique, les discussions autour des pipelines, de la qualité des données ou du machine learning, il est facile d’avoir l’impression de ne pas être “assez technique” pour prendre sa place. 

J’ai moi-même connu ce sentiment au début de mes projets data. Avec le temps, j’ai compris qu’un PO Data n’a pas besoin de remplacer un data engineer : sa valeur est ailleurs, dans sa capacité à poser les bonnes questions, cadrer le besoin métier et faire le lien entre les équipes.

Ce guide partage les repères qui m’ont aidée à piloter des projets data avec plus de clarté, sans devenir experte technique.

Part I. Introduction

Mon expérience 

C'était il y a quelques années. Je venais de décrocher un mastère spécialisé en Analyses Avancées Big Data, la tête pleine de concepts prometteurs. Mais sur le marché du travail, le choc fut brutal.

"Nous cherchons un PO Data sachant coder en Python et SQL, maîtrisant l'architecture Lambda et si possible, ayant déjà déployé un modèle de ML en production."

Ce genre d'annonce, j'en ai lu des dizaines. Résultat ? "Désolé, vous n'êtes pas assez expérimentée”, autrement dit, pas assez technique. Cette petite phrase qui claque comme une porte et vous renvoie dans la case des "non-initiés".

Chez Ippon, j’ai découvert une approche différente : au-delà des compétences techniques, l’entreprise valorise aussi de vrais profils produits, capables de comprendre un besoin métier, de structurer une vision et de piloter la création de valeur.

 Mes premières missions ? Un projet BI par-ci, un projet IA par-là. Passionnant... et terrifiant. Je me souviens de ces réunions où je cherchais ma place, noyée sous un torrent de termes techniques, à me demander si j'étais légitime. 

 Puis, petit à petit, la magie a opéré. Avec le temps, la pratique et les conseils avisés de collègues plus expérimentés, j'ai commencé à y voir plus clair. J'ai appris à décoder, à poser les bonnes questions, à recentrer les débats sur l'essentiel.

 Aujourd'hui, je pilote des projets data avec aisance. Et devinez quoi ? Je ne suis toujours pas une "experte technique". Et c'est parfait comme ça.

Ma conviction

Ce parcours m'a fait prendre conscience d'une réalité : des tonnes de profils brillants – Product Owners, Chefs de Projet, Business Analysts, Managers – passent à côté de projets passionnants, simplement parce qu'ils se sentent exclus de ce monde qu'ils croient réservé aux initiés.

Stop. La data n'est pas un mythe inaccessible pour des profils projet ou produit.

Si vous avez déjà eu l’impression de manquer de légitimité ou de repères à l’idée de piloter un projet data, cet article est fait pour vous. Il ne s'agit pas de devenir expert·e, mais de trouver les bons repères pour naviguer dans cet univers et collaborer efficacement avec les équipes data.

 Car ma conviction est simple : un excellent Product Owner data n'est pas un expert technique déguisé. C'est avant tout un excellent gestionnaire de valeur.

Sa force? Savoir poser la question métier qui fait réfléchir, prioriser la fonctionnalité qui aura le plus d'impact. Bâtir un pont de confiance entre les équipes métier et techniques.

Part II. Mais au fait, c'est quoi un "PO Data" ? 

Si vous tapez "Product Owner Data" sur LinkedIn, vous tomberez sur des profils aussi variés que déroutants. La vérité est plus simple : un Product Owner Data est d'abord un Product Owner. Sa mission reste la même : porter la vision, prioriser le backlog, représenter les utilisateurs, maximiser la valeur et collaborer avec l'équipe technique. Ce qui change, c’est la matière première : la donnée.

Contrairement à une fonctionnalité visible dans une interface, la donnée n’a pas toujours d’écran ni de parcours utilisateur évident. Le rôle du PO Data est donc d’identifier qui va la consommer : un métier, un analyste, un manager, une API ou un autre système, et pour quel usage concret : décider, automatiser ou piloter.

L’essentiel à retenir : la valeur ajoutée du PO Data n’est pas de remplacer l’équipe technique, mais de relier la donnée à un besoin, un utilisateur et une valeur métier.

Pour jouer pleinement ce rôle, il faut d’abord clarifier ce qu’est un produit data, qui le consomme et quelle valeur il doit produire. C’est ce que nous allons voir dans la partie suivante.

Part III. Vision, valeur et chaîne technique

C'est quoi, un produit data ?

Un produit data, c'est un livrable qui met la donnée au service d'un besoin métier. Concrètement, cela peut être :

• Un tableau de bord pour suivre les ventes en temps réel
• Un score de probabilité d'attrition intégré dans un outil CRM
•  Une recommandation personnalisée affichée sur un site e-commerce
•  Un rapport automatisé envoyé chaque lundi matin aux équipes opérationnelles

 Attention : la donnée seule ne fait pas un produit. Un produit data n'existe que s'il est utilisé par des utilisateurs pour prendre une décision ou automatiser une action.

Comment trouver la valeur ajoutée d'un produit data ?

Voici les questions que vous devez vous poser en tant que PO, avant même d'ouvrir un outil technique :

• Qui va utiliser ce produit ? Un dirigeant ? Un commercial ? Un opérateur ? Une API ou autre système ?
• Quel usage le produit data sert ? Améliorer une décision, automatiser une action, piloter une activité ou réduire un risque ?
• Quelle est la valeur mesurable ? Gain de temps, augmentation du chiffre d'affaires, réduction des risques ?
• La donnée est-elle exploitable et digne de confiance ? A-t-on le bon volume ? Est-elle fraîche, complète, cohérente, variée et fiable pour l’usage attendu ?
• Sans ce produit, comment l'utilisateur fait-il aujourd'hui ? S’il s’en sort déjà très bien avec son processus actuel, il faut clarifier la valeur réelle du produit à construire.

Un produit data sans valeur métier claire devient vite un centre de coûts. Mais un produit construit sur une donnée non fiable peut aussi conduire à de mauvaises décisions. Le rôle du PO Data est donc de travailler à la fois sur la valeur d’usage et sur la confiance dans la donnée.

Le piège à éviter : ne pas confondre chaîne technique et fonctionnalités métier

C'est l'une des erreurs les plus fréquentes quand on débute sur des projets data. Et je l'ai moi-même commise.

On a tendance à regarder ce que l'équipe technique fait au quotidien – collecter, stocker, nettoyer, gouverner – et à se dire : "Voilà, ce sont les fonctionnalités de mon produit data !"

Pensez à la construction d’une maison. Les fondations sont invisibles pour le visiteur, mais sans elles, rien ne tient. La chaîne technique, c’est pareil : elle est souvent invisible pour l’utilisateur, mais indispensable pour construire un produit data fiable. La question est donc moins de savoir si le PO doit entrer dans le détail technique, que de comprendre comment il peut garder le cap sur la valeur métier tout au long de cette chaîne.

Votre rôle face à cette chaîne technique

Une question se pose alors : jusqu’où le PO doit-il s’impliquer dans la chaîne technique ?

La réponse est nuancée. Le rôle du PO n’est pas de choisir les outils, l’architecture ou la séquence technique à la place de l’équipe data. En revanche, il doit garder le cap sur la valeur métier et aider l’équipe à faire les bons arbitrages.

• Définir les priorités métier : "La donnée client est plus critique pour nous que la donnée produite dans les premières semaines."
• Poser les bonnes questions : "De quelles sources avons-nous absolument besoin pour livrer la première version ?"
• Arbitrer les compromis : "Peut-on accepter un niveau de qualité temporairement imparfait sur cette source pour livrer plus vite, sans mettre en risque l’usage métier ?"

L’équipe technique décide du comment. Le PO, lui, s’assure que chaque choix reste relié à un usage, une priorité et une valeur métier. Cette posture se construit surtout dans la collaboration quotidienne avec l’équipe data : c’est ce que nous allons voir dans la partie suivante.

Part IV. Comment collaborer efficacement avec l’équipe data

Un produit data ne se construit pas seul. Il naît de la rencontre entre un besoin métier (porté par PO) et une expertise technique (portée par les data architectes, data engineers, data analysts, data scientists). Mais cette rencontre peut être fertile ou chaotique.

Ce qu’une équipe data attend d’un PO data

Pour mieux comprendre ce qui fait une bonne collaboration, j'ai interrogé deux data engineers expérimentés. Leurs réponses confirment une évidence : le PO data est indispensable, mais à une condition : qu'il joue pleinement son rôle de trait d'union.

1. Traduire le besoin métier en usage data

L'équipe technique n'attend pas d'un PO qu'il sache coder ou configurer un pipeline. En revanche, elle attend qu'il sache faire le pont entre le monde métier et le monde data.

« Ce serait de pouvoir traduire un besoin métier en usage data, pouvoir également nous aider à la priorisation des tâches, la définition des tickets… »  — Charles-Albert

2. Maîtriser un socle conceptuel (pas le code)

Le PO doit connaître les notions de base (différence entre data warehouse et data lake, ce qu'est un pipeline, l'importance de la data quality) pour parler le même langage que l'équipe et comprendre pourquoi certaines tâches prennent du temps.

« Savoir par exemple c'est quoi un data warehouse, c'est quoi la différence entre un data warehouse et un data lake […] la notion de pipeline, mais vite fait, pas entrer dans les détails. »  — Meyan

3. Prioriser et challenger les demandes

Un bon PO data ne se contente pas de transmettre les demandes du métier. Il les questionne : cette fonctionnalité est-elle vraiment nécessaire ? Quel est son périmètre exact ? Quel sera son impact ?

« Voire aussi challenger les demandes […] se dire est-ce que ça c'est réellement nécessaire, quel est le scope, comment tu délimites l'impact. »  — Charles-Albert

Les difficultés de collaboration les plus fréquentes

Les deux data engineers ont été directs : les blocages ne viennent presque jamais du manque de bonne volonté. Ils viennent du manque de compréhension du produit, et des rituels qui en découlent.

1. Ne pas confondre confiance et délégation complète

Faire confiance à l’équipe technique est indispensable. Mais sur un projet data, un risque apparaît lorsque le PO ne comprend pas suffisamment le produit pour cadrer les décisions, challenger les demandes ou arbitrer les priorités.

Dans ce cas, il peut finir par déléguer non seulement le “comment” technique, mais aussi une partie du “pourquoi” et du “pour qui”. Or c’est précisément là que se situe sa responsabilité de produit.

« Elle [la PO] n’avait jamais travaillé sur des projets data. Donc je sais qu'au début c'était difficile. Quand on parlait technique, elle n’y comprenait pas grand-chose. Donc en fait elle nous laissait faire les choses et puis elle nous disait "Bon bah je vous fais confiance." »  — Meyan

2. Des user stories insuffisamment cadrées

Comme sur tout projet produit, une user story doit relier un besoin métier à une solution livrable. Mais sur un projet data, l’exercice est souvent moins visible : il faut aussi préciser la source, le schéma, la qualité, la fraîcheur ou les règles d’anonymisation des données.

Si la story est rédigée uniquement côté technique, elle risque de manquer de contexte métier. Si elle est rédigée uniquement côté PO, elle peut manquer de précisions data pour être développée correctement.

« Je pense que le PO et le tech sont obligés d'écrire les user story ensemble, parce que c'est le tech qui a toute la partie technique en tête et ce n'est pas au PO de les écrire forcément tout seul. »  — Meyan

3. L'absence de Definition of Ready / Definition of Done

La Definition of Ready et la Definition of Done sont utiles sur tout projet produit. Sur un projet data, elles deviennent particulièrement importantes, car un ticket peut sembler prêt ou terminé alors que la donnée n’est pas encore accessible, fiable, documentée ou réellement exploitable.

La DoR permet de vérifier qu’un ticket est prêt à être démarré : source identifiée, accès disponibles, périmètre défini, règles de qualité ou d’anonymisation clarifiées.

La DoD permet de vérifier qu’il est réellement terminé : données disponibles, contrôles qualité passés, documentation à jour et validation PO–tech réalisée.

Sans ces critères partagés, les tickets arrivent en refinement avec trop de zones floues, ou sont considérés comme terminés sans vérification commune.

Comment réussir sa collaboration avec l’équipe data

1. S'appuyer sur le tech lead au démarrage

Au début d'une mission data, le PO a intérêt à travailler en binôme étroit avec le tech lead. Ce n'est pas un aveu de faiblesse, c'est une stratégie de montée en compétence.

« On a souvent des questions par rapport à ce qui se fait "sous le capot" ou quels sont les points bloquants. Et c'est toujours un plaisir d'expliquer ce qu'on fait et pourquoi ça marche ou ça ne marche pas. Ça permet d'évoluer. »  — Charles-Albert

2. Comprendre la valeur avant de spécifier les solutions

Votre rôle n'est pas de spécifier comment les choses sont faites techniquement, mais pourquoi elles sont faites. Concentrez-vous sur le "pourquoi" et le "pour qui" de chaque user story.

« Le plus important c'est qu'il [le PO] comprenne la valeur métier. Dans le Gherkin, c'est vraiment le "afin de…" qui est important. Toute la partie technique, c'est pas le métier du PO. »  —  Meyan

3. Anticiper la période d'apprentissage

Acceptez que les deux à trois premiers mois soient une période d'apprentissage intense. Ce temps n'est pas un échec, c'est un investissement. L'important est de le planifier et de communiquer dessus aux parties prenantes.

« Si tu connais les notions de base de data, tu peux arriver sur une mission data et t'en sortir. Des missions data, il y en a pas 40 non plus : c'est souvent les mêmes sujets qui reviennent. »  —  Meyan

À travers ces deux interviews, un message se dégage clairement : votre équipe data n’attend pas de vous que vous sachiez coder.

Python, SQL ou l’architecture cloud peuvent s’apprendre progressivement. Ce qui compte avant tout, c’est votre capacité à comprendre les enjeux, poser les bonnes questions et maximiser la valeur du produit.

Rédiger des users stories data pour mieux collaborer avec votre équipe

Les interviews menées avec deux data engineers expérimentés ont fait ressortir deux sources de friction récurrentes dans la collaboration PO–équipe data : des user stories mal construites et l'absence de critères partagés pour savoir quand un ticket est prêt à être traité, ou considéré comme terminé.

Ces deux problèmes sont liés, et ils ont des solutions concrètes à condition d'accepter un principe que le framework Scrum pose clairement : rédiger des user stories n'est pas le travail du PO seul.

Exemple d’une user story d’archivage de données

Plusieurs PO data ayant déjà piloté des projets de migration, de data plateforme ou d'ETL le confirment : les user stories data ont tendance à être moins chargées en détails métier que dans d'autres contextes (e-commerce, application grand public, etc.). Le "qui" et le "pourquoi" sont souvent plus stables ; c'est le "comment" technique qui concentre la complexité.

Ce qui change par rapport à une US classique, c'est surtout la nature des spécifications et des critères d'acceptation : ils portent sur des données (couverture, schéma, qualité, anonymisation…) plutôt que sur des comportements utilisateurs. Une fois ce changement de registre intégré, le format reste le même.

Voici un exemple de user story fictive, construit autour d’un cas d’archivage de données historiques :

Ce que cette user story fait bien :

• Périmètre précis : la source concernée, la période couverte et les environnements cibles sont clairement définis. L’équipe sait exactement quelles données archiver.
• Valeur métier explicite : l’archivage répond à un besoin concret de conformité, d’audit et d’analyse historique pour les équipes concernées.
• Contraintes non fonctionnelles intégrées : anonymisation ou suppression des données sensibles, droits d’accès et protection contre la suppression accidentelle sont pris en compte dès la rédaction.
• Critères d’acceptation objectifs : disponibilité de la table, cohérence du volume, stabilité du schéma, traitement des données sensibles et documentation à jour peuvent être vérifiés.
• Cas de tests concrets : couverture, schéma, confidentialité, accès et documentation sont testés séparément, ce qui facilite la validation PO–tech.

Vous n’avez pas à tout faire seul

Dans le framework Scrum, le PO n'est pas le seul à pouvoir créer des user stories. Plusieurs options s'offrent à vous :

• Déléguer la rédaction technique : demandez à votre tech lead de rédiger les spécifications et cas de tests. Vous vérifiez que le besoin métier est bien exprimé.
• Co-rédiger en atelier : 30 à 45 minutes où PO et tech rédigent ensemble. La pratique la plus efficace pour produire des US complètes dès le premier essai.
• Vous concentrer sur le backlog : si déléguer la rédaction technique vous libère du temps pour prioriser et arbitrer, c'est un excellent compromis.
• Valider les US en binôme : sur une US data, la validation implique souvent de vérifier des données en base ou dans un outil BI. Le PO n’a pas forcément à réaliser ces contrôles techniques lui-même. En revanche, il peut organiser une validation avec un data engineer, un QA ou un analyste : le PO vérifie que l’usage métier est bien couvert, l’équipe technique confirme la cohérence des données, des traitements et des contrôles qualité.

Part V. Les notions data indispensables pour un PO

Après avoir vu comment collaborer avec l’équipe data, une question se pose naturellement : quel socle de notions faut-il maîtriser pour être efficace sans devenir expert technique ?

Les deux data engineers interviewés l’ont rappelé : un PO n’a pas besoin de coder, mais il doit pouvoir parler le même langage que son équipe. Sur un projet data, cela signifie comprendre les grandes notions qui reviennent souvent dans les échanges : sources, pipelines, qualité, stockage, modèles, accès ou conformité.

L’objectif n’est donc pas de remplacer les data engineers, mais d’acquérir assez de repères pour suivre les discussions, poser les bonnes questions, détecter les points d’attention et garder le cap sur la valeur métier.

Voici un petit lexique des notions data les plus utiles pour piloter sereinement ce type de projet.

Collecter : faire entrer les données 

ETL / ELT

Processus qui déplacent et transforment les données d'un point A à un point B. ETL (Extract, Transform, Load) transforme avant de charger ; ELT (Extract, Load, Transform) charge avant de transformer. Pour un PO, l’enjeu est de comprendre que le choix entre ETL et ELT peut influencer les délais, les coûts et l’ordre de priorisation des traitements.

API (Application Programming Interface)

Un pont qui permet à deux systèmes de communiquer. Une API a souvent des limites (nombre d'appels, volume de données). Elle peut servir à collecter ou à exposer des données. Savoir pourquoi l'équipe parle de "rate limit" vous évite de promettre des délais irréalistes.

Stocker : où vivent les données

Data Lake

Grand espace de stockage "brut". On y met toutes les données sans les transformer, souvent en vrac. Économique et flexible, mais peu structuré, difficile à interroger directement. C'est le grenier : tout y est, mais trouver une info précise demande du travail.

Data Warehouse

Espace de stockage “propre et structuré”. Les données y sont nettoyées, harmonisées, modélisées et prêtes pour l’analyse. Plus rapide à interroger, mais plus coûteux à construire qu’un Data Lake. Car il demande un travail de transformation, de modélisation, de qualité et de documentation en amont. Il sert à rendre les données disponibles pour différents cas d’usage : reporting, pilotage, analyse ou alimentation d’outils métier.

Data Mart

Vue du Data Warehouse taillée sur mesure pour un métier spécifique (finance, RH, commercial). Sous-ensemble optimisé pour un usage particulier. Utile pour comprendre pourquoi l'équipe finance a son propre périmètre de données.

Base de données (relationnelle vs non relationnelle)

Relationnelle (SQL) : données organisées en tables avec des liens entre elles, parfaites pour les analyses structurées.

Non relationnelle (NoSQL) : formats variés (documents, graphes, clé-valeur), plus adaptée pour des volumes massifs.

Nettoyer : rendre la donnée fiable

Data Quality

Ensemble des mesures qui disent si une donnée est fiable : complétude (pas de trous), unicité (pas de doublons), validité (format correct), fraîcheur (à jour). Utile pour fixer des objectifs réalistes : "On peut avoir une donnée fiable à 99% sur ce champ, mais cela demandera deux semaines supplémentaires. 95% vous suffit pour commencer ?"

Architecture médaillon (Bronze, Silver, Gold)

Façon d'organiser les données par niveau de qualité croissante.

Bronze : données brutes, conservées telles qu’à la source.

Silver : données nettoyées et validées.

Gold : données agrégées, modélisées et prêtes à être exposées ou consommées pour un usage métier.

Si la donnée est encore en Bronze, il faut la faire monter en Silver puis Gold avant de l'exploiter.

Gouverner : maîtriser la donnée

Data Catalogue

Annuaire qui liste toutes les données disponibles dans l'entreprise :où elles se trouvent, ce qu’elles signifient, qui en est responsable, leur niveau de qualité et leurs règles d’accès. Il peut prendre la forme d’un outil dédié ou d’un portail interne connecté aux différentes sources de données.

Couche sémantique / Couche de contexte

Couche qui donne du sens métier aux données. Elle permet de définir clairement les concepts, les indicateurs et les règles de calcul : par exemple, ce qu’on entend par “client actif”, “chiffre d’affaires net” ou “taux d’attrition”. La couche sémantique aide donc les équipes métier, data et parfois les outils d’IA à parler le même langage.

Data Observability

Capacité à surveiller la santé des données : fraîcheur, volume, qualité. La donnée peut se dégrader silencieusement. Un pipeline qui échoue sans alerte, personne ne le remarque tout de suite, jusqu'à ce que les utilisateurs s'en plaignent.

RGPD et conformité

Cadre légal qui encadre l'utilisation des données personnelles en Europe. Une fonctionnalité brillante mais non conforme ne doit pas voir le jour. En tant que PO, vous protégez votre organisation des risques juridiques et financiers.

Exposer / consommer : rendre la donnée réellement utilisable

Modélisation des données

La modélisation consiste à organiser les données pour les rendre plus faciles à analyser. Par exemple, pour suivre les ventes, on peut relier chaque vente à un client, un produit, une date ou un magasin.

Dans certains cas, cette organisation prend la forme d’un schéma en étoile, avec une table centrale pour les événements ou mesures, par exemple les ventes, et des tables autour pour décrire le contexte : client, produit, date, magasin.

SQL (Structured Query Language)

Langage qui permet d'interroger une base de données. Un PO n'a pas besoin de le maîtriser couramment. Mais savoir le lire un peu vous permet de valider par vous-même qu'une donnée existe, de comprendre pourquoi une requête est complexe, et de ne pas dépendre de votre data analyst pour toute question simple.

Projet BI vs Projet IA

Les projets BI (Business Intelligence) produisent des tableaux de bord, des indicateurs et du reporting. L’objectif est d’aider les utilisateurs à comprendre une situation et à prendre une décision à partir des données.

Les projets IA (Intelligence Artificielle) produisent plutôt des modèles prédictifs, des scores ou des recommandations. Ils servent à anticiper un comportement, détecter un risque, personnaliser une action ou automatiser une partie d’un processus.

En début de projet, n’hésitez pas à demander à un data engineer, un data analyst ou un data architecte de vous faire un tour d’horizon de l’architecture et des principaux flux de données. Cela vous aidera à mieux comprendre le terrain sans entrer dans tous les détails techniques.

Merci d'avoir lu cet article jusqu'au bout

Ce parcours a été construit à partir de retours terrain, data engineers et PO data, qui ont accepté de partager leur expérience sans filtre. Qu'ils en soient chaleureusement remerciés.

Une mention spéciale à Léana Afonso, data engineer chez IPPON Technologies, qui m'a accompagnée tout au long de la rédaction de cet article pendant ces quelques mois : pour ses connaissances du monde data, ses retours précieux et sa disponibilité à chaque étape. Cet article n'aurait pas la même profondeur sans elle.

 Si vous débutez sur un projet data en tant que PO, j'espère que ce guide vous aura donné les repères essentiels pour aborder ce nouveau terrain avec plus de sérénité. Et si vous êtes déjà en mission, j'espère y avoir glissé quelques pistes qui vous seront utiles au quotidien.

— Zixi LIAO

Product Owner chez Ippon Technologies