Du Product Owner au Product Builder : ce que l'IA change concrètement dans la fabrication produit 

Il y a quelques années, sur un projet de portail fournisseurs pour un groupe hôtelier, j'ai reçu un besoin qui tenait en une phrase : « simplifier les échanges avec nos fournisseurs ». Rien de plus. Pas de user story, pas de cas d'usage, juste une intention. 

À l'époque, mon travail de Product Owner a consisté à combler ce vide avant même de penser priorisation de backlog. J'ai interviewé des hôteliers, des fournisseurs, des prestataires, pour faire émerger les vraies questions : qui valide quoi, que se passe-t-il quand un fournisseur ne répond pas dans les délais, comment traiter les cas particuliers qui ne rentrent dans aucune règle. Ce n'est qu'une fois ces scénarios posés noir sur blanc que le projet a pu vraiment démarrer. 

Je raconte cette histoire parce qu'elle a continué d’occuper mon esprit par la suite, en observant ce que l'IA générative est en train de faire au métier de Product Owner. Ce n'est plus un débat théorique : l'industrie a déjà donné un nom à ce qui se dessine l'« AI Builder »¹ . Ce que je découvre également dans les retours d'expérience récents, c'est que la mécanique qui a fait la différence sur mon projet de portail fournisseurs est exactement celle qui fait ou défait un « Product Builder » aujourd'hui. 

Prototyper, ce n'est pas prompter 

Ce qui m'a le plus frappée en creusant le sujet, c'est à quel point la méthode qui fonctionne avec l'IA ressemble à ce que je fais depuis des années sans le savoir sous ce nom.  

Prompter une IA avec « construis-moi un programme de parrainage » ne donne rien d'exploitable, c’est trop vague. Ce qui marche, c'est de décomposer la demande comme on écrirait des critères d'acceptation : l'expérience cœur, les règles métier, les cas limites³. Sans cette décomposition, l'IA comble les trous avec des hypothèses que personne n'a validées, exactement ce qui se serait passé sur mon portail fournisseurs si j'avais laissé un développeur deviner ce que « simplifier les échanges » voulait dire, sans passer par la phase d'interviews. 

Ce qui change vraiment avec l'IA, ce n'est donc pas cette étape de cadrage, elle reste, plus que jamais, le cœur du métier. Ce qui change, c'est ce qui se passe juste après : au lieu d'attendre plusieurs sprints pour voir un premier écran, un PM peut aujourd'hui faire tourner un prototype qui interagit avec les vraies pages du produit, tester un vrai parcours utilisateur, et transformer ce prototype en revue de code que les ingénieurs approuvent et fusionnent³. Le mur entre « celui qui définit » et « celui qui fabrique » devient poreux. 

C'est aussi une question de posture managériale, autant que d'outil. Ce que je retiens des retours d'expérience les plus intéressants sur le sujet, c'est que cette aisance avec l'IA ne s'acquiert pas en lisant des articles, elle se construit en manipulant les outils soi-même, et elle se propage dans une équipe quand les managers montrent l'exemple plutôt que de se contenter de la prescrire⁴.

Le vrai test n'est pas le prototype : c’est ce qu'on en fait 

Sur un autre projet, dans une enseigne de bricolage, j'ai piloté la vision produit d'un programme de fidélité B2B et B2C (app, carte digitale, CRM). La partie visible, excitante, c'était la définition du parcours. Mais la partie qui a réellement déterminé si le projet tenait debout, c'était tout ce qui suivait : la priorisation du backlog, la coordination avec les prestataires, le suivi des livraisons, le respect des exigences qui garantissent qu'un produit fonctionne, une fois en production, sous charge réelle, avec de vrais utilisateurs. 

C'est exactement le point de bascule que je vois se dessiner autour de l'IA Builder aujourd'hui. Un cas devenu assez emblématique dans l'industrie l'illustre bien : une équipe technique a dû reprendre le prototype construit par un collaborateur non-développeur, et y a découvert des failles structurelles qui rendaient toute mise en production impossible sans un retravail complet⁵. La vitesse sans garde-fou n'est pas un risque théorique. Un scan mené sur plus de 5 000 applications « vibe-codées » et déployées publiquement le confirme à grande échelle : plus de 2 000 vulnérabilités critiques, plus de 400 secrets exposés (clés API, tokens) et des données personnelles ou médicales mal protégées⁶. 

À l'inverse, les organisations qui posent un vrai cadre : spécifications précises plutôt que prompts ouverts, tests automatisés qui conditionnent le pipeline, revue humaine de l'architecture,  documentent des gains mesurables en fiabilité et en vitesse de correction, sans sacrifier la vélocité de développement.  

Autrement dit : prototyper vite ne dispense de rien. Ça déplace juste le moment où la rigueur doit intervenir. 

Ce que je retiens pour la suite 

C’est dans ce contexte que j’ai utilisé pour la première fois l’IA dans une logique de Product Building, sur un sujet auquel je suis confrontée actuellement : comment une IA conversationnelle pourrait améliorer le parcours client d'une enseigne de grande distribution alimentaire. Je suis partie d'une question assez simple : que se passerait-il si, plutôt que de chercher successivement chaque produit, un client pouvait simplement exprimer son besoin, par exemple « Je prépare un dîner pour quatre personnes », et se laisser accompagner jusqu'à la constitution de son panier ? 

J'ai utilisé Lovable pour matérialiser cette idée, puis j'ai progressivement enrichi le prototype. Et c'est précisément là que l'exercice est devenu intéressant. Il ne s'agissait plus seulement de générer quelques écrans : j'ai pu simuler un parcours dans lequel la proposition de l'assistant devient réellement manipulable. Les produits peuvent être ajoutés au panier, les quantités ajustées directement depuis les fiches produits mais aussi à travers la conversation avec l'agent. Le prototype peut également faire évoluer sa proposition en fonction d'une nouvelle contrainte : respecter un budget donné, adapter les quantités au nombre de personnes ou, à l'inverse, intégrer des préférences et régimes alimentaires spécifiques. 

Surtout, le prototype a commencé à challenger mon propre raisonnement produit. Chaque interaction soulève immédiatement de nouvelles questions : que doit faire l'assistant si le budget demandé est incompatible avec le nombre de personnes ? Doit-il privilégier le prix, les quantités ou proposer plusieurs arbitrages ? Que se passe-t-il si le client indique après coup qu'une personne est végétarienne ou sans gluten ? Faut-il modifier quelques produits ou repenser toute la proposition ? En faisant évoluer le prototype, j'ai pu tester différentes réponses possibles, observer leurs conséquences sur le parcours et affiner progressivement les règles que je souhaitais appliquer. 

C'est probablement ce que cette expérimentation m'a le mieux fait comprendre du passage du Product Owner au Product Builder. Je n'ai pas appris à coder un produit, j'ai raccourci la distance entre une hypothèse et sa mise à l'épreuve. Là où j'aurais auparavant formalisé ces scénarios dans des spécifications avant de pouvoir les confronter à une expérience tangible, j'ai pu les manipuler, identifier les zones floues et faire évoluer mon besoin en même temps que le prototype. L'IA ne remplace donc pas le travail de cadrage que je décrivais au début de cet article. Elle lui donne une nouvelle forme : on ne spécifie plus seulement avant de voir, on peut désormais voir, tester et manipuler pour mieux spécifier. 

Sources ¹ Product School, juin 2026 ² Roman Pichler, avril 2026 ³ Builder.io, janvier 2026 ⁴ Atlassian, janvier 2026 ⁵ Martin Fowler / Thoughtworks, mai 2026 ⁶ BeyondScale, données Escape.tech, avril 2026