Rubriques

Intelligence artificielle Automatisation Veille Écosystème lyonnais

Le site

Tous les articles Le média Nous écrire
Intelligence artificielle

Agents IA : ce que douze mois de déploiements ont appris aux entreprises

Un an après la vague d'annonces, les agents IA ont trouvé quelques terrains solides et beaucoup de projets à l'arrêt. Ce que les déploiements réels ont appris.

Agents IA : ce que douze mois de déploiements ont appris aux entreprises

Cela fait maintenant un an que les agents occupent le devant de la scène. Le retour d'expérience sur les agents IA commence donc à être exploitable : assez de projets sont passés du diaporama à l'exploitation quotidienne pour qu'on distingue les périmètres où ça tient de ceux où ça casse.

Le tableau est contrasté, et c'est plutôt une bonne nouvelle. Contrasté veut dire qu'il existe des cas qui marchent, avec des caractéristiques communes identifiables. Cela vaut mieux qu'un enthousiasme uniforme, qui ne renseigne sur rien.

Nous avons repris les études publiées sur la période, les chiffres communiqués par les cabinets qui déploient eux-mêmes ces systèmes, et les constantes qui reviennent dans les retours de terrain. Voici ce que douze mois ont appris.

Ce que disent les chiffres publiés

Le premier signal date de juin 2025 : Gartner prévoyait alors que plus de 40 % des projets d'IA agentique seraient annulés d'ici la fin 2027, en raison de coûts qui dérapent, d'une valeur métier mal établie ou de contrôles de risque insuffisants. Le cabinet pointait aussi un phénomène de requalification marketing, l'« agent washing », consistant à rebaptiser en agents des assistants, des chatbots ou des robots logiciels existants. Sur les milliers de fournisseurs revendiquant une offre agentique, Gartner estimait qu'environ 130 proposaient réellement autre chose.

Le deuxième signal vient du rapport publié à l'été 2025 par l'initiative NANDA du MIT, largement relayé depuis. Il concluait que 95 % des projets pilotes d'IA générative en entreprise ne produisaient aucun impact mesurable sur le compte de résultat, avec un écart marqué entre les organisations qui achètent des solutions éprouvées et celles qui développent tout en interne, ces dernières échouant beaucoup plus souvent.

Le troisième signal est plus encourageant, parce qu'il vient de praticiens. Dans un entretien publié en janvier 2026, McKinsey décrivait un déploiement interne de l'ordre de 25 000 agents pour 60 000 collaborateurs, avec des gains de productivité annoncés entre 20 et 30 % sur la plupart des projets, et de 30 à 50 % sur le développement logiciel. Le cabinet insistait sur un point : il ne s'agit pas de systèmes autonomes livrés à eux-mêmes, mais de couplages humain-agent avec supervision et gouvernance.

Les trois lectures ne se contredisent pas. Elles décrivent une technologie qui produit de la valeur dans des conditions précises, et qui en produit très peu en dehors.

Les périmètres où les agents tiennent en production

Sur douze mois, les déploiements qui survivent partagent quatre caractéristiques.

  • Un périmètre étroit et répétitif. Traitement d'une catégorie de demandes entrantes, préparation d'un dossier, contrôle de cohérence documentaire. Pas « la relation client », mais « les demandes de duplicata de facture ».
  • Une source de vérité propre. L'agent lit dans un référentiel maintenu, pas dans un partage de fichiers accumulé depuis dix ans.
  • Un point de sortie contrôlé. L'action irréversible reste soumise à validation humaine, ou n'est autorisée qu'en dessous d'un seuil.
  • Un propriétaire métier identifié. Quelqu'un dont le travail est de regarder les résultats chaque semaine et de décider d'élargir ou de restreindre.

Ces quatre points recoupent les garde-fous que nous avions détaillés dans notre article sur les agents IA en production. Un an plus tard, rien dans les retours publiés ne les remet en cause.

Les trois causes d'abandon les plus fréquentes

1. Le périmètre n'a jamais été délimité

C'est la cause la plus banale. Le projet démarre sur une intention large, « automatiser le support », sans définir la liste des cas traités ni ce que l'agent doit faire quand il sort de cette liste. Le résultat est un système qui répond à tout, donc mal, et que l'équipe finit par contourner.

Le contre-exemple est simple à mettre en place : écrire, avant de développer, les vingt demandes les plus fréquentes et les traiter uniquement celles-là. La suite se décide sur des mesures, pas sur des intentions.

2. Le coût réel n'a pas été anticipé

Une démonstration consomme quelques dizaines de milliers de jetons. Un agent en exploitation, qui relit un contexte long à chaque étape et reprend plusieurs fois une tâche, en consomme des ordres de grandeur au-dessus. Beaucoup d'équipes découvrent la facture au troisième mois.

Deux éléments ont changé la donne en 2026, et pas dans le même sens. Les tarifs à l'entrée ont baissé sur les gammes intermédiaires, ce qui rend certains usages viables. Mais les agents consomment davantage à chaque itération, parce qu'ils raisonnent plus longtemps. Le prix unitaire baisse, le volume monte : le budget ne suit pas mécaniquement la baisse affichée.

3. Personne ne sait dire si ça marche

C'est la cause la plus coûteuse, parce qu'elle interdit toute décision. Sans jeu de tests, sans indicateur de qualité suivi dans le temps, la discussion sur l'élargissement devient une question d'opinion. Les projets qui passent la première année sont presque toujours ceux qui ont construit, dès le pilote, une petite batterie de cas de référence rejouée à chaque changement de modèle ou de consigne.

L'écart entre la démonstration et l'exploitation quotidienne

Une démonstration se déroule sur des données choisies, avec un opérateur qui sait formuler sa demande et qui rattrape les erreurs sans le dire. L'exploitation quotidienne, elle, apporte les cas mal formulés, les pièces jointes illisibles, les demandes qui portent sur deux sujets à la fois, et les utilisateurs qui n'ont pas assisté à la réunion de lancement.

Trois écarts reviennent systématiquement dans les retours de la période.

  • La variabilité. Le même agent, sur des demandes proches, donne des réponses de qualité inégale. En démonstration, on montre les bonnes. En production, les utilisateurs se souviennent des mauvaises.
  • Les changements de modèle. Les fournisseurs font évoluer leur gamme plusieurs fois par an. Un comportement calé sur une version peut se décaler sur la suivante, ce qui impose de rejouer les tests avant chaque bascule.
  • La maintenance silencieuse. Un agent branché sur cinq outils dépend de cinq contrats d'interface. Une évolution chez l'un d'eux casse une branche du parcours, souvent sans erreur explicite.

Autrement dit, un agent est un logiciel. Il demande le même soin qu'un logiciel : versions, tests, journalisation, astreinte. Ce n'est pas ce que promettaient les démonstrations de l'an dernier.

Le partage des rôles s'est déplacé

L'idée d'un agent totalement autonome a reculé. Ce qui s'installe à la place ressemble davantage à une chaîne où l'agent prépare et où l'humain décide. Concrètement : l'agent rassemble les pièces, propose une réponse, signale ce dont il n'est pas sûr, et un opérateur valide en quelques secondes au lieu de traiter le dossier en quinze minutes.

Ce format a un avantage sous-estimé : il produit de la donnée d'entraînement propre. Chaque correction humaine documente un cas limite. Au bout de quelques mois, l'équipe sait précisément où l'agent se trompe, et peut décider d'automatiser complètement la portion qui ne pose plus de problème.

Ce qu'il faut retenir pour un projet qui démarre maintenant

Le retour d'expérience collectif sur les agents IA tient en quelques règles simples, et elles sont plus exigeantes sur la préparation que sur la technique.

  1. Choisissez une tâche que vous savez décrire en une phrase et compter en volume mensuel.
  2. Écrivez les critères de réussite avant la première ligne de code, et constituez un jeu de tests d'une trentaine de cas réels.
  3. Gardez la validation humaine sur tout ce qui est irréversible tant que le taux d'erreur n'est pas stabilisé.
  4. Mesurez le coût par tâche traitée, pas le coût mensuel global : c'est la seule métrique qui permet de décider d'un élargissement.
  5. Prévoyez le budget de maintenance dès le départ, autour d'un tiers du coût de construction chaque année.

Si ces cinq points paraissent lourds pour un premier essai, c'est probablement que le sujet choisi est trop large. Réduisez le périmètre plutôt que le sérieux. Et si la notion même d'agent reste floue dans votre équipe, notre article sur ce qu'est un agent IA pose les définitions avant d'entrer dans le vif.

Sources

Laisser un commentaire

Votre commentaire

Jamais publiée, jamais transmise à des tiers.

Les commentaires sont relus avant publication. Voir la politique de confidentialité.