Pourquoi 40 % des projets d'IA agentique seront abandonnés, et comment être dans les 60 %

Les projets d’IA agentique sont rarement abandonnés pour des raisons purement techniques : ils s’arrêtent quand leur valeur reste floue, quand le coût d’exploitation n’a pas été anticipé et quand personne ne mesure le résultat. Sur la question des projets IA en échec, les repères existent : Gartner estimait en juin 2025 que plus de 40 % des initiatives agentiques seraient abandonnées d’ici la fin 2027, pour cause de coûts, de valeur incertaine et de risques mal encadrés.

Une étude du MIT (MIT NANDA, 2025) aboutit à un constat comparable : environ 5 % des pilotes d’IA générative produisent un effet mesurable sur le résultat de l’entreprise, tandis que les solutions achetées auprès de spécialistes aboutissent beaucoup plus souvent, de l’ordre de 67 % du temps. L’écart ne tient pas au LLM choisi, mais à la façon dont le projet est cadré, mesuré et exploité après la démonstration.

Pourquoi les projets d’IA agentique sont abandonnés ?

Trois causes expliquent la majorité des arrêts, et aucune n’est technologique.

La première est une valeur mal définie. Un agent IA est lancé parce que le sujet est attendu, sans tâche précise ni indicateur associé. Personne ne sait dire, six mois plus tard, si le projet a fait gagner du temps ou de l’argent. Sans indicateur de départ, la décision d’arrêter ou de poursuivre se prend à l’impression, qui penche vers l’arrêt.

La deuxième est un coût mal anticipé. Une démonstration coûte quelques dizaines d’euros de tokens. Un service qui tourne tous les jours, avec des documents volumineux et des relances, coûte de l’hébergement, des appels de modèle et de la supervision. Un agent mal borné qui boucle sur une demande impossible peut consommer sans rien produire. Le coût d’exploitation doit être estimé dès le cadrage, pas découvert sur la facture.

La troisième est un risque non encadré. Un agent qui lit des documents clients, écrit dans un ERP ou envoie un message engageant l’entreprise doit avoir des garde-fous : périmètre d’action limité, journalisation, et validation humaine pour toute action qui compte. Un agent IA mis en production propose, l’humain confirme. Quand ce point est négligé, le premier incident sérieux suffit à faire geler le projet.

Comment savoir si un projet d’IA mérite d’être lancé ?

Un projet mérite d’être lancé quand on peut décrire en une phrase la tâche visée, l’indicateur qui la mesure et la personne qui en répond. Cinq questions suffisent à trancher.

1. La tâche est-elle précise et répétée ? Un volume et une fréquence réels valent mieux qu’une intuition.
2. Le résultat est-il mesurable ? Temps de traitement, taux d’erreur, délai de réponse, nombre de dossiers traités.
3. Les données sont-elles accessibles et à jour ? Des documents dispersés ou obsolètes plombent n’importe quel agent.
4. Qui pilote côté métier ? Un projet sans responsable métier identifié retombe sur l’équipe technique, qui n’a pas autorité sur les priorités.
5. Quel est l’outil le plus simple qui marche ? Souvent, une automatisation IA suffit : n8n ou Make enchaînent les outils et ajoutent une étape d’IA pour lire ou classer. Un RAG est utile quand la réponse doit venir de documents internes. Un agent, avec LangGraph par exemple, devient pertinent quand la tâche enchaîne plusieurs étapes et des décisions.

Si l’une de ces réponses manque, complétez le cadrage avant de lancer le développement : c’est l’étape la moins chère et la plus décisive pour la suite.

Quels signaux annoncent un projet d’IA qui va échouer ?

Certains signaux se repèrent tôt, avant que le budget ne soit consommé.

• La démonstration convainc, mais personne ne l’utilise au quotidien. Un prototype qui ne sort pas du comité de direction ne prouve rien.
• Aucune eval n’est prévue. Si l’on ne sait pas mesurer la qualité des réponses, chaque évolution devient un pari.
• Le projet repose sur une seule personne. Si son départ arrête l’agent, l’entreprise n’a rien construit de durable.
• Le périmètre grossit à chaque réunion. Un agent qui doit tout faire ne fait rien correctement.
• L’agent prend seul des décisions engageantes. Un remboursement, un envoi ou une modification de commande validés par un humain restent la règle.

À l’inverse, les projets qui tiennent ont un périmètre étroit, des evals rejouées avant chaque évolution et une mise en production rapide sur un seul cas d’usage. Ce point est détaillé dans un projet IA qui évite la sur-promesse et livre ce qui tient.

Ce qui sépare un pilote d’une mise en production

Passer de la démonstration au service exploité demande quatre briques, et c’est là que se joue l’écart entre les 5 % et les 67 %.

Les evals d’abord. Ragas mesure la fidélité d’un RAG à ses sources, Promptfoo rejoue un jeu de tests à chaque modification. Sans elles, on ne sait pas si une nouvelle version améliore ou dégrade le service.

L’observabilité ensuite. Langfuse trace chaque appel, son coût et son résultat, ce qui permet de repérer une dérive ou une requête qui fait exploser la facture. C’est le cœur du LLMOps : traiter l’IA comme un logiciel en production, avec des journaux et des alertes.

Les garde-fous et l’intégration aux outils, enfin. MCP (Model Context Protocol) est le standard ouvert qui connecte un agent à vos outils et à vos données en contrôlant ce à quoi il a accès, ce qui évite d’ouvrir un accès trop large à votre système d’information. Code, prompts et evals restent la propriété de l’entreprise, documentés et reprenables : un service sans cette documentation dépend de celui qui l’a écrit. Un exemple d’architecture concrète : un chatbot agentique en PHP Symfony avec Neuron AI.

Prestataire ou équipe interne : ce qui change le taux de réussite

Le chiffre du MIT est instructif : les solutions achetées auprès de spécialistes aboutissent autour de 67 % du temps. Le facteur n’est pas le statut du prestataire, mais la présence de compétences de mise en production : evals, intégration aux outils métier, supervision, gestion des accès.

Avant de signer, demandez des points vérifiables : des evals sur vos cas réels avant la construction, le code et les prompts livrés, un prix fixé avec un périmètre écrit, et un plan de supervision après la mise en ligne. Une équipe qui accepte de cadrer avant de facturer un développement réduit le risque d’un projet qui s’arrête en route.

Pour poser les cas d’usage, les données et le coût mensuel estimé sans engager un budget lourd, un échange de 30 minutes suffit, avec une proposition chiffrée sous cinq jours. Le détail de la démarche figure sur la page des agents IA sur mesure, qui couvre aussi le jugement à porter sur la façon dont un prestataire teste et surveille ses agents : evals, CI/CD et observabilité.

Le test à faire cette semaine

Choisissez une seule tâche répétée, chronométrez-la aujourd’hui, et fixez l’indicateur que vous voulez voir bouger : minutes gagnées par dossier, taux d’erreur, délai de réponse. Vérifiez ensuite que les données nécessaires sont accessibles, puis décidez de l’outil le plus simple entre automatisation IA, RAG et agent. Si les trois critères tiennent (tâche précise, indicateur clair, données disponibles), le projet a une base solide pour aller en production.

Ce premier pas coûte peu et évite l’erreur la plus fréquente : construire vite un agent séduisant en démonstration, puis découvrir en exploitation qu’il ne sert à personne. Cadrer le besoin puis mettre en production sur un cas étroit reste la façon la plus sûre d’être dans les 60 % : lancer un agent IA sur un cas précis. Pour aller plus loin sur la mesure, les bons indicateurs d’un projet IA prolongent cette approche.