Forward Deployed Engineer : le métier, pas le titre

Le terme vient des éditeurs de logiciels qui vendaient des systèmes trop spécifiques pour être installés à distance : il fallait envoyer un ingénieur chez le client, pour plusieurs mois, avec le droit d'écrire du code dans leur environnement.

Ce n'est donc pas un titre de poste inventé pour le marketing. C'est une réponse à un problème précis : certaines technologies ne se déploient pas par documentation. Elles se déploient par présence.

La différence n'est pas le niveau technique, beaucoup de consultants sont d'excellents ingénieurs. Elle tient à trois choses.

Le livrable. Un consultant remet une recommandation, et sa qualité se juge sur la pertinence de l'analyse. Un Forward Deployed Engineer remet un système en service, et sa qualité se juge sur le fait que les gens s'en servent.

Le lieu. Le travail se fait dans les systèmes du client, avec ses données réelles et ses contraintes d'accès, pas dans un environnement de démonstration reconstitué.

La fin de mission. Elle n'est pas datée par le contrat mais par une démonstration : l'équipe interne modifie le système, seule, devant l'ingénieur, avant qu'il parte.

Cette technologie a une propriété qui la rend hostile au transfert par documentation : elle échoue de façon plausible.

Un système classique qui dysfonctionne renvoie une erreur. Un système d'IA générative qui dysfonctionne renvoie une réponse bien écrite et fausse. Détecter cela demande de connaître le métier, de savoir que ce montant ne peut pas être exact, que cette procédure a été remplacée l'an dernier.

Cette connaissance ne se transmet pas dans un cahier des charges. Elle s'acquiert en étant là, en regardant les dossiers réels avec ceux qui les traitent. C'est ce qui rend le déploiement avancé pertinent ici plus qu'ailleurs.

Ce mode d'intervention n'est pas adapté à tout. Il suppose un enjeu suffisant pour justifier une présence longue, et une organisation prête à ouvrir ses systèmes.

Pour un besoin standard, couvert par un outil du marché, c'est disproportionné : il faut acheter l'outil et former les équipes. Le déploiement avancé se justifie quand le cas d'usage est spécifique, quand les données ne peuvent pas sortir, ou quand l'échec précédent a montré que la voie classique ne passait pas.

J'en parle sous l'angle économique dans ce qu'un taux journalier élevé achète réellement.

Trois livrables conditionnent la sortie : un jeu de tests, une fiche du système, et la liste datée des décisions prises. Sans eux, le départ laisse un système que personne ne peut modifier.

Le jeu de tests permet à l'équipe de changer quelque chose sans casser. La fiche décrit finalité, données, décision servie et supervision. La liste des décisions consigne quel palier pour quelle tâche, quel seuil, à quelle date, et pourquoi.

Ces trois pièces coûtent une journée sur une mission de plusieurs semaines, et elles décident si le système survit six mois. Le contenu de la transmission est détaillé dans les trois gestes qui font tenir un système.

Les décisions qui comptent, corpus, périmètre, seuils, se prennent au contact des données réelles et des utilisateurs réels, pas dans une salle de réunion. C'est ce qui rend le document de recommandations peu opérant sur ces sujets.

Un rapport peut dire qu'il faut désigner les documents faisant autorité. Il ne peut pas les désigner : cela suppose d'ouvrir le dossier partagé avec la personne qui connaît les procédures.

De même, un rapport peut recommander de définir le périmètre de refus. Le définir suppose de lire cinquante questions réelles avec le responsable métier. C'est la démarche décrite dans combien de cas d'usage faut-il abandonner.

Demander qui exécute la recommandation : si la réponse est « le client », c'est du conseil ; si c'est « moi, la semaine prochaine, dans votre dépôt », c'est autre chose. Le test est direct et il tranche.

La distinction n'est pas une question de valeur, un bon rapport a de la valeur. Elle porte sur ce qui reste après.

Un rapport laisse une intention. Un système déployé, testé et documenté laisse une capacité. La différence se mesure six mois plus tard, à l'usage réel, selon la méthode de mesurer l'adoption, pas la satisfaction.