Format de résumé KPI Slack pour les rapports générés par agent

Cette note couvre les conventions de format pour les résumés KPI Slack générés par agent et l’approche garantissant la fiabilité des calculs. Une sortie cohérente nécessite des instructions délibérées ; des calculs fiables nécessitent de pré-calculer les valeurs en SQL plutôt que de déléguer l’arithmétique au LLM.

Le modèle

Cette structure fonctionne bien pour les résumés hebdomadaires orientés clients :

📊 Rapport KPI Hebdomadaire — Acme Corp
Semaine du 10 au 16 mars 2026

Sessions : 12 847 (↑ 8 % vs semaine dernière)
Conversions : 342 (↓ 3 %)
Taux de conversion : 2,66 % (↓ 0,3 pp)
Revenus : 47 291 € (↑ 12 %)
Valeur moyenne des commandes : 138,28 € (↑ 15 %)

Principales sources de trafic :
1. Recherche organique — 6 204 sessions (↑ 11 %)
2. Recherche payante — 3 102 sessions (→ stable)
3. Direct — 2 441 sessions (↓ 5 %)

À noter : Revenus en hausse malgré un taux de conversion plus faible.
VCM plus élevée portée par le lancement de la campagne de printemps.

Les choix de conception sont expliqués ci-dessous.

La convention des flèches directionnelles

↑, ↓ et → donnent une lecture visuelle instantanée sans que le lecteur ait à comparer deux chiffres. La flèche communique la direction ; le pourcentage quantifie l’amplitude. Ensemble, ils répondent à la question principale (« est-ce que ça monte ou descend ? ») avant que le lecteur ne traite les chiffres spécifiques.

Utiliser → stable au lieu de (0 %) pour les changements quasi nuls reconnaît qu’un changement de 0,3 % dans une métrique bruitée n’est pas significativement différent du stable. C’est un jugement éditorial qui appartient au format, pas quelque chose à laisser à la discrétion de l’agent à chaque exécution.

Définissez les seuils dans vos instructions d’agent :

Conventions de direction :
- ↑ pour les augmentations supérieures à 1 %
- ↓ pour les diminutions supérieures à 1 %
- → stable pour les changements entre -1 % et +1 %

Cela empêche l’agent d’inventer sa propre interprétation de seuil d’une exécution à l’autre.

Points de pourcentage vs pourcentages

La ligne du taux de conversion dit ↓ 0,3 pp, pas ↓ 10 %. Cette distinction compte.

Si le taux de conversion passe de 2,96 % à 2,66 %, c’est une baisse de 0,3 point de pourcentage. C’est aussi une baisse relative de 10 % (0,3 / 2,96). Les deux sont vrais. Mais « en baisse de 10 % » sonne alarment d’une façon que « en baisse de 0,3 point de pourcentage » ne fait pas. Pour une métrique de taux, le changement absolu (pp) est généralement plus informatif pour la personne qui prend des décisions.

Utiliser % pour les changements relatifs sur les métriques de volume (sessions, revenus) et pp pour les changements absolus sur les métriques de taux (taux de conversion, taux de clics, taux de rebond) est le standard dans le reporting professionnel. Intégrez cette distinction dans vos instructions d’agent explicitement, car les LLMs utiliseront par défaut la formulation qui semble la plus naturelle dans le contexte — ce qui est incohérent.

Règles de formatage :
- Utiliser % pour les changements de métriques de volume (sessions en hausse de 8 %)
- Utiliser pp pour les changements de métriques de taux (taux de conversion en baisse de 0,3 pp)

La ligne d’interprétation « À noter »

La phrase d’interprétation unique au bas du résumé est la partie la plus précieuse et la plus dangereuse du modèle.

Précieuse : elle synthétise les changements individuels de métriques en une seule phrase explicative — « Revenus en hausse malgré un taux de conversion plus faible, porté par une VCM plus élevée » — qui nécessiterait autrement une question de suivi.

Dangereuse : les LLMs infèrent des patterns à partir du timing et des chiffres sans connaître la cause réelle. Un agent qui infère que « le lancement de la campagne de printemps a porté la VCM » produit une interprétation plausible, pas une interprétation vérifiée. Les clients traitent les interprétations écrites comme faisant autorité, surtout dans les rapports automatisés.

La ligne « À noter » devrait être traitée comme un brouillon et revue avant la livraison aux clients.

Une alternative qui réduit le risque : remplacez le « À noter » ouvert par un prompt structuré :

Si une métrique a changé de plus de 15 % semaine sur semaine, expliquez-le en une phrase.
Si aucune métrique n'a changé de plus de 15 %, omettez cette section.

Cela limite l’interprétation aux cas où quelque chose de genuinement notable s’est produit, plutôt que de générer une interprétation qu’il y ait ou non quelque chose de significatif à dire.

Pousser les calculs dans SQL

Les LLMs produisent des chiffres vraisemblables mais ne sont pas des calculateurs fiables. La même entrée peut produire différentes valeurs de pourcentage dans différentes exécutions. Pré-calculer toutes les valeurs en SQL et demander à l’agent de narrer des résultats pré-calculés élimine cette variabilité.

Pré-calculez chaque chiffre dans la requête SQL :

SELECT
  this_week.sessions,
  last_week.sessions AS sessions_last_week,
  ROUND(
    (this_week.sessions - last_week.sessions) * 100.0 / last_week.sessions,
    1
  ) AS sessions_pct_change,
  this_week.conversions,
  ROUND(this_week.conversions * 100.0 / this_week.sessions, 2) AS conversion_rate,
  ROUND(last_week.conversions * 100.0 / last_week.sessions, 2) AS conversion_rate_last_week,
  ROUND(
    (this_week.conversions * 100.0 / this_week.sessions) -
    (last_week.conversions * 100.0 / last_week.sessions),
    2
  ) AS conversion_rate_pp_change
FROM ...

L’agent reçoit des valeurs pré-calculées et les narre : « Sessions : 12 847 (↑ 8,0 %) » plutôt que de calculer 8,0 à partir des chiffres bruts.

Le même principe s’applique aux flèches directionnelles. Ajoutez une colonne que l’agent peut utiliser directement :

SELECT
  ...,
  CASE
    WHEN sessions_pct_change > 1 THEN '↑'
    WHEN sessions_pct_change < -1 THEN '↓'
    ELSE '→'
  END AS sessions_direction
FROM ...

L’agent colle ↑ 8,0 % plutôt que de décider si 8 % qualifie comme « en hausse ».

Cohérence de format entre les exécutions

Le plus grand défi de format avec les rapports générés par agent n’est pas de bien configurer le format la première fois — c’est de le maintenir cohérent semaine après semaine. Les agents ont tendance à dériver. Le résumé qui ressemble à une chose la semaine 1 peut avoir un ordre de sections différent, des emojis différents et une formulation différente à la semaine 4, parce que le modèle génère du texte plutôt que de suivre un modèle rigide.

Deux approches stabilisent cela :

Donnez à l’agent un exemple de sortie. Incluez le modèle complet comme exemple littéral dans votre message cron ou fichier de compétence. Les agents font une correspondance de pattern contre des exemples plus fiablement qu’ils ne suivent des descriptions de format abstraites. « Formatez la sortie comme ceci : [coller le modèle] » surpasse « utilisez des flèches pour les changements directionnels et incluez une ligne à noter ».

Stockez le modèle dans un fichier. Mettez le modèle de format dans un fichier Markdown (~/reports/acme/summary-template.md) et demandez à l’agent de le suivre : « Formatez les résultats en suivant la structure dans le fichier summary-template.md. » Cela facilite aussi l’itération sur le modèle sans toucher au job cron.

Voir Compétences OpenClaw pour le monitoring pour la façon dont la même approche de modèle par exemple fonctionne pour le formatage des alertes de monitoring — les mêmes principes s’appliquent ici.

Ce qu’il faut vérifier avant d’envoyer aux clients

Même avec des chiffres SQL pré-calculés et un modèle rigide, quelques éléments méritent une vérification manuelle avant que les rapports orientés clients partent à grande échelle :

Les flèches directionnelles correspondent aux changements en pourcentage. Un ↑ sur une métrique en baisse signifie que quelque chose s’est cassé.
La ligne « À noter » ne contient pas d’interprétation erronée affirmée avec confiance. Un coup d’œil rapide est suffisant.
La plage de dates dans l’en-tête correspond aux données réelles. L’agent calcule parfois mal « la semaine dernière » dans le texte d’en-tête même quand la logique de dates SQL est correcte.
Le formatage des devises et unités correspond aux attentes du client. Un client en France qui attend des euros ne veut pas voir des signes dollar.

La vérification manuelle ajoute du temps mais réduit le risque d’envoyer des chiffres incorrects aux clients. Intégrer un bref contrôle dans un workflow hebdomadaire est raisonnable jusqu’à ce que la sortie ait été validée à un volume suffisant pour lui faire confiance à distance.