- Un Forward Deployed Engineer (FDE) est un ingénieur directement déployé chez le client pour mettre en œuvre le « dernier kilomètre » de produits techniquement complexes
- Ce n’est pas un simple consultant, mais un développeur qui écrit du vrai code de production, débogue et identifie de nouvelles opportunités produit
- Ce modèle ne convient pas à toutes les entreprises et n’est efficace que si trois conditions sont réunies : de gros contrats clients, un ICP non standardisé et une attitude ouverte sur l’orientation du produit
- Les meilleurs FDE sont souvent des profils en début de carrière dotés d’autonomie intellectuelle, de persévérance, d’un très haut niveau technique et d’une curiosité business, sans dépendre de playbooks existants
- Pour piloter une équipe FDE, l’essentiel est de se concentrer sur les problèmes les plus difficiles des plus gros clients, tout en combinant présence sur site et bon contrôle du périmètre
Origines et état actuel des FDE
- Alex Karp, cofondateur de Palantir, a imaginé pour la première fois le rôle de Forward Deployed Engineer (FDE) il y a environ 20 ans, inspiré par l’idée qu’un serveur dans un restaurant français est le prolongement de l’équipe en cuisine
- Le FDE est directement déployé chez le client et construit le "dernier kilomètre" du produit dans l’environnement de production ; à la différence d’un consultant solutions traditionnel ou d’un sales engineer, il écrit et débogue réellement du code de production
- Longtemps, le rôle a suscité du scepticisme comme n’étant « rien de plus que du conseil premium », mais l’intérêt a été relancé après que Palantir a dépassé les 300 milliards de dollars de capitalisation boursière
- Entre janvier et septembre 2025, les offres d’emploi FDE ont augmenté de 800 %, et des startups IA, dont OpenAI, construisent des équipes FDE pour renforcer leurs ventes enterprise
Où les FDE créent de la valeur
- Le FDE ne se limite pas à l’implémentation : c’est un véritable membre de l’équipe software engineering qui doit parler chaque jour avec les clients tout en construisant lui-même le logiciel
- Chez Serval, les FDE ont par exemple transformé en produit plus de 60 intégrations d’apps tierces, un système de feedback sur les performances d’agents, des systèmes de SLA, etc.
- Le périmètre des FDE de Palantir va de la réduction du taux de défauts dans l’industrie manufacturière au déploiement de logiciels pour la gestion de l’aide lors de catastrophes naturelles
-
Aider à conclure de gros contrats
- Looker a utilisé les FDE dans les ventes en proposant aux prospects un essai gratuit sur leurs données réelles, avec un fort accompagnement pré-implémentation
- Le cofondateur Lloyd Tabb : « Le fait de ne pas avoir tranché entre produit et service a ouvert une troisième voie. Nous vendions un produit, mais en faisant du forward deployment pendant l’essai gratuit pour que cela ressemble à un service sur mesure. »
- Plutôt qu’une version de démonstration avec de fausses données, les PoC étaient toujours construits sur les vrais jeux de données des prospects
- Chez Palantir aussi, il existe des cas où 3 à 4 FDE ont construit directement des solutions spécialisées pour résoudre le problème, sans roadmap ni validation du siège, afin de conclure un contrat avec un client du secteur de l’énergie
-
Identifier des opportunités produit via l’immersion client
- Une immersion sur site permet de découvrir des insights profonds qu’un simple Zoom de 30 minutes ne permet pas d’obtenir
- « Vivre sur le terrain avec le client est au cœur du rôle de FDE. Il ne s’agit pas de planifier des user interviews, mais de prototyper le soir ce qu’on a entendu dans la journée et de le montrer le lendemain. »
- Certains des cas de réussite les plus marquants des FDE chez Palantir sont apparus dans des domaines sans lien direct avec le produit cœur
- Mais il existe un risque que les FDE fabriquent au hasard des fonctionnalités sans rapport avec l’amélioration du produit principal ; il faut donc un vrai sens produit pour identifier des problèmes pouvant aussi être servis à d’autres clients
-
Étendre l’énergie des fondateurs des débuts
- Le modèle FDE est une manière de reproduire et d’étendre l’énergie des débuts, quand le CTO écoutait directement les retours clients et y répondait immédiatement par du code
- Chez Serval, la différence entre FDE et ingénieur classique est faible ; les FDE passent environ 20 % de leur temps avec les clients et se concentrent sur des capacités produit plutôt que sur l’infrastructure
- Dans un cycle traditionnel feedback-produit, il faut souvent plusieurs mois entre le solution engineer, le PM, l’engineering manager et la planification d’un sprint ; le modèle FDE supprime ces couches intermédiaires
-
Résorber les fonctionnalités peu prioritaires
- Les FDE peuvent traiter concrètement des demandes de fonctionnalités de niveau P2 qui sont sans cesse repoussées dans la roadmap
- Chez Verkada, l’équipe commerciale accumulait les demandes clients dans un canal Slack nommé "Feature Garage", mais la plupart restaient ignorées
- « Si les P2 continuent de s’accumuler, même en se concentrant uniquement sur ce qui est techniquement correct, on finit quand même avec un produit inférieur. Dans un modèle FDE, les P2 sont réellement examinés. »
Auto-diagnostic avant de lancer des FDE
- Investir dans une équipe FDE représente un coût important, surtout pour une startup en phase initiale, et si l’économie du modèle n’est pas bonne, on peut brûler rapidement sa trésorerie
- Le CEO de Looker, Frank Bien, n’a décidé d’investir dans les FDE qu’après avoir validé un modèle permettant d’atteindre 100 millions de dollars d’ARR avec 2 000 clients
- « Si vous comprenez parfaitement le modèle, vous pouvez vérifier par le calcul si chaque ressource que vous ajoutez peut être supportée. Mais si vous ne saviez pas s’il fallait 2 000 ou 100 000 clients pour atteindre 100 millions de dollars, vous auriez simplement brûlé l’argent des VC. »
-
Condition 1 : avoir déjà gagné, ou viser, de gros clients
- Les FDE sont par nature une stratégie upmarket, et si la forme finale visée est un modèle PLG premium, les FDE ne sont pas adaptés
- Ironclad a compris très tôt que ses meilleurs clients étaient les directions juridiques de très grands groupes mondiaux, et a introduit des FDE en jugeant qu’une implémentation sur mesure était nécessaire pour sécuriser des ACV enterprise
-
Condition 2 : ne pas avoir une vision trop rigide de l’usage du produit
- Si une entreprise a une opinion très forte sur ce que son produit doit devenir, des PM ou des ingénieurs en contact direct avec les clients seront souvent plus appropriés que des FDE
- À une extrémité du spectre, Apple (même expérience pour tous les utilisateurs) ; à l’autre, Palantir (une plateforme transformable pour s’adapter à des problèmes et organisations variés)
- Aux débuts de Palantir, on disait rarement « voilà à quoi le produit doit ressembler » ; les FDE apprenaient des cas d’usage concrets et des clients pour construire progressivement un produit utile
-
Condition 3 : un ICP non homogène
- Si les critères clients sont définis de façon très détaillée, le besoin d’une équipe FDE peut diminuer
- Les 50 premiers clients d’Ironclad avaient très peu en commun : entreprises tech cotées, startups YC, marques mondiales de beauté, équipes de sport professionnel, etc.
- Les workflows de contrats d’influenceurs en japonais et les contrats de vente d’abonnements saisonniers MLB avaient des besoins totalement différents
- Promise, dont les clients sont des administrations publiques américaines, construit une équipe FDE en raison d’un environnement client hétérogène où chaque État opère ses programmes différemment
-
Ne pas forcer le FDE dans un rôle d’ingénierie ou de post-sales
- Beaucoup de fondateurs disent vouloir des FDE, alors qu’en réalité ils ont souvent besoin d’un software engineer classique ou d’un consultant d’implémentation, CSM
- Questions de validation recommandées par Tiffany Siu de First Round :
- « Qu’est-ce qui vous amène à ouvrir ce poste ? Qui fait actuellement ce travail ? Que se passera-t-il si vous ne recrutez pas cette personne ? »
- « À quoi ressemble concrètement le quotidien de cette personne ? »
- « Quels sont les indicateurs de réussite de cette personne ? »
- Si vous voulez « qu’un FDE close X deals ou fasse X démos », c’est qu’il vous faut non pas un FDE, mais un rôle plus proche de la vente
Comment recruter le bon FDE
- Il n’est pas nécessaire de s’obséder sur le fait de trouver quelqu’un qui a déjà le titre FDE. Comme la structure du rôle varie selon les entreprises, il faut vérifier le contenu réel du travail plutôt que le titre
-
Les 5 traits communs des meilleurs FDE
- Des profils qui ne dépendent pas de playbooks (souvent en début de carrière) : chez Palantir, une part importante des FDE étaient de jeunes diplômés. Le bon profil est un penseur indépendant convaincu de pouvoir résoudre n’importe quel problème, plutôt qu’un simple spécialiste du pattern matching
- Un candidat avec plus de 10 ans de carrière FAANG et des habitudes trop figées peut même être un signal d’alerte
- La persévérance (grit) : le travail de FDE touche à des espaces problèmes extrêmement difficiles, donc une « volonté d’endurer la douleur » est indispensable. Les meilleurs FDE d’Ironclad étaient eux aussi décrits comme des « grinders »
- Le FDE joue un rôle de mini-fondateur dans l’organisation et doit avoir un fort sens produit ainsi qu’un intérêt réel pour la vente
- Un haut niveau d’exigence technique : les meilleurs FDE d’Ironclad avaient le niveau pour devenir staff engineer dans une top tech company. Chez Palantir aussi, les FDE devaient passer le même process d’entretien que les software engineers
- Une habitude de builder en continu : les meilleurs FDE sont des « builders compulsifs » qui ne peuvent pas s’empêcher de créer — outils, apps, contributions open source, etc.
- Une curiosité profonde pour le business : par exemple, des personnes qui aiment creuser les risques juridiques du marketing d’influence, et qui tirent de l’énergie du fonctionnement même de l’entreprise
-
Concevoir les entretiens
- Palantir privilégiait des entretiens centrés sur la résolution de problèmes de haut niveau à partir de vrais problèmes clients, plutôt que des coding interviews big tech classiques
- Exemple : après avoir présenté un cas de délit d’initié, demander « de quelles données avez-vous besoin, quelles questions poseriez-vous au client, que chercheriez-vous ? » afin d’évaluer à la fois le raisonnement business et le raisonnement technique
- Ironclad utilisait un entretien de présentation ouverte dans lequel les candidats devaient exposer un problème rencontré dans leur parcours et expliquer comment ils l’avaient résolu par la technologie
- Un cas emblématique montrait des photos d’une "deal room" physique dans un financement aéronautique, avec des milliers de pages couvertes de Post-it, puis la macro Excel créée ensuite pour automatiser le processus
Scoper le rôle de FDE : 3 tactiques pour rendre une première équipe FDE réellement impactante
-
Déployer les FDE sur les problèmes les plus difficiles des plus gros clients
- Ironclad envoyait au départ des FDE chez tous les clients, puis a évolué vers une approche où seuls les clients à fort ACV se voyaient attribuer un FDE
- Il ne s’agit pas d’être « totalement une entreprise FDE ou pas du tout », mais de structurer un menu d’options selon les besoins clients, tout en standardisant l’implémentation sur le bas de marché
- Serval aussi déployait d’abord des FDE chez tous les clients, mais les réserve aujourd’hui en priorité aux grands comptes, notamment aux entreprises de plus de 1 000 employés
-
L’importance de la présence sur site
- Les FDE donnent le meilleur d’eux-mêmes sur le terrain. Au-delà de la liste d’exigences écrites dans le contrat, ils peuvent faire des découvertes absentes du périmètre initial en partageant le vécu quotidien du client
- La culture des visites sur site des FDE d’Ironclad était si connue que des responsables juridiques du Fortune 100 les surnommaient "The Backpacks"
-
Une approche équilibrée du scope creep : l’accepter, mais éviter de « masquer un problème produit par du travail humain »
- Il faut accepter la dimension de service du rôle FDE, tout en évitant d’investir un temps illimité dans des solutions qui ne bénéficieront pas aux futurs clients
- Aux débuts d’Ironclad, le scope creep était interprété comme le signal qu’« il y a encore plus de problèmes clients à résoudre », et grâce à une tarification fondée sur les workflows, l’économie du logiciel bénéficiait de cette extension du périmètre
- Le mauvais scope creep, c’est quand on effectue un travail répétitif sans fin sur un workflow à faible nombre d’utilisateurs, sans aucune perspective d’effet de levier logiciel ; dans ce cas, il faut arrêter
- Un vrai FDE est tellement absorbé par la résolution du problème qu’il ne se rend même pas compte qu’il a dépassé le cadre contractuel ; la gestion du périmètre relève donc du manager
Aucun commentaire pour le moment.