Magazine LLM Opensource · 9 November 2026Artificial Analysis v5 : les 12 points qui séparent les agents ouverts des agents fermés — et les 26 que personne ne regarde
Le 27 octobre 2026, Artificial Analysis publiait la refonte v5 de son Intelligence Index. En une nuit, l’écart entre modèles propriétaires et open weights est passé de 3 à 12 points. Mais derrière ce chiffre se cache une réalité plus dure encore : parmi les poids réellement téléchargeables, le fossé atteint 26 points. Voici ce que la nouvelle méthodologie mesure vraiment, pourquoi les modèles ouverts décrochent dès que la tâche devient une trajectoire, et comment arbitrer sans se tromper.
Le classement qui a fait taire les « open weights rattrapent tout »
Depuis deux ans, une petite musique berçait l’écosystème : les modèles ouverts rattrapent les fermés. Et les chiffres semblaient lui donner raison. Sur les benchmarks classiques — MMLU et ses avatars, les tests de code type HumanEval, les problèmes de math façon GSM8K ou AIME — la convergence était patente. Plusieurs modèles atteignaient des scores parfaits sur AIME 2025, et les écarts entre familles ouvertes et propriétaires se comptaient en fractions de point. Les leaderboards, saturés, affichaient des colonnes de 95, 98, 100 %.
Puis est arrivé le 27 octobre 2026. Ce jour-là, Artificial Analysis a publié l’Intelligence Index v5, et l’écart entre modèles propriétaires et open weights est passé de 3 points (en v4, lancée en janvier 2026) à 12 points. Un quadruplement d’un coup. Le genre de bascule qui ne se discute pas : elle tombe au moment précis où les praticiens déploient massivement des agents en production, où le choix d’un modèle cesse d’être un choix de chatbot pour devenir un choix d’architecture.
Ce chiffre mérite mieux qu’un titre. Il faut le démonter, le décortiquer, voir de quoi il est fait — et surtout voir ce qu’il cache. Car le « 12 points » officiel n’est pas le chiffre qui compte pour vous si vous ne pouvez télécharger que des poids publiés. Nous allons donc procéder en quatre temps : la méthodologie v5 et ce qu’elle change, l’anatomie exacte de l’écart, les causes techniques probables du décrochage, et enfin une grille d’arbitrage concrète pour votre agent en production.
v4 → v5 : la bascule vers l’agentique « sale »
Ce qui a changé dans v5 n’est pas cosmétique. C’est un changement de philosophie de mesure, et il faut le comprendre avant de discuter du moindre score.
La v4 mesurait encore, pour une large part, ce qu’on pourrait appeler de l’intelligence « propre » : des tâches bien délimitées, des réponses vérifiables, des formats standardisés. La v5 a introduit deux nouveaux benchmarks qui changent la nature de l’exercice. Le premier, FrontierCode 2.0 (développé par Cognition), plonge les modèles dans 132 tâches situées dans des dépôts open source réels, avec une notation binaire impitoyable : « un mainteneur mergerait-il ce changement ? » Un échec à un seul check bloquant, et le score tombe à zéro. Pas de crédit partiel, pas de consolation. Le second, Terminal-Bench-Science, ajoute 70 tâches agentiques de recherche scientifique — des tâches où il faut enchaîner des commandes, lire des sorties, corriger le tir.
Trois benchmarks ont par ailleurs été mis à niveau : HLE-Diamond (qui remplace Humanity’s Last Exam), AA-Omniscience v1.1 et CritPt v2. Et trois ont été retirés : GDPval-AA v2.1, SciCode et AA-LCR v1.1. Les maintenus — AA-Briefcase, AutomationBench-AA, GDP.pdf, Terminal-Bench 4.0 — restent dans la grille, mais repondérés.
La nouvelle pondération se répartit en quatre quarts égaux :
| Domaine | Poids | Composantes |
|---|---|---|
| Knowledge Work | 25 % | AA-Briefcase 15 %, AutomationBench-AA 5 %, GDP.pdf 5 % |
| Coding | 25 % | FrontierCode 2.0 15 %, Terminal-Bench 4.0 10 % |
| Science | 25 % | Terminal-Bench-Science 15 %, CritPt v2 hard 10 % |
| General | 25 % | AA-Omniscience v1.1 15 % (10 % accuracy + 5 % non-hallucination), HLE-Diamond 10 % |
Mais le vrai point de rupture n’est pas dans cette table. Il est dans cette phrase du post officiel : 60 % de l’Index v5 repose désormais sur des jeux de test privés ou des réponses retenues (held-out). Autrement dit, la majorité du score dépend de données que personne, en dehors d’Artificial Analysis, ne peut inspecter.
La justification est entendable : la contamination des benchmarks publics est devenue un fléau. Quand un jeu de test traîne sur GitHub depuis deux ans, il finit dans les corpus d’entraînement, et les scores deviennent des mesures de mémorisation déguisées en raisonnement. Le passage au privé est une réponse rationnelle à ce problème. Mais il a un coût : la reproductibilité s’effondre, et le biais joue en faveur des labos qui ont les moyens de faire du post-training sur des distributions proches de celles qu’Artificial Analysis garde en réserve. C’est un arbitrage, pas une vérité révélée.
Ce que la refonte mesure vraiment, en revanche, est clair : non plus la connaissance statique, mais la capacité à enchaîner des étapes, à utiliser des outils, à récupérer après une erreur. C’est de l’agentique « sale », celle qui se salit les mains dans les dépôts, les terminaux et les appels d’API qui échouent. Et c’est précisément là que les modèles ouverts trébuchent.
12 points, mais 12 points de quoi ? Anatomie d’un écart qui cache plusieurs écarts
Prenons le classement v5 tel que publié. En tête, les propriétaires :
| Rang | Modèle | Score v5 |
|---|---|---|
| 1 | Claude Opus 5.5 (max) | 58 |
| 2 | GPT-6 Astra (max) | 57 |
| 3 | GPT-6.1 Sol (max) | 55 |
| 4 | Gemini 4 Argon (high) | 50 |
Côté open weights, le meilleur score affiché est celui de Kimi K3.1 Pro, à 46 points. Sauf que — et c’est le piège de lecture majeur — ses poids ne sont pas publiés. Un praticien ne peut pas le télécharger, ne peut pas le déployer sur ses serveurs, ne peut pas le fine-tuner. Il existe dans le classement comme une promesse, pas comme un produit.
Si l’on ne regarde que les poids réellement disponibles, le tableau change du tout au tout. Les meilleurs modèles ouverts publiés — DeepSeek V4.1 Flash 1017 (max) et GLM-5.3 (max) — plafonnent à 32 points. Soit 26 points derrière le leader, et même sous Claude Haiku 5.5 (max, 36), qui n’est pourtant pas le fer de lance de son labo.
Voilà donc le nœud de l’affaire : le « 12 points » officiel est un écart composite. Il mélange deux réalités très différentes — l’écart entre les meilleurs modèles ouverts annoncés (46 vs 58, soit 12 points) et l’écart réellement actionnable pour qui ne peut télécharger que des poids publiés (32 vs 58, soit 26 points). Les deux chiffres sont vrais ; ils ne parlent simplement pas du même monde.
Faut-il pour autant prendre ces scores au pied de la lettre ? Prudence. Le post officiel ne détaille ni les intervalles de confiance, ni les tailles d’échantillon par sous-tâche, ni les dates exactes de snapshot des modèles évalués. Et surtout, aucune source indépendante n’a reproduit la méthodologie v5 à ce jour. Tout ce que nous savons provient du post d’Artificial Analysis lui-même. Ce n’est pas un motif de rejet — l’équipe a une réputation de sérieux — mais c’est un motif de calibrage : un écart de 12 points sur des tâches bruitées, avec des échantillons dont on ignore la taille, n’a pas la solidité d’un écart de 12 points sur un test standardisé de 10 000 items. L’absence de sources tierces doit inciter à traiter ces chiffres comme des ordres de grandeur robustes, pas comme des mesures au centième.
Kimi, DeepSeek, Mistral, Muse, Beam, Nemotron : le peloton ouvert n’est pas homogène
L’expression « open weights » suggère un bloc. C’est une fiction commode. Le peloton ouvert de v5 est en réalité traversé de lignes de fracture qui n’ont rien à voir avec le fait d’être ouvert ou fermé.
Kimi K3.1 Pro est le cas le plus intéressant — et le plus frustrant. Leader open à 46 points, il n’existe pour l’instant que comme annonce. Ses poids ne sont pas publiés, ce qui en fait un argument commercial autant qu’un modèle. Tant qu’il n’est pas téléchargeable, il ne compte pas dans une décision d’architecture.
DeepSeek V4.1 Flash illustre un autre profil : un excellent rapport performance/coût sur les tâches courtes, mais un décrochage marqué dès que la trajectoire s’allonge. C’est le comportement classique d’un modèle optimisé pour la réponse ponctuelle plutôt que pour l’enchaînement.
Mistral Large 4, lancé début octobre 2026, occupe un positionnement européen assumé. Sa faiblesse probable — et le conditionnel est de rigueur, faute de données publiques détaillées par sous-tâche — se situe sur le tool use multi-étapes, là où les labos américains et chinois ont investi massivement.
Muse Spark Open, le MoE de Meta (816 milliards de paramètres, 42 milliards actifs, contexte d’un million de tokens, publié le 15 octobre 2026), revendique explicitement les capacités agentiques. C’est le candidat ouvert le plus crédible sur le papier pour les charges agentiques — mais les classements v5 ne permettent pas encore de trancher finement son comportement en trajectoire longue.
Beam et Nemotron complètent le tableau avec des profils plus spécialisés. Pour Nemotron, notons que la famille s’est récemment illustrée sur un tout autre terrain — la transcription vocale avec Nemotron 3.5 Transcribe (28 octobre 2026) — ce qui rappelle que « Nemotron » désigne une gamme, pas un modèle unique, et que les scores d’un membre de la famille ne se transposent pas aux autres.
Ce que les classements ne montrent pas, en revanche, est peut-être plus important que ce qu’ils montrent : la variance entre runs (un modèle qui oscille de 5 points selon le tirage est-il fiable ?), la sensibilité au prompt système (certains modèles s’effondrent avec un system prompt mal calibré), et le fait que certains « open weights » ne le sont que sur le papier — poids non publiés, licences restrictives, conditions d’usage commercial limitantes. Le mot « ouvert » mérite aujourd’hui une vérification au cas par cas.
Pourquoi les open weights décrochent quand la tâche devient une trajectoire
Venons-en au cœur du sujet : pourquoi cet écart se creuse-t-il précisément sur les tâches agentiques, alors qu’il s’était refermé sur les tâches statiques ?
Quatre causes techniques probables se dégagent. Aucune n’est documentée publiquement avec la précision qu’on aimerait — les model cards des modèles ouverts restent discrètes sur le post-training agentique — mais elles convergent avec ce que l’on sait des recettes des labos fermés.
Première cause : le volume et la qualité du SFT sur trajectoires agentiques. Les labos fermés investissent massivement dans des données d’interaction réelles — des enregistrements d’agents en train de résoudre des tâches, avec leurs erreurs, leurs reprises, leurs hésitations. Les modèles ouverts héritent souvent de datasets plus courts, plus propres, moins divers. Or un agent ne s’entraîne pas sur des réponses justes : il s’entraîne sur des trajectoires, y compris des trajectoires qui échouent puis se rattrapent.
Deuxième cause : le RL tool-use avec reward models spécialisés. Entraîner un modèle à utiliser des outils par renforcement exige des environnements coûteux — des simulateurs d’API réalistes, des sandboxes, des systèmes de récompense capables de juger une trajectoire entière, pas seulement une réponse finale. C’est de l’ingénierie lourde, difficile à reproduire hors des grands labos.
Troisième cause : la robustesse aux erreurs de tool calls. Un agent en production reçoit des réponses malformées, des timeouts, des schémas JSON invalides. La capacité à parser tolérant, à réessayer intelligemment, à récupérer après un échec, est rarement optimisée explicitement dans les checkpoints ouverts. Elle émerge parfois, mais elle n’est pas un objectif d’entraînement déclaré.
Quatrième cause : le context management long. Les modèles ouverts tendent à perdre le fil au-delà de quelques dizaines de tours. Les fenêtres de contexte se sont considérablement allongées — un million de tokens chez Muse Spark Open, plus d’un million chez Kolibri-1 d’Aleph Alpha — mais la fenêtre n’est pas la tenue. Un modèle peut avoir un million de tokens de contexte et perdre la cohérence au trentième tour d’une trajectoire.
Il faut être clair sur le statut épistémique de ces explications : elles relèvent de l’hypothèse raisonnée, pas de la preuve publique. Aucune ablation détaillée, aucune model card exhaustive ne vient les confirmer pour les familles concernées. C’est une limite que nous assumons — et un appel aux labos ouverts pour qu’ils documentent leur post-training agentique aussi sérieusement que leurs benchmarks de connaissance.
Le piège du classement unique : ce que v5 ne mesure pas (et qu’il faut croiser)
Un score global de 58 ne dit rien de la performance sur votre workload. C’est la leçon la plus importante de toute cette affaire.
Premier réflexe à acquérir : regarder le coût par tâche. Le post officiel révèle un écart de plus de 13x parmi les dix meilleurs modèles — de 0,96 $/tâche pour GPT-6.1 Terra (max) à 13,04 $/tâche pour Claude Fable 5.1 (max). Autrement dit, deux modèles du top 10 peuvent avoir des scores proches et des coûts séparés par un ordre de grandeur. Un classement qui ignore le coût est un classement incomplet.
Deuxième réflexe : croiser avec des benchmarks complémentaires. SWE-bench Verified, Terminal-Bench, et surtout vos propres traces internes. Un modèle excellent sur FrontierCode 2.0 peut se révéler médiocre sur vos workflows métier.
Troisième réflexe : mesurer ce que v5 ne mesure pas. La liste est longue : latence, taux d’échec silencieux (l’agent qui « réussit » en faisant la mauvaise chose), robustesse aux tool calls malformés, tenue en contexte long, reproductibilité. Et les biais connus de v5 : 60 % de datasets privés non auditables, surpondération du coding et de la science, absence de mesure de fiabilité en production.
Comment construire un mini-benchmark maison en une semaine ? Trois étapes suffisent. D’abord, extraire 30 à 50 trajectoires réelles de vos logs, avec leurs issues (succès, échec, échec silencieux). Ensuite, les rejouer sur chaque candidat avec un prompt système identique et un harnais de tool calls contrôlé. Enfin, noter non pas la réponse finale mais la trajectoire : nombre de tours, reprises après erreur, qualité des appels d’outils. Une semaine de travail qui vous en apprendra plus que n’importe quel leaderboard.
Arbitrer en pratique : open weights ou API fermée pour votre agent en production ?
La grille de décision tient en quelques questions.
Quand payer une API fermée se justifie : tâches à fort enjeu où une erreur coûte cher ; trajectoires longues (plus de quelques dizaines de tours) ; tool use critique où la robustesse aux erreurs est non négociable ; besoin de SLA de fiabilité contractuel. Dans ces cas, l’écart de 12 points — ou de 26 points sur les poids réellement publiés — n’est pas un détail, c’est un argument massif.
Quand les open weights restent le bon choix : volume massif où le coût par token domine ; souveraineté des données (santé, secteur public, industrie régulée) ; fine-tuning sur un domaine spécialisé où un modèle plus petit mais entraîné sur vos données battra un géant généraliste ; latence maîtrisée en on-premise ; déploiement sans dépendance à un fournisseur.
Les stratégies hybrides sont souvent les plus rentables. Un routeur de modèles qui envoie les tâches simples vers un modèle ouvert et les étapes critiques vers une API fermée. Une distillation de trajectoires propriétaires vers un modèle ouvert fine-tuné — vous payez l’API une fois pour générer les données, puis vous exploitez un modèle ouvert qui a appris vos workflows. Un fallback automatique en cas d’échec de tool call, qui bascule sur un modèle fermé quand l’ouvert abandonne.
Les coûts cachés des deux options méritent d’être posés franchement. Côté ouvert : l’ingénierie d’infrastructure (serving, GPU, monitoring) et l’ingénierie d’évaluation (benchmarks maison, harnais de test) représentent souvent plus de travail que le fine-tuning lui-même. Côté fermé : la dépendance à un fournisseur, la tarification imprévisible, et le risque de voir un modèle déprécié du jour au lendemain.
Ce que la refonte v5 change pour l’écosystème (et ce qu’il faut surveiller ensuite)
La bascule d’Artificial Analysis vers 60 % de données privées et vers des tâches agentiques réelles acte un changement de régime. On ne mesure plus la connaissance, on mesure la fiabilité opérationnelle. C’est un progrès — les benchmarks saturés ne disaient plus rien — mais c’est aussi un déplacement du pouvoir : celui qui détient les jeux de test détient la définition de l’excellence.
Pour les labos open weights, la pression est claire : publier des poids réellement ouverts (pas des annonces), et documenter sérieusement le post-training agentique dans les model cards. Pour les praticiens, la conclusion est tout aussi nette : les benchmarks internes ne sont plus un luxe, c’est la condition d’un choix éclairé. Pour la gouvernance, enfin, l’opacité des datasets privés pose une question de fond — celle du benchmark washing, où un classement opaque devient un outil marketing plutôt qu’un instrument de mesure.
Ce qu’il faut surveiller dans les prochains mois : la publication effective des poids de Kimi K3.1 Pro (qui ferait passer le leader open réel de 32 à 46 points), l’arrivée de versions « agentiques » des familles ouvertes — Muse Spark Open est le candidat le plus crédible —, et l’émergence de benchmarks indépendants et reproductibles pour contrebalancer v5.
L’écart de 12 points n’est pas une fatalité technique. C’est le prix actuel d’un investissement en post-training agentique que seuls quelques acteurs peuvent se permettre. Il se resserrera, comme se sont resserrés tous les écarts précédents. En attendant, la seule erreur vraiment coûteuse serait de choisir son modèle sur un seul chiffre.
Sources
- Artificial Analysis — Intelligence Index v5 (post officiel, 27 octobre 2026)
- Artificial Analysis — changelog
- Meta — Introducing Muse Spark Open (15 octobre 2026)
- SiliconANGLE — Mistral launches open-source Mistral Large 4 (6 octobre 2026)
- MSN — Agentic AI Benchmarks Widen Proprietary-Model Edge to 12 Points in Artificial Analysis v5 Overhaul
- Unite.AI — 10 Best Open Source LLMs (novembre 2026)
- LLM-Stats — Open LLM Leaderboard 2026
Article recherché et rédigé automatiquement · Magazine Electrosens