Comment travaille un forward deployed engineer : le déroulé d'une mission

Le premier jour : s'asseoir à côté de ceux qui font le travail

Une mission forward deployed ne commence pas par un atelier de cadrage en salle. Elle commence à côté d'une personne qui fait son travail. L'ingénieur arrive, s'installe, et regarde. Il ne demande pas comment le processus est censé se dérouler. Il regarde comment il se déroule vraiment, un mardi ordinaire, avec les interruptions, les exceptions et les contournements que personne n'a jamais écrits nulle part.

Ce premier jour a une règle : l'ingénieur ne propose rien. Ses questions servent à comprendre, pas à placer une idée. Pourquoi ce fichier est ouvert en permanence. Pourquoi cette colonne est remplie à la main alors que la valeur existe ailleurs. Qui appelle qui quand le dossier bloque. Ce que la personne fait quand l'application officielle ne prévoit pas le cas.

La raison est pratique. Le processus décrit dans une note de service est une intention. Le travail réel est un enchaînement de gestes, dont une bonne partie existe parce que la note ne tient pas. Ce sont eux qui coûtent du temps, et ce sont eux qu'on peut outiller. Un logiciel conçu à partir de la note ne sait pas traiter les cas qui occupent la moitié de la journée.

Côté client, ce premier jour demande une chose : que quelqu'un accepte d'être observé sans se sentir audité. L'ingénieur n'évalue pas les personnes, il cherche à comprendre le travail. Quand cette phrase est dite par le responsable devant son équipe, le reste de la mission est plus simple.

La cartographie : les gestes, les outils, ce qui se recopie

À partir de ces observations, l'ingénieur construit une carte. Pas un schéma d'architecture : une carte du travail, lisible par un responsable métier, qui répond à quatre questions.

• Quels gestes composent réellement la journée : ouvrir un message, extraire une pièce jointe, contrôler un montant, relancer un fournisseur, produire un récapitulatif.
• Quels outils portent ces gestes : l'ERP, la messagerie, un ou plusieurs tableurs, un dossier partagé, parfois un carnet.
• Ce qui se recopie d'un endroit à l'autre. Signal le plus fort de la carte : chaque recopie prouve que deux systèmes ne se parlent pas, et ouvre un endroit où une erreur entre sans être vue.
• Où le travail attend : une validation, une réponse, un export mensuel, une personne en congé qui est la seule à savoir faire.

Cette carte se corrige en la montrant. L'ingénieur la relit avec les utilisateurs, ligne par ligne. Presque toujours, quelqu'un dit « ça, on ne le fait plus » ou « il manque l'étape du vendredi ». C'est le but : une cartographie validée par ceux qui font le travail est un objet de décision ; produite en chambre, c'est une opinion.

La carte fait aussi apparaître l'état réel des données : champs libres là où il faudrait une liste, doublons, identifiants qui ne correspondent pas d'un outil à l'autre. Ce constat se pose maintenant, pas à la mise en production, parce qu'il change ce qui est faisable. Ce travail relève autant de la donnée et de l'intégration que du développement.

Choisir le premier chantier, et dire ce qu'on écarte

La cartographie produit une liste d'irritants, toujours plus longue qu'une mission ne peut traiter. Le premier chantier se choisit sur des critères explicites, posés devant le client :

• La fréquence. Un geste fait tous les jours par plusieurs personnes vaut mieux qu'une opération annuelle, même lourde.
• Le temps passé. Pas le temps supposé : le temps relevé pendant l'observation, avec les utilisateurs.
• Le risque d'erreur. Une recopie manuelle sur un montant ou une date d'échéance : l'erreur y reste invisible jusqu'au jour où elle coûte cher.
• La réversibilité. On commence là où l'on peut revenir en arrière sans dommage, pas au cœur de la facturation.
• L'existence d'un porteur. S'il n'y a personne côté métier pour dire « oui, c'est bien ça » chaque semaine, on ne commence pas là.

Le geste le plus important n'est pas de choisir, c'est d'écarter à voix haute. L'ingénieur dit ce qu'il ne traitera pas, et pourquoi : trop rare, données pas prêtes, dépendance à un chantier en cours, gain qui ne justifie pas la complexité. Cette liste d'exclusions est écrite et partagée : elle protège tout le monde quand la question reviendra.

Le choix se formule en termes de travail, jamais de technologie. On ne décide pas « on fait un agent », on décide « le rapprochement des pièces doit cesser d'occuper les matinées du service ». Le choix entre une automatisation de flux, un agent ou une application vient après, et peut changer en route.

Le premier livrable utile, entre les mains d'une ou deux personnes

Le premier livrable n'est pas une démonstration. C'est un outil qui fait vraiment le travail, sur les vraies données, mis entre les mains d'une ou deux personnes volontaires. Il est volontairement étroit : il traite un cas, bien, et il dit clairement quand il ne sait pas traiter.

Ce point est une règle de conception. Un outil qui produit une réponse plausible quand il n'a pas l'information est plus dangereux qu'un outil qui s'arrête. Chez nous, ce qui engage l'entreprise, un prix, une disponibilité, une référence, une adresse, est calculé côté serveur à partir de la source et vérifié avant affichage. Le modèle ne l'invente jamais.

Le choix des volontaires compte autant que le code : des personnes qui font le geste tous les jours, assez expérimentées pour repérer une anomalie, assez franches pour dire que l'outil les ralentit. Un utilisateur poli qui n'ose pas critiquer fait perdre plus de temps qu'un opposant déclaré. Le chemin manuel reste ouvert : personne ne doit être bloqué par un défaut du nouvel outil.

Ce livrable n'est pas encore en production. Il tourne sur les vraies données, avec de vrais utilisateurs, sans être le passage obligé du service. La différence entre ce stade et la production est détaillée dans les prérequis d'un passage en production.

La boucle : usage réel, retours, correction, extension

Vient ensuite la partie qui fait la différence et se voit le moins sur un planning. L'ingénieur reste sur place pendant que l'outil est utilisé. Il regarde les cas qui sortent du cadre, il corrige, il repasse. Un point bref et régulier, une correction visible entre deux points.

Trois choses remontent dans cette boucle, à distinguer :

• Les défauts. L'outil se trompe ou plante sur un cas. Correction immédiate, sans discussion.
• Les manques. Un cas réel n'est pas couvert. On l'ajoute maintenant, plus tard, ou on le laisse en manuel. Décision du client.
• Les demandes d'extension. « Puisque l'outil fait ça, il pourrait aussi… ». Bon signe, et principal danger d'une mission. Elles vont dans une liste, pas dans le chantier en cours.

L'extension à l'équipe n'arrive qu'après une période où les volontaires utilisent l'outil sans se plaindre et sans revenir au chemin manuel. Ce signal est plus fiable qu'un test de recette. Et ce ne sont pas les ingénieurs qui forment l'équipe : ce sont les volontaires, qui parlent le langage du métier et ont vécu les défauts. C'est là que la conduite du changement se joue, bien plus que dans une note de direction.

Ce que le client décide, et à quel moment

Une mission bien menée ne demande pas au client de décider tout le temps. Elle lui demande de décider à des moments précis, avec de quoi trancher. Ces points sont posés dès le début :

• Après la cartographie : valider que la carte décrit bien le travail, et arbitrer le premier chantier.
• Avant le premier livrable : accepter le périmètre exact et la liste écrite de ce qui est exclu.
• Au moment de l'extension : décider qu'on sort du cercle des volontaires, et ce qu'on fait du chemin manuel.
• Au passage en production : accepter que l'outil devienne le chemin officiel, avec le support et la responsabilité associés.
• À la passation : nommer le référent interne, et décider de la suite, arrêt, maintenance ou chantier suivant.

Entre ces points, l'ingénieur avance sans faire remonter chaque micro-arbitrage. C'est le sens du modèle : le client décide de ce qui l'engage, pas de la couleur d'un bouton. Cet accompagnement est décrit sur la page FDE as a service.

Ce que demande le client, concrètement

Autant le dire : ce modèle demande du travail côté client. Une mission où l'entreprise attend simplement un livrable ne marche pas. Trois engagements sont nécessaires.

Du temps d'équipe, pas seulement du temps de réunion

Des utilisateurs doivent être observés pendant qu'ils travaillent, puis tester, puis dire ce qui ne va pas. Ce temps est réel, il se prend sur la production courante et se concentre sur quelques personnes. Le plus coûteux n'est pas l'observation, c'est la boucle : quelqu'un doit répondre aux questions de l'ingénieur dans la journée, pas la semaine suivante. Un responsable qui protège ce temps dans les plannings vaut plus qu'un comité de pilotage.

Des accès, ouverts tôt

Un accès en lecture à l'outil métier, un jeu de données réelles ou anonymisées, un environnement où déployer, les droits nécessaires. C'est le premier sujet à lancer : il dépend le moins de nous et bloque le plus souvent. Un accès demandé le premier jour et obtenu bien plus tard, c'est une partie de la mission passée à attendre. Le sujet se traite avec la DSI et la conformité dès le cadrage : hébergement, localisation des données, traçabilité, conservation. Nous travaillons avec un hébergement en France et des données en Europe, ce qui simplifie cette discussion sans la remplacer.

Une personne nommée, côté métier

Pas un sponsor lointain : quelqu'un qui connaît le travail, disponible chaque semaine, autorisé à trancher sur le périmètre. Son rôle est de dire « oui, c'est bien ça », « non, ce cas n'existe pas », « celui-là on le garde manuel ». Sans cette personne, l'ingénieur arbitre à sa place, et il arbitre mal. C'est la condition la plus souvent sous-estimée.

La mesure : relever avant, relever après

On ne promet pas de chiffre de gain au démarrage : personne ne sait ce que donnera un outil qui n'existe pas encore, et un pourcentage annoncé d'avance devient un objectif à défendre plutôt qu'une mesure à observer.

En revanche, on relève un état avant. Pendant la cartographie, on note avec les utilisateurs le nombre de dossiers traités sur une période, le temps qu'ils déclarent y passer, les reprises et corrections, le délai entre une demande et sa réponse, et les moments où le travail attend. Ces relevés sont déclaratifs et imparfaits, et on le dit. Ils ont un mérite : ils existent avant l'outil.

Après la mise en service, on reprend les mêmes indicateurs, de la même façon. On regarde aussi deux signaux qu'aucun tableau de bord ne donne : combien de fois les utilisateurs sont revenus au chemin manuel, et quels cas l'outil a refusé de traiter. Le second désigne souvent le chantier suivant.

Cette mesure sert à décider, pas à communiquer. Elle peut conclure que le gain est réel, qu'il est faible, ou qu'il s'est déplacé ailleurs. Une mission honnête accepte les trois réponses. Le coût de fonctionnement entre dans ce bilan, comme nous l'expliquons à propos du coût d'un agent en production.

La passation : ce qui reste quand l'ingénieur part

Une mission se juge sur ce qui fonctionne encore longtemps après le départ de l'ingénieur. La passation se prépare pendant la mission, pas à la fin. Quatre choses doivent être en place.

• Une documentation courte et utile. Ce que fait l'outil, ce qu'il ne fait pas, où sont les données, comment on relance, qui appeler. Écrite pour la personne qui prendra le poste plus tard.
• Un référent interne identifié et formé. Il ne code pas forcément. Il sait expliquer l'outil, repérer une anomalie, parler à un prestataire. Il a été associé aux décisions, il ne découvre pas l'outil à la passation.
• Les accès au nom de l'entreprise. Comptes, dépôts de code, clés, hébergement, noms de domaine : tout est détenu par le client, vérifié en sa présence. Un outil dont les accès appartiennent au prestataire n'appartient pas à l'entreprise.
• Un chemin de reprise. Ce qu'on fait si l'outil s'arrête. Il existe toujours, et il est écrit.

La passation se teste. Le référent fait une manipulation courante sans l'ingénieur, pendant que celui-ci est encore là. Si ça bloque, c'est la documentation qui est en cause, et quelqu'un peut encore corriger.

Ce qui fait échouer une mission

Les échecs se ressemblent, et se voient tôt.

• Le périmètre qui gonfle. Chaque ajout paraît raisonnable, et la mise en service recule de semaine en semaine. Le remède est la liste des exclusions, relue à chaque point.
• Pas de porteur côté métier. Les questions restent sans réponse, l'ingénieur tranche seul, l'outil s'éloigne du travail réel. Sans porteur nommé, mieux vaut suspendre.
• Des accès jamais ouverts. On travaille sur des données fictives, tout fonctionne, et la mise en service révèle que le réel ne ressemble pas à l'échantillon.
• Un outil imposé sans les utilisateurs. Décidé en comité, annoncé par note, jamais essayé par ceux qui devront s'en servir. Ils reviennent au tableur.
• La confusion entre démonstration et service. Une démonstration réussie sur quelques cas choisis ne dit rien de la tenue sur un flux réel, avec ses pièces manquantes.
• Le chantier trop gros. Remplacer d'un coup l'outil central du service donne un projet long, visible et fragile. Une automatisation étroite posée sans casse installe la confiance nécessaire au chantier suivant.

Dernière cause, moins visible : l'équipe qui ne sait pas quoi faire de l'outil livré. Cela ne se règle pas par une formation en fin de mission, mais par la participation des utilisateurs tout du long et par un travail de fond sur la montée en maturité des équipes.

Pour aller plus loin

Ce déroulé est la traduction pratique d'un métier décrit dans la page pilier de cette série, ce qu'est un forward deployed engineer. Si vous avez un geste répétitif en tête, partez d'un cas réel : c'est l'objet de notre diagnostic, qui produit une cartographie et une liste de chantiers classés, que vous poursuiviez avec nous ou non.

Questions fréquentes

Faut-il que l'ingénieur soit présent sur site en permanence ?

Non, mais la présence physique compte surtout au début, pendant l'observation et la cartographie, puis aux moments où les utilisateurs prennent l'outil en main. Entre ces périodes, le travail se fait très bien à distance avec des points courts et réguliers. Ce qui ne marche pas, c'est une mission entièrement à distance, où l'ingénieur ne voit jamais le travail réel.

Peut-on démarrer si nos données sont en mauvais état ?

Oui, et c'est fréquent. L'état des données fait partie de ce que la cartographie révèle, et il oriente le choix du premier chantier : on commence là où la donnée est suffisamment propre pour tenir, pas là où il faudrait une longue reprise avant de produire quoi que ce soit. Vouloir nettoyer tout le patrimoine avant de commencer est le meilleur moyen de ne jamais commencer.

Que se passe-t-il si nos priorités changent en cours de mission ?

Elles changent souvent, et le découpage en chantiers courts existe pour ça. Un changement de priorité se traite à un point de décision : on termine ce qui est en cours et utilisable, puis on repose le choix suivant. Ce qui pose problème, c'est le changement de périmètre au milieu d'un chantier, parce qu'il produit un outil à moitié fini dans deux directions.

Nos équipes vont-elles croire qu'on cherche à supprimer des postes ?

La question se pose presque toujours, et mieux vaut y répondre avant qu'elle circule dans les couloirs. Ce que nous pouvons dire, c'est ce que nous faisons : nous outillons des gestes précis, que les personnes concernées ont elles-mêmes désignés comme pénibles, et elles participent à la conception. Ce que l'entreprise fait du temps libéré est une décision de direction, et elle doit être annoncée par la direction, pas par le prestataire.

Comment savoir si notre sujet relève d'une mission ou d'un outil du marché ?

Si le besoin est standard et que le travail peut s'adapter à l'outil, un logiciel du marché coûte moins cher et se maintient tout seul. Une mission se justifie quand le travail est propre à votre organisation, quand plusieurs systèmes doivent se parler, ou quand la valeur tient justement dans votre façon de faire. Le diagnostic sert aussi à trancher cette question, y compris en concluant que l'achat est la bonne réponse.