Le product manager data d'une plateforme gère un produit dont les clients sont internes. Il décide de ce que l'équipe plateforme construit sur Snowflake, Databricks ou BigQuery : parcours en self-service, catalogue, contrôles de qualité, niveaux de service, maîtrise de la facture. On le trouve chez les grands comptes qui font tourner une plateforme pour des dizaines d'équipes, dans les scale-ups qui structurent leur data, et en ESN sur des missions de product owner plateforme.
Le poste attire des profils venus de la gestion de projet qui parlent roadmap et priorisation sans savoir ce qu'est un SLO de fraîcheur ni d'où vient une facture de warehouse. Un product manager de plateforme doit pourtant lire un historique de requêtes, discuter d'un contrat de données avec un data engineer et répartir un coût entre équipes. L'entretien porte donc sur ces sujets techniques.
Avant l'entretien, faites nommer au manager les clients internes les plus exigeants et ce qui coince aujourd'hui avec eux. Les bons candidats citent un indicateur d'adoption suivi dans le temps plutôt qu'une liste de fonctionnalités livrées. Douze équipes partagent la plateforme du cas pratique.
Ce qu'un product manager de plateforme data a dans son périmètre
Entrepôt ou lakehouse (Snowflake, Databricks, BigQuery)
Le socle sur lequel les équipes stockent, transforment et interrogent leurs données. Le product manager n'administre pas ce socle. Il doit comprendre ses options et son modèle de facturation, puisque la plus grosse part de la facture et des contraintes de la plateforme en dépend. Demandez comment se calcule la facture de l'outil cité sur le CV.
Parcours self-service et golden paths
Des chemins balisés pour qu'une équipe crée un pipeline sans ticket : dépôt modèle, projet dbt, DAG Airflow, tests et CI déjà branchés, environnement provisionné automatiquement en Terraform. Certaines entreprises les exposent dans un portail développeur comme Backstage. Le temps pour mettre en production un premier pipeline est la mesure à suivre.
Catalogue et lignage (DataHub, OpenMetadata, Unity Catalog, Collibra)
Le catalogue recense les jeux de données, leur propriétaire, leur description et leur niveau de confiance. Le lignage montre d'où vient chaque table et ce qui en dépend, jusqu'aux tableaux de bord. Un catalogue que personne n'ouvre ne sert à rien, et un bon candidat sait l'expliquer.
Contrats de données
Un accord écrit et versionné entre l'équipe qui produit une donnée et celles qui la consomment : schéma, signification des champs, propriétaire, fraîcheur garantie. L'Open Data Contract Standard en propose un format YAML. Vérifié automatiquement, il évite qu'un renommage de colonne casse des tableaux de bord sans prévenir.
SLI, SLO et observabilité des données
Un SLI est une mesure (heure de mise à jour d'une table, taux de succès des jobs), un SLO la cible fixée sur cette mesure. Des outils comme Monte Carlo, Elementary ou Soda, ou des contrôles maison, mesurent fraîcheur, volume et schéma. Le product manager décide quelles tables méritent quel engagement.
FinOps et allocation des coûts
Rendre la facture cloud lisible par équipe : étiquettes sur les ressources, warehouses ou clusters dédiés, vues de consommation, showback puis éventuellement chargeback. S'y ajoutent des garde-fous qui coupent une dérive avant la fin du mois. Sur une plateforme partagée, c'est souvent le sujet qui fait venir la direction.
Accès, sécurité et données personnelles
Rôles par domaine, demandes d'accès validées par les propriétaires, masquage des colonnes sensibles, politiques au niveau des lignes, durées de conservation et journal des accès. Le product manager n'écrit pas ces règles. Il doit en faire une fonctionnalité de la plateforme, pas une contrainte laissée à chaque équipe.
Mesure de l'usage de la plateforme
Historiques de requêtes et de jobs, tables système de l'entrepôt, journaux des outils et du catalogue. C'est de là que viennent les indicateurs d'adoption : équipes actives, pipelines créés via les modèles, tickets par équipe. Un candidat qui ne sait pas où trouver ces données pilote à l'aveugle.
L'intitulé change d'une entreprise à l'autre : product manager plateforme data, data platform product owner, IT data product line manager. Chez un grand compte, la personne gère une plateforme partagée par de nombreuses équipes, avec des enjeux de gouvernance, de migration et de facture. En scale-up, elle structure une plateforme encore jeune et pose les premiers SLO. En ESN, la mission de product owner plateforme se fait souvent aux côtés d'une équipe de data engineers chez le client. Dans une organisation data mesh, elle fournit l'outillage commun aux domaines qui publient leurs data products. Le recrutement se joue sur la culture technique, qui se vérifie en entretien.
Juger un PM plateforme data sur ses bases techniques
- Architecture et briques de la plateforme data
- Parcours self-service des équipes data
- SLI, SLO et fiabilité des données
- Contrats de données et qualité
- FinOps et allocation des coûts
- Métriques d'adoption et roadmap technique
Fiabilité, coûts, adoption : des questions pour un product manager data plateforme
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.
Question 1 · confirmé
L'équipe BI se plaint que les tables du matin arrivent en retard. Comment écrivez-vous un SLO de fraîcheur pour ces tables ?
Une bonne réponseIl part d'un indicateur mesurable (SLI) : l'heure de la dernière mise à jour réussie de chaque table, comparée à l'heure attendue par les consommateurs. Il fixe une cible sur une fenêtre glissante, par exemple tant de jours sur trente où la table est prête avant 7 h, calculée automatiquement à partir des métadonnées ou de l'outil d'observabilité. Le SLO ne couvre que les tables critiques, précise si les sources hors plateforme en font partie, et une alerte part avant que la cible ne soit manquée.
Signal d'alerte« 99,99 % de disponibilité » sans dire ce qui est mesuré, ou confondre la disponibilité de l'entrepôt avec la fraîcheur des données.
Question 2 · confirmé
Comment mesurez-vous qu'une plateforme data en self-service est vraiment adoptée ?
Une bonne réponseAvec des données d'usage, pas des déclarations : équipes et utilisateurs actifs chaque semaine, part des pipelines créés depuis les modèles de la plateforme face à ceux montés à côté, délai pour mettre en production un premier pipeline, part des requêtes sur des jeux de données certifiés, tickets de support par équipe. Les sources sont les historiques de requêtes et de jobs, les tables système de l'entrepôt et les journaux des outils de la plateforme.
Signal d'alerteLe nombre de comptes créés ou de licences, ou une enquête de satisfaction comme unique indicateur.
Question 3 · confirmé
La facture Snowflake ou Databricks a pris 40 % en un trimestre. Comment répartissez-vous le coût entre équipes, et qu'est-ce qui entre dans la roadmap ?
Une bonne réponseD'abord l'attribution : warehouses ou clusters par équipe, étiquettes sur les ressources et les requêtes (query tags), lecture des vues de consommation (ACCOUNT_USAGE dans Snowflake, tables system.billing dans Databricks). Puis un showback par équipe et un coût unitaire, par pipeline ou par tableau de bord. La roadmap reprend les gains rapides (mise en veille automatique, taille des warehouses, clusters de job au lieu de clusters partagés, requêtes répétées) et des garde-fous durables : budgets, moniteurs de ressources, politiques de cluster.
Signal d'alerteCouper des accès ou demander à chacun de faire attention, sans savoir qui consomme quoi.
Question 4 · confirmé
Une équipe applicative renomme une colonne et casse dix tableaux de bord. Que proposez-vous côté plateforme pour que cela ne se reproduise pas ?
Une bonne réponseUn contrat de données versionné entre producteur et consommateurs : schéma, types, signification des champs, propriétaire et engagements de fraîcheur, dans un format comme l'Open Data Contract Standard. Le contrat est vérifié dans la CI du producteur ou à l'ingestion, et un changement cassant passe par une nouvelle version avec une période de dépréciation. Le lignage dans le catalogue dit tout de suite quels tableaux de bord sont touchés.
Signal d'alerte« Il faut mieux communiquer », ou figer tous les schémas, ce qui bloque les équipes applicatives.
Question 5 · confirmé
Une équipe met trois semaines à mettre en production son premier pipeline sur la plateforme. Que regardez-vous et que proposez-vous ?
Une bonne réponseIl découpe le parcours et mesure chaque étape : demande d'accès, création du dépôt et de l'environnement, secrets, orchestration, revue, déploiement. Il cible les attentes humaines et propose un chemin balisé (golden path) : un dépôt modèle avec CI, projet dbt et DAG déjà branchés, tests par défaut, provisionnement automatique en Terraform et documentation exécutable. Il mesure à nouveau le délai après livraison.
Signal d'alerte« On organise une formation » sans avoir regardé où passent les trois semaines.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Product manager data plateforme : les questions des recruteurs
Faut-il avoir été data engineer pour devenir product manager d'une plateforme data ?
Ce n'est pas obligatoire, mais la personne doit parler le langage des data engineers. Elle lit un historique de requêtes, comprend un DAG, sait ce que coûte un warehouse ou un cluster et ce qu'implique un changement de schéma. Beaucoup de bons profils viennent de l'ingénierie data ou de l'analytics engineering. Un profil venu de la gestion de projet peut convenir s'il démontre cette culture sur des cas concrets pendant l'entretien.
Plateforme data ou produit analytique : où s'arrête le périmètre de chaque product manager ?
Le product manager de plateforme sert les équipes data : outillage, self-service, niveaux de service, coûts. Le product owner analytics ou BI sert les métiers : indicateurs, tableaux de bord, couche sémantique. Le premier mesure l'adoption de la plateforme par les équipes internes, le second l'usage des rapports par les directions. Une offre qui mélange les deux décrit souvent un poste de product owner data généraliste, à clarifier avant de sourcer.
Que mettre à la place d'un test de code pour un product manager plateforme ?
Un test technique de code n'a pas de sens pour ce poste. Mieux vaut un exercice sur des données de la plateforme : un extrait d'historique de requêtes, une facture découpée par warehouse, une liste d'incidents. Demandez à la personne d'en tirer un diagnostic et trois priorités chiffrées. Vous verrez si elle sait lire ces données, formuler un SLO ou proposer une répartition des coûts, sans écrire une ligne de code.
Le FinOps fait-il vraiment partie du poste ?
Sur une plateforme partagée, oui. La facture de l'entrepôt ou du lakehouse grossit avec l'usage, et c'est souvent au product manager qu'on demande d'expliquer pourquoi. Il ne négocie pas forcément les contrats, mais il doit savoir attribuer les coûts aux équipes, suivre un coût unitaire et mettre des garde-fous dans la roadmap. Un candidat qui renvoie toute question de coût vers l'équipe infrastructure passera à côté d'une partie du travail.
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.
