Recruter un forward deployed engineer ou le faire venir en service

La question n'est pas « faut-il ce profil », c'est « sous quelle forme »

Vous avez compris l'intérêt du modèle forward deployed : un ingénieur qui travaille dans vos locaux, sur vos données, à côté des personnes qui font le travail, et qui livre des choses utilisables plutôt que des recommandations. La question suivante arrive vite. Est-ce qu'on embauche ce profil, ou est-ce qu'on le prend en service ?

Les deux réponses sont défendables. Ce qui les sépare, ce n'est ni la qualité des personnes ni l'ambition du projet. C'est l'état de votre organisation au moment où vous décidez. Cet article donne les critères pour trancher, et ce qu'il faut sécuriser dans les deux cas.

Ce que ce profil sait faire, et pourquoi il est rare

Le poste combine cinq choses qui, prises isolément, se recrutent sans difficulté particulière.

• L'ingénierie logicielle. Écrire du code qui tourne en production, qui se teste, qui se déploie, et qui se reprend six mois plus tard par quelqu'un d'autre. Pas un notebook de démonstration.
• Les données. Aller chercher l'information là où elle est, dans un ERP, un CRM, une boîte mail, un dossier de fichiers, et accepter qu'elle soit sale. Nettoyer, rapprocher, documenter ce qui manque.
• L'IA appliquée. Savoir ce qu'un modèle sait faire et ce qu'il ne sait pas faire, poser les garde-fous, vérifier les sorties, décider ce qui doit rester calculé par du code plutôt que produit par un modèle.
• L'écoute du métier. Passer une demi-journée dans un service, regarder les gestes réels, repérer l'étape que personne ne mentionne parce qu'elle paraît évidente, et reformuler le besoin autrement que le commanditaire ne l'a formulé.
• La décision sur le terrain. Arbitrer seul, devant l'utilisateur, sans remonter la question à un comité. Dire non à une demande qui ferait dérailler le projet. Dire oui à un changement de cap le mardi après avoir écouté le lundi.

La rareté ne vient pas de chaque brique, elle vient de la combinaison. Les profils très techniques préfèrent souvent la profondeur au terrain : ils veulent un cahier des charges, pas une réunion dans un atelier. Les profils très à l'aise avec le métier écrivent rarement du code de production. Et le cinquième point, l'autonomie de décision, s'acquiert par l'exposition, pas par la formation. Cela ne se lit pas sur un diplôme.

Ajoutez une contrainte de tempérament. Le poste demande d'arriver dans un service qu'on ne connaît pas et d'y produire quelque chose d'utile avant que la patience ne s'épuise. Beaucoup d'excellents ingénieurs détestent cette situation, et c'est ce qui réduit le vivier.

Les trois conditions d'un recrutement qui tient

Un recrutement réussi sur ce poste repose sur trois appuis. Si l'un manque, la personne partira, ou s'éteindra, ce qui revient au même en plus lent.

1. Un flux de sujets continu

Ce profil vit de la variété et du rythme. Il lui faut un sujet en cours, un sujet qui arrive, et un sujet en observation. Une entreprise qui a un seul chantier identifié recrute en réalité pour un projet, pas pour un poste. Une fois le chantier livré, la personne se retrouve à faire de la maintenance, ce qui n'est pas ce qu'elle est venue chercher.

Listez sur une page les sujets que vous confieriez à cette personne sur les prochains mois. Pas les idées, les sujets : un service demandeur, un utilisateur identifié, une situation qui coûte du temps aujourd'hui. Si la liste tient en deux lignes, la question du recrutement est prématurée. Si elle déborde et que vous devez arbitrer, le flux existe. Un sujet ne devient réel que le jour où quelqu'un du métier accepte d'y passer du temps.

2. Quelqu'un capable de l'encadrer techniquement

Encadrer ne veut pas dire manager. Le poste a besoin d'un pair qui puisse relire une décision d'architecture, challenger un choix de stockage, remarquer qu'une clé d'API traîne dans un fichier, et dire « là tu vas trop vite ». Ce rôle peut être tenu par un responsable technique interne, un architecte, un lead développeur. Il peut aussi être tenu de l'extérieur, à condition que ce soit organisé et non improvisé.

Sans ce pair, la vitesse du profil devient un problème. Il livre vite, il livre beaucoup, et personne ne voit que la dette s'accumule. Les questions de mise en production, de reprise et de sécurité passent à la trappe, et on s'en aperçoit le jour où un outil devient critique. C'est le sujet traité dans ce qui sépare un POC métier d'un outil en production.

3. Une entreprise prête à le laisser travailler hors de l'informatique centrale

Le modèle suppose que l'ingénieur s'installe dans le service, prend ses accès, parle directement aux utilisateurs et livre sans passer par le cycle complet des projets informatiques. Si votre organisation impose un ticket pour chaque accès, un comité pour chaque livraison et plusieurs semaines de file d'attente avant toute mise en ligne, vous allez recruter un profil rapide et l'installer dans un dispositif lent. Il fera le travail d'un chef de projet et partira.

Cela ne veut pas dire travailler contre la direction informatique. Cela veut dire négocier un cadre à l'avance : quels environnements sont ouverts, quelles données sont accessibles, quel niveau d'outil peut être mis entre les mains d'un service sans revue lourde, et à partir de quel seuil le projet bascule dans le circuit standard. Ce cadre se pose avant le recrutement, avec la direction informatique dans la pièce. L'hébergement et la conformité se clarifient à ce moment : voir héberger un projet IA en France.

Les signes qu'il vaut mieux commencer par un service

Quatre situations rendent le recrutement risqué et le service plus raisonnable.

• Le premier sujet est encore à cadrer. Vous savez qu'il y a un problème, vous n'êtes pas sûr de sa forme ni de qui devrait le porter. Recruter dans ce brouillard, c'est demander à la personne de définir son propre poste pendant sa période d'essai.
• Il n'y a pas de pratique IA en interne. Personne chez vous n'a encore mis un modèle en production, personne ne sait relire une décision sur ce terrain. Le nouvel arrivant n'aurait aucun repère, et vous non plus pour l'évaluer.
• Vous avez besoin de résultats avant d'ouvrir un poste. Créer un poste demande souvent des arbitrages longs. Un premier livrable qui tourne et que des utilisateurs réclament rend la discussion nettement plus courte.
• Vos sujets arrivent par vagues. Trois chantiers au premier semestre, rien au second, puis deux à l'automne. Un service absorbe cette irrégularité. Un poste permanent la subit.

C'est la même logique que le choix entre sur-mesure et logiciel du marché : on engage une structure quand le besoin est stable et connu, on garde de la souplesse tant qu'il ne l'est pas.

Le risque du recrutement isolé

C'est le scénario le plus fréquent. Une entreprise recrute un profil solide, unique en son genre dans la maison. Il livre. Les utilisateurs sont contents. Les demandes affluent. Et personne ne relit jamais ce qu'il produit.

Au bout de quelques mois, plusieurs outils tournent, tous conçus par la même personne, avec ses conventions et ses raccourcis. La documentation existe dans sa tête. Les accès sont à son nom. Quand un utilisateur signale un problème, il est le seul à pouvoir répondre. Et vous n'avez aucun moyen de savoir si ce qui tourne est bien construit, parce que personne d'autre ne sait le lire.

Ce n'est pas une question de confiance. Un ingénieur seul, même excellent, prend des décisions qui ne sont jamais contredites. Il stagne, s'isole, finit par partir parce qu'il n'apprend plus, et vous héritez d'un parc d'outils orphelins.

La parade est connue. Jamais un seul. Soit vous recrutez avec un pair interne qui relit, soit vous adossez la personne à une équipe externe qui joue ce rôle, soit vous imposez une revue croisée régulière avec un tiers. Et vous exigez dès le premier jour que chaque outil livré ait un second lecteur identifié.

Le modèle mixte, souvent le plus sain

Dans la plupart des organisations de taille moyenne, la bonne réponse se déroule dans le temps.

Premier temps : un service. Vous prenez un forward deployed engineer en service pour traiter deux ou trois sujets réels. L'objectif n'est pas seulement de les livrer. Il est de mesurer autre chose : est-ce que les services demandeurs suivent, est-ce que les utilisateurs adoptent, est-ce que d'autres sujets remontent spontanément. Vous testez votre flux en conditions réelles.

Deuxième temps : la décision. Si le flux est prouvé, le recrutement se défend tout seul, usages à l'appui. Si le flux ne se confirme pas, vous n'avez pas créé un poste que vous devrez justifier pendant des années.

Troisième temps : la passation. Le point critique, et celui qu'on oublie. Elle ne s'organise pas quand la personne recrutée arrive, mais au premier jour du service. Le prestataire travaille dès le départ comme s'il devait partir : code lisible, dépôt chez vous, environnements documentés, décisions écrites, et un référent interne désigné qui suit les travaux même s'il ne code pas.

Ce troisième temps monte aussi le niveau général de la maison. Un ingénieur en service qui explique ce qu'il fait aux équipes métier laisse derrière lui plus que des outils : voir faire monter ses équipes en maturité IA.

Ce qu'il faut exiger d'un prestataire pour ne pas être prisonnier

Un service mal cadré crée exactement la dépendance que vous cherchiez à éviter en recrutant. Cinq exigences suffisent, et elles se posent avant de commencer.

• La propriété du code. Le code produit pour vous est à vous, sans condition et sans licence à renouveler. Le dépôt est chez vous, ou sous un compte à votre nom dont vous avez l'administration. Vérifiez que vous pouvez cloner le projet vous-même, pas qu'on vous le promette.
• L'hébergement à votre nom. Serveurs, noms de domaine, bases de données et comptes de services sont ouverts au nom de l'entreprise, payés par elle, avec vos coordonnées de récupération. Un hébergement au nom du prestataire est un point de blocage le jour où la relation s'arrête.
• La documentation. Pas un manuel que personne ne lit. Un document court par outil : à quoi il sert, qui l'utilise, comment on le relance, où sont les données, quelles décisions ont été prises et pourquoi. Exigez-le dès la première livraison, pas à la fin.
• La formation d'un référent interne. Une personne chez vous doit pouvoir expliquer chaque outil, savoir où regarder quand ça coince, et tenir la relation avec les utilisateurs. Ce n'est pas forcément un développeur.
• La réversibilité. Écrivez la sortie dans le contrat : ce qui vous est remis, sous quel format, dans quel délai, avec une séance de transfert prévue. Mieux : testez-la une fois, à froid, sur un outil déjà livré. Une réversibilité jamais testée est une clause, pas une garantie.

Un prestataire sérieux accepte ces cinq points sans discuter, parce qu'il travaille déjà ainsi. Une hésitation sur l'un d'eux vous renseigne mieux que n'importe quelle référence.

Reconnaître le profil en entretien

Si vous recrutez, l'entretien classique ne vous servira pas à grand-chose. Les compétences qui comptent ici se détectent par le récit d'expériences réelles.

Questions qui font parler

• « Racontez-moi une fois où vous avez livré quelque chose que l'utilisateur n'a pas utilisé. Qu'est-ce que vous aviez mal compris ? » La bonne réponse est précise et assume. La mauvaise accuse l'utilisateur.
• « Sur votre dernier projet, quelles données étaient sales, et qu'est-ce que vous en avez fait ? » Cette question sépare ceux qui ont travaillé sur des données de production de ceux qui ont travaillé sur des jeux de test.
• « Qu'avez-vous refusé de faire, et comment l'avez-vous dit au commanditaire ? » On cherche la capacité à arbitrer seul, sans se réfugier derrière une hiérarchie.
• « Montrez-moi quelque chose qui tourne encore aujourd'hui sans vous. » C'est la question la plus utile de toute la liste.
• « Comment savez-vous qu'une sortie de modèle est fausse ? » Cherchez des méthodes de vérification concrètes, pas une opinion générale sur les limites de l'IA. Le sujet est développé dans le rôle d'AI engineer.

Signaux d'alerte

• Il parle beaucoup d'outils et jamais d'utilisateurs. Comptez les noms de technologies contre les noms de métiers dans ses réponses.
• Il n'a jamais mis quelque chose en production, ou ne sait pas dire ce que devient ce qu'il a livré.
• Il demande un cahier des charges complet avant de pouvoir commencer. Sur ce poste, le cahier des charges est un résultat, pas un point de départ.
• Il ne pose aucune question sur votre organisation pendant l'entretien.
• Il présente l'IA comme la réponse avant d'avoir entendu la question.

Un dernier conseil : faites intervenir une personne du métier dans le processus, pas seulement des techniciens. Faites raconter au candidat comment il aborderait un vrai service chez vous, devant la personne qui le dirige.

Comment trancher

Reprenez les trois conditions. Un flux de sujets que vous pouvez lister. Un pair capable de relire. Une organisation qui accepte un fonctionnement à côté du circuit standard. Si les trois sont réunies, recrutez, en prévoyant d'emblée le second lecteur. Si l'une manque, commencez par un service et servez-vous de cette période pour construire ce qui manque.

Dans les deux cas, les mêmes exigences protègent votre entreprise : propriété du code, hébergement à votre nom, documentation vivante, référent interne, sortie testée. Elles ne coûtent rien à poser au début et changent tout à la fin.

Pour la vue d'ensemble du modèle, retournez à la page pilier : un forward deployed engineer, c'est quoi. Et si vous voulez mettre vos sujets à plat avant de choisir entre un poste et un service, c'est ce que fait le diagnostic IA : on regarde vos cas d'usage, votre organisation et vos données, et on vous dit ce qui tient debout.

Questions fréquentes

Peut-on confier ce rôle à un développeur déjà en poste chez nous ?

C'est possible si la personne a envie de terrain et accepte de travailler dans les services plutôt que devant un backlog. Deux points bloquent souvent : la disponibilité, car elle reste rattachée à ses projets existants, et l'autorité, car ses collègues continueront de la solliciter sur l'ancien périmètre. Si vous tentez ce transfert, détachez la personne complètement et annoncez-le clairement en interne.

Un prestataire peut-il vraiment travailler dans nos locaux, au milieu des équipes ?

Oui, c'est même la condition du modèle. L'ingénieur prend une place dans le service concerné, assiste aux réunions d'équipe et déjeune avec les utilisateurs. Ce qu'il faut préparer côté entreprise, ce sont les accès et un référent qui l'introduit auprès des bonnes personnes la première semaine.

Comment éviter que le service devienne une dépendance permanente ?

En posant la sortie au début et en la testant une fois à froid. Le dépôt de code chez vous, l'hébergement à votre nom, un document court par outil et un référent interne qui suit les travaux suffisent à garder la main. Si vous n'avez jamais essayé de reprendre un outil sans le prestataire, vous ne savez pas si vous en êtes capable.

Faut-il que le référent interne sache coder ?

Non. Il doit comprendre à quoi sert chaque outil, savoir qui l'utilise, où sont les données et qui appeler quand ça coince. Un responsable métier attentif fait souvent un meilleur référent qu'un développeur occupé ailleurs. En revanche il lui faut du temps dédié et les accès, sinon le rôle reste théorique.

Et si on recrute et que la personne part au bout d'un an ?

C'est le scénario à anticiper dès le premier jour, pas à craindre. Si chaque outil a eu un second lecteur, une documentation courte et un dépôt chez vous, le départ est gérable. Si tout est passé par une seule tête, le départ vous coûte l'ensemble du travail. La différence se joue dans les habitudes prises au démarrage.