Meta Muse Spark 1.1 à l'épreuve : un plafond haut et un plancher bas

Ce que j'entends par test, et ce que je n'ai pas pu vérifier

Muse Spark 1.1 est sorti le 9 juillet 2026, il a donc passé environ quatre semaines dans la nature, et non quatre jours. Cela change beaucoup de choses. Il existe désormais des données indépendantes, pas seulement les impressions du jour du lancement. Le tableau d'ensemble de l'entreprise se trouve dans mon panorama de Meta AI.

Il y a moins de retours de première main qu'un lancement de pointe n'en génère habituellement, et la raison est structurelle. La Meta Model API a ouvert exclusivement aux États-Unis. Des développeurs ont rapporté avoir été bloqués dès le premier jour depuis le Vietnam, le Canada et l'Argentine, et le modèle n'a rejoint OpenRouter qu'environ une semaine plus tard. Un commentateur a résumé l'effet concret sans détour :

« Le fait que ce ne soit pas disponible sur Openrouter rend vraiment les choses difficiles à tester. J'allais le comparer à Grok 4.5 et GPT-5.6 Luna, mais je n'ai pas envie de m'inscrire chez Meta pour ça tant que je ne sais pas si ça vaut le coup. »

mchusma, Hacker News

Un fil de lancement à 413 points n'a donc produit qu'une poignée de retours d'usage réels. Tout ce qui suit s'appuie sur trois types de sources : les tests indépendants d'Artificial Analysis et le propre rapport d'évaluation de Meta, long de 105 pages, plus le petit nombre d'ingénieurs qui ont réellement réussi à le faire fonctionner. Là où personne n'a rien testé, je le dis au lieu de combler le vide.

Le graphique qui explique tous les autres résultats

Voici le classement de Muse Spark 1.1 sur les benchmarks qui composent l'Intelligence Index. Même modèle, même semaine, un seul labo qui fait passer tous les tests.

La plupart des modèles sont ennuyeux d'une manière utile. Ils se situent à peu près au même percentile quel que soit le test, si bien qu'un seul chiffre permet de prédire le reste. Ce n'est pas le cas ici. L'écart entre son meilleur et son pire classement est plus large que tout l'écart entre le haut et le bas de la plupart des gammes de prix.

C'est pourquoi le chiffre phare que tout le monde répète, 50,6 contre 60,7 pour Opus 5, ne dit presque rien d'exploitable. Il fait la moyenne d'un excellent résultat et d'un mauvais. Ce qu'il faut savoir, c'est lequel des deux on achète réellement.

Là où il gagne vraiment

Trois choses sont bien réelles ici, et je préférerais que la critique qui suit ne les enterre pas.

Il écrit bien le code. Pas « bien pour le prix ». Bien, tout simplement. Sur SciCode, il bat Claude Opus 5, GPT-5.6 Sol et Grok 4.5. La formule « Meta a du retard en programmation », entendue après le lancement, concerne les longues exécutions d'agent, pas la génération de code, et ce sont deux métiers différents.

C'est le plus rapide du tableau. 217,4 tokens de sortie par seconde contre 55,7 pour Claude Opus 5, et un peu devant Gemini 3.6 Flash à 213,5. Pour tout usage exposé à l'utilisateur, on ressent une différence de débit de 4x avant même que quiconque la mesure.

Le tarif de mise en cache est la partie la mieux conçue du produit. À 0,15 $ par million, c'est une remise de 88%, appliquée automatiquement, sans aucune clé de cache à gérer. Un ingénieur a expliqué pourquoi ce ratio compte plus que le prix affiché :

« Le tarif des entrées en cache a un bon ratio. Compare avec Grok 4.5, sorti à 2 $/6 $ mais qui facture ensuite discrètement 0,50 $ par million de tokens d'entrée en cache. C'est aussi élevé que chez Opus 4.8 ! »

Aurornis, Hacker News

En mettant tout cela bout à bout, le bon cas d'usage prend une forme évidente : prompts courts, prompt système stable, volume énorme, une décision par appel. Classification par lots, étiquetage, extraction, routage. La grille tarifaire complète est dans mon dossier sur le prix de Muse Spark 1.1. Pour le reste du marché, commence par le prix de Claude. La gamme OpenAI tient dans un seul tableau sur tous les modèles OpenAI.

Là où ça se casse

Meta a positionné ce modèle comme un modèle agentique. Son annonce met en avant l'usage d'outils et les workflows multi-étapes, la ligne même qui sépare les agents des chatbots. Le test équitable, ce sont donc les évaluations agentiques indépendantes. C'est ici que le test bascule.

La contradiction est difficile à manquer. Le modèle vendu sur l'usage agentique d'outils est le plus faible en performance agentique du tableau indépendant. Sur GDPval, il accuse 481 Elo de retard sur Opus 5, et les intervalles de confiance ne recouvrent rien au-dessus de lui. En usage agentique d'outils, il est même derrière DeepSeek V4 Flash, qui coûte 0,14 $ en entrée et 0,28 $ en sortie.

Meta ne le conteste pas totalement. Son propre rapport d'évaluation reconnaît que « pour les tâches agentiques à long horizon (par exemple DeepSWE et DeepSearchQA), des améliorations significatives restent en retard sur, ou au mieux à égalité avec, les modèles concurrents les plus performants ». Cet aveu est mesuré par rapport à Opus 4.8 et GPT-5.5, tous deux une génération en retard sur ce qu'on achèterait aujourd'hui.

La lecture de la communauté est arrivée à peu près à la même conclusion. Un commentateur, en le voyant apparaître près du sommet d'un classement de programmation, y a vu la preuve que le classement était cassé :

« votre benchmark est manifestement bancal quand les 3 meilleurs modèles en Typescript (Combined) sont Grok 4.5, Muse Spark 1.1 (lol), Gemini 3.5! Flash »

eis, Hacker News

La formulation la plus incisive est venue d'un duel entre quatre modèles. Une personne y était déconcertée que Muse Spark ait produit le meilleur artefact unique du lot tout en obtenant 2 sur 5. La clarification résume tout le modèle en une phrase :

« 2/5 n'est pas une note de qualité, c'est de la cohérence, comme c'est écrit là. Les liens complets sont en bas. La plupart des tentatives de Spark sont des échecs »

rsstack, Hacker News

Plafond haut. Plancher bas. Tout le reste de ce test en découle.

La session unique la plus longue jamais publiée arrive au même constat. Trois heures avec le modèle, par un développeur qui l'a fait tourner via une CLI de codage :

« Je viens de l'essayer pendant 3 heures d'affilée, et je dois dire que je suis déçu. Je ne sais pas ce qui arrive à Meta ces derniers temps, mais il faut se souvenir qu'ils sont les créateurs de Llama, ceux qui ont déclenché la vague open source des modèles. Même en closed source (du moins maintenant), je dirais que ça se situe entre Kimi 2.7 et GLM 5.2, loin d'être au niveau d'Opus 4.8 medium/Sonnet5 »

u/FBIFreezeNow, Reddit

À prendre avec des pincettes. C'est l'après-midi d'une seule personne, et il ne rapporte aucun chiffre mesuré. Presque personne ne le fait. Sur quatre semaines de Reddit et Hacker News, on compte à peine une douzaine de retours de première main réels sur l'utilisation de ce modèle, et aucun d'entre eux ne publie de chiffre qu'il aurait mesuré lui-même. Personne non plus n'a soumis publiquement la fenêtre de 1M de tokens à un test de charge. En partie à cause du blocage régional, en partie parce qu'un modèle pour lequel on ne peut pas obtenir de clé API n'est pas benchmarké par les amateurs.

Le mode d'échec que Meta documente lui-même

C'est la partie que je voudrais connaître avant de brancher ce modèle sur quoi que ce soit. Elle est enfouie dans la documentation, pas dans l'article de lancement.

Muse Spark 1.1 garde sa chaîne de raisonnement privée, ce qui est normal aujourd'hui. Ce qui est inhabituel, c'est ce qui se passe sur la voie d'intégration la plus courante. La propre documentation de Meta sur le raisonnement indique que sur Chat Completions, le champ reasoning_content est caviardé et renvoyé vide avant d'atteindre l'appelant, « de sorte qu'il n'y a rien à rejouer et que chaque tour raisonne à partir de zéro ».

Le guide des agents de programmation de Meta en tire la conséquence : le modèle « peut perdre le fil de son propre raisonnement antérieur et se comporter de façon erratique : répéter un travail déjà fait, se contredire par rapport à des étapes précédentes ».

Un modèle vendu sur du travail agentique multi-étapes oublie son propre raisonnement entre les tours sur la voie qu'utilisent par défaut la plupart des outils. Le raisonnement multi-tours ne survit que sur la Responses API, où le serveur conserve le contexte à ta place via previous_response_id.

Rien de tout cela n'est théorique. Le meilleur retour d'expérience pratique depuis le lancement décrit exactement ce type de problème, et il vient d'un ingénieur qui a réussi à faire tourner Codex face à l'API dans un conteneur :

« C'est une sorte d'erreur de parsing ou d'intégration, due à ce que je pense être le fait que codex n'anticipe pas l'appel d'outils côté serveur et la façon dont meta traite ces identifiants... les premières fois que j'ai exécuté codex avec muse, ça échouait dès le premier appel qui n'était pas une recherche web. »

weitendorf, Hacker News

Il a réglé le problème et est resté positif sur le modèle. L'essentiel, c'est que deux sources indépendantes, la documentation de Meta elle-même et la première personne à l'avoir intégré dans un environnement réel, arrivent à la même cause profonde. La tuyauterie agentique est sur mesure, et les environnements tiers trébuchent dessus.

Le chiffre d'hallucination que tout le monde cite est le mauvais

Ici, je dois corriger une lecture flatteuse qui circule, ma propre couverture antérieure incluse.

Muse Spark 1.1 a effectivement un bon taux de non-hallucination, c'est-à-dire qu'il refuse de répondre plutôt que d'inventer quelque chose assez souvent. C'est vrai, et cela vaut quelque chose. Mais l'indice composite de fiabilité des connaissances, qui récompense les bonnes réponses et pénalise les hallucinations, le place à 18,0. C'est le plus bas des douze configurations listées sur sa propre page de modèle. Claude Opus 5 obtient 31,3.

Les propres tests d'alignement de Meta le confirment, avec un langage plus direct que tout ce qu'un concurrent a publié. Extrait de l'évaluation Petri 3.0 dans son rapport : « l'hallucination en entrée (1,67) est la principale, plus élevée que GPT-5.5 (1,22) et Claude 4.8 Opus (1,34) ». Le même passage signale une tromperie accrue envers les utilisateurs et un excès de refus accru.

Ainsi, deux sources indépendantes, dont Meta elle-même, arrivent à la même conclusion : l'hallucination est la dimension la plus faible de ce modèle, pas la plus forte.

Même ce chiffre-là n'est pas celui sur lequel je baserais une décision de déploiement pour le support, cela dit. Voici celui qui compte :

Chaque benchmark d'hallucination mesure si un modèle invente des faits sur le monde. Presque aucun échec en support ne ressemble à cela. Une équipe de support technique B2B avec laquelle nous avons travaillé, traitant environ 200 tickets par mois sur Zendesk avec une montée en charge vers 2 000, est tombée sur la vraie version du problème. Leur bot disait aux clients qu'il prenait en charge des véhicules absents de leur base de données, parce que leur propre centre d'aide indiquait « nous prenons en charge tous les modèles ». Le modèle était fidèle à sa source. C'est la source qui avait tort.

Aucun score sur aucun classement ne détecte cela. C'est pourquoi entraîner une IA sur une base de connaissances est un problème de contenu avant d'être un problème de modèle, et pourquoi les seuils de confiance font plus pour la qualité des réponses qu'une amélioration du raisonnement ne le fera jamais.

La même logique s'applique en amont. Bien faire le tri des tickets fait bouger le taux de résolution de façon plus fiable qu'un changement de modèle. Les schémas d'échec sont suffisamment cohérents pour que les problèmes des chatbots IA les répertorie mieux que n'importe quelle fiche de modèle.

La vitesse est réelle, mais regarde la bonne horloge

Le chiffre de débit est réel, et c'est la meilleure statistique individuelle du modèle. Le chiffre de latence a besoin d'une correction.

Les 2,89 s bruts de Meta pour le délai jusqu'au premier token sont les meilleurs du tableau. Ce n'est cependant pas ce que vit un utilisateur. En ajoutant 9,2 secondes de raisonnement invisible, le premier token réellement utile arrive à 12,09 s. C'est tout de même nettement mieux qu'Opus 5, donc la conclusion tient. Mais c'est quatre fois plus lent que ce que suggère le chiffre phare.

Ce même raisonnement invisible explique aussi l'histoire du coût. 68% des tokens de sortie facturés sont de la réflexion que l'appelant ne voit jamais, avec 15 164 tokens de raisonnement contre 7 232 tokens de réponse par tâche. Sur l'exécution complète de l'index d'Artificial Analysis, 360 $ sur un total d'environ 548 $ sont partis dans le raisonnement. Tokens bon marché, habitude de réflexion coûteuse. C'est la raison pour laquelle le coût du service client par IA ne colle jamais à la grille tarifaire.

Quatre pièges à connaître avant de commencer

Aucun d'entre eux n'est rédhibitoire. Chacun coûte un après-midi si on le découvre à froid.

1. tool_choice n'accepte que "auto". On ne peut pas forcer un outil précis, et il n'existe ni "required" ni "none". Tout autre valeur renvoie une erreur 400.
2. La sortie structurée est désactivée par défaut. Avec strict: false, la référence de Meta sur l'appel d'outils avertit que les arguments générés « ne sont pas garantis de valider » ton schéma. Valide avant d'exécuter quoi que ce soit.
3. Claude Code demande trois changements distincts. Une URL de base sans /v1, les cinq alias de modèle redirigés vers muse-spark-1.1, puis ANTHROPIC_AUTH_TOKEN à la place de ANTHROPIC_API_KEY.
4. MCP est annoncé mais non documenté. L'article de lancement affirme que le modèle se généralise aux serveurs MCP et aux compétences personnalisées. La référence d'appel d'outils ne documente ni l'un ni l'autre. Les outils définis par le développeur sont la seule voie d'extensibilité réellement montrée.

Il n'existe pas non plus de plafond côté serveur pour les boucles d'outils personnalisés qui s'emballent. max_tool_calls limite uniquement les outils intégrés de Meta, ce qui vaut la peine d'être su si tu as déjà vu une boucle d'agent IA tourner à vide. La moitié « délégation » de ce sujet est couverte dans l'orchestration de sous-agents, et l'argument pour le tester soi-même se trouve dans les évaluations d'agents.

Ce que Meta n'a toujours pas publié

Les manques font aussi partie du test, et cette liste est plus longue qu'elle ne devrait l'être quatre semaines après le lancement.

Meta n'apparaît pas non plus sur le classement officiel de Terminal-Bench, si bien que le score autodéclaré à cet endroit n'a aucune confirmation tierce. Mon panorama de Muse Spark 1.1 couvre le litige méthodologique autour de ce chiffre. Il reste non résolu.

Qui devrait l'acheter, et qui devrait passer son chemin

Achète-le si tu gères du travail à haut volume et à horizon court : classification, étiquetage, extraction, routage, génération de code sur un seul fichier, tout ce où un appel produit une réponse et où tu fais des millions de ces appels. La vitesse est réelle et le tarif de cache est excellent, et à environ 0,29 $ par tâche, les économies par rapport au prix d'Opus 5 sont assez importantes pour compter.

Passe ton chemin si ta charge de travail concerne des agents à longue durée de vie, des exécutions de recherche approfondie, ou tout ce qui doit raisonner sur un vaste ensemble de documents. Les chiffres agentiques indépendants ne sont pas du tout à la hauteur. C'est l'un des rares cas où payer pour GPT-5.6 ou Opus 5 revient moins cher une fois qu'on compte les nouvelles tentatives. Pour les environnements de programmation en particulier, Codex est aujourd'hui la voie la mieux documentée.

Attends si tu es en dehors des États-Unis, ou si tu as besoin d'une politique de conservation publiée, ou de poids ouverts. Sur ce dernier point, Kimi K3 est l'option la plus proche de la frontière technologique avec des poids que tu peux réellement récupérer. Le virage vers des poids fermés est la partie de ce lancement que la communauté a le moins pardonnée.

La lecture modérée, venant de quelqu'un qui suit le classement, est assez juste pour que je la signe :

« Nouveau respect pour Meta Muse Spark. Il semble se placer à beaucoup d'endroits idéaux dans le classement. Il n'est le meilleur en rien en particulier, mais il équilibre plutôt bien coût et performance. »

drob518, Hacker News

Ce que ça change pour une file de support

Presque rien. Je le dis en tant que personne dont le travail consiste en partie à remarquer quand un nouveau modèle change vraiment quelque chose.

Toutes les quelques semaines, un modèle moins cher et plus rapide sort, et quelqu'un demande si cela réécrit le plan de son service d'assistance. La réponse honnête, c'est que le modèle n'a jamais été la contrainte. Dans les propres essais croisés d'eesel, quand des agents réécrivaient un brouillon d'IA, environ 65% des modifications concernaient la longueur et le ton. Environ 20% avaient besoin de données que l'IA ne pouvait pas atteindre dans un ERP ou un système logistique. Seuls environ 5% correspondaient à l'IA se trompant sur les faits. Un meilleur modèle règle exactement ces derniers 5%. Le reste, ce sont l'ingénierie de prompt, la recherche documentaire, le coaching des agents sur les réponses réellement envoyées par ton équipe, et la profondeur d'intégration.

C'est aussi pourquoi la rédaction de type copilote est le point de départ pour la plupart des équipes, le modèle derrière les outils d'assistance à l'agent, et pourquoi un chemin d'escalade propre compte plus qu'une position dans un classement. Si tu construis un argumentaire business plutôt qu'une stack technique, le coût de l'IA face à celui d'un humain est le cadre le plus utile.

L'échec que je surveille le plus attentivement en production est celui qu'aucun benchmark sur la page de lancement de Meta ne mesure. Un agent qui raconte une recherche qu'il n'a jamais effectuée. Qui rapporte des fichiers qu'il n'a jamais enregistrés. Un agent qui prétend avoir fait le travail est un problème plus difficile qu'un agent qui le fait mal, et un modèle qui oublie son propre raisonnement entre les tours n'est pas celui à qui je ferais confiance pour rendre compte de lui-même.

Essaie eesel pour le support, pas une simple clé de modèle brute

Si ce que tu veux vraiment, c'est une IA qui répond aux tickets clients, la question utile n'a que peu à voir avec le modèle qui domine l'index ce mois-ci. Elle est plutôt : peux-tu prouver que la chose est sûre avant qu'elle ne réponde à qui que ce soit ?

C'est exactement autour de cela qu'eesel est construit. Tu peux faire tourner un agent IA en simulation sur tes propres tickets historiques, et lire ses réponses sur de vraies conversations passées avant qu'un seul client n'en voie une. Si les réponses ne sont pas encore au niveau, tu commences en mode copilote, où il rédige et ton équipe continue d'envoyer.

La mise en place, c'est une connexion à ton service d'assistance, pas un projet. Elle se branche sur Zendesk en quelques minutes, lit le centre d'aide que tu as déjà rédigé, et facture par ticket résolu plutôt que par million de tokens, si bien que la facture reflète le travail effectué plutôt que la verbosité du modèle ce jour-là. Gratuit à l'essai, et le prix est public.

Le verdict

Muse Spark 1.1 est un bon modèle qui porte la mauvaise étiquette. Meta a vendu un agent, et les benchmarks agentiques sont ses pires résultats. Au vu des preuves, c'est le meilleur modèle rapide et bon marché à réponse unique disponible en ce moment, avec un excellent score en génération de code et un tarif de cache que personne d'autre n'égale.

Juge-le sur le travail que tu as, pas sur la catégorie où Meta l'a classé, et il devient facile de le situer. Achète-le pour les millions d'appels courts. Garde quelque chose de plus puissant pour les longues exécutions. Et ne laisse pas une fenêtre de 1M de tokens te dissuader de la recherche documentaire. À environ un huitième du coût par tâche d'Opus 5, être le deuxième meilleur sur les bons travaux reste un très bon calcul.