Forward deployed engineers : cartographie d'abord le processus

"Become a $1M/yr FDE." C'est le titre d'un épisode récent de The Startup Ideas Podcast. FDE veut dire forward deployed engineer. Le titre est bon. Les données racontent une histoire plus modeste.

La demande est réelle. Les offres d'emploi pour des forward deployed engineers sur Indeed ont augmenté de 800% entre janvier et septembre 2025. Le salaire est élevé, pas magique. Une analyse du secteur situe le salaire de base médian à environ 174 000 dollars, avec une rémunération totale de 350 000 à 550 000 dollars dans les labs d'IA. Le calcul de l'épisode pour le million est une part de la valeur : livre 10 millions de dollars, gardes-en 10%.

Oublie donc le salaire. Ce qui sert, c'est la méthode derrière. Elle explique pourquoi la plupart des projets d'IA s'enlisent. Et elle vaut autant pour une entreprise de 60 personnes que pour un grand groupe américain.

L'invité est Vasuman Moza de Varick Agents, une société qui place des forward deployed engineers dans de grandes entreprises et reconstruit leurs processus autour d'agents IA. Un forward deployed engineer est un ingénieur qui travaille dans l'activité du client, pas au bureau du fournisseur.

L'animateur Greg Isenberg exige des exemples concrets, et Moza apporte des chiffres issus de missions clients. Les détails sont modifiés. Lis les chiffres comme une direction, pas comme un benchmark.

Ce que tu vas apprendre

• Pourquoi le processus documenté n'est jamais le vrai
• Les quatre seaux dans lesquels range chaque étape d'un processus
• Pourquoi les agents ont leur place dans ton CRM ou ton ERP, pas à côté
• Ce que livre un premier projet, en chiffres

Un agent ne vaut que la carte du processus sur laquelle il repose

C'est la thèse. La version de Moza est plus courte : don't apply AI. L'IA ne s'applique pas comme une couche de peinture. Si personne n'a écrit comment le travail circule réellement, l'agent automatise une supposition.

La carte vient donc en premier, l'agent ensuite. Le reste de cet article en est la preuve, de l'origine du problème jusqu'aux chiffres.

Pourquoi la plupart des pilotes d'IA s'enlisent-ils ?

La plupart des pilotes d'IA s'enlisent parce qu'ils automatisent le processus documenté, et le processus documenté n'est pas le vrai. Le vrai vit dans les têtes, dans les exceptions et dans des boucles que personne n'a dessinées. Un agent construit sur la version officielle échoue à la première exception.

Le schéma est bien mesuré. Le rapport GenAI Divide du MIT montre qu'environ 95% des pilotes d'IA générative en entreprise ne produisent aucun retour. Les auteurs mettent en cause l'écart entre les outils et les vrais flux de travail, pas la qualité des modèles. Dans une enquête Celonis auprès de 1 620 dirigeants, y compris en Allemagne, en Autriche et en Suisse, 89% disent que l'IA doit comprendre comment leurs processus fonctionnent pour donner des résultats.

Le premier exemple de Moza rend la chose concrète. Un éditeur de logiciels coté, avec 5 milliards de dollars de chiffre d'affaires, avait documenté son processus de devis en 7 étapes bien propres. Son équipe a lancé du process mining sur le CRM.

Le vrai processus comptait 20 étapes et 7 boucles. 61% des demandes revenaient au départ. Le juridique en renvoyait 12%. Dans 30% des cas, un nouveau devis devait repasser par la validation.

Rien de tout cela n'était sur papier. Dans chaque entreprise qu'il voit, quelqu'un est là depuis 20 ans et s'en occupe, tout simplement. J'appelle ça le contexte fragmenté : le produit connaît une partie, les ventes une autre, et chaque agent repart de zéro. C'est pour la même raison qu'un entonnoir CRM n'est pas ton vrai processus de vente.

Cela explique aussi pourquoi tant d'entreprises du DACH restent bloquées à la première étape. En Allemagne, 57% des entreprises utilisent désormais l'IA, mais 9 sur 10 disent n'en être qu'au début.

Comment un forward deployed engineer cartographie un processus

Je compte cinq étapes dans sa méthode. L'essentiel du travail se fait avant que quiconque construise un agent.

1. Interroge les gens. Commence par un département. Demande pourquoi chaque étape existe, qui décide vraiment, quelle étape relève du théâtre et à quelle fréquence surviennent les exceptions.
2. Exploite les systèmes de référence. Son équipe fait tourner des agents de process mining sur le CRM ou l'ERP pendant trois à quatre semaines. Quels enregistrements arrivent, qui les corrige, où vont-ils ensuite ?
3. Lis ce qui existe. Ancienne documentation, fils de discussion, tableurs. Parfois dépassés, parfois bons.
4. Trie chaque étape dans l'un des quatre seaux. Supprime-la. Transforme-la en code simple, quand c'est une règle si-alors. Confie-la à un agent, quand elle demande du jugement et que tu as un historique pour apprendre. Ou garde-la comme décision humaine, quand une erreur coûte cher.
5. Mesure avant de construire. Temps de cycle, taux d'exceptions, coût par dossier. Sans valeur de départ, tu ne pourras rien prouver plus tard.

Aucune source ne suffit seule. Une grande entreprise a dix ans d'historique CRM. Une petite a surtout des têtes. Les entretiens sans les données donnent des opinions, et les données sans les entretiens donnent la moitié du tableau.

La valeur se trouve à l'étape 4. Moza cite Michael Hammer, dont l'article de 1990 dans la Harvard Business Review demandait aux entreprises de repenser leurs processus au lieu de les automatiser.

Ce qu'il retient de Hammer : accélère chacune des 20 étapes, et le processus n'ira peut-être pas plus vite, parce que le temps se trouve entre les étapes. C'est le passage de relais entre équipes. Aucun agent ne répare un passage de relais qui ne devrait pas exister.

La répartition est moins chargée en agents que le battage ne le laisse croire. Une description de la méthode de Varick donne une refonte type : sur 8 étapes, 4 sont automatisées, 3 gardent un humain dans la boucle et 1 reste manuelle.

Son calendrier est court. 4 semaines pour l'audit et les premiers proofs of concept. 4 semaines pour construire. Puis une comparaison avant-après 3 et 6 mois plus tard. La carte terminée a un second rôle : c'est le brief de l'agent, de la même façon qu'un bon ticket est un conteneur de contexte pour les agents.

Dois-je remplacer mon CRM ou mon ERP pour des agents IA ?

Non. Les agents qui fonctionnent tournent dans les systèmes que tu as déjà. Ils lisent et écrivent dans ton CRM ou ton ERP, et ils demandent la validation dans l'outil de chat que ton équipe utilise déjà. Un pitch de migration perd la salle et retarde le résultat de plusieurs années.

Moza est direct sur ce point. Des clients lui parlent de changements d'ERP qui ont pris plusieurs années et plusieurs millions de dollars, dans un cas environ 10 millions. Personne ne veut un second tour. Ses agents exploitent donc le CRM et agissent dans le CRM, et une validation humaine est un message dans Slack. Le personnel n'a besoin d'aucune formation, parce que rien ne change à l'écran.

Le système de référence devient ainsi le véritable outil. Il contient l'historique dont un agent a besoin pour juger un dossier. Ce que tu veux en tirer, c'est du contexte, pas seulement des données.

Deux autres choix tirés de l'épisode. D'abord, il distingue les assistants de chat des agents d'arrière-plan. Un agent d'arrière-plan fait le même travail à chaque fois sans qu'on le lui demande et ne te sollicite que lorsqu'il a besoin d'une décision. Son estimation : un assistant donne un output 10 à 20% plus rapide, un agent d'arrière-plan 70 à 80%.

Ensuite, la plupart des étapes n'ont pas besoin du modèle le plus récent. Il teste chaque workflow contre plusieurs modèles et choisit par workflow.

Un point pour les lecteurs du DACH. Il n'a vu aucune demande de matériel sur site chez ses clients, banques et groupes pharmaceutiques compris. Sa société fait passer les modèles par les grandes plateformes cloud, avec des conditions qui excluent l'entraînement et la conservation des données.

Dois-tu recruter un forward deployed engineer ?

Probablement pas au début. Un forward deployed engineer réunit trois compétences : comprendre comment le travail se fait, livrer du code de production avec audit et sécurité, et savoir ce qu'on peut confier à un modèle. Tu peux les développer dans ta propre équipe en commençant par un seul processus.

Moza dit que les personnes fortes dans les trois sont rares. La plupart en ont une ou deux. Une quatrième s'ajoute par-dessus : tout expliquer à la direction.

• Le processus. Comment fonctionnent vraiment Salesforce, NetSuite ou Dynamics, et à quoi la fonction devrait-elle ressembler ?
• Le code. Des agents qui appellent ces systèmes, avec une piste d'audit, de la gouvernance et de la sécurité. C'est de l'agentic engineering avec discipline, pas une démo.
• La couche IA. Quel modèle pour quelle étape, des evals pour le tester, et un rollback quand un agent se trompe.

Son exercice de départ dure quatre jours et prend ta propre vie comme cas de test. Liste chaque app qui contient tes affaires, et laquelle l'emporte quand deux se contredisent. Choisis 20 choses que tu as faites la semaine dernière.

Écris l'une d'elles étape par étape, avec chaque exception. Trie les étapes dans les quatre seaux. Il donnerait le même playbook à une entreprise qui veut former ses propres FDE.

Mon ajout : fais-le ensuite pour un vrai processus dans une équipe. Un processus, un responsable.

Que livre le reengineering des processus, en chiffres ?

Dans le cas de comptabilité fournisseurs de l'épisode, 17 étapes de processus sont devenues 7. Le temps de cycle est passé de 24 jours à 6. Le coût par facture est tombé de 31 à 6 dollars. La part des factures qui passent sans exception est montée de 18% à 87%.

Relis ce dernier chiffre. Avant le projet, 82% des factures prenaient une voie d'exception. Ce n'est pas un agent qui manque. C'est un processus cassé.

Moza le dit lui-même : ce gain relève du reengineering des processus, et tout ne tient pas aux agents. La cartographie a pris deux à trois semaines d'entretiens et de process mining.

Personne ne conçoit un tel processus. Il pousse tout seul. Dans un autre exemple, cinq sociétés de portefeuille sur le même ERP faisaient tourner le même type de processus en 12, 9, 15, 18 et 13 étapes.

Une réserve. Ce sont les chiffres d'un prestataire, issus de clients isolés, avec des détails modifiés. Confronte-les donc à un cas publié.

Moza renvoie à Thrive Holdings, qui rachète des cabinets comptables et des sociétés de services informatiques et y installe des ingénieurs. Le groupe détient plus de 70 sociétés. Ses agents fiscaux ont traité plus de 7 000 déclarations avec 98% de précision et réduit le temps de préparation de plus de 30%. Autre société, même schéma : des ingénieurs dans l'activité, le processus d'abord.

Où ça marche, où ça ne marche pas, et le piège

✅ Ce qui brille. Les flux à fort volume et à nombreuses règles, avec un système de référence et des années d'historique : factures, validations de devis, rapprochements. Il y a un responsable clair, une valeur de départ mesurable et un résultat visible en quelques mois.

❌ Ce qui ne brille pas. Les petites entreprises où rien n'est écrit et où il n'y a pas de système de référence. Il n'y a pas d'historique à exploiter, donc les entretiens portent tout. Les agents assistants personnels ne brillent pas non plus. Moza ne voit pas encore de gouvernance pour leur confier des processus d'entreprise.

⚠️ Attention. Garde des humains sur les validations et les paiements. Un agent qui paie chaque facture qui a l'air authentique est un cadeau pour les fraudeurs.

Et applique une décote aux calculs de marge des roll-ups IA. Une étude de Stanford et BetterUp montre que 40% des salariés reçoivent des productions d'IA qui ont l'air soignées mais manquent de substance. Le coût : environ 186 dollars par personne et par mois. Gartner s'attend à ce que plus de 40% des projets d'agentic AI soient arrêtés d'ici fin 2027. Les raisons : des coûts en hausse, une valeur floue ou un contrôle des risques faible.

Revenons au million. Personne ne le paie pour connaître les agents. Si quelqu'un le paie, c'est pour connaître le processus.

Les quatre seaux décrivent simplement la façon dont les équipes devraient travailler, selon moi. J'appelle ça Get Multiplayer : Les humains fixent les objectifs, décident et valident. Les agents préparent et prennent en charge les tâches répétitives. Objectifs communs et contexte commun tiennent le travail ensemble.

La carte du processus est ce contexte commun, mis par écrit. L'IA ne répare pas un processus flou. Elle le rend plus rapide et plus bruyant.

Si tu veux une construction de ce genre par numéro, abonne-toi à la newsletter The Science of GTM.