Un product owner technique porte une API, une plateforme interne ou un ensemble de services partagés. Ses utilisateurs sont des équipes de développement, des partenaires qui intègrent l'API ou d'autres applications. Il tient le backlog comme tout PO, mais les items parlent de contrat OpenAPI, de pagination, de temps de réponse, de montée de version et d'outillage CI/CD. Les offres demandent souvent un passé de développeur, une bonne lecture des specs d'API et une pratique de Jira et Confluence.
Deux profils se présentent. L'ancien développeur comprend vite l'équipe, mais il a parfois du mal à dire non à une demande technique séduisante et à expliquer la valeur d'un sujet au métier. Le PO fonctionnel qui a travaillé à côté d'une API cite les bons mots sans avoir jamais relu un contrat ni géré un changement cassant. Un bon candidat a déjà retiré une version, priorisé de la dette contre une fonctionnalité et mesuré l'adoption d'une API par ses consommateurs.
Un exemple daté de changement cassant, et ce qu'il a coûté aux consommateurs, fait vite la différence. Le PDF contient 30 questions sur six axes, un cas de 20 minutes sur la refonte d'une API de réservation et une grille de 1 à 4.
Le vocabulaire d'un PO technique, expliqué simplement
API REST et contrat OpenAPI
La plupart des API exposées par ces équipes suivent le style REST et sont décrites dans un fichier OpenAPI (anciennement Swagger), en version 3.0, 3.1 ou 3.2. Ce fichier liste les ressources, les champs, les codes de réponse et les règles d'accès. Un PO technique sait le lire et le faire relire par les consommateurs avant le développement.
Versioning et changements cassants
Un changement est cassant quand un consommateur existant doit modifier son code : champ retiré ou renommé, type changé, paramètre devenu obligatoire. Les équipes publient alors une nouvelle version majeure et maintiennent l'ancienne pendant un délai annoncé. C'est le sujet qui révèle le plus vite l'expérience réelle.
Dépréciation et fin de vie
Retirer une version demande un calendrier, un guide de migration et le suivi des consommateurs qui appellent encore l'ancienne. Deux en-têtes HTTP décrits dans des RFC de l'IETF servent à l'annoncer dans les réponses : Deprecation (RFC 9745) et Sunset (RFC 8594).
Dette technique et enablers
La dette technique regroupe ce qui ralentit l'équipe ou fait courir un risque : bibliothèque en fin de support, code fragile, tests absents. Un enabler est un travail sans valeur directe pour l'utilisateur final qui rend possibles les évolutions suivantes. Le PO technique les rend visibles et les priorise avec le reste.
Exigences non fonctionnelles et SLO
Temps de réponse, disponibilité, sécurité, volume supporté. Un SLO (objectif de niveau de service) les chiffre, par exemple 99,9 % de requêtes réussies sur 30 jours et une latence cible au 95e centile. Ces chiffres servent de critères d'acceptation et d'alerte quand la qualité se dégrade.
API gateway et portail développeur
La gateway gère l'authentification, les quotas et les logs d'appels par consommateur. Le portail développeur publie la documentation, délivre les accès et propose un bac à sable. Pour le PO, ce sont aussi les sources de mesure de l'adoption.
Tests de contrat et CI/CD
Un test de contrat vérifie que l'implémentation respecte le contrat validé, et un outil de comparaison de fichiers OpenAPI détecte un changement cassant avant la mise en production. Le PO n'écrit pas ces tests, il exige qu'ils existent dans la définition de fini.
Jira, Azure DevOps et Confluence
Les outils de backlog et de documentation qui reviennent dans les offres. Ils montrent comment la personne structure epics, features, stories et enablers, et où elle range les décisions d'architecture et les standards d'API.
Le titre recouvre des postes assez différents. Sur une API exposée à des partenaires, le PO technique passe beaucoup de temps sur les contrats, la documentation et les fins de vie. Sur une plateforme interne (CI/CD, outillage développeur, services partagés), ses utilisateurs sont des collègues et l'adoption se mesure à l'usage réel. Dans un train SAFe, il prépare des features et des enablers pour le PI Planning. Les offres demandent souvent quelques années de développement, ce qui ne remplace pas la pratique du métier de PO : priorisation, découpage, revue des incréments, refus argumentés.
Ce qu'un PO technique prouve en entretien
- Lecture et revue de contrats d'API
- Priorisation de la dette et des enablers
- Stories testables pour des utilisateurs développeurs
- Gestion des versions et des fins de vie
- Mesure de l'adoption et des niveaux de service
- Arbitrages avec l'architecture et le métier
Questions d'entretien pour un product owner technique
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é
Trois équipes internes et deux partenaires consomment votre API. Une équipe demande de renommer un champ mal nommé depuis le début. Que décidez-vous ?
Une bonne réponseUn renommage casse les consommateurs, donc il ne part pas tel quel. La personne regarde d'abord qui lit ce champ (logs de la gateway, appels par client). Elle propose d'ajouter le nouveau champ à côté de l'ancien, de marquer l'ancien comme déprécié dans le contrat OpenAPI et d'annoncer une date de retrait. Si le changement doit vraiment casser, il part dans une nouvelle version majeure avec un calendrier de migration par consommateur.
Signal d'alerteAccepter le renommage parce que « c'est plus propre », ou refuser sans proposer de chemin. Une réponse qui ne demande jamais qui consomme le champ.
Question 2 · confirmé
L'équipe vous demande deux sprints pour remplacer une bibliothèque d'authentification en fin de support. Le métier attend une nouvelle fonctionnalité. Comment arbitrez-vous ?
Une bonne réponseLa personne chiffre le risque de l'inaction : date de fin des correctifs de sécurité, vulnérabilités connues, ce qui casse si rien ne bouge. Elle l'inscrit comme enabler visible dans le backlog, avec un critère de fini vérifiable, et le priorise avec la même méthode que le reste (coût du retard, WSJF). Elle explique au métier ce qu'il perd si on attend et cherche à découper le remplacement pour livrer une partie de la fonctionnalité en parallèle.
Signal d'alerte« La technique passe toujours après le métier », ou au contraire laisser l'équipe décider seule sans rien rendre visible. Un enabler caché dans une story fonctionnelle.
Question 3 · junior à confirmé
Écrivez les critères d'acceptation d'une story « exposer la liste des commandes d'un client » sur une API REST.
Une bonne réponseDes critères vérifiables par un test : la ressource et le verbe, la pagination et sa taille maximale, les filtres acceptés, les codes de réponse attendus (200, 400 sur un filtre invalide, 401, 403 si le client n'est pas le bon, 404), le format des erreurs, le temps de réponse visé au 95e centile, et la mise à jour du contrat OpenAPI. Un bon profil pense au cas du client sans commande et au droit d'accès.
Signal d'alerte« La liste des commandes s'affiche correctement. » Des critères rédigés comme pour un écran, sans code d'erreur, sans pagination, sans contrôle d'accès.
Question 4 · confirmé
Votre API est publiée depuis six mois et peu d'équipes l'utilisent. Comment cherchez-vous ce qui bloque ?
Une bonne réponseDes mesures d'abord : nombre de demandes d'accès, délai entre l'inscription et le premier appel réussi, taux d'erreurs 4xx par consommateur, questions posées au support. Puis quelques entretiens avec des développeurs qui ont abandonné. Les causes habituelles sont une documentation sans exemple, une demande d'accès trop longue, un bac à sable absent ou une API qui ne répond pas au besoin réel. La personne en tire des items de backlog mesurables.
Signal d'alerte« Il faut faire plus de communication », sans aucune mesure. Ou supposer que le problème est technique sans avoir parlé à un seul consommateur.
Question 5 · senior
Vous retirez la v1 de l'API dans six mois. Comment organisez-vous la fin de vie ?
Une bonne réponseUne annonce écrite avec la date de retrait et le guide de migration, l'ancienne version marquée dépréciée dans le contrat, les en-têtes HTTP Deprecation et Sunset sur les réponses de la v1, et un suivi des appels par consommateur pour relancer ceux qui restent. La personne prévoit des jalons (gel des évolutions, coupures courtes de test, coupure finale) et une règle d'exception validée par quelqu'un qui a le pouvoir de la donner.
Signal d'alerteUn mail à tous puis la coupure à la date prévue, sans savoir qui appelle encore la v1. Ou une v1 maintenue sans fin parce que personne n'ose la retirer.
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 owner technique : les questions fréquentes
Un product owner technique doit-il avoir été développeur ?
Beaucoup d'offres le demandent, et quelques années de développement aident à comprendre l'équipe et à lire un contrat d'API. Ce n'est pas suffisant. Un ancien développeur peut rester trop proche de la solution et mal défendre la valeur d'un sujet auprès du métier. Le plus important est qu'il ait déjà priorisé un backlog, refusé une demande avec des arguments et suivi l'usage d'une API après sa livraison.
Quelle différence avec un product owner fonctionnel ?
Le PO fonctionnel sert des utilisateurs métier à travers des écrans et des processus. Le PO technique sert des développeurs ou des systèmes à travers des interfaces. Le métier de base reste le même : vision, backlog, priorisation, validation des incréments. Le PO technique ajoute la lecture des contrats, la gestion des versions, la dette technique et les niveaux de service. Les deux profils se recrutent rarement avec la même grille.
Quel exercice est donné à un PO technique ?
Un exercice de code n'a pas de sens pour ce poste. Un test technique adapté consiste à lui donner un extrait de contrat OpenAPI et une demande d'évolution, puis à lui demander s'il casse les consommateurs et comment il découpe le travail. En vingt minutes, on voit s'il lit un contrat, s'il pense aux consommateurs existants et s'il écrit des critères vérifiables.
Quels signaux d'alerte repérer dans le CV d'un PO technique ?
Une liste de technologies sans aucun produit nommé, aucune mesure d'usage ou de qualité, et des missions décrites comme de la rédaction de spécifications pour une MOA. Le titre de PO technique sert parfois à désigner un business analyst ou un chef de projet. La personne doit pouvoir dire quelle API elle a portée, qui la consommait et quelle version elle a retirée.
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.
