Le constat de départ
Un forward deployed engineer est un ingénieur senior qui travaille à l'intérieur de votre organisation plutôt qu'à côté : vos dépôts, votre CI, vos données, votre astreinte, dès la première semaine. La distinction ne tient ni au titre ni au plan de bureaux. Elle tient au fait que l'ingénieur qui a cadré le problème est celui qui écrit le code, et qu'il répond d'un système en production, pas d'un document qui le décrit.
Le terme vient de Palantir, qui a bâti son modèle de livraison autour de ce rôle et en énonce clairement l'inversion : là où un ingénieur classique crée une capacité unique utilisée par de nombreux clients, un forward deployed software engineer met de nombreuses capacités au service d'un seul client. Cette inversion est toute l'idée. Le rôle optimise pour la réalité désordonnée d'une organisation, pas pour un produit générique.
Cette page s'adresse à la personne qui achète la prestation, pas à celle qui postule. Ce que le rôle fait réellement, pourquoi toutes les entreprises d'IA en recrutent soudainement, en quoi il diffère d'un consultant, d'une agence ou d'un prestataire en régie, et la seule question qui sépare un vrai engagement forward deployed d'une régie qui a changé de nom.
De l'idée à la production
La façon dont SDEN transforme une idée comme celle-ci en un système que vous exploitez.
Dans votre environnement, responsable de la production
Forward deployed décrit où le travail se fait et qui porte le résultat, pas le niveau de séniorité.
Au quotidien, un forward deployed engineer se tient près des personnes qui utiliseront le système, apprend un métier qui n'est pas le sien et écrit du code dans les dépôts du client, sur les données du client. Un ingénieur produit optimise pour la généralité, puisque son code doit servir tous les clients. Un forward deployed engineer optimise pour la spécificité : ce modèle de données précis, ses exceptions, le tableur qui fait tourner la finance en silence, l'intégration que personne n'a documentée.
Le rôle est hybride, et les trois composantes doivent être présentes. Assez de jugement produit pour décider quoi construire, assez d'ingénierie pour le construire au niveau production, et assez d'aisance relationnelle pour mener la conversation sans couche de traduction. Retirez l'une des trois et le rôle retombe dans une catégorie plus familière : un architecte de solutions qui ne livre pas, un prestataire qui ne cadre pas, ou un ingénieur avant-vente qui fait des démonstrations plutôt que des déploiements.
Deux choses le séparent du conseil. Le livrable est un logiciel qui tourne plutôt qu'une recommandation, et la boucle de retour fonctionne dans les deux sens : ce que l'ingénieur apprend sur le terrain est censé changer ce qui sera construit ensuite. Palantir a rendu cette boucle explicite dans sa description du rôle, et les offres forward deployed d'OpenAI décrivent la même chose, avec l'adoption en production et les retours guidés par les évaluations qui alimentent la feuille de route produit et modèles.
L'IA a déplacé la difficulté sur le dernier kilomètre
Les modèles de pointe sont accessibles à tous aux mêmes conditions. En faire un système qui survit à vos cas particuliers, non.
L'écart entre les entreprises ne tient plus à l'accès aux modèles. Il tient à la capacité d'en brancher un sur un vrai flux de travail : les données réelles avec leurs trous réels, le harnais d'évaluation qui dit si la chose fonctionne, les garde-fous, le plafond de coût et le repli non IA pour le jour où le système dérape. Rien de tout cela ne se généralise proprement en produit, parce que le désordre est propre à chaque entreprise. Quelqu'un doit aller s'y asseoir.
C'est pour cela que le terme s'est propagé de Palantir aux grands laboratoires. Le 11 mai 2026, OpenAI a lancé une société dédiée au déploiement et annoncé l'acquisition de Tomoro, ce qui lui apporte environ 150 forward deployed engineers et spécialistes du déploiement expérimentés dès le premier jour. Quand l'organisation qui dispose des meilleurs modèles conclut que le déploiement mérite sa propre société, cela en dit long sur l'endroit où réside désormais la difficulté.
Pour un acheteur, cela a une conséquence pratique. La demande a dépassé le nombre de personnes réellement capables de tenir le rôle, si bien que l'étiquette est aujourd'hui apposée sur des prestations qui n'ont rien à voir. La suite de cette page sert à faire la différence avant de signer, car les propositions se ressemblent beaucoup.
Quatre modèles qui se ressemblent sur une proposition
La différence porte sur ce que vous achetez réellement, et les contrats sont souvent rédigés de façon à la brouiller.
Un consultant vend du jugement. Le livrable est une recommandation, et les meilleurs changent réellement vos décisions. Ce qu'aucun ne laisse derrière lui, c'est un système qui tourne. Un engagement forward deployed prend l'engagement inverse : le livrable est un logiciel en production, exploité puis transmis. Un filtre simple consiste à se demander si la mission pourrait se terminer par un document et être considérée comme réussie. Si oui, vous achetez du conseil, ce qui peut être le bon achat, mais pas celui-ci.
Une agence vend de la capacité de production sur un backlog qui reste le vôtre. Les agences sont excellentes sur le volume standardisé et sur des spécialités qu'une petite équipe senior n'internalise jamais, et elles peinent quand le travail exige un jugement d'architecture que le client ne peut pas fournir. Un engagement forward deployed suppose l'inverse : ce jugement est précisément ce que vous payez, ce qui en fait aussi un mauvais choix pour un travail que vous sauriez spécifier vous-même.
La régie est le jumeau le plus proche et de loin le renommage le plus fréquent. Les deux modèles placent des ingénieurs seniors dans votre environnement, donc de l'extérieur ils se ressemblent. Ce qui est acheté diffère. La régie achète de la capacité sur un backlog dont vous restez propriétaire, facturée à l'heure, qui s'arrête quand vous cessez de payer. L'ingénierie forward deployed achète un résultat : les ingénieurs portent l'architecture pendant leur déploiement, le périmètre est un jalon de production plutôt qu'un backlog, et la mission se termine à une date de transfert nommée, quand votre équipe prend la main.
Le recrutement interne est la bonne réponse pour le produit cœur, quand la direction a la bande passante pour recruter et garder des seniors et que le travail est permanent plutôt que ponctuel. La plupart des entreprises finissent hybrides : en interne pour le cœur, un partenaire forward deployed pour les parties qui demandent du jugement senior maintenant et une équipe permanente jamais.
Demandez la date de transfert
Si un prestataire se dit forward deployed et ne sait pas vous dire quand la mission se termine ni ce que vous possédez ce jour-là, il vous vend de la régie.
La question ne coûte rien et il est très difficile d'y répondre malhonnêtement. Une vraie réponse donne une date, énumère ce qui est transféré ce jour-là (les dépôts, le harnais d'évaluation qui tourne dans votre CI, les runbooks, la supervision, le plan d'astreinte) et nomme la personne de votre côté qui en prendra la charge. Un prestataire qui travaille ainsi a la réponse prête, parce que la date structure toute la mission.
Trois modes d'échec apparaissent immédiatement. Il n'y a pas de date, et la mission est un abonnement sans fin sous un meilleur nom. Il y a une date mais rien qui y soit rattaché, donc le travail s'arrête et la connaissance opérationnelle part avec. Ou il y a une date accompagnée d'un renouvellement déjà prévu, ce qui est une dépendance présentée comme un partenariat. Aucun de ces achats n'est forcément mauvais, mais aucun ne correspond à ce que forward deployed est censé vouloir dire.
Deux questions de suivi terminent le travail. Qui écrit le code, précisément : si la personne qui a cadré n'est pas celle qui construit, il y a une couche de traduction et vous la paierez deux fois, en honoraires puis en exigences perdues au passage. Et où vit le code dès le premier jour : s'il reste dans les dépôts du prestataire jusqu'à la fin, vous avez acheté un événement de transmission, ce qui échoue bien plus souvent qu'un processus de transmission.
Trois engagements sur chaque mission
SDEN est un partenaire d'ingénierie forward deployed : des ingénieurs seniors qui travaillent dans vos dépôts pour construire les systèmes agentiques dont vous devenez propriétaire. Voici les engagements qui rendent l'étiquette honnête.
Dans votre stack dès le premier jour
Vos dépôts, votre CI, vos données, votre astreinte. Il n'y a pas de base de code parallèle jetée par-dessus le mur à la fin, et l'ingénieur qui a cadré le travail est celui qui l'écrit.
Une date de transfert nommée au contrat
Le périmètre est un jalon de production, pas un backlog. La mission se termine à une date convenue dès le départ, avec le transfert de propriété intellectuelle inscrit au contrat plutôt que promis en réunion.
La transmission comme processus, pas comme événement
Runbooks, supervision et harnais d'évaluation livrés dans votre CI, plus une période de support pendant laquelle nous exploitons le système avec votre ingénieur référent avant de nous retirer.
Un système que votre équipe fait encore tourner après notre départ
La mesure d'une mission forward deployed n'est pas ce qui a été livré. C'est ce que votre équipe peut modifier sans risque six mois plus tard.
À la date de transfert, votre équipe doit pouvoir répondre à trois questions sans appeler personne : où vit le code, comment savons-nous qu'il fonctionne toujours, et que faisons-nous quand il casse. Cela correspond aux dépôts, au harnais d'évaluation dans votre CI et aux runbooks. Si l'une des trois exige un coup de téléphone, la transmission n'a pas eu lieu, quoi qu'en dise le contrat.
L'échec courant est plus subtil qu'un projet raté. Le système fonctionne, personne dans l'entreprise ne le comprend, et ceux qui l'ont construit sont les seuls à pouvoir le modifier. C'est à la fois un produit qui marche et un risque stratégique, et on le découvre en général au pire moment : quand un tarif augmente ou qu'une personne clé s'en va.
Le rôle vaut d'être acheté quand le travail est assez spécifique pour qu'aucun produit ne le couvre jamais, et assez important pour devoir continuer à tourner après la fin de la mission. Si seule la première condition est vraie, vous achetez un prestataire. Si seule la seconde l'est, achetez le produit. Quand les deux le sont, exigez la date de transfert.
Ingénierie de l'IA
les questions qu'on nous pose le plus.
Des réponses directes aux questions qu'on nous pose le plus souvent. Si la vôtre n'y est pas, écrivez à l'équipe.