# Tableaux de bord

:::caution
**Aucun tableau de bord n'est provisionné.** Les données sont interrogeables chez les quatre
fournisseurs, ce qui est vérifié ; les tableaux de bord restent à construire. Cette page décrit
ce qui est possible et par quel moyen, en distinguant ce qui est automatisable de ce qui ne l'est
pas.
:::

## État

| Fournisseur | Provisionnement par API                              | État                                  |
| ----------- | ---------------------------------------------------- | ------------------------------------- |
| OpenObserve | oui (`/api/{org}/dashboards`)                        | Non fait                              |
| Umami       | non documenté                                        | Non fait, vues natives disponibles    |
| Matomo      | oui (`API.getReportMetadata`, widgets)               | Non fait, rapports natifs disponibles |
| Rybbit      | partiel (entonnoirs via `/api/sites/{site}/funnels`) | Non fait                              |

Umami et Rybbit offrent des vues prêtes à l'emploi sans configuration : audience, pages, référents,
événements. Pour un POC de comparaison, elles suffisent et ne demandent aucun travail.

## Ce qui est mesurable avec le catalogue actuel

Avec les cinq événements de [events.md](/analytics/prise-en-main/events) :

- pages vues, visiteurs, sessions — natif chez les trois fournisseurs ;
- recherches sans résultat (`search_performed` avec `outcome: zero_results`) — l'indicateur le plus
  utile du projet, déjà suivi par `trackSiteSearch` côté Matomo ;
- clics vers les sources externes par catégorie (`outbound_link_clicked`) ;
- consultations de fiches par type (`record_viewed`).

## Ce qui n'est pas mesurable, et pourquoi

Le cahier des charges demande DAU/WAU/MAU, entonnoir d'inscription, adoption de fonctionnalité,
rétention et attribution de campagne. **La plupart n'ont pas de sens ici** :

- pas d'inscription ni de compte : aucun entonnoir d'activation ;
- pas d'identification (ADR 006) : la rétention par utilisateur est hors d'atteinte, seule une
  approximation par session est possible ;
- `agent_created` et `agent_run_completed` de l'exemple n'existent pas dans ce produit.

Provisionner des panneaux pour des signaux qui ne sont pas collectés produirait des tableaux de bord
vides. Le cahier des charges l'interdit explicitement, à raison.

## Pour OpenObserve

L'API accepte une définition JSON :

```bash
AUTH=$(grep '^OPENOBSERVE_AUTH=' infra/analytics/compose/.env | cut -d= -f2-)
curl -X POST "http://localhost:5080/api/default/dashboards" \
  -H "Authorization: $AUTH" -H 'Content-Type: application/json' \
  -d @mon-tableau-de-bord.json
```

Panneaux qui correspondent à des signaux **réellement collectés** aujourd'hui : volume de journaux
par niveau, durée des spans par nom d'opération, compteurs applicatifs exportés par la façade.

Tout le reste — latence HTTP par centile, erreurs par route, santé des conteneurs — suppose
d'activer l'instrumentation automatique et un exportateur d'hôte, ce qui n'est pas fait.

## Chaîne analytics

Le cahier des charges demande un tableau de bord sur la chaîne elle-même : événements générés,
acceptés, rejetés, réessais, arriéré, erreurs par fournisseur. Les compteurs **existent** dans
`AnalyticsClient.getStats()` et `EventQueue.getStats()`, mais ne sont pas encore exportés en
métriques OpenTelemetry. C'est le chaînon manquant le plus simple à ajouter, et le plus utile pour
exploiter la chaîne.