TL;DR. Sur ITBench-AA — le premier benchmark pour agents enterprise sur des tâches IT, publié le 27 mai 2026 par IBM Research et Artificial Analysis — Claude Opus 4.7 atteint 47 % et GPT-5.5 46 %, mais aucun modèle ne dépasse 50 % sur des diagnostics SRE Kubernetes réels. Le coût par tâche varie de 0,14 $ à 5,38 $ : la sélection de modèle ne peut plus reposer sur le score seul.
Contexte : un benchmark SRE qui force une réévaluation
Le 27 mai 2026, IBM Research et Artificial Analysis publient ITBench-AA sur Hugging Face — le premier benchmark conçu spécifiquement pour évaluer des agents IA sur des tâches IT de niveau enterprise. Le corpus comprend 59 tâches SRE (Site Reliability Engineering), principalement des diagnostics d'incidents Kubernetes : pannes d'infrastructure, défaillances applicatives, épuisement de quotas de ressources, échecs de déploiements et partitionnements réseau.
La notation est stricte, selon la méthodologie publiée : un agent doit identifier l'ensemble minimal des causes racines indépendantes. Manquer une cause réelle donne un score de 0,0 ; inclure un faux positif réduit la précision finale. C'est ce cadre qui rend le résultat difficile à contourner — aucun modèle, frontier ou open-weight, ne dépasse 50 %.
Là où Claude prend la tête — avec sa contrainte principale
Selon le leaderboard ITBench-AA, Claude Opus 4.7 en mode Adaptive Reasoning, Max Effort obtient 47 % — le meilleur score publié à ce jour. C'est 1 point au-dessus de GPT-5.5, 7 points au-dessus de Gemini 3.5 Flash et 17 points au-dessus de Gemini 3.1 Pro Preview.
La contrepartie est documentée dans le même benchmark : Claude Opus 4.7 est le modèle le plus coûteux, à 5,38 $ par tâche. Pour une équipe SRE traitant plusieurs centaines d'incidents par semaine, ce coût unitaire est une variable d'architecture, pas un détail de facturation.
Là où GPT-5.5, Gemini et les open-weights tiennent encore la ligne
GPT-5.5 en mode xhigh atteint 46 % — 1 point sous Claude — avec une efficacité d'exécution que le benchmark révèle explicitement : 31 tours en moyenne par tâche. Gemini 3.1 Pro Preview, de son côté, consomme 83 tours pour un score de seulement 30 %. Deux fois et demie plus de tours pour seize points de moins : l'impact sur la latence et les coûts API est structurel, pas marginal.
Gemini 3.5 Flash stabilise à 40 % pour 1,70 $ par tâche — un rapport score/coût nettement plus favorable que Gemini 3.1 Pro à 2,23 $ pour 30 %. Qwen3.7 Max atteint 42 %, se logeant entre les deux modèles frontier dominants.
Sur le segment open-weight, GLM-5.1 (Reasoning) atteint 40 % pour 1,23 $ par tâche. DeepSeek V4 Pro (Reasoning) obtient 38 %. Gemma 4 31B (Reasoning) ferme le classement open-weight à 37 % pour 0,14 $ par tâche — un coût 38 fois inférieur à Claude Opus 4.7, selon les données publiées par IBM Research et Artificial Analysis. Fait notable : Gemma 4 31B surpasse Gemini 3.1 Pro Preview à la fois sur le score (37 % contre 30 %) et sur le coût (0,14 $ contre 2,23 $ par tâche).
Implications tarifaires et opérationnelles
L'écart de coût entre le modèle le plus performant et le moins onéreux du leaderboard est de 38x (5,38 $ contre 0,14 $), selon les données publiées. Pour une organisation qui automatise des centaines de diagnostics SRE par semaine, cet écart remet fondamentalement en question l'hypothèse selon laquelle un seul modèle frontier suffit pour l'ensemble du périmètre opérationnel.
Le nombre de tours constitue un deuxième axe de coût souvent absent des comparatifs de modèles. Un agent à 83 tours par tâche génère une latence incompatible avec des alertes SRE temps réel. GPT-5.5 à 31 tours offre ici un avantage opérationnel que le seul delta de score (1 point sous Claude) ne capte pas. La cadence d'exécution est une dimension de performance à part entière.
Ce que cela implique pour une architecture multi-modèles
La lecture croisée des scores, des coûts et des tours suggère une segmentation fonctionnelle. Les incidents critiques à faible fréquence — partitionnements réseau, diagnostics de sécurité, rollouts complexes — justifient Claude Opus 4.7 ou GPT-5.5 malgré leur coût. Les tâches SRE courantes à fort volume — monitoring de quotas, alertes récurrentes, diagnostics applicatifs standards — peuvent être routées vers Gemma 4 31B ou GLM-5.1 avec un rapport coût/performance documenté dans le benchmark lui-même.
Une architecture à modèle unique pour l'ensemble des tâches IT agentiques devient difficile à défendre sur la base de ces données. Le routage par criticité et par type d'incident cesse d'être une optimisation pour devenir une décision d'architecture à part entière.
Trois leviers à activer cette semaine
- Consulter le leaderboard ITBench-AA sur artificialanalysis.ai avant tout arbitrage de modèle pour des cas d'usage IT agentiques — les données de score, de coût et de tours sont publiques et directement comparables.
- Mesurer le nombre de tours dans les déploiements d'agents SRE actuels, pas uniquement le taux de réussite. Un écart de 2,7x en nombre de tours entre modèles se traduit directement en latence et en coût API réels.
- Piloter Gemma 4 31B sur les tâches SRE à fort volume avant de reconduire automatiquement un abonnement frontier : à 0,14 $ par tâche, le pilote est peu risqué financièrement, et les données de référence existent dans le benchmark.
Un taux de 47 % sur des diagnostics IT autonomes : où se situe la frontière non négociable avec la supervision humaine ?
Si ce décryptage vous parle, je publie une analyse de ce calibre chaque jour sur l'innovation digitale et l'IA en entreprise. 👉 Recevez la prochaine directement dans votre boîte mail — l'inscription prend dix secondes, et chaque édition est lue avant 9h par des dirigeants de PME, d'ETI et d'institutions belges.