FDE et product builder : deux responsabilités à relier

Deux intitulés apparus en même temps

En juin 2025, Joe Schmidt, associé chez Andreessen Horowitz, publiait « Trading Margin for Moat », une analyse qui présentait le forward deployed engineer comme le poste le plus recherché des startups d'IA. Sa démonstration s'appuyait sur un précédent daté, celui de Salesforce, ServiceNow et Workday, qui ont accepté pendant des années des marges plus faibles pour accompagner l'implémentation chez leurs clients et sont devenus ensuite des systèmes de référence. Le rôle avait été popularisé bien avant par Palantir, et en 2026 OpenAI, Google et Anthropic recrutent des FDE pour accompagner leurs clients entreprises.

Quelques jours plus tôt, le 27 mai 2025, Marty Cagan publiait sur le site de SVPG « The Era of the Product Creator », où il défendait l'idée que les outils d'IA générative permettent à un designer, à un ingénieur ou à un fondateur de prendre en charge la création produit, à condition d'assumer les quatre risques qu'il décrit depuis longtemps, la valeur, l'utilisabilité, la faisabilité et la viabilité. Il écrit que « anyone actively shaping the product and tackling the product risks is a product creator », et que le titre importe peu. En décembre 2025, LinkedIn a traduit cette idée dans son organisation, puisque Tomer Cohen, son Chief Product Officer, a annoncé sur le podcast de Lenny Rachitsky la fin du programme d'Associate Product Manager, remplacé à partir de janvier 2026 par un programme d'Associate Product Builder qui enseigne ensemble le code, le design et le product management.

Les deux intitulés circulent donc en même temps, souvent dans les mêmes discussions sur le SDLC agentique, et on les confond facilement parce que dans les deux cas il s'agit de profils capables de prototyper avec l'IA et d'aller jusqu'à la mise en production. Ce qui les distingue apparaît plus clairement quand on regarde de quoi chacun doit rendre compte.

Comprendre ce dont le FDE répond

Le FDE part du travail réel d'utilisateurs précis. Les offres qu'OpenAI publie pour ce poste décrivent un périmètre qui va de la découverte technique chez le client au cadrage, puis à la conception de l'intégration et au déploiement jusqu'à la mise en production, avec la responsabilité explicite de faire remonter les frictions rencontrées vers les équipes Produit et Recherche. Le point de départ est un métier, avec ses processus, ses outils, ses données et ses contraintes, et la question posée est celle de l'endroit où l'IA peut réellement changer la façon dont ce métier travaille.

Prenons, à titre d'exemple hypothétique, un service de comptabilité fournisseurs dans un grand groupe. Le FDE observe comment les factures arrivent, par quels canaux, quels contrôles sont faits à la main et quelles exceptions mobilisent le plus de temps des comptables. C'est à partir de cette observation qu'il prototype, avec les modèles et les outils dont il dispose, un traitement des rapprochements les plus répétitifs, qu'il teste directement avec les comptables concernés avant de l'amener, si le résultat le justifie, jusqu'en production.

Sa responsabilité se mesure à ce qui a changé dans le quotidien de ces utilisateurs, et un prototype techniquement réussi que les comptables ont abandonné au bout de trois mois reste un échec pour lui. Par ailleurs, sa valeur tient à sa capacité à arriver avec des moyens d'éditeur, quels qu'ils soient, qu'il s'agisse de modèles, de plateformes d'agents ou de composants d'intégration, pour passer vite du diagnostic à quelque chose que l'utilisateur peut essayer dans son travail réel.

Comprendre ce dont le product builder répond

Le product builder part d'un périmètre produit. Dans le modèle décrit par LinkedIn, il réunit des compétences jusque-là réparties entre le product manager, le designer et le développeur, et travaille au sein de petits pods pour amener un produit de l'idée au lancement sans les passages de relais qui structuraient une squad classique. Dans une organisation qui n'a pas fait un choix aussi radical, on peut le décrire comme la prise en charge par une seule personne, ou par un très petit nombre de personnes, de ce que portaient ensemble un business analyst, un product owner et des développeurs.

Sa responsabilité est celle d'un produit dans la durée. Il arbitre une roadmap, tient la qualité de ce qui est en production, fait évoluer le produit à mesure que les usages changent et assume les quatre risques décrits par Cagan, y compris la viabilité, qui ne se juge qu'après plusieurs cycles. Un product builder qui livre vite une première version puis ne la maintient pas n'a pas rempli son rôle, même si le lancement s'est bien passé.

Son périmètre dépasse donc un utilisateur ou un service. Ce qu'il construit a vocation à servir plusieurs populations, à être exploité, supervisé et corrigé, et c'est à cette échelle qu'il rend des comptes, bien au-delà de la première équipe qui a exprimé le besoin.

Distinguer les deux rôles par leur responsabilité plutôt que par leurs gestes

Si l'on compare les deux rôles par ce qu'ils font, la frontière est floue. Le FDE prototype et va souvent jusqu'à la production, comme le montrent les offres d'OpenAI, et le product builder prototype aussi avant de construire. Les deux utilisent les mêmes outils, travaillent vite et limitent le nombre d'intermédiaires entre une intention et un logiciel qui tourne.

La distinction devient nette dès qu'on regarde ce que chacun laisse derrière lui. Le FDE laisse un usage transformé chez des utilisateurs précis, et avec lui une connaissance fine de la façon dont ce métier travaille réellement. Le product builder laisse un produit qu'il continue de porter, avec une roadmap, une qualité à tenir et des utilisateurs qui dépendent de son évolution. Leurs risques d'échec suivent la même ligne, puisque le FDE peut multiplier des solutions sur mesure qui ne se généralisent jamais, et que le product builder peut construire rapidement un produit qui a perdu le contact avec l'usage qui le justifiait.

On peut objecter qu'il s'agit du même profil à deux moments d'un même cycle, d'abord la découverte puis la construction, et certaines personnes savent effectivement faire les deux. Pour autant, une organisation qui confie les deux responsabilités à la même personne sans le formuler lui demande de répondre à la fois de l'adoption chez quelques utilisateurs et de la tenue d'un produit pour tous, et ces deux engagements entrent en conflit dès que le temps manque, parce qu'il faut alors choisir entre le prochain utilisateur à accompagner et la dette du produit à résorber.

Organiser le passage de l'usage au produit

C'est entre les deux rôles que la valeur se perd le plus souvent. Les guides consacrés à la structuration d'équipes de FDE insistent sur ce point, et certains proposent de suivre un indicateur simple, le nombre de fonctionnalités réintégrées dans le produit à la suite de chaque intervention sur le terrain, faute de quoi ce que le FDE a appris reste attaché à un client ou à un service.

Du côté de l'organisation qui adopte l'IA, le même problème se présente dans l'autre sens. Reprenons l'exemple hypothétique de la comptabilité fournisseurs. Le prototype fonctionne, les comptables l'utilisent, et d'autres services comme les achats ou la comptabilité clients demandent quelque chose de comparable. Il faut alors décider qui transforme ce prototype en produit, qui en porte la roadmap, qui le finance au-delà de l'expérimentation et qui répond de sa qualité quand il sert plusieurs métiers. Si personne n'est désigné, le prototype reste en production sans propriétaire, ou il est reconstruit ailleurs sans ce qui a été appris auprès des utilisateurs.

Trois décisions permettent d'éviter cette perte :

- désigner, dès le démarrage d'une intervention de FDE, le product builder ou l'équipe produit qui reprendra ce qui mérite de durer - définir le critère qui fait passer un prototype de l'expérimentation au produit, par exemple un niveau d'adoption mesuré ou une demande venue d'autres métiers - organiser la transmission de ce que le FDE a appris sur le métier, et pas seulement de son code, pour que le product builder parte de l'usage réel

En septembre 2026, les deux intitulés restent instables et leurs définitions varient d'une entreprise à l'autre, ce qui rend peu utile un débat sur les titres. Pour une organisation qui veut tirer parti de l'IA dans son SDLC, la décision utile consiste à nommer séparément la responsabilité de l'usage et celle du produit, puis à organiser explicitement le passage de l'une à l'autre avant de recruter ou de former l'un ou l'autre profil.