Forward Deployed Engineering in Practice: What Actually Works

Published by Florian Nègre · April 2026 · 9 min read

Most accounts of the FDE model describe what the role is supposed to do. This article describes what it actually does: the first 90 days of an enterprise AI deployment, the failure modes that appear before anyone admits the engagement is in trouble, and the specific decisions that separate deployments that reach production from those that stay in proof-of-concept for a year.

Why most enterprise AI deployments do not reach production

The gap between "we signed an enterprise AI contract" and "we have something running in production" is where most deployments fail. It is not a technical gap. The technology works. It is an operational gap: the enterprise client's environment, data, processes, and organizational dynamics were not accounted for during the sales cycle, and there is no one with the right combination of technical skill and client presence to bridge them.

85% of enterprise AI proofs-of-concept that do not reach production within 6 months never reach production at all

Day 45 the point at which most FDE engagement failures become visible, if someone is looking for them

3 the number of integration blockers that determine whether a deployment succeeds, in the majority of enterprise accounts

What the first 90 days of an FDE engagement actually look like

The 90-day structure is not arbitrary. It reflects the operational rhythm of enterprise deployment: discovery takes longer than expected, integration problems surface in week three, and the window to establish momentum before organizational inertia sets in closes around day 60.

D1-30

Environment mapping and first working prototype

The FDE maps the client's technical environment: data sources, APIs, infrastructure access, existing workflows, and the people who actually control each system. They identify the three to five integration blockers that will determine deployment success, and they build something running on real client data by day 30. Not a demo. Something in the client's environment, on their data, that shows the core value proposition working.

D30-60

Integration build and first production workflow

The FDE builds the integrations identified in the first 30 days. This is where the real work happens: connecting to legacy systems, handling data quality issues that were not visible in the sales process, working around access control limitations, and managing the organizational dynamics of a client team that may be skeptical of the new system. The goal is one workflow in production with real users by day 60.

D60-90

Adoption drive and expansion planning

With something in production, the FDE shifts focus to adoption: training users, resolving friction points, iterating on the workflow based on actual usage patterns, and identifying the internal champions who will carry the system after the FDE's intensity decreases. They also scope the next phase of deployment, which is where expansion revenue comes from, and hand that scope to Sales with enough technical detail to close it.

D90+

Steady state or structured handover

By day 90, the FDE should either be moving to a steady-state lower-intensity engagement with the account, or executing a structured handover to Customer Success. What should not happen: the FDE remaining at full intensity indefinitely because no internal capability was built. That is a sign the engagement was designed around FDE dependency rather than client self-sufficiency.

The four failure modes that appear before anyone admits there is a problem

FDE engagement failures rarely announce themselves. They accumulate through a sequence of small decisions and delays that individually seem manageable and collectively make the engagement unrecoverable.

Failure mode	What it looks like	What it actually means
Data access delay	Still waiting for production data access at day 30. Working on synthetic data or anonymized exports.	The client organization is not ready for deployment. The blocker is not technical, it is organizational. The FDE needs to escalate to the executive sponsor, not wait.
Scope expansion	The client keeps adding requirements. The FDE is accommodating each request to maintain the relationship.	The original scope was not agreed at the right level of authority. Every new requirement added without a timeline adjustment is a step toward a deployment that satisfies no one fully.
Sandbox permanence	At day 60, the deployment is still in a test environment. Production is always "next month."	There is no internal champion with enough authority to push a production deployment through the client's change management process. This is a political problem, not a technical one.
Shadow CSM	The FDE is spending more than 30% of their time on account management, relationship maintenance, and coordination rather than building.	The engagement is missing a Customer Success function. The FDE is filling the gap because no one else is. This is expensive and unsustainable.

The internal champion problem

The single variable that most reliably predicts whether an FDE engagement succeeds is not the quality of the FDE, the complexity of the integration, or the state of the client's data. It is whether there is an internal champion at the client who has both the authority to make decisions and the motivation to see the deployment succeed.

Without that person, the FDE is building systems that no one inside the client organization will defend, maintain, or expand. Every deployment decision requires another round of stakeholder alignment. Every production push requires a committee. The FDE's technical work is sound, but it has no organizational traction.

What to do when there is no internal champion: do not assume one will emerge. Identify the person who has the most to gain from a successful deployment, whether that is a department head who needs to show efficiency gains, a CTO who needs to demonstrate AI capability to the board, or a team lead who is drowning in manual work. Make their success case explicit and give them the technical narrative to carry internally. Champions are built, not found.

The data quality problem: what actually works

Every FDE encounters data quality problems. The data was clean in the demo environment. The production data is not. The question is not how to wait for the data to be cleaned. The question is how to get to production despite the data quality, and then use production usage to drive data quality improvement from the inside.

Handling data quality blockers in practice

Data quality is poor but one specific dataset is clean enough to deploy on

→

Deploy on the clean dataset first, expand to others as quality improves

Data is in the right place but access controls prevent the FDE from connecting to it

→

Escalate immediately to the executive sponsor, not the IT team. This is a priority decision, not a technical request.

Data requires transformation before it can be used, and the client's team needs to do the transformation

→

Define the minimum transformation required, build the specification, and give the client's team a clear target with a timeline, not an open-ended request

Data quality is systemically poor with no clear remediation path in the near term

→

Restructure the deployment scope around the use case with the lowest data quality dependency and document the gap formally

What separates deployments that expand from those that stay static

The FDE's commercial value is not just getting the product into production. It is structuring the first deployment so that expansion is the obvious next step. The deployments that expand consistently share two characteristics: the first use case was chosen for visibility (something stakeholders can see and measure), and the FDE documented the second use case before the first was live.

The deployments that stay static share a different characteristic: the first use case was chosen for technical ease rather than visibility, the stakeholders who approved the contract are not seeing the deployment results, and no one has scoped what comes next because the FDE was focused entirely on the current deployment.

The expansion setup: at day 45, while the first workflow is being finalized for production, the FDE should already be having conversations with the client about what they would deploy next if the first use case succeeds. That conversation serves two purposes: it plants the expansion seed before the first deployment is complete, and it gives the FDE visibility into whether the client sees value beyond the initial contract.

Frequently asked questions

What does an FDE actually do in the first 30 days of an engagement?

In the first 30 days, an FDE maps the client's existing technical environment: data sources, APIs, infrastructure, access controls, and the workflows that the deployed product is supposed to integrate with. They identify the three to five integration blockers that will determine whether the deployment succeeds, and they build a working proof-of-concept using real client data. By day 30, there should be something running in the client environment, even if limited, that demonstrates the core value proposition on real data.

Why do most enterprise AI deployments fail to reach production?

The three most common reasons are: data quality problems that were not identified during the sales cycle, integration complexity with existing systems that was underestimated, and lack of a designated internal champion with both authority and technical understanding to drive adoption. The FDE role directly addresses all three, but only if the engagement starts with a realistic assessment of these risks rather than an optimistic implementation timeline inherited from the sales process.

How does an FDE handle a client whose data is too messy to deploy on?

The FDE's job in that situation is not to clean the data. It is to define the minimum data quality threshold required for the first production use case, scope a data preparation workstream with the client's team, and sequence the deployment around data that is already clean enough rather than waiting for a complete data remediation. An FDE who stops deployment because the data is not perfect is not doing their job.

What makes an FDE engagement fail?

The most common causes of FDE engagement failure are: no internal champion with decision-making authority, scope that was defined during the sales cycle without FDE input, a client organization that is not operationally ready to change its workflows, and an FDE who was not given access to production systems early enough. Most failures are visible within the first 45 days. If the FDE does not have access to real data and real systems by day 30, the engagement is already at risk.

What is the difference between a successful FDE engagement and a failed one at 90 days?

At 90 days, a successful FDE engagement has at least one workflow running in production with real users. A failed engagement at 90 days is still in the assessment phase, waiting for data access, waiting for stakeholder alignment, or still running on synthetic data in a sandbox environment. The 90-day mark is a hard diagnostic: if nothing is in production, the engagement needs to be restructured, not extended.

Related resources on this site

Your AI deployment is stuck between proof-of-concept and production. The blockers are usually visible within a single diagnostic session. Let's identify them.

Book a deployment diagnostic

Last updated: April 2026. Enterprise AI deployment practice is evolving rapidly. This guide reflects patterns observed across deployments completed through Q1 2026.

Forward Deployed Engineering en pratique : ce qui fonctionne vraiment

Publié par Florian Nègre · Avril 2026 · 9 min de lecture

La plupart des descriptions du modèle FDE expliquent ce que le rôle est censé faire. Cet article décrit ce qu'il fait réellement : les 90 premiers jours d'un déploiement AI entreprise, les modes d'échec qui apparaissent avant que personne n'admette que l'engagement est en difficulté, et les décisions spécifiques qui séparent les déploiements qui atteignent la production de ceux qui restent en proof-of-concept pendant un an.

Pourquoi la plupart des déploiements AI entreprise n'atteignent pas la production

L'écart entre "nous avons signé un contrat AI entreprise" et "nous avons quelque chose en production" est là où la plupart des déploiements échouent. Ce n'est pas un écart technique. La technologie fonctionne. C'est un écart opérationnel : l'environnement, les données, les processus et les dynamiques organisationnelles du client entreprise n'ont pas été pris en compte pendant le cycle de vente, et il n'y a personne avec la bonne combinaison de compétences techniques et de présence client pour les combler.

85% des preuves de concept AI entreprise qui n'atteignent pas la production en 6 mois ne l'atteignent jamais

Jour 45 le moment où la plupart des échecs d'engagement FDE deviennent visibles, si quelqu'un les cherche

3 le nombre de blocages d'intégration qui déterminent si un déploiement réussit, dans la majorité des comptes entreprise

À quoi ressemblent vraiment les 90 premiers jours d'un engagement FDE

J1-30

Cartographie de l'environnement et premier prototype fonctionnel

L'FDE cartographie l'environnement technique du client : sources de données, APIs, accès à l'infrastructure, workflows existants, et les personnes qui contrôlent réellement chaque système. Il identifie les trois à cinq blocages d'intégration qui détermineront le succès du déploiement, et construit quelque chose fonctionnant sur des données client réelles avant le jour 30. Pas une démo. Quelque chose dans l'environnement du client, sur ses données, qui démontre la proposition de valeur centrale.

J30-60

Construction des intégrations et premier workflow en production

L'FDE construit les intégrations identifiées dans les 30 premiers jours. C'est là que le vrai travail se fait : connexion aux systèmes legacy, gestion des problèmes de qualité de données non visibles pendant le processus de vente, contournement des limitations de contrôle d'accès, et gestion des dynamiques organisationnelles d'une équipe client qui peut être sceptique. L'objectif est un workflow en production avec de vrais utilisateurs avant le jour 60.

J60-90

Conduite de l'adoption et planification de l'expansion

Avec quelque chose en production, l'FDE déplace son attention vers l'adoption : formation des utilisateurs, résolution des points de friction, itération sur le workflow en fonction des patterns d'utilisation réels, et identification des champions internes qui porteront le système quand l'intensité de l'FDE diminuera. Il cadre également la phase suivante du déploiement et la transmet à la vente avec suffisamment de détail technique pour la conclure.

J90+

État stable ou passation structurée

Au jour 90, l'FDE devrait soit passer à un engagement de moindre intensité avec le compte, soit exécuter une passation structurée vers le Customer Success. Ce qui ne devrait pas se produire : l'FDE restant à pleine intensité indéfiniment parce qu'aucune capacité interne n'a été construite. C'est un signe que l'engagement a été conçu autour de la dépendance à l'FDE plutôt que de l'autonomie du client.

Les quatre modes d'échec qui apparaissent avant que personne n'admette le problème

Mode d'échec	Ce que ça ressemble	Ce que ça signifie réellement
Délai d'accès aux données	Toujours en attente d'accès aux données de production au jour 30. Travail sur des données synthétiques ou des exports anonymisés.	L'organisation client n'est pas prête pour le déploiement. Le blocage n'est pas technique, il est organisationnel. L'FDE doit escalader vers le sponsor exécutif, pas attendre.
Expansion du périmètre	Le client continue d'ajouter des exigences. L'FDE accommode chaque demande pour maintenir la relation.	Le périmètre initial n'a pas été accepté au bon niveau d'autorité. Chaque nouvelle exigence ajoutée sans ajustement de délai est un pas vers un déploiement qui ne satisfait personne complètement.
Permanence du sandbox	Au jour 60, le déploiement est toujours dans un environnement de test. La production est toujours "le mois prochain."	Il n'y a pas de champion interne avec suffisamment d'autorité pour pousser un déploiement en production à travers le processus de gestion du changement du client. C'est un problème politique, pas technique.
CSM fantôme	L'FDE passe plus de 30% de son temps sur la gestion du compte et la coordination plutôt que sur la construction.	L'engagement manque d'une fonction Customer Success. L'FDE comble le vide parce que personne d'autre ne le fait. C'est coûteux et insoutenable.

Le problème du champion interne

La variable qui prédit le plus fiablement si un engagement FDE réussit n'est pas la qualité de l'FDE, la complexité de l'intégration, ou l'état des données du client. C'est s'il y a un champion interne chez le client qui a à la fois l'autorité pour prendre des décisions et la motivation pour voir le déploiement réussir.

Que faire quand il n'y a pas de champion interne : n'attendez pas qu'un champion émerge. Identifiez la personne qui a le plus à gagner d'un déploiement réussi, qu'il s'agisse d'un chef de département qui doit montrer des gains d'efficacité, d'un CTO qui doit démontrer une capacité AI au board, ou d'un responsable d'équipe noyé dans du travail manuel. Rendez leur cas de succès explicite et donnez-leur le narratif technique à porter en interne. Les champions se construisent, ils ne se trouvent pas.

Le problème de qualité des données : ce qui fonctionne vraiment

Gérer les blocages de qualité de données en pratique

La qualité des données est faible mais un dataset spécifique est suffisamment propre pour déployer

→

Déployer d'abord sur le dataset propre, étendre aux autres à mesure que la qualité s'améliore

Les données sont au bon endroit mais les contrôles d'accès empêchent l'FDE de se connecter

→

Escalader immédiatement vers le sponsor exécutif, pas l'équipe IT. C'est une décision de priorité, pas une demande technique.

Les données nécessitent une transformation et l'équipe du client doit la faire

→

Définir la transformation minimale requise, construire la spécification, et donner à l'équipe du client une cible claire avec un délai, pas une demande ouverte

La qualité des données est systémiquement faible sans chemin de remédiation clair à court terme

→

Restructurer le périmètre du déploiement autour du cas d'usage avec la plus faible dépendance à la qualité des données et documenter formellement l'écart

Ce qui sépare les déploiements qui s'étendent de ceux qui restent statiques

La valeur commerciale de l'FDE n'est pas seulement de mettre le produit en production. C'est de structurer le premier déploiement de sorte que l'expansion soit l'étape suivante évidente. Les déploiements qui s'étendent partagent deux caractéristiques : le premier cas d'usage a été choisi pour sa visibilité, et l'FDE a documenté le deuxième cas d'usage avant que le premier soit en production.

La mise en place de l'expansion : au jour 45, pendant que le premier workflow est finalisé pour la production, l'FDE devrait déjà avoir des conversations avec le client sur ce qu'ils déploieraient ensuite si le premier cas d'usage réussit. Cette conversation sert deux objectifs : elle plante la graine d'expansion avant que le premier déploiement soit terminé, et elle donne à l'FDE une visibilité sur si le client voit de la valeur au-delà du contrat initial.

Questions fréquentes

Que fait réellement un FDE dans les 30 premiers jours d'un engagement ?

Dans les 30 premiers jours, un FDE cartographie l'environnement technique existant du client : sources de données, APIs, infrastructure, contrôles d'accès, et les workflows que le produit déployé est censé intégrer. Il identifie les trois à cinq blocages d'intégration qui détermineront si le déploiement réussit, et construit une preuve de concept fonctionnelle avec des données client réelles. Au jour 30, quelque chose doit tourner dans l'environnement client, même limité, qui démontre la proposition de valeur sur des données réelles.

Pourquoi la plupart des déploiements AI entreprise n'atteignent pas la production ?

Les trois raisons les plus courantes sont : des problèmes de qualité de données non identifiés pendant le cycle de vente, une complexité d'intégration avec les systèmes existants sous-estimée, et l'absence d'un champion interne désigné avec à la fois l'autorité et la compréhension technique pour conduire l'adoption. Le rôle FDE adresse directement les trois, mais seulement si l'engagement commence par une évaluation réaliste de ces risques plutôt qu'un calendrier d'implémentation optimiste hérité du processus de vente.

Comment un FDE gère-t-il un client dont les données sont trop désordonnées pour déployer dessus ?

Le travail de l'FDE dans cette situation n'est pas de nettoyer les données. C'est de définir le seuil minimum de qualité de données requis pour le premier cas d'usage en production, de cadrer un workstream de préparation des données avec l'équipe du client, et de séquencer le déploiement autour des données déjà suffisamment propres plutôt qu'attendre une remédiation complète. Un FDE qui arrête le déploiement parce que les données ne sont pas parfaites ne fait pas son travail.

Qu'est-ce qui fait échouer un engagement FDE ?

Les causes les plus courantes d'échec d'engagement FDE sont : absence de champion interne avec autorité décisionnelle, périmètre défini pendant le cycle de vente sans input FDE, organisation cliente non prête à changer ses workflows, et FDE qui n'a pas eu accès aux systèmes de production assez tôt. La plupart des échecs sont visibles dans les 45 premiers jours. Si l'FDE n'a pas accès aux données réelles et aux systèmes réels au jour 30, l'engagement est déjà à risque.

Quelle est la différence entre un engagement FDE réussi et un échec à 90 jours ?

À 90 jours, un engagement FDE réussi a au moins un workflow en production avec de vrais utilisateurs. Un engagement raté à 90 jours est toujours en phase d'évaluation, en attente d'accès aux données, en attente d'alignement des parties prenantes, ou toujours sur des données synthétiques dans un environnement sandbox. Le marqueur des 90 jours est un diagnostic dur : si rien n'est en production, l'engagement a besoin d'être restructuré, pas prolongé.

Ressources associées sur ce site

Votre déploiement AI est bloqué entre la preuve de concept et la production. Les blocages sont généralement visibles en une seule session de diagnostic. Identifions-les.

Réserver un diagnostic de déploiement

Dernière mise à jour : avril 2026. Les pratiques de déploiement AI entreprise évoluent rapidement. Ce guide reflète les patterns observés sur des déploiements complétés jusqu'au T1 2026.

Before you go...