Product owner data BI : définition des KPI, couche sémantique et adoption

Le product owner data BI porte un backlog de tableaux de bord et d'indicateurs pour les directions métier. Il fixe la définition des KPI, rédige des user stories dont les critères d'acceptation sont chiffrés, travaille avec les analytics engineers sur le modèle et la couche sémantique, et suit l'usage des rapports dans Power BI, Tableau ou Looker. On le recrute chez un client final pour remettre de l'ordre dans des centaines de rapports, ou en ESN sur une mission de PO data aux côtés d'une équipe BI.

Les CV mélangent souvent product owner, chef de projet BI et business analyst. Les rituels agiles se racontent facilement en entretien. La différence se voit sur des sujets plus techniques : expliquer pourquoi deux chiffres d'affaires divergent, choisir le grain d'une table, savoir qu'un taux ne se moyenne pas, lire un journal d'usage pour décider d'archiver un rapport.

Le nombre de rapports existants et le nom de celui qui tranche aujourd'hui la définition d'un KPI sont à obtenir du manager. La réponse dit si vous cherchez un PO qui construit ou un PO qui fait le ménage. Faites ensuite raconter au candidat un rapport qu'il a supprimé, et comment il l'a fait accepter.

Le périmètre technique d'un product owner BI

Outils de restitution (Power BI, Tableau, Looker, Qlik)

Les tableaux de bord que voient les métiers. Le product owner ne construit pas forcément les visuels, mais il connaît les possibilités et les limites de l'outil : filtres, sécurité par ligne, modes de connexion, partage. Demandez sur quel outil il a déjà suivi l'usage des rapports.

Couche sémantique (modèle Power BI, LookML, dbt Semantic Layer, Cube)

L'endroit où les KPI sont définis une seule fois, avec leurs formules, leurs relations et leurs droits, puis réutilisés par tous les rapports. Sans elle, chaque rapport recalcule le chiffre d'affaires à sa façon. Les assistants IA qui répondent sur des données s'y branchent aussi.

Entrepôt et modèle en étoile

Les données sont organisées en tables de faits (ventes, factures) et de dimensions (clients, produits, dates). Le grain, c'est-à-dire ce que représente une ligne, détermine les calculs possibles. Un product owner BI doit savoir en parler pour écrire des critères d'acceptation justes.

Transformations SQL versionnées (dbt)

dbt sert à écrire en SQL les transformations qui préparent les tables du modèle, avec des tests et une documentation versionnés dans Git. Le product owner n'écrit pas forcément ce code, mais il lit un modèle dbt et demande les tests qui protègent ses indicateurs.

Backlog et critères d'acceptation chiffrés (Jira, Azure DevOps)

Le backlog BI se gère comme un autre, avec une particularité : un critère d'acceptation porte sur une valeur. Pour tel mois, tel segment, on attend tel chiffre, rapproché de la source. C'est ce qui rend une recette vérifiable.

Journaux d'usage des rapports

Power BI propose des métriques d'usage et un journal d'activité, Tableau ses Admin Insights, Looker son espace System Activity. On y lit qui consulte quoi, à quelle fréquence, et ce qui est exporté. C'est la base pour décider de refondre ou d'archiver un rapport.

Gouvernance des contenus (certification, espaces, sécurité)

Contenus promus ou certifiés, espaces de travail séparés par environnement, droits par groupes, sécurité au niveau des lignes. Quand une entreprise compte des centaines de rapports, ces règles permettent de savoir lesquels font foi.

Tests de données et recette

Tests automatiques sur les tables (unicité des clés, fraîcheur, volumes) et rapprochement des chiffres avec une source de référence comme l'ERP ou la comptabilité. Une recette faite à l'œil par le demandeur laisse passer les doublons et les mauvaises jointures.

Les intitulés varient : product owner data BI, PO data analytics, data product manager analytics, parfois chef de projet BI dans les organisations moins agiles. Chez un client final, le poste consiste souvent à rationaliser un parc de rapports devenu illisible et à faire converger les définitions entre directions. En ESN, la mission se déroule chez un client avec une équipe BI déjà en place, souvent sur Power BI, et une recette à organiser. Dans les entreprises qui ont adopté une couche sémantique, le PO travaille de près avec les analytics engineers sur les métriques partagées. Une base de SQL et de modélisation est attendue, même si le PO n'écrit pas le code de production.

Les savoir-faire techniques qu'un PO data analytics doit prouver

• Définition et formalisation des KPI
• Modélisation dimensionnelle et grain
• Couche sémantique et métriques partagées
• Backlog BI et critères d'acceptation data
• Qualité des données et recette des chiffres
• Mesure d'usage et gouvernance des rapports

Chiffres divergents, recette, usage : cinq situations pour un product owner data BI

Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.

1. Question 1 · confirmé

   Deux directions présentent un chiffre d'affaires différent pour le même mois. Comment remettez-vous les deux chiffres d'accord ?

   Une bonne réponseIl remonte aux définitions : source (commandes ou factures), date retenue (commande, livraison, facturation), hors taxes ou TTC, avoirs et retours, devise, périmètre des filiales, ventes internes au groupe. Il reconstitue l'écart en SQL, ligne à ligne, puis écrit une fiche KPI avec formule, grain, source, filtres et propriétaire. La mesure unique va dans la couche sémantique et sa définition s'affiche dans le rapport. Si les deux besoins sont légitimes, il garde deux indicateurs portant deux noms différents.

   Signal d'alerteRetenir le chiffre de la direction la plus haut placée, ou faire la moyenne des deux.

2. Question 2 · confirmé

   Rédigez à voix haute les critères d'acceptation d'une user story « afficher le taux de churn mensuel par segment ».

   Une bonne réponseD'abord la définition : qui compte comme client actif en début de mois, ce qui fait qu'un client est perdu, ce qu'on fait des réactivations et des clients créés dans le mois. Puis le grain, le segment retenu (celui du début de mois ou l'actuel, donc un historique des segments), la fréquence de rafraîchissement et les droits par région. Enfin des valeurs attendues : pour mars, tel segment doit donner tel taux, rapproché de la source. Chaque critère se vérifie.

   Signal d'alerte« Le tableau de bord affiche le churn par segment », sans définition ni valeur attendue.

3. Question 3 · confirmé

   Un rapport est en ligne depuis six mois. Comment savez-vous s'il sert à quelque chose ?

   Une bonne réponseAvec les journaux d'usage de l'outil : métriques d'usage et journal d'activité de Power BI, Admin Insights de Tableau, System Activity de Looker. Il regarde les utilisateurs uniques rapportés à la population visée, la fréquence, les pages réellement consultées, les abonnements et les exports vers Excel, signe d'un besoin mal couvert. Selon le résultat, le rapport est refondu, fusionné avec un autre ou archivé.

   Signal d'alerteEnvoyer un e-mail pour demander si le rapport plaît, ou compter le nombre de rapports livrés comme indicateur de succès.

4. Question 4 · confirmé

   Pourquoi placer les KPI dans une couche sémantique plutôt que dans chaque rapport ?

   Une bonne réponsePour qu'un indicateur ait une seule définition, réutilisée par tous les rapports et par d'autres outils (Excel, notebooks, assistant IA), versionnée et testée, avec la sécurité appliquée au même endroit. Il cite des réalisations concrètes : modèle sémantique Power BI partagé, LookML, dbt Semantic Layer avec MetricFlow, Cube. Il connaît les limites : performance à surveiller, dépendance à un outil, changements à gouverner.

   Signal d'alerte« Chaque analyste écrit sa mesure dans son rapport », ou aucune idée de ce qu'est une couche sémantique.

5. Question 5 · senior

   Le métier veut la marge par produit et par jour, mais les coûts ne sont connus qu'au mois. Que décidez-vous pour le modèle de données ?

   Une bonne réponseIl voit deux faits à des grains différents. Soit la marge s'affiche au mois seulement, soit le coût est réparti au jour selon une clé documentée et visible dans le rapport. Le modèle garde deux tables de faits reliées par des dimensions communes (produit, mois) au lieu de forcer une jointure. Il prévient du risque de doublement des coûts si on joint les deux tables au mauvais grain.

   Signal d'alerteDiviser le coût par trente sans le dire, ou joindre les deux tables au jour et multiplier les coûts.

SQL, couche sémantique et périmètre du product owner BI

Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.