FDE : La nouvelle frontière des postes d'ingénierie pilotés par l'IA

Au cours du dernier mois, j'ai rencontré quatre amis préparant une transition de carrière — développeur frontend, architecte de solutions, produit manager, ingénieur algorithmique traditionnel — avec des profils, âges et villes différents, mais ils ont tous posé la même question : FDE [2] vaut-il la peine que j'y aille ?

FDE, abréviation de Forward Deployed Engineer [2]. Il y a deux ans, c'était encore un jargon interne à Palantir ; aujourd'hui, il est devenu silencieusement une phrase d'accroche pour les recruteurs, un poste fréquemment mentionné dans les offres d'emploi et l'une des réponses candidates à la question « le poste le plus précieux de l'ère de l'IA ». OpenAI a directement créé une entreprise dédiée nommée Deployment Company [3] en mai 2026, avec un investissement initial de 4 milliards de dollars, affirmant clairement son intention d'envoyer des ingénieurs sur site chez les clients pour s'intégrer à leurs flux de travail ; l'équipe Applied AI d'Anthropic recrute également des FDE simultanément dans quatre fuseaux horaires. Ce terme est passé du jargon interne au vocabulaire courant en un peu plus d'un an.

Dans mon article précédent, « À l'individu exceptionnel » [4], j'ai examiné le « moteur humain » — la curiosité, l'apprentissage autodidacte, l'initiative personnelle et les compétences pratiques — et comment ils sont stimulés dans un Closed-loop complet. Mais les individus ne sont pas flottants ; ils doivent être accueillis par un système de coordonnées professionnelles concret. Si l'individu exceptionnel est la « matière première » des relations de production à l'ère de l'IA, alors le FDE est la forme d'emploi la plus évidente qui a émergé sur le marché cette année.

À mon avis, FDE n’est ni dans la case « conseil », ni dans la case « externalisation ». Il est le plus proche de l’individu super, la différence résidant uniquement dans le fait que FDE est un individu super organisé dans la faille entre « entreprise modèle × client ».

Saviez-vous d’où vient le terme Forward Deployed ? Il provient à l’origine du vocabulaire militaire américain Forward Deployed Forces, qui désigne les unités déployées à l’étranger ou en première ligne, capables de répondre rapidement, par opposition aux forces restées sur les bases nationales. Palantir a introduit ce terme dans l’industrie du logiciel à la fin des années 2000 pour décrire le modèle consistant à envoyer des ingénieurs quitter le siège pour s’installer sur site chez les clients ; les équipes internes étaient même nommées selon l’alphabet phonétique militaire, sous les noms Delta et Echo. Ce récent retour de ce concept par OpenAI et Anthropic n’est pas une coïncidence — l’essence même d’envoyer des ingénieurs sur le terrain n’a jamais changé.

Les trois interrogations spécifiques auxquelles cet article répond est ce que les quatre amis ont posées récemment :

FDE est-elle une société de conseil déguisée en IA ? Où se situe sa frontière avec le conseil traditionnel ?

FDE est-il un外包 logiciel plus avancé ? Quelle est la différence avec ce que je fais actuellement en tant que sous-traitant ?

- Suis-je adapté pour le poste de FDE ? Quels types de personnes seront amplifiés par ce poste, et quels types seront écrasés ?

L'attitude de l'auteur est prudemment optimiste : le FDE est réellement en train de se développer, mais il n'est loin d'être la solution de transition pour tous. Il est plus important de bien l'expliquer que de le rendre populaire.

Si l’on ne pouvait retenir qu’un seul événement pour marquer le point de renaissance de FDE dans cette vague, l’auteur choisirait le 11 mai 2026 — jour où OpenAI a annoncé la création de la Deployment Company [5], avec Brad Lightcap, son COO, quittant son ancien département commercial pour prendre en charge les projets spéciaux directement sous la supervision de Sam Altman, en tant que responsable à plein temps. La même semaine, OpenAI a acquis l’entreprise britannique de conseil en IA Tomoro, intégrant du jour au lendemain 150 Forward Deployed Engineers et Deployment Specialists au sein de la nouvelle entité.

Il est à noter que la page de recrutement d'OpenAI affiche simultanément une dizaine de postes FDE : San Francisco, New York, Washington, ainsi que des orientations verticales par secteur comme Life Sciences, Semiconductor, Gov, etc., et le poste même de recruteur FDE [6] est également ouvert. Les analystes estiment que cette équipe s'élargira à 2 000 à 4 000 personnes en trois ans. Ce n'est pas la taille d'un groupe de recherche, c'est une armée régulière.

Anthropic effectue presque une action miroir. Le poste d'ingénieur forward deployed au sein de l'équipe Applied AI [7] est ouvert simultanément à Boston, New York, Seattle, San Francisco, Washington et Londres, avec une exigence de déplacements sur site chez les clients de 25 % à 50 %. Un exemple récemment souvent cité est l'entreprise de technologie financière FIS — qui a explicitement déclaré dans son annonce : « L'équipe Applied AI d'Anthropic et les ingénieurs forward-deployed sont intégrés à FIS pour concevoir conjointement l'agent IA Financial Crimes et transférer leurs connaissances à FIS afin qu'elle puisse ultérieurement étendre de manière autonome davantage d'agents ».

Ces mots révèlent la réalité du poste de FDE. Ce n’est pas un architecte pré-vente, ni un SDR, ni un évangéliste venu former les clients. C’est un ingénieur qui apporte des modèles et s’installe directement dans le dépôt de code du client. Brad Lightcap l’exprime encore plus clairement : « Nos clients nous ont dit qu’ils avaient besoin de la capacité de passer du pilot à la production. Deployment Company, c’est envoyer nos ingénieurs au sein de leurs équipes, avec les ressources nécessaires pour livrer. »

Dessinez cela sous forme de schéma, et les relations entre les trois parties deviendront très claires :

Notez les deux lignes les plus informatives sur ce graphique : les retours envoyés par FDE dans les deux directions. Du côté des clients, FDE ne vend pas le modèle comme un SaaS, mais intègre les données, les autorisations, la conformité et les systèmes internes des clients en un seul flux capable d'exécuter le modèle. Du côté des entreprises de modèles, FDE ramène les véritables problèmes et échantillons d'échec des clients à l'équipe produit et recherche, influençant la feuille de route — un schéma d'appel d'outil qui échoue répétitivement pourrait devenir la prochaine abstraction intégrée dans le SDK.

C’est pourquoi FDE a été réactivé simultanément par deux des principales entreprises de modèles lors de cette vague — ce n’est pas aussi simple que « nous aussi, nous allons faire du conseil comme Palantir ». C’est un dispositif de collecte de signaux pour les entreprises de modèles : les points de douleur des clients les plus fréquents en première ligne ne peuvent être captés qu’en ayant quelqu’un de l’entreprise sur place ; les demandes transmises par des partenaires sont toujours filtrées. Anthropic suit une approche hybride : elle gère FDE en interne tout en établissant des réseaux de déploiement conjoints avec des sociétés de conseil et des géants du capital-investissement. L’un privilégie l’auto-gestion, l’autre l’écosystème, mais le noyau est identique : les entreprises de modèles ne sont plus seulement des fournisseurs d’API — elles envoient directement des ingénieurs au sein des produits de leurs clients.

Les deux questions les plus courantes à répondre sont : où se situe la frontière entre le FDE et le conseil traditionnel (du type McKinsey, Accenture) ? Et est-ce la même chose que l’externalisation logicielle que nous connaissons ?

Beaucoup de personnes, lorsqu'elles entendent pour la première fois la description du poste de FDE, réagissent en disant : « Ce n'est pas simplement la nouvelle version de McKinsey ou d'Accenture ? »

Je comprends cette association. Porter un costume, se rendre sur site chez les clients, dessiner sur un tableau blanc dans une salle de réunion client et aligner les dirigeants C-level — sur le plan visuel, les FDE et les conseillers en stratégie semblent effectivement similaires. Mais dès que l’on pousse un peu plus loin, la nature même de leur travail diffère complètement. Le conseil vend des limites de processus, tandis que le FDE vend des limites de modèle.

Placer ces deux éléments côte à côte dans un tableau fait immédiatement apparaître les différences.

La ligne la plus méritant une pause dans ce tableau est « Amortissement des actifs ».

La logique la plus rentable du conseil traditionnel réside dans la réutilisation des actifs — une proposition destinée à une banque peut être légèrement modifiée et revendue à la suivante ; un playbook numérique pour le secteur de la vente au détail peut être réutilisé auprès de trente clients. C’est le modèle économique fondamental qui a permis à Accenture, Deloitte et McKinsey Digital de se développer au cours des trente dernières années.

FDE ne possède pas ce type d'actif. Les capacités des modèles évoluent rapidement — aujourd'hui, il faut encore concevoir soigneusement des chaînes de prompts, mais la prochaine version du modèle pourra peut-être y parvenir avec une seule phrase. La « matérialisation méthodologique » des consultations perd rapidement de sa valeur face à cette vitesse. Ainsi, FDE ne peut pas utiliser un modèle de réutilisation d'actifs ; il doit à chaque fois exécuter un cycle complet : réévaluer les limites du modèle, sélectionner à nouveau les outils et recomposer la forme du produit. Cela semble inefficace, mais c'est en réalité la seule manière de suivre la vitesse des modèles.

Saviez-vous ce qu’est le Product Overhang ? Dans mon précédent article « À l’individu super » [4], j’ai expliqué ce terme : la capacité du modèle dépasse la forme de produit actuelle, mais il manque un point d’entrée, des autorisations et un contexte pour le concrétiser. La valeur du poste FDE réside essentiellement à transformer les Overhang suspendus dans les scénarios clients en un produit concret et opérationnel. Le client n’achète pas des quotas d’appels d’API de modèle, mais la capacité « à concrétiser réellement cet ensemble d’Overhang dans son propre business ».

Cela explique également la différence dans la ligne « structure du projet ». La structure standard d'un projet de conseil est le SOW (Statement of Work) + le WBS (Work Breakdown Structure) + les livrables par phase : le contrat précise clairement ce qui doit être livré, quand et selon quels critères d'acceptation. Ce cadre suppose que les objectifs sont déjà définis avant la signature du contrat.

Le modèle de projet de FDE ne fonctionne pas de cette manière. La phrase la plus fréquemment entendue des clients est : « Je sais que l'IA devrait pouvoir m'aider à faire quelque chose, mais je ne sais pas quoi. » L'objectif fait lui-même partie du projet. Ainsi, FDE n'accepte pas de SOW, mais des missions — une direction relativement floue ; puis, à travers des itérations, affiner progressivement cette direction ; enfin, lors d'une de ces itérations, transformer les modèles accumulés en un produit concret.

La ligne « livrable » mérite également d'être développée. Après le départ de FDE, ce qui reste dans le système client est une fonctionnalité opérationnelle — peut-être petite, peut-être laide, peut-être sans interface utilisateur, mais elle est réellement appelée, modifiée et critiquée chaque jour. Les livrables du conseil sont des PPT et des rapports de gestion du changement ; même si du code a été écrit ou un ERP configuré dans le cadre du projet, ce qui reste entre les mains des dirigeants clients est toujours un document méthodologique.

La ligne « fossé compétitif » est la plus subtile. Le fossé compétitif de FDE réside dans la sensation en temps réel des limites des capacités du modèle — combien de scénarios clients réels avez-vous exécutés ce mois-ci ? Plus vous en avez exécutés, mieux vous savez ce que Claude 4.7 peut faire et ce qui doit attendre Claude 5. Cette sensation ne peut pas être inscrite dans une présentation PowerPoint ni intégrée dans une base de connaissances ; elle ne peut exister que dans la tête des ingénieurs ayant travaillé sur ces sujets au cours des 90 derniers jours.

Donc, la prochaine fois qu'une personne dit « FDE n'est rien d'autre qu'une nouvelle version d'Accenture », vous pouvez répondre ainsi : les ingénieurs d'Accenture réinventent les processus des clients, tandis que FDE explore de nouveau les limites du modèle. Les actifs du premier peuvent s'accumuler pendant dix ans, tandis que ceux du second doivent être recréés tous les 90 jours.

Si dire que « FDE est la nouvelle version d’Accenture » constitue une première méprise, alors dire que « FDE est un prestataire de logiciels coûteux » en constitue une seconde. Cette couche est plus trompeuse, car les preuves apparentes semblent très convaincantes : FDE se rend effectivement sur site chez les clients pour écrire du code, développe réellement des fonctionnalités personnalisées selon les besoins des clients, et est effectivement appelée pendant les heures de travail des clients. À première vue, elle n’est pas différente d’un ingénieur externalisé.

Mais dès qu'on regarde le circuit de rétroaction, la différence ne peut plus être cachée.

La différence la plus cruciale dans ce graphique n'est pas la simplicité de la partie supérieure, mais la présence d'une chaîne de rétroaction s'étendant vers l'entreprise de modèles dans la partie inférieure. Cette chaîne n'est pas un élément décoratif ; c'est la raison fondamentale de l'existence du poste de FDE. En décomposant cette différence, on peut identifier au moins quatre paires de contrastes.

Les choses auxquelles on se connecte sont différentes. Pour les sous-traitants, on se connecte à un SOW — une liste de besoins clairement définie avant la signature du contrat : quelles fonctionnalités développer, quel stack technologique utiliser, selon quels critères d'acceptation, et quelles indemnités en cas de manquement. Les FDE, eux, se connectent à une mission — le client n'a pas encore bien défini ce qu'il veut, il sait seulement que « l'IA devrait pouvoir m'aider à faire quelque chose ». Le SOW repose sur la certitude, la mission sur l'exploration. Deux approches de démarrage de projet totalement différentes.

Les domaines traités sont différents. Le prestataire externe se charge de livraisons partielles — un module, un site web, un pipeline de données — puis termine, livre et passe à la prochaine entreprise. FDE assure une approche de bout en bout — depuis la résolution des problèmes métier, jusqu'à la sélection du modèle, la conception de la forme produit, et la rétention et la désabonnement des utilisateurs réels après le déploiement.

Le mode de facturation est différent. C’est ce qui va le plus à l’encontre de l’intuition. Une entreprise de modèles envoie un FDE sur site client, et ce qui l’intéresse au final ne se limite pas à la facturation de ce projet unique : combien de tokens ce client consommera-t-il à l’avenir ? Deviendra-t-il un client récurrent ? Étendra-t-il ses utilisations à d’autres lignes de business ? Le véritable KPI du FDE, c’est la courbe de consommation à long terme des tokens du modèle, et non le chiffre inscrit sur le bon de réception du projet.

Les retours ont des destinations différentes. C’est le groupe le plus profond parmi les quatre. Dans les projets externalisés, les retours du client ne remontent jamais au-delà de l’entreprise externalisée et n’affectent pas les produits futurs que cette dernière vend à d’autres clients. En revanche, les retours des FDE reviennent vers la feuille de route de l’entreprise de modèles — chaque difficulté rencontrée par le client dans un scénario réel, chaque échec de prompt, chaque bogue d’appel d’outil, devient une entrée pour les prochaines versions de données d’entraînement, de conception d’outils et de fonctionnalités produit. Autrement dit, chaque client déployé en tant que FDE est, pour l’entreprise de modèles, un partenaire de conception naturel.

C’est la véritable raison pour laquelle les entreprises de modèles paient des salaires élevés pour recruter des FDE. Elles ne vendent pas seulement un service ; elles collectent sur site des signaux réels sur la forme des produits auprès des clients. Ces signaux ne peuvent être achetés, captés ni obtenus par enquête — ils ne peuvent être ramenés que par un ingénieur concret, qui a heurté plusieurs fois les murs dans le flux de travail spécifique d’un client.

Saviez-vous que le package total des FDE chez OpenAI et Anthropic peut atteindre combien ? Selon les données publiées sur Levels.fyi pour les ingénieurs logiciels chez Anthropic [8], la médiane du package total pour un SDE expérimenté atteint déjà 710 000 $ US. Le poste de FDE comporte un risque plus élevé — il implique de faire face à l’incertitude des capacités du modèle, à l’incertitude des activités clients, ainsi qu’à l’incertitude de la forme du produit. Ainsi, selon une synthèse du secteur [9], les packages totaux des FDE de niveau intermédiaire à avancé dans les laboratoires d’IA de pointe se situent généralement entre 350 000 $ et 550 000 $ US, avec les niveaux Staff et supérieurs pouvant atteindre plus de 630 000 $ US. Ce salaire ne rémunère pas simplement des « heures externalisées », mais récompense celui qui assume la combinaison des trois risques : produit + client + modèle. > Rappelons-nous 2006, lorsque j’ai commencé ma carrière dans une entreprise publique chinoise, en pleine transformation numérique. À l’époque, les consultants d’Accenture étaient présents sur site, et notre groupe devait payer à Accenture 3 500 yuans par jour pour leurs services — un engagement qui a duré plusieurs années, et qui a été qualifié de « golden collar » par les médias de l’époque. Plus tard, j’ai rejoint l’allemande SAP, qui a même défini un nouveau terme dans le secteur du conseil : le consultant SAP est devenu le symbole même du « golden collar ». De ce point de vue, les salaires des FDE devraient continuer à augmenter sur les 24 à 36 prochains mois, tout comme la demande.

L'externalisation est une forme d'arbitrage du travail, tandis que le FDE est un capteur de terrain. Confondre ces deux notions amène le client à croire qu'il peut recruter le FDE selon une approche SOW, et pousse les candidats à aborder le poste de FDE comme un emploi externalisé. Les deux côtés heurteront rapidement un mur.

Beaucoup de gens pensent à tort que le terme FDE a été inventé par OpenAI. En réalité, non. Il possède deux racines historiques : l'une provenant de Palantir, l'autre des entreprises de modèles de nouvelle génération après 2023. En comparant ces deux racines côte à côte, on comprend mieux ce que fait réellement le poste de FDE.

Regardez d'abord une ligne du temps.

La première racine est Palantir.

Palantir a été fondée en 2003 par Peter Thiel, Alex Karp, Joe Lonsdale et d'autres, avec pour premiers clients des agences de renseignement américaines. Karp, qui n'avait pas de formation en informatique, avait poursuivi un doctorat en philosophie auprès de Jürgen Habermas à Francfort, avant d'être recruté par Thiel pour devenir PDG aux États-Unis. Le poste de FDE est né précisément de cette combinaison atypique de « PDG non traditionnel + clients hautement classifiés » : selon un article de rétrospective de 36Kr [10], Palantir a été violemment critiqué au début par les agences de renseignement, qui reprochaient aux ingénieurs de ne pas avoir accès à des scénarios opérationnels réels, les exigences étant déformées au fil des transmissions. Par la suite, Palantir a négocié un accord permettant à ses ingénieurs d'aller directement sur les sites clients et de travailler aux côtés des analystes du renseignement. Ce modèle a ensuite été systématisé par Shyam Sankar, devenant ainsi le prédécesseur du FDE.

En 2009, les FDE se sont étendus au domaine commercial. Lorsque JPMorgan a déployé la plateforme Metropolis de Palantir, 120 FDE ont été intégrés pour surveiller les menaces internes. À partir de ce moment, les FDE ne se limitaient plus à « envoyer des ingénieurs sur le terrain », mais constituaient une approche systématique d'intégration client : faire réellement entrer Foundry / Gotham dans les flux opérationnels des clients, plutôt que de simplement livrer une licence et partir.

Le recrutement FDE de Palantir suit une règle contre-intuitive — aucune formation en informatique n'est requise. Cela peut être inclus dans « Saviez-vous que ? »

Saviez-vous que Palantir FDE ne demande pas de diplôme en informatique ? Selon les critères de recrutement de Palantir compilés par SkillScouter [11] et la page carrières officielle de Palantir [12], Palantir accueille explicitement les candidats provenant de domaines autres que l’informatique ; les derniers recrutés en tant que FDE provenaient de disciplines telles que le génie mécanique, l’économie et la philosophie. Les deux seuls critères réellement décisifs sont : la capacité à agir malgré des informations incomplètes, et la capacité à dialoguer directement avec des clients C-level. Un diplôme en informatique est un atout, pas une condition d’entrée. Karp lui-même est le premier exemple de cette règle — un PDG diplômé en philosophie, qui a dirigé une équipe de FDE issus de la physique, des mathématiques et de la philosophie.

La deuxième racine est une entreprise de modèles de nouvelle génération après 2023.

Après le lancement de ChatGPT à la fin de 2022, OpenAI a rapidement réalisé une chose : brancher l’API du modèle sur la documentation et laisser les clients l’intégrer eux-mêmes était tout simplement impossible. Les clients ne refusaient pas de l’utiliser ; ils ne savaient tout simplement pas comment le faire — ils avaient des problèmes métier, mais pas de forme produit. C’est ainsi qu’OpenAI, Anthropic, Cohere, Scale, Glean, Sierra, Hebbia et Decagon ont commencé à recruter massivement des FDE.

Cette vague de FDE reprend le playbook de Palantir — envoyer des ingénieurs sur site client pour mettre en œuvre un flux de travail de bout en bout. Mais le support produit est désormais totalement différent : les FDE de l’ère Palantir se concentraient sur l’intégration de données et la personnalisation d’interfaces, tandis que les nouveaux FDE travaillent sur la conception de prompts, l’orchestration d’agents, l’appel d’outils et l’intégration de flux de travail.

Dans l'article dédié à FDE par Pragmatic Engineer [13], cette nouvelle version est appelée « embedded with enterprises to make Claude solve real, specific, high-value problems » — une formulation presque identique à celle utilisée par Palantir à l'époque, à la différence près que le terme « données » a été remplacé par « modèle ».

En regardant ces deux racines ensemble, on peut observer un ensemble de points communs et de différences très clairs.

Point commun : les clients n'achètent pas un logiciel. Ils achètent une « équipe d'ingénieurs + un ensemble d'outils » capable de résoudre leurs problèmes. Ce phénomène était anormal dans l'histoire de 30 ans des logiciels d'entreprise. SAP, Oracle et Salesforce vendaient le logiciel lui-même — les ingénieurs étaient des ressources d'appoint destinées à « rendre ce logiciel accessible aux clients ». Palantir inverse cette logique : les outils existent comme des leviers pour permettre aux FDE de résoudre les problèmes des clients. Les nouvelles générations d'entreprises de modèles ont hérité de cette relation inversée — OpenAI ne vend pas une licence GPT-4, mais « nos FDE utilisent GPT-4 pour vous automatiser votre service client ».

Différence : L'ère de Palantir privilégie l'intégration OPS — l'accent est mis sur l'intégration des données, la modélisation ontologique et la gouvernance des autorisations. La nouvelle génération se concentre sur la mise en œuvre des capacités des modèles — l'accent est mis sur la conception des prompts, l'orchestration des agents et l'optimisation de la rétention. La première ressemble à une version avancée d'intégrateur de systèmes, la seconde à une extension de l'ingénieur produit.

Un dernier fait intéressant : de nombreux anciens FDE de Palantir sont devenus des entrepreneurs ou ont directement rejoint des entreprises de nouveaux modèles. On peut citer une longue liste d’anciens de Palantir parmi les premières équipes d’Anthropic, d’OpenAI, de Sierra et de Hebbia. Ce n’est pas une coïncidence — le poste de FDE oblige une personne à assumer simultanément les risques produits, clients et techniques, ce qui revient presque à une formation d’entrepreneur. L’auteur préfère considérer Palantir comme un incubateur d’entrepreneurs invisible : il forme non seulement des ingénieurs, mais aussi des personnes capables de faire avancer un projet de zéro à un malgré des informations incomplètes. Deux racines qui se sont finalement réunies après 2023.

La convergence des deux racines se produit principalement à l'étranger. En Chine, le terme FDE n'est apparu que récemment, mais les activités qu'il désigne ne sont pas apparues de nulle part. Pour comprendre le FDE en Chine, il faut d'abord identifier ses deux prédécesseurs locaux, puis les trois différences contextuelles entre le FDE chinois et le FDE américain.

Deux précurseurs locaux

Le premier ancêtre est l'architecte de solutions des fournisseurs de cloud. Au cours des dix dernières années, Alibaba Cloud, Tencent Cloud et Huawei Cloud ont formé une équipe complète d'architectes de solutions (SA) chargés de présenter des architectures aux clients, d'écrire des POC, de concevoir des plans de migration et de collaborer à la livraison jusqu'à la mise en production. Au sein de Huawei, une série dédiée d'« ingénieurs de livraison » est responsable de la mise en œuvre des projets dans les datacenters des clients. Ce système couvre déjà 80 % des tâches liées au FDE, mais son accent reste mis sur la phase pré-vente et le déploiement — la responsabilité de l'itération produit dans son ensemble ne repose pas sur les SA ; en cas de modification des exigences, un processus de changement doit être suivi, et en cas de changement de modèle, il faut attendre la planification du siège.

Le deuxième prédécesseur est une nouvelle séquence née dans les startups d’IA. MiniMax affiche sur BOSS Zhipin le poste d’« Expert en solutions pré-vente IA », et des entreprises de modèles comme Moonshot, Zhipu, Tongyi et Hunyuan affichent également des postes similaires. Les intitulés varient légèrement, mais les descriptions de poste sont hautement convergentes : comprendre les scénarios clients, réaliser des démonstrations, ajuster les prompts, exécuter des RAG, rédiger des plans de livraison, et collaborer avec les équipes techniques clients jusqu’au déploiement. Ces postes constituent véritablement les « FDE nationaux ».

Trois différences de sol et d'eau

Le déploiement privé et la conformité aux données écrasent le modèle purement basé sur l'appel de modèles. Les clients professionnels en Chine exigent bien plus que ceux aux États-Unis que les données ne quittent pas leur périmètre, que les poids du modèle soient contrôlables et que les audits soient traçables. Dans un projet FDE, le travail consistant à appeler uniquement une API et à exécuter des invites ne représente peut-être que 30 % de l'effort total ; les 70 % restants consistent à déplacer le modèle dans les locaux du client, à mettre en place l'authentification, à l'intégrer à la plateforme de données et à accomplir les formalités de conformité.

Les capacités des modèles sont encore en train de rattraper les SOTA, et l’espace d’innovation se réduit à la couche ingénierie. Aux États-Unis, OpenAI et Anthropic peuvent séduire les clients grâce aux capacités mêmes de leurs modèles ; en Chine, les différences entre les modèles de Tongyi, DouBao, Kimi, GLM et DeepSeek sont moins marquées, et les clients évaluent davantage les compétences techniques telles que l’orchestration des agents, la qualité de la recherche RAG, l’intégration des outils et la conception des workflows. En Chine, les FDE ne se disputent pas sur « la puissance de notre modèle », mais sur « notre capacité à faire réellement fonctionner ce business ».

La volonté de payer et le rythme de tarification des clients B ne sont pas cohérents avec ceux des États-Unis. Le modèle de Palantir, qui consiste à « d'abord déployer des FDE, puis facturer des abonnements à prix élevé », est difficile à reproduire directement. Les budgets des clients nationaux suivent les cycles d'achat annuels et tendent à privilégier les projets ponctuels ; le modèle commercial des FDE est souvent une combinaison d'abonnement, de licence privatisée et de livraison de projet.

Un positionnement unique : FDE interne

De nombreux équipes IA au sein des grandes entreprises commencent à utiliser le modèle FDE pour servir des « clients internes ». Alibaba Cloud PAI a envoyé des ingénieurs sur place chez Taobao, et Tencent Hunyuan dispose d’un mécanisme similaire pour collaborer avec WeChat et les équipes publicitaires. Sur JD, on trouve des postes tels que « Ingénieur de mise en œuvre sectorielle », « Ingénieur d’applications IA » et « Expert en affaires intelligentes » — en réalité, ce sont des FDE internes qui transforment les capacités des équipes de modèles en solutions end-to-end au niveau des opérations. Cela offre aux dirigeants des grandes entreprises une nouvelle approche : placer quelques FDE internes sur le terrain, produire le premier démonstrateur, et remettre les données de ROI aux responsables métier — cela dissoudra les barrières départementales bien plus rapidement que dix réunions de synchronisation.

Dans mon précédent article « À l'individu super » [4], j'ai mentionné les cinq moteurs de l'individu super : une forte curiosité, un fort esprit d'exploration et d'innovation, une forte capacité d'apprentissage autodidacte, une forte autonomie et une forte capacité pratique. Ces cinq qualités sont le billet d'entrée pour le poste de FDE, mais elles ne constituent pas tout. En plus de ces cinq moteurs, le poste de FDE exige un ensemble de traits spécifiques supplémentaires, et certaines personnalités sont clairement inadaptées. J'ai vu trop d'ingénieurs excellents connaître des difficultés d'adaptation après avoir changé pour un poste de FDE ; les problèmes venaient le plus souvent non pas de leurs compétences, mais de leur personnalité et de leurs préférences professionnelles.

Cinq qualités adaptées à FDE

Ne pas craindre les ventes ni la communication. La journée typique d’un FDE n’est pas passée à coder en isolation, mais à interagir directement avec les CTO, responsables opérationnels, acheteurs, responsables de la conformité et équipes IT des clients. Un rythme typique : le CTO d’un client vous interrompt pendant une démonstration — la réaction d’un FDE ne peut pas être « Je vais revoir ça et revenir la semaine prochaine », mais plutôt ouvrir immédiatement l’IDE pour modifier le prompt et relancer l’opération devant lui. « Le client est présent, je modifie en temps réel » est la norme pour un FDE.

Profitez de la zone floue. Le FDE ne reçoit pas un PRD clair, mais seulement une phrase : « Nous voulons faire quelque chose avec l’IA ». Le client lui-même ne sait pas exactement ce qu’il veut ; il faut que le FDE l’accompagne pour faire émerger cette attente floue en une forme concrète. Si vous ne pouvez agir que lorsqu’il y a des besoins clairs, le FDE vous rendra anxieux chaque jour.

Des compétences techniques solides, mais pas besoin d’être 10x. FDE ne demande pas que vous soyez la personne avec le code le plus propre ou les algorithmes les plus poussés de l’entreprise ; elle exige simplement que vous puissiez faire fonctionner un système end-to-end : une interface frontend fonctionnelle, un service backend opérationnel, et un modèle connecté aux sources de données métier. Dans le monde FDE, « ça suffit comme ça » n’est pas une faiblesse, c’est une vertu.

Aime être affiné par les retours. Le travail de FDE comporte de nombreux moments où l’on se fait dire de tout reprendre par les clients : un demo d’aujourd’hui est rejeté demain par les parties prenantes avec « Ce n’est pas ce que je voulais » ; une solution validée la semaine dernière doit être refaite cette semaine parce qu’un nouveau dirigeant a été nommé. Les personnes adaptées à FDE transforment ces retours en carburant, assument la responsabilité end-to-end et ne rejettent pas la faute sur « une demande mal formulée ».

Sensible aux limites du modèle. C'est la plus technique et la plus implicite des règles. Le FDE doit être capable de déterminer quelles tâches sont adaptées à un LLM et lesquelles ne le sont pas, ainsi que les mécanismes de repli à mettre en œuvre — cette sensibilité ne peut pas être acquise par la lecture d'articles scientifiques, mais uniquement à travers les échecs répétés. Au fil de l'accumulation d'exemples de défaillance, le FDE développe une mémoire musculaire des limites du modèle : dans quels scénarios utiliser le RAG, dans quels cas appliquer des règles fixes, et dans quels cas il est impératif de prévoir une porte de repli vers un humain.

Quatre types de personnes non adaptées à FDE

Technicien pur qui veut se cacher dans le code. Les FDE passent environ 50 % de leur temps hors du codage — dans des réunions clients, des coordinations internes, des discussions produit et la progression des contrats. Si votre source de bonheur est d’écrire du code sans être dérangé pendant quatre heures consécutives, un poste de FDE vous mènera à un épuisement mental prolongé.

Les personnes qui ont besoin d’OKR pour agir. Les objectifs de FDE sont ancrés chez le client, pas dans votre tableau de performance. L’avancement du travail est déterminé par les jalons des projets clients, l’évolution des capacités du modèle et votre propre jugement sur les scénarios. Ceux qui ont l’habitude de « ne savoir quoi faire qu’après avoir un OKR » ne trouveront pas de point d’ancrage.

Ceux qui valorisent la promotion plus que les réalisations. FDE n’a pas d’avantage dans le système de promotion des grandes entreprises — des indicateurs comme la satisfaction client, la signature de projets et le taux de réutilisation pèsent moins lourd que la quantité de code ou la fréquence de déploiement lors des évaluations de niveau. Si la promotion est votre première motivation, FDE n’est pas un bon choix.

Les personnes qui résistent au contexte commercial. Un FDE doit comprendre le résultat net, le ROI, les processus d'achat et les exigences de conformité des clients. Si vous avez naturellement une aversion pour parler d'argent, de contrats ou de logique commerciale, le travail de FDE vous fera vous sentir comme si vous vendiez vos idéaux techniques.

Liste de vérification auto-évaluation

7 questions, chacune correspondant à un scénario réel de travail pour FDE. Répondez « oui » à plus de 5 questions pour envisager sérieusement FDE ; répondez « oui » à 3 questions ou moins, il est conseillé d’être prudent.

1. Êtes-vous prêt à déplacer chaque jour 50 % de votre temps du code vers des réunions avec les clients, des réponses aux messages et des appels téléphoniques ?

2. Lorsque le client vous dit « Ça ne marche pas, je ne sais pas pourquoi », votre première réaction est-elle la curiosité ou l’impatience ?

3. Personne ne t’a écrit de PRD, peux-tu, en une semaine, mettre en œuvre avec Claude Code un prototype visible par les clients ?

4. Pour un même livrable, le client vous demande huit versions modifiées : pouvez-vous conserver votre jugement au lieu d’agir mécaniquement ?

5. Lorsque le modèle donne une réponse incorrecte, votre première réaction est-elle de concevoir un mécanisme de secours ou de vous plaindre que le modèle est inadéquat ?

6. Êtes-vous prêt à signer des contrats, rédiger des rapports, accompagner les clients pour la validation et collaborer avec le service juridique sur les clauses de conformité ?

7. Can you accept rapid prototyping and rapid failure?

Cinq qualités, quatre types de profils inversés, sept questions d'auto-évaluation : au final, il s'agit toujours de la même question : êtes-vous prêt à faire évoluer simultanément votre sens du produit, vos compétences en ingénierie et votre jugement commercial dans un même flux de travail ?

Dans l’article précédent, j’ai discuté du « moteur humain » : la curiosité, l’esprit d’exploration, la capacité d’apprentissage autodidacte, l’initiative personnelle et les compétences pratiques, et comment ces éléments peuvent être pleinement stimulés en boucle fermée au sein des grandes entreprises. Cet article aborde un autre sujet : la forme des postes. Le FDE est la première nouvelle forme de poste à avoir un nom, une fourchette salariale, une description de poste et une validation par des clients payants dans la révolution industrielle de l’IA. Il n’est pas synonyme du concept de « super-individu », mais constitue le premier repère concret issu de cette vague de restructuration.

FDE n'est pas la fin. Selon l'avis de l'auteur, FDE n'est que la première forme à prendre un nom dans cette nouvelle répartition des tâches. Viendront ensuite le Forward Deployed PM, le Forward Deployed Designer, le Forward Deployed Researcher — tous les métiers étroitement couplés aux scénarios clients et nécessitant de faire émerger le produit dans des zones floues, auront leur propre version « pré-déployée ». Les intitulés de postes changeront, mais la logique sous-jacente restera la même : les capacités du modèle avancent en tête, la forme produit suit, et la structure des postes se réorganise en fonction du flux de travail.

Laissez une phrase pour chacun des trois types de lecteurs.

Pour les techniciens : FDE ne demande pas que vous soyez le meilleur développeur de l’entreprise, mais il exige que vous soyez prêt à dédier la moitié de votre temps aux clients. Si votre réponse est « oui », la fenêtre du marché vient de s’ouvrir : les recrutements des principales entreprises chinoises de modèles, des fournisseurs de cloud et des équipes internes IA des grandes entreprises s’accélèrent. Si votre réponse est « non », ce n’est pas un problème : de nouveaux postes émergeront dans cette nouvelle répartition des rôles.

À RH et OD : Méfiez-vous de la séparation entre le titre et la réalité. Votre entreprise compte probablement déjà un certain nombre de FDE qui travaillent, mais sont classés sous des postes comme « Expert en solutions », « Architecte industriel » ou « Ingénieur en applications IA ». Identifiez-les, reclassifiez-les et offrez-leur un parcours de carrière aligné sur leurs fonctions réelles, ce qui sera plus efficace que de recruter de nouveaux employés depuis zéro.

Aux gestionnaires : le modèle FDE ne s'applique pas seulement à l'extérieur, mais aussi à l'intérieur. Installer quelques « FDE internes » au sein des équipes opérationnelles pour faire passer les compétences de l'équipe modèle directement dans les processus métiers sera probablement bien plus efficace que de créer un nouveau département IA et d'organiser dix réunions de synchronisation inter-équipes. Les silos ne disparaissent pas grâce à une conception organisationnelle, mais grâce à un démonstrateur fonctionnel.

La transition professionnelle à l'ère de l'IA a déjà commencé ; FDE est le premier signal qui nous indique que la vitesse à laquelle les capacités des modèles évoluent est désormais suffisante pour créer de nouveaux postes. L'auteur souhaite laisser aux lecteurs une question concrète : si, dans trois ans, trois nouveaux postes apparaissent sur le schéma organisationnel de votre entreprise, quelles pourraient-ils être ? Réfléchir à cette question est plus utile que de simplement lire cet article.

👦🏻 Auteur : Henry (équipe DeerFlow) [1]