Les deux tiers de notre travail de déploiement sont désormais réalisés de manière autonome par notre propre produit (via Duet).
Cet article explique pourquoi, expose notre philosophie sur la construction d'un produit et notre dynamique de déploiement, et comment cela a évolué au fil du temps.
Ce que nous avions l'habitude de mépriser est devenu la réponse par défaut
« Forward deployed engineer » est devenu la réponse à presque toutes les questions difficiles du go-to-market en IA. Les déploiements sont douloureux ? Embauchez des FDE. Les clients ne peuvent pas se servir seuls ? Des FDE. Le produit n'est pas prêt ? Des FDE. Anthropic et OpenAI ont tous deux mis en place des branches de déploiement en entreprise explicitement calquées sur Palantir, et toutes les startups en amorçage à qui je parle ont désormais une offre d'emploi pour un poste de FDE. Les offres d'emploi pour ce titre auraient augmenté de plusieurs centaines de pour cent au cours de l'année écoulée.
Ce qui est étrange, c'est que jusqu'à très récemment, c'était quelque chose pour lequel on se faisait critiquer. Déployer des ingénieurs chez les clients était perçu comme un signe que vous n'aviez pas un vrai produit : vos revenus étaient de moindre qualité et vos marges étaient structurellement plafonnées. Rien n'a changé dans l'économie sous-jacente.
L'essentiel avec les FDE, c'est qu'ils produisent des résultats. C'est formidable à l'ère de l'IA, car les entreprises ne savent peut-être pas quel chemin emprunter pour obtenir le résultat, mais il est clair que l'IA génère des résultats convaincants.
Dans le même temps, ce rôle devient surutilisé et ne devrait pas servir de béquille pour masquer un problème structurel.
« Les FDE avalent la douleur et recrachent du produit »
Palantir (d'où vient mon cofondateur @AshwinSreenivas) a popularisé ce rôle au milieu des années 2000 en vendant Gotham à la CIA, à la NSA et aux unités de renseignement de l'Armée. Et ils ont encaissé les critiques pendant longtemps. Joe Lonsdale, l'un des cofondateurs, a écrit que pendant presque deux décennies, la vision dominante de Palantir était celle d'un cabinet de conseil glorifié plutôt que d'une véritable entreprise technologique, et que cette vision reposait sur une observation vraie : beaucoup de leurs ingénieurs passaient énormément de temps assis avec les clients.
Mais Shyam Sankar, le CTO de Palantir, avait une formule qu'il répétait sans cesse : les FDE avalent la douleur et recrachent du produit.
Les premiers déploiements de Gotham chez Palantir étaient profondément sur mesure, conçus pour répondre à une question de renseignement pour une seule unité. Palantir a encodé les problèmes qu'ils ont vus sous forme de primitives de plateforme : l'ontologie, les modèles d'objets, les permissions, les moteurs de workflow, le suivi de provenance. Ces primitives sont devenues Foundry. Foundry est devenu ce qu'on pouvait vendre commercialement. Apollo et AIP ont suivi le même chemin.
Rien de tout cela n'aurait existé sans des ingénieurs qui avalent d'abord la douleur sur le terrain. La douleur était la matière première du produit, pas un coût de vente.
À mesure que Foundry a mûri, les déploiements standardisés ont considérablement réduit le besoin de travail sur mesure, les marges brutes sont montées dans les 80, et Palantir est passé d'une dynamique menée par les FDE à une vente basée sur les comptes. Beaucoup de ces FDE ont rejoint l'ingénierie centrale. Ils ont aussi, comme on le sait, refusé des contrats où le client voulait simplement un Accenture avec de meilleurs logiciels.
L'équipe FDE n'était pas le modèle économique. C'était le moyen de construire le bon produit.
Pourquoi certaines startups d'IA ont réellement besoin de FDE en ce moment
Si vous construisiez un CRM SaaS en 2015, vous n'aviez pas besoin de découvrir le workflow. Vingt ans de personnes avaient déjà réfléchi à ce qu'est un pipeline, ce qu'est une étape, à quoi ressemble un transfert de lead.
Si vous construisez un agent d'IA pour la comptabilité en 2026, il n'existe pas de workflow établi, car littéralement personne n'a jamais utilisé un tel outil. Personne ne sait à quoi ressemble le parcours utilisateur — pas vous, et surtout pas votre client non plus. Ils ne peuvent pas vous dire ce qu'ils veulent, parce que la chose qu'ils voudraient n'a pas encore de forme.
C'est la même situation dans laquelle Palantir a commencé. Lonsdale expliquait qu'ils étaient partis en déploiement avancé par nécessité : ils avaient une technologie solide et aucune idée de la façon dont leurs premiers clients de la défense et du renseignement fonctionnaient réellement.
Donc oui, envoyez des ingénieurs. Asseyez-vous dans la pièce. Regardez votre produit casser de façons que vos tests n'avaient jamais imaginées. Dans une catégorie vraiment nouvelle, le dernier kilomètre n'est pas un problème de livraison, c'est un problème de découverte, et rien ne remplace le fait d'être sur place.
Le piège n'est pas de commencer. C'est de ne pas s'arrêter.
Une fois que vous savez ce que sont réellement les parcours utilisateurs, vous devriez commencer à retirer les FDE.
Vous n'en aurez pas envie. Pas parce que quelqu'un prend une mauvaise décision, mais parce que les garder est plus facile à chaque sprint.
Les FDE vous permettent d'éviter tous les arbitrages difficiles sur le produit. Vous n'avez jamais à décider ce que fait le produit, ni laquelle des deux demandes clients l'emporte, ni où s'arrête la surface de configuration. Ça semble gratuit. Personne n'a à dire non à qui que ce soit. Aucune décision architecturale douloureuse n'est prise. Le client est ravi.
Et maintenant, vous avez tous les inconvénients du modèle et aucun des bénéfices de la découverte. Votre coût de service ne diminue pas. Vos marges restent plafonnées. Votre croissance est limitée par les embauches. Chaque correctif sur mesure sur le terrain est une décision produit que vous avez choisi de ne pas prendre. Chaque déploiement devrait rendre le suivant plus facile.
En plus de cela, très peu de startups peuvent conclure les contrats à huit chiffres que Palantir décrochait d'emblée, ce qui rend l'économie encore plus difficile à soutenir.
Une dernière chose à ne pas confondre
FDE n'est pas non plus la même chose qu'implémentation. « Intégrez ceci dans leur système de tickets » est un travail réel et nécessaire, mais c'est de l'exécution selon un cahier des charges connu, pas la découverte d'un cahier des charges inconnu. Regrouper les deux sous un même titre, c'est ainsi que les entreprises se convainquent qu'une organisation de services en pleine croissance est un investissement produit.
Les modèles écrivent assez bien le code maintenant pour qu'une grande partie de ce qu'une équipe d'implémentation faisait en 2023 devienne quelque chose que le produit fait lui-même. À terme, vous serez en mesure de construire un agent capable d'effectuer tout le travail du dernier kilomètre de bout en bout. Il pourra observer les workflows et même interroger les clients.
Ce que nous avons fait à la place
Dans notre cas précis avec @DecagonAI, nous croyons fondamentalement qu'une approche axée sur le produit est la réponse, plutôt qu'une approche axée sur les services ou menée par les FDE. Le service client est une activité à fort volume, répétable et décomposable, et quand nous parlons aux entreprises, deux choses sont toujours constantes :
- La rapidité d'itération est essentielle. Lancer un agent d'IA n'est pas une opération ponctuelle. Il faut constamment l'ajuster et le mettre à jour au fil du temps. Si chaque modification nécessite de l'ingénierie, ce sera beaucoup trop lent et trop coûteux pour passer à l'échelle.
- Verrouillage fournisseur et souveraineté. Compte tenu de l'expérience des organisations avec le SaaS, personne ne veut être enfermé chez un fournisseur et dépendre de ses ressources.
Au début, Ashwin et moi construisions personnellement tout ce que les clients demandaient. Au fur et à mesure que le produit a décollé, nous avons pris la décision explicite que notre proposition de valeur centrale serait d'avoir le meilleur produit.
Pour être clair, nous nous associons toujours avec le client pour livrer le résultat de bout en bout. Cependant, même dans ce processus, nous gardons la maîtrise du développement, tout en formant leur équipe à notre produit et en leur donnant les clés. À mesure que le produit a mûri, le travail spécifique au client effectué par notre équipe d'ingénierie a considérablement diminué.
Cette décision a eu ses compromis. Cela signifiait ne pas bricoler quelque chose sur le terrain quand cela aurait été plus rapide. Cela signifiait transformer les remontées terrain en exigences plutôt qu'en correctifs, ce qui prend du temps à court terme.
Le résultat :
- Les deux tiers du travail de déploiement se font désormais de manière autonome via Duet : configuration, itération, la longue traîne de réglages qui exigeait auparavant un humain dans la boucle.
- Il ne faut plus que quelques jours en moyenne pour lancer le premier AOP, même pour les grandes banques, les compagnies aériennes, les opérateurs télécoms, etc.
Il reste encore beaucoup de travail, mais nous sommes sur la bonne voie.
Alors : FDE ou pas FDE ?
Allez en déploiement sur le terrain dès le début. Captez le signal. Gardez vos ingénieurs au contact des clients en permanence.
Puis posez-vous les vraies questions. Le sur-mesure vient-il de l'environnement de votre client, ou des lacunes de votre propre produit ? Le dernier kilomètre est-il irréductible, ou simplement pas encore construit ? Vos FDE découvrent-ils quelque chose, ou absorbent-ils quelque chose ? Et qu'est-ce qui a été intégré au produit la dernière fois que l'un d'eux est revenu ?
Utilisez les FDE pour déterminer ce qui doit exister dans le produit. Les FDE avalent la douleur et recrachent du produit. Si les vôtres avalent la douleur et recrachent plus de douleur, vous n'avez pas une équipe FDE. Vous avez une entreprise de services.
