Meta Muse Image : le modèle, l'API et l'image à prix fixe de 0,01 $

Si vous avez recherché le nom désambiguïsé et êtes arrivé ici, la réponse courte est la suivante : Meta Muse Image est le modèle agentique de génération et d’édition d’images de Meta, il est propriétaire plutôt qu’à poids ouverts, et vous l’appelez via l’API Model de Meta sous l’identifiant muse-image-1.0 à un tarif forfaitaire de 0,01 $ par image générée, avec l’ancrage par recherche inclus dans ce prix. C’est toute la réponse à la question que pose la recherche, et tout ce qui suit en est la référence — ce que fait le modèle, comment y accéder, quelle est réellement l’unité de facturation, ce que Meta documente au sujet de la provenance, et où la documentation s’arrête.

Deux choses au sujet de la justification de cette page méritent d'être dites clairement, car cette famille a déjà été annoncée plus d'une fois et un second article d'annonce ferait doublon avec la couverture que nous publions déjà. Il s'agit de la page de référence canonique pour ce nom : la destination à laquelle un lecteur arrive après l'avoir recherché. Sa justification est une demande permanente que nous avons mesurée en propre le 29 septembre 2026 — les lecteurs tapent la forme désambiguïsée de ce nom selon trois orthographes, à hauteur de centaines d'impressions, à une position que nous devons à d'autres pages, par accident, plutôt qu'au fait d'avoir écrit une page conçue comme celle-ci, et son taux de conversion est proche de zéro parce que rien de ce que nous publions n'a la forme d'une référence. Cette mesure est un fait concernant ce que les gens tapent, et rien d'autre ; elle ne dit rien de la qualité ou de la popularité du modèle dans le monde. Et l'ancre datable sert ici de fait pour dater le modèle, non d'événement à rapporter : l'article de lancement de Meta pour Muse Image et Muse Video porte la date du 7 juillet 2026 et décrit le modèle comme « disponible dès aujourd'hui » sur les surfaces grand public de Meta à cette date ; le 7 juillet 2026 est donc la date de lancement sur laquelle s'appuie cette page. Chaque chiffre ci-dessous a été relevé sur les propres pages de Meta le 29 septembre 2026, sauf indication contraire dans la phrase.

Ce qu'est réellement Muse Image

La description en une ligne de Meta est le point de départ, car elle fait un vrai travail plutôt que du marketing : Muse Image est « une génération d'images agentique, ancrée par la recherche et tarifée pour des volumes de production à 0,01 $/image ». Sur la page du modèle de Meta, la surface de capacités se décompose en quatre modes de travail — génération d'images, édition précise, composition ancrée et affinement multi-tours — et la documentation destinée aux développeurs résume la même chose en une phrase : « Muse Image génère et modifie des images à partir d'une conversation. »

Selon Meta, l'argument distinctif est que Muse Image « est un modèle d'image qui raisonne avant de générer le rendu ». La publication de lancement de Meta rend cette affirmation concrète plutôt que théorique : « Au lieu de mapper directement les prompts aux images, Muse Image fonctionne comme un agent : il invoque des outils de recherche et de codage pour améliorer la précision, raffine ses propres générations et s'améliore grâce à la mise à l'échelle du calcul d'inférence. » En pratique, cela signifie que le modèle planifie avant de dessiner, récupère des références en direct sur le web lorsqu'un prompt touche à des faits du monde réel, et écrit et exécute du code lorsque la précision compte — la voie que Meta décrit pour des graphiques et des QR codes précis — puis vérifie le résultat avant de le renvoyer.

Les trois capacités que Meta cite en premier sont celles sur lesquelles il faut l’évaluer, et elles sont énoncées dans la propre phrase de Meta : Muse Image « suit fidèlement les instructions, effectue des modifications avec précision et compose à partir de plusieurs références ». L’affirmation sur la modification est la plus pointue des trois, car elle porte sur la retenue plutôt que sur le résultat : la page du modèle de Meta indique que le modèle « est conçu pour modifier exactement ce que vous spécifiez et ne rien toucher d’autre », et prend en charge un raffinement itératif au fil des échanges plutôt que des modifications en une seule passe. La composition est le domaine du mode « composition ancrée » — ancrer « toute une série de générations sur un petit ensemble d’images de référence afin que le personnage, le style et le décor restent cohérents d’une image à l’autre », ce qui est la capacité qui compte si vous produisez un catalogue ou une série d’annonces plutôt qu’une seule image. Prises ensemble, ce sont ces affirmations qui distinguent un modèle d’image avec lequel on génère d’un modèle sur lequel on construit un pipeline, et ce sont des affirmations de fournisseur : Meta ne publie aucun benchmark indépendant sur le suivi d’instructions ou la fidélité des modifications pour ce modèle.

Le cadrage agentique ne concerne pas uniquement les outils. Meta présente Muse Image comme étant associé à Muse Spark, son modèle de raisonnement, afin que « les deux modèles partagent des outils et planifient conjointement pour une génération de médias agentique puissante » — l'exemple documenté étant une sortie en plusieurs parties, comme des GIF animés, des pages avec des images intégrées et de petits jeux interactifs. Si vous développez quoi que ce soit qui mêle des images générées à du texte ou du code générés, cette association est l'élément de conception qu'il vaut la peine de comprendre, et c'est la raison pour laquelle le modèle est servi sur la même API et avec la même authentification que Muse Spark, plutôt que sur un point de terminaison d'images distinct avec ses propres identifiants.

Comment vous l'appelez : la surface d'API

Muse Image is reached through Meta's Model API, and the developer documentation is specific about the shape of that call. The model identifier is muse-image-1.0, passed as the model field on every request. Requests go to the base URL https://api.meta.ai/v1 with a bearer token — the documentation notes that it uses the same base URL and auth as Muse Spark — and there are two image endpoints plus a conversational one:

• Générer — POST /v1/images/generations, invite textuelle en entrée, image en sortie.

• Modifier — POST /v1/images/edits, prompt et images d'entrée, pour le travail image à image.

• Affiner au fil des tours — POST /v1/responses, l'API Responses, qui correspond au fonctionnement du flux multi-tours documenté.

Sur les points de terminaison d’images, les paramètres documentés sont peu nombreux et méritent d’être mémorisés, car c’est là que se décident le coût et le format de sortie. n prend une valeur de 1 à 10 et vaut 1 par défaut. size prend une chaîne "WxH" telle que 1792x1024, et la documentation précise explicitement que, sur ces points de terminaison, il « ne définit que le rapport d’aspect, pas les pixels exacts » — ne l’interprétez pas comme une garantie de résolution. response_format est b64_json par défaut ou url, et output_format est webp par défaut, avec png et jpeg disponibles. Le comportement agentique peut être activé ou désactivé : les points de terminaison d’images prennent une tool_enablement extension couvrant enable_image_search, enable_web_search et enable_shell, ainsi qu’un reasoning_strength de high (la valeur par défaut) ou low. Réduire le raisonnement est le levier pour le coût et la latence, et c’est la première chose à tester en A/B sur vos propres prompts plutôt que de la croire sur parole.

Sur l’API Responses, les mêmes contrôles se trouvent à l’intérieur d’un image_generation objet outil dans tools, avec la recherche d’images, la recherche web et le shell tous activés par défaut, et le tableau de sortie revient dans un ordre fixe : un élément de raisonnement résumant ce que le modèle a planifié et consulté, un élément de message, puis un élément image_generation_call par image. L’image elle-même se trouve dans le champ result de cet élément, au format base64, et son id est documenté comme un identifiant signé que vous renvoyez pour continuer à modifier la même image lors d’un tour ultérieur. Cet identifiant est le mécanisme qui sous-tend l’affinage multi-tours — c’est ainsi que vous évitez de re-téléverser une image pour en modifier un détail. Les deux points de terminaison d’images acceptent également stream: true, ce qui émet image_generation.completed pour la génération et image_edit.completed pour les modifications. Model API est documentée comme étant compatible sans modification avec le SDK OpenAI, le SDK Anthropic et les CLI d’agents compatibles OpenAI, de sorte qu’un appel d’image existant est un simple changement de chaîne de modèle plutôt qu’une réécriture.

Une mise en garde qui a sa place dans la référence plutôt que dans une note de bas de page : Meta n’a pas publié de limites de débit pour Muse Image que nous ayons pu consulter. La page relative aux limites de débit sur le propre site développeur de Meta ne renvoyait qu’une coquille vide, sans aucun chiffre, tout comme la page de tarification. Si le débit compte pour votre conception, il s’agit d’une inconnue que vous découvrirez via l’API plutôt que dans la documentation.

Le prix, et l’unité dans laquelle il est exprimé.

Un centime par image. Ce chiffre provient de la page modèle de Meta consacrée à Muse Image, qui répertorie le modèle dans un tableau tarifaire où l'ancrage par recherche et le raisonnement sont tous deux indiqués comme inclus, le prix étant donné sous la forme $0.01/image ; la documentation destinée aux développeurs le reformule ainsi : « Muse Image est facturé à un tarif fixe de $0.01 par image générée. » L'unité est l'image, et non le jeton — la documentation le dit explicitement (« Muse Image n'est pas facturé au jeton ») — et cela a son importance, car les API d'images qui expriment leur consommation en jetons sont généralement facturées au jeton. Muse Image renvoie un bloc d'usage comportant le nombre de jetons d'entrée et de sortie, et ces chiffres ne sont fournis qu'à titre indicatif.

Trois détails de facturation découlent de l'unité. Premièrement, n est un multiplicateur : une requête qui renvoie dix images est facturée pour dix images, donc le 1–10 paramètre est autant un contrôle des dépenses qu'un simple confort d'utilisation. Deuxièmement, les échecs ne sont pas facturés — les images dont la génération échoue ou qui sont retirées par le filtrage de sécurité avant d'être renvoyées ne sont pas comptabilisées. Troisièmement, l'ancrage par recherche est inclus dans le prix par image plutôt que facturé sur une ligne distincte ; la documentation de Meta indique qu'il « fait partie du prix par image, de sorte qu'il n'entraîne aucuns frais d'ancrage par recherche distincts ». Ce dernier point est celui qui rend ce tarif pertinent pour le travail agentique : un modèle qui effectue des recherches sur le web avant de générer une image peut produire plusieurs appels d'outils derrière une seule sortie, et Meta affirme que ces appels d'outils ne sont pas facturés séparément de l'image.

Nous n'avons pas pu corroborer ce chiffre à partir d'une grille tarifaire, et cela vaut la peine d'être dit plutôt que passé sous silence. Chaque URL de tarification du domaine développeur de Meta que nous avons récupérée renvoyait une coquille de page sans aucun montant en dollars, de sorte que la page du modèle et la documentation sur la génération d'images sont les deux endroits où ce chiffre existe sous la forme d'un énoncé lisible. Si vous avez besoin d'une seconde source pour l'approvisionnement, il n'y en a aucune sur le site de Meta aujourd'hui.

Ce qu'un centime vous achète en pratique, c'est un changement de décision plutôt qu'une remise. La formulation employée par Meta sur la page du modèle est que celui-ci « vous permet d'exécuter des charges de travail que la tarification des modèles de pointe rendait auparavant hors de portée » — génération de variantes publicitaires, imagerie de catalogue et personnalisation par utilisateur — et à ce tarif, cent mille images reviennent à environ 1 000 $. Si vous comparez ce tarif aux modèles d'image premium que vous payez peut-être déjà, la bonne démarche est de tester les deux sur vos propres prompts et avec votre propre évaluation, et c'est le centime par image qui rend cette comparaison suffisamment bon marché pour être réellement réalisable.

Provenance : ce que Content Seal règle et ne règle pas

Meta embarque avec ce modèle un système de filigrane invisible, et le documente avec assez de précision pour qu'il vaille la peine d'être cité : « Muse Image inclut Content Seal, notre système de filigrane invisible. Les images créées par Muse Image dans l'application Meta AI et sur meta.ai portent un signal de provenance caché qui reste intact — même lorsqu'elles sont recadrées, compressées, redimensionnées ou font l'objet d'une capture d'écran. » Meta indique qu'il prévoit d'étendre Content Seal à la vidéo, et présente en avant-première un outil de détection qui permet de vérifier si une image porte la marque.

Lisez attentivement la portée de cette phrase, car elle est plus étroite qu’il n’y paraît à première vue. Le signal de provenance est décrit comme étant porté par les images créées dans l’application Meta AI et sur meta.ai — les surfaces grand public — et la page du modèle de Meta ainsi que la documentation de l’API ne disent rien sur la question de savoir si les images générées via l’API Model portent la même marque. Nous n’avons trouvé aucune déclaration dans un sens ou dans l’autre, alors considérez Content Seal comme une fonctionnalité de provenance des surfaces grand public et ne supposez pas qu’elle accompagne un fichier généré par API tant que vous n’avez pas testé la sortie de votre propre compte. Indépendamment, le seul test du détecteur que nous ayons rapporté provient de Reuters, qui a constaté qu’il ne parvenait pas à vérifier une majorité d’images filigranées après recadrage ; ce constat et son chiffre sont traités dans notre article explicatif sur ce modèle, qui est la page à lire pour l’argument de provenance plutôt que celle-ci.

Où cela tourne

La déclaration de disponibilité de Meta, tirée de la publication de lancement : Muse Image « est disponible aujourd'hui dans l'application Meta AI et sur meta.ai, dans Instagram Stories aux États-Unis, et sur WhatsApp dans un nombre limité de pays, et sera bientôt disponible sur Facebook. » Ce sont les mots de Meta et les surfaces sont les propres produits de Meta — il n'y a ni liste d'attente, ni code d'invitation, ni inscription séparée pour aucun d'entre eux. Côté développeur, le modèle est servi via Model API, ce à quoi servent l'identifiant et les points de terminaison ci-dessus. La page du modèle de Meta répertorie également des plateformes d'inférence tierces parmi les moyens de l'exécuter ; nous ne les nommons pas ici, et rien dans cette page ne doit être interprété comme une affirmation sur les conditions ou les tarifs sur une surface autre que l'API propre de Meta.

Meta n'a pas publié de date pour l'arrivée de Muse Image sur Model API, et la documentation pour développeurs de Meta n'en indique aucune. La seule date sur laquelle cette page se base est la date de lancement du modèle lui-même, le 7 juillet 2026, établie à partir de la date de l'article d'annonce de Meta. Si vous datez la surface de l'API plutôt que le modèle, dites ce que dit Meta, c'est-à-dire rien.

Poids ouverts ou propriétaire ? Propriétaire — et la famille a les deux

C'est la question sur laquelle les lecteurs se trompent le plus souvent dans cette famille, il vaut donc la peine d'y répondre directement. Muse Image est propriétaire.La documentation destinée aux développeurs de Meta trace la ligne explicitement : les modèles que vous appelez via Model API — Muse Spark, Muse Image, Muse Voice Transcribe et SAM — sont servis, et « Muse Glimmer suit une autre voie : vous téléchargez les poids ouverts et l'exécutez sur votre propre matériel au lieu de l'appeler via Model API », sous une licence permissive Apache 2.0. Muse Glimmer est la voie open-weight de cette famille, et il s'agit d'un modèle différent : un modèle multimodal distillé à partir de Muse Spark, et non une version ouverte de Muse Image. Rien sur la page de Meta consacrée à Muse Image n'indique de licence ni ne propose de poids, car il n'y en a aucun à proposer. Si l'auto-hébergement est une exigence absolue, Muse Glimmer est le modèle à évaluer ; si vous voulez le modèle d'image décrit ici, vous appelez l'API de Meta et vous payez à l'image.

Ce que Meta affirme classer, étiqueté comme une affirmation de Meta

Le post de lancement de Meta déclare : « Muse Image occupe la 2e place sur Arena pour la génération d'images à partir de texte, l'édition d'une seule image et l'édition multi-images, telles que mesurées par les classements Elo de préférence humaine au moment de la rédaction. » Deux éléments de cette phrase comptent, et tous deux proviennent des propres termes de Meta. Il s'agit d'un classement rapporté par le fournisseur, et non d'un score indépendant, et c'est une position Elo fondée sur la préférence humaine plutôt qu'un résultat de benchmark sur un banc d'essai figé — une distinction qui change réellement les choses lorsque l'écart entre les deux premières positions est inférieur à la marge d'une note Elo construite sur un nombre limité de votes. Les graphiques que Meta publie à l'appui de cette affirmation sont datés du « 5 juillet 2026 », et l'affirmation elle-même est assortie de la réserve « au moment de la rédaction » ; il s'agit donc d'un instantané d'un classement en direct cité par une partie qui y a un intérêt, et non d'une position établie.

Le même post inclut un graphique de scaling que Meta légende pour vous : le graphique montrant la qualité s’améliorer avec le raisonnement a pour légende « Elo issu d’une ablation interne ». Il s’agit d’une mesure interne au fournisseur, et elle n’est pas comparable à un classement tiers. L’argument de Meta est que la qualité s’améliore avec le calcul au moment du test selon une relation approximativement log-linéaire et que le raisonnement et l’utilisation d’outils se renforcent mutuellement lorsqu’ils sont combinés — une ablation interne, présentée comme telle.

Des positions indépendantes pour ce modèle existent, sur des classements qui ne sont pas ceux de Meta, et nous les avons rapportées : notre article explicatif contient les classements d’images d’Artificial Analysis et les positions d’arène avec leurs chiffres, et les deux pages de comparaison placent ces chiffres à côté de concurrents nommés. Si vous voulez une vision indépendante plutôt que celle du fournisseur, c’est là qu’il faut la lire. Cette page ne reproduit pas ces chiffres, et l’un d’eux doit de toute façon être lu avec attention, parce qu’Artificial Analysis ne classe que les modèles d’image qui proposent une API appelable — donc une position indépendante sur Muse Image est une affirmation concernant Model API, et non sur l’application Meta AI.

Ce à quoi la documentation ne répond pas

Une page de référence n'est utile que si elle indique où s'arrête l'information, voici donc ce que nous n'avons pas pu établir à partir de Meta le 29 septembre 2026. Il n'existe pas de limite de débit publiée pour Muse Image. Il n'y a pas de profil de latence publié, pas de taux de réussite et pas d'évaluation indépendante de la boucle agentique sous trafic de production — le prix par image est documenté, mais pas l'enveloppe opérationnelle. Il n'existe aucun benchmark de suivi d'instructions ou de fidélité d'édition provenant d'un tiers indépendant, et Meta ne publie aucun chiffre de ce type en propre ; le graphique de benchmark sur la page du modèle de Meta ne comporte aucun chiffre lisible. Il n'y a pas de déclaration de licence, car le modèle n'est pas sous licence pour le téléchargement. Et la date à laquelle Muse Image est devenu appelable sur Model API n'est indiquée nulle part dans la documentation de Meta. Aucune de ces absences n'est une raison d'éviter le modèle — une image à un centime avec ancrage de recherche inclus vaut la peine d'être testée rien que pour cela — mais chacune est une raison de mesurer plutôt que de supposer avant qu'un pipeline n'en dépende.

Le verdict pour un développeur

Meta Muse Image mérite d’être évalué si votre problème est le volume : imagerie de catalogue, variantes publicitaires, personnalisation par utilisateur, tout ce où le tarif à l’image des modèles de pointe était ce qui a fait échouer le projet. Le prix unitaire est documenté, l’unité est sans ambiguïté, les échecs ne sont pas facturés, et l’ancrage de recherche est inclus dans le tarif plutôt que facturé à côté, ce qui est assez inhabituel sur ce marché pour constituer le point fort mis en avant. Cela ne vaut pas la peine d’être adopté à l’aveugle, car tout ce qui va au-delà du prix — débit, latence, la fiabilité avec laquelle la boucle agentique se referme sur vos prompts, si la signalisation de provenance accompagne la sortie de l’API — n’est pas documenté, et la propre affirmation de classement du fournisseur est un classement de préférence humaine cité à un instant donné plutôt qu’un résultat mesuré. La forme honnête d’une décision ici est une expérience à un centime face au modèle d’image que vous déployez déjà, sur vos propres prompts, avec le mode d’échec bon marché et une solution de repli éprouvée derrière. Pour ce qu’est ce modèle, comment il est appelé et ce qu’il coûte, cette page est la référence ; pour savoir s’il doit figurer dans votre stack, les chiffres que vous générez vous-même sont les seuls qui comptent.