Quand faire appel à un FDE dans un projet IA

Faire appel à un FDE devient justifié quand le blocage a cessé d’être technique et qu’il est devenu contextuel : les données réelles ne ressemblent pas aux données d’essai, les utilisateurs contournent l’outil, et personne à distance ne sait pourquoi. Tant que le problème se pose et se résout depuis un dépôt de code, ce rôle coûte plus qu’il ne rapporte.

Les trois situations qui le justifient

La première est l’écart entre la démonstration et l’usage. Un premier système fonctionne en réunion et se dégrade dès qu’il rencontre les documents réels. Le diagnostic ne se fait pas à distance, parce que ce qui casse tient à des détails que personne ne pense à transmettre : un modèle de fichier abandonné mais toujours en circulation, une règle non écrite, un champ rempli différemment selon les services.

La deuxième est l’intégration à des systèmes que l’on ne contrôle pas. Dès que le projet dépend d’accès, d’exports ou d’outils internes dont les propriétaires sont dispersés, l’essentiel du travail devient organisationnel. Il faut quelqu’un sur place pour trouver les bons interlocuteurs et négocier, ce qu’aucun cahier des charges ne peut anticiper.

La troisième est l’usage qui ne décolle pas alors que la technique tient. Le système fonctionne, il est disponible, et les équipes continuent de faire autrement. C’est le signal le plus clair, et le plus souvent mal interprété : on l’attribue à la conduite du changement alors qu’il révèle presque toujours un décalage entre ce que le système fait et ce dont le travail a besoin.

Les cas où ce n’est pas nécessaire

Il faut le dire aussi nettement, parce que ce rôle est coûteux et long.

Quand le processus visé est stable et prévisible, une automatisation classique suffit et n’exige personne sur place. La distinction entre un agent et une automatisation est utile ici : si les règles peuvent s’écrire à l’avance, elles n’ont pas besoin d’être découvertes sur le terrain.

Quand la question ouverte est encore « quoi faire », le déploiement est prématuré. Une organisation qui hésite entre plusieurs chantiers a besoin d’un cadrage avant d’avoir besoin d’un ingénieur. Envoyer quelqu’un construire à ce moment produit un objet correct au service d’un objectif que personne n’a arbitré.

Quand le projet n’a pas de propriétaire interne. Sans personne pour arbitrer et pour reprendre le système, une mission de terrain produit une dépendance plutôt qu’une capacité. Mieux vaut régler ce point d’abord, même si cela retarde le début.

Quand l’organisation veut un budget fermé et un périmètre stable. C’est une demande légitime, mais elle décrit une prestation de réalisation, pas ce métier. Le déguiser en mission de terrain garantit une renégociation tendue au troisième mois.

À quel moment du projet l’introduire ?

Rarement au début, presque jamais au premier projet. Le moment habituel est le deuxième, quand une organisation a déjà produit une première version et découvert que la difficulté n’était pas là où elle l’attendait.

Trop tôt, l’ingénieur attend des décisions et s’occupe en construisant des choses dont l’utilité n’est pas établie. Trop tard, il hérite d’un système déjà en production, avec des usages installés et des contournements devenus des habitudes, ce qui rend chaque correction plus coûteuse qu’elle ne l’aurait été.

Le bon indicateur n’est pas l’avancement technique mais la nature des questions ouvertes. Tant qu’elles portent sur le choix des outils, il est trop tôt. Quand elles portent sur le comportement du système face à des cas réels, le moment est venu. Ce basculement est le même que celui qui rend utile un audit du potentiel d’automatisation : on cesse de raisonner sur des capacités générales pour raisonner sur une situation particulière.

Ce qu’il faut préparer avant

Quatre éléments, qui déterminent en grande partie le résultat.

Un accès réel aux données réelles, pas un échantillon reconstitué. C’est la condition la plus souvent négligée et celle qui bloque le plus de missions dans les premières semaines.

Un interlocuteur qui arbitre, disponible et légitime. Pas un comité mensuel : quelqu’un qui peut trancher dans la semaine.

Une personne interne désignée pour reprendre, impliquée dès le début. Sa présence change la manière de construire, et son absence produit un système que personne ne saura faire évoluer.

Une définition écrite de ce qui n’entre pas dans le périmètre. L’élargissement se fait toujours par petites demandes raisonnables, et seule une liste d’exclusions permet de le refuser sans conflit.

Le calcul honnête

La question n’est pas de savoir si le rôle apporte de la valeur, mais s’il en apporte plus que l’alternative. Pour un processus stable, l’alternative est une automatisation, moins chère et suffisante. Pour un chantier mal cadré, l’alternative est un travail de cadrage. Pour une organisation qui déploiera plusieurs systèmes de ce type, l’alternative est d’internaliser la compétence, et l’intervention d’un Forward Deployed Engineer se justifie alors surtout par ce qu’elle transmet.

Reste le cas où il n’y a pas d’alternative : un système qui doit interpréter des situations que personne n’a su décrire à l’avance. C’est là que le rôle est irremplaçable, et c’est aussi là qu’une organisation gagne à l’inscrire dans un cadre plus large de transformation IA avec AI Makers plutôt que de le traiter comme un renfort ponctuel.