Entretien pour un rôle transverse en IA : produit, MOA, UX

Un entretien pour un rôle produit, MOA ou design sur un sujet IA se joue rarement sur les connaissances techniques, et pourtant c'est là que la préparation se concentre le plus souvent. Le candidat révise le vocabulaire, apprend la différence entre fine-tuning et RAG, puis se retrouve en difficulté sur une question de cadrage qu'il aurait su traiter sur n'importe quel autre projet.

L'erreur n'est pas de connaître le vocabulaire, elle est utile. L'erreur est de croire que l'évaluation porte sur lui. Sur ces rôles, l'entretien cherche à savoir si vous savez décider dans un contexte où le système est probabiliste, où la qualité se mesure au lieu de se constater, et où l'échec doit être prévu dès la conception.

Ce que l'entretien évalue réellement

Quatre capacités reviennent, quelle que soit l'entreprise. Elles ne sont presque jamais annoncées comme telles, mais chaque question sérieuse en teste au moins une.

1. 1

   Cadrer un problème

   1

   Savoir formuler le besoin avant la solution, et reconnaître un cas où l'IA n'est pas le bon outil. Une réponse qui part directement sur une architecture disqualifie plus souvent qu'elle ne rassure.

2. 2

   Raisonner en incertitude

   2

   Accepter qu'un système puisse se tromper, et concevoir en conséquence : quelle erreur est tolérable, laquelle ne l'est pas, qui vérifie, à quel moment.

3. 3

   Définir ce que « bon » veut dire

   3

   Traduire une attente métier en critère observable. C'est la capacité la plus discriminante, et celle qui manque le plus souvent.

4. 4

   Travailler avec des ingénieurs

   4

   Poser des questions utiles, comprendre une contrainte sans la contester à l'aveugle, et arbitrer sans prétendre décider à la place de l'équipe technique.

Aucune de ces quatre capacités n'exige d'écrire du code. Toutes exigent d'avoir réfléchi à un système qui ne donne pas toujours la bonne réponse.

Le niveau technique attendu, et sa limite

On attend de vous que vous compreniez les grandes familles d'approches, ce qu'elles impliquent en données, en coût et en délai, et ce qu'elles ne résolvent pas. On n'attend pas que vous choisissiez une architecture ni que vous discutiez d'implémentation.

Les questions qui reviennent, et ce qu'elles cherchent

• « Comment décideriez-vous si ce cas d'usage mérite de l'IA ? » — on teste votre capacité à dire non, et à nommer une alternative plus simple.
• « Comment sauriez-vous que ça marche ? » — on attend un critère observable, une population de cas et un seuil, pas un ressenti.
• « Que faites-vous des erreurs du système ? » — on teste si vous concevez un parcours qui suppose l'erreur plutôt qu'un parcours qui l'ignore.
• « Comment priorisez-vous entre qualité et délai ? » — on cherche un arbitrage assumé, avec la conséquence acceptée nommée.
• « Comment travaillez-vous avec les ingénieurs ? » — on écoute surtout comment vous parlez d'un désaccord passé.
• « Qu'est-ce qui vous a surpris sur un projet IA ? » — on vérifie que vous en avez réellement vécu un, à n'importe quelle échelle.

Ce que l'entretien cherche chez un profil produit ou PO

Sur un produit IA, l'entretien produit ne porte pas sur l'implémentation : il porte sur la manière dont vous choisissez un cas d'usage, dont vous définissez ce que « bon » veut dire, et dont vous décidez avec une qualité qui n'est jamais garantie. La question la plus discriminante reste celle du renoncement : savoir dire qu'un cas ne mérite pas d'IA, ou qu'une règle métier suffirait, rassure davantage qu'une feuille de route ambitieuse.

• Le choix du cas d'usage : quel problème utilisateur ou métier existe déjà, et pourquoi celui-là plutôt qu'un autre.
• La valeur attendue, formulée autrement que par « gagner du temps » : ce qui change concrètement pour la personne qui fait le travail aujourd'hui.
• La définition de la qualité : ce qu'est une bonne réponse, qui en juge, et à partir de quel seuil la fonctionnalité devient utile.
• Les métriques adaptées au cas, plutôt qu'une exactitude globale empruntée à un autre contexte.
• La priorisation et l'arbitrage entre qualité, coût et latence, avec le compromis assumé et sa raison.
• Les dépendances avec les équipes data et engineering : ce que vous devez leur demander, et à quel moment.
• La décision de lancer, de restreindre le périmètre ou d'arrêter, et les signaux qui la déclenchent.
• La capacité à conclure que l'IA n'est pas la bonne solution, en nommant l'alternative.

Personne n'attend d'un profil produit qu'il choisisse une architecture. On attend qu'il sache cadrer, prioriser et trancher dans un contexte probabiliste, puis expliquer ce compromis à une équipe technique.

Ce que l'entretien cherche chez un profil MOA, BA ou conseil

L'entretien BA se joue sur la décomposition. Reformuler « le métier veut un chatbot » n'est pas une analyse : c'est la reprise d'une solution déjà choisie. Ce qu'on observe, c'est votre capacité à remonter du besoin exprimé au processus réel, puis à redescendre vers des critères d'acceptation que quelqu'un pourra vérifier.

• Le processus existant : ce qui se passe aujourd'hui, étape par étape, avant toute idée de solution.
• Les acteurs : qui fait quoi, qui valide, qui subit l'erreur lorsqu'elle survient.
• Les données nécessaires, leur disponibilité réelle, leur fraîcheur et leur qualité connue.
• Les exceptions : les cas rares qui représentent souvent l'essentiel de la charge et la majorité des litiges.
• Les permissions : qui a le droit de voir quoi, et ce que cela implique lorsqu'un assistant restitue une information.
• Les dépendances et les risques, y compris ceux qui n'ont rien de technique : réglementation, sous-traitance, calendrier.
• Les critères d'acceptation, écrits de façon vérifiable, y compris pour les cas où le système doit refuser de répondre.
• L'intégration au fonctionnement réel et l'adoption : à quel moment de la journée l'outil est utilisé, et par qui.

La chaîne attendue est toujours la même : problème → processus → acteurs → données → règles → exceptions → résultat attendu → critères d'acceptation. Elle ne recouvre pas les responsabilités de l'AI Engineer, et ce n'est pas son rôle.

Ce que l'entretien cherche chez un profil UX, research ou design

Concevoir une expérience IA ne consiste pas à ajouter une conversation dans l'interface. Le système peut se tromper de manière plausible, produire une réponse fausse mais convaincante, et varier d'une exécution à l'autre. L'entretien cherche à voir comment vous concevez pour cette instabilité plutôt qu'en la supposant absente.

• Le modèle mental de l'utilisateur : ce qu'il croit que le système peut faire, et l'écart avec ce qu'il fait vraiment.
• La confiance appropriée : ni méfiance qui fait abandonner l'outil, ni confiance aveugle dans une réponse fausse.
• La représentation de l'incertitude, lorsqu'elle aide la décision plutôt qu'elle ne décore l'écran.
• Le traitement des erreurs plausibles : ce que voit l'utilisateur quand la réponse est fluide et incorrecte.
• Les fallbacks : ce qui se passe quand le système ne sait pas, et pourquoi c'est un moment de conception à part entière.
• La correction et la reprise : pouvoir signaler, corriger, revenir en arrière ou repasser par un humain.
• Le niveau de contrôle laissé à l'utilisateur, et les points où une confirmation explicite est nécessaire.
• La transparence utile : ce qui aide réellement à juger une réponse, plutôt qu'une explication décorative.
• La recherche utilisateur avec un système non déterministe : observer des sessions réelles, comparer des variantes, mesurer la confiance et l'usage plutôt que la satisfaction déclarée.

Le human-in-the-loop n'est pas un correctif ajouté à la fin. C'est une décision de conception qui détermine où l'utilisateur reprend la main, à quel coût d'attention, et ce que le système fait de cette correction.

Un cas transversal, pour situer les trois perspectives

Le scénario qui suit est fictif et pédagogique ; il ne décrit aucune entreprise ni aucun projet réel. Une organisation souhaite ajouter un assistant IA à un processus interne : les collaborateurs pourraient y chercher des informations dispersées dans plusieurs référentiels documentaires et obtenir de l'aide pour préparer certaines tâches métier récurrentes. Les documents ne sont pas tous à jour, tout le monde n'a pas accès aux mêmes ressources, et une partie des questions posées portera sur des cas particuliers rarement documentés.

1. 1

   Produit / PO

   valeur

   Quel problème mérite réellement d'être résolu, pour quelle population et sur quel périmètre commencer. Comment décider que le résultat est suffisamment utile pour être élargi, et quels arbitrages accepter entre exhaustivité, coût et délai de réponse.

2. 2

   MOA / BA / conseil

   processus

   Quel processus est modifié, qui fait quoi aujourd'hui, quelles données et quelles règles interviennent, quelles permissions doivent être respectées, quelles exceptions doivent rester traitées par une personne, et comment l'assistant s'insère dans le fonctionnement réel.

3. 3

   UX / research / design

   usage

   Comment l'utilisateur comprend ce que l'assistant peut et ne peut pas faire, ce qui se passe lorsqu'il se trompe, quand demander une confirmation, quand permettre une reprise humaine, et comment observer la confiance et l'usage réel plutôt que l'enthousiasme initial.

Les équipes engineering et data restent les partenaires du scénario : ce sont elles qui rendront exploitables la récupération documentaire, les droits d'accès et la fraîcheur des contenus. La qualité attendue d'un profil produit, MOA ou UX n'est pas de faire ce travail, mais de discuter ses contraintes sans se les approprier.

Relier le cas aux questions posées en entretien

Un même scénario permet de répondre à la plupart des questions attendues, à condition de dérouler un raisonnement plutôt que de réciter une réponse : hypothèses, questions que vous poseriez, arbitrages envisagés, puis décision assumée.

• « Quand ne choisiriez-vous pas l'IA ? » — lorsque les documents de référence sont peu nombreux et stables : un moteur de recherche et une mise à jour du référentiel coûtent moins cher et échouent de façon plus lisible.
• « Comment sauriez-vous si c'est assez bon ? » — en construisant un jeu de questions réelles issues du processus, en définissant ce qu'est une réponse acceptable avec les personnes qui font le travail, et en fixant le seuil avant le lancement.
• « Que faites-vous si les utilisateurs croient des réponses incorrectes ? » — traiter cela comme un problème de conception et de mesure : rendre la source visible, dégrader la présentation quand la réponse est faible, et observer les corrections plutôt que les avis.
• « Comment définiriez-vous avec engineering des critères évaluables ? » — en apportant les cas et la définition métier du résultat attendu, en laissant à l'équipe le choix de la méthode de mesure, et en convenant ensemble de ce qui bloque une mise en production.
• « Que faudrait-il observer après le lancement ? » — l'usage réel par population, les questions restées sans réponse, les corrections humaines, les écarts entre confiance affichée et exactitude, et ce que le processus a réellement changé.

Adosser vos réponses à un cas vécu

La réponse la plus solide n'est pas la plus générale : c'est celle qui s'appuie sur une situation réelle, décrite avec sa contrainte et sa décision. Un atelier de cadrage interne, un pilote abandonné, une évaluation manuelle sur cinquante cas suffisent, à condition d'être racontés honnêtement.

1. 1

   Le contexte

   situer

   Quel problème, pour qui, avec quelle contrainte réelle — délai, données, réglementation, adoption.

2. 2

   Votre rôle exact

   clarifier

   Ce que vous avez décidé vous-même, et ce que d'autres ont décidé. La précision sur ce point est un signal de fiabilité.

3. 3

   La difficulté

   assumer

   Ce qui n'a pas fonctionné du premier coup, et ce que cela a coûté.

4. 4

   La décision

   trancher

   Ce que vous avez arbitré, sur quelle base, et ce que vous avez accepté de perdre.

5. 5

   Ce que vous feriez autrement

   conclure

   Une réflexion, pas une autocritique de façade.

Trois pièges fréquents

Le premier est de parler du modèle plutôt que du problème : le détail technique remplace alors le raisonnement produit. Le deuxième est de promettre une mesure impossible, comme un taux d'exactitude sur un sujet où personne ne sait définir la bonne réponse. Le troisième est de présenter un projet collectif comme personnel : la question de suivi arrive presque toujours, et l'écart se voit immédiatement.

Dire « cette partie était portée par l'équipe data, mon apport était le cadrage et l'évaluation » ne réduit pas la valeur d'une réponse. C'est ce qui la rend vérifiable.

Les questions à poser en fin d'entretien

• Comment mesurez-vous aujourd'hui la qualité de ce qui est déjà en production ?
• Qui tranche quand la qualité perçue et la mesure divergent ?
• Quelle part du travail relève de l'exploration et quelle part de l'industrialisation ?
• Comment les rôles produit, MOA et UX se répartissent-ils les décisions avec les équipes engineering et data ?
• Quel cas d'usage a été abandonné récemment, et pourquoi ?

La dernière question est la plus informative. Une entreprise qui sait nommer un cas d'usage abandonné a un processus de décision ; une entreprise qui n'en a aucun n'a probablement pas encore rencontré la contrainte de la production.

• Entretien
• Produit IA
• Cadrage