Entretien de PM à l'ère de l'IA : comment répondre aux 5 questions préférées des recruteurs

Ces deux dernières années, j’ai fait passer pas mal d’entretiens de product manager, et j’en ai passé aussi. Il y a un schéma tellement frappant que je m’en souviens encore : dès qu’on touche à une question sur l’IA, huit candidats sur dix se mettent aussitôt à réciter des concepts — c’est quoi le RAG, la différence entre fine-tuning et prompting, comment marche le mécanisme d’attention du Transformer… Plus ils débitent avec fluidité, plus j’ai le cœur qui se serre, et je suis à peu près sûr de ne pas les prendre.

Ce n’est pas parce qu’ils se sont trompés. C’est parce que ces questions ne testent jamais ce que vous avez retenu, mais votre capacité à réfléchir. Dès que vous ouvrez la bouche sur une définition, vous dites au recruteur : j’ai bachoté ça comme une leçon, mais je n’ai jamais eu à trancher quoi que ce soit là-dessus.

Le poste de PM IA, c’est précisément là qu’il diffère du PM traditionnel. Un logiciel classique, une fois que vous l’avez bien pensé, il fait à peu près ce que vous attendez. L’IA, non — un modèle peut être bluffant en test et s’effondrer en production ; il est excellent pour 90 % des gens et raconte n’importe quoi aux 10 % restants ; souvent vous ne savez même pas expliquer pourquoi il se trompe, et vous ne pouvez pas le réparer d’un simple correctif. Donc ce que le recruteur veut vraiment savoir, ce n’est pas si vous connaissez ces termes, c’est comment vous prenez des décisions produit face à une chose qui « se trompe, s’explique mal et se répare mal ».

Voici les 5 questions que j’ai le plus entendues — et le plus posées — ces deux dernières années. Je ne vous donne pas de réponse type : sur l’IA, la plupart de ces questions n’ont pas de réponse type, le recruteur évalue votre raisonnement, pas votre conclusion. Je vais juste dire ce que chaque question pèse chez vous, comment j’y répondrais, et le genre de réponse qui fait le plus souvent trébucher.

1. « Cette fonction IA se trompe parfois. Comment décidez-vous si elle peut être mise en production ou non ? »

C’est presque la première question d’un entretien de PM IA, et c’est aussi la ligne de partage.

Elle teste ceci : êtes-vous capable d’accepter le postulat que « l’IA va forcément se tromper », et malgré ça de prendre une décision responsable ? Le réflexe du logiciel classique, c’est « il y a un bug, je corrige jusqu’à ce qu’il n’y en ait plus » — mais une fonction IA, vous ne la corrigerez jamais jusqu’à zéro erreur. Si votre réponse laisse transparaître « je veux atteindre 100 % de précision avant de la mettre en ligne », vous êtes à peu près éliminé : ça montre que vous n’êtes pas encore entré dans le monde de l’IA.

Comment je répondrais : je ne cherche pas qu’elle ne se trompe pas, je cherche à ce que « quand elle se trompe, le coût soit un coût que je peux assumer ». Je commence par poser une question — si cette fonction se trompe, quel est le pire scénario ?

Une IA qui aide l’utilisateur à rédiger un e-mail, si elle se trompe, l’utilisateur corrige un peu : le coût est très faible, alors 80 % de précision me suffit pour la lancer, parce que les 20 % restants, l’utilisateur les rattrape lui-même. Mais une IA qui prélève automatiquement de l’argent, ou qui suggère un diagnostic à un médecin, une seule erreur, c’est un accident : là, même 99 % ne me suffit pas, il me faut une relecture humaine, un filet de sécurité, et une porte de sortie du type « dans le doute, on ne fait pas ». À précision égale, pouvoir la lancer ou non dépend du coût de l’erreur, pas du chiffre lui-même.

La réponse qui fait le plus souvent trébucher : ne parler que du chiffre de précision, jamais de ce qui se passe en cas d’erreur. Traiter « l’IA est-elle bonne » comme une question de note, et non comme une question produit du type « le pire cas, est-ce que je le tiens ou pas » — c’est le raisonnement de 2023, et un recruteur de 2026 comprend tout de suite que vous n’avez jamais mis une vraie fonction IA en production.

2. « Pour ce besoin, vous utilisez du prompting, du RAG, ou du fine-tuning ? Pourquoi ? »

Cette question revient à une fréquence délirante, surtout sur les postes liés aux grands modèles : le triple choix prompting / RAG / fine-tuning est quasiment inévitable.

Beaucoup croient qu’elle teste la technique, alors qu’en réalité elle teste votre capacité à arbitrer. Le recruteur ne s’attend absolument pas à ce que vous sachiez écrire du code de fine-tuning à la main ; ce qu’il veut voir, c’est : face à un besoin, savez-vous classer ces différentes voies selon le coût, la vitesse de résultat et le contrôle, puis expliquer clairement pourquoi vous choisissez celle-ci et ce que renoncer à celle-là vous coûte.

Comment je répondrais : je pars toujours de la solution la plus légère et je monte en charge ; si le prompting résout le problème, je ne toucherai jamais au fine-tuning. Parce que le prompting se modifie le plus vite, coûte le moins cher, et si ça ne marche pas aujourd’hui je peux l’ajuster demain ; le RAG convient au cas « la réponse doit s’appuyer sur mes propres documents et pouvoir être mise à jour à tout moment » ; le fine-tuning est le plus lourd — l’entraînement coûte de l’argent, exige des données, et chaque modification prend du temps. Je n’y touche que quand « j’ai essayé les deux premiers, l’effet reste vraiment insuffisant, et cette capacité vaut la peine que j’y mette ce coût ».

L’essentiel, c’est la dernière partie — vous devez pouvoir dire ce que chaque voie fait renoncer. Choisir le prompting, c’est renoncer à la stabilité (la même formulation marche aujourd’hui, se plante demain) ; choisir le fine-tuning, c’est renoncer à la flexibilité (pour changer un comportement, il faut réentraîner). Savoir exposer clairement « j’ai choisi A, le prix c’est de perdre B, mais sur ce besoin ce prix en vaut la peine », et cette question est notée au maximum, même si vous ne savez pas écrire une seule ligne de code de modèle.

La réponse qui fait le plus souvent trébucher : lâcher d’entrée « là forcément du fine-tuning, c’est le plus efficace ». Quelqu’un qui réclame d’emblée la solution la plus lourde, le recruteur va supposer par défaut qu’il ne comprend rien aux coûts, et qu’il n’a jamais eu à se ronger les sangs pour le budget d’un vrai projet.

3. « Racontez-moi une fois où vous avez décidé de NE PAS utiliser l’IA. »

Cette question est particulièrement vicieuse, mais elle filtre remarquablement bien. Ces deux dernières années, tout le monde crie « IA » à tous les vents ; si un product manager n’a jamais, pas une seule fois, dit de lui-même « ici, on ne devrait pas utiliser l’IA », alors il court probablement après la tendance, il ne fait pas du produit.

Elle teste ceci : l’IA, c’est une fin pour vous, ou un outil ? Le recruteur veut s’assurer que vous n’irez pas caser de force une fonction IA là où elle est parfaitement inutile, juste parce que « le boss veut de l’IA » ou parce que « ça raconte mieux pour lever des fonds ».

Comment je répondrais : je raconterais un cas concret — par exemple une fonction où, à l’époque, tout le monde voulait ajouter une « recommandation intelligente », et je l’ai bloquée. Parce que dans ce scénario l’utilisateur n’avait que quelques options fixes ; une règle codée en dur était plus rapide, plus juste et sans erreur, alors qu’y coller de force un modèle, c’était lent, cher, et ça recommandait de travers de temps en temps — de l’IA pour l’IA, purement. Au final on a résolu ça avec le plus bête des if-else, et je considère que c’est l’une des décisions les plus justes que j’ai prises cette année-là.

Avoir une histoire concrète du type « j’ai refusé l’IA » vaut plus que de dérouler le RAG avec des mots à faire pleuvoir les étoiles. Parce qu’elle prouve ce que le recruteur veut le plus, et qu’il est le plus difficile à tester : vous avez du jugement, l’IA ne vous commande pas, c’est vous qui l’utilisez.

La réponse qui fait le plus souvent trébucher : répondre « je ne vois pas de cas de ce genre, je pense que l’IA améliore l’expérience à peu près partout ». Cette seule phrase vous range dans la catégorie « croyant de l’IA » — et aucune équipe mûre ne veut d’un product manager incapable de distinguer les moments où il ne faut pas utiliser l’IA.

4. « Le coût et la latence, comment les arbitrez-vous ? »

Il y a quelques années, on prenait ça pour un problème d’ingénierie — combien de tokens on dépense, si la réponse est lente ou non, c’était au backend de s’en soucier. Mais la norme a changé en 2026 : le coût et la latence sont désormais posés sur le tableau de bord du PM IA lui-même, à côté de la qualité et de l’expérience, et doivent être arbitrés explicitement au moment de faire la roadmap.

Elle teste ceci : savez-vous qu’une fonction IA brûle du vrai argent à chaque appel, et qu’une seconde de plus peut vous faire perdre une partie de vos utilisateurs ? Un logiciel classique, une fois écrit, un utilisateur de plus ne coûte quasiment rien de plus ; l’IA, non : chaque appel dépense de l’argent, plus on l’utilise plus ça brûle. Un product manager qui ne regarde pas ce compte va livrer une fonction à l’expérience superbe, mais que l’entreprise ne peut pas se permettre d’entretenir.

Comment je répondrais : je le traite comme un arbitrage explicite à trois — qualité, coût, vitesse — dont il est généralement impossible d’avoir les trois en même temps. Je demande sur quoi cette fonction gagne vraiment : si c’est sur « répondre juste », alors je l’autorise à être un peu plus lente, un peu plus chère, avec un modèle plus puissant ; si c’est sur « pouvoir s’en servir sur le pouce », alors je choisis peut-être un petit modèle bon marché et rapide, en sacrifiant un peu de qualité pour gagner en temps de réponse et en coût. L’important, c’est que je sache ce que j’échange contre quoi, au lieu de prendre par défaut, à tous les coups, le modèle le plus puissant et le plus cher.

La réponse qui fait le plus souvent trébucher : « ça, on le confie à la technique, ils optimiseront. » Renvoyer le coût et la latence à l’ingénierie — c’est exactement la mauvaise réponse que le recruteur attend, et dès que vous la sortez, l’étiquette « ce type ne comprend pas le compte d’un produit IA » vous est collée dessus.

5. « Pourquoi voulez-vous être PM IA ? »

Ça ressemble à une question d’ouverture de politesse, mais c’est en réalité un test d’honnêteté.

Elle teste ceci : avez-vous vraiment mis les mains dedans, ou avez-vous été attiré par la tendance et le salaire, prêt à réciter un laïus ? Parce que chaque relance technique qui suit va vérifier si ce « pourquoi » est vrai.

Comment je répondrais : je ne dirais pas « parce que l’IA est l’avenir, c’est le sens de l’histoire » — ce genre de banalité correcte, le recruteur l’entend vingt fois par jour, autant ne rien dire. Je raconterais une petite chose concrète : la première fois où j’ai réussi, avec l’IA, à faire exister en un après-midi un truc que je ruminais depuis longtemps et que je ne savais pas coder moi-même — un truc réel, sur lequel on pouvait cliquer —, ce choc du « en fait, une seule phrase de ma part et ça devient réel ». Une vraie première fois, concrète, un peu maladroite, sera toujours plus convaincante qu’un grand jugement correct.

La réponse qui fait le plus souvent trébucher : réciter les tendances du secteur, réciter les grands mots. Plus vous formulez les choses en grand et en correct, plus le recruteur est certain que vous n’avez jamais rien fait pour de vrai — parce que quelqu’un qui a vraiment fait, dès qu’il ouvre la bouche, parle de choses concrètes, pas de beaux jugements.

N’oubliez pas : le vrai examen est dans les relances

Chacune des questions ci-dessus, avoir répondu au premier tour ne suffit pas. Là où un entretien de PM IA montre vraiment ce que vous valez, c’est ce petit « et ensuite ? » que le recruteur laisse tomber, l’air de rien, juste après.

Vous dites « cette fonction, à 80 % de précision, j’ose la lancer », il relance : « Et concrètement, comment rattrapez-vous les 20 % ? » « Et si, une fois en ligne, vous constatez qu’en réalité c’est seulement 70 %, vous faites quoi ? » Vous dites « j’ai choisi le prompting plutôt que le fine-tuning », il relance : « Et si, quoi que vous ajustiez dans le prompting, l’effet reste bloqué à 60 %, à quel moment changerez-vous d’avis pour passer au fine-tuning ? Où tracez-vous cette ligne ? »

Il ne cherche pas à vous piéger, il cherche à confirmer : votre belle conclusion, l’avez-vous pensée, ou récitée ? Ce qui a été récité se démasque en deux relances — parce qu’une réponse apprise par cœur n’a pas de niveau suivant, vous n’avez qu’une conclusion isolée, et vous ne savez pas répondre à « si les conditions changent, comment je m’adapte ». Ce qui a été pensé, on peut le relancer autant qu’on veut, il y a toujours de quoi discuter, parce que vous avez réellement, dans votre tête, parcouru cette voie jusqu’au bout.

Alors quand vous vous préparez, ne préparez pas seulement les réponses, posez-vous une fois de plus la question « et ensuite ? » : si cette décision se révèle fausse, comment je répare ; si les conditions changent, à quel moment je change d’avis ; au nom de quoi je trace cette ligne. Faites vous-même le tour des relances d’abord, et le jour de l’entretien, ce « et ensuite ? » cessera d’être un obstacle pour devenir l’occasion de montrer ce que vous valez vraiment.

Au fond, c’est la même chose qui est testée

Reliez ces 5 questions entre elles, et vous verrez que ce que le recruteur pèse et repèse, c’est en réalité la même chose : avez-vous en main une histoire concrète — une vraie décision, un vrai arbitrage, et de préférence avec un chiffre ?

À quelle précision vous osez lancer, pourquoi vous avez choisi le prompting plutôt que le fine-tuning, quelle fois vous avez bloqué une fonction IA, si vous avez échangé de la qualité contre du coût ou du coût contre de la vitesse, ce qui vous a fait le choc la première fois que l’IA vous a bluffé — ces cinq questions, ceux qui y répondent bien parlent tous de choses qu’ils ont vraiment faites, ceux qui y répondent mal récitent tous des définitions et des tendances. Les histoires creuses perdent l’offre, les histoires concrètes décrochent l’offre — et sur le poste de PM IA, cette phrase est plus impitoyable que sur n’importe quel autre.

Donc si vous préparez ce genre d’entretien, mon conseil n’est pas d’aller réviser une banque de questions. C’est de retourner déterrer, une par une, les choses liées à l’IA que vous avez vraiment faites, et pour chacune de réfléchir clairement : quelle était la décision à l’époque, à quoi vous avez renoncé, quel a été le résultat, y a-t-il un chiffre. Réunissez cinq ou six histoires comme celles-là, et quelle que soit la manière dont on retourne ces questions, vous aurez de la vraie matière à raconter.

Je continue moi-même à ruminer une chose, que je vous lance au passage : quand l’IA fait tomber si bas le seuil pour « faire exister un truc », ces questions d’entretien du type « qu’avez-vous fait ? » deviendront de plus en plus faciles à répondre — parce que tout le monde pourra fabriquer quelque chose. Alors, à ce moment-là, quelle deviendra la question qui départage vraiment les gens ? Je parie qu’elle ira vers « qu’avez-vous choisi de ne pas faire, et pourquoi ». Mais ce n’est qu’une supposition de ma part, je n’ai pas encore vu la réponse.