Un nouveau rôle commence à faire parler de lui avec une fréquence croissante : le Forward Deployed Engineer, ou FDE.
Le nom peut sembler étrange au premier abord. Ce n'est pas une expression courante en français et il n'est pas né dans le monde du logiciel. Il vient d'une idée militaire : être déployé en première ligne, au plus près de là où se déroule l'opération.
Cette origine décrit précisément la position du FDE : au cœur de l'opération qu'il cherche à transformer. Il travaille avec les utilisateurs, les données, les exceptions, les systèmes hérités et les contraintes réelles ; c'est à partir de là qu'il définit le problème, conçoit la solution et la met en production.
Ce rôle me semble particulièrement pertinent pour penser la prochaine étape de l'IA en entreprise. Non pas parce que c'est une tendance de la Silicon Valley, ni parce que toutes les entreprises doivent créer une équipe avec ce nom, mais parce qu'il décrit une responsabilité que beaucoup d'organisations n'ont pas encore bien résolue : transformer une capacité technologique très puissante en une meilleure façon de travailler.
Ce que fait un Forward Deployed Engineer
Un FDE est un constructeur technique qui travaille au plus près de l'opération pour transformer des capacités avancées — aujourd'hui principalement l'IA et les agents — en workflows productifs, mesurables et adoptés par ceux qui réalisent le travail.
Ce n'est pas simplement un ingénieur qui rend visite aux clients. Ce n'est pas non plus un consultant qui observe de l'extérieur. Il combine ingénierie, produit et sens opérationnel pour mener une solution jusqu'au point où elle doit fonctionner au quotidien.
Cela implique plusieurs choses à la fois.
Premièrement, il s'immerge dans le processus réel. Il ne se contente pas de lire comment l'entreprise dit qu'elle travaille. Il observe où surgissent les exceptions, quelles validations sont informelles, quelles informations vivent en dehors des systèmes officiels, quels raccourcis utilisent les personnes et où le temps ou la qualité se perdent.
Deuxièmement, il transforme un problème ambigu en un système constructible. Pour y parvenir, il doit travailler avec les utilisateurs, les équipes techniques et les décideurs ; distinguer les symptômes des causes ; définir quel résultat compte et quelle métrique permettra de savoir s'il y a eu une amélioration.
Troisièmement, il construit et déploie. Un FDE peut concevoir une architecture, intégrer des systèmes, travailler avec des données et des permissions, définir des évaluations, instrumenter l'observabilité et corriger des défaillances en production. Il ne délègue pas la réalité opérationnelle à une phase ultérieure du projet.
Enfin, il transforme ce qu'il a appris en quelque chose de réutilisable. C'est là que réside une part importante de la valeur du rôle : le travail réalisé chez un client ou dans une unité métier ne devrait pas se terminer uniquement par une solution locale. Il devrait améliorer la base technique, les connecteurs, les évaluations, les playbooks ou la méthodologie pour le prochain déploiement.
Pourquoi on l'appelle "forward deployed"
La traduction qui fait le plus sens est ingénieur déployé sur le terrain.
On peut aussi le concevoir comme une avant-garde technique : quelqu'un qui se déploie en première ligne, comprend le terrain, construit avec de vrais utilisateurs et restitue cette expérience à un noyau technique réutilisable.
L'idée n'est pas d'être "avancé" au sens de sophistiqué. C'est d'être déployé vers l'avant. Ne pas résoudre depuis l'arrière, mais au plus près de l'opération que l'on veut transformer.
Palantir est l'entreprise la plus associée au terme. C'est elle qui a popularisé et institutionnalisé la version moderne du rôle, bien que la pratique réunisse des antécédents plus anciens : ingénierie de terrain, intégration de systèmes, services professionnels, architecture de solutions et développement de produit aux côtés du client.
Dans la logique de Palantir, il existe une distinction simple. Ils ont des Devs et des FDEs. Les Devs développent des applications communes pour de nombreux clients. Les FDEs (qu'ils appellent aussi Deltas en interne) prennent ces applications et capacités et les transforment en résultats concrets dans le contexte spécifique d'un projet ou d'un client.
L'innovation ne consiste pas à envoyer des ingénieurs configurer des logiciels. Elle consiste à faire travailler des personnes capables de construire au plus près du problème, à les responsabiliser sur un résultat opérationnel et à faire remonter les apprentissages vers le produit central.
L'écart entre un modèle et un résultat business
L'IA en entreprise présente un paradoxe. Plus un modèle est général, plus le travail contextuel nécessaire pour qu'il produise un résultat spécifique et fiable peut être important.
Un modèle peut résumer, classifier, raisonner, générer du texte, écrire du code ou utiliser des outils. Mais il ne sait pas par défaut quelle est la bonne donnée, quelle exception doit être escaladée, qui peut approuver une action, quel risque est acceptable ou comment mesurer le succès d'un processus.
Entre une capacité d'IA et un résultat business, il existe plusieurs couches que quelqu'un doit concevoir :
contexte : données, documents, connaissances et sémantique métier ;
workflow : états, décisions, exceptions, rôles et handoffs ;
intégration : systèmes, identité, permissions et APIs ;
fiabilité : évaluations, observabilité, limites et récupération ;
gouvernance : sécurité, confidentialité, audit et conformité ;
adoption : formation, redéfinition des rôles, confiance et responsabilité.
Le FDE vit à cette frontière.
Sa question n'est pas seulement de savoir si quelque chose peut être construit, mais ce qui devrait changer dans le processus pour que la technologie produise un résultat mesurable.
C'est pourquoi il ne faut pas le réduire à un simple implémenteur. Implémenter est une partie du travail. Le défi majeur consiste à découvrir ce qui vaut la peine d'être construit, ce qui peut être simplifié, à quelles décisions une personne doit rester impliquée dans le workflow et comment démontrer que le nouveau workflow fonctionne mieux que le précédent.
Ce qu'un FDE n'est pas
Les frontières entre les rôles ne sont pas parfaites. Un FDE peut réaliser du travail de découverte, d'intégration, de conception d'architecture, de formation et de gestion du changement. Mais il existe des différences importantes à prendre en compte.
Le conseil commence généralement par la question « que devrait faire l'organisation ? ». Le FDE peut participer à cette conversation, mais il assume également la responsabilité de construire, de déployer et d'apprendre du résultat.
L'implémentation commence généralement une fois que le problème et la solution sont déjà définis. Le FDE aide à définir les deux, surtout lorsque la technologie doit encore s'adapter au contexte.
Un architecte de solutions conçoit une architecture viable. Un FDE peut faire cela, mais il travaille aussi sur l'adoption, les exceptions et les décisions qui apparaissent après la première intégration.
Le développement sur mesure peut très bien résoudre un problème ponctuel. Le modèle FDE devient plus intéressant lorsque chaque déploiement laisse des actifs qui réduisent l'effort, le risque ou le temps du suivant. Si tout repart de zéro, l'organisation dispose d'un service intensif ; pas d'une capacité cumulative.
Le circuit qui transforme le déploiement en apprentissage
Le circuit est simple : un déploiement part de l'opération, génère des apprentissages, encode ces apprentissages en patterns et laisse des actifs réutilisables qui améliorent le déploiement suivant.
Cela explique pourquoi le rôle émerge dans des entreprises d'IA appliquée comme OpenAI, Anthropic, Google Cloud, Scale AI et Glean. Plus elles résolvent de problèmes dans de vraies entreprises, meilleurs sont les outils qu'elles développent pour en résoudre de nouveaux.
Les actifs réutilisables développés à chaque intervention peuvent être : un connecteur qui résout une intégration fréquente, une évaluation pour une tâche récurrente, un pattern de permissions, un playbook d'adoption, un modèle de workflow ou une décision d'architecture qui évite de répéter une erreur.
Les construire et les réutiliser est important car cela détermine si une entreprise accumule un avantage ou vend simplement des heures supplémentaires.
Le FDE ne travaille pas seul
L'image d'une personne exceptionnelle qui résout tout est séduisante, mais ce n'est pas un modèle sérieux pour des déploiements complexes. Dans de nombreux cas, le FDE fait partie d'un pod avec d'autres responsabilités : pilotage du déploiement, expertise métier, produit, sécurité et adoption.
L'important n'est pas que chaque projet porte tous ces titres. L'important est que quelqu'un réponde à chaque question critique : qui décide du périmètre, qui connaît les exceptions du processus, qui construit, qui mesure la qualité, qui prend en charge l'exploitation et qui transforme les apprentissages en actif partagé.
Ce point est particulièrement important avec les agents. Un agent n'est pas simplement une nouvelle interface. Il peut lire des informations sensibles, utiliser des outils, prendre des actions et modifier l'ordre d'un processus. Le déployer correctement exige une architecture, des limites, des évaluations, des permissions et des accords clairs sur le moment où une personne doit intervenir.
Pourquoi c'est important pour l'Amérique latine
De nombreuses entreprises de la région n'ont pas besoin de commencer par une grande « stratégie IA ». Elles ont besoin d'identifier quels processus posent problème, combien ces problèmes coûtent, quelle décision peut être assistée ou automatisée et quelles conditions techniques et organisationnelles doivent exister pour fonctionner différemment.
Parfois la réponse sera un agent. D'autres fois, un copilote. D'autres encore, une automatisation conventionnelle. Et dans certains cas, la bonne solution consistera à organiser les données, définir des responsables ou repenser une validation avant d'introduire l'IA.
La valeur qu'apporte un FDE réside dans sa capacité à comprendre le terrain et à choisir un workflow où l'intelligence apporte réellement une amélioration : moins de retravail, moins d'erreurs, de meilleurs délais de réponse, une meilleure capacité de décision ou un service plus cohérent.
Pour les entreprises qui opèrent dans des environnements réglementés, avec des processus complexes ou des systèmes qui ont évolué par couches successives, une intervention de ce type n'est pas un luxe. C'est la condition pour éviter que l'IA reste au stade de la démo.
La question qui compte
Ce qui m'enthousiasme dans le travail d'un FDE, c'est l'ordre dans lequel il aborde un problème. Avant de discuter de modèles, d'agents ou d'architecture, il doit comprendre comment le travail se fait aujourd'hui, où il se grippe, quelle décision pourrait changer et quel résultat justifierait l'effort.
Ce n'est qu'ensuite que viennent les décisions techniques : de quelle information le système a besoin, avec quels outils il doit s'intégrer, quels contrôles il requiert et comment ses performances seront évaluées.
C'est pourquoi la première question n'est pas technologique.
C'est celle-ci : quel workflow mérite d'être repensé en premier et comment saurons-nous qu'il s'est amélioré ?