Un Forward Deployed Engineer est un ingénieur qui s'installe chez le client, comprend comment le travail se fait vraiment, et transforme cette compréhension en logiciel qui tourne. Le rôle est né chez Palantir. L'intelligence artificielle vient d'en faire l'un des métiers les plus recherchés du secteur.
La raison tient en une phrase. L'intelligence est devenue une commodité, savoir où la mettre dans une entreprise ne l'est pas. Tandem exerce ce métier au quotidien, et cet article décrit ce qu'il recouvre, les trois étapes qui le composent, et une feuille de route de quatre semaines pour s'y former.
Pourquoi l'intelligence ne peut plus être un avantage concurrentiel
Tout le monde a accès aux mêmes modèles frontière, le même jour, au même prix. Une capacité que votre concurrent peut acheter cet après-midi ne fonde pas un avantage durable. L'intelligence brute est devenue une commodité, au sens strict du terme.
L'avantage s'est donc déplacé ailleurs. Il se joue sur le où, le comment et le pourquoi. Dans quel process précis vous injectez cette intelligence, et avec quelles garanties. Deux entreprises peuvent utiliser exactement les mêmes modèles et obtenir des retours sur investissement qui n'ont rien à voir. La différence n'est pas le modèle.
Le chiffre qui documente cet écart est connu. Le rapport « The GenAI Divide: State of AI in Business 2025 », publié en juillet 2025 par le projet NANDA du MIT, mesure que 95 % des projets d'IA générative en entreprise ne produisent aucun retour mesurable. L'étude repose sur 150 entretiens de dirigeants, 350 questionnaires de salariés et l'analyse de 300 déploiements publics. Son diagnostic est organisationnel, pas technologique.
Nous avions traité cet écart sous l'angle du retour sur investissement dans notre article sur les entreprises qui ne voient aucun ROI sur l'IA. Le présent article prend l'autre bout du problème, celui du métier qui fait passer un projet du mauvais côté de la statistique au bon.
Qu'est-ce qu'un Forward Deployed Engineer ?
Quelqu'un doit décider où l'intelligence a sa place dans une organisation. C'est le rôle du Forward Deployed Engineer, souvent abrégé FDE. Palantir a inventé le poste pour désigner des ingénieurs envoyés directement chez le client, chargés de résoudre son problème plutôt que de construire une fonctionnalité générique.
Le rôle demande deux jugements qui cohabitent rarement chez la même personne. Le jugement métier porte sur les workflows, les exceptions, les coûts, le risque et l'adoption. Le jugement technique porte sur les modèles, les API, les données, la fiabilité et ce qui tient en production. Un FDE transforme une compréhension métier en logiciel qui fonctionne.
Le marché a déjà tranché, et il y a mis 4 milliards de dollars
En mai 2026, OpenAI a lancé une coentreprise dédiée au déploiement, l'OpenAI Deployment Company, et racheté dans la foulée le cabinet Tomoro. L'opération lui apporte environ 150 Forward Deployed Engineers et spécialistes du déploiement dès le premier jour. Le capital initial dépasse 4 milliards de dollars, apportés par un consortium de 19 sociétés d'investissement, de cabinets de conseil et d'intégrateurs mené par TPG.
L'intention est claire. Il ne s'agit pas de vendre davantage de modèles, mais d'aller les installer chez les clients. Quand le principal éditeur de modèles construit une structure entière pour le déploiement, il reconnaît que la valeur ne se trouve plus dans le modèle seul.
Étape 1, comprendre comment le travail se fait vraiment
Le process documenté n'est presque jamais le process réel. Un mail arrive, il est recopié dans un tableur, vérifié dans un outil interne, validé sur une messagerie d'équipe, puis ressaisi dans l'ERP. La moitié des cas sont des exceptions, et leur logique vit dans la tête d'une seule personne.
C'est la raison pour laquelle notre audit IA commence par du terrain avant de chiffrer quoi que ce soit. Sur une mission récente dans un réseau de centres de santé, plusieurs des frictions les plus coûteuses ne figuraient dans aucun document. Deux d'entre elles se réglaient en activant des fonctions déjà présentes dans les outils du groupe, sans une ligne de code.
Étape 2, décider où l'IA a sa place et où elle n'en a pas
Sur un workflow de dix étapes, deux ou trois demandent du jugement. Le reste se règle en conditions et en appels d'API. Chaque fois que le déterminisme est possible, il faut l'utiliser, et réserver le modèle de langage aux zones de jugement. C'est le partage qui sépare un système qui tient d'une démonstration qui impressionne.
- Du logiciel déterministe quand les règles sont prévisibles. Moins cher, plus rapide, testable, et il ne se met pas à improviser un lundi matin.
- Un agent quand l'objectif est clair mais que le chemin varie. C'est là que le modèle apporte quelque chose qu'aucune règle écrite ne remplace.
- Un humain quand la décision est irréversible. Un remboursement, une résiliation, un refus de prise en charge ne se délèguent pas à un système probabiliste.
Ce raisonnement recoupe les quatre niveaux d'automatisation que nous détaillons dans nos articles sur les niveaux d'automatisation et sur la différence entre agents et workflows. L'erreur la plus fréquente est de sauter directement à l'agent autonome, alors qu'un assistant paramétré ou une automatisation simple suffisent dans la plupart des cas.
Étape 3, prouver que le système tient plutôt que le promettre
Dès qu'il y a du jugement, il y a du non-déterminisme. Les evals transforment ce non-déterminisme en preuve. Le principe est simple. Vous construisez un jeu de cas, vous mesurez le taux de réussite, et vous classez les échecs par catégorie.
- Le cas normal, celui que le système rencontrera le plus souvent.
- Le cas limite, celui qui est encore dans le périmètre mais tout juste.
- L'information manquante, pour vérifier que le système sait dire qu'il ne sait pas.
- La demande ambiguë, pour vérifier qu'il demande une précision au lieu d'inventer.
- L'action à risque, pour vérifier qu'il s'arrête et passe la main.
Colin Jarvis, responsable du forward deployed engineering chez OpenAI, en donne l'illustration la plus nette dans son entretien avec Altimeter. Sur un déploiement mené chez un acteur de la gestion de patrimoine, l'obstacle technique principal a été levé en six à huit semaines. Il a ensuite fallu quatre mois de plus de pilotes, de collecte d'evals et d'itérations pour que les conseillers fassent réellement confiance au système. À l'arrivée, l'outil a été adopté par la quasi-totalité d'entre eux.
La boucle complète, de l'audit à l'amélioration
Les trois étapes s'enchaînent dans une boucle qui ne s'arrête pas. Audit, construction, evals, déploiement, observation, amélioration. Puis la boucle recommence, parce qu'un format change, un produit évolue et un modèle est mis à jour.
C'est la logique que Tandem applique sur ses missions, et elle est décrite pas à pas dans notre méthode d'audit IA. Le diagnostic du process réel vient toujours avant la moindre ligne de code.
Comment devenir Forward Deployed Engineer en quatre semaines
Le rôle s'apprend en construisant, pas en lisant. Voici la feuille de route que je donne aux profils qui veulent basculer sur ce métier. Elle suppose de savoir coder un minimum, et de disposer d'un vrai process à automatiser, même petit.
| Semaine | Objectif | Ce qui doit exister à la fin |
|---|---|---|
| 1 | Une boucle qui tourne | Un agent qui accomplit un vrai workflow de bout en bout, deux outils, des garde-fous, un journal d'audit |
| 2 | Un système qui tient | Sorties structurées en JSON, validation de schéma, modes de défaillance identifiés, redémarrage au dernier point de reprise |
| 3 | Un coût mesuré | Retry avec backoff, taxonomie des échecs, jeu de données de référence annoté à la main, coût par requête |
| 4 | Un système défendable | L'architecture, ce que la v1 a raté, les evals et l'économie du système, expliqués à un ingénieur comme à un dirigeant |
La quatrième semaine est celle qui départage. Vous devez pouvoir expliquer le même système à un ingénieur et à un dirigeant non technique. Le point de douleur, la raison pour laquelle l'IA a sa place ici, l'architecture, ce que la première version a raté, les evals, et ce que ça coûte. Un candidat qui ne sait défendre que la moitié technique n'est pas encore un FDE.
Faut-il un FDE interne ou un partenaire externe ?
Les deux fonctionnent, et ils ne servent pas le même moment. Un partenaire externe apporte le recul de dizaines de déploiements et va vite sur les premiers cas d'usage. Un FDE interne connaît les exceptions maison et tient la boucle d'amélioration dans la durée.
La séquence qui marche est presque toujours la même. Un partenaire cadre et livre les deux ou trois premiers cas, en formant au passage la personne qui reprendra le sujet. Puis l'entreprise internalise. Sur une mission menée chez un éditeur de santé numérique, la session de clôture a été animée par l'équipe interne. Le rôle d'accompagnement était déjà internalisé au départ de Tandem.
Le contre-exemple à éviter est le recrutement d'un FDE unique, sans process écrit ni socle documentaire. Il passera ses six premiers mois à faire de l'archéologie plutôt que du déploiement. Un corpus documentaire propre conditionne la moitié des chantiers qui suivent.
Par où commencer si vous voulez déployer l'IA sérieusement ?
Commencez par le process réel, pas par le modèle. Asseyez-vous une journée à côté de l'équipe qui fait le travail, et écrivez ce que vous voyez. C'est le point de départ du carrousel que j'ai publié sur le métier du déploiement de l'IA, et c'est aussi le point de départ de chacune de nos missions.
Ensuite, tracez la ligne entre ce qui relève du déterminisme et ce qui relève du jugement. Puis construisez les evals avant de promettre quoi que ce soit. Ces trois gestes suffisent à sortir du lot des 95 % de projets sans retour mesurable, et aucun des trois ne dépend du modèle que vous aurez choisi.
Une dernière chose. Si votre système ne sait pas dire qu'il n'est pas sûr, il n'est pas prêt à toucher un process de production.
