Pourquoi 40 % des projets d’agents IA seront abandonnés

Gartner prévoit que plus de 40 % des projets d’IA agentique seront abandonnés avant fin 2027, pour trois raisons nommées : absence de ROI clair, absence de gouvernance, absence d’intégration.

Ce qu’il faut lire dans ce chiffre, c’est le mot « abandonnés ». Pas « échoués » : abandonnés. Ces projets fonctionnent techniquement. Ils sont arrêtés parce que personne ne sait dire ce qu’ils rapportent, personne ne sait qui répond quand ils se trompent, et ils n’atteignent pas les outils où le travail se fait.

Les trois causes se préviennent, et aucune ne demande de compétence technique.

Première cause : un ROI que personne ne sait lire

Le piège est de mesurer le mauvais objet.

« Temps gagné » est l’indicateur que tout le monde choisit et celui que personne ne sait établir. Gagné par rapport à quoi ? Un business manager ne chronomètre pas ses relances. Six mois plus tard, le comité demande le chiffre, personne ne l’a, et le projet devient une dépense sans justification.

Ce qui se mesure, c’est ce qui n’existait pas avant. Le nombre de relances effectivement parties dans le mois, alors qu’un tiers d’entre elles ne partaient jamais. Le nombre de fins de mission repérées à soixante jours au lieu de trente. Le nombre de comptes rendus d’entretien réellement écrits, plutôt que promis.

Ces chiffres-là ont deux qualités : ils se comptent sans interroger personne, et ils se traduisent en euros sans hypothèse héroïque. Une fin de mission anticipée de trois semaines sur un consultant qui coûte environ 5 480 € par mois, c’est un montant que personne ne discute en comité.

Fixez cet indicateur avant de démarrer, pas au moment du bilan. Un chiffre choisi après coup est toujours suspect, et il l’est à raison.

Deuxième cause : personne ne sait qui répond

Un agent qui écrit à des candidats pose une question que l’organisation n’a jamais eu à trancher : qui est responsable de ce qu’il envoie ?

Tant qu’elle reste sans réponse, deux issues, également fatales. Soit tout passe par une validation, y compris ce qui n’en avait pas besoin, et le coût de relecture annule le gain : l’équipe conclut que « ça ne fait pas gagner de temps », ce qui est vrai dans cette configuration. Soit rien ne passe par une validation, et le premier message maladroit envoyé à un candidat sénior arrête le projet en une réunion.

La ligne qui tient est mécanique : ce qui sort de l’entreprise attend une validation, ce qui reste dedans part seul, ce qui ferme une porte se décide par une personne. C’est le sujet d’un article entier, parce que c’est la décision qui détermine si le projet survit à son premier incident.

Et il faut un journal. Sans trace de qui a validé quoi, un incident se conclut par « l’IA a fait n’importe quoi », ce qui n’apprend rien et détruit la confiance de toute l’équipe pour une erreur qui était peut-être une consigne mal formulée.

Troisième cause : l’agent n’atteint pas le travail

C’est la plus banale et la plus coûteuse.

Un agent qui vit dans sa propre interface ne se fait presque rien déléguer. Il faut y penser, s’y rendre, recopier le contexte. À la troisième fois, on fait la tâche à la main : c’est plus rapide.

Le corollaire est moins évident : un agent bien intégré à un système d’information en désordre est pire qu’inutile. Il produit des raisonnements justes sur des données fausses, avec l’assurance d’une machine. Une shortlist impeccablement argumentée à partir d’un vivier dont les disponibilités datent de l’an dernier fait perdre plus de temps qu’elle n’en gagne, parce qu’elle est crédible.

D’où l’ordre des opérations, qui est contre-intuitif : vérifiez l’état de vos données avant d’évaluer un agent. Si vos fins de mission ne sont pas à jour dans l’ATS, aucun agent ne les anticipera. C’est aussi pourquoi la vraie question sur les intégrations n’est pas leur nombre, mais si les quatre ou cinq outils que vous ouvrez chaque matin en font partie.

La quatrième cause, que Gartner ne nomme pas

L’impatience.

Le break-even d’un déploiement industrialisé se situe entre 4 et 9 mois. L’adoption met trois à quatre semaines à démarrer, et l’habitude de déléguer se construit plus lentement encore.

Un comité qui juge à trois mois arrête donc systématiquement avant d’avoir la réponse. Et il l’arrête avec de bonnes raisons apparentes : les chiffres sont minces, l’usage est irrégulier, quelqu’un a une anecdote d’erreur. Tout cela est normal à trois mois et ne dit rien de ce que sera le mois neuf.

Fixez l’horizon d’évaluation au démarrage, par écrit, en même temps que l’indicateur. C’est une protection contre vous-même.

Le piège du pilote

Il y a une manière presque garantie de rater : lancer un pilote isolé.

Le raisonnement paraît prudent. On prend un périmètre restreint, sans enjeu, avec deux volontaires, pour « voir ce que ça donne sans risque ». Six semaines plus tard, la démonstration est réussie et personne ne sait quoi en faire, parce qu’un pilote sans enjeu ne produit aucun chiffre défendable, et qu’un usage sans contrainte ne prouve rien sur un usage sous contrainte.

Le petit périmètre est une bonne idée ; le petit enjeu, non. Prenez un processus étroit mais réel : les relances d’un business manager sur ses comptes, pas « des tests de relance ». Vous obtenez en six semaines un nombre qui se discute en comité, et une équipe qui a vraiment eu besoin que ça marche.

L’autre variante du piège est le pilote confié aux plus curieux. Ils réussiront, et ils ne prouveront rien : ce sont ceux qui auraient trouvé un moyen de gagner du temps de toute façon. La question intéressante est ce que ça donne avec quelqu’un que ça n’intéresse pas.

Ce qu’il faut écrire avant la première connexion

Trois choses, sur une page, avant d’ouvrir un compte.

Le chiffre, et sa valeur aujourd’hui. « Combien de relances sont parties le mois dernier » a une réponse mesurable maintenant ; sans ce point de départ, le même chiffre dans six mois ne voudra rien dire.

La ligne de validation, en une phrase, et qui l’applique. Pas un document de gouvernance : une phrase que l’équipe retient.

L’horizon, et ce qui serait un échec. Une date, un seuil. Le décider à froid protège contre la réunion de mars où quelqu’un raconte une anecdote d’erreur.

Une page. Le temps de la rédiger est le meilleur investissement du projet, et c’est précisément ce que quatre projets sur dix n’ont pas fait.

Le seul indicateur d’adoption qui vaille

Ni le nombre de connexions, ni le volume de requêtes. Le nombre de demandes que personne n’a suggérées.

Une statistique d’usage sur un outil que la direction a demandé d’utiliser mesure l’obéissance. Une demande spontanée mesure l’adoption, quelqu’un a eu un problème et a pensé à l’agent avant de penser à le faire à la main.

Le signe le plus fiable est encore plus simple : le jour où un membre de l’équipe s’agace qu’une chose ne soit pas encore possible. On ne s’agace que de ce sur quoi on compte.

Ce que ça change à la façon de démarrer

Trois décisions, prises avant la première connexion, et écrites.

Quel chiffre on regardera dans six mois, et comment on le compte aujourd’hui pour avoir un point de départ. Qui valide quoi, selon la ligne « ça sort / ça reste ». Sur quels outils l’agent est branché, et si les données qu’ils contiennent sont à jour.

Aucune des trois n’est technique. C’est précisément pour cela qu’elles sont oubliées, et que quatre projets sur dix s’arrêtent en marchant.