Les outils du forward deployed engineer

Le premier outil n'est pas un logiciel

Quand un ingénieur déployé arrive dans vos locaux, la première semaine produit peu de code. Elle produit de la compréhension. Un carnet, un chronomètre, un tableau blanc et beaucoup de questions valent, à ce moment, davantage que n'importe quel environnement de développement. La raison : dans une organisation, personne ne sait décrire complètement son propre travail. Les procédures écrites racontent le cas nominal. Le travail réel est fait d'exceptions, de contournements, de fichiers officieux et de gestes appris sur le tas.

C'est pour cela que la boîte à outils commence par des instruments d'observation et finit par des instruments de transmission. Entre les deux, il y a du code, mais le code n'est que la partie visible. Nous ouvrons ici la caisse, famille par famille : à quoi chacune sert, comment on choisit dedans, ce qu'elle demande à votre informatique, et ce qu'il en reste chez vous à la fin.

Observer et mesurer le travail réel

Cette famille répond à une question : que se passe-t-il vraiment entre l'entrée d'une demande et sa sortie traitée. Les instruments sont volontairement rudimentaires.

• Le relevé de gestes. On s'assoit à côté d'une personne et on note chaque action, dans l'ordre, avec l'outil utilisé. Un aller-retour vers un tableur compte comme une action.
• La capture d'écran annotée. On photographie l'écran à l'instant où la personne hésite, et on écrit en marge la raison de l'hésitation. C'est le format qui se partage le mieux avec un comité de direction.
• Le chronométrage. On mesure un cas simple et un cas compliqué, sur plusieurs personnes. Jamais pour juger le rythme de quelqu'un : pour savoir où part le temps.
• L'entretien court. Vingt minutes, trois questions. Qu'est-ce qui vous fait perdre du temps. Qu'est-ce que vous refaites deux fois. Qu'est-ce que vous n'osez pas déléguer.

Critère de choix : l'instrument qui perturbe le moins le travail observé. Un outil de mesure à installer sur les postes coûte plus cher en temps et en méfiance qu'une demi-journée assise en binôme. À ce stade, votre informatique n'est pas sollicitée : rien n'est installé, rien n'est branché.

Accéder aux données existantes

Dès que l'observation a désigné une cible, il faut atteindre les données. Aucun outil utile ne se construit sur des informations saisies deux fois. Quatre chemins, du plus léger au plus engageant.

• L'export manuel. On demande un fichier au format habituel. Cela suffit pour comprendre la structure des données, pas pour faire tourner un outil au quotidien.
• Le connecteur existant. Beaucoup de logiciels du marché savent déjà envoyer leurs données ailleurs, sans une ligne de code. Quand un connecteur existant couvre le besoin, on le prend. Le code qu'on n'écrit pas est du code que personne n'aura à maintenir.
• L'interface de programmation. La plupart des logiciels métier exposent une porte d'entrée documentée. C'est le chemin le plus propre : lecture cadrée, droits attribués nommément, appels traçables.
• L'accès direct à la base, en lecture seule. Réservé aux cas où rien d'autre n'existe. On demande un compte qui ne peut que lire, et on l'écrit noir sur blanc.

Une cinquième voie concerne les documents : contrats, bons de commande, factures scannées. L'outil devient une chaîne de lecture qui transforme un document en texte exploitable, puis en champs contrôlables. C'est souvent le point de départ des projets qui commencent par un tableur : voir transformer un fichier Excel en outil.

Critère de choix : la source la plus proche de la vérité et la moins intrusive. On demande des droits de lecture nommés et on documente qui accède à quoi dès le premier jour. Pour votre informatique, c'est le moment des vraies demandes : un compte technique, une adresse à autoriser, un pare-feu à ouvrir. Mieux vaut les traiter groupées, au début.

Prototyper vite

Un prototype sert à trancher une question, pas à rendre un service. Sa durée de vie utile se compte en jours. Les outils sont choisis pour la vitesse : une petite application web montée en quelques heures, une feuille de calcul jetable qui rejoue le calcul contesté, une maquette cliquable sans moteur derrière, un script qui tourne sur un échantillon.

La règle qui accompagne cette famille est stricte : un prototype n'est pas une production. Il n'a ni gestion des droits, ni sauvegarde, ni journal, ni reprise sur erreur. Personne ne doit l'utiliser sur un vrai dossier client. Le danger est social. Dès qu'un prototype rend service, une personne s'en sert, puis un service entier, et la mise en production ne se décide plus : elle se subit. Nous fixons donc une date de fin au prototype avant de l'écrire, et nous listons ce qui manquerait pour le rendre exploitable. Ce passage a des prérequis précis, à connaître avant de s'enthousiasmer devant une démonstration qui marche.

Critère de choix : l'outil le plus jetable qui répond à la question posée. Si une feuille de calcul prouve le calcul, on ne monte pas d'application. Un prototype ne doit rien coûter à votre informatique : il tourne sur un poste ou dans un espace isolé, jamais dans un système en service.

Construire l'application

Quand la décision est prise, on passe aux outils de construction. Plus ennuyeux, volontairement. Quatre briques reviennent presque toujours.

• La base de données. Elle fixe le vocabulaire : ce qu'est un dossier, un client, une étape, un statut. La moitié des désaccords d'usage se règlent ici, avant le premier écran.
• Les écrans. Un écran par moment de travail, pas un écran par table. On dessine la journée type de l'utilisateur, les formulaires viennent ensuite.
• Les droits. Qui voit quoi, qui modifie quoi, qui valide. Un outil sans droits clairs finit utilisé au rabais, parce que personne ne veut assumer une erreur visible de tous.
• La journalisation. Chaque action importante laisse une trace datée et nominative. C'est ce qui permet de répondre à « qui a changé ce montant » sans ouvrir une enquête.

S'y ajoutent les tests automatisés, les migrations de données et la gestion des versions. Rien de spectaculaire, mais c'est la différence entre un outil qui vieillit correctement et un outil qui s'effondre au premier changement d'équipe. Ces briques forment le socle de notre méthode application complète.

Critère de choix : les technologies les plus ordinaires qui tiennent le besoin. Un cadre répandu et documenté, que d'autres savent reprendre, vaut mieux qu'un choix élégant connu de trois personnes dans le pays.

La partie IA

L'IA est un composant posé au milieu des autres, pas une famille à part. Elle intervient là où une règle serait impossible à écrire : comprendre une phrase libre, lire un document mal cadré, rapprocher deux libellés qui ne s'écrivent pas de la même façon. Cinq outils composent cette famille.

• Le modèle de langage, appelé depuis le serveur de l'application, jamais depuis le navigateur de l'utilisateur.
• L'extraction depuis documents. On transforme un PDF ou un scan en champs vérifiables, en conservant le passage d'origine pour le contrôle humain.
• La recherche dans un corpus. On indexe vos documents pour que le modèle réponde en s'appuyant sur eux et indique d'où vient sa réponse. Sans source citée, une réponse n'est pas vérifiable, donc pas utilisable.
• Le jeu d'évaluation. Une liste de cas réels, avec la bonne réponse attendue, que l'on rejoue à chaque modification. C'est l'outil le plus négligé et le plus décisif : sans lui, personne ne sait si un changement améliore ou dégrade le résultat.
• Les garde-fous côté serveur. C'est notre règle de maison : tout ce qui engage l'entreprise, un prix, une disponibilité, une référence, une adresse, est calculé par le code et vérifié avant affichage. Le modèle formule, il ne décide pas.

Critère de choix : le plus petit modèle qui passe le jeu d'évaluation, et pas de modèle du tout quand une règle suffit. Deux contraintes non techniques s'ajoutent : où tournent les traitements, et ce que la réglementation impose à votre secteur. Sur le premier point, voir héberger un projet IA en France.

Automatiser les flux

Une application ne suffit pas si le travail continue d'être déclenché à la main. Cette famille relie les briques entre elles. Quatre notions suffisent à comprendre ce qui sera installé chez vous.

• Le déclencheur. Un événement qui lance un traitement : un courriel qui arrive, un fichier déposé, un statut qui change, une heure de la journée.
• La file d'attente. Les tâches s'empilent et sont traitées une par une. C'est ce qui évite qu'un pic de charge fasse tomber l'ensemble un jour de clôture.
• Le traitement de nuit. Les calculs lourds et les synchronisations volumineuses tournent quand personne ne travaille.
• La reprise sur erreur. Une tâche qui échoue est réessayée, puis mise de côté avec son message d'erreur et de quoi la rejouer. Un flux qui échoue en silence est pire qu'un flux absent : on croit le travail fait.

Ici encore, un outil d'automatisation du marché fait souvent l'affaire, et il faut savoir quand il suffit et quand il coince. La bascule vers du sur-mesure se joue sur trois points : le volume, la finesse de la gestion des erreurs, et le besoin d'une trace exploitable en cas de contrôle.

Critère de choix : le nombre de pièces mobiles. Chaque automatisation ajoutée peut se casser un dimanche soir. On n'automatise que les flux dont l'échec est détectable et rattrapable, et on laisse à la main ce qui demande un jugement.

Héberger et exploiter

L'outil vit ensuite tout seul, plusieurs années. Cette famille distingue un projet livré d'un projet abandonné. Elle tient en quatre éléments.

• Les environnements. Un espace de test séparé de l'espace réel. On ne corrige jamais directement dans l'outil que les équipes utilisent, même pour une virgule.
• Les sauvegardes. Automatiques, datées, et surtout testées. Une sauvegarde jamais restaurée est une hypothèse, pas une sécurité.
• La supervision. Est-ce que le service répond, est-ce que les traitements de nuit sont passés, est-ce que la file se vide. Trois indicateurs valent mieux que trente tableaux que personne ne regarde.
• Les alertes. Qui est prévenu, par quel canal, à partir de quel seuil. Une alerte envoyée à tout le monde n'arrive à personne : on nomme un destinataire.

Critère de choix : ce que vos équipes savent déjà exploiter. Si votre informatique administre déjà un type de serveur, on s'y range. Installer une pile inconnue de la maison, c'est créer une dépendance au prestataire, et ce n'est pas le contrat. C'est la famille qui demande le plus de discussion, et le plus tôt possible : hébergement, accès, sauvegardes, astreinte.

Transmettre

Dernière famille, la plus négligée, celle qui décide si l'outil survit au départ de l'ingénieur. Quatre livrables.

• Une documentation courte. Quelques pages, pas un classeur. Ce que fait l'outil, comment il est branché, où sont les données, quoi faire dans tel cas. Une documentation longue n'est jamais lue, donc jamais mise à jour, donc fausse au bout d'un an.
• Une formation sur l'outil réel. Avec les vrais dossiers, dans la vraie application, pas sur des diapositives. Les utilisateurs apprennent en traitant leurs propres cas. C'est le format de notre méthode formation.
• L'accès au code et aux comptes. Le code est à vous, dans un dépôt dont vous êtes propriétaire. Les comptes de service sont à votre nom, chez vos fournisseurs. Si vous devez nous demander un mot de passe pour reprendre la main, la transmission a échoué.
• Un référent interne. Une personne de la maison, formée pendant la mission, qui sait qui appeler et où regarder. Pas forcément un informaticien : souvent celle qui connaît le mieux le métier concerné.

Critère de choix : tout ce qui est installé doit être repris sans nous. On se pose la question à l'envers : si l'équipe disparaissait demain, qu'est-ce qui resterait inutilisable. La réponse dicte la documentation à écrire et les choix techniques à refuser.

Le plus simple qui tienne le besoin

Une règle traverse toutes ces familles : on choisit l'outil le plus simple qui tienne le besoin réel, pas le besoin imaginé dans trois ans. La machinerie inutile a un coût qui n'apparaît pas au devis. Elle se paie au recrutement, quand il faut trouver quelqu'un qui connaît cette pile, et à la panne, quand personne ne sait par où commencer.

Concrètement : un connecteur existant au lieu d'une intégration écrite à la main, une règle explicite au lieu d'un appel de modèle. Chaque fois qu'on ajoute une pièce, on doit pouvoir dire qui la maintiendra et comment on s'apercevra qu'elle est tombée.

Le piège symétrique existe : refuser une brique nécessaire pour rester léger. Une application qui manipule des données sensibles a besoin de droits et d'un journal, même pour dix utilisateurs. La simplicité porte sur le nombre de technologies, pas sur le sérieux de ce qui est construit.

Ce qui reste chez vous

À la fin d'une mission, faites l'inventaire. Vous devez avoir entre les mains : le code source et les comptes d'hébergement à votre nom, les données dans un format exportable, une documentation courte à jour, un jeu d'évaluation si de l'IA est en jeu, et une personne en interne qui sait faire tourner tout cela. Si l'un de ces éléments manque, ce n'est pas une mission terminée, c'est une dépendance installée.

C'est le sens du modèle déployé : l'ingénieur travaille chez vous, sur vos données, à côté de vos équipes, et repart en laissant un outil qu'elles font vivre. Pour reprendre la série depuis le début, le point d'entrée est ce qu'est un forward deployed engineer. Et si vous avez un processus en tête et voulez savoir quelles familles d'outils il appelle vraiment, le diagnostic est fait pour cela : on regarde le travail réel, on nomme ce qui est automatisable, et on vous dit ce qui reste à la main.

Questions fréquentes

Est-ce que l'ingénieur installe des logiciels sur nos postes ?

En phase d'observation, non : le relevé de gestes et les entretiens ne demandent aucune installation. Ensuite, l'outil construit est en général une application web, accessible depuis un navigateur, donc rien à déployer poste par poste. Les seules installations éventuelles concernent les serveurs, et elles passent par votre informatique.

Qui décide de la pile technique, vous ou notre DSI ?

Votre DSI a le dernier mot sur l'hébergement, les accès et les standards internes. Nous proposons, nous expliquons le coût de chaque option, et nous nous rangeons à ce que vos équipes savent exploiter. Installer une technologie que personne chez vous ne connaît crée une dépendance, et c'est exactement ce que le modèle déployé cherche à éviter.

Combien d'accès faut-il nous demander au démarrage ?

Le moins possible, et groupés. On dresse la liste complète après la phase d'observation, en lecture seule quand c'est suffisant, avec un compte nommé par usage. Cela évite les demandes au fil de l'eau qui bloquent le projet une semaine à chaque fois et qui rendent impossible le suivi de qui accède à quoi.

Peut-on garder le prototype pour dépanner en attendant la version finale ?

C'est le scénario que nous refusons le plus souvent. Un prototype n'a ni droits, ni sauvegarde, ni journal : un dossier traité dedans est un dossier que personne ne pourra retrouver. Si le besoin est urgent au point de vouloir garder le prototype, c'est le signe qu'il faut discuter du périmètre de la version exploitable, pas prolonger le prototype.

Comment savoir que l'outil marche encore une fois que vous êtes partis ?

Par trois choses laissées en place : la supervision, qui dit si le service répond et si les traitements de nuit sont passés, les alertes nommées, qui préviennent une personne identifiée, et le jeu d'évaluation, qui se rejoue avant chaque modification quand il y a de l'IA. Votre référent interne sait les lire, cela fait partie de la transmission.