Un même intitulé de poste apparaît en ce moment chez les acteurs les plus visibles de l'IA. Ils déploient des ingénieurs au plus près du client, au contact de son terrain plutôt qu'à l'écart de son contexte.
Le mot venu de l'anglais est « forward deployed engineer ». Derrière l'étiquette se joue un mouvement plus profond. Ce métier ne réapparaît pas par hasard : il signale un déplacement de la valeur logicielle.
Un rôle qui réapparaît chez les géants de l'IA
Plusieurs acteurs majeurs de l'IA mettent en avant le même profil. Palantir en a fait une marque de fabrique. OpenAI, AWS et Microsoft ont suivi, chacun à sa manière.
L'idée tient en une phrase. Un ingénieur logiciel expérimenté travaille directement avec les équipes du client, dans son environnement réel, pour transformer un problème métier en outil qui fonctionne.
Il ne conseille pas à distance. Il ne code pas dans une bulle. Il construit au contact du terrain : les métiers, les utilisateurs, les données, les systèmes déjà en place et les contraintes de sécurité.
Quand le développement logiciel s'est éloigné du métier
Pour comprendre ce retour, il faut regarder d'où l'on vient. Pendant deux décennies, la production logicielle s'est organisée en usine, à l'écart des usages réels.
La logique était industrielle, et elle avait ses raisons. On spécifiait tout dans un cahier des charges, puis on confiait la réalisation à une équipe qui ne voyait ni le métier, ni les utilisateurs.
Le code coûtait cher à produire. Le réflexe rationnel était de le fabriquer au meilleur coût, à grande échelle. La distance qui comptait n'était pas géographique, c'était l'éloignement du réel.
Ce que l'IA déplace vraiment
L'IA générative a changé une donnée simple mais décisive. Écrire du code n'est plus le point le plus difficile. Une bonne partie se génère, s'assemble et se corrige vite.
La rareté a changé de camp. Ce qui reste difficile, c'est de comprendre un problème métier réel, puis de l'intégrer dans un environnement qui n'a rien d'idéal.
Là se trouve le vrai travail : des données dispersées, un système d'information vivant, des règles de sécurité, des utilisateurs avec leurs habitudes. Une démonstration n'est pas un système de production.
Ce constat déplace l'ingénieur. Si la valeur se joue dans le réel du client, c'est là qu'il doit se tenir. Le mouvement s'inverse, non par nostalgie, mais par nécessité.
Au plus près du client : ce que cela exige
Travailler au plus près du client n'est pas une affaire de kilomètres. On peut être à distance et rester en prise directe avec son réel, à condition de poser les bonnes questions et de parler aux bonnes personnes.
C'est d'abord une manière de mener le projet, par cycles courts, au plus près de la décision.
On part d'une intuition, on la cadre, on obtient vite un résultat concret, on l'évalue, on ajuste. L'outil se précise à mesure qu'on le voit fonctionner, sans long détour théorique.
Cette proximité impose une montée par étapes. On clarifie d'abord le besoin réel. On teste ensuite une première version sur un périmètre maîtrisé. On durcit enfin ce qui mérite de tenir en production.
Chaque étape tranche une question : faut-il continuer, corriger ou renoncer ? Le terrain rend cette décision possible, parce qu'elle se prend sur du concret, pas sur une promesse.
Un ingénieur hors-sol n'est pas un ingénieur de terrain
Le rôle se comprend mieux par ce qu'il n'est pas. Ce n'est pas un preneur d'ordres qui exécute un cahier des charges figé, sans jamais interroger le contexte.
Ce n'est pas non plus un consultant qui s'arrête aux recommandations, ni un développeur isolé qui accepte du code généré sans le maîtriser.
Le fil commun de ces postures n'est pas la distance physique, c'est le détachement du réel. On peut rester hors-sol dans les mêmes bureaux que le client, ou très proche à l'autre bout d'un fil.
L'ingénieur de terrain, lui, reste responsable de la cohérence d'ensemble : le besoin, l'architecture, le code, la sécurité, l'adoption et le passage en production. Il compose avec la complexité réelle au lieu de l'ignorer.
Ce qu'un décideur peut en déduire
Pour un dirigeant, ce mouvement offre un critère de choix utile. La bonne question n'est plus seulement « cette équipe sait-elle produire », mais « sait-elle travailler dans mon réel ».
Un partenaire proche du terrain se juge à des signes concrets. Il comprend votre métier, il compose avec vos systèmes, il rend les risques visibles tôt et il vous fait décider sur des résultats tangibles.
Un dernier point compte, souvent négligé. Un bon travail de terrain renforce votre maîtrise au lieu de créer une dépendance. Code livré, choix expliqués, savoir-faire transmis : vous devez pouvoir reprendre la main.
Le retour de l'ingénieur au plus près du client n'est donc ni une mode, ni un simple anglicisme. C'est le signe que la valeur a changé de place.
Elle ne réside plus dans la capacité à produire du code, devenue abondante. Elle réside dans celle de transformer un problème en système qui tient, chez vous, dans la durée.
Avant de choisir qui vous accompagne, regardez donc moins la vitesse affichée que la vraie proximité : celle du métier et des usages, pas celle de la carte. C'est souvent là que se décide la suite.