Recruter un FDE : profil, signaux et erreurs à éviter

Recruter un FDE revient à chercher quelqu’un qui supporte l’ambiguïté aussi bien qu’il code. Le niveau technique est un prérequis, pas un critère de sélection : la plupart des candidats qui échouent sur ce poste sont d’excellents ingénieurs. Ce qui les met en difficulté, c’est un problème dont l’énoncé bouge, dans une organisation qu’ils ne dirigent pas.

Le profil réel

Le poste demande trois choses simultanément, et c’est leur simultanéité qui rend le recrutement difficile.

Une capacité technique large plutôt que profonde. Un FDE touche à l’intégration, aux données, à un peu de modélisation, à beaucoup de plomberie. Il a rarement besoin d’être le meilleur sur l’un de ces sujets ; il a besoin d’être autonome sur tous, parce qu’il n’aura personne à côté de lui pour prendre le relais.

Une aisance avec des interlocuteurs qui ne sont pas techniques et qui n’ont pas demandé le projet. Une bonne partie du travail consiste à obtenir des informations de gens occupés, à leur expliquer un fonctionnement, et à encaisser que la démonstration les laisse indifférents.

Une tolérance à l’inconfort. Le FDE est extérieur à l’organisation mais travaille dedans. Il n’a pas d’autorité et porte la responsabilité du résultat. Cette position ne convient pas à tout le monde, et rien ne le laisse voir sur un curriculum vitae.

Quels signaux chercher en entretien ?

Les meilleurs signaux sont narratifs. Demandez le récit d’un projet qui s’est mal passé, et écoutez où se porte l’attention. Un candidat qui décrit longuement la solution technique et rapidement le contexte humain travaillera bien en environnement stable. Celui qui raconte spontanément qu’il a mis six semaines à comprendre que le problème posé n’était pas le bon a déjà vécu le métier.

Trois autres signaux, faciles à tester.

La reformulation. Donnez un besoin volontairement vague et regardez si le candidat commence par construire ou par poser des questions. Sur ce poste, poser des questions n’est pas de la prudence, c’est la compétence principale.

Le rapport à la donnée réelle. Demandez ce qu’il a fait la dernière fois qu’un export était incomplet. Les réponses utiles parlent de négociation avec une équipe métier, pas seulement de nettoyage.

Le récit de sortie. Demandez comment s’est terminée sa dernière mission longue et qui a repris le système. Les candidats qui n’ont jamais pensé la transmission le disent sans s’en apercevoir.

L’erreur classique

Elle consiste à recruter le meilleur ingénieur disponible en supposant que le reste s’apprendra. C’est l’inverse qui est vrai : les lacunes techniques se comblent en quelques semaines sur un périmètre large, alors que l’inconfort à travailler dans une organisation étrangère ne se corrige pas par la formation.

Une deuxième erreur, plus discrète, consiste à recruter quelqu’un qui aime résoudre des problèmes difficiles. Le métier en contient peu. Il contient surtout des problèmes ennuyeux dans des conditions désagréables, et il faut aimer les finir plutôt que les résoudre élégamment. Un candidat qui décrit son plaisir comme celui de voir quelqu’un utiliser ce qu’il a construit tiendra mieux que celui qui décrit le plaisir de l’énigme.

La troisième erreur porte sur le poste lui-même plutôt que sur le candidat : ouvrir ce recrutement alors que l’organisation n’a pas encore décidé quoi construire. On obtient alors un ingénieur très capable qui attend des arbitrages, et il partira avant qu’ils n’arrivent.

Intégrer la personne une fois recrutée

Trois décisions valent la peine d’être prises avant le premier jour.

Nommer l’interlocuteur qui arbitre. Un FDE sans interlocuteur décisionnaire finit par arbitrer lui-même, ce qui fonctionne quelques mois puis laisse une organisation incapable de justifier ses propres règles.

Désigner la personne interne qui reprendra le système. Pas à la fin : au début, et en la faisant travailler dès les premières semaines. C’est la seule protection efficace contre le système orphelin, et elle relève autant de l’organisation que de la formation IA en entreprise par AI Makers.

Écrire ce qui n’est pas dans le périmètre. La liste des exclusions est plus utile que celle des missions, parce que l’élargissement se fait toujours par petites demandes raisonnables.

Faut-il recruter ou faire appel à l’extérieur ?

La question dépend de la fréquence. Une organisation qui déploiera plusieurs systèmes de ce type sur plusieurs années a intérêt à internaliser, parce que la connaissance accumulée est la vraie valeur du rôle. Une organisation qui fait cela une fois se trompe presque toujours en recrutant : elle passera plus de temps à recruter qu’à déployer, et le poste perdra son sens une fois le projet terminé.

Entre les deux, il existe une position intermédiaire souvent négligée : faire venir un Forward Deployed Engineer sur la première mission et prévoir explicitement qu’il forme son successeur interne. Le coût apparent est plus élevé, le résultat est plus durable, et la décision se prend plus facilement quand on l’a déjà instruite en regardant ce que le métier recouvre réellement.

Un dernier point, souvent découvert trop tard. Ce recrutement échoue aussi quand l’organisation n’a personne pour écouter ce que l’ingénieur rapporte du terrain. Les contournements qu’il observe sont de l’information rare, et sans mécanisme pour l’absorber, on paie un poste d’observation dont personne ne lit les observations.