Décryptage · Partenaire IA

Forward Deployed Engineer : un métier de cadrage avant d’être un métier de code

Photo d’une séance de travail en fin d’après-midi : un ingénieur au tableau blanc couvert de post-it écoute un chef d’atelier qui explique, devant une responsable financière sceptique et un collègue pensif, l’ordinateur portable fermé sur la table.

OpenAI, Anthropic et Palantir envoient des ingénieurs chez leurs clients pour faire aboutir leurs projets d’IA. Le titre arrive maintenant dans les ETI. Voici ce que recouvre ce métier, que j’exerce, et à quoi vous reconnaissez un vrai Forward Deployed Engineer.

  • Mis à jour le
  • 11 min
  • Produit et développement
Dans ce guide

Vos équipes passent des heures sur une tâche que tout le monde juge absurde. Vous sentez que l’IA pourrait aider, mais personne chez vous ne sait dire quoi construire, ni par où commencer. C’est précisément le terrain du Forward Deployed Engineer.

Un Forward Deployed Engineer, ou FDE, est un ingénieur qui travaille directement avec les équipes d’un client pour transformer un problème métier flou en solution utilisée et mesurée. Le rôle vient de Palantir et s’est répandu avec les projets d’IA d’OpenAI et d’Anthropic. Son cœur n’est plus le code, que l’IA produit de plus en plus : c’est le cadrage, la coordination des métiers et la mesure du résultat.

J’exerce ce rôle auprès d’ETI, après des années de direction technique. Voici mon avis de praticien : ce que le métier réunit, ce qu’il doit vous livrer, et la place réelle du code et de l’urgence dans ce travail.

Qu’est-ce qu’un Forward Deployed Engineer ?

Le terme vient de Palantir, éditeur américain de logiciels d’analyse de données, où Shyam Sankar, arrivé en 2006, a conçu ce rôle d’ingénieur au contact des clients. En interne, Palantir appelle le développeur classique « Dev » et le Forward Deployed Engineer « Delta ». Le Dev construit une fonctionnalité de logiciel qui servira à beaucoup de clients ; le Delta combine des fonctionnalités existantes pour résoudre le problème d’un seul client.

Le modèle a ensuite gagné les projets d’IA. Anthropic, l’éditeur de l’assistant Claude, en a fait en décembre 2025 un levier pour déployer Claude dans les grandes entreprises, puis OpenAI l’a mis au centre de Frontier, son offre pour les entreprises, en février 2026. Le titre existait chez quelques entreprises depuis longtemps. Il est devenu un métier à part entière il y a peu, comme d’autres rôles nés avec l’IA.

Demandez à tout prestataire qui se présente comme Forward Deployed Engineer ce qu’il cherche à faire réussir : votre problème, ou l’installation d’un produit qu’il vend. Chez un éditeur, ce rôle sert d’abord son produit ; c’est utile, mais ce n’est pas un cadrage neutre.

Les 6 métiers que réunit un Forward Deployed Engineer

Pour moi, le Forward Deployed Engineer est une fusion de métiers. Sur un même projet, il tient 6 rôles :

  • Chef de produit : il décide ce qu’il faut construire, et surtout ce qu’il ne faut pas construire.
  • Ingénieur : il conçoit la solution et la fait construire, de plus en plus avec l’IA.
  • Analyste de données : il sait ce que contiennent vos données, et ce qu’elles valent vraiment.
  • Interlocuteur du client : il explique ses choix avec vos mots et il propose, au lieu d’attendre une commande.
  • Garant de la mesure : il pose des indicateurs pour vérifier que ses hypothèses vont dans le bon sens.
  • Coordinateur : il organise les entretiens avec vos équipes et fait travailler ensemble ceux qui savent et ceux qui construisent.

Les métiers

Le Forward Deployed Engineer tient 3 familles de métiers à la fois

ProduitTechniqueTerrain FDE
Un développeur couvre la technique, un PM le produit, un consultant passe sur le terrain. Le Forward Deployed Engineer tient les 3 à la fois.

Les 6 rôles se rangent en 3 familles. Le produit réunit le chef de produit et le garant de la mesure. La technique réunit l’ingénieur et l’analyste de données. Le terrain réunit l’interlocuteur du client et le coordinateur.

Prévoyez du temps pour la coordination, le rôle le plus sous-estimé. Votre problème se trouve dans la tête de vos équipes, pas dans un cahier des charges. Un Forward Deployed Engineer qui n’obtient pas une heure avec la personne qui traite les dossiers construit sur des suppositions.

Les anciens directeurs techniques, ou CTO, se prêtent bien à ce rôle, comme ceux qui ont dirigé à la fois la technique et le produit. Ils ont déjà vécu ces problèmes ailleurs : un besoin mal compris, une donnée qui ne dit pas ce qu’on croit, un projet qui s’arrête faute de décideur. Face à un candidat ou à un prestataire, demandez-lui lequel de ces 6 rôles il n’a jamais tenu.

Pourquoi un Forward Deployed Engineer est si bien payé

Vous verrez passer de plus en plus d’offres d’emploi de Forward Deployed Engineer, surtout aux États-Unis. Les salaires annoncés par les employeurs eux-mêmes sont élevés, sans être délirants :

Les montants bien plus élevés qui circulent ajoutent ces actions au salaire. Leur valeur future reste incertaine, et les offres n’en garantissent pas le montant.

Pour moi, ces salaires s’expliquent par le levier. Un Forward Deployed Engineer qui revoit un processus avec l’IA générative ne fait pas gagner quelques heures. Dans un grand groupe, il peut libérer l’équivalent de plusieurs dizaines de postes à temps plein. À cette échelle, un ingénieur payé 300 000 dollars reste une bonne affaire.

Le cas de Klarna, société suédoise de paiement, montre les 2 faces de ce levier. En février 2024, elle annonçait que son assistant IA faisait le travail de 700 agents du service client. En mai 2025, son dirigeant reconnaissait une qualité en baisse et recrutait de nouveau des humains. Le gain annoncé était réel sur le papier, mais il se mesurait aussi à la qualité du service, pas seulement aux postes économisés.

Dans votre ETI, l’ordre de grandeur sera plus modeste : quelques postes libérés, ou du volume absorbé sans recruter. Le raisonnement reste le même : le prix d’un Forward Deployed Engineer se juge au gain qu’il produit, mesuré dans le dossier de cadrage décrit ci-dessous.

Ce qu’un Forward Deployed Engineer doit vous livrer après le cadrage

Le cadrage est la phase qui précède toute construction : il interroge vos équipes, examine vos données et chiffre la solution. Vous pouvez juger un Forward Deployed Engineer sur un livrable précis : le dossier qu’il vous remet à la fin de ce cadrage. Ce dossier doit vous permettre de décider, chiffres à l’appui, s’il faut construire. Il couvre 4 volets :

  • La valeur : les gains attendus, chiffrés avec des hypothèses écrites (volumes, temps passé, coûts), et le retour sur investissement.
  • L’usage réel : comment vos équipes travaillent aujourd’hui, où se perdent le temps et les erreurs, et le parcours visé.
  • La technique : ce que votre système d’information permet déjà, l’architecture visée, c’est-à-dire l’organisation des briques logicielles, et ce qu’il faut construire, acheter ou réutiliser.
  • La trajectoire : le planning, le coût de construction, le coût de fonctionnement par an, les risques et les prérequis.

Le dossier vous laisse le dernier mot : il se termine par une recommandation et une décision, poursuivre ou non. Un prestataire qui ne vous laisse pas la possibilité de dire non ne cadre pas votre projet, il vous vend la suite.

Le retour sur investissement se lit avec 2 chiffres, à demander séparément :

  • Le délai de récupération : la mise initiale divisée par le gain net mensuel, une fois l’outil adopté par vos équipes. Le gain net, ce sont les gains du mois moins le coût de fonctionnement du mois.
  • Le retour sur investissement, ou ROI, sur une période, par exemple 3 ans : les gains de la période moins tous les coûts, divisés par ces mêmes coûts.

Dans les dossiers que je remets, chaque hypothèse est écrite : volume traité, temps gagné, part des équipes qui utilisera l’outil. Sans elles, personne ne peut vérifier le gain après la mise en service. Le temps libéré n’est pas non plus une économie : il le devient seulement si une dépense baisse ou si vos équipes traitent davantage. Les critères qui valideront chaque livraison se fixent ensuite, comme le décrit le guide de la recette logicielle.

Le code n’est plus le cœur du métier de Forward Deployed Engineer

Idée reçue : « le Forward Deployed Engineer est un développeur de haut niveau qui passe sa journée dans le code. » Le code reste nécessaire, mais il n’est plus ce qui fait sa valeur.

L’IA s’est intercalée entre l’ingénieur et le code. Dans ma pratique, elle produit une grande partie du programme et de ses tests. Je lui donne les règles métier et les consignes, puis je vérifie le résultat. Le métier se déplace vers ce qui précède et ce qui suit : trouver le bon problème, puis vérifier que la solution le résout. Je décris cette organisation dans l’article sur la software factory.

Un bagage technique reste indispensable, mais il sert à juger. Vous avez besoin de quelqu’un qui sait si une architecture tiendra, si le choix d’un modèle d’IA se justifie et si un coût de fonctionnement est réaliste. Taper chaque ligne n’est plus ce qui fait la différence.

N’évaluez donc pas un Forward Deployed Engineer seulement sur un test de code. Donnez-lui un problème flou de votre activité et regardez les questions qu’il pose. S’il demande d’abord quel résultat vous attendez, et comment vous le mesurerez, il fait le métier.

Chez un Forward Deployed Engineer, l’urgence permanente vient le plus souvent d’un cadrage raté

Idée reçue : « le Forward Deployed Engineer vit dans l’urgence, sous la pression constante du client, jusqu’au week-end. » La responsabilité est réelle : un Forward Deployed Engineer répond de ce qu’il livre. L’urgence permanente, elle, signale un défaut de cadrage, et c’est votre projet qui en paie le prix.

Sur des projets qui traitent des données de santé, j’ai appris à cadrer dès le départ ce qui autorise l’usage des données, souvent le consentement : qui l’a donné, pour quel usage, et comment le retirer. Ce travail n’a rien de spectaculaire. Il évite de reprendre l’application pour la mettre en conformité, au moment où les utilisateurs sont déjà là. Votre secteur a son équivalent : une règle qu’il coûte peu de traiter au départ et cher de rattraper. Les mêmes questions se posent pour les données de santé envoyées à un modèle d’IA.

Le cadrage

La même application, avec ou sans cadrage

Cadrage expédié

  • Consentement traité après la mise en ligne
  • Données envoyées sans savoir à qui
  • Aucune surveillance de l’application
  • Corrections faites dans l’urgence

Cadrer avant de construire

Cadrage fait

  • Consentement prévu dès la conception
  • Circulation des données décrite et validée
  • Surveillance et alertes en place
  • Corrections planifiées par un responsable
Un bon cadrage ne supprime pas les incidents : il prévoit à l’avance qui les voit et comment vous les traitez.

Demandez aussi à votre Forward Deployed Engineer qui fera tourner ce qu’il livre, lui ou vos équipes, et comment, avant qu’il ne livre. Le cadrage est la 1re protection contre l’urgence ; la 2e est le système qui fait tourner les applications déployées : surveillance, alertes, procédure de correction et responsable désigné. Quand ce système existe, la plupart des incidents se traitent dans les délais prévus. Quand il manque, presque chaque incident devient une urgence.

Forward Deployed Engineer ou product engineer : la différence

Le product engineer est l’autre métier nouveau dont vous entendrez parler. C’est un développeur augmenté par l’IA qui fait évoluer un produit : il pense à l’utilisateur et il livre vite. Mais le produit existe déjà, et quelqu’un d’autre a décidé de sa direction.

Les 2 métiers

2 métiers nouveaux, 2 points de départ

Point de départ

Forward Deployed Engineer

Un problème métier flou, chez vous.

Product engineer

Un produit existant à faire évoluer.

Face au client

Forward Deployed Engineer

Il propose et arbitre avec vous.

Product engineer

Il échange avec les utilisateurs du produit, pas avec vos métiers.

Coordination

Forward Deployed Engineer

Il organise les entretiens avec vos métiers.

Product engineer

Il travaille dans une équipe produit déjà organisée.

Part du code

Forward Deployed Engineer

Une partie de son temps, souvent produite avec l’IA.

Product engineer

L’essentiel de son temps.

Ce qu’il mesure

Forward Deployed Engineer

Gain financierUtilisation par vos équipesDécision prise

Product engineer

Usage du produitQualitéDélai de livraison

Si votre problème est déjà cadré et que le produit existe, un product engineer suffit.

Le critère qui tranche est la coordination des métiers. Si personne chez vous ne sait encore formuler le besoin, vous avez besoin de quelqu’un qui va le chercher auprès de vos équipes et qui propose une solution. Un product engineer part d’un produit et de ses utilisateurs, pas d’un problème encore flou chez vous.

Quand faire appel à un Forward Deployed Engineer, et quand s’en passer

Un Forward Deployed Engineer n’est pas un exécutant. Il a besoin d’une marge de manœuvre réelle pour produire un résultat. Trop contraint, il ne vous apporte rien de plus qu’un développeur, pour un coût plus élevé. Faites appel à lui si vous vous reconnaissez dans ces 4 situations :

  • Le problème est réel mais flou : vous savez où ça coince, pas encore quoi construire.
  • Vous attendez un résultat mesurable : du temps gagné, des erreurs évitées, une décision plus rapide.
  • Vos équipes métier peuvent se rendre disponibles pour des entretiens et des essais.
  • Vous acceptez qu’il propose un autre chemin que celui imaginé au départ.

Passez votre chemin dans ces 3 cas :

  • Votre équipe interne a les compétences et le projet est déjà cadré : renforcez-la plutôt.
  • Vous cherchez un exécutant pour une liste de fonctions décidée d’avance.
  • Le mandat fixe tout d’avance : la solution, la technologie et le calendrier, sans marge pour en discuter.

Votre projet d’IA a déjà fonctionné en démonstration sans aller plus loin ? Avant de mandater qui que ce soit, identifiez ce qui bloque avec l’article sur le prototype d’IA, ou POC, qui ne passe pas en production.

Comment décider : la séquence, dans l’ordre

Avant de recruter ou de mandater un Forward Deployed Engineer, suivez ces 5 étapes :

  1. 1

    Nommez le résultat attendu et la façon de le mesurer : temps par dossier, taux d’erreur ou délai de décision.

  2. 2

    Vérifiez si une équipe interne peut porter le sujet. Si le problème est déjà cadré et que vos équipes savent le construire, un Forward Deployed Engineer apporte peu.

  3. 3

    Rédigez un mandat qui fixe le résultat attendu et la date de décision, sans imposer la solution.

  4. 4

    Réservez la disponibilité de vos équipes métier et d’un décideur pendant toute la durée du cadrage.

  5. 5

    À la fin du cadrage, demandez le dossier de décision : gains chiffrés, usage réel, solution technique, coûts et planning. Décidez sur cette base de construire ou d’arrêter.

À la fin du cadrage, vous devez savoir combien coûte la solution, ce qu’elle rapporte et qui la fera tourner. Si l’une de ces 3 réponses manque, le cadrage n’est pas terminé.

Pour votre budget, je raisonne à l’échelle d’un projet. Un projet IA sérieux, mené du cadrage à la mise en production, commence à 20 000 € ; en dessous, on bricole. Le plafond, lui, n’existe pas : certains projets dépassent 300 000 €. Entre les 2, le montant dépend de la solution technique retenue, de ce qu’elle touche dans vos systèmes et de la facilité à la mettre en place.

Votre délai suit la même logique : l’objectif est d’apporter des résultats vite. Un projet rapide, pour moi, dure 3 mois. Ce délai dépend aussi de votre organisation : la disponibilité de vos équipes et la vitesse de vos décisions comptent autant que la technique.

Portrait de Fabien Bousquet

Auteur de l’article

Fabien Bousquet, CTO externalisé.

Du cadrage à la mise en production, une pratique de direction technique au contact des équipes et de leurs outils métier.

En savoir plus sur mon parcours →

Questions fréquentes sur le Forward Deployed Engineer

Qu’est-ce qu’un Forward Deployed Engineer ?

C’est un ingénieur placé chez le client, qui porte un problème métier depuis sa définition jusqu’à un résultat mesuré. Né chez Palantir, ce rôle est aujourd’hui repris par les éditeurs d’IA comme OpenAI et Anthropic. Il réunit le cadrage, la coordination des équipes, la construction et la mesure.

Que signifie FDE ?

FDE est l’abréviation de Forward Deployed Engineer, littéralement un ingénieur déployé en avant, c’est-à-dire chez le client. Palantir parle aussi de Forward Deployed Software Engineer, et surnomme ce rôle « Delta » en interne. Le sigle désigne une façon de travailler, pas un diplôme ni une certification.

Un Forward Deployed Engineer doit-il savoir coder ?

Il doit comprendre le code et l’architecture pour juger les choix techniques : la solidité d’une architecture, le choix d’un modèle d’IA, le coût de fonctionnement. Avec l’IA, il n’écrit plus chaque ligne lui-même. Son apport principal est de trouver le bon problème, de cadrer la solution et de vérifier qu’elle produit le résultat attendu.

Quelle différence entre un Forward Deployed Engineer et un product engineer ?

Le product engineer fait évoluer un produit qui existe déjà, au sein d’une équipe produit organisée. Le Forward Deployed Engineer part d’un problème métier encore flou chez le client : il coordonne les métiers, propose une solution, la fait construire et mesure son effet. Un produit qui existe et un besoin déjà formulé relèvent du product engineer.

Quelle différence entre un Forward Deployed Engineer et un CTO externalisé ?

Le CTO externalisé dirige la technique de votre entreprise dans la durée : priorités, équipe, prestataires. Le Forward Deployed Engineer porte un problème précis jusqu’à son résultat. Un ancien directeur technique fait souvent un bon Forward Deployed Engineer, et une même personne peut tenir les 2 rôles selon son mandat. Le guide du CTO externalisé détaille le premier.

Combien gagne un Forward Deployed Engineer ?

Aux États-Unis, les offres publiées en octobre 2026 annoncent un salaire de base de 135 000 à 200 000 dollars par an chez Palantir, et de 185 000 à 300 000 dollars pour les postes spécialisés par secteur d’OpenAI, auxquels peuvent s’ajouter des actions. Ces niveaux reflètent le levier du poste : un processus revu avec l’IA peut libérer l’équivalent de nombreux postes dans une grande entreprise.

Combien coûte un projet avec un Forward Deployed Engineer ?

Tout dépend de la solution technique retenue, de ce qu’elle touche dans vos systèmes et de sa facilité de mise en place. Pour un projet IA complet, du cadrage à la mise en production, le budget commence à 20 000 € et peut dépasser 300 000 €. Un projet rapide dure environ 3 mois, si votre organisation se rend disponible et décide vite.

Quand faire appel à un Forward Deployed Engineer ?

Quand un problème métier est réel mais pas encore cadré, que vous attendez un résultat mesurable et qu’aucune équipe interne ne peut le porter. Il faut aussi accepter de lui laisser une marge de manœuvre. Si le projet est déjà cadré et que vos équipes ont les compétences, renforcez-les plutôt.