Forward Deployed Engineer : apprendre à déployer une IA qui ne sera jamais parfaite

Nous aimons les systèmes prévisibles. Une action produit un résultat attendu. Si ce résultat n’arrive pas, quelque chose doit être corrigé.

L’IA générative casse cette logique. Une synthèse, une recommandation ou une image générée ne sont pas toujours justes ou fausses. Leur qualité dépend du contexte, du risque et parfois du jugement de l’utilisateur. Deux personnes peuvent évaluer différemment une même réponse.

Sur le terrain, je constate que cette réalité reste difficile à accepter. Beaucoup d’entreprises cherchent encore à savoir si une solution d’IA « fonctionne » avant de la déployer. La question utile est généralement plus exigeante : à partir de quel niveau de performance cette solution crée-t-elle assez de valeur pour être utilisée, et sous quelles conditions ?

C’est là que le Forward Deployed Engineer entre en jeu.

Au sens strict, le FDE est un ingénieur placé au plus près du client pour adapter et déployer une technologie. J’utilise ici le terme dans un sens plus large. Pour moi, le FDE porte la responsabilité du passage entre une capacité technologique et un usage réel. Il ne s’occupe donc pas seulement du modèle ou du code. Il intervient aussi sur les données, les processus, le produit, les garde-fous et l’adoption.

Ce point de vue dépasse la fiche de poste. Il vient de ce que nous rencontrons chaque jour dans les projets d’IA.

Le FDE organise l’incertitude

Le FDE ne reçoit pas simplement un cahier des charges avant de revenir quelques mois plus tard avec une application terminée. Il met rapidement une première version entre les mains des utilisateurs, observe ce qui se passe et fait évoluer le système.

Son travail n’est pas de faire disparaître le caractère probabiliste de l’IA. Il aide l’entreprise à fonctionner avec lui.

Cela oblige à répondre à des questions concrètes. Quelles erreurs peut-on tolérer ? Lesquelles sont inacceptables ? Peut-on détecter les situations dans lesquelles le système est incertain ? Quand faut-il demander une confirmation ? À quel moment un humain doit-il reprendre la main ? Combien coûte une amélioration supplémentaire, et quelle valeur apporte-t-elle réellement ?

Une erreur de reformulation dans un courriel marketing n’a pas les mêmes conséquences qu’une erreur dans une décision industrielle, juridique ou liée aux ressources humaines. Appliquer le même niveau de contrôle dans les deux cas n’aurait aucun sens.

Le FDE transforme une incertitude technique en règles opérationnelles. Il permet de sortir d’un débat abstrait sur la perfection du modèle pour décider comment employer le système dans une situation donnée.

Attendre la perfection peut bloquer un projet utile

Nous avons travaillé sur une expérience permettant à des consommateurs de photographier une pièce, de choisir un produit et de visualiser une image générée présentant ce produit dans leur environnement.

La qualité des résultats était élevée, sans pouvoir être garantie dans tous les cas. Le service étant directement exposé à des prospects, une mauvaise génération pouvait dégrader l’expérience.

Nous aurions pu attendre une fiabilité impossible à garantir. Nous avons préféré expliciter le risque. Le client a décidé d’avancer en connaissance de cause, et les images générées ont été clairement présentées comme une fonctionnalité en bêta.

La réponse n’était pas seulement technique. Elle concernait aussi la conception du service et le niveau d’attente donné à l’utilisateur.

Ce cas résume une partie importante du métier. Le FDE n’attend pas que l’incertitude disparaisse. Il aide l’entreprise à déterminer celle qu’elle accepte, puis à concevoir le produit autour de cette décision.

Un problème d’IA ne réclame pas toujours un meilleur modèle

Lorsqu’un système produit des résultats insuffisants, le premier réflexe consiste souvent à incriminer le modèle. Il faudrait une technologie plus puissante, un meilleur prompt ou une nouvelle version.

Le problème peut pourtant venir des données, du processus, de l’interface, de l’intégration au système d’information ou du niveau d’autonomie accordé à l’IA.

Un groupe souhaitait généraliser Microsoft Copilot avant de construire plusieurs agents. Au début de la mission, nous avons constaté que les collaborateurs utilisaient encore très peu OneDrive et SharePoint. Une grande partie de l’information nécessaire restait donc inaccessible aux usages envisagés.

Continuer à développer les agents aurait mécaniquement produit des résultats médiocres. Le projet a momentanément changé de nature : il fallait d’abord organiser les données et les placer dans les environnements appropriés. Le travail sur l’IA a ensuite pu reprendre sur des fondations plus solides.

Dans ce cas, le meilleur travail à accomplir sur le projet d’IA consistait à arrêter provisoirement de travailler sur l’IA.

Cette manière de raisonner demande un profil suffisamment transversal pour identifier le véritable blocage. Le FDE n’a pas besoin d’être le meilleur spécialiste de chaque discipline. Il doit en comprendre assez pour poser un diagnostic, prendre les premières décisions et savoir quand mobiliser une expertise plus pointue.

Cette lecture rejoint la grille PPDA — People, Process, Data, Algorithm (nouvelle fenêtre)— créée par Manuel Davy. Elle rappelle qu’une difficulté attribuée à l’algorithme peut en réalité venir des personnes, du processus ou des données.

Le terrain peut révéler un usage plus utile

La proximité avec les utilisateurs ne sert pas uniquement à vérifier qu’une solution fonctionne. Elle permet parfois de découvrir un usage plus pertinent que celui imaginé au départ.

Une enseigne de distribution avait développé un assistant sur son site marchand pour répondre aux questions des clients sur ses produits. Une fois l’outil disponible, un comportement inattendu est apparu : les vendeurs s’en servaient eux-mêmes pour accéder rapidement à la connaissance produit.

Cet usage n’avait pas été placé au centre du projet initial. Il répondait pourtant à un besoin réel. Le même socle a donc évolué pour devenir également un outil d’aide à la vente.

Un POC réalisé dans un environnement contrôlé aurait difficilement permis cette découverte. Il aurait démontré que l’assistant savait répondre à quelques questions préparées. La mise à disposition d’une première version dans des conditions réelles a révélé une autre valeur.

C’est pourquoi je préfère parler de MVP plutôt que de POC lorsque l’objectif est d’aboutir à un produit utilisé. Le POC cherche à établir qu’une technologie peut fonctionner. Le MVP permet d’apprendre comment elle doit s’intégrer à un métier pour produire de la valeur.

Chaque expérimentation devrait conduire à une décision : poursuivre, modifier le périmètre, ajouter un garde-fou, changer de technologie ou arrêter. Une expérimentation qui ne change aucune décision entretient seulement l’illusion du progrès.

Les fournisseurs de modèles ont légitimé le métier

OpenAI, Anthropic et d’autres entreprises qui développent les grands modèles d’IA constituent désormais des équipes de Forward Deployed Engineers. Certains y voient surtout une manière de vendre davantage de services autour de leurs technologies.

Cette lecture n’est pas absurde. Un fournisseur a naturellement intérêt à favoriser l’adoption de son produit. J’en tire néanmoins une conclusion positive : en investissant dans cette fonction, ces entreprises reconnaissent publiquement que la performance d’un modèle ne suffit pas. Elles ont donné un nom et une visibilité à une difficulté que nous rencontrons quotidiennement.

Même avec un excellent modèle, une entreprise doit encore l’intégrer à ses données, à ses outils et à ses processus. Elle doit définir des garde-fous, accompagner les utilisateurs et observer ce qui se passe réellement en production.

Ces fournisseurs connaissent leurs technologies avec une profondeur qu’un acteur indépendant ne prétendra pas égaler. Leur FDE est particulièrement pertinent lorsqu’une entreprise a déjà choisi un environnement technologique et souhaite en exploiter toutes les possibilités.

La limite tient à leur point de départ. Un fournisseur regarde légitimement le problème depuis son produit. Il cherchera d’abord comment employer son modèle. Un FDE indépendant doit pouvoir poser une question en amont : ce modèle est-il réellement la bonne réponse, et faut-il nécessairement utiliser un grand modèle de langage ?

Pourquoi aiko défend un FDE indépendant

aiko est un cabinet spécialisé dans le conseil et la mise en œuvre de projets d’intelligence artificielle. Nous ne développons pas notre propre modèle et nous n’avons donc pas de technologie particulière à imposer.

Notre travail doit commencer par le problème métier, le processus existant et le niveau de risque acceptable. Selon le contexte, la réponse peut être un modèle proposé par OpenAI, Anthropic ou Mistral, un modèle open source, un système plus petit ou une approche qui ne repose pas sur un grand modèle de langage.

Cette indépendance n’a d’intérêt que si elle influence les décisions du projet. Elle doit permettre de suspendre un développement pour traiter les données, de maintenir une étape humaine, de réduire le périmètre d’automatisation ou de reconnaître que l’usage imaginé au départ n’est pas le bon.

Le fournisseur connaît parfaitement son produit. Le FDE indépendant doit suffisamment bien connaître l’entreprise pour déterminer comment l’utiliser et, parfois, s’il faut l’utiliser.

À mesure que les modèles progressent, cette capacité de jugement devient plus importante. La différence ne se fera pas seulement entre les organisations qui ont accès à l’IA et les autres. Elle se fera entre celles qui attendent de l’IA qu’elle soit toujours prévisible et celles qui apprennent à construire des systèmes utiles malgré l’incertitude.

C’est, à mes yeux, la fonction essentielle du Forward Deployed Engineer.

Pour approfondir la manière dont les personnes, les processus, les données et les algorithmes conditionnent la réussite d’un projet d’IA, découvrez la grille PPDA (nouvelle fenêtre).