Sortez le rapport du lundi avec un connecteur Meta Muse pour les rapports analytiques

Un rapport hebdomadaire est la seule tâche qu'un connecteur Meta Muse pour les rapports analytiques peut accomplir sans jamais modifier un chiffre, car chaque point de terminaison dont il a besoin est un GET. Muse écrit ce connecteur lui-même à partir de la spécification publique de l'API Flowsery. Parallel a rapporté le 14 septembre 2026 que le travail se déroule sur la machine virtuelle cloud propre à chaque utilisateur que Meta attribue à tout compte Muse ; Meta, de son côté, se contente de dire que cette machine a assez de puissance de calcul pour faire du vrai travail. L'installation et les identifiants sont traités dans le guide du connecteur Meta Muse pour l'analyse de site web ; ce billet commence au rapport que vous lancez chaque lundi.

En bref : un rapport hebdomadaire, c'est GET /websites une fois, GET /overview deux fois, GET /timeseries pour la forme, puis GET /channels et GET /breakdown pour nommer la cause. Six lectures, zéro écriture, et un websiteId sur chacune.

De quels appels un rapport hebdomadaire a-t-il vraiment besoin ?

Un rapport Flowsery hebdomadaire tient en six appels, et l'ordre compte plus que le nombre. GET /websites fournit les identifiants que chaque appel suivant transporte. GET /overview s'exécute deux fois, une fois par période. GET /timeseries transforme l'écart en une forme, si bien qu'un seul mardi médiocre cesse de ressembler à une tendance. Ensuite, GET /channels et GET /breakdown nomment ce qui a bougé.

GET /countries, /devices, /browsers et /realtime relèvent de la question de suivi, pas du rapport planifié. Donnez quand même la liste complète au connecteur : un point de terminaison qu'il n'appelle jamais ne coûte rien, et un point de terminaison qui lui manque un mardi coûte un connecteur à reconstruire.

Comment demander une comparaison entre deux périodes ?

Nommez explicitement les deux plages de dates et nommez le fuseau horaire. Muse résout « la semaine dernière » lui-même, avant que l'appel ne parte, et Meta ne publie rien sur l'horloge qu'il utilise. Flowsery regroupe ensuite startAt et endAt selon le fuseau horaire du site web, sauf si l'appel en nomme un. Deux résolutions distinctes, toutes deux silencieuses, toutes deux capables de décaler un rapport d'une journée.

Report on flowsery.com for the week of 8 to 14 September and the week of
1 to 7 September, timezone Europe/Berlin.
 
Call GET /websites on the first run only, then carry the saved websiteId
through every call.
Then GET /overview once per period.
If sessions or conversions moved more than 10%, call
GET /breakdown?dimension=channel for both periods and name the channel.
Numbers first. No recommendations. If nothing moved, say so and stop.

« Les chiffres d'abord, pas de recommandations » mérite sa place. Un agent à qui on demande une analyse produit une analyse, et celui qui dispose de vingt-deux points de terminaison en lecture sans aucun accès à votre feuille de route la construit sur le seul trafic. Le modèle de Grok Bot pour les rapports analytiques livre la même instruction pour la même raison.

Pourquoi chaque appel a-t-il besoin d'un sélecteur de site web ?

Un jeton d'espace de travail Flowsery couvre tous les sites web de l'espace de travail, donc l'API ne peut pas deviner lequel vous visez. Chaque appel a besoin de websiteId ou de domain. Omettez le sélecteur et le jeton d'espace de travail n'a aucun site web à résoudre : l'appel échoue au lieu de renvoyer en silence les chiffres d'un seul site web.

L'endroit où va le jeton flow_ws_, et la raison pour laquelle il n'a jamais sa place dans le chat, sont dans l'article pilier. Ce que le rapport doit gérer, c'est la portée de ce jeton : il atteint tous les sites web.

Dites au connecteur d'enregistrer les identifiants de sites web après la première exécution et de les réutiliser. Dès la deuxième semaine, le rapport tient en cinq appels, et relancer GET /websites ne vaut le coup que lorsque vous ajoutez un site.

Que peut modifier un connecteur de reporting ?

Rien. Chaque point de terminaison de ce billet est un GET, ce qui fait d'un connecteur de reporting la chose la plus sûre à confier à un agent : aucune approbation à configurer, aucune écriture à surveiller, aucune annulation à prévoir.

Meta déclare clairement qu'il n'examine pas les connecteurs personnalisés ni l'usage qu'ils font de vos informations, et cette absence d'examen pèse moins lourd quand tout le vocabulaire du connecteur est en lecture.

Qu'est-ce qu'un rapport assemblé fait de travers qu'un tableau de bord ne fait pas ?

Un agent qui assemble un rapport commet trois erreurs qu'un tableau de bord ne peut pas commettre : il écrit de la prose sur des chiffres au lieu de les dessiner.

Il arrondit, puis raisonne sur le chiffre arrondi. « Stable d'une semaine sur l'autre » absorbe une baisse de 9%. Demandez les chiffres bruts à côté de la phrase.

Il attribue des causes qu'il n'a jamais interrogées. GET /breakdown?dimension=channel nomme le canal qui a bougé. Aucun point de terminaison Flowsery ne renvoie une raison, et le connecteur n'a ni journal de versions ni file de tickets où en lire une. L'agent fournira quand même une raison, sauf si on lui dit de s'en abstenir.

Il compare des fenêtres inégales. Un jour férié, une fenêtre de sept jours contre une de six, un décalage de fuseau horaire. Un tableau de bord se trompe d'une manière que vous voyez ; un paragraphe, non.

Le correctif pour les trois est GET /timeseries avec interval=day. Les chiffres au jour le jour sous le total hebdomadaire permettent au lecteur de confronter la phrase de l'agent à la forme de la courbe, et c'est pour cela que le tableau de bord reste ouvert à côté.

Combien coûte un rapport hebdomadaire quand il tourne chaque semaine ?

Muse décompte tout sur une seule enveloppe hebdomadaire de tokens, et les chiffres par plan sont dans l'article pilier. Ce qu'une tâche planifiée change, c'est la forme de la dépense, pas le tarif : les mêmes lectures tournent 52 fois par an, que quelqu'un lise le résultat ou non.

Six lectures et un paragraphe de prose, c'est une petite dépense hebdomadaire. La version qui tourne mal, non : un agent qui réessaie vingt fois un appel en échec, chaque lundi, pour toujours, parce que personne ne lui a dit que le sélecteur était obligatoire.

L'API est incluse dans les deux plans Flowsery, donc l'exécution hebdomadaire ne dépend pas de celui que vous avez.

Qu'est-ce qui casse sur le reporting en particulier ?

Quatre choses, et aucune n'est l'authentification, qui fonctionne dès le premier appel ou pas du tout.

La première est le fuseau horaire, la panne qui survit le plus longtemps parce que le rapport arrive quand même et semble toujours correct. startAt et endAt sans timezone se regroupent selon le fuseau horaire du site web lui-même, celui défini dans Flowsery plutôt que celui où vit la personne qui demande le rapport, si bien que « la semaine dernière » couvre en silence sept jours différents de ceux de son calendrier.

La deuxième est le websiteId manquant, que l'agent tentera de résoudre en réécrivant la requête plutôt qu'en ajoutant le paramètre.

La troisième est la dérive de la compétence enregistrée. Parallel a rapporté le 14 septembre 2026 que Muse enregistre une intégration personnalisée comme une compétence réutilisable qui persiste d'une conversation à l'autre, ce qui fige la liste d'appels au moment où le connecteur a été construit. Meta ne documente pas ce point, alors traitez ce gel comme un comportement observé plutôt que comme une garantie. Quand l'API change, la réparation en un message décrite dans l'article pilier s'applique telle quelle. Personne ne regarde quand un rapport planifié casse, alors relisez la référence sur un rappel de calendrier plutôt qu'au moment d'une panne.

La quatrième est le rapport que personne ne lit. Celui qui énonce l'écart, nomme le canal et s'arrête est lu pendant des années ; celui qui commente est ignoré dès le troisième mois.

Questions fréquentes

Un connecteur de reporting Muse peut-il modifier mes données Flowsery ?

Pas si vous le construisez uniquement à partir des points de terminaison de reporting. Les treize dont un connecteur de reporting a réellement besoin sont tous en lecture : GET /overview, /timeseries, /pages, /referrers, /channels, /campaigns, /countries, /devices, /browsers, /breakdown, /goals, /realtime et /websites. Les appels en écriture de Flowsery couvrent les objectifs, les paiements et le statut des incidents ; un connecteur de reporting n'entend parler d'aucun d'eux.

Pourquoi la deuxième période revient-elle vide ?

Le deuxième GET /overview transporte un startAt et un endAt que le connecteur a écrits lui-même, alors vérifiez ce qu'il a réellement envoyé : Flowsery fixe par défaut startAt à il y a trente jours et endAt à maintenant dès que l'un des deux manque, et une plage sans trafic revient sous forme de zéros plutôt que d'erreur. Donnez à Muse les deux plages comme dates littérales dans le prompt plutôt que comme « la semaine précédente », et vérifiez que les deux réponses diffèrent avant de lire l'écart.

Peut-il comparer plus de deux périodes ?

Oui. Chaque période est son propre appel GET /overview ou GET /timeseries avec son propre startAt et son propre endAt, donc quatre trimestres coûtent quatre appels. Donnez à chacun le même fuseau horaire, sinon la comparaison enjambe des limites de journée différentes.

Le rapport hebdomadaire tourne-t-il quand l'application est fermée ?

Meta dit que Muse continue de travailler après la fermeture de l'application et revient quand quelque chose change ou qu'une approbation est nécessaire. Son centre d'aide documente les rappels et les tâches planifiées comme une capacité de Muse et ne dit rien d'un connecteur personnalisé qui tournerait dans l'une d'elles (vérifié le 20 septembre 2026). Testez une exécution hebdomadaire sans surveillance pendant un mois avant d'en dépendre.

Faut-il utiliser Muse ou le modèle de Grok Bot pour cela ?

Choisissez selon l'endroit où le rapport doit atterrir. Le modèle de Grok Bot pour les rapports analytiques s'installe depuis un lien de partage avec le texte de compétence déjà écrit et publie dans le chat que votre équipe lit déjà ; Muse écrit son propre connecteur à partir de la spécification publique et garde le résultat dans sa propre application. Les deux lisent la même API Flowsery, et chaque point de terminaison appelé par l'un ou l'autre est un GET.

Que appelle le connecteur en premier ?

Il appelle GET /websites, une seule fois, au premier lancement. Cela renvoie les ID de site web que porte chaque appel suivant. Dites au connecteur de les enregistrer et de les réutiliser, et dès la deuxième semaine le rapport tient en cinq appels.

Quel jeton utilise un connecteur de reporting Muse ?

Un jeton d'espace de travail flow_ws_, collé dans l'invite sécurisée d'identifiants de Muse et jamais dans le chat. Un jeton d'espace de travail couvre tous les sites web du compte, le connecteur peut donc tous les atteindre. C'est pourquoi chaque appel nomme quand même un websiteId.

Que se passe-t-il quand un appel n'a pas de websiteId ?

L'appel échoue. Un jeton d'espace de travail n'a pas de site unique à résoudre, donc l'API ne renvoie pas discrètement les chiffres d'un seul site. L'agent essaiera de corriger en réécrivant la requête, alors dites-lui d'emblée que le sélecteur est obligatoire.

Faut-il un forfait Flowsery précis pour le rapport hebdomadaire ?

Non. L'API est incluse dans les deux forfaits Flowsery, donc l'exécution hebdomadaire ne dépend pas de celui que vous avez. Le quota hebdomadaire de jetons de Muse est une limite distincte.

Quel fuseau horaire un rapport hebdomadaire Flowsery utilise-t-il ?

Celui que vous nommez dans l'appel. Si startAt et endAt arrivent sans timezone, Flowsery les répartit selon le fuseau horaire du site web, réglé dans Flowsery et pas forcément le vôtre. Indiquez le fuseau dans le prompt, sinon "la semaine dernière" peut couvrir sept autres jours que ceux de votre calendrier.

Créez un jeton d'espace de travail et donnez la spécification à Muse, ou lisez la référence de l'API d'abord.

Sources : l'article d'aide de Meta sur les connecteurs Muse, l'analyse de Parallel sur les intégrations personnalisées de Muse (14 septembre 2026) et la spécification OpenAPI de Flowsery. Vérifié le 20 septembre 2026.