Ingénieur déployé chez le client : rôle, missions et périmètre

Un ingénieur déployé chez le client prend en charge la partie du système que personne d’autre ne peut construire à distance : les intégrations, les cas particuliers et l’ajustement au fonctionnement réel des équipes. Son périmètre est plus étroit qu’on ne le croit au départ, et il se déplace pendant la mission. Le poser explicitement est la condition pour que la mission tienne.

Le périmètre en trois cercles

Le premier cercle est celui dont il est responsable seul : la mécanique du système, les connexions entre les outils, la qualité de ce qui entre et de ce qui sort. Personne d’autre ne le fera, et il est jugé dessus.

Le deuxième cercle est partagé avec l’équipe interne : les règles métier, les arbitrages sur ce que le système a le droit de faire, la définition de ce qui compte comme un bon résultat. L’ingénieur déployé chez le client propose, l’organisation tranche. Quand il tranche à sa place, l’installation fonctionne un temps puis se retourne contre elle, parce que personne en interne ne sait plus justifier les choix.

Le troisième cercle ne lui appartient pas du tout : la priorisation, le budget, l’arbitrage entre équipes. Il peut alerter, il ne décide pas. C’est le cercle où les missions dérapent le plus souvent, par glissement progressif et sans mauvaise intention de part et d’autre.

Quelles missions lui confie-t-on réellement ?

Sur une mission type, quatre blocs reviennent.

La mise en données arrive en premier, et elle occupe presque toujours plus de temps que prévu. Les fichiers existent rarement dans la forme dont le système a besoin, et une part du travail consiste à décider ce qu’on nettoie, ce qu’on ignore, et ce qu’on renvoie à l’équipe métier parce que seule elle peut le corriger.

L’intégration vient ensuite. Elle est rarement difficile techniquement et souvent difficile organisationnellement : obtenir un accès, comprendre qui a le droit de l’accorder, trouver la personne qui a écrit le connecteur il y a quatre ans.

Le troisième bloc est l’ajustement. Le système fonctionne, les utilisateurs s’en servent, et leurs usages ne ressemblent pas à ce qui avait été imaginé. C’est le moment le plus productif de la mission et celui qu’on ampute le plus volontiers quand le calendrier se tend.

Le quatrième est la transmission. Elle ne se fait pas par une réunion de clôture et un document. Elle se prépare depuis le début, en laissant l’équipe interne faire elle-même les gestes qu’elle devra refaire seule.

Ce qui revient à l’équipe interne

Deux choses, non négociables. La première est la définition de la qualité : quel résultat est acceptable, lequel ne l’est pas, et qui arbitre les cas limites. Un ingénieur externe peut proposer une grille, il ne peut pas la valider à la place de ceux qui vivront avec.

La seconde est la propriété du système après la mission. Si aucune personne interne n’est nommée avant la fin, le système devient orphelin le jour du départ. La qualité du code n’y change rien. C’est un point sur lequel une formation IA en entreprise par AI Makers fait souvent plus de différence qu’une semaine d’ingénierie supplémentaire, parce qu’elle produit des gens capables de reprendre l’ouvrage.

Les frictions les plus fréquentes

La première friction est le périmètre qui s’étend sans qu’on le renégocie. Une demande adjacente arrive, elle est petite, on la prend. Trois mois plus tard, l’ingénieur maintient quatre outils dont deux ne faisaient pas partie de la mission, et le projet principal a pris du retard sans qu’aucune décision explicite n’ait été prise.

La deuxième est l’ambiguïté sur le rôle d’arbitre. L’ingénieur déployé chez le client est présent, disponible, et il comprend le sujet mieux que la plupart des interlocuteurs. Il devient naturellement celui à qui l’on pose les questions de fond. C’est confortable pour tout le monde et mauvais pour le projet, parce que ces questions ne sont pas les siennes.

La troisième est le double rattachement. Il rend des comptes à son employeur et travaille dans les équipes du client. Quand les deux divergent, l’absence de règle explicite se paie immédiatement. Le point mérite d’être traité avec la même rigueur que le reste du dispositif de gouvernance de l’IA, car il porte sur la même question : qui décide de quoi.

Comment le périmètre évolue

Il se resserre, en général, et c’est bon signe. Au début, l’ingénieur touche à tout parce que rien n’est stabilisé. À mesure que le système se solidifie, des morceaux passent à l’équipe interne, et le périmètre se recentre sur ce qui reste incertain.

Un périmètre qui s’élargit au fil des mois indique presque toujours l’inverse : l’organisation s’est habituée à déléguer, et la transmission n’a pas commencé. Le signal est mesurable sans instrument sophistiqué. Il suffit de regarder qui écrit les modifications au sixième mois. Si c’est toujours la même personne, la mission produira un système qui marche et une équipe qui ne saura pas le faire vivre.

Ce mouvement de resserrement est aussi ce qui distingue le rôle d’une prestation classique. La question de savoir à quel moment un FDE devient nécessaire se pose donc en même temps que celle de savoir quand il cesse de l’être.