AI>DRIVEN>DEV_

Forward Deployed Engineer : le développeur qui fait passer un problème métier en production.

Un FDE part d’un travail bloqué. Il le rend observable, construit une solution dans les systèmes existants, puis laisse à l’équipe les moyens de la faire évoluer.

Qu’est-ce qu’un FDE ?

Un Forward Deployed Engineer est un ingénieur logiciel qui prend en charge un problème métier jusqu’à son usage réel. Il travaille avec les personnes concernées, relie les données et les systèmes existants, code la solution, la teste en production et documente ce que l’équipe doit reprendre.

Le terme a été popularisé par Palantir. Les entreprises emploient aussi FDSE ou Applied AI Engineer. Le titre varie. La frontière utile ne varie pas : il y a un système à construire, une personne qui l’utilise et une équipe qui en devient propriétaire.

Capture réelle de la fiche de poste Palantir : le rôle FDE comprend les problèmes clients, conçoit des solutions de bout en bout et va du design système à l’intégration des données.
“FDSEs understand our customers’ greatest pain points and design end-to-end solutions to address them.”
Palantir · Forward Deployed Software Engineer. La fiche Palantir relie douleur client, conception de bout en bout, prototypage, développement et intégration des données. Fiche Palantir ↗

Quand un FDE est-il la bonne réponse ?

  1. Un geste métier revient souvent.Exemple : le support reçoit plusieurs fois par jour un mail sur une commande absente du portail.
  2. Le geste dépend de systèmes, de règles ou de droits.Le support doit croiser un ERP, un portail client et des permissions.
  3. Une recommandation ne suffit pas.Il faut réellement relier ces systèmes, tester la réponse et la déployer.
  4. Quelqu’un côté métier doit pouvoir reprendre la main.Sans propriétaire, règles de contrôle et procédure d’arrêt, il n’y a pas de système durable à livrer.

Ce n’est probablement pas un sujet FDE si un produit standard couvre déjà le besoin, si l’on attend uniquement un diagnostic, ou si personne ne portera le flux après la mise en service.

Exemple : automatiser un mail de support sans perdre le contrôle.

Le problème n’est pas « répondre avec une IA ». Le problème est plus précis : un opérateur met du temps à retrouver les bonnes informations, puis doit décider quoi répondre sans exposer de données auxquelles il n’a pas droit.

Exemple illustratif · support incident

Un mail n’est pas encore une automatisation.

Decamille@client.fr
ObjetLa synchronisation bloque encore

Bonjour, la commande apparaît dans notre ERP mais pas dans le portail. Pouvez-vous regarder ?

1. Rendre le problème vérifiable

Le FDE ne branche pas un modèle sur cette phrase.

Il regarde des tickets comparables, suit le traitement par le support et vérifie quelles données le support a réellement le droit de lire.

# brief.md
utilisateur : support niveau 1
signal : commande présente dans ERP, absente du portail
hors périmètre : modifier une commande ou révéler des données non autorisées
preuve : une personne retrouve la bonne cause avec les sources citées

2. Construire un système avec une frontière

L’automatisation prépare. Une personne décide.

3. Laisser une équipe capable de continuer

Les fichiers qui rendent la solution modifiable.

  • context.mdrègles métier, sources et permissions
  • evals/tickets.ymltickets représentatifs, réponse attendue, raison du refus
  • runbook.mdquoi vérifier, comment arrêter, qui prévenir
Ce qui prouve la valeur : le support retrouve plus vite la bonne cause, les propositions restent traçables et l’équipe peut couper ou modifier le système sans attendre le FDE.

Schéma · frontière d’automatisation

Le système ne choisit pas toujours.

La frontière de décision d’un mail de supportLe mail de Camille est vérifié contre l’identifiant de commande et les droits de l’opérateur. Si ERP et portail concordent, un brouillon cite les sources. S’ils se contredisent, le support reçoit les valeurs à comparer. En absence de droit ou d’identifiant, aucune recherche et aucun envoi ne sont autorisés.CAMILLECommandeID du maildroits du support3 VÉRIFICATIONSID · droitsERP = portail ?OUIBrouilloncause + liensCONFLITRevue2 valeurs visiblesDROIT / ID ABSENTStopni recherche, ni envoi
1Mail de CamilleID de commande + droits de l’opérateur
2Vérifierl’ID, les droits et l’écart ERP / portail
3AConcordancebrouillon avec la cause et les liens sources
3BConflitrelecture des 2 valeurs par le support
3CDroit ou ID absentaucune recherche, aucun envoi
La sortie est concrète : le support reçoit soit un brouillon sourcé, soit les valeurs à arbitrer, soit rien. Il peut donc vérifier pourquoi le système a refusé d’agir.

Le Markdown n’est pas un gadget. Dans cet exemple, il rend les règles, les exceptions et les critères de refus lisibles par le support, versionnables avec le code et exploitables par les outils d’IA. Ce sont ces fichiers qui permettent de modifier l’automatisation sans repartir de zéro.

Face au même mail, qui fait quoi ?

Camille écrit : sa commande existe dans l’ERP, mais pas dans le portail. Le support doit répondre sans exposer d’information interdite. Voici la sortie attendue de chaque rôle.

Consultant
Il diagnostique le trajet de la commande. Il livre une carte des données manquantes et recommande la correction.
Sa sortie s’arrête avant l’intégration qui prépare la réponse du support.
Solutions engineer
Il démontre un scénario. Il montre comment le produit peut retrouver une commande et rédiger un message à Camille.
Sa sortie est une démo : elle ne décide pas des droits réels ni de la procédure d’incident.
Software engineer
Il construit la fonction approuvée. Il peut créer l’intégration ERP–portail et les tests qui empêchent une régression.
Sa sortie devient commune quand une règle de support a déjà été validée et qu’un propriétaire produit la porte.
Forward deployed engineer
Il relie le mail à une réponse contrôlée. Il suit le ticket avec le support, écrit la règle, intègre ERP et portail, installe le contrôle humain et transmet les fichiers d’exploitation.
Sa sortie est un flux que le support peut vérifier, arrêter puis faire évoluer.

Le point que les comparatifs de rôles laissent souvent abstrait.

La productisation n’est pas automatique. Une taxonomie récente du FDE décrit cette boucle ; ici, nous la traduisons en question exploitable : lorsque la même règle revient dans plusieurs files de support de la même organisation, faut-il la sortir du runbook local ? Lire la source ↗

Schéma · apprentissage produit

Le terrain ne doit pas créer 1 intégration de plus.

La boucle de productisation d’un apprentissage FDEUn cadre de décision pour une organisation : un cas local devient une règle et des tests. Si la même règle revient dans plusieurs files de support de la même organisation, elle peut devenir une capacité partagée. Sinon elle reste une exception documentée dans le runbook de l’équipe.1 · OBSERVERCas réelmail, règle, friction2 · STABILISERPreuverègle + evals3 · DÉCIDERRépétable ?autre file, même règle ?NON → RUNBOOK DE L’ÉQUIPEOUICapacité partagée
1Observerun cas réel : le mail, la règle, la friction
2Stabiliserajouter la règle et des cas dans les évaluations
3Déciderla même règle revient-elle dans une autre file de support ?
OUICapacité partagéeelle revient dans le socle et sera re-testée au prochain déploiement
NONRunbook de l’équipel’exception reste locale, documentée et opérable
Le signal à surveiller : la même règle et les mêmes cas de test reviennent dans plusieurs files de support. C’est le moment de choisir entre une capacité partagée et une exception locale bien opérée.

Les fiches de poste montrent ce périmètre.

Une fiche de poste et un post du responsable FDE d’OpenAI décrivent la même responsabilité : comprendre le besoin, construire, intégrer et livrer jusqu’à l’usage. Le dernier visuel est une opinion X, présentée comme telle.

Capture réelle de la fiche de poste Anthropic : le FDE travaille avec les clients, livre des applications d’IA de production et accélère l’adoption.
Anthropic · Forward Deployed Engineer. Anthropic place le FDE entre ingénierie, compréhension des workflows clients et adoption de systèmes d’IA en production. Fiche Anthropic ↗
Capture du post LinkedIn public de Colin Jarvis annonçant la fonction Forward Deployed Engineering chez OpenAI et sa mission : amener les clients en production.
LinkedIn · Colin Jarvis, OpenAI. Le responsable FDE d’OpenAI cite explicitement la production, les cas zéro-à-un et l’adaptation de cas éprouvés aux systèmes propres de chaque client. Post LinkedIn ↗
Capture de l’article public publié sur X par Mickey Haslavsky, intitulé Custom Autonomous Software: The Next Software Model After SaaS.
X · Mickey Haslavsky. Une opinion sur le logiciel autonome sur mesure. Elle illustre le débat autour de logiciels adaptés au travail réel, sans servir de définition du rôle FDE. Article X ↗

Les 2 posts sont recadrés à leur zone éditoriale. La fiche et le post LinkedIn décrivent un rôle ; le visuel X reste une opinion et ne porte aucune affirmation factuelle du guide.

Comment savoir si ce mail est mieux traité ?

Avant de déployer, l’équipe décide comment elle vérifiera le résultat. Voici une trame pour le cas illustratif, pas des seuils universels.

  1. Temps de première réponseRelever le délai sur le même type de ticket avant puis après le changement, sur une période définie.Si aucune baseline n’existe, on commence par la mesurer.
  2. Qualité du routageChaque semaine, le support relit un échantillon de tickets et compare catégorie proposée, sources citées et décision finale.Si le contrôle humain corrige souvent, l’automatisation reste au stade de brouillon.
  3. Respect des droitsTester les scénarios où l’émetteur ne doit pas accéder aux données recherchées.Une permission ambiguë bloque la réponse automatique.
  4. Reprise par l’équipeFaire exécuter le runbook par la personne qui gère le support, sans le FDE.Si elle ne sait pas arrêter ou corriger le flux, le transfert est incomplet.

Ce que l’AI-Driven Development change dans ce rôle.

L’IA peut accélérer la recherche, proposer du code et préparer un brouillon. Le développeur garde la responsabilité des accès, des règles métier, des évaluations et de la mise en production. Le FDE rend cette responsabilité concrète parce qu’il travaille sur un flux réel et peut vérifier le résultat avec les personnes qui l’utilisent.

Sources.

  1. 01Palantir — Dev versus Delta ↗Palantir documente la distinction entre ses ingénieurs produit et ses ingénieurs déployés auprès des clients, ainsi que l’origine interne du nom Delta.
  2. 02Palantir — Forward Deployed Software Engineer ↗La fiche décrit un rôle qui part d’un problème métier flou, conçoit une solution de bout en bout, intègre les données et itère avec les utilisateurs.
  3. 03OpenAI — Forward Deployed Engineer ↗OpenAI présente le FDE comme le point de rencontre entre livraison client et développement de plateforme, de la découverte à la production.
  4. 04OpenAI — lancement de la Deployment Company ↗OpenAI annonce une société dédiée au déploiement de l’IA et environ 150 FDE et spécialistes issus de Tomoro, selon les termes de l’annonce.
  5. 05Anthropic — Forward Deployed Engineer ↗La fiche Applied AI décrit des applications de production, des intégrations, des serveurs MCP, des sous-agents et des patterns reproductibles.
  6. 06AWS — 1 milliard de dollars pour le FDE ↗AWS annonce une organisation dédiée, des ingénieurs embarqués chez les clients et un objectif d’autonomie après le déploiement.
  7. 07Forward Deployed Engineering: A Taxonomy and Definition ↗Un working paper propose 3 propriétés : ownership produit, transfert de connaissances dans les 2 sens et boucle de productisation.
  8. 08METR — Impact de l’IA sur des développeurs expérimentés ↗Une étude randomisée sur 16 développeurs et 246 tâches a mesuré un allongement de 19 % avec les outils IA de début 2025. Le résultat est un point de mesure, pas une loi universelle.
  9. 09Stanford AI Index 2026 — Economy ↗Le rapport suit l’adoption de l’IA en entreprise et distingue cette adoption du déploiement plus précoce des agents.
  10. 10McKinsey — State of AI 2026 ↗L’enquête met en regard passage à l’échelle, productivité déclarée et impact financier déclaré.
  11. 11Anthropic Economic Index ↗Les données publiées par Anthropic montrent une forte concentration des usages sur le développement logiciel et une majorité d’usages d’augmentation.
  12. 12GitHub et Accenture — étude Copilot ↗Une étude d’entreprise publiée par GitHub rapporte jusqu’à 55 % de vitesse de codage en plus dans son contexte expérimental.
  13. 13Colin Jarvis — lancement de la fonction FDE chez OpenAI ↗Le responsable FDE d’OpenAI résume la mission : amener les clients en production, du cas nouveau à l’adaptation de cas éprouvés.
  14. 14Mickey Haslavsky — Custom Autonomous Software ↗Un point de vue public sur le lien entre logiciel personnalisé, déploiement et rôle FDE. À lire comme une opinion, pas comme une définition officielle.