La valeur du code s’effondre. Ce qui était hier l'actif rare et coûteux du numérique est en train de devenir une commodité abondante, produite à la volée. Dans ce nouveau paradigme, le Product Manager "gestionnaire" s'efface au profit du Product Builder, capable de propulser des produits en production en totale autonomie. Mais comment passer du prototype individuel à la puissance organisationnelle sans sombrer dans le chaos ? Renaud Chevalier, CTO de Thiga, décrypte cinq concepts clés pour comprendre et faire face à ce changement.
Vous ouvrez Claude Code et vous activez le Mode Plan. Claude vous interviewe : quel problème résout-on, quels critères de succès, quelles contraintes métier et techniques… En quelques échanges, une spec se formalise, lisible, que vous approuvez avant qu'une seule ligne de code n'existe.
Vous validez, et Claude Code se met au travail. Il orchestre l'implémentation en parallèle, appelle des serveurs MCP pour récupérer de la data contextuelle dans les systèmes de l'organisation, commite, reporte. Vous suivez l'avancement, vous ajustez si besoin. Claude Code pousse le code et ouvre une Pull Request. Les guardrails de la plateforme valident automatiquement la compliance, la sécurité, les tests. Vous mergez, vous lisez les métriques en direct, et vous recommencez.
De la spec à la production, seul, en quelques heures. Sans sprint planning, sans PRD rédigé pour convaincre l'engineering, sans réunion de priorisation. Vous avez pensé le problème, cadré la solution, construit le produit et mesuré le résultat, le tout dans la même journée.
Ce scénario n'a rien d'une fiction, et ce n'est pas du vibe coding. C'est une démarche structurée, reproductible, traçable, que pratiquent aujourd'hui les professionnels du produit qui ont compris dans quel monde ils travaillent. On les croise chez nos clients, on en a dans nos équipes.
Le constat qu'ils partagent est le même : les mots de l'ère précédente ne collent plus à ce qu'ils font. "Product Manager" décrit quelqu'un qui gère. "Sprint" décrit une contrainte de temps. "PRD" décrit un artefact de communication avec la tech. Ces termes renvoient à une réalité qui a bougé; or, quand le vocabulaire ne suit pas, on perd la capacité de penser ce qui se passe. Et ce qui ne se pense pas ne se pilote pas.
Cet article pose cinq termes pour comprendre et piloter cette rupture.
Le changement d’état
En physique, un changement d'état n'a rien de progressif. L'eau à 99°C et l'eau à 101°C n'ont pas les mêmes propriétés. Il n'y a pas de transition douce entre les deux, juste un seuil au-delà duquel tout fonctionne différemment.
Le produit numérique vient de franchir ce seuil. Pendant vingt ans, la pratique produit a fonctionné dans un cadre stable, structuré par une réalité simple : construire coûtait cher. Le code était rare, le produire exigeait des compétences spécialisées, du temps, une chaîne d'intermédiaires. Ce coût structurait tout le reste : les rôles, les rituels, les artefacts.
Ce coût s'est effondré, et le code se banalise. Les systèmes continuent de reposer dessus, mais sa production cesse d'être une contrainte. Le code devient ce que l'électricité est devenue au XXe siècle : une infrastructure invisible, universellement accessible, que personne ne valorise en soi. Personne ne pense à l'électricité en allumant une lampe. Il suffit de brancher une prise.
Si le code cesse d'être l'actif rare, qu'est-ce qui prend de la valeur à sa place ?
La data, d'abord. Le code généré à la volée n'a de sens que parce qu'il manipule, transforme et présente de la data. Quand le code s'efface comme contrainte, ce qui reste comme actif réel et différenciant, c'est la donnée sur laquelle il opère. Sa qualité, sa gouvernance, son accessibilité, sa fraîcheur : voilà ce qui détermine la valeur de ce qui est produit, bien plus que la sophistication du code qui les traite.
Le jugement, ensuite. Dans un monde où le code est de l'électricité, ce qui prend de la valeur, c'est la décision de ce qu'on connecte au réseau. Si l'exécution est abondante, l'erreur de direction coûte proportionnellement plus cher. Il n'y a plus de friction mécanique pour ralentir les mauvaises décisions : plus de sprint à attendre, plus d'estimation qui force à réfléchir avant de s'engager. La décision de ce qu'on construit, pourquoi et pour qui, c'est ça qui devient rare, et qui fait vraiment la différence.
Mot n°1 : le Product Builder
Ce changement d'état fait émerger un rôle. La trajectoire ressemble à celle du DevOps : d'abord une culture et des pratiques adoptées par quelques équipes, puis un rôle reconnu, et enfin un titre de poste standardisé sur le marché. Le Product Builder en est au deuxième stade. Certains PMs l'exercent déjà sans en porter le titre, et quelques entreprises recrutent déjà sous ce nom.
Le Product Builder peut venir du Product management, du Design ou du développement. L'origine importe moins que ce qui a changé dans sa pratique : son rapport à l'exécution. Il parcourt seul la chaîne de valeur complète, de l'intention à la production, sans dépendre de l'engineering à chaque hypothèse. Le PM apporte la rigueur de la discovery et l'alignement business. Le designer apporte l'empathie utilisateur et la qualité d'expérience. Le dev apporte la compréhension technique et le sens de l'architecture. Le Product Builder idéal combine ces regards ; à défaut, il sait dialoguer avec chacun d'entre eux et exploiter l'IA pour compenser ce qui lui manque.
Ce nouveau rapport à l'exécution transforme la pratique en profondeur.
Le rapport à l'artefact change d'abord. Le Product Builder ne décrit plus - il spécifie, puis montre. La spec co-construite avec l'agent remplace le PRD solitaire, et le livrable devient une démonstration qui aligne par la preuve plutôt qu'un document de communication destiné à convaincre.
Le rapport au temps se contracte avec lui. Le sprint de deux semaines se réduit à quelques heures, et l'itération cesse d'être un rituel cadencé pour devenir un réflexe continu. Parce que chaque étape est tracée et validée par la plateforme, l'accélération renforce la qualité au lieu de la sacrifier.
La relation avec l'engineering se reconfigure en fonction du degré d'autonomie atteint. Au départ, le Product Builder prototype et l'engineering reprend pour la production. À mesure que la plateforme se consolide, avec ses guardrails, ses tests et sa compliance automatisée, le Product Builder pousse directement sur des périmètres de plus en plus larges, et l'engineering se recentre sur la revue de code et les décisions d'architecture. Dans les configurations les plus avancées, la seule dépendance externe reste la Platform Engineering team, qui intervient comme infrastructure partagée plutôt que comme partenaire de livraison.
La collaboration elle-même change de nature. Puisque le Product Builder peut parcourir seul la chaîne de valeur, la collaboration cesse d'être une contrainte structurelle imposée par le process (handoffs, cérémonies, dépendances croisées) et devient un acte délibéré. On collabore pour accéder à une data que les agents ne couvrent pas, pour partager des apprentissages que la data seule ne raconte pas, pour challenger ses propres angles morts, et pour maintenir le lien humain, la confiance et la dynamique collective, qu'aucun agent ne peut générer.
Pour que tout cela soit possible, deux enablers doivent être réunis. Le premier est un environnement d'exécution adapté. Le second est une infrastructure qui ouvre l'autoroute jusqu'en production.
Devenez Product Builder, quel que soit votre point de départ ! Le profil Product Builder peut venir du Produit comme de la tech. Thiga Academy propose une formation pour chaque chemin : Vibe Coding pour les PMs et designers qui veulent pousser des produits en prod et Product Builder for Engineers pour les engineers qui veulent développer les réflexes Product dans leur pratique de build.
Mot n°2 : l’Operating System du Product Builder
Le premier enabler, c'est l'Operating System (OS) du Product Builder, son environnement d'exécution personnel.
Chromebook a démontré qu'il était possible de faire disparaître l'OS traditionnel derrière un navigateur. L'OS du Product Builder fait la même chose un cran au-dessus : il fait disparaître la stack de développement derrière une interface conversationnelle. Cinq éléments le constituent.
Le modèle de langage
C'est le moteur de tout le reste. Le choix du modèle détermine la qualité du raisonnement, la taille de la fenêtre de contexte, la vitesse d'exécution et le coût à l'usage. Un agent consomme beaucoup plus d'appels qu'une interaction directe, et l'écart de coût entre un modèle frontier (les plus performants du marché) et un modèle rapide peut atteindre plusieurs ordres de grandeur. La responsabilité du Product Builder, c'est de calibrer : frontier pour les tâches à fort jugement comme la spec, l'architecture ou une décision structurante ; modèle économique pour la haute fréquence comme le reformatage, les tests ou la documentation. Ce calibrage engage aussi des questions de souveraineté (quelles données transitent par quelle API, sous quelle juridiction) et d'empreinte environnementale, puisque chaque inférence consomme de l'énergie et qu'à l'échelle d'une organisation, ça devient un enjeu de gouvernance collective.
L’interface conversationnelle
Autour du modèle, l'interface conversationnelle détermine la façon dont le Product Builder exprime son intention. Trois typologies coexistent aujourd'hui. La ligne de commande, brute et épurée de toute distraction (Claude Code, Gemini CLI, Open Code). L'IDE augmenté, où l'IA s'intègre dans l'environnement de développement comme couche d'assistance (Cursor, Windsurf). Et l'approche orientée Design, où le Product Builder décrit ou esquisse ce qu'il souhaite construire et l'outil génère l'interface sans exposer le code (Lovable, Figma Make, v0, Bolt).
Laquelle s'imposera reste une question ouverte, et l'enjeu de cette génération de produits est celui de l'expérience.
Les serveurs MCP
Les serveurs MCP (Model Context Protocol) forment le troisième élément, et c'est celui qui ancre l'OS dans le réel. MCP est le protocole ouvert qui connecte l'interface conversationnelle aux systèmes de l'organisation : Jira, Figma, GitHub, bases de données, APIs internes, outils d'analytics. Tant que l'OS n'est pas branché aux systèmes de l'organisation, il raisonne dans le vide. MCP change la donne : la data circule, les contraintes s'appliquent, et l'agent travaille sur des données réelles plutôt que sur des abstractions.
Les skills
Viennent ensuite les skills. Ce sont des fichiers (SKILL.md) chargés dans l'OS qui encodent des savoir-faire spécialisés, activés automatiquement par l'agent dès qu'il en reconnaît la pertinence. Un agent sans skills est généraliste, compétent mais sans mémoire de la façon dont le Product Builder ou son équipe travaillent. Les skills lui donnent des comportements reproductibles : une façon de brainstormer, de débugger, de faire une revue de code, qu'il applique sans qu'on les lui réexplique à chaque session. C'est comme ça que l'OS s'ajuste progressivement au contexte et aux standards de l'organisation.
La mémoire
La mémoire, enfin, repose sur deux mécanismes. Le contexte de session, volatile, qui disparaît à la fermeture. Et la mémoire persistante, ce que le Product Builder encode délibérément dans des fichiers chargés à chaque session (CLAUDE.md, .cursorrules, AGENTS.md) : standards de l'équipe, décisions passées, contraintes du contexte, complétés via MCP par des systèmes de mémoire externes. Toute mémoire qui traverse les sessions est le fruit d'une intention explicite : les LLMs ne s'auto-modifient pas et n'apprennent pas au fil de l'usage.
Mot n°3 : la plateforme
Si l'OS donne au Product Builder la capacité d'exécuter, la plateforme transforme quant à elle cette capacité en déploiement maîtrisé. Les barrières de la production sont toujours là, mais elles se sont déplacées de la compétence individuelle vers l'infrastructure partagée.
C'est le travail du Platform Engineering : concevoir une Internal Developer Platform (IDP) qui donne aux Product Builders la capacité d'aller en production en self-service, dans un cadre maîtrisé. Le concept existe depuis longtemps, mais l'émergence du Product Builder change la donne : sans plateforme, cette nouvelle capacité d'exécution reste individuelle et isolée, sans chemin fiable vers la production. La plateforme est ce qui fait passer le Product Builder du prototype au produit en production.
L'IDP fonctionne sur un principe central : les golden paths. Des chemins standardisés, préconfigurés, qui encodent les bonnes pratiques de l'organisation sous forme d'automatisations accessibles en self-service. Suivre un golden path, c'est déployer en production sans avoir à comprendre chaque couche de l'infrastructure sous-jacente… Exactement comme on branche une prise sans comprendre le réseau électrique !
L'OS vient toucher plusieurs couches de cette plateforme :
- Le contrôle de version d'abord. La gestion du code source avec ses branches et ses Pull Requests forme la colonne vertébrale de l'exécution agentique. Quand des agents génèrent du code en continu, potentiellement sur plusieurs features en parallèle, la discipline de branches devient une condition de fonctionnement, plus une convention d'équipe. La Pull Request est le point de jonction entre l'OS individuel et la plateforme collective, le moment où les guardrails s'activent et où la compliance est vérifiée automatiquement. Avec des agents capables d'ouvrir des dizaines de PRs, la plateforme doit absorber la validation systémique pour que la review humaine reste ciblée et à haute valeur.
- L'accès à la data constitue une couche à part entière. Qui a accès à quoi, avec quelles règles de qualité et quelle traçabilité : la fiabilité de ce que l'agent produit dépend directement de la qualité des données auxquelles il est connecté, et quand les données sont mal maîtrisées, l'agent va vite… Mais il va “faux”.
- L'infrastructure d'exécution (environnements de build, pipelines CI/CD, orchestration de containers) prend une dimension nouvelle dans un contexte agentique. Les agents peuvent déclencher des dizaines de builds en parallèle, sur des branches isolées, pour des features simultanées, et l'infrastructure doit absorber cette parallélisation sans que la reproductibilité ou la rapidité d'exécution en souffrent.
- Les guardrails encodent les règles de compliance et de sécurité directement dans la plateforme. Concrètement, le Product Builder avance en autonomie, et c'est la plateforme qui garantit que ce qui arrive en production respecte les standards de l'organisation. C'est la différence entre une autoroute avec des rails de sécurité et un chemin de terre.
- Le monitoring et l'observabilité, enfin, ferment la boucle d'apprentissage. Le monitoring signale qu'un comportement inattendu se produit, et l'observabilité permet de remonter à la cause en interrogeant les signaux du système. Les deux ensemble donnent au Product Builder le retour dont il a besoin pour itérer, parce que pousser en production sans lire ce qui s'y passe, c'est itérer à l'aveugle.
Mot n°4 : le Product Operating Model IA
Un Product Builder avec un OS performant, connecté à une plateforme bien conçue, c'est une unité capable et autonome. Mais une organisation n'est pas une collection d'unités autonomes. Elle est (ou devrait être) un système dont l'intelligence dépasse la somme de ses parties.
Le Product Operating Model, c'est le cadre organisationnel qui a structuré jusqu’à présent la façon dont les équipes Produit opèrent collectivement, prennent des décisions, capitalisent leurs apprentissages et maintiennent la cohérence entre des OS individuels qui tournent en parallèle. Avec la GenAI, il doit évoluer pour rester pertinent.
Enjeu 1 : décider à la vitesse de l’exécution
Quand l'exécution s'accélère, la décision doit suivre. Quand un Product Builder peut shipper en quelques heures, les rituels de priorisation hebdomadaires perdent leur fonction. Le sprint planning supposait que l'exécution était le goulot : il organisait la file d'attente devant une ressource rare et forçait, par contrainte, à prioriser avant d'engager.
Quand cette ressource devient abondante, la file d'attente disparaît, et avec elle les points de pause où le jugement s'exerçait naturellement. Le risque, c'est de décider trop lentement ou de décider vite et mal. Le POM AI recrée délibérément ces points de jugement : il organise explicitement ce qui est dans le focus stratégique, ce qui est en exploration contrôlée, ce qui attend son moment.
Enjeu 2 : transformer l’apprentissage individuel en capital collectif
La capitalisation de l'apprentissage est un enjeu d'une autre nature. La mutualisation des outils, skills partagés ou connexions MCP communes, relève de la plateforme. Mais comment l'apprentissage individuel devient-il une connaissance collective ? Comment passer de "j'ai validé cette hypothèse" à "l'organisation sait que cette hypothèse est validée et agit en conséquence" ? Le POM augmenté structure cette capitalisation en construisant une mémoire stratégique collective : les hypothèses testées, les segments compris, les directions explorées. Sans cette couche, chaque cellule redécouvre ce que les autres savaient déjà.
Enjeu 3 : gouverner sans contraindre
Quand chaque Product Builder dispose d'un OS autonome et d'un accès direct à la production, le contrôle des accès ne suffit plus. La gouvernance doit opérer à deux niveaux. Au niveau opérationnel : quelles données les OS peuvent consommer, quels périmètres les Product Builders peuvent couvrir seuls, quelles décisions nécessitent une validation collective. La plateforme encode ces règles techniquement, tandis que le POM AI les définit organisationnellement. Au niveau stratégique : quand chaque cellule est autonome et rapide, le risque de dérive est proportionnel à la vitesse d'exécution. Le POM AI pose alors un cadre de convergence fait de contraintes légères et explicites, avec une direction partagée, des limites claires et une visibilité réciproque. Plus l'exécution est décentralisée et rapide, plus ce cadre de cohérence doit être explicite et léger. Sans lui, l'autonomie distribuée se transforme en chaos.
Enjeu 4 : gérer la data comme un actif stratégique
La gouvernance de la data mérite un traitement à part. La plateforme contrôle l'accès technique, mais qui décide quelles données sont collectées, maintenues et partagées entre les cellules ? Quand chaque Product Builder consomme et produit de la data via MCP de façon autonome, sans gouvernance organisationnelle, les données se dupliquent et perdent en fiabilité. Le POM AI définit qui possède les data products, comment les standards de qualité sont établis collectivement, et comment la data produite par une cellule devient un actif accessible aux autres. Puisque la data est l'actif central de la nouvelle organisation, sa gouvernance est un enjeu organisationnel avant d'être un enjeu technique. À cela s'ajoute une question de souveraineté : quand les OS consomment de la data via des APIs hébergées hors de l'Union européenne, la localisation des données et la réversibilité des dépendances fournisseurs deviennent des enjeux de gouvernance stratégique.
Enjeu 5 : gouverner le coût et l’empreinte de l’exécution agentique
Quand l'exécution s'accélère, deux coûts s'accumulent en dehors du champ de vision individuel : le coût financier et l'empreinte carbone de chaque appel. Un Product Builder peut voir les conséquences de ses propres choix, mais une organisation de Product Builders qui opèrent en parallèle produit une consommation agrégée que personne ne pilote si la gouvernance n'a pas été pensée. Qui fixe les enveloppes budgétaires ? Quels modèles sont approuvés pour quels usages ? Qui est comptable de l'empreinte collective ? Ce sont des questions de gouvernance organisationnelle, pas des questions techniques, et c'est ce que le FinOps appliqué à l'IA et le GreenOps adressent. Sans cette couche, l'accélération de l'exécution devient une inflation à la fois financière et environnementale.
Mot n°5 : le Craft
Les quatre termes précédents décrivent ce qui change. Le cinquième aborde une question différente : qu'est-ce qui demeure irréductiblement humain quand tout cela est en place ?
Le terme “craft” vient du mouvement Software Craftsmanship : la conviction que le développement logiciel est un métier dont la maîtrise se construit dans la durée et par la pratique. Appliqué au Product Builder, le craft désigne la même idée étendue à la pratique Produit : tout ce qui s'accumule avec l'expérience et que ni les agents ni la plateforme ne peuvent reproduire. Il comprend quatre capacités :
Capacité 1 : Le Product Taste
Le “Product taste” (le “bon goût” en Produit, comprendre la capacité à prendre de bonnes décisions) en est la manifestation la plus évidente. Distinguer un vrai problème d'un faux besoin et sentir ce qui va compter pour un utilisateur avant que les données ne le confirment, c'est une intelligence contextuelle qui se forge au fil des projets. L'OS peut produire dix options, choisir la bonne pour les bonnes raisons demeure un acte de jugement humain.
Capacité 2 : l’empathie profonde
L'empathie profonde relève du même registre, même si elle opère différemment. On ne parle pas ici des personas segmentés ou des feedbacks analysés par un agent, mais de ce qui s'obtient en restant avec le problème longtemps et en comprenant le contexte d'usage derrière le comportement observé. Les agents synthétisent de l’information; ils ne comprennent pas un être humain dans sa singularité.
Capacité 3 : l’arbitrage sous incertitude
Décider lorsque les données sont incomplètes, lorsque les parties prenantes divergent, lorsque le marché envoie des signaux contradictoires. L’OS peut générer des scénarios, quantifier des probabilités, produire des analyses. Il ne peut pas porter la responsabilité du choix, ni assumer les conséquences organisationnelles d’une décision structurante.
Capacité 4 : le leadership narratif
Le leadership narratif complète le tableau. Plus qu’un simple exercice analytique, aligner une organisation autour d'une vision Produit est un acte politique et relationnel qui repose sur la confiance que des individus accordent à d'autres individus, et cette confiance se construit au fil du temps et de la relation.
Ce que la GenAI transforme, c'est le temps que le Product Builder peut consacrer à exercer ces capacités. Quand l'OS absorbe les tâches à haute fréquence et faible jugement et que la plateforme prend en charge la complexité du déploiement, le jugement et l'empathie peuvent enfin occuper la place centrale qu'ils auraient dû occuper depuis le début.
Cette libération ne se produit pas mécaniquement. Elle suppose un Product Operating Model qui organise délibérément ce que l'OS prend en charge et ce que l'humain conserve, faute de quoi l'accélération génère simplement plus de tâches à basse valeur à un rythme plus élevé.
Les mots de l'ère précédente décrivaient un monde où construire coûtait cher. Ce monde-là est derrière nous. Product Builder, OS, Plateforme, POM-AI, Craft : ces cinq termes dessinent le cadre dans lequel les organisations produit vont opérer dans les années qui viennent. La réalité a déjà changé d'état. Le langage, lui, commence à peine à rattraper son retard. Reste à savoir quelles organisations s'en saisiront pour construire leur modèle.
L'IA change le terrain, et avec lui le cadre stratégique. Pour vraiment exploiter l'opportunité de l'IA, il faut être capable de décider quoi prioriser, comment gouverner et comment embarquer leur organisation. La formation IA pour les leaders de Thiga Academy donne les outils pour passer à l'action : identifier les cas d'usage à fort potentiel dans leur organisation, construire un cadre de gouvernance adapté et structurer un plan d'action sur 30, 60 et 90 jours.
