Quand un outil tombe, votre assistant IA perd 60 % de sa qualité

Un matin, la connexion entre votre assistant automatisé et votre logiciel de facturation tombe. L'assistant ne s'arrête pas. Il continue à répondre, avec assurance, en proposant des montants qui semblent justes. Personne ne s'en aperçoit avant la réunion de l'après-midi.

Ce scénario n'est pas une hypothèse. Une équipe de six chercheurs a mesuré ce qui arrive à un assistant privé de ses outils. Le 23 octobre 2026, elle a publié ses résultats sur arXiv, l'archive publique des travaux scientifiques. La conclusion tient en une phrase : le programme continue de travailler, mais la qualité de son travail s'effondre.

Une étude qui teste les pannes, pas les performances

Un agent est un programme à qui l'on confie un objectif et des outils. Il choisit seul les étapes, essaie, vérifie, puis recommence. On le branche sur un agenda, une base de clients, un logiciel de facturation.

Les auteurs viennent de l'université du Luxembourg, de l'université de Tilburg, de l'école supérieure de Gran Sasso et de l'université de Naples. Ils ont construit un outil qui provoque volontairement des pannes. La panne est simulée entre l'assistant et le service qu'il appelle, sans modifier ni l'un ni l'autre.

Pour choisir quelles pannes provoquer, ils n'ont pas improvisé. Ils ont analysé 57 240 échanges publics, tirés de 1 774 projets qui exposent des outils à des assistants. Autrement dit : leur mélange de pannes ressemble à ce qui arrive vraiment.

Le protocole compte 1 350 essais. Trois façons de construire l'assistant, deux tailles de modèle, vingt-cinq tâches, trois répétitions. Chaque essai est rejoué avec et sans panne.

Ce qu'est un outil branché sur un assistant

Un assistant ne sait rien faire seul. Pour lire une facture ou consulter un stock, il appelle un service extérieur. Longtemps, chaque branchement demandait un travail sur mesure.

Un standard a changé la donne : le MCP, pour Model Context Protocol. C'est une prise universelle. Le service décrit ses outils dans un format commun, et l'assistant peut les appeler sans qu'on réécrive son programme. Un catalogue public recense des milliers de ces prises.

Une prise universelle a un revers. Elle multiplie les points de contact, donc les occasions de panne. L'étude en distingue six formes. Le service peut renvoyer une petite erreur. Il peut renvoyer une réponse bien formée mais fausse. Il peut renvoyer un format invalide. Il peut signaler une erreur explicite. Il peut répondre trop tard. Il peut se taire complètement.

Ces pannes durent aussi de trois façons : définitivement, le temps d'un incident, ou par intermittence. Dans les échanges analysés, la panne définitive domine. La plus fréquente est l'erreur explicite : 10 393 cas sur 14 829 pannes classées.

Ce que la panne fait à la réponse

Sans panne, les assistants testés terminent 95 à 100 % des tâches. Leur note moyenne atteint 8,08 sur 10.

Avec les pannes, la note tombe à 3,23 sur 10. Soit une chute de 60 %. Le choix du bon outil perd 59 %. La planification perd 67 %. Les six autres critères mesurés perdent entre 54 et 68 %.

Le taux de tâches terminées reste élevé : 88 à 97 %. C'est le point contre-intuitif. L'assistant ne s'arrête pas. Il rend quelque chose. Ce quelque chose est simplement deux fois moins bon.

La répartition des comportements confirme ce diagnostic. Dans 56 % des essais, la dégradation est partielle : la tâche est terminée, mais mal. Les cas sans aucun effet représentent 7 à 19 % selon la configuration. Le reste se partage entre arrêt net, dégradation propre, contournement d'outil et échec complet.

Pourquoi un plus gros modèle ne protège pas

L'intuition naturelle est simple : prenez un modèle plus gros, il s'en sortira mieux. Les auteurs ont testé exactement cela.

Ils ont comparé deux versions d'une même famille de modèles ouverts, gpt-oss : l'une à 20 milliards de paramètres, l'autre à 120 milliards. Un paramètre est un réglage interne du modèle. Plus il y en a, plus le modèle est coûteux à faire tourner.

Résultat : aucune différence de résistance. La version à 120 milliards ne conserve pas une plus grande part de sa note initiale quand les outils tombent. Le test statistique ne détecte aucun écart (p = 0,96).

Les taux de réussite vont même dans le sens inverse. Sous pannes, le gros modèle termine 91,1 % des tâches, le petit 95,6 %. Les auteurs refusent d'en faire une preuve : l'intervalle de confiance descend sous zéro. Ils parlent d'un écart descriptif, pas d'un effet de la taille.

Un détail nuance le tableau. Quand le gros modèle termine, sa réponse est meilleure : 3,68 contre 3,26. Il est donc plus capable, sans être plus robuste.

L'explication probable est l'exposition. Le gros modèle reçoit plus de pannes par essai, 4,6 contre 3,9. Il écrit des réponses plus longues. Il insiste plus longtemps sur un outil qui échoue. Sur ses vingt échecs complets, dix-huit sont des dépassements de délai. Un camion plus puissant ne tient pas mieux la route sur du verglas ; il y arrive plus vite.

Le piège de la réponse plausible

Le résultat le plus dérangeant n'est pas la baisse de note. C'est la façon dont certains essais obtiennent une bonne note sans avoir utilisé l'outil.

Les auteurs appellent cela le contournement d'outil. Le juge automatique note la réponse comme utile, mais constate qu'aucune preuve d'appel n'existe. Sur 450 essais avec pannes, 27 tombent dans ce cas, soit 6 %.

Deux constats rendent le phénomène instructif. D'abord, 17 de ces 27 essais n'ont appelé aucun outil : la panne n'a même pas eu l'occasion de se produire. Ensuite, le phénomène existe aussi sans panne : 21 essais en mode normal.

La panne ne crée donc pas le problème. Elle le révèle. Et elle le rend plus fréquent : quand on retire ces essais sans appel, la chute de qualité passe de 60 % à 67 %.

L'image est celle d'un employé qui répond de mémoire au lieu d'ouvrir le dossier. Il tombe parfois juste. Il ne peut pas dire d'où vient son chiffre.

C'est le comportement le plus coûteux pour une entreprise, parce qu'il ne déclenche aucune alerte. Une erreur visible se corrige. Une réponse plausible se valide.

Ce que cela change pour votre entreprise

Cinq décisions découlent de cette étude, sans acheter quoi que ce soit.

Testez la panne, pas la démonstration. Débranchez un outil dans un environnement de test, puis observez. Si l'assistant répond quand même, vous avez trouvé votre risque principal.

Comptez les réponses sans outil. Ajoutez un journal qui note, pour chaque réponse, si un appel a eu lieu. Un taux élevé signale un assistant qui devine.

Regardez la façon dont les erreurs sont transmises. Les trois constructions testées ne se comportent pas pareil. L'une replanifie avec un autre outil ; les deux autres abandonnent la boucle plus souvent. Cet écart compte plus que le choix du modèle.

Priorisez les tâches fragiles. La dégradation dépend fortement du type de tâche. Un service en ligne vivant perd jusqu'à 97 % de sa note. Une tâche à chaîne séquentielle longue perd 82 %. Un calcul court perd 19 %. Mettez vos contrôles là où la chaîne est longue.

Gardez un humain sur ce qui engage. L'étude porte sur des tâches sans validation humaine. Elle ne dit rien des dispositifs qui font relire chaque action. Elle ne les absout pas non plus.

Trois limites empêchent d'en faire une certitude. Le banc d'essai ne contient que 25 tâches, faciles sans panne. Les deux modèles viennent de la même famille. Les pannes suivent la fréquence observée dans les rapports publics, avec leur biais de déclaration.

La conclusion utile reste solide. Un agent se juge sur ce qu'il fait quand un outil manque, pas sur ce qu'il fait quand tout va bien.

Ce qu'il faut retenir

• Une étude du 23 octobre 2026 a mesuré 1 350 essais d'assistants privés de leurs outils : la qualité chute de 60 %.
• Les assistants ne s'arrêtent pas : ils terminent la tâche dans 88 à 97 % des cas, avec une réponse deux fois moins bonne.
• Un modèle plus gros n'est pas plus résistant : la version à 120 milliards de paramètres ne fait pas mieux que celle à 20 milliards.
• Dans 6 % des essais, l'assistant invente une réponse plausible sans appeler l'outil, un défaut qui existe aussi sans panne.
• Testez la panne en environnement de test, journalisez les appels d'outils, et contrôlez en priorité les tâches à chaîne longue.
• Une réponse plausible coûte plus cher qu'une erreur visible, parce que personne ne la vérifie.