Sur une plateforme interne, le technical product manager décide de ce que l'équipe plateforme construit pour les autres équipes : chaîne de déploiement, modèles de services, portail développeur. Sur un produit API, il porte le contrat que des partenaires appellent chaque jour. Les offres françaises le cherchent pour un socle cloud, une plateforme d'IA générative exposée par API, ou les composants techniques d'un progiciel. Dans les deux cas, il passe plus de temps avec des ingénieurs qu'avec le marketing.
La difficulté tient au dosage. Un ancien développeur devenu PM parle bien d'architecture mais oublie parfois de mesurer l'adoption. Un PM venu du produit grand public connaît la discovery et ne voit pas pourquoi renommer un champ peut casser quarante intégrations. Le candidat raconte une API ou une plateforme qu'il a fait évoluer sans casser ses clients, et ce qu'il a mesuré.
Deux points se règlent dès la fiche de poste : le type d'utilisateurs, internes ou externes, et la disponibilité déjà promise aux clients. Le PDF contient un cas de 20 minutes sur l'ouverture d'une API interne à des partenaires.
Les briques techniques qu'un technical PM doit savoir discuter
API REST et OpenAPI
La plupart des API publiques sont en REST et décrites dans une spécification OpenAPI, aujourd'hui en version 3.1 ou 3.2. Ce fichier sert de contrat entre l'équipe et ses clients : documentation, SDK et contrôles automatiques en sont générés. Un technical PM doit savoir le lire et le faire relire avant le code.
GraphQL, gRPC et webhooks
GraphQL laisse le client choisir les données qu'il demande, utile pour des fronts variés. gRPC sert surtout entre services internes, pour la performance. Les webhooks envoient un événement au client au lieu de le laisser interroger l'API en boucle. Le candidat doit savoir quand proposer chacun.
Passerelle API
Kong, Apigee, Azure API Management ou Amazon API Gateway se placent devant les services. Ils gèrent l'authentification, les limites de débit, les quotas par offre et les statistiques d'usage. Le choix pèse sur le coût et sur la capacité à facturer l'API.
Authentification et sécurité
OAuth 2.0 et OpenID Connect pour les applications et les utilisateurs, clés d'API pour les intégrations simples, mTLS entre services. Le technical PM n'a pas à les implémenter, mais il doit savoir lesquels proposer à un partenaire et ce que la sécurité exige.
SLO, budget d'erreur et observabilité
Un SLO fixe l'objectif de fiabilité interne, par exemple 99,9 % de requêtes réussies sur trente jours, et le budget d'erreur dit ce qu'il reste à consommer. Datadog, Grafana ou OpenTelemetry fournissent les mesures. Sur une API vendue, le SLA contractuel découle de ces chiffres.
Plateforme interne : CI/CD et Kubernetes
Une plateforme interne regroupe en général la chaîne d'intégration et de déploiement (GitLab CI, GitHub Actions, Argo CD), un hébergement sur Kubernetes, la gestion des secrets et la supervision. Le technical PM en fait un produit, avec un parcours recommandé pour créer un service.
Portail développeur et Backstage
Le portail regroupe catalogue des services, documentation, propriétaires et modèles de projet. Backstage, projet open source né chez Spotify et hébergé par la CNCF, est le plus cité. Des offres hébergées comme Port ou Cortex existent aussi. Le catalogue n'a de valeur que s'il reste à jour.
Mesure de l'usage et facturation
Pour une API payante, chaque appel ou transaction doit être compté de façon fiable puis facturé, souvent avec un outil de facturation à l'usage. Le technical PM choisit l'unité facturée et vérifie que la mesure correspond à la facture envoyée au client.
Deux postes partagent l'intitulé. Le product manager de plateforme interne sert les développeurs de l'entreprise : son produit est la chaîne de déploiement, l'hébergement et l'outillage commun, et il se mesure à l'adoption et au temps gagné par les équipes. Le product manager API sert des clients externes : intégrateurs, partenaires, éditeurs qui construisent sur son API, avec un contrat, une documentation publique et souvent une facturation à l'usage. Les offres demandent une culture technique solide (architecture distribuée, API REST, cloud), sans exiger un passé de développeur. Certaines, sur des composants techniques de progiciels, demandent en revanche une expérience longue en développement. L'entretien dépend de celui des deux postes qui est ouvert.
Ce qui distingue un bon product manager plateforme ou API
- Conception et contrat d'API
- Versionnement et fin de vie
- Fiabilité et SLO
- Expérience développeur sur la plateforme
- Arbitrages de roadmap technique
- Adoption externe et monétisation
Cinq questions d'entretien annotées pour un technical product manager
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é
Un partenaire renvoie sa requête de création de commande après un timeout, et la commande est créée deux fois. Que changez-vous dans l'API ?
Une bonne réponseIl rend la création idempotente : le client envoie une clé unique par opération dans un en-tête (Idempotency-Key, pratique popularisée par Stripe et en cours de normalisation à l'IETF), le serveur garde la clé et la réponse pendant une durée donnée et renvoie la même réponse au second appel. Il l'inscrit dans le contrat de l'API, la documente et vérifie que les webhooks renvoyés après échec sont traités de la même façon côté client.
Signal d'alerte« On demande au partenaire de ne pas relancer », ou un dédoublonnage fait à la main par le support après coup.
Question 2 · senior
La v1 de l'API est encore appelée par 40 clients externes, dont trois qui pèsent la moitié du revenu de l'API. L'équipe veut la couper au prochain trimestre. Comment fixez-vous la date et menez-vous la fin de vie ?
Une bonne réponseIl part des données : qui appelle encore la v1, avec quel volume et quel revenu, à partir des clés d'API, et ce que les contrats prévoient comme préavis. Il fixe la date avec les commerciaux et le support, pas avec la seule équipe technique, et traite les trois gros clients en direct, avec un plan de migration daté pour chacun. Pour les autres : guide de migration, en-têtes Deprecation (RFC 9745) et Sunset (RFC 8594) sur les réponses, coupures courtes et annoncées (brownouts) avant la date. Il suit chaque semaine les appels v1 et le revenu encore exposé.
Signal d'alerteUn e-mail d'annonce, puis la coupure le jour dit, sans savoir qui appelle encore la v1.
Question 3 · senior
Le directeur commercial promet 99,99 % de disponibilité de l'API à un grand client. Qu'est-ce que cela représente, et que vérifiez-vous avant la signature ?
Une bonne réponse99,99 % laisse environ 52 minutes d'indisponibilité par an, à peine plus de quatre minutes par mois. Il vérifie la disponibilité réellement mesurée sur l'année, celle des dépendances (hébergeur, base de données, fournisseur d'authentification), qui se multiplient entre elles, et la façon dont elle sera mesurée. Il rappelle que le SLA contractuel, avec pénalités, doit rester moins strict que l'objectif interne (SLO) de l'équipe.
Signal d'alerteIl accepte parce que « l'hébergeur garantit 99,99 % », ou ne sait pas traduire le pourcentage en minutes.
Question 4 · confirmé
Qu'est-ce qu'un golden path sur une plateforme interne, et comment savez-vous qu'il est suivi ?
Une bonne réponseLe chemin recommandé pour créer et faire tourner un service : un modèle de projet avec la CI, le déploiement, la supervision et la sécurité déjà configurés. Il reste proposé et non imposé. Il mesure la part des nouveaux services créés à partir du modèle, le temps entre la création d'un service et sa première mise en production, et les équipes qui en sortent, pour comprendre pourquoi.
Signal d'alerteUn ensemble de règles imposées sans outillage, ou une documentation présentée comme un golden path.
Question 5 · senior
Les équipes réclament de nouvelles fonctionnalités, l'équipe plateforme veut remplacer son orchestrateur. Comment construisez-vous la roadmap du semestre ?
Une bonne réponseIl chiffre ce que la migration apporte aux utilisateurs (déploiements plus rapides, coût, incidents évités) pour la comparer aux demandes sur la même échelle. Il réserve une part de capacité explicite, découpe la migration en étapes livrables qui remplacent l'ancien système morceau par morceau, et dit clairement ce qui ne sera pas fait ce semestre.
Signal d'alerteTout pour la migration parce que « c'est technique », ou tout pour les demandes en laissant la dette s'accumuler.
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
Technical PM : les questions fréquentes
Technical product manager ou product owner technique : qui fait quoi ?
Le product owner technique tient le backlog d'une équipe, écrit les user stories et suit la livraison sprint par sprint. Le technical product manager porte la stratégie du produit technique : à qui sert la plateforme ou l'API, ce qu'elle promet en fiabilité, comment elle sera adoptée et parfois facturée. Dans les petites équipes, la même personne fait les deux. Dans l'entretien, la différence se voit sur les questions de roadmap et de modèle économique.
Ancien développeur ou product manager de métier : quel profil convient ?
Les deux peuvent réussir. Un ancien développeur comprend vite les contraintes d'architecture, mais il faut vérifier qu'il mesure l'adoption et qu'il sait refuser une demande d'ingénieur. Un product manager de métier doit prouver qu'il lit une spécification OpenAPI, comprend un changement cassant et discute un SLO avec l'astreinte. Les questions sur la fin de vie d'une version et sur la disponibilité font vite ressortir les manques de chaque profil.
Le test technique a-t-il sa place pour ce poste ?
Pas sous forme de code. Un exercice sur une vraie spécification OpenAPI marche mieux : le candidat relève les changements cassants entre deux versions, propose une politique de versionnement et écrit les exigences non fonctionnelles d'un endpoint. Une étude de cas orale sur une plateforme interne peu adoptée complète bien. On voit en direct s'il parle aux développeurs comme à des clients.
Plateforme interne ou API pour clients externes : faut-il le même candidat ?
Le socle est commun : contrat d'API, fiabilité, versionnement, mesure de l'adoption. Sur une API externe, il faut en plus une expérience de documentation publique, de relation avec des partenaires et de facturation à l'usage. Sur une plateforme interne, il faut savoir faire migrer des équipes qui n'en ont pas envie et prouver la valeur de la plateforme à la direction. Les questions suivent le poste réel.
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.
