Forward deployed engineer : le FDE, c'est quoi ?

Cette page rassemble ce qu'il faut savoir sur le forward deployed engineer, en commençant par l'origine du terme et ce qu'il désigne aujourd'hui. On regarde ensuite le travail réel: une journée type, ce que le rôle n'est pas, les compétences qu'il suppose. Vient la raison de son retour, puis ce qu'il change pour une organisation de taille moyenne et les métiers où on le déploie. La dernière partie traite les questions d'achat: déroulé d'une mission, outils, comparaison avec les autres façons d'acheter du logiciel, choix entre recruter et passer par un service, mesure des résultats, et cas où ce n'est pas le bon modèle. Chaque partie renvoie vers un article dédié.

D'où vient le terme, et ce qu'il désigne aujourd'hui

Forward deployed vient du vocabulaire militaire. Être déployé en avant, c'est opérer au point d'action plutôt que de piloter depuis une base arrière. Palantir a repris l'expression au début des années 2010, par nécessité opérationnelle et non par théorie de l'organisation.

Les premiers clients de l'entreprise étaient des agences gouvernementales américaines. Leurs données ne sortaient pas de leurs murs. Impossible d'exporter un échantillon vers une équipe distante pour construire dessus. Impossible, aussi, de mener des entretiens utilisateurs normaux, parce que le client ne pouvait pas dire ouvertement ce dont il avait besoin. Le développement produit classique, qui suppose un besoin exprimable et des utilisateurs interrogeables, ne fonctionnait pas.

Palantir a donc fait l'inverse. Plutôt que de faire venir le besoin jusqu'aux ingénieurs, l'entreprise a envoyé les ingénieurs jusqu'au besoin. Ils s'installaient dans les locaux du client pour des semaines ou des mois, écrivaient du code de production sur place, déboguaient des chaînes de traitement sur du matériel classifié, et assistaient aux points d'équipe du client comme s'ils en faisaient partie.

Deltas et Echos

En interne, ces ingénieurs étaient appelés les Deltas. La formule qui les définit tient en une phrase: un développeur travaille sur une capacité pour beaucoup de clients, un Delta sur beaucoup de capacités pour un seul client. À côté des Deltas, les équipes Echo regroupaient des gens qui venaient du métier du client, militaires, soignants, financiers, et dont le rôle était d'identifier le bon problème avant que quiconque ne code.

Le modèle a pris une place centrale dans l'entreprise. Jusque vers 2016, Palantir comptait plus d'ingénieurs forward deployed que d'ingénieurs logiciels classiques. Ce n'était pas une activité de service en marge du produit, c'était son mécanisme principal de découverte.

Du chemin de terre à la route goudronnée

C'est le second point qui distingue le modèle d'une prestation ponctuelle. Chaque FDE construisait une solution taillée pour son client, avec les moyens du bord. Les équipes produit regardaient ensuite ce qui revenait d'un client à l'autre, et transformaient ces motifs récurrents en fonctionnalités standard de la plateforme. Un chemin de terre tracé par un ingénieur sur le terrain, puis goudronné par le produit quand le trafic le justifie.

Le mot a depuis quitté le contexte classifié. Il désigne une façon de livrer du logiciel qui repose sur quatre traits. Le code tourne sur les données réelles du client, pas sur un jeu d'essai. Le prestataire répond de l'obtention d'un résultat, pas de la conformité d'une version à une spécification. La spécification émerge de l'observation du travail réel au lieu de la précéder. Et la présence dure assez longtemps pour que l'ingénieur comprenne le métier, pas seulement la demande.

Ce que fait un FDE, concrètement

Un FDE porte une solution de bout en bout: comprendre le problème, construire, intégrer aux systèmes existants, mettre en production sous les contraintes réelles, et rester assez longtemps pour voir si les gens s'en servent. Il ne passe pas le relais à une équipe d'intégration après la conception, parce que la conception et l'intégration sont le même travail.

Une journée type

Le matin, une heure ou deux au poste d'un utilisateur. Pas un entretien formel, pas un atelier avec des post-its: le travail réel, avec ses interruptions. On note les détours, les copier-coller, les questions posées à un collègue parce que la réponse n'est écrite nulle part, les étapes que la personne saute toujours et dont la procédure officielle ne dit rien.

Le milieu de journée sert à construire. Une version qui tourne sur les données du client, pas une maquette. Incomplète, un seul cas, pas d'interface soignée, mais un résultat vérifiable sur un dossier que l'utilisateur reconnaît.

En fin de journée ou le lendemain matin, on la montre. La réaction utile n'est pas l'avis exprimé, c'est ce qui se passe quand la personne pose les mains sur le clavier. Si elle hésite, c'est que le modèle mental est faux. Si elle contourne, c'est que le cas qu'elle traite vraiment n'est pas celui qu'on a codé. Si elle ouvre son ancien fichier à côté, c'est qu'il manque quelque chose d'essentiel.

Le reste du temps part dans l'invisible: obtenir un accès, comprendre pourquoi un export contient trois formats de date, négocier un connecteur avec la DSI, écrire ce qui permettra à un autre de reprendre le code. Ce travail ne se voit pas en démonstration, et c'est souvent lui qui décide du sort du projet.

Ce que ce n'est pas

Le mot commence à circuler. Quatre modèles voisins sont régulièrement confondus avec lui.

Ce n'est pas du conseil. Un consultant produit une analyse et des recommandations. Sa mission se termine quand le document est remis, et l'exécution appartient à quelqu'un d'autre. Un FDE livre du code qui tourne en production. Le document, s'il existe, est un sous-produit, jamais le livrable.

Ce n'est pas un projet au forfait. Le périmètre est figé avant le premier jour, et tout ce qui est découvert ensuite devient un avenant. Modèle cohérent quand le besoin est stable, coûteux quand il est mal compris au départ, parce que la découverte y est traitée comme un incident contractuel.

Ce n'est pas de la régie. En régie, on loue des heures d'ingénieur pour exécuter une spécification écrite ailleurs. Le client porte la responsabilité de dire quoi construire. Dans un modèle forward deployed, le prestataire participe à définir quoi construire, parce qu'il a vu le travail réel, et il répond du fait que le résultat arrive.

Ce n'est pas du support. Le support traite des incidents sur un outil existant, dans un périmètre borné. Le FDE construit. Un prestataire qui passe ses journées à répondre à des tickets ne fait pas ce travail, quel que soit le nom de la ligne sur la facture.

Quatre questions pour vérifier

Face à un prestataire qui se présente comme faisant du travail forward deployed, quatre questions suffisent à savoir si le mot recouvre une pratique ou une étiquette:

• Où le code sera-t-il écrit: sur vos données réelles, ou sur un jeu d'essai simplifié qui ne ressemblera jamais à votre production ?
• Qui porte le risque si le résultat n'arrive pas: le prestataire répond-il d'un résultat, ou seulement de la livraison d'une version conforme à une spécification ?
• Qui écrit la spécification: vous, seul, avant toute observation, ou une équipe qui a passé du temps avec vos utilisateurs avant de proposer quoi que ce soit ?
• Que reste-t-il chez vous à la fin: une équipe interne capable de faire évoluer l'outil, ou une dépendance complète à l'ingénieur qui est reparti ?

Un prestataire qui n'a pas de réponse claire aux quatre vend probablement de la régie sous un nom plus séduisant. Le détail des différences, contrat et facturation compris, est traité plus bas et dans l'article qui leur est consacré.

Les compétences réelles du profil

La fiche de poste de Palantir donne le socle technique: une bonne maîtrise d'un langage généraliste, Python, Java, C++ ou TypeScript, une formation scientifique, une aisance avec les données à grande échelle, et une disponibilité pour se déplacer chez le client. Un an d'expérience suffit à l'entrée, ce qui dit quelque chose d'important: la barrière n'est pas la séniorité technique.

Elle est ailleurs. Un bon FDE cumule des qualités qui vivent rarement chez la même personne.

• Une ingénierie large plutôt que profonde. Il faut savoir brancher une base, écrire une interface utilisable, poser un connecteur, mettre en ligne et surveiller. Un spécialiste d'un seul étage de la pile reste bloqué au premier obstacle qui sort de son domaine.
• Une capacité à lire un métier qu'on ne connaît pas. Comprendre en quelques jours pourquoi un service comptabilise de cette façon, pourquoi un commercial saisit ce champ en dernier, et ce que le vocabulaire maison recouvre vraiment.
• De la conduite d'entretien, sans le mot. Poser des questions ouvertes à quelqu'un qui n'a pas demandé votre visite, et repérer l'écart entre ce qu'on vous décrit et ce que vous voyez.
• De l'arbitrage produit. Décider de ce qu'on ne construit pas. C'est la compétence la plus rare, parce qu'elle consiste à dire non à une demande légitime au nom d'un résultat plus important.
• Du sang-froid en réunion. Un FDE parle à un directeur, à un utilisateur et à la DSI dans la même journée, avec trois vocabulaires et trois enjeux différents.
• De l'écrit. Ce qui n'est pas écrit ne survit pas au départ de l'ingénieur.

Cette liste explique pourquoi le profil est difficile à recruter: chaque qualité prise isolément est courante, la combinaison ne l'est pas. Nous y revenons plus loin, au moment de choisir entre recruter un FDE et acheter la compétence en service.

Pourquoi le modèle revient maintenant

Le mouvement est net depuis le début 2025. OpenAI a monté une équipe FDE à ce moment là: partie de deux ingénieurs, elle dépasse aujourd'hui la dizaine, répartie sur huit villes et trois continents. Ramp en compte une quinzaine, organisés en petites équipes. Le fonds a16z a qualifié la fonction de métier le plus recherché de la tech.

La raison de fond est la même qu'en 2010, avec un déclencheur différent. À l'époque, l'obstacle était la confidentialité: les données ne sortaient pas. Aujourd'hui, l'obstacle est la nature même du travail à faire. Brancher un modèle de langage sur une organisation suppose de connaître son vocabulaire, ses cas limites, ses exceptions tolérées et ce qu'elle n'a pas le droit de dire. Rien de tout cela ne figure dans un cahier des charges, parce que personne ne le sait de façon consciente et formulable.

Un modèle branché sur des données génériques répond de façon générique. Un modèle confronté aux vrais dossiers, aux vrais échanges et aux vraies exceptions répond avec la nuance que les équipes attendent. La différence entre les deux ne se joue pas dans le choix du modèle, elle se joue dans le temps passé au contact du travail réel. C'est exactement ce que la présence sur site permet et ce qu'une livraison à distance rate presque toujours.

Ce que ça change pour une organisation de taille moyenne

Le modèle est né chez des clients très gros, mais rien dans son principe n'exige une grande taille. Il exige un problème réel, des données réelles et des utilisateurs accessibles. Une organisation de cent personnes remplit souvent mieux ces trois conditions qu'un grand groupe, parce que la distance entre la direction et le terrain y est courte et que les accès se débloquent en une conversation.

Le premier changement est organisationnel avant d'être technique. Il faut accepter qu'un ingénieur extérieur passe du temps assis à côté des équipes avant de produire quoi que ce soit de visible. Il faut aussi accepter qu'un manager ne puisse pas lui remettre une spécification fermée le premier jour. C'est une forme de confiance plus proche de celle qu'on accorde à une recrue senior qu'à un fournisseur.

Le deuxième porte sur qui dit ce qu'il faut construire. Dans un projet classique, l'utilisateur exprime un besoin, un chef de projet le traduit, un prestataire le réalise, et chaque traduction perd de l'information. Ici, l'ingénieur voit directement ce que l'utilisateur fait. Le raccourci est brutal pour les organisations habituées au circuit long, et c'est là où vient la valeur.

Le troisième concerne le coût. Le démarrage est plus cher qu'une prestation classique, parce qu'il commence par de l'observation qui ne produit pas de livrable. Ce qu'on récupère ensuite, c'est un outil que les gens utilisent au lieu d'un outil livré conforme et abandonné. C'est aussi ce qui évite le scénario le plus courant du logiciel métier: une maquette validée en comité qui ne passe jamais en production faute d'avoir rencontré les conditions réelles. Nous avons détaillé ces conditions dans notre article sur les prérequis pour passer un POC en production.

Les métiers où on le déploie

Le modèle n'est pas lié à un domaine technique. Il est lié à la présence d'un travail répétitif, informé par des règles non écrites, et effectué par des gens qu'on peut aller regarder. On le retrouve donc dans des fonctions très différentes. Nous les traitons séparément sur nos pages FDE as a Service, parce que les contraintes ne sont pas les mêmes.

• Finance: rapprochements, clôture, contrôle de gestion, reporting. Des processus à forte charge documentaire, où la règle métier vit dans des fichiers de calcul entretenus par une seule personne. L'enjeu est la traçabilité autant que le gain de temps.
• Marketing: production de contenu, gestion des assets, suivi des campagnes, qualification des demandes entrantes. Beaucoup de volume, des critères de qualité subjectifs, et un besoin permanent de garder la main sur ce qui sort.
• RevOps: hygiène du CRM, routage des affaires, prévisions, articulation entre vente, marketing et service client. Le sujet est rarement l'outil, presque toujours la cohérence de la donnée entre les équipes. Nous avons d'ailleurs écrit sur la différence entre un FDE orienté vente et un profil RevOps.
• Donnée: collecte, nettoyage, réconciliation entre systèmes, mise à disposition pour l'analyse. C'est le terrain historique du rôle, et celui où l'écart entre le schéma théorique et la réalité des exports est le plus grand.
• Pilotage de projet: suivi d'avancement, consolidation des informations entre équipes, alertes. Beaucoup de temps y part en collecte manuelle d'états que les systèmes connaissent déjà.

Selon le besoin, le travail prend la forme d'une application métier complète, d'un agent IA branché sur les outils existants, d'une automatisation ciblée sur un processus précis, ou d'une montée en compétence des équipes menée en parallèle de la construction.

Le déroulé d'une mission, en résumé

Une mission forward deployed suit à peu près toujours la même séquence, même si la durée de chaque étape varie fortement.

• Cadrage court. On identifie le processus à regarder et on obtient les accès. Cette étape paraît administrative, elle conditionne tout le reste.
• Observation. L'ingénieur s'installe et regarde le travail réel. Elle se termine quand il sait reproduire mentalement une journée de travail de l'utilisateur, y compris les exceptions.
• Première version utile. Un périmètre volontairement étroit, qui tourne sur les données réelles et traite un cas complet plutôt que dix cas à moitié.
• Boucles courtes. Construire, montrer, corriger, en cycles de quelques jours. C'est la partie la plus longue et celle qui produit l'essentiel de la valeur.
• Mise en production. Droits, surveillance, reprise d'historique, procédure de secours. Ce n'est pas une formalité de fin de projet.
• Passation. Elle ne commence pas à la fin. Un correspondant interne suit la construction depuis le début et reprend l'outil quand l'ingénieur repart.

Le détail de chaque étape, avec ce qui la déclenche et ce qui la termine, est dans notre article sur la méthode d'une mission forward deployed.

Les outils, en résumé

La question de l'outillage vient souvent tôt dans les discussions, et elle est moins décisive qu'on ne le croit. Un FDE utilise ce qui est déjà en place chez le client autant que possible, parce que chaque outil ajouté devient une charge pour l'équipe interne le jour où il repart.

L'outillage se répartit en quelques familles: l'accès à la donnée et les connecteurs vers les systèmes existants, l'environnement de construction et le contrôle de version, les assistants de codage, le socle d'exécution des modèles quand il y a de l'IA, la surveillance de ce qui tourne en production, et enfin la trace écrite. La règle de sélection est simple: on privilégie ce que l'équipe interne saura reprendre, même quand un outil plus puissant existe. Le détail des choix, et les critères pour arbitrer entre une solution du marché et du sur-mesure, sont dans notre article sur les outils d'un forward deployed engineer.

FDE ou un autre modèle d'achat

Le bon modèle dépend d'une seule question: sait-on déjà précisément quoi construire ?

Si oui, si le besoin est stable, documenté, et que la difficulté est purement d'exécution, un projet au forfait ou une mission en régie fait le travail et coûte souvent moins cher. Si le besoin porte sur un produit du marché à paramétrer, un intégrateur spécialisé est mieux placé. Si la question est stratégique et qu'aucun code n'est attendu, c'est du conseil.

Le modèle forward deployed prend l'avantage quand l'incertitude porte sur le quoi et pas seulement sur le comment: quand les utilisateurs ne savent pas expliquer leur propre processus, quand les règles métier vivent dans des fichiers officieux, quand des tentatives précédentes ont produit un outil conforme que personne n'utilise. La comparaison complète, y compris sur les modes de facturation et la réversibilité, est dans l'article FDE, consultant, ESN, régie.

Recruter ou passer par un service

Une fois le modèle choisi, reste la question de qui le porte. Recruter un FDE en interne a un avantage décisif: la connaissance métier accumulée reste dans l'entreprise, et la personne devient meilleure chaque année. Cela suppose de trouver le profil, de le payer au niveau du marché, et surtout de lui donner assez de sujets variés pour qu'il ne s'ennuie pas une fois le premier chantier terminé.

Passer par un service externe donne accès à une équipe plutôt qu'à une personne, donc à un éventail de compétences plus large, et évite le risque du poste unique. Le coût est une vigilance permanente sur la passation: sans correspondant interne sérieux, la connaissance repart avec le prestataire.

Beaucoup d'organisations font les deux dans l'ordre: un service externe pour les premiers chantiers, pendant lesquels le futur responsable interne se forme, puis un recrutement une fois que le volume de sujets le justifie. Les critères pour trancher sont détaillés dans recruter un FDE ou passer par un service externe.

FDE et IA générative

L'IA générative a deux effets opposés sur le rôle, et c'est ce qui rend le sujet intéressant.

D'un côté, elle rend le FDE plus rapide. Écrire une première version d'un connecteur, explorer un export mal documenté, produire une interface jetable pour tester une hypothèse: tout cela prend aujourd'hui des heures là où il fallait des jours. La boucle observation, construction, démonstration se resserre, ce qui augmente mécaniquement le nombre d'aller-retours possibles dans une semaine.

De l'autre, elle rend le rôle plus nécessaire. Un système qui produit du texte ou des décisions doit être borné, et les bornes viennent du métier: ce qui est acceptable, ce qui ne l'est jamais, ce qui doit être vérifié avant affichage. Nous appliquons une règle constante sur ce point: tout ce qui engage l'entreprise, un prix, une disponibilité, une référence, une adresse, est calculé par le système et vérifié avant d'être montré, jamais produit librement par le modèle. Poser ces règles demande d'avoir vu les cas limites, donc d'avoir été sur place. L'analyse complète est dans FDE et IA générative, pourquoi maintenant.

Comment mesurer que ça marche

Un projet forward deployed se mesure mal avec les indicateurs habituels d'un projet logiciel. Le respect du planning et la conformité au périmètre initial ne disent rien, puisque le périmètre est censé évoluer avec ce qu'on apprend. Quelques signaux tiennent mieux.

• L'usage spontané. Les gens ouvrent-ils l'outil sans qu'on le leur demande, y compris les semaines où personne ne les regarde ? C'est l'indicateur le plus difficile à truquer.
• L'abandon des contournements. Le fichier parallèle que tout le monde gardait ouvert à côté est-il fermé ? Tant qu'il est là, l'outil ne couvre pas le cas réel.
• Le temps du chemin complet. Pas le temps d'une étape isolée, mais celui du dossier de bout en bout, reprises et exceptions comprises. C'est la seule mesure que le métier reconnaît.
• La part des exceptions traitées. Un outil qui gère les cas simples et renvoie le reste en manuel déplace le travail plus qu'il ne le réduit.
• Le délai avant la première modification interne. Combien de temps après le départ de l'ingénieur l'équipe interne fait-elle sa première évolution seule ? Si la réponse est jamais, la passation a échoué quelle que soit la qualité du code.

Ces mesures se prennent après la mise en production, pas à la livraison. C'est pour cela qu'il faut mesurer l'état initial pendant la phase d'observation. Sans point de départ, personne ne pourra dire honnêtement ce que le projet a changé.

Conditions de réussite, et quand ce n'est pas le bon modèle

Trois conditions reviennent systématiquement dans les missions qui aboutissent. Un accès réel aux utilisateurs, pas seulement à leur responsable. Un correspondant interne identifié, qui connaît le métier dans le détail, qui a du temps, et qui reprendra l'outil ensuite. Et un sponsor qui accepte que le périmètre bouge quand l'observation révèle que le problème initial n'était pas le bon.

Trois erreurs reviennent aussi souvent. Traiter l'observation comme du temps perdu et passer directement à la construction, ce qui recrée le problème que le modèle cherche à éviter. Garder l'ingénieur à distance pour économiser des déplacements. Ne prévoir aucune passation, ce qui transforme le projet en dépendance permanente.

Un signal mérite une attention particulière. Si, après plusieurs semaines, le prestataire demande encore des validations formelles avant chaque avancée sans jamais montrer de code qui tourne sur vos données réelles, il ne fait pas de travail forward deployed. Le test le plus simple reste de demander à voir, à intervalles courts, ce qui fonctionne vraiment chez vous.

Quand choisir autre chose

Le modèle est mauvais dans plusieurs situations, et le dire évite des déceptions. Quand le besoin est un logiciel du marché à paramétrer, un intégrateur spécialisé sera meilleur et moins cher. Quand la contrainte est réglementaire et déjà formalisée, il y a peu à découvrir sur le terrain. Quand les utilisateurs ne sont pas accessibles, pour des raisons de charge ou de politique interne, le modèle perd sa matière première. Quand l'organisation traverse une réorganisation qui va changer les processus dans les mois qui viennent, mieux vaut attendre que le travail se stabilise. Et quand la direction veut un prix ferme sur un périmètre ferme, le forfait est plus honnête que de promettre un modèle adaptatif sur un contrat qui ne l'est pas.

Si vous hésitez entre ces options, un diagnostic permet de trancher avant tout engagement: on regarde le processus concerné, on vérifie si les conditions du modèle sont réunies, et on vous dit si une autre approche convient mieux. Les autres articles de cette série, sur la méthode, les outils, les modèles d'achat et l'IA générative, complètent cette page pour qui veut entrer dans le détail.

Sources

• What are Forward Deployed Engineers, and why are they so in demand ?, The Pragmatic Engineer
• How Palantir Invented the Forward Deployed Engineer Model, FDE Academy
• Forward Deployed Software Engineer, fiche de poste Palantir Technologies

Questions fréquentes

L'ingénieur travaille-t-il dans nos locaux tous les jours ?

Non, et ce n'est pas souhaitable. La présence sur site est concentrée sur les phases où elle apporte quelque chose: l'observation du travail réel, les démonstrations, la mise en production. Le reste se fait à distance sans perte, une fois que le métier est compris.

Faut-il acheter des outils avant de commencer ?

En général non. Le principe est de partir de ce que vous avez déjà, parce que tout outil ajouté devient une charge pour vos équipes ensuite. Si un achat s'avère nécessaire, il arrive après l'observation, quand le besoin est vérifié, pas au moment du cadrage.

Nos données sont mal rangées, faut-il faire le ménage d'abord ?

Non. Des données mal rangées sont la situation normale, pas une exception, et attendre qu'elles soient propres revient à ne jamais commencer. Le nettoyage fait partie du travail et il se fait au fil des cas réels, pas dans un chantier préalable qui ne produit rien d'utilisable.

Nos utilisateurs n'ont pas de temps à consacrer à un projet.

L'observation se fait pendant leur travail, pas en atelier ni en réunion. Ce qui est demandé, c'est d'accepter une présence à côté d'eux et de répondre aux questions au fil de l'eau. La charge réelle porte surtout sur le correspondant interne, qui doit être choisi en conséquence.

Peut-on arrêter en cours de route ?

Oui, et le découpage en boucles courtes est fait pour cela. À chaque cycle, ce qui a été mis en production reste en production et continue de servir. Il n'y a pas de point de non-retour où tout ne vaut que si le projet va jusqu'au bout.