SolutionScience #033 | Forward Deployed Engineer : le rôle le plus mal compris du moment
Forward Deployed Engineer.
Si tu es SE et que tu vois ce terme apparaître un peu partout en ce moment sans vraiment comprendre ce qu'il recouvre, alors je t'invite à te faire couler un café et à lire ce numéro. Si tu es manager Presales et qu'on t'a déjà demandé « pourquoi on n'a pas de FDE chez nous ? », cela va t'être vraiment utile pour faire de la pédagogie en interne. Et enfin, si tu es RH ou recruteur SaaS et que tu es en train de rédiger une job description FDE en ce moment même : lâche ton clavier deux minutes, parce qu'on a deux ou trois choses importantes à se dire.
Quelque part chez un éditeur SaaS en pleine euphorie IA, un hiring manager a commencé à rédiger une fiche de poste. Il voulait un profil avec cinq petites années d'expérience capable :
- de coder en Python et en Node.js,
- de comprendre les architectures de données complexes,
- de savoir intégrer des systèmes très hétérogènes,
- de faire des démos produit convaincantes devant tous types de stakeholders,
- de gérer la relation client sur le long terme,
- de savoir influencer les business workflows chez un client,
- de parler ML/IA à un data scientist,
- d'avoir des bases solides en MLOps,
- de discuter ROI à un CMO,
- d'avoir du « business acumen » comme on dit,
- d'être orienté « résultats »,
- et de délivrer un projet en autonomie complète dans les six semaines suivant la signature.
Facile, non ?
Il a appelé ça Forward Deployed Engineer. Comme la touche sur un magnétoscope qui traîne dans son grenier.
Le cabinet de recrutement a rappelé le lendemain pour bien confirmer que le budget alloué et l'ensemble des compétences étaient bien pour un seul être humain.
Pour comprendre ce qu'est un FDE, il faut commencer par Palantir. C'est là que le modèle a été inventé, dans un contexte si spécifique qu'il rend la transposition mécanique à d'autres éditeurs vraiment hasardeuse...
Palantir a été fondé en 2003 avec une ambition très précise : résoudre des problèmes analytiques d'une complexité extrême pour des clients comme la CIA, le Pentagone, ou de grandes institutions financières. Gotham, leur première plateforme, n'était pas un logiciel qu'on déploie en 2 semaines : c'était un outil de traitement de données qui nécessitait une intégration profonde dans les systèmes existants du client, avec tout ce que cela implique : une compréhension de l'ordre de l'intime des flux d'information, et souvent la construction sur mesure de workflows entiers qui n'existaient nulle part ailleurs.
Dans ce contexte, le cycle de vente que je dirais « classique », à savoir discovery, workshops, démo, POC éventuel, closing, était structurellement insuffisant. Ce dont Palantir avait besoin, ce n'était pas des personnes capables de faire de belles démonstrations : c'était des vrais ingénieurs de très haut niveau, capables de s'embarquer physiquement chez le client pendant des semaines ou des mois, de vivre dans son environnement, de comprendre son architecture de l'intérieur, et de construire des solutions qui fonctionnent dans sa réalité.
Forward Deployed Engineers : des ingénieurs « déployés en avant », au sens littéral du terme.
Ce rôle a été pensé pour des contrats gouvernementaux de plusieurs dizaines de millions de dollars, sur des cycles de plusieurs années, avec des clients dont les enjeux opérationnels étaient, dans le sens propre du mot, vraiment stratégiques. C'est dans ce terreau-là que le FDE a du sens. Beaucoup moins dans une organisation qui vend une solution de CRM ou de Marketing Automation à des équipes de quelques personnes.
Le rapport avec le rôle de SE ? Aucun.
La confusion entre ces deux rôles vient d'une lecture superficielle qui se limite à constater que les deux profils sont techniques et font du client facing. C'est à peu près aussi pertinent que de confondre un chirurgien et un médecin généraliste parce que les deux portent une blouse blanche et parlent de choses médicales.
Le SE vit dans le cycle de vente et son terrain est la relation commerciale dans toute sa complexité : la discovery pour comprendre les besoins derrière les besoins, la narration de valeur pour rendre la technologie pertinente pour résoudre des problèmes réels, la navigation politique dans une organisation pour identifier les alliés, neutraliser les résistances, et construire un consensus vers la décision. Il est à l'intersection du commercial et du technique, et c'est précisément cette double lecture qui fait sa valeur. Il ne construit pas ou très peu : il convainc, il influence, il sème de la confiance, il guide, bref, il crée les conditions pour qu'une décision soit possible... et prise.
Le FDE, lui, vit dans le cycle du delivery. Il arrive en général quand la décision est déjà prise (même s'il peut aider en phase d'avant-vente). Son terrain, c'est le code, les données, les intégrations, la construction de ce qui a été promis pendant la vente. Sa mission est de rendre la technologie réellement opérationnelle dans l'environnement spécifique du client, avec ses contraintes, ses systèmes « legacy », ses données imparfaites, ses équipes techniques plus ou moins disponibles. Il n'a pas à gérer la politique commerciale : quelqu'un d'autre, de compétent, s'en est occupé avant lui.
Ces deux rôles ne sont pas hiérarchiquement ordonnés : le FDE n'est pas du tout un SE amélioré, et le SE n'est pas un FDE qui manque d'expérience technique. Ce sont deux métiers distincts, avec des compétences différentes, des temporalités différentes, et des modes opératoires fondamentalement... différents.
Pourquoi la confusion explose maintenant ?
L'IA générative a créé un phénomène nouveau chez les éditeurs et chez leurs prospects : la promesse est immense, visible, tangible et pourtant la projection des cas d'usage réels dans un contexte organisationnel spécifique reste très difficile. Les équipes métiers voient bien le potentiel mais elles ne savent pas comment le matérialiser. Les éditeurs voient l'opportunité et cherchent des profils capables de rendre les choses concrètes très rapidement, dans l'environnement réel du client, avec de vraies données.
Et dans cette fébrilité collective, quelqu'un a sorti le terme FDE du chapeau. Parce qu'il sonnait sexy et sérieux et parce que Palantir avait construit quelque chose qui semblait fonctionner. Le marché cherchait un mot pour un besoin qu'il n'arrivait pas encore à formuler clairement.
Le problème, c'est que le modèle Palantir a été construit pour un GTM très spécifique et une complexité d'intégration hors normes. La plupart des éditeurs SaaS opèrent dans un monde quand même très différent : des cycles plus courts, des budgets de quelques dizaines ou centaines de milliers d'euros, et accessoirement des équipes chez les prospects qui ont d'autres priorités que d'accueillir un ingénieur externe pendant six mois.
Copier le terme FDE sans copier le contexte, c'est comme installer un moteur de F1 dans une Twingo parce que la F1 gagne des courses.
Les conséquences de cette confusion ne sont pas théoriques. Elles se mesurent en recrutements ratés, en loupés organisationnels, et en opportunités commerciales manquées. Oups.
Un SE qu'on transforme progressivement en FDE, parce qu'on lui demande de construire des intégrations, de coder des prototypes, de délivrer des projets post-signature passe moins de temps sur ce qui fait sa vraie valeur : aider et accélérer fortement le closing.
Un FDE qu'on force à faire des démos et à gérer des relations perd en profondeur technique : il est mal à l'aise dans les situations commerciales ambiguës, il manque de patience pour les politiques internes des organisations clientes, et il finit par partir chez un éditeur qui le laisse faire ce pour quoi il est vraiment bon.
Voici donc quelques conseils pour les différentes fonctions chez un éditeur :
Pour les managers Presales : quand ton organisation commence à parler de créer des postes FDE, sort l'option « temps mort » et pose une question simple avant toute autre chose : quel est notre modèle GTM et est-ce qu'il ressemble à celui de Palantir ? Si la réponse est non, la conversation sur le FDE est probablement prématurée. Défends la clarté du rôle SE avec des arguments business.
Pour les RH et hiring managers : avant de rédiger une job description FDE, demande-toi à quelle étape du cycle cette personne intervient majoritairement. Avant ou après la signature ? Plutôt construction ou conviction ? Si la réponse mélange les deux, tu n'as peut-être pas besoin d'un FDE : tu as besoin de revoir ton organisation commerciale.
Pour les SEs : cette confusion n'est pas une menace pour ton rôle : elle est le symptôme d'une incompréhension de ce que tu fais vraiment et je crois que c'est une opportunité de le rendre visible. Sois capable d'expliquer précisément où s'arrête ton terrain et où commence celui du FDE. Les organisations qui comprennent cette frontière construisent de bien meilleures équipes commerciales.
Pour les éditeurs qui veulent vraiment un modèle FDE : les prérequis sont exigeants : des contrats suffisamment importants pour justifier le coût d'un ingénieur senior embarqué chez le client pendant des semaines voire des mois. Une complexité d'intégration réelle qui ne peut pas être adressée par un onboarding standard. Et une organisation Customer Success et/ou Professional Services déjà très mature pour absorber la transition post-déploiement. Sans ces conditions, le FDE est un titre très coûteux pour un problème qui n'existe pas encore.
Le Forward Deployed Engineer est un vrai métier. Il a été inventé pour de vraies raisons, dans un contexte qui le rendait indispensable.
La confusion entre SE et FDE n'est pas qu'un problème de terminologie RH. C'est le symptôme d'une incompréhension plus profonde de ce que vendre et délivrer de la valeur technologique impliquent réellement et de qui fait quoi dans ce processus. Dans un marché où les cycles de vente se complexifient et où la pression sur les équipes Presales ne va pas en diminuant, cette clarté-là n'est pas un luxe organisationnel : c'est une condition de performance !
Et toi… tu as déjà vu une job description FDE qui t'a fait te demander si l'auteur avait déjà rencontré un ingénieur de sa vie ?
Merci de lire SolutionScience chaque semaine. Si ce numéro met des mots sur quelque chose que tu avais du mal à formuler, partage-le à tes collègues SEs, à tes AEs, et surtout à tes RH : ils en ont probablement besoin sans le savoir.
Si tu n'es pas encore abonné, c'est le moment !
À vendredi prochain.
Philippe