OpenAI, Anthropic et les grands cabinets investissent des milliards dans le Forward Deployed Engineer. Derrière ce métier et deux rôles voisins, le Product Engineer et le Product Builder, une seule ligne de partage : le mur entre une preuve et un système en production. Dans cet article, le CTO de Thiga Renaud Chevalier revient sur les similitudes et les différences entre ces trois rôles.
Le 11 mai 2026, OpenAI a lancé l'OpenAI Deployment Company, avec plus de 4 milliards de dollars d'investissement initial. Une semaine plus tôt, Anthropic annonçait une nouvelle société de services IA avec Blackstone, Hellman & Friedman et Goldman Sachs. Dans les deux cas, l'enjeu est le même : ne plus vendre des modèles, mais aider les entreprises à les intégrer dans leurs opérations.
Le métier mis en avant s'appelle Forward Deployed Engineer. Ses offres d'emploi ont bondi de plus de 800 % entre janvier et septembre 2025. Ce rôle désormais financé à grande échelle vient percuter deux intitulés déjà installés : le Product Engineer, cet ingénieur qui pense Produit, et le Product Builder, né du no-code avant d'être réinventé par l'IA.
À première vue, les trois se ressemblent : ils parlent aux utilisateurs, ils construisent des choses, ils cherchent l'impact... De quoi se demander si l'industrie n'a pas inventé trois noms pour un même métier. La réponse est non. Ce qui les sépare tient à un seul point : leur position par rapport au mur qui sépare une preuve d'un système en production.
- Années 2010, Palantir invente le Forward Deployed Engineer
- 2019, le Product Engineer avant l'IA
- 2021, le Product Builder naît dans le no-code
- Le mur entre la preuve et la production
- 2026, le retour du Forward Deployed Engineer
- Pourquoi on les confond
- Ce qui les sépare
- Juge et partie, la vigilance s'impose
- Aucun des trois ne travaille seul
- Un vocabulaire pour ne pas croire à la magie
Années 2010, Palantir invente le Forward Deployed Engineer
Envoyer des ingénieurs chez le client est aussi vieux que le logiciel d'entreprise. Des pans entiers de SAP R/1 ont été construits sur les sites d'ICI et de John Deere, dans les années 1970. Des ingénieurs avant-vente aux professional services en passant par les intégrateurs, la technique au contact du client a toujours existé, sous des noms éclatés, chacun optimisant sa tranche du problème. Ce que Palantir invente au début des années 2010, c'est une façon de faire, et un nom.
Le contexte l'exige. Ses clients sont des agences de renseignement, incapables d'exprimer leurs besoins dans un cycle de discovery classique. Le besoin se découvre sur place, au contact des données et des opérations du client.
Cette méthode tient en deux ruptures. La première : pas de partenaire. Depuis toujours, le logiciel d'entreprise se déploie en triangle : l'éditeur vend, un partenaire intègre, le client exploite. Palantir casse le triangle et envoie ses propres ingénieurs installer sa plateforme dans le SI du client. Son organisation distingue deux familles : les Devs développent les plateformes Foundry et Gotham, les Deltas sont déployés chez les clients sous le titre de Forward Deployed Software Engineers. Ce sont des ingénieurs qui écrivent le code pour adapter la plateforme au terrain. Jusqu'en 2016, Palantir compte plus de Deltas que d'ingénieurs classiques.
La seconde : le terrain nourrit le produit. Là où le travail d'un consultant ou d'un intégrateur reste chez le client, celui du Delta remonte au siège et alimente la plateforme elle-même. C'est cette boucle qui distingue le FDE de tout ce qui l'a précédé.
La pratique reste propre à Palantir pendant une décennie, puis essaime. Scale AI et C3.ai adoptent le titre tel quel, Databricks et Snowflake construisent des fonctions équivalentes.
2019, le Product Engineer avant l'IA
Le deuxième rôle vient de la culture engineering. Dans les entreprises product-led, le découpage classique entre un PM qui décide et un ingénieur qui exécute montre ses limites. Coupés du terrain par des couches de process, les ingénieurs reçoivent une version aseptisée de la réalité et décident moins bien.
La réponse se construit par étapes. Chez Atlassian, le PM Sherif Mansour publie un essai sur les "Product Engineers". Gergely Orosz s'en inspire et signe en 2019 le "Product-Minded Software Engineer", portrait d'un développeur qui veut comprendre pourquoi les décisions sont prises et comment les gens utilisent ce qu'il construit. En 2023, Vercel retitre ses postes : "Fullstack" devient "Product Engineer". PostHog va plus loin et en fait un principe d'organisation : les ingénieurs y dirigent les équipes produit et parlent aux utilisateurs. Les PM n'y possèdent ni la roadmap ni les décisions.
2021, le Product Builder naît dans le no-code
Le troisième rôle naît dans la culture Produit. Il apparaît au tournant des années 2020 dans l'écosystème no-code, pour désigner un hybride de product manager et d'expert des outils visuels comme Webflow, Airtable ou Make, qu'il utilise pour créer des produits. En France, le métier de product builder no-code est même officiellement reconnu par France Compétences, certifications professionnelles à l'appui. La promesse : construire sans passer par l'ingénierie. Mais elle bute sur le plafond du Shadow IT.
Puis l'IA renverse la donne. Quand un agent génère le code en quelques heures, le travail en silos devient un luxe de lenteur. Le PM spécifie, le designer maquette, l'ingénieur implémente... Et le produit, lui, attend.
La réponse la plus radicale vient d'un CPO. Chez LinkedIn, Tomer Cohen lance en 2024 le programme Full Stack Builder : le développement produit devient le travail d'un seul professionnel assisté d'IA, au lieu d'une chaîne de tâches. Puis LinkedIn institutionnalise le modèle. Le programme historique Associate Product Manager est remplacé par un Associate Product Builder, qui enseigne ensemble le code, le Design et le Product Management. Le titre reçoit son parcours de carrière, ouvert à quiconque veut porter un produit de l'idée au lancement, depuis n'importe quelle fonction.
LinkedIn parle de "Full Stack Builder", Meta de "AI builders". Le terme se répand : "Builder" désigne désormais quiconque repère un problème et mobilise l'IA pour le résoudre.
Le Product Builder, né dans le no-code, change d'échelle avec l'IA et incarne une nouvelle capacité. La question n'est plus "qui décide dans l'équipe ?" mais "jusqu'où une personne peut-elle aller seule ?".
Aller au bout d'un produit, seul. Apprenez à concevoir vos propres assistants et agents IA, et à augmenter votre impact sur tout le cycle Produit, avec la formation PM augmenté par l'IA.
Le mur entre la preuve et la production
La réponse tient en une phrase. Si construire est devenu trivial, opérer en production ne l'est pas.
Le marché l'a chiffré. Selon le MIT, 95 % des déploiements d'IA en entreprise ne produisent aucun résultat mesurable, et McKinsey arrive au même ordre de grandeur : huit entreprises sur dix sans gain concret sur leurs résultats. Surtout, le MIT nomme la cause : non pas les modèles, mais leur intégration en entreprise. Ce passage du pilote au système qui tourne dans un SI réel, avec ses données legacy, ses comités et sa conformité. C'est le premier enseignement chiffré de la vague IA. Il dessine un mur entre la preuve et la production : sécurité, scalabilité, compliance, observabilité, run. Le code ne coûte presque plus rien, mais cette exigence-là n'a pas bougé.
L'industrie commence à le codifier. Avec AI-DLC, sa méthodologie de développement piloté par l'IA, AWS trace la frontière. Les systèmes simples, constructibles par des non-développeurs, sont renvoyés au no-code. La méthode vise les systèmes complexes, ceux qui exigent de l'architecture et de la conformité. La sortie y est un artefact à part entière : du code packagé, passé au crible des évaluations et testé pour la sécurité, les exigences non fonctionnelles et les risques opérationnels. Le prod-ready devient un véritable étage de qualification.
Le territoire du Product Builder s'étend de l'idée à la preuve. Et il est vaste. Mais au mur, son autonomie s'arrête. Qui le franchit ?
Le Product Engineer, d'abord. C'est sa définition même : l'architecture, la qualité, le run, la redevabilité sur ce qui tourne. Là où le Builder prouve, l'Engineer met en production. Des trois rôles, c'est le seul dont l'ownership inclut nativement l'autre côté du mur, et c'est lui qui construit les produits complexes destinés à la prod. Plus les preuves arrivent vite, plus celui qui les fait passer devient critique. C'est ainsi que l'IA, sans créer le rôle, le consacre.
2026, le retour du Forward Deployed Engineer
Le retour du FDE part d'un problème, celui des éditeurs de modèles. Ils ont promis une valeur considérable et levé des milliards dessus. Mais leurs pilotes échouent au pied du mur : la promesse ne tient pas, et la hype menace de se retourner contre eux. Il faut franchir le mur chez les clients, à grande échelle et vite. Les ESN et les cabinets n'ont ni le volume ni la rapidité nécessaires, et la demande de FDE a bondi de 800 % en neuf mois sur un vivier de talents trop rare. Alors les éditeurs montent leur propre structure, sur le modèle de Palantir.
OpenAI établit le poste en 2025 et le distingue explicitement du Solution Architect. La fiche officielle est sans détour : le FDE possède le discovery, le cadrage technique, le system design, le build et le rollout en production, avec jusqu'à 50 % de déplacements. Son succès se mesure à l'adoption en production, à l'impact sur les workflows, à un retour terrain qui infléchit les roadmaps, côté produit comme côté modèle.
On retrouve la boucle de Palantir, poussée bien plus loin. Ce que le FDE apprend chez un client peut redescendre dans le produit, et jusque dans le modèle d'IA lui-même, au bénéfice de tous les autres.
Mai 2026 industrialise l'approche. La Deployment Company d'OpenAI réunit plus de 4 milliards de dollars et dix-neuf investisseurs menés par TPG, dans une entité majoritairement détenue par OpenAI. Les grands cabinets de conseil n'ont pas été évincés : ils sont entrés au capital. Hier, l'éditeur passait par les partenaires pour entrer dans le SI. Aujourd'hui, les partenaires investissent dans le véhicule de l'éditeur. La co-entreprise d'Anthropic suit la même logique, avec Blackstone, Hellman & Friedman et Goldman Sachs.
Le titre se répand. Salesforce s'engage sur une équipe de 1 000 FDE. Deloitte recrute ses propres "Forward Deployed Engineers (AWS)", des pods embarqués chez les clients sur la stack d'Amazon, pendant qu'AWS, fidèle à sa nomenclature historique, continue d'appeler les siens Solutions Architects. Déployer chez le client pour le compte de l'éditeur est devenu une industrie.
La structure financière trahit l'enjeu. Ces montages dépassent de loin un simple recrutement. La presse financière rapporte que le véhicule d'OpenAI garantirait à ses investisseurs un rendement minimum de 17,5 % par an sur cinq ans. On ne structure pas ainsi un pari. On structure une obligation de résultat.
Pourquoi on les confond
Trois rôles, trois époques, trois cultures : l'éditeur pour le FDE, l'engineering pour le Product Engineer, le Produit pour le Builder. Et pourtant, leurs fiches de poste se recouvrent largement, autour du discovery, du build, du déploiement, de la mesure d'impact, de l'autonomie.
L'IA fait fondre les frontières entre rôles, partout en même temps. Le FDE de 2026 réunit en une personne ce que Palantir répartissait entre plateforme et terrain. Le Full Stack Builder, lui, absorbe ce qui revenait au PM, au Designer et à l'ingénieur. Même cause, même effet : les silhouettes de compétences convergent.
Elles convergent vers une forme que Kent Beck a nommée bien avant l'IA : le Paint Drip. Au profil en T, profond sur une seule compétence, Beck oppose une autre image. Le pinceau balaie la toile, c'est l'exploration permanente ; les coulures qui descendent sont les spécialisations successives, dont on ne sait jamais à l'avance jusqu'où elles iront. Produit, ingénierie, métier, évaluation : les trois rôles exigent ce profil multi-profondeurs. Quand les compétences se superposent, on croit voir le même métier.
Ce qui les sépare
Les silhouettes convergent, pas les positions. Quatre questions les départagent.
La première : où s'arrête l'ownership ? Le Product Builder s'arrête à la preuve. Le Product Engineer va jusqu'à la production. Le Forward Deployed Engineer, lui, la pousse jusque dans le SI d'un autre.
La deuxième porte sur la couverture du cycle. Sur la séquence Inception, Construction, Operations que formalise l'AI-DLC, le Builder domine l'amont. L'Engineer tient la construction puis les opérations. Quant au FDE, il traverse tout le cycle, mais chez le client.
La troisième oppose intégrer et créer. Le Builder et l'Engineer créent. Le FDE est né intégrateur avant de devenir créateur, seul à se tenir entre les deux. Cette position hybride est sa signature.
Reste la question que les fiches de poste n'écrivent jamais : qui l'envoie, et pour le compte de qui ? Le Product Builder et le Product Engineer travaillent pour l'organisation qui construit, salariés ou consultants. Le Forward Deployed Engineer est envoyé par l'éditeur dans le SI du client, pour y déployer la solution de l'éditeur. Et ce qu'il y apprend nourrit la roadmap de l'éditeur.
Juge et partie, la vigilance s'impose
Cette dernière question mérite qu'on s'y arrête. Le FDE qui entre dans votre SI cumule trois casquettes que les gouvernances d'achat ont toujours pris soin de séparer. Le même homme conseille votre architecture, vous vend la solution qu'il a conseillée, puis rend compte de la mission à celui qui l'emploie. Un consultant, donc, à qui il manque la seule chose qui fait le consultant : ne pas avoir d'intérêt dans la réponse.
La conséquence porte un nom : le verrouillage. Chaque mission FDE câble la stack de l'éditeur au cœur de votre système d'information, là où vivent vos données et vos contrôles. Ce qui était hier une dépendance applicative remplaçable devient une dépendance d'architecture. Elle s'installe à la vitesse du FDE, c'est-à-dire vite. C'est précisément ce pour quoi il est payé.
Reste à l'encadrer. Exigez la réversibilité dès le contrat. Gardez des évaluations indépendantes de celles de l'éditeur, puisque c'est lui qui mesure son propre succès. Et adossez chaque FDE à vos propres Product Engineers : le transfert de compétence est la seule porte de sortie qui vous appartient.
Aucun des trois ne travaille seul
Une dernière leçon traverse les trois cultures, et elle contredit le fantasme du héros solitaire que ces titres véhiculent.
Palantir a structuré le rôle en équipes, adossées aux équipes plateforme. Dans l'AI-DLC, AWS fait converger les silos techniques mais conserve délibérément le Product Owner, les développeurs et la QA, réunis dans des rituels collectifs où l'équipe entière valide ce que l'IA propose. McKinsey aboutit au même constat : les équipes de huit à douze personnes cèdent la place à des pods réduits de professionnels très qualifiés, qui supervisent l'exécution par agents. La polyvalence a ses limites : le risque, la charge cognitive, le piège de tout faire à moitié. Elles tiennent même quand les agents démultiplient la personne. L'unité de production qui se stabilise reste collective. C'est le pod, à géométrie variable.
Et ce qui règle la taille du pod, c'est la plateforme. Lee Robinson, qui a rebaptisé les rôles chez Vercel, pense le Product Engineer en couple avec le Platform Engineer, l'ingénieur qui construit ce sur quoi les autres s'appuient. Plus la plateforme encaisse, avec ses guardrails, ses golden paths, sa compliance automatisée, plus le mur s'abaisse et plus le pod rétrécit. Le bâtisseur de plateforme ne dispute pas le match. Il en fixe les règles.
Un vocabulaire pour ne pas croire à la magie
Ces trois noms ne fusionneront pas, parce qu'ils répondent à des besoins différents. Le Builder mène vite à la preuve. L'Engineer tient le système en production. Le Forward Deployed Engineer fait entrer la solution d'un éditeur dans un SI complexe, et mieux vaut alors savoir ce qu'il y câble. Chacun travaille en pod, dont la plateforme fixe la taille.
Le bon mot, au bon moment, désamorce une croyance qui grandit en face. L'agent de code impressionne : on décrit, la machine produit. D'où l'illusion qu'avec assez d'agents, on mettrait en production ce que plus personne ne comprend. Le terrain dit l'inverse, les chiffres aussi.
La génération de code tient de la magie. La mise en production reste un métier. Confondre les deux, c'est confondre la démo et le réel. Ces trois rôles ne se confondent pas. Les nommer, c'est commencer à piloter la rupture en cours.
Le Product Builder au travail. Pierre Sur, Product Builder chez Thiga, montre comment il utilise Claude au quotidien (second brain, assistant PRD, spec driven development) dans cette vidéo.
