Product Manager IA : faut-il savoir coder ?

Une question presque toujours mal posée

« Faut-il savoir coder ? » suppose une réponse binaire à une réalité continue. Entre le Product Manager qui ne sait pas ce qu'est un token et celui qui pousse lui-même un prototype en production, il existe une dizaine de positions intermédiaires, et la plupart des postes se jouent au milieu. La question utile est différente : quelle profondeur de compréhension permet de prendre de bonnes décisions produit sur un système dont le comportement n'est pas déterministe ?

Le déplacement est important. Sur un produit classique, un PM peut raisonner en règles : telle action déclenche tel écran, tel calcul donne tel résultat. Sur un produit IA, le système produit une distribution de comportements. Deux formulations proches donnent deux réponses différentes ; la même formulation peut être excellente sur un cas et médiocre sur le suivant. Les décisions de périmètre, de garde-fous et de mesure deviennent alors des décisions produit à part entière, et elles se prennent avec un vocabulaire que le PM doit maîtriser.

Coder est une compétence. Comprendre un système probabiliste, ses données et ses modes d'échec en est une autre. Les deux se recoupent partiellement, mais c'est la seconde qui conditionne la qualité des décisions produit.

Niveau 1 — indispensable, même sans écrire une ligne de code

Ce socle est non négociable, quel que soit le contexte. Il ne s'agit pas de savoir comment un modèle est entraîné, mais de savoir ce qu'il fait, ce qu'il ne fait pas, et à quoi ressemble un échec.

Ce que le système peut et ne peut pas faire

• Le comportement est probabiliste : la même entrée peut produire des sorties différentes, et une réponse plausible n'est pas une réponse vérifiée.
• Un modèle de langage travaille sur le contexte qu'on lui fournit ; ce qui n'est pas dans le contexte n'existe pas pour lui, sauf à ressortir de sa mémoire d'entraînement, sans garantie de fraîcheur.
• Les hallucinations ne sont pas un bug ponctuel à corriger : elles sont la contrepartie d'un système qui produit du texte plausible. On les réduit et on les encadre, on ne les supprime pas par décision managériale.
• La qualité dépend d'abord des données accessibles : leur exhaustivité, leur fraîcheur, leurs droits d'accès et leur structure.
• Sans évaluation, aucune affirmation sur la qualité n'a de valeur. « Ça marche bien » n'est pas un résultat.

Les contraintes qui deviennent des arbitrages produit

• La latence : un système qui répond en quelques secondes ne s'insère pas dans les mêmes parcours qu'un système qui répond instantanément. C'est un choix d'expérience, pas un détail d'implémentation.
• Le coût : chaque appel a un prix qui varie avec la longueur du contexte et le modèle retenu. Une fonctionnalité peut être excellente et économiquement intenable à volume réel.
• La confidentialité et les droits : ce qui sort de l'organisation, ce qui est conservé, ce qu'un utilisateur a le droit de voir à travers l'assistant. Un assistant ne doit jamais élargir les droits de celui qui l'utilise.
• Les limites d'un prototype : une démonstration prouve qu'un comportement est possible sur des cas choisis. Elle ne dit rien de la stabilité sur des cas non choisis, ni du coût, ni de la maintenabilité.

Un PM qui maîtrise ce niveau prend déjà de meilleures décisions que beaucoup de profils plus techniques : il sait quand une idée est infaisable dans les contraintes du produit, et il sait pourquoi.

Niveau 2 — fortement utile : la capacité à vérifier soi-même

Le deuxième niveau ne consiste toujours pas à écrire du code de production. Il consiste à réduire la boucle entre une hypothèse et une observation. Un PM capable de tester lui-même une intuition en une heure ne consomme pas le temps d'un ingénieur pour trancher une question de faisabilité grossière — et il arrive en discussion avec des observations plutôt qu'avec des opinions.

• Tester rapidement une hypothèse : soumettre au système une vingtaine de cas réels et regarder ce qui casse, plutôt que de raisonner sur trois exemples flatteurs.
• Comprendre ce qu'est une API : ce qu'on envoie, ce qu'on reçoit, ce que coûte l'appel, ce qui se passe en cas d'erreur ou de dépassement de quota.
• Lire une documentation technique sans en avoir peur : limites de contexte, formats de sortie, options de configuration.
• Manipuler un outil de prototypage — feuille de calcul connectée, atelier de prompts, outil no-code, notebook partagé — pour produire une maquette exploitable.
• Comprendre la forme générale d'un workflow : appel simple, récupération d'information puis génération, ou enchaînement d'actions avec outils. Savoir de quoi on parle suffit ; savoir l'implémenter n'est pas demandé.
• Dialoguer précisément avec Engineering et Data : nommer correctement les objets, distinguer un problème de récupération d'information d'un problème de formulation, poser une question qui n'oblige pas l'interlocuteur à reformuler la demande.

Ce niveau produit un effet secondaire net : il rend crédible. Une équipe technique accorde une attention différente à un interlocuteur qui a déjà regardé les données et testé le comportement avant d'ouvrir la discussion.

Niveau 3 — écrire du code : un bonus dépendant du contexte

Savoir écrire un peu de Python ou de JavaScript, appeler une API, assembler un petit prototype : c'est un avantage réel, et il serait malhonnête de le minimiser. Mais c'est un avantage contextuel, pas une condition d'accès au métier. Il pèse lourd dans certaines configurations et presque rien dans d'autres.

• Startup ou produit très jeune : personne n'est disponible pour valider une intuition ; un PM autonome sur un prototype fait gagner des semaines.
• Équipe réduite : la frontière entre les rôles est floue par nécessité, et la capacité à contribuer techniquement élargit ce que l'équipe peut explorer.
• Phase de discovery intensive : quand la question porte sur ce que le modèle sait faire, l'expérimentation directe est souvent plus rapide qu'une spécification.
• Produit très technique, vendu à des développeurs ou à des équipes data : la crédibilité auprès des utilisateurs eux-mêmes passe par une compréhension de première main.

À l'inverse, dans une organisation dotée d'une équipe AI Engineering constituée, d'un backlog fourni et d'enjeux forts de conformité ou de coordination, la valeur marginale d'un PM qui code est faible devant la valeur d'un PM qui sait cadrer, prioriser et arbitrer. Y voir une hiérarchie universelle est une erreur d'analyse.

Scénario : deux Product Managers, deux résultats

Scénario pédagogique, volontairement simplifié. Une entreprise veut aider ses conseillers à retrouver l'information dans une documentation interne volumineuse. Deux PM abordent le sujet différemment.

Le second n'est pas supérieur parce qu'il code moins. Il l'est parce que sa compréhension technique était suffisante pour poser les bonnes contraintes, et que son énergie est allée au problème plutôt qu'à la démonstration. Le cas idéal, évidemment, combine les deux : un PM qui prototype vite et cadre bien. La compétence rare est la seconde.

PM et PO : deux questions techniques différentes

La confusion entre les deux rôles brouille souvent le débat sur la technicité. Le Product Owner travaille au niveau de la fonctionnalité : spécifier un comportement attendu, définir des critères évaluables, arbitrer ce qui est acceptable et ce qui ne l'est pas, suivre la qualité dans la durée. Sa profondeur technique sert la précision de la spécification.

Le Product Manager travaille en amont et plus large : quel problème mérite d'être traité, pour quel utilisateur, avec quelle valeur, dans quelle séquence, et à quel coût d'opportunité. Sa profondeur technique sert la qualité du jugement : distinguer une piste faisable d'une piste séduisante mais coûteuse, savoir ce qu'un modèle rendra probablement possible dans le périmètre du produit, et éviter d'engager une équipe sur une promesse que le système ne pourra pas tenir.

Une organisation où le PM ne se pose que la question de la valeur et le PO que la question de la spécification fonctionne. Une organisation où aucun des deux ne comprend le comportement du système livre des fonctionnalités que personne ne sait évaluer.

Progresser sans se tromper d'objectif

La trajectoire la plus efficace ne consiste pas à suivre un cours de programmation, mais à construire une compréhension utilisable, dans cet ordre.

1. 1

   Observer le système sur des cas réels

   Rassembler des cas issus du terrain — pas des exemples inventés — et regarder où le comportement se dégrade. C'est la source la plus rapide de compréhension technique concrète.

2. 2

   Nommer correctement ce que l'on observe

   Distinguer une mauvaise récupération d'information d'une mauvaise formulation, une limite de contexte d'un manque de données, une erreur de format d'une erreur de fond. Cette précision de vocabulaire change immédiatement la qualité des échanges avec l'équipe.

3. 3

   Apprendre à évaluer avant d'apprendre à construire

   Savoir constituer un jeu de cas de test métier, définir ce que « bonne réponse » signifie et comparer deux versions vaut plus, pour un PM, que savoir appeler une API.

4. 4

   Prototyper, si le contexte le justifie

   Ajouter la capacité à monter un prototype quand l'organisation en tire un bénéfice réel : équipe réduite, discovery intensive, produit technique. Sinon, cette énergie est mieux investie ailleurs.

Cette progression a un avantage : chaque étape est immédiatement utile, y compris pour un PM qui n'écrira jamais de code. Et elle évite le piège symétrique — un PM qui a appris à coder mais reste incapable de dire, devant une réponse du système, si elle est acceptable pour le métier.

• AI Product
• Culture IA
• Cadrage des cas d'usage