FDE : le métier qui met l'IA en production chez le client

Un FDE est un ingénieur qui travaille depuis l’intérieur de l’organisation cliente, sur son terrain et avec ses contraintes, pour amener un système d’IA jusqu’à un usage réel. Le sigle vient de l’anglais Forward Deployed Engineer. Ce n’est ni un consultant qui recommande, ni un prestataire qui livre un lot et repart : c’est quelqu’un qui reste jusqu’à ce que le système serve à quelqu’un.

Que fait un FDE au quotidien ?

L’essentiel de son temps ne ressemble pas à du développement. Il passe des heures à regarder des gens travailler, à noter les endroits où ils contournent l’outil officiel, à comprendre pourquoi un fichier passe par une boîte mail plutôt que par le système prévu pour ça. Cette observation n’est pas une phase préalable qu’on solde en deux semaines. Elle continue pendant toute la mission, parce que les besoins réels n’apparaissent qu’une fois que quelque chose fonctionne et que les utilisateurs commencent à s’en servir de travers.

Le reste se partage entre trois activités. Écrire du code, souvent moins qu’on ne l’imagine, et rarement le code élégant qu’on aurait écrit dans un dépôt propre. Brancher des systèmes les uns sur les autres, ce qui suppose de négocier des accès, des droits, des exports, et d’accepter que la moitié des intégrations passeront par un format que personne n’a choisi. Et expliquer, en continu, à des gens qui n’ont pas demandé ce projet et qui ont déjà un métier.

Pourquoi ce rôle apparaît maintenant

Les systèmes à base de modèles de langage ont déplacé la difficulté. Construire une première version qui impressionne est devenu rapide. La rendre utilisable par une équipe qui a ses habitudes, ses données mal rangées et ses cas particuliers reste aussi lent qu’avant. L’écart entre la démonstration et l’usage s’est creusé, et c’est exactement dans cet écart que le métier s’est installé.

Il y a une deuxième raison, moins souvent dite. Ces systèmes se comportent différemment selon les données qu’on leur donne, et personne ne peut prévoir depuis l’extérieur comment ils réagiront aux documents réels d’une entreprise. Il faut être sur place, avec les vrais fichiers, pour le découvrir. C’est une contrainte technique, pas une préférence organisationnelle. Chez AI Makers, le rôle de Forward Deployed Engineer existe pour cette raison précise.

Ce que le métier n’est pas

Ce n’est pas un rôle de support. Un FDE ne prend pas en charge les tickets d’un produit existant : il construit, et ce qu’il construit change de forme en cours de route.

Ce n’est pas non plus une mission de conseil déguisée. La différence tient au livrable. Un consultant en IA produit une analyse et une recommandation, dont la valeur ne dépend pas de leur mise en œuvre immédiate. Un FDE produit un système qui tourne, et son travail n’a aucune valeur tant que ce système ne tourne pas.

Enfin, ce n’est pas un poste pour le meilleur ingénieur disponible. La compétence technique est nécessaire mais elle n’est pas ce qui décide du résultat. Ce qui décide, c’est la tolérance à l’ambiguïté : accepter de travailler sur un problème dont l’énoncé bouge, dans une organisation qu’on ne dirige pas, avec des données qu’on n’a pas choisies.

Le rapport au produit

Un FDE occupe une position inconfortable et féconde : il est le seul à voir simultanément ce que le produit promet et ce que le terrain renvoie. Les contournements qu’il observe chez un client sont, dans presque tous les cas, des besoins que la feuille de route ignore encore.

Cette remontée n’est utile que si quelqu’un l’écoute. Une organisation qui déploie des FDE sans mécanisme pour absorber ce qu’ils rapportent obtient des projets qui réussissent un par un et un produit qui n’apprend rien. C’est le gaspillage le plus courant du modèle, et il est invisible de l’intérieur : chaque mission se passe bien, et pourtant rien ne se capitalise.

Ce qu’il faut accepter avant de créer ce rôle

Trois choses, qu’il vaut mieux regarder en face.

La première est que le travail est partiellement invisible. Les semaines les plus utiles d’une mission produisent parfois très peu de code, parce qu’elles servent à comprendre pourquoi le problème posé n’était pas le bon. Une direction qui mesure l’avancement au volume livré trouvera ce rôle décevant.

La deuxième est que la dépendance se déplace. Un FDE efficace devient rapidement la personne qui connaît le mieux le système, et cette connaissance est difficile à transférer parce qu’elle est en grande partie contextuelle. Prévoir la sortie dès le début fait partie du métier, et c’est ce qu’on oublie le plus souvent.

La troisième est qu’un FDE ne remplace pas une stratégie. Il fait exister un usage ; il ne décide pas lesquels valent la peine. Ce cadrage relève d’un autre travail, celui de la transformation IA avec AI Makers, et le confondre avec le déploiement produit des systèmes bien construits au service d’objectifs que personne n’a arbitrés.

Où ce rôle se place par rapport à l’automatisation

Beaucoup d’organisations découvrent le besoin d’un FDE en essayant de dépasser un premier projet d’automatisation. La frontière entre un agent et une automatisation classique est utile ici : tant qu’un processus est stable et prévisible, une automatisation suffit et n’exige personne sur place. Dès que le système doit interpréter des situations, la présence sur le terrain redevient nécessaire, parce que c’est le terrain qui définit ce qu’interpréter veut dire.

C’est pour cela que le rôle apparaît rarement au premier projet. Il apparaît au deuxième, quand l’organisation a compris que la difficulté n’était pas là où elle l’attendait.