Pourquoi le forward deployed engineer revient avec l'IA générative

D'où vient ce métier

Le forward deployed engineer est apparu chez des éditeurs de logiciels d'analyse de données. Leur produit était puissant et générique. En face, les clients avaient des données sales, des règles internes que personne n'avait écrites, et des utilisateurs qui n'avaient pas le temps d'apprendre un outil de plus. Entre les deux, il manquait quelqu'un. Ni un consultant qui rédige des recommandations, ni un avant-vente qui fait une démonstration. Un ingénieur qui s'installe chez le client, ouvre les vraies données et écrit le code qui relie le produit au métier.

Ce profil a toujours existé dans les organisations qui livrent du logiciel utile. Il est simplement redevenu visible, parce que la même configuration se reproduit à grande échelle avec l'IA générative. Un modèle de langage est un produit générique, disponible pour tout le monde au même tarif public. Il ne sait rien de votre nomenclature, de vos conditions tarifaires, de vos cas particuliers, de la personne à qui il faut passer le dossier quand il sort du cadre. Anthropic, qui édite les modèles Claude, recrute lui même ce profil sous le titre de forward deployed engineer, y compris à Paris, comme le montre sa page carrière. Ce savoir existe chez vous. Il n'est presque jamais écrit. Le travail consiste à aller le chercher là où il se trouve.

La valeur n'est pas dans le modèle, elle est dans le raccordement

On compare souvent les modèles entre eux. C'est une question secondaire pour une direction générale. Les modèles progressent vite, ils se remplacent, et un agent bien construit doit pouvoir changer de moteur sans être réécrit. Ce qui fait la différence entre un agent qu'on retire au bout d'un mois et un agent qui reste, c'est le raccordement au métier. Ce raccordement comporte quatre couches, et aucune ne s'achète.

La première, c'est le corpus. Quels documents font foi, lesquels sont périmés, lequel gagne quand deux se contredisent. Dans la plupart des organisations, personne n'a jamais eu à trancher cette question par écrit, parce que les humains savaient d'instinct quelle version regarder.

La deuxième, c'est le vocabulaire. Le même mot désigne deux choses selon le service. Une commande n'a pas le même sens aux achats et à la comptabilité. Un dossier ouvert ne veut pas dire la même chose au support et au juridique. Un modèle qui ignore ces écarts produit des réponses plausibles et fausses.

La troisième, ce sont les règles. Les conditions d'application d'une remise, les seuils de validation, ce qui est possible et ce qui ne l'est pas. Elles sont souvent réparties entre un tableur, un ERP et la tête de deux personnes.

La quatrième, ce sont les cas limites. C'est là que se joue la crédibilité de l'outil. Les utilisateurs jugent un agent sur les dossiers compliqués, pas sur les dossiers simples qu'ils traitaient déjà sans difficulté.

Aucune de ces quatre couches ne se collecte par un cahier des charges. On peut demander à un responsable métier de décrire son processus. Il décrira la version officielle. La version réelle apparaît quand on regarde par dessus son épaule pendant qu'il traite un dossier tordu, et qu'on lui demande pourquoi il vient de faire ce geste. C'est exactement ce que fait un ingénieur en immersion. Sur ce point, le passage d'une idée à un outil qui tient en production suit les mêmes règles que pour n'importe quel logiciel métier, et nous les avons détaillées dans les prérequis d'un passage en production.

Le cycle de construction a changé

Pendant vingt ans, la méthode dominante a consisté à spécifier, valider, développer, recetter. Elle fonctionne quand le comportement du système est prévisible sur le papier. Avec un composant probabiliste, elle ne fonctionne plus. Vous ne pouvez pas écrire à l'avance ce que le modèle répondra sur vos documents, parce que la réponse dépend de vos documents. Vous ne pouvez pas non plus estimer sérieusement la qualité tant que vous n'avez pas essayé sur les vraies données.

Le cycle devient donc : on branche sur un échantillon réel, on observe ce qui sort, on mesure, on corrige, on recommence. Chaque tour dure des heures, pas des semaines. Ce rythme a une conséquence d'organisation que beaucoup de directions sous-estiment. Si la personne qui code et la personne qui connaît le métier ne sont pas dans la même pièce, chaque tour de boucle coûte une réunion, un compte rendu et deux jours d'attente. La boucle meurt.

C'est la raison structurelle du retour de ce profil. Le forward deployed engineer n'est pas un développeur plus sympathique. C'est quelqu'un qui peut tenir les deux bouts : lire une règle de gestion avec un responsable, puis la traduire en code dans l'après-midi et montrer le résultat le lendemain matin. Ce format, nous le décrivons dans notre offre d'ingénieur en immersion, et il se décline par fonction, du contrôle de gestion aux opérations commerciales.

Un agent se juge sur des cas réels, pas sur une démonstration

La démonstration d'un agent est toujours réussie. On choisit les questions, on connaît les réponses, l'outil impressionne. Ce moment ne prouve rien. La seule chose qui prouve quelque chose, c'est un jeu d'évaluation : une liste de cas réels, tirés de vos dossiers, avec pour chacun la réponse attendue validée par quelqu'un qui fait le métier.

Constituer ce jeu est un travail de terrain, et c'est souvent l'étape que les projets sautent. Il faut s'asseoir avec les utilisateurs, récupérer des dossiers récents, y compris ceux qui se sont mal passés, et écrire ce qu'une bonne réponse aurait été. Il faut y mettre les cas ennuyeux : la pièce jointe illisible, la demande qui mélange deux sujets, le client qui pose une question hors périmètre, la donnée absente. Il faut aussi y mettre les cas piégeux, ceux où la bonne réponse est de ne pas répondre et de transmettre à un humain.

Une fois ce jeu constitué, tout change dans la conduite du projet. Vous cessez de discuter d'impressions. Vous pouvez comparer deux versions de l'agent, décider si un changement améliore ou dégrade, et surtout arbitrer le moment de la mise en service sur autre chose que l'enthousiasme d'une réunion de démonstration. Ce jeu devient un actif de l'entreprise, indépendant du modèle utilisé. Il survit au changement de fournisseur.

Il rend aussi la discussion budgétaire saine, parce qu'il permet de relier la qualité obtenue au coût d'exploitation réel, sujet que nous traitons dans ce qu'un agent coûte en production.

Les garde-fous sont des décisions métier

Un agent qui se trompe sur une reformulation, c'est un désagrément. Un agent qui annonce une disponibilité fausse, un prix qui n'existe plus ou une référence client qui n'a jamais donné son accord, c'est un engagement de l'entreprise. La différence n'est pas technique, elle est juridique et commerciale. Elle doit donc être tranchée par le métier, pas par l'ingénieur seul, et encore moins par le fournisseur du modèle.

Chez nous, la règle est simple et elle ne se négocie pas. Ce qui engage l'entreprise ne sort jamais du modèle. Un prix vient du système qui détient les prix. Une disponibilité vient du stock. Une adresse vient du référentiel. Le modèle sait rédiger la phrase autour, il ne produit pas la donnée. Le calcul se fait côté serveur, la valeur est vérifiée avant affichage, et si elle n'est pas disponible, l'agent le dit au lieu d'improviser.

La deuxième question est celle de la validation humaine. Quelles actions l'agent peut-il exécuter seul, lesquelles doivent passer devant quelqu'un. Envoyer un devis, clôturer un ticket, modifier une fiche, déclencher une commande : chacune de ces actions mérite une réponse explicite, écrite, avec un nom en face. Un ingénieur seul ne peut pas trancher cela. Un comité qui n'a jamais vu l'outil fonctionner non plus. Il faut les deux, au même endroit, devant les mêmes cas concrets. Le cadre réglementaire pèse aussi dans la balance, et nous en avons fait un point de passage obligé sur notre approche de l'IA responsable.

Ce qu'il faut écrire avant la mise en service

• La liste des données que l'agent n'a pas le droit de produire lui-même.
• Les actions autorisées sans validation, et celles qui exigent un accord humain.
• Le comportement attendu quand l'information manque.
• Le chemin de transmission vers un humain, avec la personne réellement destinataire.
• Qui regarde les échanges de la semaine, et à quelle fréquence.

L'adoption est la moitié du sujet

Un agent que personne n'ouvre n'a rien résolu. C'est la fin la plus fréquente des projets IA en entreprise, et elle est rarement causée par la qualité technique. Elle est causée par le fait que l'outil est arrivé à côté du travail réel.

Les signes se repèrent tôt. L'agent vit dans une application séparée que les utilisateurs doivent penser à ouvrir. Il répond bien mais lentement, et le geste manuel reste plus rapide. Il n'affiche pas d'où vient sa réponse, donc l'utilisateur revérifie tout et perd le bénéfice. Il a été annoncé comme un gain de productivité, ce que les équipes traduisent immédiatement par une menace.

Là encore, la réponse se trouve sur le terrain. On place l'agent dans l'outil que les gens utilisent déjà. On montre les sources pour que la vérification prenne quelques secondes. On commence par la tâche que tout le monde déteste, pas par celle qui fait la plus belle démonstration. On désigne deux ou trois utilisateurs qui testent en vrai pendant les premières semaines et dont les remarques sont traitées vite, parce qu'un retour ignoré éteint définitivement l'envie de tester. Cette montée en compétence collective compte autant que le code, et nous y consacrons une méthode dédiée.

Ce que l'IA change dans le travail de l'ingénieur lui-même

Le métier a aussi changé de l'intérieur. Écrire une première version fonctionnelle prend beaucoup moins de temps qu'avant. Un ingénieur peut arriver le matin avec une règle de gestion décrite à l'oral et montrer quelque chose qui tourne l'après-midi. C'est un progrès réel, à condition de comprendre ce qu'on fait du temps ainsi libéré.

Bien utilisé, ce temps va à l'observation et à la mesure. Regarder travailler les utilisateurs. Élargir le jeu d'évaluation. Chercher les cas où l'outil échoue silencieusement, ce qui est la panne la plus dangereuse d'un agent : une réponse fausse formulée avec assurance. Ce travail n'a pas d'équivalent automatisable, parce qu'il consiste précisément à confronter la machine au réel.

Mal utilisé, ce temps produit un risque nouveau et assez répandu. Comme construire coûte peu, on construit avant d'avoir compris. On livre en trois jours un outil que personne n'a demandé, propre, rapide, inutile. La facilité de production déplace le goulot d'étranglement : il n'est plus dans le développement, il est dans le discernement. La question à poser avant d'ouvrir l'éditeur reste la même qu'avant, elle est juste devenue plus facile à sauter. Quel est le problème, qui le vit, et comment saurons nous qu'il est réglé. C'est la logique que nous appliquons dans notre méthode agent IA.

Les signaux qui montrent que vous avez besoin de ce profil

Quelques situations reviennent souvent, et elles se reconnaissent sans audit.

• Vous avez testé un assistant sur vos documents, la démonstration était bonne, et six mois plus tard personne ne l'utilise.
• Vos équipes passent un temps important à chercher une information qui existe déjà, dans un endroit que tout le monde connaît mal.
• Un prestataire vous a demandé un cahier des charges complet pour un projet IA, et vous n'arrivez pas à l'écrire parce que vous ne savez pas encore ce qui est faisable.
• Le savoir critique d'un processus repose sur une ou deux personnes qui partent bientôt.
• Vous hésitez entre un outil du marché et un développement spécifique, sans élément objectif pour trancher.

Dans ces cas, ce qui manque est rarement un modèle plus performant. C'est quelqu'un qui vient voir, qui code, qui mesure et qui reste assez longtemps pour que l'outil entre dans les habitudes. Le déroulé complet d'une mise en service est décrit dans notre article sur le déploiement d'un agent en entreprise.

Si vous voulez d'abord comprendre le rôle avant d'envisager une mission, commencez par notre page pilier, le forward deployed engineer expliqué simplement. Si vous avez déjà un sujet identifié et que vous cherchez à savoir s'il tient debout, le diagnostic IA sert exactement à cela : regarder vos données, vos processus et vos contraintes, puis vous dire ce qui est faisable et ce qui ne l'est pas.

Sources

• Anthropic, postes ouverts (Forward Deployed Engineer, Paris)

Questions fréquentes

Faut-il un forward deployed engineer, ou une équipe IA interne suffit-elle ?

Les deux se complètent. Une équipe interne connaît le métier et reste après le projet. L'ingénieur en immersion apporte l'expérience des pièges déjà rencontrés ailleurs et accélère les premiers mois. Le bon signe d'une mission réussie, c'est que l'équipe interne puisse reprendre l'outil sans nous.

Peut-on commencer sans cahier des charges ?

Oui, et c'est souvent préférable sur un sujet IA. Ce qu'il faut au départ, c'est un problème précis, des données réelles accessibles et une personne du métier disponible. Le cahier des charges se construit en avançant, à partir de ce qu'on observe sur vos dossiers.

Comment savoir si un agent est assez fiable pour être mis en service ?

En le confrontant à un jeu de cas réels tirés de vos dossiers, avec la réponse attendue validée par le métier. Vous décidez ensuite du seuil acceptable selon l'enjeu, et vous encadrez le reste par une validation humaine. Une impression de réunion ne suffit jamais.

Nos données sont mal rangées. Faut-il les nettoyer avant de lancer un projet IA ?

Pas entièrement, sinon vous ne démarrez jamais. On travaille sur le périmètre nécessaire au premier usage, et le passage sur les données réelles révèle rapidement quels défauts gênent vraiment. Le nettoyage devient ciblé au lieu d'être un chantier préalable sans fin.

Que se passe-t-il quand le modèle utilisé devient obsolète ?

Un agent bien construit sépare le moteur du reste : connecteurs, règles métier, garde-fous et jeu d'évaluation restent votre propriété. Changer de modèle revient alors à rejouer le jeu d'évaluation et à comparer. C'est précisément pour cela que ce jeu est un actif à constituer tôt.