Forward Deployed Engineers (FDE) : pourquoi les entreprises d'IA envoient leurs ingénieurs chez leurs clients

Depuis deux ans, un nouveau poste apparaît sans cesse dans les offres d'emploi des entreprises d'IA : le Forward Deployed Engineer (FDE, ou ingénieur déployé en première ligne). Ces ingénieurs ne développent pas des produits génériques depuis le siège ; ils se rendent chez les clients avec les modèles et la plateforme, et travaillent avec les équipes métier pour brancher l'IA sur les données, les processus et les systèmes réels. Le succès des FDE montre une chose : la partie la plus difficile du déploiement de l'IA ne se trouve pas dans le modèle lui-même, mais dans le « dernier kilomètre » à l'intérieur de l'entreprise cliente.

Que font donc exactement les FDE ? Pourquoi des éditeurs de modèles comme OpenAI et Anthropic constituent-ils eux aussi de telles équipes à grande échelle ? Dans cet article, nous présentons la définition et l'origine du rôle de FDE, le contexte dans lequel les entreprises d'IA créent ces équipes, les raisons pour lesquelles le déploiement de l'IA a besoin de ce rôle, les différences entre les FDE et plusieurs postes voisins ainsi que les compétences requises, et enfin la façon dont les entreprises peuvent travailler avec des FDE et former leurs propres « FDE internes ».

Qu'est-ce qu'un Forward Deployed Engineer (FDE) ?

Un FDE est « un ingénieur logiciel installé aux côtés du client ». Il écrit du code, construit des pipelines de données, configure des systèmes, mais il ne sert pas « tous les clients » : il sert un client précis, et sa réussite se mesure à la résolution des problèmes métier de ce client. Un ingénieur classique développe une fonctionnalité pour de nombreux clients ; un FDE combine de nombreuses fonctionnalités pour un seul client.

Ce rôle s'est fait connaître grâce à Palantir, éditeur de logiciels d'analyse de données (source). Dans son blog officiel, dans l'article « Dev versus Delta », Palantir distingue deux types d'ingénieurs : les ingénieurs logiciel rattachés à la R&D produit (appelés « Dev » en interne) construisent un composant de la plateforme et se concentrent sur « une capacité au service de nombreux clients » ; les ingénieurs logiciel déployés en première ligne, rattachés au développement commercial (appelés « Delta » en interne), forment des équipes autour d'un seul client et se concentrent sur « un client, de nombreuses capacités » : leur réussite se juge aux résultats métier du client, par exemple la baisse des défauts sur une ligne de production (source). Les Delta interrogés dans cet article passent une part importante de leur semaine sur site chez le client.

Un autre article du blog de Palantir détaille le quotidien d'un FDE : concevoir, développer et déployer pour le client des processus métier et des modèles de données dédiés ; construire et maintenir les pipelines de données à grande échelle qui soutiennent l'activité ; configurer les droits d'accès conformément aux exigences réglementaires et de conformité ; assurer la stabilité, les mises à jour et la supervision des systèmes de production, et identifier la cause racine en cas de panne ; enfin, remonter à l'équipe produit ce qui a été appris sur le terrain et intégrer à la plateforme les solutions de valeur générale (source).

Il est notable que Palantir distingue explicitement les FDE des consultants. Selon elle, les FDE s'appuient sur une plateforme logicielle et des composants existants, avec pour objectif de construire pour le client des systèmes durables, et non de produire des analyses ponctuelles ou de bricoler une solution sur mesure pour chaque client. C'est la différence la plus fondamentale entre les FDE et le conseil traditionnel : ce qui est livré, c'est un système qui fonctionne dans la durée, et non des recommandations.

Pourquoi les entreprises d'IA constituent-elles des équipes de FDE ?

Les éditeurs de modèles étaient au départ les plus proches d'entreprises qui « vendent un produit standard », et pourtant ils envoient eux aussi des ingénieurs chez leurs clients. La raison est simple : le client a acheté le modèle, mais n'arrive pas forcément à l'utiliser ; s'il ne l'utilise pas, le contrat est difficile à renouveler et à étendre.

Plusieurs informations publiques illustrent cette tendance :

• La demande de postes augmente rapidement. En novembre 2025, eWeek, citant le Financial Times, indiquait qu'OpenAI, Anthropic, Cohere et d'autres développaient leurs équipes de FDE ; selon les données du site d'emploi Indeed, les offres de postes de FDE ont progressé de plus de 800 % entre janvier et septembre 2025 (source). Précisons qu'il s'agit d'une hausse relative, qui ne signifie pas que le nombre absolu de ces postes soit déjà élevé.
• Les éditeurs de modèles étoffent leurs équipes. Le même article mentionne qu'OpenAI a constitué son équipe de FDE début 2024 et prévoyait de l'élargir à environ 50 personnes en 2025 ; Anthropic prévoyait de multiplier par cinq en 2025 son équipe d'IA appliquée, FDE compris.
• Le déploiement est devenu une activité à part entière. En mai 2026, OpenAI a annoncé la création d'une entreprise de déploiement à gestion indépendante (OpenAI Deployment Company), dotée d'un investissement initial de plus de 4 milliards de dollars, mené par TPG avec 19 investisseurs, sociétés de conseil et intégrateurs de systèmes ; OpenAI a également annoncé l'acquisition de Tomoro, société de conseil en IA appliquée, qui devrait apporter environ 150 FDE et spécialistes du déploiement (source). Selon la description d'OpenAI, ces FDE intégreront l'organisation du client, identifieront les domaines où l'IA est la plus utile, repenseront autour d'eux les processus et l'infrastructure, et connecteront les modèles aux données, aux outils et aux processus métier du client.
• Les exigences de recrutement sont très concrètes. La page de recrutement actuelle d'Anthropic pour les FDE précise que ce poste est rattaché à l'équipe d'IA appliquée, qu'il s'agit de s'intégrer au sein de clients stratégiques pour construire, sur la base de Claude, des applications prêtes pour la production, avec 25 à 50 % du temps en déplacement chez le client (source).

Dans un article de juin 2025, la société d'investissement a16z qualifie cette approche de « croissance tirée par les services » (services-led growth) : les produits d'IA d'entreprise exigent un important travail de mise en œuvre, et les start-up peuvent accepter une marge brute plus faible au départ pour intégrer en profondeur, par les services, les processus et les données du client (source). Autrement dit, le FDE est à la fois un moyen de livraison et la manière dont une entreprise d'IA s'enracine chez son client.

Pourquoi le déploiement de l'IA a-t-il besoin d'un rôle comme celui de FDE ?

Les grands modèles sont généralistes, alors que l'activité d'une entreprise est spécifique. Le modèle sait ce que signifie « retour de marchandise », mais il ignore combien de validations votre entreprise exige pour un retour, dans quel système se trouvent les données, et quels clients bénéficient d'une politique d'exception. Intégrer ces connaissances spécifiques, c'est le « dernier kilomètre » du déploiement de l'IA.

Ce dernier kilomètre se heurte généralement à trois obstacles :

• Les données. Les données de l'entreprise sont dispersées entre l'ERP, le CRM, le système d'entrepôt, les tableurs et les e-mails, avec des définitions incohérentes et des droits d'accès différents. Pour répondre à « pourquoi cette commande n'est-elle pas encore expédiée ? », l'IA doit pouvoir lire en toute sécurité les données de commande, de stock et de logistique.
• Les processus. Les processus métier réels comportent de nombreuses règles et exceptions qui ne figurent dans aucun document. Par exemple, pour une demande d'achat, la signature de la direction générale est requise au-delà d'un certain montant, et certains fournisseurs exigent une comparaison de prix supplémentaire. Ces règles ne se découvrent qu'en les cartographiant sur place avec les équipes de terrain.
• Les systèmes. Pour que les recommandations de l'IA se transforment en actions, elles doivent être réécrites dans les systèmes métier : créer un ticket, mettre à jour un stock, générer une facture. La stabilité des interfaces, le traitement des échecs, la définition de qui est autorisé à exécuter l'action : tout cela relève d'un jugement d'ingénierie.

L'article de a16z souligne aussi que les agents d'IA doivent se connecter en toute sécurité aux bases de données, aux interfaces et aux workflows internes de l'entreprise, et comprendre la logique métier et l'historique ; mettre un agent en service ressemble beaucoup à l'intégration d'un nouveau collaborateur (source). La répartition traditionnelle des rôles ne suffit souvent pas ici : l'équipe produit est trop loin du client pour voir les problèmes concrets ; le consultant en mise en œuvre connaît les processus, mais ne sait pas forcément coder ni ajuster un modèle ; l'équipe informatique de l'entreprise connaît les systèmes, mais pas nécessairement les caractéristiques et les limites des grands modèles. La valeur du FDE est de réunir, chez une même personne ou dans une même petite équipe, la compréhension du métier, des systèmes et des modèles.

Prenons l'exemple d'une entreprise de distribution en gros qui veut que l'IA traite automatiquement les commandes envoyées par e-mail par ses clients. Lors de la démonstration, le modèle extrait avec précision les produits et les quantités d'un e-mail bien formaté ; mais sur place, le FDE découvre que les clients utilisent chacun leurs propres abréviations de produits, que certaines commandes sont accompagnées de scans manuscrits, et que d'autres exigent de vérifier d'abord la limite de crédit. Ce n'est qu'en intégrant la table de correspondance des produits, les règles de crédit et le circuit de renvoi des exceptions vers un opérateur que cette IA devient réellement utilisable.

En quoi un FDE diffère-t-il d'un ingénieur logiciel, d'un consultant en mise en œuvre ou d'un ingénieur avant-vente ?

Le FDE se confond facilement avec plusieurs postes voisins. En résumé, le FDE est proche du client comme un consultant en mise en œuvre, construit le système de ses propres mains comme un ingénieur logiciel, et répond en plus des résultats métier après la mise en production.

Le tableau ci-dessous compare ces quatre rôles selon plusieurs dimensions :

Les entreprises ne définissent pas toutes ces postes de la même façon ; le tableau reflète la répartition la plus courante et n'a qu'une valeur indicative.

Quelles compétences faut-il pour être un bon FDE ?

Les compétences d'un FDE sont « en T » : l'expertise en ingénierie doit être profonde, la compréhension du métier et la communication doivent être larges. Ce qui est le plus rare, ce n'est pas une compétence isolée, mais la capacité à faire avancer les choses de façon autonome dans un environnement client flou et changeant.

À partir des descriptions de poste de Palantir et des exigences de recrutement d'Anthropic, on peut distinguer cinq catégories de compétences :

• Une solide capacité d'ingénierie. Savoir écrire du code destiné à la production, construire des pipelines de données et réaliser des intégrations de systèmes. La page de recrutement d'Anthropic exige une expérience de l'usage des grands modèles en production, notamment la conception de prompts, le développement d'agents et les méthodes d'évaluation, ainsi qu'une bonne maîtrise de Python (source).
• Apprendre vite un domaine inconnu. Aujourd'hui, c'est le processus de contrôle qualité d'un industriel ; le mois prochain, ce sera le système de planification d'une entreprise de logistique. Palantir range la « maîtrise rapide de systèmes, de domaines et de bases de code peu familiers » parmi les capacités attendues d'un FDE (source).
• Traduire un problème métier en solution technique. Comprendre les plaintes des équipes métier, creuser jusqu'au vrai problème sous-jacent, puis décider ce qui revient à l'IA, ce qui relève de règles, et ce qu'il vaut mieux ne pas faire.
• Communication et construction de la confiance. Le FDE doit faire face à la fois aux équipes de terrain, à la DSI et à la direction, tout en coordonnant l'équipe produit de sa propre entreprise. La page de recrutement d'Anthropic attend explicitement des FDE qu'ils travaillent de manière autonome, restent efficaces dans l'incertitude et communiquent bien.
• La responsabilité des résultats. Le travail d'un FDE ne s'arrête pas quand la démonstration réussit : il suit la stabilité du système et ses effets métier après la mise en production, et transforme les pratiques réutilisables en méthodes qu'il remonte à l'équipe produit.

Comment travailler avec des FDE ou former ses propres « FDE internes » ? Guide pas à pas

Pour la plupart des PME, les FDE des éditeurs de modèles ne viendront pas forcément frapper à la porte. Mais leur façon de travailler peut parfaitement servir d'inspiration : que l'on collabore avec une équipe externe ou que l'on forme des talents en interne, le principe central est que les personnes qui connaissent le métier et celles qui connaissent la technique travaillent côte à côte sur un même problème concret.

Étape 1 : choisir d'abord un problème métier concret et mesurable. Ne partez pas de « nous voulons utiliser l'IA », mais d'une difficulté précise comme « la saisie des commandes mobilise trois personnes chaque jour » ou « le rapprochement de fin de mois prend une semaine ». OpenAI décrit elle aussi ses services de déploiement comme un diagnostic ciblé, suivi d'un travail concentré sur quelques processus prioritaires (source).

Étape 2 : préparer à l'avance l'accès aux données et aux systèmes. L'attente la plus fréquente d'un FDE, c'est l'attente des données et des droits d'accès. Avant le début de la collaboration, il faut déterminer quels systèmes seront connectés, qui valide les droits d'accès et quelles données ne doivent pas sortir de l'entreprise, afin que les ingénieurs n'arrivent pas sans rien à faire.

Étape 3 : désigner un responsable métier, impliqué du début à la fin. Aussi compétent soit-il, un FDE externe ne connaît ni vos règles d'exception ni vos règles tacites. L'entreprise a besoin d'un responsable métier qui connaît bien le processus et dispose d'un pouvoir de décision, afin de faire chaque semaine le point avec le FDE, de répondre aux questions et de trancher les arbitrages.

Étape 4 : construire ensemble sur place, par petites itérations rapides. Faites s'installer le FDE à côté du service métier, commencez par une version minimale capable de traiter de vrais documents, puis améliorez-la progressivement selon les retours du terrain. Chaque itération doit être validée sur des données réelles, et non sur le seul effet d'une démonstration.

Étape 5 : mettre en place l'exploitation et la passation dès la mise en production. Précisez qui intervient en cas de problème, qui décide des ajustements du modèle ou du processus, où sont conservés les journaux d'opérations. Avant le départ de l'équipe externe, la documentation, la formation et la passation des droits doivent être terminées, pour que le système ne dépende pas d'une seule personne extérieure.

Étape 6 : former des FDE internes grâce à la collaboration. Choisissez un ou deux collaborateurs qui connaissent le métier et souhaitent apprendre la technique (par exemple un ingénieur de la DSI qui fréquente souvent le terrain, ou un référent métier à l'aise avec les données), faites-les suivre l'équipe externe tout au long du projet, puis laissez-les prendre progressivement la direction à partir du deuxième projet. La valeur d'un FDE interne, c'est que le prochain projet d'IA n'a pas à repartir de zéro.

Questions fréquentes sur les Forward Deployed Engineers (FDE)

Quelle est la différence entre un FDE et un développement externalisé ? Le développement externalisé livre généralement des fonctionnalités à partir d'un cahier des charges que le client doit rédiger clairement ; le FDE, lui, découvre et définit le problème avec le client, répond des résultats métier et construit sa solution sur une plateforme et des produits existants, plutôt que de partir de zéro.

Une PME doit-elle recruter spécifiquement des FDE ? Pas nécessairement. L'approche la plus réaliste pour une PME consiste, lors de la collaboration avec une équipe externe, à impliquer en profondeur des collaborateurs clés pour former progressivement un ou deux « FDE internes » associant compétences métier et techniques.

La demande de FDE croît très vite : s'agit-il d'un engouement passager ? L'intitulé du poste pourrait changer, mais le besoin derrière ce rôle a peu de chances de disparaître : tant que les modèles seront généralistes et l'activité spécifique, il faudra quelqu'un pour relier les deux. À mesure que les outils mûriront, une partie du travail d'intégration deviendra plus simple, mais la compréhension du métier et la responsabilité des résultats resteront l'affaire des personnes.

Sur quoi juger la réussite d'une collaboration avec un FDE ? Trois points comptent : le système est-il réellement entré dans l'usage quotidien, les indicateurs métier convenus se sont-ils améliorés, et l'entreprise peut-elle le maintenir et le faire évoluer seule après le départ de l'équipe externe. Se fier uniquement à l'effet des démonstrations ou au nombre de fonctionnalités livrées conduit souvent à surestimer les résultats.

Références

• Dev versus Delta: Demystifying engineering roles at Palantir, blog officiel de Palantir, date de publication non indiquée sur la page (consulté en novembre 2026)
• A Day in the Life of a Palantir Forward Deployed Software Engineer, blog officiel de Palantir, date de publication non indiquée sur la page (consulté en novembre 2026)
• Why Forward-Deployed Engineers Are in High Demand, eWeek, novembre 2025
• OpenAI launches the Deployment Company, OpenAI, mai 2026
• Forward Deployed Engineer (page de recrutement), Anthropic, consulté en novembre 2026
• Services-Led Growth, a16z, juin 2025