Triez les sessions cassées avec un connecteur Meta Muse pour l'analyse de sessions

Un agent qui remonte des chiffres de trafic et un agent qui trie des sessions cassées ne font pas le même travail, et un connecteur Meta Muse pour l'analyse de sessions appartient à la deuxième catégorie. Le résultat n'est pas un graphique mais une liste courte et classée de ce qui a cassé sur votre site, enregistrements à l'appui, où l'agent décide ce qu'un humain ouvre ensuite.

En bref : trois des quatre endpoints de session sont en lecture seule. Construisez le connecteur, collez un jeton de workspace flow_ws_ dans l'invite d'identifiants sécurisée de Muse, et dites-lui dans le même message que PATCH /issues/{issueId} est interdit.

Muse écrit lui-même le connecteur à partir d'une spec d'API publique, et Parallel a rapporté le 14 septembre 2026 que le code qu'il écrit s'exécute dans la propre cellule d'exécution cloud de l'agent. Le guide connecteur Meta Muse pour l'analytics web couvre ce mécanisme et le flux d'identifiants. Cet article, lui, le pointe vers les incidents.

Que voit le connecteur quand Muse ouvre un incident ?

Muse voit la fiche d'incident produite par Flowsery, pas l'enregistrement qui se trouve derrière. La détection de Flowsery fait remonter les rage clicks, les erreurs JavaScript, les dead clicks et les abandons, et chaque fiche porte un titre, une description, une gravité, un statut, sessionsCount, firstSeenAt, lastSeenAt, des stepsToReplicate ordonnées et un sampleRecordingId.

La gravité prend low, medium, high et critical. Un jeton de workspace couvre tous les sites du workspace, donc chaque appel a besoin de websiteId ou de domain pour en désigner un.

GET /issues/{issueId} est l'appel qu'il vaut la peine d'apprendre à Muse tôt, parce qu'il renvoie les commentaires laissés par votre équipe sur un incident en plus des sessions. Cela sépare un abandon que personne n'a vu d'un abandon que quelqu'un a déjà regardé jeudi dernier.

Muse peut-il regarder un replay de session ?

Non. Un replay a la forme d'une vidéo et l'API renvoie du JSON, donc Muse lit un résumé structuré d'un enregistrement plutôt que l'enregistrement. Ce que l'API offre de plus proche est le tableau occurrences : chaque moment signalé porte une description, une gravité et un décalage atSeconds dans l'enregistrement.

En pratique : Muse peut vous dire qu'un groupe de rage clicks a touché 41 sessions, vous lire les étapes pour le reproduire et nommer l'enregistrement qui le montre le mieux. Il ne peut pas vous dire que le bouton d'envoi paraissait grisé. La voie du navigateur ne sauve rien ici : Meta indique que le sous-agent navigateur lit un instantané de l'arbre d'accessibilité, pas le DOM brut.

Que collez-vous dans Muse pour construire le connecteur ?

Un seul message portant l'URL de la spec, le mode d'authentification et l'interdiction d'écriture. L'interdiction a sa place dans le premier message plutôt que dans une correction ultérieure, parce que le connecteur que Muse enregistre est construit à partir de ce qu'il a lu pendant la configuration.

Build a custom connector for Flowsery from the API reference at
https://flowsery.com/docs/api-introduction.md. It is public, so read it
without logging in. Full spec: https://flowsery.com/openapi.json.
 
Base URL: https://analytics.flowsery.com/analytics/api/v1
Auth: an "Authorization: Bearer <token>" header. I will paste the token into
the secure credential prompt, not into this chat. It starts with flow_ws_.
 
Use GET /issues, GET /issues/{issueId} and GET /visitors/{visitorId} only.
Do not call PATCH /issues/{issueId}. Start with GET /websites and list the
website IDs you can see.

Le guide analytics web déroule l'invite d'identifiants étape par étape. Ce qui change côté incidents, c'est le dernier paragraphe : nommez les trois lectures, nommez la seule écriture, interdisez-la. Demandez ensuite les incidents critiques ouverts sur un site, ce qui sollicite le chemin de lecture sans rien écrire.

Quels appels de session lisent, et lequel écrit ?

Quatre endpoints comptent et un seul modifie des données : PATCH /issues/{issueId} met à jour le statut d'un incident, et c'est là tout le problème de supervision.

Gardez le connecteur en lecture seule la première semaine. Pourquoi un connecteur que Muse a écrit lui-même obtient moins d'isolation qu'un connecteur intégré, et ce que les réglages d'approbation par défaut de Meta y changent, c'est le sujet du guide analytics web. Côté incidents, cette posture ne coûte rien, parce que le triage n'a jamais besoin de l'écriture.

Faut-il autoriser Muse à changer le statut d'un incident ?

Pas la première semaine, et pas de façon planifiée ensuite. Un agent qui détient PATCH /issues/{issueId} peut résoudre quelque chose que personne n'a regardé, et un incident résolu quitte la liste que tout le monde ouvre le matin. Le statut suspendu est pire : un incident suspendu sort de la réponse par défaut de GET /issues jusqu'à ce que quelqu'un demande status=suspended.

L'hygiène des statuts est exactement la corvée où un agent a l'air bon, et un balayage qui fait passer douze critiques périmés en résolus produit une liste plus courte avec le même paiement cassé en dessous.

Meta indique que certaines actions de l'agent sont irréversibles et vous laisse la réparation. Au 20 septembre 2026, votre trace est le journal d'activité de Muse, un relevé chronologique des actions menées et des permissions accordées, alors lisez-le avant d'élargir une permission. Autorisez une écriture une fois, pour l'incident que vous avez sous les yeux, après avoir ouvert le replay.

Qu'est-ce qui casse spécifiquement sur l'analyse de sessions ?

Cinq choses tournent mal ici qui ne tournent pas mal sur un connecteur de reporting.

Une règle vient du guide analytics web : la VM de Muse se trouve dans le cloud de Meta, donc tout ce qui est derrière votre VPN ou sur votre portable est hors de portée. Pour la même boucle sans Muse, le modèle de Grok Bot pour l'analyse de sessions exécute exactement la même chaîne d'appels.

Questions fréquentes

Meta Muse prend-il en charge MCP pour l'analyse de sessions ?

Parallel n'a trouvé aucun réglage « add MCP server » le 14 septembre 2026, et le guide analytics web donne la réponse complète sur MCP. Pour le triage, cela ne change rien : les trois lectures et la seule écriture passent par REST dans les deux cas, et le serveur MCP hébergé de Flowsery sert Claude, Cursor et Codex à la place.

Muse peut-il fermer un incident Flowsery de sa propre initiative ?

Seulement si vous le laissez faire. PATCH /issues/{issueId} est le seul appel qui fait passer un incident entre open, in_progress, resolved et suspended, et le message de configuration ci-dessus l'interdit purement et simplement. Les invites d'approbation de Meta apparaissent dans l'interface du client plutôt que dans le chat, donc une écriture inattendue est visible avant de se produire.

Que voit Muse d'un visiteur ?

Plus qu'une chronologie. GET /visitors/{visitorId} renvoie un bloc identity avec le pays, la région, la ville, le navigateur, l'OS, l'appareil et le viewport, plus activity, revenue et un profile portant userId, name et email dès que votre site a appelé identify. L'identifiant de visiteur est la valeur first-party _fs_vid, et Flowsery ne stocke aucune adresse IP et ne pose aucun identifiant inter-sites. Décidez si Muse doit détenir cela avant de créer le jeton.

Est-ce que cela remplace l'ouverture du replay ?

Non. Le connecteur classe et réduit, et c'est dans l'enregistrement que se trouve la raison. Laissez Muse choisir les trois sessions qui valent dix minutes, puis passez ces dix minutes. Les questions agrégées relèvent du volet analytics web du même connecteur.

De quel plan Flowsery ai-je besoin ?

L'un ou l'autre. GET /issues et l'analyse de sessions par IA derrière sont sur Team à $250 par mois comme sur Pro à $500 par mois, et les deux s'ouvrent sur un essai gratuit de 14 jours sans carte. Le guide analytics web détaille les limites de sièges, de sites et de rétention des replays qui les séparent.

De quoi Muse a-t-il besoin pour appeler GET /issues avec un jeton de workspace ?

Un jeton de workspace couvre tous les sites du workspace, donc chaque appel a besoin de websiteId ou domain pour en désigner un. Sans cela, Flowsery renvoie 404 Website not found, pas une erreur d'authentification. Dites à Muse d'exécuter GET /websites d'abord et de reporter l'ID.

Où Muse trouve-t-il un ID de visiteur pour GET /visitors/{visitorId} ?

Dans GET /realtime/map, la seule lecture qui renvoie visitorId. Le endpoint attend une valeur _fs_vid, et aucun payload d'incident n'en contient. Un id deviné renvoie 404, donc dites à Muse de ne pas en inventer.

Que se passe-t-il quand Muse atteint une limite de débit Flowsery ?

Flowsery répond par un 429 et ajoute Retry-After en secondes. Chaque réponse contient aussi RateLimit-Remaining et RateLimit-Reset. Dites à Muse de lire ces en-têtes et de rythmer son balayage au lieu de réessayer à l'aveugle.

Pourquoi un incident suspendu manque-t-il dans les résultats de Muse ?

GET /issues écarte les incidents suspendus de la réponse par défaut tant que vous ne demandez pas status=suspended. Les quatre statuts sont open, in_progress, resolved et suspended. Si un incident a disparu sans que vous l'attendiez, consultez l'Activity log de Muse.

Que doit faire Muse quand un incident n'a pas d'enregistrement d'exemple ?

sampleRecordingId peut être nul, donc certains incidents arrivent sans rien à ouvrir. Muse doit signaler l'incident sans enregistrement plutôt qu'en substituer un voisin. Vous obtenez quand même sa gravité et son sessionsCount.

Créez un jeton de workspace et lancez un balayage d'incidents en lecture seule, ou consultez la référence de l'API d'abord.

Sources : l'article d'aide de Meta sur les connecteurs Muse, How we built safety into Muse, l'analyse de Parallel sur les intégrations personnalisées de Muse (14 septembre 2026), et la référence de l'API Flowsery. Vérifié le 20 septembre 2026.