Le Grand Rattrapage Product Building : 5 cas d’usage pour passer de la veille à la delivery

Senior Manager Data & AI Transformation chez Converteo, Erik Perrier est un leader expérimenté de la transformation data et IA. Il accompagne les organisations dans la définition de leur stratégie produit et le management d’équipes dédiées à l’innovation dans le domaine de l’IA et de l’agentique.

A retenir

• Le workflow prime sur l’outil : La vraie valeur de l’IA ne vient pas d’un prompt ponctuel, mais de la création de systèmes fiables et réutilisables à chaque étape du cycle produit (veille automatisée, prototypage express, base de feedbacks centralisée).
• L’IA exécute, l’humain décide : L’IA agit comme un « sparring partner » qui élimine la friction documentaire (structurer des données, rédiger des tickets Jira). Le jugement produit (cadrer, prioriser, arbitrer) reste une discipline strictement humaine.
• L’émergence du « Product Building » : L’enjeu stratégique n’est plus de tester les derniers outils à la mode, mais d’industrialiser ces usages et de partager ces nouvelles pratiques en communauté pour générer de vrais gains business.

Début juillet, Converteo et Le Ticket ont organisé Le Grand Rattrapage : 5 talks live pour aider à passer de la curiosité à la pratique sur l’IA. La rentrée est le bon moment pour s’y plonger, ou pour rattraper ce qu’on a manqué. L’été n’a pas ralenti le rythme de l’IA, et beaucoup d’équipes produit retrouvent leurs projets avec la même question qu’avant les congés : par où commencer, concrètement ? Ce guide rassemble l’essentiel des cinq sessions pour y répondre, à lire au calme avant de replonger dans la delivery.

Le sujet n’est pas l’outil, mais le workflow

Depuis plusieurs mois, une grande partie des conversations autour de l’IA dans les métiers produit se concentre sur les outils : Claude, ChatGPT, Lovable, Dust, Cursor, Notion AI, Perplexity. C’est compréhensible : les outils évoluent vite et beaucoup d’équipes cherchent encore par où commencer.

Mais les cinq sessions ont mis en évidence un point plus structurant : la valeur ne vient pas de l’outil choisi. Elle vient de la capacité à transformer un usage isolé en workflow fiable, contextualisé et réutilisable. Un prompt aide ponctuellement. Un agent automatise une tâche. Mais un workflow bien pensé change la manière dont une équipe apprend, décide, construit et livre.

C’est ce fil rouge, du « test IA » au « système produit augmenté », qui relie les cinq étapes qui suivent.

Étape 1 – Capter les signaux : faire de sa veille un actif produit

Tout commence par la compréhension du marché. Elodie Gueho, Lead PM chez Gens de Confiance, a ouvert le capot d’un système qui tourne chez elle depuis neuf mois : une veille immobilière générée par Claude, archivée dans une base Notion et diffusée chaque lundi sur Slack, automatisée via Claude Cowork. Avec un enseignement central, souvent contre-intuitif : la valeur ne tient pas à la démo, mais au cadrage du prompt et à la vérification des sources. Elle estime avoir passé deux mois et une trentaine de tests à fiabiliser le système avant la mise en production.

Le basculement clé : la veille cesse d’être une activité annexe dépendante de la discipline individuelle pour devenir une infrastructure de connaissance, sourcée, requêtable, partagée, qui nourrit la discovery, la priorisation et les arbitrages. C’est elle qui a fait remonter, en signal faible, une évolution réglementaire sur les locations Airbnb en copropriété : une opportunité de supply que la lecture manuelle du fil LinkedIn aurait manquée

Étape 2 – Explorer en construisant : le prototype comme support de dialogue

Une fois les signaux captés, il faut explorer. Jules Boiteux, fondateur de Vibe Coding Academy, a déroulé un scénario réaliste : un PM chez Excalidraw doit explorer une fonctionnalité sans designer disponible, et produit une première version testable avec Claude Code et Lovable. La bascule technique passe par un « Master Project » répliquant le produit, qu’on duplique pour chaque test, et un prototype fonctionnel obtenu en 10 à 15 minutes.

Le basculement clé : le prototype arrive beaucoup plus tôt dans la conversation. L’équipe ne discute plus d’une idée abstraite mais réagit à un objet concret, ce qui réduit l’ambiguïté et accélère l’apprentissage. Surtout, en interrogeant directement la codebase plutôt qu’une doc obsolète, le PM peut désormais prototyper pour cadrer, et non plus cadrer pour prototyper.

Étape 3 – Écouter à l’échelle : rendre la connaissance client requêtable

Explorer, oui, mais en s’appuyant sur du réel. Romain Deschamps, AI & Product Ops freelance, a montré comment exploiter enfin les feedbacks dispersés dans les tickets support, les verbatims CSAT, les calls sales, les CRM et les notes CSM, en les rendant interrogeables avec des outils comme Dust. Son cas le plus abouti, chez Semji, est passé de 240 à environ 4 000 feedbacks exploitables par an en connectant les calls sales via transcription, avec plus de 500 appels MCP par mois pour seulement deux PM.

Le basculement clé : la connaissance client devient une mémoire collective requêtable plutôt qu’une somme de souvenirs dispersés. À une condition, souvent sous-estimée : structurer la donnée en amont. Sans cette base, l’IA produit des synthèses fragiles ; avec elle, un levier de décision qui remonte jusque dans les tickets et les présentations stratégiques du CPO.

Étape 4 – Livrer sans se perdre : automatiser le flow Discovery > Jira

Vient le moment où la discovery doit se transformer en delivery, et c’est souvent là que la valeur se perd. Marion Jachimski, Head of AI Transformation chez AI Discipline, a présenté un workflow complet : Claude pour produire un PRD à partir d’une discovery en cinq étapes imposées (où l’agent refuse de sauter une étape ou de rédiger si l’information manque), puis un agent Dust pour le décliner en tickets Jira exploitables, marqués « AI generated » pour garder une review humaine avant le backlog.

Le basculement clé : l’IA réduit la friction documentaire (reformuler, structurer, décliner, mettre en forme), mais ne doit jamais porter seule le jugement produit : cadrer, arbitrer, prioriser, renoncer. Marion parle d’un « sparring partner » qui renvoie la balle, pas d’un exécutant. Le « human in the loop » n’est pas une précaution théorique : c’est une discipline produit. La vraie question n’est pas comment tout automatiser, mais où concentrer l’énergie humaine.

Étape 5 – S’organiser soi-même : poser les bases de son Personal OS

Dernière étape, et pas la moindre : soi. Julie Prieur, CPO de Poppins, a montré comment faire de Claude un véritable système personnel de travail : analyse de transcriptions de réunions, publication de comptes-rendus dans Slack, audit d’agenda pour détecter une surcharge opérationnelle. Le tout incarné par des agents nommés et personnalisés, dont « Jarvis », un bras droit explicitement configuré pour la challenger plutôt que lui donner raison, et montable, dans sa première version, en une trentaine de minutes.

Le basculement clé : un bon Personal OS n’est pas un assistant générique, c’est un système qui connaît votre contexte, vos objectifs et votre manière de décider. Le construire oblige à formaliser sa façon de travailler, et cette compétence de formalisation est exactement celle qu’il faudra ensuite mobiliser pour concevoir des workflows d’équipe. Le Personal OS est le laboratoire du Product Building.

Ce que ces cinq étapes racontent : l’émergence du Product Building

Ces cinq sessions couvraient des moments différents du cycle produit. Pourtant, elles pointent toutes vers la même transformation. Le Product Builder n’est pas simplement quelqu’un qui utilise de nouveaux outils : c’est quelqu’un qui sait repenser son environnement de travail à partir des nouvelles capacités offertes par les modèles, les agents et les outils de prototypage.

Il apprend à définir le bon contexte, à identifier les données utiles, à intégrer les outils dans un processus existant et à préserver les moments où l’expertise humaine reste indispensable. Il ne cherche pas à automatiser toute la chaîne produit (ce serait confondre vitesse et qualité) mais à déplacer son énergie vers les tâches à plus forte valeur : comprendre le problème, formuler les bons arbitrages, tester plus vite, décider avec plus de clarté.

Ce qui émerge, c’est une discipline à part entière : le Product Building, à la croisée du product management, de la data, du design, de la delivery, de l’architecture et de l’adoption métier. Et c’est là que le sujet devient stratégique : les entreprises qui tireront le plus de valeur de l’IA ne seront pas celles qui auront testé le plus d’outils, mais celles qui sauront intégrer ces outils dans leurs modes de fonctionnement, leurs pratiques de décision et leurs cycles de delivery.

Pourquoi Converteo investit ce sujet

Si Converteo s’engage sur le Product Building, c’est parce qu’il se situe exactement à l’intersection de plusieurs expertises devenues indissociables : stratégie, data, IA, produit, technologie, transformation et adoption.

Construire un produit IA ne se résume pas à faire une démo. Il faut identifier le bon cas d’usage, comprendre les données disponibles, concevoir l’expérience, choisir la stack, prototyper vite, tester avec les utilisateurs, mesurer l’impact, sécuriser le passage à l’échelle et accompagner les équipes. C’est ce passage de l’expérimentation à l’industrialisation qui fait toute la différence. Beaucoup d’organisations savent produire des prototypes, beaucoup moins savent les transformer en workflows robustes, en produits adoptés et en gains business mesurables.

Avec The Product Builder Community, Converteo veut contribuer à structurer cette nouvelle pratique avec une approche concrète : événements, retours d’expérience, contenus, ateliers, replays, podcasts et une communauté de praticiens.