Dans une salle de réunion, un chef de produit ouvre un terminal, tape une question en langage courant, et vingt secondes plus tard tient une réponse chiffrée, puisée en direct dans les données du produit.

Ce n’est pas une démonstration scénarisée pour impressionner un comité de direction. C’est, selon Colin Matthews, un mardi ordinaire pour une poignée de chefs de produit qui ont discrètement changé la nature de leur métier. Ce formateur, qui affirme avoir accompagné plus de 40 000 chefs de produit, designers et professionnels de la tech, a publié fin juin sur Lenny’s Newsletter, référence nord-américaine du product management, une grille de lecture sur l’IA pour chef de produit qui a largement circulé au-delà du cercle habituel des praticiens : trois formes de levier, ce supplément de force qu’un outil procure à celui qui l’actionne, que l’intelligence artificielle offrirait désormais à qui sait s’en servir.

Premier levier : ne plus seulement écrire, déléguer

Le premier de ces leviers, personnel, est le plus répandu et le moins spectaculaire. À son premier échelon, l’IA rédige : un brouillon de PRD (product requirements document, le cahier des charges qui décrit ce qu’une équipe doit construire et pourquoi), un compte rendu de réunion, un e-mail de cadrage. Au deuxième, elle produit un artefact entier plutôt qu’un simple texte : une présentation, une maquette sommaire. Au troisième, le plus abouti, elle ne se contente plus de répondre : elle agit. Reliée par les développeurs à des outils comme Amplitude, Notion ou Google Drive via un protocole technique appelé MCP (Model Context Protocol, un standard qui permet à un agent d’intelligence artificielle, un programme capable d’enchaîner plusieurs actions de façon autonome pour atteindre un objectif, de consulter et manipuler directement les outils qu’une équipe utilise déjà), l’IA rédige un premier jet de feuille de route ou dépouille seule une centaine de retours clients pour en extraire les trois thèmes qui reviennent le plus souvent.

Le rapport Atlassian sur l’état du product management en 2026 décrivait déjà des chefs de produit dotés de plus de pouvoir, mais aussi plus de peur d’échouer. Ce premier levier ne change rien à cette tension : il déplace simplement l’heure à laquelle la peur se manifeste, du moment de la rédaction à celui de la décision.

Deuxième levier IA du chef de produit : le prototype remplace la promesse

Le second levier, produit, touche à ce que l’équipe peut réellement livrer. Un chef de produit sans compétences de design ou de développement ne pouvait, jusqu’ici, que décrire une idée : une diapositive, un texte, une intention. Il peut désormais la montrer. Premier échelon : un prototype web jetable, une version fonctionnelle mais déconnectée du produit réel, qui sert uniquement à rendre une idée tangible en réunion. Deuxième échelon, plus exigeant : des outils comme Claude Code ou Codex accèdent directement au code source de l’entreprise pour générer un prototype qui s’appuie sur l’architecture existante, donc plus proche de ce qui pourrait réellement être livré. À l’extrémité de cette échelle, chez une minorité d’équipes seulement, l’IA va jusqu’à proposer une modification de code prête à être intégrée, qu’un développeur se contente de relire et de fusionner dans le produit.

Troisième levier : automatiser ce qui se répète

Le troisième levier, systémique, est le moins documenté des trois mais le plus ambitieux : transformer une tâche ponctuelle en flux automatisé et fiable, pour libérer, semaine après semaine, du temps consacré à la réflexion stratégique plutôt qu’à l’exécution. C’est aussi le plus difficile à généraliser, car il suppose une discipline d’ingénierie, tester, documenter, surveiller, que peu de chefs de produit possèdent encore. Encadrer ces automatismes relève d’une discipline que nous décrivions déjà en juillet : le harnais qui empêche les agents IA de s’emballer, coûts et dérives compris.

Le vrai risque n’est pas de mal coder, c’est de mal choisir

Cette progression a un revers que Colin Matthews, dont l’activité commerciale repose justement sur la formation de chefs de produit à ces outils, ne développe guère. Un autre analyste influent du secteur, Shreyas Doshi, défend de son côté un raisonnement presque inverse. Son argument : les outils d’intelligence artificielle se banalisent vite, si vite que la maîtrise d’un outil précis, aussi impressionnante soit-elle aujourd’hui, cessera rapidement d’être un avantage concurrentiel. Ce qui distingue un chef de produit d’un autre, écrit-il, ne sera bientôt plus l’outil qu’il manie, mais le jugement qu’il applique à ce que cet outil produit : l’empathie envers l’utilisateur, la capacité à simuler les conséquences d’une décision, le sens stratégique, le goût, l’exécution créative. Un tableur n’a jamais fait un bon analyste, rappelle-t-il ; un agent IA ne fera pas, à lui seul, un bon chef de produit.

Les deux lectures ne s’excluent pas, elles se corrigent l’une l’autre. Savoir interroger ses données ou générer un prototype fait gagner des heures, un gain réel et mesurable sur le temps d’exécution. Cela ne dispense pas de savoir quelle question poser, ni de porter la responsabilité de ce qu’on livre. Nous l’écrivions déjà à propos des équipes d’ingénierie : coder plus vite ne suffit pas à faire avancer une organisation. Un prototype produit par une IA à partir du code réel de l’entreprise reste un changement livré sans la revue de sécurité ou d’architecture qu’un développeur aurait exigée pour la même modification. La vitesse gagnée d’un côté peut se payer, de l’autre, en dette technique ou en incident, si personne ne rejoue ce contrôle en aval.

Par où commencer, concrètement

Pour une équipe qui découvre ces usages, la progression a son utilité justement parce qu’elle est graduée : nul besoin de viser d’emblée le sommet de l’échelle. Un chef de produit peut commencer, cette semaine, par demander à un assistant IA de synthétiser les retours clients accumulés dans un canal de discussion interne avant un comité produit, ou de préparer un premier jet de compte rendu après une série d’entretiens de discovery (la phase d’exploration où l’on cherche à comprendre un problème utilisateur avant de décider quoi construire). Le pas suivant, un prototype jetable pour tester une idée en réunion plutôt qu’une planche de diapositives, ne demande ni développeur ni budget particulier. Le reste, l’intégration au code réel, l’automatisation de flux entiers, peut attendre que l’équipe d’ingénierie ait posé les garde-fous nécessaires : revue de sécurité, tests, surveillance.

Mind the Product notait, dans son édition de l’été 2026 consacrée aux ressources produit, une fracture naissante dans le métier : d’un côté des chefs de produit qui construisent, de l’autre ceux qui continuent d’écrire des documents sur ce que d’autres construisent. Le levier, en lui-même, ne choisit pas de quel côté de cette ligne on se trouve. Il ne fait qu’accélérer la trajectoire déjà prise, dans un sens comme dans l’autre.

Sources

ARTICLES CONNEXESPLUS DE L'AUTEUR