Dans le sillage des Forward Deployed Engineers, que les labos d'IA et les hyperscalers recrutent par milliers, le titre de Forward-Deployed Product Manager débarque côté Produit avec la promesse de résoudre les problèmes chez le client, dans son environnement, avec ses données. N'importe quel PM correct fait ça depuis quinze ans, et les intégrateurs partenaires des éditeurs depuis vingt. Ce qui pourrait distinguer le FDPM d'un Consultant Salesforce tient dans une seule chose : sa capacité à peser sur la roadmap.
Ça y est, le mot est lâché. Depuis plusieurs semaines, je scrutais LinkedIn en me demandant qui allait y aller en premier. C'est chose faite : l'infographie est tombée dans mon fil un matin de septembre, avec sa tasse à café, sa pile de livres ("Customers", "AI", "Product", "Engineering") et son sous-titre en capitales espacées, "the PM role built for the AI era". Le Forward-Deployed Product Manager a désormais sa fiche récapitulative en pastel.
Je dis "en premier" avec un peu de mauvaise foi. Le titre traîne dans les offres d'emploi depuis des mois, chez Palantir, OpenAI, Scale AI, Glean ou Salesforce, et OpenAI préfère parler de "Deployed PM". Ce que l'infographie fait, c'est autre chose. Elle transforme une ligne de fiche de poste en concept à destination de la communauté Produit, avec son workflow en six étapes, ses compétences clés et sa citation manuscrite sur fond vert. Le titre sort des RH pour entrer dans le débat.
Il fallait bien que quelqu'un le pose. Depuis que les labos d'IA recrutent des Forward Deployed Engineers à tour de bras, il était évident qu'on finirait par poser le mot côté Produit. Et "à tour de bras" est un euphémisme. Les offres d'emploi de FDE ont augmenté de plus de 729 % en avril 2026 par rapport à l'année précédente, selon des données Indeed. Fin juin, AWS a annoncé un milliard de dollars pour bâtir une organisation autour de ce seul titre, et Microsoft a lancé dans la foulée Microsoft Frontier Company, 2,5 milliards et environ 6 000 experts embarqués chez les clients. OpenAI avait ouvert le bal en mai avec The Deployment Company, 10 milliards, et Anthropic a suivi avec une coentreprise de services à 1,5 milliard aux côtés de Blackstone et Hellman & Friedman. Quand l'ingénieur a son titre et son budget, le PM veut les siens.
Ce que le rôle promet
Le principe : le PM va résoudre le problème chez le client, dans son environnement, avec ses données, ses workflows et ses contraintes. L'infographie le résume dans un tableau à deux colonnes. Au PM traditionnel le "what to build" et l'équipe Produit centrale, au FDPM le "how to make it work for the customer" et un bureau chez le client. Le workflow s'allonge d'autant : Discover, Prototype, Integrate, Test, Deploy, Observe, Generalize. L'arbitrage se fait sur place, avec les gens qui vivent le problème.
Le "pourquoi maintenant" tient. En SaaS classique, on configurait, on intégrait, on formait, on déployait, et le produit restait le même d'un client à l'autre. Avec l'IA, deux boîtes qui utilisent exactement le même modèle n'ont ni le même contexte, ni les mêmes workflows, ni les mêmes garde-fous, ni les mêmes points de validation humaine. Le dernier kilomètre devient une part énorme du produit, et quelqu'un doit le parcourir. Scale AI, dans sa fiche de poste, insiste sur ce point : le FDPM n'est ni un Roadmap PM, ni un CSM, ni un Solutions Engineer, et les meilleurs savent faire la différence entre la demande formulée par le client, son vrai problème et ce que la plateforme devrait faire. Sur le papier, difficile de dire le contraire.
Un PM qui fait son travail
Maintenant, deux minutes de recul. Est-ce vraiment un nouveau métier ? Un PM qui ne met jamais les pieds chez son client, qui ne comprend pas son environnement et qui ne regarde pas ce que devient ce qu'il a livré, c'est surtout un PM qui fait mal son travail. Relisez la ligne "Key skills" de l'infographie. Deep customer discovery. Systems thinking. Savoir distinguer un besoin ponctuel de ce qui peut devenir un produit. Si vous retirez les deux compétences liées à l'IA (la maîtrise des evals, l'usage des agents de code pour prototyper vite), il reste la fiche de poste d'un Product Manager correct en 2012. Le terme décrit avec un vocabulaire 2026 quelque chose que beaucoup pratiquent depuis quinze ans.
Beaucoup, pas tous. Le PM qui pilote depuis un tableau de bord, à trois couches d'Account Managers du terrain, existe, et l'infographie a raison de le viser. Son problème se règle en le faisant sortir du bureau. Un nouveau titre n'y change rien.
Formation. Thiga Academy propose une formation de deux jours, PM augmenté par l'IA, consacrée à la conception d'assistants et d'agents IA sur l'ensemble du cycle Produit.
Les professional services, version modèles de fondation
Côté éditeur, avoir des partenaires spécialisés sur son produit n'a rien de neuf non plus. Les intégrateurs partenaires de Salesforce, SAP ou ServiceNow emploient depuis vingt ans des PM et des Consultants fonctionnels qui travaillent chez le client, avec ses données, dans ses workflows, sous ses contraintes. Ils font ce que l'infographie décrit, avec des tasses à café moins photogéniques.
a16z fait la même comparaison, et le fonds investit dans ces boîtes. Dans son papier sur la "services-led growth", il observe que les entreprises d'application IA adoptent des modèles de services d'implémentation proches de ceux de Salesforce, ServiceNow ou Workday, et que chez les meilleures, ce rôle est souvent tenu par un employé de professional services, parfois rebaptisé Forward Deployed Engineer. La thèse du fonds est assumée : les éditeurs échangent délibérément de la marge brute contre un fossé défensif, parce que la profondeur du déploiement se défend mieux qu'un tarif.
L'origine du modèle est connue. Palantir a inventé le rôle en 2005 en embarquant ses ingénieurs à la CIA, à la NSA et dans les unités de renseignement de l'armée, et les a appelés les Deltas. Pendant des années, le modèle a ressemblé à un désastre de marge pour quiconque valorisait Palantir comme un éditeur normal. Puis la marge brute est montée à 82 %, parce que les FDE ont converti leurs solutions sur mesure en logiciel réutilisable, revendu à d'autres clients. Tout le monde veut sa version de cette histoire. Thomas Otter, qui a passé des années chez Gartner à regarder des éditeurs, en tire une mise en garde que je reprends volontiers : quand une tactique devient assez sexy pour devenir "le playbook", il s'inquiète, et si votre deal médian est à 100 000 dollars alors que vous copiez le go-to-market d'une boîte qui déploie à plusieurs millions pour le DoD, vous vous racontez une belle histoire en construisant discrètement une société de conseil.
On réinvente la terminologie des professional services des éditeurs de soft. Avec des modèles de fondation à la place des ERP.
La roadmap, ou rien
Il reste un argument, et il mérite mieux qu'un bémol en fin de post. Les PM partenaires ont rarement leur mot à dire sur la roadmap de l'éditeur. Le Consultant Salesforce découvre les nouveautés de la plateforme en même temps que ses clients, dans les release notes. C'est la limite réelle du modèle actuel, et c'est exactement l'argument que les défenseurs du FDE mettent en avant : les Forward Deployed Engineers opèrent en amont de la roadmap, les consultants en aval du contrat. À Palantir, les équipes de terrain construisaient des "routes de gravier", rapides et sur mesure, pendant que l'équipe plateforme étudiait ces routes, en tirait les motifs récurrents et les asphaltait dans Foundry.
Si cette boucle existe, le mot désigne quelque chose. Si elle n'existe pas, on a un PM de SSII avec une meilleure fiche de poste et un salaire de la Bay Area. Et la boucle est fragile, les praticiens du modèle l'écrivent eux-mêmes. La métrique la plus importante d'une fonction FDE est le taux de productisation, au moins une feature reversée dans le produit cœur par engagement avant le 90e jour. La fonction doit dépendre du Produit ou de l'ingénierie, parce qu'un rattachement aux ventes tord chaque engagement vers la signature suivante et tue la boucle. Dès que la revue de performance mentionne le taux d'utilisation, l'incitation s'inverse et l'engagement est récompensé pour durer. Détail qui vaut le coup d'œil chez OpenAI : le Deployed PM est mesuré en partie sur l'expansion du compte, et travaille avec les équipes go-to-market sur la croissance à long terme. Un PM mesuré sur l'expansion du compte a intérêt à ce que le client ait toujours besoin de lui. Il existe déjà un mot pour ce métier.
Ma position tient en une phrase : le titre ne dit rien, la ligne de reporting et la métrique disent tout. Un FDPM rattaché au Produit, évalué sur ce qu'il reverse dans la plateforme, apporte quelque chose que les intégrateurs n'ont jamais eu. Le même FDPM rattaché aux ventes, évalué sur son taux d'occupation, fait le métier du Consultant SAP d'à côté, en jean plus cher.
En attendant, je trouve l'exercice amusant. Un secteur qui a vendu pendant quinze ans le logiciel sans implémentation redécouvre qu'un produit qui marche chez le client demande quelqu'un chez le client. Palantir l'avait compris en 2005, les SSII bien avant. Dans deux ans, on saura si les FDPM ont changé des roadmaps, ou si les labos auront réappris à prix d'or ce que les intégrateurs savaient déjà. La prochaine infographie est sûrement en préparation quelque part. Je parie sur le Forward-Deployed Designer.
FDE, Product Engineer, Product Builder : le combat des intitulés de poste fait rage. Découvrez ce qui les rapproche et la ligne qui les sépare dans cet article.
