AOS-Bench évalue les agents IA : la performance chute de 13 à 23 points sur les tâches parallèles

Comment l'expérience a été conçue

Une équipe de chercheurs s'est penchée sur une question très concrète : les agents IA capables d'écrire du code et de piloter un ordinateur sont-ils vraiment prêts à traiter non pas une seule tâche à la fois, mais un flux de tâches — comme dans la vraie vie, où pendant qu'un projet est en cours de compilation, une demande de traitement de données arrive, suivie d'une autre pour corriger un bug. Tous les tests existants pour ce type d'agents (comme Terminal-Bench ou OSWorld) évaluent les tâches séparément, si bien que personne n'avait jusqu'à présent mesuré la capacité d'un agent à gérer plusieurs dossiers simultanément avec des ressources informatiques limitées. C'est pour combler ce manque qu'a été créé le nouveau test AOS-Bench — il simule le fonctionnement d'un agent comme une sorte de « système d'exploitation en langage naturel », qui décide lui-même quand se saisir d'une nouvelle tâche, comment répartir le travail entre les sous-tâches, et comment ne pas dépasser le CPU et la mémoire disponibles.

Cinq combinaisons « modèle + enveloppe agentique » ont été testées : Claude Opus 5, GPT-5.6-sol, DeepSeek-V4-Pro, GLM-5.3 et Kimi-K3. Chaque système disposait d'une limite de 4 cœurs CPU et 8 gigaoctets de mémoire — dans un cas, les tâches arrivaient strictement une par une (référence de performance « individuelle »), dans l'autre, plusieurs tâches arrivaient à la suite avec des intervalles, comme dans un environnement de travail réel (« flux »). Deux niveaux de difficulté ont été testés : moyen (10 tâches par run) et élevé (20 tâches).

Ce que révèlent les chiffres

En charge élevée, chacun des cinq systèmes a perdu entre 13 et 23 points de pourcentage de réussite par rapport à ce que le même système obtient sur les mêmes tâches traitées une par une. Claude Opus 5 s'en est le mieux sorti : son taux de réussite est passé de 75,5 % sur des tâches individuelles à 62,5 % en flux — soit environ 83 % de sa capacité de base conservée. Les quatre autres systèmes n'ont conservé que 61 à 75 % de leur niveau de base.

En charge moyenne, les résultats se sont révélés encore plus révélateurs : la qualité avec laquelle un système résout des tâches individuelles ne prédit presque pas sa performance face à un flux de tâches. GPT-5.6-sol obtient le meilleur score sur les tâches individuelles (85,3 %), mais perd 14,5 points en flux.

Kimi-K3, dont le score de base est pourtant inférieur de 11 points, ne perd que 6,3 points en flux. L'exemple le plus frappant : deux systèmes dont les taux de réussite sur tâches individuelles ne diffèrent que de 0,6 point (74,9 % contre 74,3 %) affichent respectivement 68,1 % et 53,9 % en flux — un écart de presque 15 points là où il ne devrait pas y en avoir.

Pourquoi un tel écart

La cause principale ne réside pas dans une moins bonne résolution des tâches elles-mêmes. Les auteurs ont décomposé chaque perte de points par cause et découvert qu'une grande partie de l'écart en charge élevée (16 à 26 points sur 16 à 23 pour quatre systèmes) provient de tâches que l'agent n'a jamais prises en charge, qu'il n'a pas terminées à temps, ou qu'il a achevées après la saturation de la mémoire. Les erreurs commises lors de l'exécution effective des tâches prises en charge ne représentent, elles, qu'une perte d'au plus 1,3 point. En somme : les systèmes ne trébuchent pas sur la résolution des tâches, mais sur le fait de s'en saisir à temps.

GLM-5.3 et DeepSeek-V4-Pro sont particulièrement révélateurs : lors de certains runs, ils ont simplement arrêté de prendre en charge de nouvelles tâches et sont repassés à un traitement unitaire, laissant respectivement 25 % et 48 % des tâches entrantes totalement de côté (contre 0 % pour Claude Opus 5). Pourtant, lorsque toutes les tâches sont soumises simultanément sans file d'attente sérielle, les systèmes prennent en charge les trois quarts d'entre elles — le problème ne réside donc pas dans la complexité des tâches, mais bien dans la logique de prise en charge du nouveau travail.

Une conclusion surprenante sur la gestion « intelligente »

On pourrait penser que la solution consiste à entraîner l'agent à mieux planifier le parallélisme. Mais l'expérience montre l'inverse : une règle élémentaire — « exécuter exactement deux tâches simultanément sans aucune analyse » — rivalise presque (écart allant jusqu'à 4 points seulement) avec les meilleures stratégies où l'agent décide lui-même quoi lancer et quand. Et quelle que soit la stratégie de gestion, pendant que les tâches attendent leur tour, le CPU n'est utilisé qu'à moins de 30 % des quatre cœurs alloués — les ressources restent inactives, même quand le travail abonde.

Pour les équipes qui envisagent de construire des agents IA persistants destinés à un travail multitâche réel, la conclusion est pragmatique : il ne vaut pas la peine d'investir immédiatement dans une logique de planification sophistiquée au sein de l'agent — une simple limitation du parallélisme donne un résultat quasiment équivalent. Ce qu'il faut réparer en priorité, c'est le mécanisme de réception et de confirmation des nouvelles tâches, là où se perd l'essentiel de l'efficacité.