Être Product Builder : 6 leçons que j'ai tirées du terrain

Le terme Product Builder fait parler. Entre ce qu'on peut parfois entendre sur les réseaux sociaux et la réalité du terrain, il y a parfois un (grand) écart. Ou en tout cas, c'est ce que constate Pierre Sur après plusieurs mois de mission chez un acteur MedTech en tant que Product Builder. Limites des frameworks open source, "AI slop", pivot de l'organisation... Pierre livre ici six leçons concrètes pour comprendre ce que déployer un Product Builder en mission implique vraiment.

Le terme Product Builder circule beaucoup en ce moment, et chacun y met un peu ce qu'il veut : pour certains c'est un PM qui code, pour d'autres un développeur qui fait de la discovery avec des agents, pour d'autres encore juste un nouveau mot pour dire full-stack. Quand j'ai démarré ma mission dans une entreprise MedTech, le client voulait lui aussi son Product Builder. Pour lui, c'était quelqu'un capable de porter un produit de l'idée à la production, avec des agents IA dans la boucle. Si le brief était clair au départ, plusieurs mois plus tard, à peu près toutes mes certitudes sur ce que ça impliquait concrètement avaient bougé.

Les frameworks du marché s'arrêtent là où les problèmes commencent

Première semaine de mission, premier réflexe : aller voir ce qui existe. BMAD, OpenSpec, Speckit... L'écosystème des frameworks open source pour travailler avec des agents de code a explosé ces derniers mois. Le problème, c'est qu'ils s'arrêtent tous au même endroit : le code généré.

Tests, validation qualité, évaluation des risques, monitoring en production : rien de tout ça n'est couvert. Et c'est pourtant là que tout se joue quand on travaille chez un client avec des contraintes réelles. Le backoffice sur lequel j'intervenais exigeait une traçabilité complète avec audit trail, de la pseudonymisation par défaut et une gestion fine des permissions. Aucun framework du marché ne parle de ces sujets.

J'ai quand même tenté BMAD pendant une semaine. Six heures de setup pour produire un PRD générique de qualité moyenne. Sur des features simples, c'est over-engineered, et sur des features critiques, ça ne suffit pas. Le rapport effort/valeur n'y était pas.

Plutôt que de chercher le bon framework, on a construit nos propres briques, calibrées sur les contraintes du projet.

Product Builder, c'est de l'idée à la prod

Le raccourci le plus répandu sur le Product Builder, c'est celui du PM qui génère du code vite avec un agent. En mission, j'ai utilisé les agents bien au-delà de la génération de code : discovery, spécifications, prototype, développement, QA. L'objectif, c'est de faire du meilleur travail produit, plus vite, sur toute la chaîne. Les agents démultiplient l'exécution, mais la réflexion Produit reste entièrement portée par le Product Builder.

Un exemple concret : sur une feature de gestion des utilisateurs, j'ai piloté les entretiens, rédigé le PRD avec un agent, lancé le prototype avec un second agent, validé avec cinq utilisateurs en une semaine, puis passé le relais à l'équipe dev. Un seul point de décision produit, de l'idée à la mise en production. Le gain de temps est réel, mais il vient de la continuité de la chaîne, pas de la vitesse de génération du code.

Cette continuité change quelque chose de fondamental dans le quotidien : la boucle de feedback se raccourcit drastiquement. Quand la même personne porte l'intent produit du premier entretien jusqu'au prototype testé, les malentendus qui se glissent habituellement entre les maillons de la chaîne disparaissent. Chaque étape reste nécessaire, les agents permettent simplement à une seule personne de toutes les porter.

Plus les agents développent vite, plus les méthodologies comptent

Ce constat est contre-intuitif, et c'est probablement la leçon la plus importante de cette mission.

Plus les agents de code sont rapides, plus la qualité de l'input détermine le résultat. Des specs floues produisent de l'AI slop (du code généré qui tourne mais qui ne sert à rien), et des priorités mal posées donnent des features inutiles livrées en quelques heures au lieu de quelques semaines. Le problème reste le même, il arrive juste plus vite.

À l'inverse, lorsque j'ai tenté de générer une feature en utilisant un PRD précis (personas, jobs to be done, edge cases, user stories issues de vrais entretiens), j'ai obtenu un prototype exploitable dès la première itération. Le différentiel de temps gagné derrière est considérable.

La discovery, la user research, la priorisation par la valeur : ces méthodologies s'appliquent toujours. Elles deviennent juste plus critiques parce que l'exécution amplifie ce qu'on lui donne. Cette capacité de jugement, ce product taste qui permet de distinguer un vrai problème d'un faux besoin (ce qu'on qualifie de craft chez Thiga), c'est précisément ce que les agents n'apportent pas. Un bon cadrage multiplie son retour quand l'exécution est quasi instantanée. À l'inverse, les dégâts d'un mauvais cadrage arrivent plus vite qu'avant.

La source de vérité doit vivre près du code

Chez Thiga, on parle d'Operating System du Product Builder pour décrire l'environnement d'exécution dans lequel il opère au quotidien : le modèle de langage, l'interface conversationnelle, les connexions MCP aux systèmes de l'organisation, les skills, la mémoire. En mission, j'ai découvert que la première décision structurante sur cet OS n'est pas le choix du modèle ou de l'interface. C'est le choix de l'endroit où vit la source de vérité.

Si les specs sont dans Notion, les décisions dans Confluence et les user stories dans Jira, les agents naviguent à l'aveugle à chaque itération. C'est un problème que j'ai découvert dès les premières semaines, et qui a demandé un changement d'architecture d'information avant même de parler de features.

On a mis GitLab au centre. Tout ce qu'on donne en input aux agents vit dans le repo, versionné : PRDs, design kit, specs techniques. Notion reste pour la documentation humaine, et le flux va toujours de GitLab vers Notion, jamais l'inverse.

La règle qu'on applique est simple : ce qui va dans GitLab, c'est uniquement ce qui sert d'input à un agent. Les transcripts d'entretiens, par exemple, restent dans Notion. C'est du matériel humain, pas du contexte agent. Cette distinction paraît anecdotique, mais elle structure tout le workflow au quotidien.

On se pose même la question de supprimer Jira complètement. Si les agents lisent directement les PRDs depuis le repo, les user stories écrites dans un outil de ticketing séparé ne servent plus à grand-chose. Quand un dev lance un agent pour implémenter une feature, il récupère automatiquement le PRD et les specs techniques depuis le repo. Tout le contexte est là, à jour, sans que personne ait eu besoin de copier-coller quoi que ce soit.

Stand-alone ou en équipe : le dispositif se calibre

Le fantasme du Product Builder autonome qui fait tout seul de A à Z est séduisant. La réalité de mission m'a appris que le bon dispositif dépend de deux variables : la criticité et la complexité du produit.

Sur le backoffice de cette scale-up MedTech (brownfield, critique), le dispositif était un PM avec deux devs AI-native. Le code a dix ans d'âge, la fiabilité prime sur la vélocité, et les compétences dev restent indispensables. Le Product Builder intégré à une mini-équipe, avec moins de devs qu'avant mais des devs quand même, c'est le bon curseur pour ce type de contexte.

Sur un outil interne de génération de données de démo pour les Sales (greenfield, non critique), un Product Builder seul a expédié une app Supabase + N8N en quelques jours. L'enjeu de fiabilité est faible, la codebase part de zéro, les utilisateurs finaux sont internes : le dispositif stand-alone tient la route.

Le Product Builder seul en toute circonstance, ça reste un fantasme. Le modèle qui fonctionne en mission, c'est celui du point de décision produit central, entouré d'une équipe calibrée selon le contexte. La vraie question à se poser à chaque fois : de combien de compétences complémentaires a-t-il besoin autour de lui sur ce projet précis ?

L'adoption ne se décrète pas

Donner des accès Claude et organiser des formations, c'est un prérequis, ça peut faire bouger les choses... mais ça ne crée pas l'adoption.

Ce qui marche vraiment, c'est de la démonstration et du mentorat direct, sur les vrais sujets de l'équipe. Quand une feature passe en développement, on prend un dev d'une autre équipe concernée par l'initiative et on bosse avec lui. On lui montre comment utiliser Claude Code, les agents qu'on a développés, et on avance ensemble sur la feature. Il monte en compétence sur un cas concret, et nous on récupère du feedback pour continuer à itérer sur notre framework.

Ce mode de transmission par le faire a produit des résultats qu'aucune formation descendante n'aurait pu atteindre, parce que la compétence s'ancre dans la pratique quotidienne du dev, sur ses vrais sujets. C'est quelque chose qu'on compte faire aussi avec les PMs plus tard : le même principe de compagnonnage appliqué à la discovery augmentée par les agents.

Le Product Builder tient la route en mission, chez de vrais clients, sur de vrais produits. Ce n'est plus une projection : des consultants opèrent déjà dans ce mode au quotidien. Mais la version qui produit des résultats ressemble peu au récit ambiant du PM augmenté qui vibe code entre deux sprints. Elle touche à l'outillage, aux méthodologies, aux sources de vérité, aux dispositifs d'équipe.

Ce que cette mission m'a confirmé, c'est qu'un Product Builder avec un bon OS ne suffit pas. L'OS structure l'exécution individuelle, il donne au Product Builder sa capacité d'agir. Mais chaque point abordé dans cet article renvoie à des questions qui dépassent l'individu : où vit la source de vérité et qui en décide ? Comment le craft d'un consultant se transmet au reste de l'équipe ? Quel dispositif pour quel niveau de criticité ? Ces questions relèvent de ce qu'on appelle chez Thiga le Product Operating Model adapté à l'IA. Le POM-AI, c'est le cadre organisationnel qui articule l'OS du Product Builder, la plateforme qui sécurise le chemin vers la prod, et les règles collectives qui permettent à plusieurs Product Builders d'opérer en parallèle sans que l'autonomie vire au chaos. Ce cadre doit couvrir l'ensemble du cycle de développement produit, et il doit être spécifique au contexte de chaque organisation. Les briques existent. Les assembler projet par projet, organisation par organisation, c'est probablement la partie la plus intéressante du travail qui reste à faire.