Agents IA : 62 % expérimentent, 23 % déploient
Entre l'entreprise qui teste un agent IA et celle qui en a mis un en production sur une fonction complète, il y a un écart de trente-neuf points. Cet écart ne s'explique presque jamais par la technologie. Il s'explique par ce qui n'a pas été préparé avant de lancer le projet.
Les chiffres, sans filtre
Les études publiées au premier semestre 2026 dessinent toutes la même courbe. Environ 62 % des entreprises interrogées déclarent expérimenter des agents IA. Elles ne sont plus que 23 % à en avoir déployé à l'échelle sur au moins une fonction. Et moins de 10 % sur plusieurs fonctions.
Autrement dit : deux tiers des entreprises ont commencé, un quart a abouti, une sur dix a généralisé. L'expérimentation est devenue la norme, le déploiement reste l'exception.
Les analyses de Gartner, McKinsey et BCG situent le taux d'échec des projets entre 70 et 85 % selon le périmètre mesuré. Une étude du MIT publiée à l'été 2025 allait plus loin : 95 % des projets d'IA générative n'atteignaient jamais un déploiement à l'échelle avec un impact mesurable. Dans le même temps, Gartner anticipe que 40 % des applications d'entreprise embarqueront des agents d'ici fin 2026, tout en estimant que 88 % des pilotes n'aboutiront pas.
Ces deux prédictions ne se contredisent pas. Les agents vont se généraliser parce que les éditeurs les intègrent dans leurs produits. Les projets d'agents montés en interne, eux, continueront de majoritairement échouer. Ce ne sont pas les mêmes trajectoires.
Là où ça marche vraiment
Il existe des cas où les agents IA produisent un retour sur investissement documenté et reproductible. Trois se détachent nettement.
| Domaine | Retour observé sur 12 mois | Pourquoi ça fonctionne |
|---|---|---|
| Support client | Environ 3,2 fois la mise | Volume élevé, questions répétitives, base de connaissance déjà écrite |
| Assistance aux équipes techniques | Environ 2,8 fois la mise | Résultat vérifiable immédiatement par l'utilisateur lui-même |
| Back-office financier | Environ 1,6 fois la mise | Processus déjà formalisé, règles explicites, données structurées |
Le point commun de ces trois cas n'est pas le secteur, ni la taille de l'entreprise, ni le modèle utilisé. C'est une combinaison de trois caractéristiques : un périmètre délimité, un résultat mesurable, et une infrastructure numérique qui existait déjà avant l'arrivée de l'agent.
Aucun de ces succès ne repose sur un agent censé « améliorer la productivité de l'entreprise ». Tous reposent sur un agent qui fait une chose précise, dont on sait dire si elle est bien faite.
Les quatre causes réelles de l'écart
Nous retrouvons systématiquement les mêmes points de blocage, et aucun n'est de nature technologique.
- L'intégration a été sous-estimée. La démonstration tourne sur un jeu de données propre. La production tourne sur le CRM réel, avec ses doublons, ses champs vides et ses conventions de nommage qui ont changé trois fois en cinq ans. Le travail d'intégration représente souvent 70 % de l'effort total, et il est presque toujours budgété comme s'il en représentait 20 %.
- Le périmètre n'a jamais été borné. Un agent à qui l'on demande de « gérer les demandes clients » échouera. Un agent à qui l'on demande de « qualifier les demandes entrantes en trois catégories et router vers la bonne boîte » réussira. La différence n'est pas la difficulté, c'est la possibilité de dire si c'est fait ou non.
- Personne n'est propriétaire du sujet. Le projet est porté par la direction, construit par un prestataire, utilisé par une équipe métier qui n'a pas été consultée. Au premier écart de comportement de l'agent, personne ne se sent responsable de l'ajuster. L'outil est abandonné en trois semaines.
- Aucun indicateur de succès n'a été fixé avant le lancement. Sans critère défini à l'avance, l'évaluation devient une impression. Et l'impression sur un outil qui se trompe une fois sur vingt est toujours négative, même quand le gain net est largement positif.
Un pilote qui échoue révèle rarement un problème de modèle. Il révèle un problème de préparation.
Le test des quatre questions
Avant d'engager un projet d'agent IA, nous posons quatre questions au client. Si l'une reste sans réponse claire, nous recommandons de traiter ce point d'abord.
- Pouvez-vous décrire en une phrase ce que l'agent doit faire, et en une phrase comment on saura qu'il l'a bien fait ?
- Les données dont l'agent a besoin sont-elles accessibles aujourd'hui, sans projet informatique préalable ?
- Qui, nommément, ajustera le comportement de l'agent quand il se trompera ? Cette personne a-t-elle du temps alloué pour le faire ?
- Que se passe-t-il si l'agent produit un résultat faux ? Quelqu'un le voit-il avant que ça ne sorte de l'entreprise ?
Cette dernière question est la plus discriminante. Un agent qui envoie directement des réponses au client sans relecture demande un niveau de fiabilité que peu de cas d'usage justifient. Un agent qui prépare une réponse qu'un humain valide en dix secondes offre 80 % du gain pour 20 % du risque. Dans la grande majorité des projets que nous menons, la seconde option est la bonne, et elle n'est presque jamais celle qui était demandée au départ.
Commencer petit n'est pas une précaution, c'est la méthode
L'erreur la plus fréquente consiste à traiter le premier projet d'agent comme une vitrine. On choisit le cas d'usage le plus visible, celui qui impressionnera le comité de direction. C'est aussi celui qui touche le plus de systèmes, le plus de personnes, et qui a le plus de chances d'échouer.
La séquence qui fonctionne est inverse. Premier projet : un cas d'usage à faible visibilité, à fort volume, avec un résultat vérifiable. Il produit des chiffres. Ces chiffres financent et légitiment le deuxième projet, plus ambitieux. Le troisième peut alors s'attaquer au sujet vitrine, avec une équipe qui a déjà appris ce qui casse.
Les 23 % d'entreprises qui ont déployé à l'échelle n'ont pas eu de meilleurs modèles que les 62 % qui expérimentent encore. Elles ont eu un premier projet suffisamment petit pour réussir.