# Le rapport client hebdomadaire, rédigé par un agent chaque lundi avant votre réveil

_2026-09-25 · Un rapport client hebdomadaire compilé par un agent depuis Shager : publications, échecs, clics par compte et par publication, et rapprochement avec le CRM._

Un agent peut rédiger le rapport de diffusion hebdomadaire d'un client en récupérant trois choses dans Shager : les publications diffusées dans la semaine et leur résultat compte par compte, les clics par compte et par publication via `get_analytics`, et la liste de tout ce qui a échoué. Il rapproche ensuite ces clics des prospects du CRM du client grâce à la valeur `utm_content`, qui identifie chaque compte. Lancez-le à intervalle régulier avec une clé en lecture seule, et le rapport vous attend dans un dossier le lundi matin.

Ce qui demande de la réflexion, ce n'est pas le code. C'est de décider ce que le client a réellement besoin de voir, et d'être honnête sur ce que mesurent les chiffres.

## Que doit contenir un rapport de diffusion hebdomadaire ?

Quatre sections suffisent. Tout le reste relève du bilan mensuel.

1. **La diffusion.** Combien de publications sont parties, sur combien de comptes, et quels comptes ont échoué. Les clients posent rarement la question tant que rien ne manque, et ensuite ils ne parlent plus que de ça.
2. **Les clics par compte.** Quelles pages, quels établissements ou quelles chaînes ont envoyé du monde sur le site. C'est la section qui fait bouger les budgets.
3. **Les clics par publication.** Quels contenus ont fonctionné, tous comptes confondus.
4. **Les actions.** Ce que le client doit faire : reconnecter un compte, valider les brouillons de la semaine suivante, envoyer les éléments manquants.

Remarquez ce qui n'y figure pas : la portée, les impressions, les J'aime. Shager mesure les clics sur ses propres liens suivis, par compte et par publication. Il ne prétend pas être une suite d'analyse des réseaux sociaux, et le rapport ne doit pas laisser croire le contraire.

## Les appels de données

Pour l'espace de travail d'un client, l'agent exécute cette séquence. Les noms d'outils sont les vrais outils MCP ; leurs équivalents REST se trouvent dans le [document OpenAPI](https://app.shager.ai/api/v1/openapi.json).

1. `list_workspaces` pour retrouver l'espace du client par son nom.
2. `list_posts` avec `status` réglé sur `PUBLISHED`, puis à nouveau avec `PARTIALLY_PUBLISHED` et `FAILED`. `limit` peut aller jusqu'à 100.
3. `get_post` pour chaque publication de la semaine, afin d'obtenir l'état par compte, les URL en ligne et les messages d'erreur.
4. `get_analytics` avec `from` et `to` couvrant la semaine.
5. `list_channels`, pour associer les ID de canaux à des noms de comptes lisibles et repérer les comptes dont l'état de connexion a changé.

L'appel aux statistiques en REST :

```bash
curl -s "https://app.shager.ai/api/v1/workspaces/ws_example/analytics?from=2026-09-14T00:00:00%2B03:00&to=2026-09-20T23:59:59%2B03:00" \
  -H "Authorization: Bearer $SHAGER_READ_KEY"
```

Deux détails de cette URL piègent souvent. Le `+` du décalage doit être encodé en `%2B` dans une chaîne de requête, sinon le serveur le lit comme une espace. Et les bornes de la semaine doivent être calculées dans le fuseau horaire du client, pas dans celui du serveur. Si `from` est omis, `get_analytics` prend par défaut les 30 derniers jours, ce qui n'est pas ce que veut un rapport hebdomadaire.

## Des clics ne sont pas des prospects : rapprochez-les

Shager donne à chaque compte son propre lien court et ses propres balises UTM, avec un `utm_content` qui identifie le compte. C'est ce qui rend le rapprochement possible. Le CRM enregistre les prospects avec les valeurs UTM captées par le formulaire de la page d'atterrissage ; l'agent les rapproche des clics par compte de Shager sur la même valeur `utm_content`.

Le tableau qui en résulte est le cœur du rapport :

| Compte | Publications | Clics (Shager) | Prospects (CRM) | Remarque |
|---|---|---|---|---|
| Aurora Downtown | 4 | ... | ... | |
| Aurora Northside | 4 | ... | ... | reconnexion nécessaire |

Les écarts entre les colonnes sont une information. Beaucoup de clics et aucun prospect, c'est un problème de page d'atterrissage ou d'offre, pas de diffusion. Notre guide sur [l'attribution des prospects par compte](/fr/blog/utm-per-account-lead-attribution) présente les champs de formulaire et le mapping CRM qui rendent la colonne des prospects fiable, et [mesurer les prospects issus du contenu d'agents](/fr/blog/measuring-leads-from-agent-content) traite le côté agent.

Si vous n'avez pas accès au CRM, le rapport fonctionne quand même avec les seuls clics. Indiquez-le en tête de rapport. Un rapport qui présente les clics comme des « résultats », c'est ainsi que les agences perdent la confiance de leurs clients un trimestre plus tard.

## Le faire tourner sans surveillance avec Claude Code

Claude Code peut fonctionner en mode non interactif avec `claude -p`, comme le décrit sa [documentation du mode headless](https://code.claude.com/docs/en/headless). Le rapport hebdomadaire devient alors une simple tâche cron.

D'abord, un dossier de projet pour les rapports, avec un `.mcp.json` qui lit la clé depuis l'environnement. La [documentation MCP de Claude Code](https://code.claude.com/docs/en/mcp) prend en charge l'expansion `${VAR}` dans les en-têtes :

```json
{
  "mcpServers": {
    "shager": {
      "type": "http",
      "url": "https://app.shager.ai/api/mcp",
      "headers": { "Authorization": "Bearer ${SHAGER_READ_KEY}" }
    }
  }
}
```

Ensuite, les instructions, enregistrées sous forme de skill pour que la logique tienne dans un seul fichier plutôt que dans une ligne de crontab. Claude Code charge les skills de projet depuis `.claude/skills/<name>/SKILL.md`, selon sa [documentation des skills](https://code.claude.com/docs/en/skills) :

```markdown
---
name: weekly-report
description: Compile the weekly distribution report for one client workspace from Shager. Use when asked for a weekly client report.
---

The argument is the client workspace name: $ARGUMENTS

1. Resolve the workspace with list_workspaces. Read its timezone.
2. Compute last Monday 00:00 to Sunday 23:59:59 in that timezone, with offsets.
3. Collect posts with list_posts (PUBLISHED, PARTIALLY_PUBLISHED, FAILED) and
   keep those published in the window. Call get_post for each.
4. Call get_analytics for the window. Map channel ids to names with list_channels.
5. If crm/<workspace>.csv exists, join leads on utm_content.
6. Write reports/<workspace>/<YYYY-MM-DD>.md with four sections: Delivery,
   Clicks by account, Clicks by post, Actions. Use tables. No adjectives about
   performance; numbers and one plain sentence per section.
7. Never call any tool that creates, schedules or cancels anything.
```

Enfin, la commande planifiée, qui ne pré-approuve que les outils de lecture et l'écriture de fichiers :

```bash
cd ~/agency-reports && claude -p "/weekly-report Aurora" \
  --allowedTools "mcp__shager__list_*,mcp__shager__get_*,mcp__shager__whoami,Write" \
  --output-format json > logs/aurora-$(date +%F).json
```

La syntaxe des règles d'autorisation avec un préfixe `mcp__<server>__` et un joker final est documentée dans la [référence des autorisations](https://code.claude.com/docs/en/permissions) de Claude Code. Tout ce qui ne figure pas dans cette liste ne sera pas approuvé automatiquement lors d'une exécution sans surveillance.

## Pourquoi une clé en lecture seule est essentielle ici

La skill demande au modèle de ne pas écrire. La clé le rend impossible. Créez, dans le tableau de bord des agents, une clé distincte avec la seule portée `read` pour le reporting, et ne l'utilisez nulle part ailleurs. Si cette clé fuit un jour, le pire scénario est que quelqu'un lise des nombres de clics. Nous détaillons le modèle de portées complet dans [clés API, portées et audit](/fr/blog/api-keys-scopes-and-audit).

Chaque appel de l'agent de reporting apparaît aussi dans le journal d'audit de ce tableau de bord : un bon moyen de vérifier, les premiers lundis, qu'il appelle ce que vous attendez et rien de plus.

## Rédiger la partie commentée

Laissez l'agent écrire une ou deux phrases par section, mais encadrez-le. Sans règles, les modèles décrivent une variation de 4 % comme « une hausse significative ». Mon instruction est sans détour : donner le chiffre, le comparer à la semaine précédente si elle est disponible, et ne rien dire des causes sauf si les données les montrent. Si la page d'un établissement n'a eu aucun clic parce que sa connexion a expiré mardi, c'est une cause que les données montrent. « La lassitude de l'audience », non.

## FAQ

### L'agent peut-il envoyer le rapport directement au client ?

Oui, si vous lui donnez un outil d'e-mail, mais je ne le ferais pas dès le premier jour. Faites-lui écrire le fichier, relisez quelques semaines de rapports, puis automatisez l'envoi. Le rapport, c'est la vitrine de votre travail aux yeux du client, et un chiffre erroné envoyé automatiquement coûte plus cher que le temps gagné.

### get_analytics inclut-il les prospects ?

Non. Il renvoie les clics sur les liens suivis de Shager, par compte et par publication, sur une période donnée. Les prospects viennent du CRM ou de l'outil de formulaire du client, rapprochés sur `utm_content`. Le rapport doit garder les deux sources clairement séparées.

### Jusqu'où le rapport peut-il remonter ?

`get_analytics` accepte n'importe quelles valeurs `from` et `to`, avec par défaut les 30 derniers jours quand `from` est omis. Pour comparer d'un mois sur l'autre, lancez la même skill avec une autre période plutôt que de traiter les anciens rapports comme source de vérité.

## Pour aller plus loin

Si vous n'avez pas encore de clé, le [point d'entrée pour les agents](/fr/agents) explique comment en créer une ou laisser un agent s'inscrire lui-même. Commencez par un seul client, lisez vous-même les rapports de trois lundis, et seulement ensuite ajoutez les autres.

---
Source: https://shager.ai/fr/blog/weekly-client-report-by-agent