Architecture d'Entreprise
Agents livrés par l'éditeur : qui en garde la main ?
Gartner prévoit que 70 % des entreprises abandonneront d'ici 2028 les agents construits pour elles par les équipes de leur fournisseur. La cause n'est pas la technologie : c'est l'absence de transfert.
Le 29 septembre 2026, Gartner a publié une prévision qui mérite d'être lue pour sa cause plus que pour son chiffre : d'ici 2028, 70 % des entreprises abandonneront les systèmes d'IA agentique construits pour elles par les équipes d'ingénierie déployées de leur fournisseur — le forward-deployed engineering (FDE) —, prises au piège de coûts croissants et incapables de les faire évoluer seules.
De quoi parle-t-on
Le modèle FDE consiste à envoyer les ingénieurs de l'éditeur chez le client pour construire, sur mesure, ce que le produit ne fait pas encore. Il est efficace : il livre vite, il contourne les files d'attente internes, il produit une démonstration convaincante en quelques semaines. C'est précisément ce qui le rend dangereux — la vitesse initiale masque l'absence de transfert.
Le mécanisme de l'échec
Il n'a rien d'une surprise technologique, et il est reproductible d'un dossier à l'autre :
- Le système n'existe que dans la tête des ingénieurs partis. Pas de documentation d'architecture, pas de décisions écrites, pas de tests qui expliquent l'intention.
- Le périmètre dérive. Chaque nouveau besoin passe par un avenant, parce que l'équipe interne ne sait pas intervenir.
- La propriété intellectuelle n'a pas été tranchée au départ, et le devient quand l'entreprise veut reprendre la main.
- Le coût devient récurrent sans devenir produit. Gartner note que, d'ici 2028, moins de 20 % des missions FDE transformeront les besoins récurrents des clients en capacités intégrées au produit standard de l'éditeur. Autrement dit, l'entreprise finance du développement spécifique qu'elle paiera encore l'année suivante.
La recommandation de l'analyste de Gartner cité dans le communiqué, Mukul Saha, va dans ce sens : une mission FDE réussie se joue sur la structure de l'engagement — périmètre, incitations, gouvernance, propriété, co-responsabilité du projet, transfert de connaissances et stratégie de sortie définie dès le premier jour.
Ce n'est pas un problème d'IA
C'est le schéma classique de l'intégrateur qui construit un système que personne ne sait reprendre, appliqué à une technologie nouvelle. Trois choses l'aggravent dans le cas des agents. D'abord, la surface de dépendance est plus large : modèle, orchestration, outils, mémoire, garde-fous. Ensuite, le comportement n'est pas déterministe : reprendre un agent suppose de comprendre pourquoi il décide, pas seulement ce qu'il exécute. Enfin, le coût d'exploitation est variable et croît avec l'usage, comme nous le détaillions à propos du coût par tâche.
Les six points à écrire avant de signer
- À qui appartient ce qui est produit — code, invites, jeux d'évaluation, données d'entraînement ou d'ajustement — et sous quelle licence.
- Le critère de transfert, formulé comme un test et non comme une intention : une personne de l'équipe interne modifie une capacité et la met en production, seule, avant la fin de la mission.
- Les décisions d'architecture écrites au fil de l'eau, pas un document de fin de projet rédigé en une semaine.
- Le jeu d'évaluation qui dit si l'agent fait correctement son travail. Il vaut davantage que le code : c'est lui qui permet de changer de modèle ou de fournisseur sans tout revérifier à la main.
- La sortie : ce qui se passe si l'on arrête, quelles données sont restituées, dans quel format, et sous quel délai. La réversibilité se décide au contrat, pas à la rupture.
- La valeur mesurée, avec un indicateur métier défini avant le démarrage. Un agent qu'on garde parce qu'il a coûté cher n'est pas un succès.
Ce que je recommande en pratique
Faire appel à des ingénieurs de l'éditeur est souvent le bon choix : ils connaissent le produit mieux que quiconque et évitent des mois d'errance. Ce qui doit changer, c'est la façon de les employer. Les faire travailler avec une équipe interne plutôt qu'à sa place ; borner la mission à une capacité livrée et transférée, pas à un périmètre ouvert ; et accepter un démarrage un peu plus lent pour une autonomie réelle à six mois.
C'est la même logique que celle qui distingue une direction technique de passage d'un renfort d'exécution : la question n'est pas qui écrit le code, mais qui reste capable de le faire évoluer (voir Fractional CTO ou temps plein). Et c'est la raison pour laquelle, dans les projets d'agents, je recommande de traiter la gouvernance et l'architecture avant la démonstration — c'est l'objet de l'article sur les agents en production.
- Gartner prévoit 70 % d'abandons d'ici 2028 pour les agents construits par les ingénieurs de l'éditeur.
- La cause est l'absence de transfert : documentation, propriété, autonomie de l'équipe interne.
- Moins de 20 % des missions FDE deviendront des capacités du produit standard : le spécifique reste spécifique.
- Le critère de réussite se teste — une personne interne met une évolution en production, seule, avant la fin de la mission.
- Le jeu d'évaluation vaut plus que le code : c'est lui qui rend le changement de modèle possible.
Sources
À lire aussi
Cet enjeu vous concerne ?
Un premier échange gratuit pour l'évaluer ensemble.