Pendant trois ans, la question de savoir pourquoi l'IA n'atterrit pas dans les entreprises a été traitée en regardant le modèle. Le contexte, les hallucinations, le prochain sera le bon. Et le prochain est arrivé, puis un autre, et le processus de ton entreprise se fait toujours à la main. En 2026, le marché a arrêté de faire semblant que le problème venait du modèle et il a donné un nom à ce qui manquait : une personne.
La thèse en une phrase : tu n'as pas besoin de recruter un forward deployed engineer. Tu as besoin de la fonction que ce rôle représente, achetée en fractions et rattachée à un workflow précis plutôt qu'à une plateforme. Et cette distinction, qui a l'air d'une nuance, c'est la différence entre brûler un budget annuel et avoir un processus qui tourne en six semaines.
Ce qu'est un forward deployed engineer et pourquoi le nom sort maintenant
Un forward deployed engineer est un ingénieur qui travaille à l'intérieur du client : il comprend le processus réel, construit la solution collée aux systèmes qui existent déjà et ne s'en va pas tant que ça ne tourne pas en production. Mi-ingénieur, mi-consultant de terrain. Palantir pratique la figure depuis deux décennies ; la définition canonique, avec responsabilités, compétences et les cas où il ne faut PAS le recruter, est dans la fiche forward deployed AI engineer de notre catalogue de rôles, et on ne va pas la répéter ici.
Ce qu'il faut expliquer, en revanche, c'est pourquoi le titre a explosé maintenant, et la réponse a une date. Le 11 mai 2026, OpenAI a annoncé l'OpenAI Deployment Company, une unité de business indépendante créée, selon ses propres mots, pour pouvoir développer le modèle opérationnel, le rythme et la concentration sur le client qu'exige ce travail. Sa fonction déclarée : incruster des forward deployed engineers dans des organisations qui résolvent des problèmes complexes dans des environnements exigeants. Et pour ne pas partir de zéro, dans la même annonce, elle a acté le rachat de Tomoro, un cabinet d'IA appliquée qui apporte environ 150 FDE et spécialistes du déploiement dès le premier jour. Source : OpenAI launches the OpenAI Deployment Company, OpenAI, 11 mai 2026.
Relis ça, parce que c'est un aveu. L'entreprise qui fabrique le modèle le plus vendu au monde a décidé que, pour que son produit marche dans une entreprise, il fallait monter une autre entreprise et acheter cent cinquante personnes. Le goulot d'étranglement n'est plus l'intelligence. C'est l'atterrissage.
Ce que le rôle n'est pas, et pourquoi la confusion te coûte de l'argent
Trois profils se vendent aujourd'hui avec le même discours et font des choses différentes. Les distinguer, c'est ce qui évite d'acheter le mauvais :
- Ce n'est pas un consultant. Le consultant livre un document avec ce que tu devrais faire. Le FDE livre le processus fait. Si à la fin de la mission ce que tu as en main est une présentation, tu as acheté du conseil avec un nom neuf.
- Ce n'est pas un AI engineer. L'AI engineer construit le système ; le FDE construit le système et découvre quel était le problème — la partie que personne n'a écrite nulle part et qui mange 70 % du calendrier.
- Ce n'est pas du customer success. Le customer success s'assure que tu utilises ce que tu as acheté. Le FDE change ce que tu as acheté jusqu'à ce que ça colle à la façon dont tes gens travaillent vraiment, pas à celle que décrit le manuel.
Le test décisif tient en une seule question : cette personne va-t-elle écrire du code contre mes systèmes, ou écrire sur mes systèmes ? Tout le reste, ce sont des titres.
Le problème : le format enterprise n'est pas fait pour toi
Voilà la partie inconfortable. Le rôle est réel, c'est celui qui marche, et la façon dont il se vend est conçue pour l'autre bout du marché. La version enterprise, c'est une équipe dédiée pendant des mois, incrustée dans l'organisation, avec un engagement pluriannuel et —presque toujours— rattachée à la plateforme de celui qui déploie. Ça marche. Et une entreprise de 50 à 500 personnes ne peut pas l'acheter, pour deux raisons distinctes qu'il vaut mieux ne pas mélanger.
La première est évidente : le prix. La seconde l'est moins, et elle est pire. Même si tu pouvais payer, tu n'as pas assez de travail pour un poste à temps plein, et un FDE sans file de problèmes devient un salarié cher qui attend. Le besoin de ton entreprise n'est pas continu : il est intense pendant six ou huit semaines par processus, puis il retombe en maintenance. Recruter en interne une demande qui a cette forme, c'est exactement l'erreur que tu répètes depuis des années avec d'autres profils.
Et il y a une troisième raison, silencieuse, qui n'apparaît que l'année d'après : l'attachement à la plateforme. Si celui qui s'incruste dans ton opération se rémunère sur la consommation de son propre produit, la solution qu'il va concevoir tournera sur son produit. Pas par mauvaise foi —par gravité. C'est le même piège que celui expliqué dans plateformes pour créer des agents IA : le coût de sortie ne se paie pas à la signature, il se paie au mois 7.
Tu n'as pas besoin du poste, tu as besoin de la fonction
La sortie, ce n'est pas de renoncer au rôle. C'est de l'acheter sous une autre forme : en fractions, par workflow, avec une fin écrite. Au lieu d'un ingénieur incrusté indéfiniment, une mission bornée à un processus —celui qui fait le plus mal— avec une date à laquelle ce processus tourne tout seul et une personne de chez toi qui reste propriétaire.
La différence pratique, c'est que l'objet de l'achat cesse d'être le temps d'une personne pour devenir un processus en production. Ça change qui porte le risque. Si le projet traîne, en modèle horaire tu paies plus ; en modèle au résultat, non. C'est la même logique qu'on applique en montant des agents IA pour l'entreprise, et la raison pour laquelle la première conversation porte toujours sur le processus et jamais sur le modèle.
Le vrai travail, en plus, ressemble très peu à ce que promet la démo. L'essentiel du calendrier part dans l'intégration de l'IA avec les systèmes que tu as déjà —l'ERP de 2011, le CRM avec des champs dont personne ne se rappelle l'usage, l'Excel qui est en réalité la base de données de la boîte— et dans la découverte que le processus documenté et le processus réel n'ont rien à voir. Ça, un meilleur modèle ne le résout pas. Ça se résout avec quelqu'un assis là.
Les trois choses à exiger par écrit avant de signer
Peu importe qui tu recrutes —gros prestataire, boutique, indépendant, nous—. Si ces trois-là ne sont pas écrites avant de commencer, ce que tu as acheté c'est du temps, pas un résultat :
- Quel processus reste en production, nommé. Pas « des capacités IA sur le périmètre commercial ». Le nom du processus, avec son déclencheur et sa sortie : « le tri et la première réponse aux e-mails qui arrivent au support ». Si ça ne tient pas en une phrase, ce n'est pas borné.
- Comment ça se mesure, avec le chiffre d'aujourd'hui. L'indicateur et sa valeur actuelle, relevés avant de commencer. Sans ligne de base, dans trois mois le débat sur « est-ce que ça a marché » est un débat d'opinions, et celui-là, c'est toujours celui qui facture qui le gagne.
- Qui l'opère quand celui qui est venu s'en va. Nom et prénom de ton côté, formé pendant la mission et pas la dernière semaine. C'est celle qu'on saute le plus souvent et la seule qui décide si le système est encore vivant l'année prochaine.
La troisième mérite un paragraphe à part, parce que c'est là que meurent la plupart des déploiements techniquement réussis. Un processus automatisé sans propriétaire interne ne tombe pas le premier mois : il tombe le jour où une règle de gestion change et où personne ne sait où toucher. C'est tout le problème de qui maintient les agents IA, et ça ne se règle pas avec de la documentation : ça se règle avec une personne qui était devant pendant qu'on construisait.
Ce que ce nouveau nom confirme
Que le marché invente un titre et monte une unité de business pour le soutenir, ce n'est pas une mode de nomenclature : c'est l'aveu public que le logiciel seul ne s'implante pas. Si le fabricant du modèle a besoin de cent cinquante personnes incrustées chez ses clients pour que son produit rende, la question à poser à ton prestataire IA cesse d'être quel modèle il utilise et devient qui s'assoit avec toi, et jusqu'à quand.
Nous, on porte ce modèle depuis le début, sans le titre : des employés IA qui livrent un processus qui tourne, avec un propriétaire interne et la métrique écrite avant de commencer. Si tu veux le vocabulaire rangé avant cette conversation, il est dans le glossaire AI Operations. L'IA ne se présente pas. On l'implémente —et quelqu'un doit être là le jour où ça casse.