L’IA transforme le métier de Product Manager. Vous l’avez déjà entendu cent fois. Ce que personne ne dit, c’est que la plupart des PM sont en train de l’utiliser de manière timide voire inopérante. J’ai la joie de travailler avec des responsables produit dans les organisations que j’accompagne. Et je constate que le niveau de maturité IA est très variable. Certains n’ont pas encore franchi le pas, d’autres sont déjà en pleine exploration, parfois un peu trop vite. Je vous livre ici une synthèse de toutes ces conversations, sous forme de dix erreurs que j’observe régulièrement sur le terrain. Pas pour pointer du doigt, mais pour partager ce qui marche, ce qui coince, et surtout ce qu’on peut faire différemment.
Mais de toutes ces erreurs, il y en a une qui me préoccupe vraiment. Une qui peut ruiner votre crédibilité de PM, mettre en péril votre produit, et décrédibiliser l’usage de l’IA dans votre organisation. C’est l’erreur n°5.
Les 5 erreurs en accès rapide
Erreur n°1 : ne pas se lancer dans l'IA
Beaucoup de Product Owners et de Product Managers n’ont pas encore démarré avec l’intelligence artificielle. Je comprends la prudence. Les outils d’IA demandent une évolution dans la façon de réfléchir, dans la manière d’accueillir un assistant, ou plutôt des assistants, pour démultiplier ses capacités de raisonnement. Et je ne parle même pas encore des agents autonomes qui arrivent.
Je pense notamment à ce PM responsable d’une dizaine de produits, complètement saturé sous la charge de travail. Il n’avait même pas le temps de se poser la question de comment ça marche. Il était dans le terrain, dans le quotidien, dans l’urgent permanent. Le déclic s’est produit lors d’une conversation où je lui ai dit : “Tiens, sur la priorisation, tu peux donner un fichier Excel à Claude, lui donner tes critères, et il peut te le faire.” Ça ne changera pas sa vie du jour au lendemain, ça lui fera juste gagner quelques minutes. Mais ces quelques minutes, répétées sur différentes tâches, finissent par créer de l’espace pour respirer.
Ce que je constate, c’est que le train de l’IA est en route. Ça prend du temps de créer de nouveaux réflexes, d’intégrer une nouvelle logique qui n’est pas évidente pour tout le monde. Il n’est jamais trop tard pour commencer, lancez-vous ! Un peu tous les jours. Pour se forger sa propre idée, développer sa boîte à outils personnelle, comprendre ce qui peut vraiment aider dans son quotidien de PM.
D’après ce que j’observe, il faut compter au minimum six mois pour arriver à une pratique mature. Et on passe tous par les mêmes étapes : d’abord l’émerveillement où on découvre ce que l’outil est capable de faire. Ensuite vient le vertige, celui de se voir dépassé par un outil. Puis on commence à se poser des questions, à repositionner l’IA au bon endroit, à se re-crédibiliser. Et enfin, on arrive à l’insérer de plus en plus, on crée des réflexes. Au début, on se concentre sur les tâches qui nous prennent vraiment la tête, puis on l’intègre à petite dose un peu partout.
Erreur n°2 : trop s'appuyer sur l'IA
C’est l’exact inverse de la première erreur, et pourtant elle est tout aussi fréquente. Devant les capacités extraordinaires de ces outils, on peut être tenté de tout déléguer. L’hyperadoption guette. Et c’est sans doute le plus gros risque : perdre le cap/le sens.
Je pense à moi-même sur ce point. Parce qu’en étant trop geek, on peut passer beaucoup de temps à explorer les potentiels. On discute avec Claude, on teste des trucs, on itère, et à la fin on ne sait plus pourquoi on est là. Il faut revenir à l’essentiel, se rappeler l’objectif de départ. Le volume de données générées est tellement important qu’il y a un moment où on arrive à une saturation de l’information. C’est à ce moment-là qu’on se rend compte du problème.
Les premières études le montrent, on perd nos capacités cognitives quand on s’appuie trop systématiquement sur l’IA. Un responsable de produit doit rester en lien avec la stratégie, en lien avec la maîtrise des idées, capable de s’adapter au marché. Une IA n’a aucune connaissance du contexte spécifique de votre produit, même si elle vous dépasse certainement dans les capacités d’analyse et de synthèse brutes.
Au final, c’est bien vous qui devez garder la décision. La gestion de produit reste une discipline stratégique. À ce titre, je ne recommande pas de déléguer la stratégie à une IA. Il est parfois bon de revenir à des actions manuelles, de rester en contact cognitif avec certains exercices. Je pense notamment aux interviews utilisateurs, à l’analyse d’entretiens. Ces moments où vous captez les nuances, les non-dits, les émotions. L’IA peut vous aider à traiter le volume, mais elle ne remplace pas votre présence attentive.
Erreur n°3 : confondre IA avec IA
Aujourd’hui, le terme IA est utilisé à tort et à travers sur toutes les plateformes, tous les supports marketing. On se retrouve avec un florilège de concepts qui se cachent tous derrière ce même acronyme : IA. Pour un Product Manager, il y a trois façons de voir l’IA, et il est essentiel de ne pas les mélanger.
J’ai eu plusieurs clients cette année où, dans la stratégie, c’était clairement écrit : “IA”. Quand je demande “Est-ce qu’on veut de l’IA partout ?“, on me répond “Oui“. “Pourquoi est-ce qu’on veut de l’IA ?” Personne ne sait vraiment. On a un problème : on est en train de dire que l’IA est une forme de grand virage à suivre, mais qui ne répond à rien de concret. On parle beaucoup de bulle IA en ce moment, ce n’est pas pour rien. Une technologie poussée n’a jamais répondu à un problème marché.
C’est pour ça que ces trois axes servent justement à clarifier les choses.
1. La première, c’est l’usage de l’IA pour améliorer sa productivité personnelle. C’est ce qu’on va regarder principalement dans cet article : comment utiliser ChatGPT, Claude, Gemini et autres pour mieux travailler au quotidien.
2. La deuxième, c’est mettre de l’IA dans son produit. Là, on change complètement de registre. Si on veut vraiment mettre de l’IA dans les produits, ce n’est pas la même démarche. Il faut une démarche d’inspection, d’analyse, peut-être des ateliers de créativité, aller à la rencontre des utilisateurs pour trouver des besoins réels. Cette démarche nécessite aussi de travailler avec des gens de la technique, de la production, et ça implique des réflexions sur le business model. C’est passionnant, mais ça n’a rien à voir avec l’usage personnel d’un assistant IA.
3. La troisième approche, c’est utiliser une fonctionnalité IA dans un produit existant qui n’est pas une IA. Par exemple, Miro propose aujourd’hui Miro AI, Canva propose Canva AI. Ce sont des briques boostées par l’IA, mais vous n’avez pas la maîtrise de ce qui se passe derrière. Vous êtes utilisateur d’une fonctionnalité, pas concepteur d’une solution IA.
4. On pourrait aller jusqu’à créer une catégorie spéciale pour les outils de vibe coding comme Lovable, Replit, Bolt, etc. Ce sont des accélérateurs de prototype fabuleux … si on ne leur en demande pas trop
Derrière chacun de ces trois usages, vous n’avez pas les mêmes attentes, pas les mêmes enjeux, pas les mêmes responsabilités. En tant que PM qui veut améliorer sa productivité, la question est simple : où est-ce que je perds du temps ? Où est-ce que je ne fonctionne pas assez bien ? Quels outils peuvent m’aider à chaque étape, du Discovery à la livraison ?
Erreur n°4 : ne pas anticiper le volume de data à analyser
Avec l’IA, il devient très facile de couvrir des zones qu’on faisait mal avant. Par exemple, l’analyse des tickets support, l’exploitation des enregistrements du service client, la compréhension fine des besoins utilisateurs. On peut enfin exploiter toutes ces sources pour avoir une vision plus complète.
La contrepartie qu’on anticipe rarement, c’est que ça génère beaucoup de données (vraiment beaucoup). On pourrait se dire qu’on va les analyser avec l’IA, et c’est vrai en partie. Néanmoins, il faudra quand même les regarder manuellement, au moins pour s’assurer que l’IA les analyse exactement comme vous l’entendez. Et surtout, il va falloir recroiser ces données avec d’autres sources, avec votre connaissance du terrain, avec les retours d’autres équipes.
Ce qu’on observe, c’est une surcharge informationnelle. Elle est inévitable si on veut vraiment exploiter le potentiel de l’IA. Mais il faut la prévoir, l’organiser, se donner le temps de digérer tout ça. Sinon, on se retrouve avec une masse de synthèses IA qu’on n’a jamais le temps de lire vraiment, et au final, on perd le fil.
Erreur n°5 : déléguer à l'IA sans garder l'humain dans la boucle
C’est sans doute l’erreur la plus critique, celle qui peut vraiment ruiner votre travail. Il s’agit ici de déléguer certaines tâches avec un niveau de confiance qui me paraît trop précoce aujourd’hui. Les systèmes d’IA ne sont pas des systèmes déterministes. C’est-à-dire que A + B ne fait pas toujours C. Parfois c’est C’, parfois D, parfois E. Cette variabilité, ce non-déterminisme, peut nous amener à détecter des erreurs fournies par l’IA bien trop tard.
Nous devons rester des experts des données entrantes et de l’évaluation de la qualité des données sortantes. Sans ça, on va faire du “slop“, c’est-à-dire du contenu généré en masse, sans valeur, sans âme, sans contrôle qualité.
Si je demande à l’IA de rédiger des synthèses, des documents, des présentations, elle va le faire. Mais la sémantique, le phrasé, la singularité, tous ces éléments qui font votre expertise de PM, l’IA ne peut pas les connaître. Même si vous faites d’excellents prompts, même si vous avez paramétré le contexte, il manquera toujours cette petite chose qui fait que c’est vous.
Le principe qui domine encore (et pour un bon moment encore), c’est de garder l’humain dans la boucle. Toujours. Vous gardez la responsabilité de vérifier que ce qui sort a du sens par rapport à votre stratégie, votre feuille de route, votre modèle de développement.
Du côté du prompt : 5 erreurs pratiques
Ces cinq premières erreurs sont d’ordre stratégique. Mais même quand on a compris tout ça, il reste le quotidien : comment on utilise vraiment ces outils au jour le jour ? C’est là que j’observe cinq autres erreurs, plus pratiques mais tout aussi coûteuses.
Demander "Écris-moi un PRD" sans donner de contexte
Les outils d’IA aujourd’hui sont conçus de telle manière qu’ils auront toujours une réponse à n’importe quelle question. Si vous demandez “Écris-moi un PRD”, vous aurez forcément un résultat. Un résultat qui pourra même être impressionnant au regard du peu d’informations que vous aurez données.
C’est un peu comme quand on va voir une voyante : elle est capable de nous impressionner alors qu’en fait, ce ne sont que des généralités. L’IA fait pareil. Elle va vous sortir un document structuré, avec des sections qui ressemblent à un PRD, mais qui ne contiendra rien de spécifique à votre contexte, votre produit, vos utilisateurs.
Il est essentiel pour un PM de structurer son prompt, de lui donner énormément de contexte. Attention, toujours en gardant en tête l’anonymisation des données et en s’interrogeant sur la confidentialité de ce qu’on injecte, sauf si on utilise un modèle déployé dans un bac à sable sécurisé.
Ce qu’il faut faire, c’est donner du contexte structuré : quel est le problème utilisateur ? Quelles sont les contraintes techniques ? Quel est l’objectif business ? Qui sont les parties prenantes ? Plus vous donnez d’informations précises, plus l’IA pourra vous aider.
Ne pas itérer sur les prompts
Il est très difficile de savoir bien prompter du premier coup. D’ailleurs, la plupart des posts qu’on voit sur les réseaux sociaux font croire qu’il existe des prompts magiques. Des formules parfaites qu’il suffirait de copier-coller. Mais on n’a jamais accès à comment ces prompts ont été élaborés, testés, ajustés.
Je vais être direct sur ce point : les prompts magiques sont une arnaque. Souvent, ils sont élaborés par des personnes qui sont juste contentes de la réponse qu’elles ont reçue, sans vraiment comprendre le fonctionnement des LLM, sans comprendre ce qu’est un réseau de neurones. On utilise des prompts comme si c’était une réponse à tout, mais ça ne peut pas fonctionner comme ça.
Ce qui est très drôle, c’est de voir combien il y a de véritables experts en prompting, c’est-à-dire des gens qui connaissent vraiment le fonctionnement technique des modèles et des LLM. Il y en a très très peu. Et sur les réseaux sociaux, il y en a encore moins. Donc apprenons à faire nos propres critiques par rapport au résultat que ça va produire.
Ici, il faut bien comprendre que le prompt engineering (c’est-à-dire l’ingénierie du prompt), peut faire appel à énormément de techniques. La plus simple et la plus accessible pour tous, c’est d’itérer. Vous pouvez partir d’un prompt aussi simple que “Écris-moi un PRD”, constater le résultat, puis rajouter les éléments qui manquent. C’est appliquer les principes de l’Agilité à l’élaboration même du prompt.
Comme de toute façon vous travaillez dans une fenêtre de contexte, le fait d’itérer contribuera à orienter les nouvelles réponses du modèle. Il faut être très à l’aise avec ça et sortir de cette injonction d’arriver à prompter correctement dès le début. Si vous pouvez le faire, c’est très bien, mais souvent c’est trop compliqué. Et une autre façon de faire des prompts plus élaborés, c’est tout simplement de faire des prompts vocaux. Ça permet une spontanéité, une richesse de contexte qui est difficile à obtenir à l’écrit.
Le prompt engineering, c’est une conversation, pas une formule magique.
Utiliser toujours le même outil
À force d’utiliser ChatGPT, Claude, Gemini ou Perplexity, on se rend compte qu’ils ont leurs qualités et leurs faiblesses qui varient en fonction des évolutions et des mises à jour. Ce qui était vrai il y a trois mois ne l’est plus forcément aujourd’hui.
Il faut garder en tête que ces modèles ne sont pas entraînés de la même manière. Leurs subtilités font qu’ils ne fonctionnent pas de la même façon et vont pouvoir amener des résultats différents. Il y a un intérêt à jongler avec plusieurs outils, un peu comme si vous aviez une équipe et que vous vous appuyiez sur plusieurs assistants, plusieurs conseillers.
ChatGPT n’est pas égal à Claude, qui n’est pas égal à Perplexity. Chacun a ses forces. Certains sont meilleurs pour la synthèse, d’autres pour la créativité, d’autres encore pour la recherche d’informations récentes. Apprenez à connaître leurs personnalités, si on peut dire, et utilisez-les en fonction de ce dont vous avez besoin.
Copier-coller les sorties sans réfléchir
On l’a déjà dit, mais ça mérite d’être répété : l’IA reste un assistant. Pas un remplaçant. Garder l’humain dans la boucle, ça veut dire rester présent au démarrage, dans l’injection du contexte, et rester présent dans l’analyse du résultat.
Les meilleurs exemples sont tous les projets de déploiement de chatbots. Ils sont très séduisants sur le papier. Mais quand on voit ce que les chatbots sont capables de sortir parfois, on comprend pourquoi énormément de boîtes ont fait machine arrière. Parce que les résultats ne sont pas satisfaisants et qu’on ne peut pas déléguer ça dans la relation client sans supervision.
C’est la même chose si je demande à l’IA de m’écrire un PRD. J’ai quand même ma responsabilité de PM de m’assurer que la production a du sens par rapport à la stratégie, par rapport à la feuille de route, par rapport au modèle de développement de la boîte. Je ne peux pas juste copier-coller et envoyer ça à l’équipe en disant “Voilà le nouveau PRD”. Il faut lire, analyser, ajuster, réécrire parfois. L’IA accélère, mais elle ne vous dispense pas de penser.
Ignorer la sécurité des données
On ne le dira jamais assez : ne mettez pas de données sensibles dans n’importe quel modèle d’IA. Jamais. Même s’il faut garder en tête que les modèles, en principe, ne sont pas entraînés avec vos données. Si vous mettez des noms et prénoms, ça n’a théoriquement aucun intérêt pour le modèle, il ne va pas les mémoriser pour s’améliorer.
Néanmoins, ce qu’on ne sait pas aujourd’hui, c’est comment les données sont exploitées par les organisations derrière ces outils. À partir du moment où les modèles ne sont pas toujours ouverts, à l’exception de Mistral par exemple , nous n’avons pas accès à leur mode de fonctionnement exact. On ne peut donc pas s’assurer de l’usage de ces données, de leurs propriétés intellectuelles, de ce qui se passe vraiment derrière.
Alors concrètement, qu’est-ce que je conseille à un PM qui me demande “Bon, je fais quoi alors ?” ? Vous anonymisez vos données. Et pour aller plus loin, vous téléchargez LM Studio, vous téléchargez des modèles en local, et vous anonymisez vos données à partir d’un modèle local. Comme ça, rien ne sort de votre machine.
Quand vous êtes responsable produit, vous devez veiller à ça. Parfois, vous pourriez même arriver à la conclusion qu’utiliser une IA externe n’est tout simplement pas possible au regard de la confidentialité des données, du code, des informations que vous souhaiteriez injecter. Je pense notamment aux industries de défense, ou à des éditeurs de logiciels qui ont des algorithmes clés. Injecter ces informations dans un modèle externe serait évidemment déconseillé.
Ce que fait un PM qui utilise bien l'IA
Avant de conclure, j’aimerais vous parler de ce que je vois chez les PM qui utilisent vraiment bien l’IA. Parce qu’il y en a. Déjà, ils font bien toutes les étapes du Discovery. De l’élaboration de la stratégie, des rencontres avec les utilisateurs, de l’analyse des datas utilisateurs, de l’élaboration de besoins à partir de ça, de la documentation et de l’interfaçage avec leurs équipes.
Globalement, la qualité de leur travail à chacune des étapes est largement meilleure. Et pourtant, ils n’ont pas plus de temps que les autres. Mais ils ont fait des choix, des arbitrages volontaires dans leurs priorités.
Combien d’équipes techniques se plaignent de l’absence de visibilité et de clarté sur ce que doit faire le produit ? Combien sont dans une lecture sprint à sprint alors qu’elles demandent de la hauteur de vue ? Souvent, c’est parce que les PM ne proposent pas ces informations. Non pas parce qu’ils sont mauvais, mais parce qu’ils n’ont pas le temps de faire cette action-là. Ils le sacrifient au bénéfice du reste.
Combien de PM n’exploitent pas les datas utilisateurs ? C’est considérable. Je ne parle pas des grandes entreprises, mais chez plein d’éditeurs, ces données dorment, inexploitées. L’IA permet de débloquer ça. Elle permet de remettre de la qualité là où aujourd’hui il en manque. Et ça fait gagner un temps précieux, mais aussi en qualité de relation avec les équipes, en qualité des produits livrés.
Et maintenant
Dans les conversations que j’ai avec les PM que j’accompagne, je constate que la vraie difficulté n’est pas de comprendre ces erreurs intellectuellement. C’est de se construire une pratique régulière, d’avoir un cadre pour expérimenter sans se perdre. C’est de savoir qu’il existe des solutions à chacune des étapes du Discovery, et qu’il n’y en a pas qu’une, il y en a beaucoup.
Ce qu’on peut faire, c’est les agencer comme des pièces de Lego, se créer ses propres workflows. Le changement, c’est qu’après on a des solutions pour l’améliorer, l’accélérer. On peut remettre de la qualité là où elle manque.
Rejoignez notre bootcamp AI4PM
C’est exactement pour ça que nous lançons le bootcamp AI4PM. Pas pour vous donner des prompts magiques, mais pour travailler ensemble sur votre usage réel de l’IA : vos questions, vos blocages, vos cas concrets. On va montrer qu’il y a des solutions à chacune des étapes du Discovery, qu’on peut les agencer de multiples façons, et que vous pouvez vraiment vous créer vos propres workflows.
Le déclic qu’on cherche à provoquer, c’est celui-là : voir qu’on peut remettre de la qualité dans son travail de PM, gagner du temps sur ce qui est répétitif ou chronophage, et surtout améliorer la qualité de la relation avec les équipes. Des échanges entre pairs, des mises en pratique, et surtout une approche qui reste ancrée dans le réel du métier de PM.