Muse, expliqué : l’agent IA personnel de Meta, sa VM sécurisée et le code d’invitation que personne n’a

Si vous avez cherché l'agent Muse, vous avez probablement deux questions. La première est de savoir si vous pouvez y accéder : le Muse de Meta n'a ni code d'invitation, ni liste d'attente, ni code d'accès nulle part dans la documentation de Meta elle-même, et cette page vous montrera d'où vient cette réponse plutôt que de vous demander de la prendre pour argent comptant. La seconde est ce qu'est réellement Muse, car ce nom est accolé à beaucoup de choses que Meta déploie. Muse Spark est le modèle qui se trouve en dessous ; Muse est le produit qu'il anime. Muse est un agent d'IA personnel que Meta fait tourner sur un ordinateur qu'elle a conçu pour cela, et l'ingénierie qui mérite d'être comprise ne réside pas dans ce qu'il peut faire, mais dans ce que Meta a décidé qu'il ne doit jamais être autorisé à atteindre.

Deux dates comptent ici, et aucune des deux n’est une raison d’écrire cette page. Meta a présenté Muse le 8 septembre 2026 et l’a activé aux États-Unis ce jour-là ; lors de Connect, le 23 septembre 2026, Meta a annoncé qu’il apportait Muse à ses lunettes d’IA. Cette seconde date est le seul événement Muse au cours des sept derniers jours, et elle sert ici à dater le produit, non à justifier un article. Il s’agit de la page de référence pour ce nom — la destination d’un lecteur qui a cherché « muse agent » et n’a trouvé que notre couverture du lancement, qui est le seul lien qui vaille la peine d’être conservé et rien qui vaille la peine d’être raconté. Tout ce qui suit provient de l’annonce de Meta elle-même et de son propre rapport de sécurité, tous deux relus le 29 septembre 2026, et chaque chiffre qui y figure est celui de Meta, sauf indication contraire de cette page.

Ce qu'est Muse, et ce qu'il n'est pas

Le propre résumé de Meta établit la distinction sans détour : « Muse est un agent d’IA personnel. Il ne se contente pas de répondre aux questions, il fait réellement le travail. » En pratique, cela signifie que Meta décrit Muse comme prenant en charge des tâches ponctuelles, comme envoyer un e-mail ou réserver un voyage, et comme se chargeant aussi d’objectifs ouverts — transformer une ambition exprimée en un plan personnalisé, puis le faire avancer de lui-même. Pour le travail qui s’étend sur plus d’une session, Meta affirme que Muse continue après la fermeture de l’application et revient lorsque quelque chose change ou lorsqu’il a besoin d’une approbation. Le modèle d’interaction repose sur la messagerie plutôt que sur une fenêtre de chat : vous lui parlez dans l’application Muse ou directement dans WhatsApp, et il est « propulsé par Muse Spark, le modèle le plus performant de Meta à ce jour, conçu pour un travail agentique concret comme celui-ci ».

Ce que Muse n'est pas compte tout autant pour quiconque arrive depuis une recherche. Ce n'est pas un modèle que vous appelez depuis une API, et ce n'est pas une interface de chat affublée d'une personnalité. C'est un produit grand public que Meta exploite pour votre compte, sur une infrastructure que Meta contrôle, et ce n'est pas quelque chose que vous pouvez installer. Meta ne publie aucun benchmark pour Muse lui-même — aucun score, aucun classement, aucune comparaison directe — et cette absence est un fait concernant la documentation, plutôt qu'une lacune que cette page peut combler avec un proxy. La manière honnête d'évaluer Muse consiste à lire l'architecture et la disponibilité, ce que fait le reste de cette page.

Pourquoi un agent a besoin de son propre ordinateur

La phrase de départ est celle de Meta : « Muse fonctionne sur Muse Secure VM, un ordinateur sécurisé dédié doté de son propre navigateur », décrit ailleurs dans le même billet comme « une machine virtuelle (VM) dédiée qui héberge à la fois l'agent et les données d'une personne », confiné de sorte qu'aucun agent d'autrui ne puisse y accéder. C'est là que sont stockés les identifiants et les données de chaque service auquel une personne se connecte. La manière dont Meta formule l'objectif de conception mérite d'être gardée à l'esprit pendant la lecture : deux domaines de sécurité isolés sur une même machine, et non un modèle de langage disposant d'un accès root.

Le rapport de sécurité de Meta, « How We Built Safety Into Muse », est bien plus précis que l'annonce, et c'est la source à citer pour toute affirmation sur le degré de confiance que mérite l'agent. L'infrastructure de l'agent, les fichiers de l'espace de travail et chaque outil que Muse exécute s'exécutent à l'intérieur d'un systemd-nspawn conteneur d'exécution. À l'intérieur de cette cellule, root correspond à un utilisateur hôte non privilégié, donc le root de la cellule n'est pas le root de l'hôte. La cellule dispose de son propre système de fichiers racine, séparé du système de fichiers hôte où vivent des données plus sensibles, ainsi que d'une interface réseau virtuelle, d'appels système filtrés — pas de io_uring, par exemple — et un ensemble de capacités restreint : pas de CAP_SYS_PTRACE, pas de CAP_NET_ADMIN. En dehors de la cellule, des unités systemd distinctes exécutent les protections qui ne doivent pas pouvoir être désactivées depuis l'intérieur de celle-ci, y compris une couche de modèles et de classificateurs indépendants qui inspectent les requêtes et les réponses d'inférence pour détecter l'injection de prompt et le risque de frontière. La raison de Meta pour les placer à l'extérieur est que la cellule d'exécution est censée traiter des données non fiables.

Pris ensemble, ces choix répondent à la question que se pose réellement un lecteur : à quoi Muse peut-il accéder ? Il peut atteindre le réseau, mais uniquement par un chemin contrôlé par un autre système. Il peut piloter un navigateur, mais pas les rouages internes du navigateur. Il peut détenir des identifiants, mais il ne peut pas les voir.

Sentinel décide ; Muse ne fait que proposer

L'annonce de Meta présente ce composant en une phrase : « Un agent Sentinel distinct s'exécute sur cette même machine, maintenu à l'écart de Muse au niveau système. » C'est dans la note de sécurité que cette autorité est explicitée, et elle est sans ambiguïté — « Sentinel est la seule autorité de permission pour les actions des connecteurs et les sorties réseau » — tout comme l'ordre : Muse propose des actions, mais seul Sentinel peut accorder la permission de les exécuter. Sentinel renvoie l'une de trois réponses pour toute action proposée : autorisée, refusée ou demander, en fonction de la politique du connecteur définie par l'utilisateur. Rien de ce que fait Muse n'atteint Internet sans l'approbation de Sentinel, et Sentinel demande l'avis de la personne quand c'est nécessaire.

La mécanique qui sous-tend cela est inhabituellement concrète. Pour la sortie réseau, Sentinel inspecte aux couches 4 et 7 — nom d’hôte, IP résolue et finale, port, protocole, méthode, chemin et la requête décodée elle-même — et applique des restrictions SSRF afin qu’un nom d’hôte public ne puisse pas résoudre vers une infrastructure privée. Les identifiants sont insérés juste à temps à la frontière réseau, en remplaçant un jeton de substitution par le vrai uniquement au moment de l’utilisation, ce qui explique pourquoi Meta considère comme vaines les tentatives visant à soutirer le véritable secret à l’agent au moyen d’une injection de prompt. La propagation de teinte, mise en œuvre avec des programmes eBPF cgroup et des hooks LSM, décide quand une action perd son autorisation automatique. Il s’agit de l’architecture de Meta au sein du produit de Meta : ce n’est pas une fonctionnalité qui nous appartient, et nous n’en exposons ni n’en revendons aucune partie.

Approbations, identifiants et le navigateur

Trois autres choix de conception portent l'essentiel du poids pour quiconque décide dans quelle mesure laisser un agent agir.

Les approbations sont des capacités, pas une conversation. La phrase de Meta est exacte : « Les approbations accordées via le système human in the loop sont des capacités strictes, et non des suggestions conversationnelles. » Chaque autorisation est liée à un connecteur ou à une destination particulière et à un cas d’usage particulier, et le système prend en charge des permissions à usage unique, limitées à la session, limitées à la tâche, limitées dans le temps ou perpétuelles. Sentinel choisit les types d’autorisation à proposer et vérifie que les invocations ultérieures correspondent à la portée accordée. Les requêtes sont transmises à l’interface client Muse plutôt que via la conversation, et la réponse revient directement à Sentinel. Les achats nécessitent une approbation humaine à chaque fois. Les actions en lecture seule, déjà autorisées ou manifestement à faible risque évitent l’interruption, ce qui est le compromis que Meta a rendu explicite plutôt que de le cacher.

Les identifiants résident à l'intérieur de la VM. hatch-authd, l'un des services sensibles sur le plan de la sécurité exécutés en dehors de la cellule d'exécution, gère le stockage des identifiants et la substitution d'identifiants, de sorte que l'agent principal ne voit jamais d'identifiants sensibles. Les jetons OAuth des services connectés sont stockés dans la VM de l'utilisateur plutôt que dans l'infrastructure centralisée de Meta. Par ailleurs, un service appelé privsep exécute le code des connecteurs intégrés avec des privilèges strictement limités, ce qui maintient les identifiants des services connectés hors de portée de l'agent. Selon le résumé que Meta fait lui-même du résultat, Muse n'a aucune visibilité sur les mots de passe ni sur les moyens de paiement, y compris les mots de passe qu'une personne saisit elle-même dans le navigateur.

Le navigateur est intermédié. Meta décrit le navigateur comme étant géré par un courtier distinct qui possède la connexion au protocole Chrome DevTools, le sous-agent le pilotant via un instantané de l'arbre d'accessibilité de la page plutôt que le DOM brut. Les conséquences sont énoncées clairement : pas de capacité d'exécuter du JavaScript dans le contexte de la page, pas de verbes de script, pas d'exécution dans le processus du navigateur, et DevTools désactivé. Parce que l'arbre d'accessibilité est l'entrée, le sous-agent ne peut pas lire les identifiants saisis depuis le magasin d'identifiants, et il ne peut pas sortir du DOM pour les trouver. Lorsqu'une personne prend le contrôle du navigateur, ou pendant que le magasin d'identifiants remplit un formulaire, l'agent est mis en pause et ne peut pas agir du tout.

Le bug bounty est la partie à lire comme un signal.

Meta affirme avoir renforcé Muse par le dogfooding, le red teaming agentique et un programme privé de bug bounty, puis avoir ouvert ce programme à tous : jusqu'à 300 000 $ pour des rapports valides fondés sur un impact démontré, y compris jusqu'à 130 000 $ pour des tentatives réussies d'injection de prompt qui affectent un seul utilisateur. Il s'agit des plafonds annoncés par Meta pour son programme, et non de résultats mesurés, et personne en dehors de Meta ne peut dire à quelle fréquence ces montants sont versés.

Ce qui rend la divulgation utile, c'est sa forme. La plus grande catégorie nommée n'est ni un jailbreak ni une fuite de données du côté de Meta — c'est une page web ou un e-mail qui persuade l'agent de faire quelque chose, au sein de la session d'une seule personne. C'est le modèle de menace que Meta évalue, et il vous indique où faire attention dès le premier jour : dans les autorisations de connecteur qu'une personne accorde, et dans le contenu que l'agent lit lorsqu'il agit en s'appuyant sur celles-ci.

Disponibilité, exactement telle que Meta le formule

Les propos de Meta, relus le 29 septembre 2026 : « Muse se déploie aux États-Unis sur iOS, Android et muse.ai, et arrive bientôt sur les lunettes connectées IA. C'est gratuit pour l'essentiel des besoins, avec des formules d'abonnement pour ceux qui veulent aller plus loin. » Les deux parties de cette déclaration méritent d'être lues telles qu'elles ont été écrites. Il s'agit d'un déploiement progressif dans un seul pays et sur trois surfaces, les lunettes connectées IA étant annoncées comme une surface à venir. Et la phrase sur les tarifs concerne le produit grand public de Meta lui-même — elle ne dit rien des offres d'aucune autre plateforme, y compris la nôtre, et cette page ne l'étend pas à d'autres cas.

La seule information datée de ces sept derniers jours concerne la gamme de lunettes, que Meta a concrétisée lors de Connect le 23 septembre 2026 : elle apporte Muse, un agent d'IA personnel, à ses lunettes d'IA, autour de la gestion du quotidien en mains libres. Cette annonce ne précise aucune date de commercialisation. L'élément de feuille de route à surveiller est Muse Confidential VM, que Meta annonce pour plus tard dans l'année ; dans celui-ci, l'intégralité de la VM, y compris les données d'une personne et ses conversations avec Muse, est chiffrée avec une clé que seul l'utilisateur détient, si bien que même Meta ne peut y accéder.

Une chose que cette page n'a pas pu vérifier : une page produit officielle de Muse existe à l'adresse ai.meta.com/muse, et le titre est renvoyé, mais son corps n'est pas remonté lors de notre lecture du 29 septembre 2026. C'est une page que nous n'avons pas pu examiner, et non une page qui a validé quoi que ce soit ; rien ici n'en est donc tiré.

Le code d'invitation : Meta n'en documente aucun

Les gens recherchent un code d'invitation, un code d'invitation et un moyen d'entrer sous Meta Muse. La réponse honnête est que rien de tout cela n'existe dans les propres documents de Meta. L'annonce du 8 septembre ne contient absolument aucune mention d'invitation, de parrainage, de liste d'attente ou de code d'accès ; l'accès est décrit uniquement comme une question de géographie et de plateforme, et le verrouillage repose sur les États-Unis, ainsi que sur iOS, Android et muse.ai. La publication du 23 septembre sur les lunettes n'ajoute rien non plus concernant l'obtention d'un accès. Donc il n'y a aucun code à trouver, aucune file d'attente à rejoindre, et aucun mécanisme documenté par lequel quelqu'un pourrait vous en donner un.

Deux mises en garde qu'il vaut la peine d'énoncer clairement, car une supposition déguisée en réponse est pire qu'une réponse négative. Nous ne pouvons rapporter que ce que Meta publie ; si un programme protégé par un code existe quelque part sans être répertorié, les pages de Meta elles-mêmes ne le documentent pas, et aucune de nos pages ne doit être lue comme promettant un tel programme. Et si cette section existe tout court, c'est parce que le nom est recherché exactement sous cette forme : l'expression attire un volume de recherche constant, et chacune de nos pages qui y répond actuellement est l'article de lancement — ce qui est le propre d'une page de référence plutôt que d'une nouvelle annonce.

Pouvez-vous appeler Muse ? Non — et voici ce que nous faisons pour router.

Le Muse de Meta est un produit grand public, et non un modèle que nous répertorions, et la réponse à la question de savoir si OrcaRouter propose quoi que ce soit qui y corresponde est que non : muse-agent n'est pas une route dans notre catalogue, et l'agent de Meta n'est pas quelque chose que nous hébergeons, proxifions ou revendons. Transporter le modèle sous-jacent est une chose différente du fait de transporter l'agent, et cette page ne brouillera pas la distinction entre les deux. La grille tarifaire de Meta pour Muse Spark n'est pas non plus publiée sous une forme que nous pouvions lire le 29 septembre 2026, donc rien ici n'est attribué à Meta à titre de prix.

Ce que notre liste de modèles en direct contient bel et bien, vérifié aujourd'hui, c'est le modèle lui-même : Muse Spark 1.2, le checkpoint que Meta décrit comme son modèle de raisonnement pour les tâches agentiques complexes, avec une fenêtre de contexte de 1 048 576 tokens, aux côtés de Muse Spark 1.1. Notre fiche modèle pour celui-ci est une route en direct, avec du trafic réel à son actif cette semaine, facturée au tarif du fournisseur sans marge de notre part — parce que nous répercutons les prix catalogue du fournisseur au lieu d'ajouter une marge, un changement de tarif de Meta se répercuterait chez nous le jour même. Le checkpoint 1.3, plus récent, ne figure pas dans notre annuaire, et nous ne listons pas ce que nous ne pouvons pas servir. Si vous voulez la capacité de l'agent en tant que développeur plutôt qu'en tant que produit, appeler le checkpoint que nous routons effectivement est l'achat que vous pouvez réellement effectuer, et la même clé donnerait accès au reste du catalogue sans qu'il en faille une seconde.

La question ouverte

Meta ne publie aucun benchmark pour Muse, il n'y a donc pas de tableau de scores qui prête à discussion, et les questions qui subsistent sont de savoir si un modèle d'autorisation exceptionnellement strict survit au contact du travail réel. Trois choses à surveiller : si les autorisations de capacités de Sentinel tiennent le coup une fois qu'un agent exécute des tâches longues et sans surveillance avec plusieurs connecteurs attachés ; si la classe d'injection de prompt que Meta valorise jusqu'à 130 000 $ apparaît dans la nature, puisque le fait que la prime soit ouverte signifie qu'un rapport manquant est une affirmation que l'on peut tester plutôt que croire ; et si Muse Confidential VM sera livré plus tard cette année comme l'affirme Meta, ce qui déplacerait l'ancre de confiance de l'infrastructure de Meta vers une clé que détient l'utilisateur.

Pour un lecteur qui décide aujourd’hui, la décision est simple. Si vous êtes aux États-Unis sur iOS, Android ou le web, Muse n’est bloqué derrière rien que vous deviez trouver — vous l’ouvrez, vous choisissez les services à connecter, vous regardez ce pour quoi il demande l’autorisation, et vous gardez la piste d’audit sous les yeux. Si vous êtes ailleurs, ou sur une plateforme que Meta n’a pas encore déployée, il n’y a rien à activer et aucun code à chercher, et le conseil honnête est d’arrêter de chercher. Et si ce que vous vouliez était le modèle plutôt que l’agent, il s’agit d’un achat distinct et bien plus simple, effectué sur un checkpoint routé plutôt qu’un abonnement.