feat(scale): observability at scale (OpenTelemetry + log aggregation + multi-tenant SLO)

[Yanstart]

Cadrage stratégique 2026 (mai 2026) — PIVOT PRODUIT

Observabilité pour produit multi-tenant à N réplicas. Sans elle, opérer
à l'échelle est aveugle.
Voir `.claude/memory/VISION_ALIGNMENT.md §0.6`.

Contexte

Aujourd'hui : Prometheus + Grafana + Alertmanager (Wave 7 platform hardening).
Métriques infrastructure OK pour mono-tenant.

Manque pour produit multi-tenant :

1. Distributed tracing : suivi d'une request à travers backend → DB → ML → cache
2. Log aggregation : logs structurés agrégés et requêtables (Loki / Elasticsearch)
3. Tags multi-tenant : chaque métrique / log / trace porte `tenant_id` pour requêtes ciblées
4. SLO / SLI par tenant : disponibilité, latence, erreurs mesurées par tenant, pas globalement
5. Audit AI Act observable : queries d'audit par tenant exposables aux Notified Bodies

Cible

1. OpenTelemetry : instrumentation traces + métriques + logs unifiée (standard CNCF, vendor-neutral)
2. Backend traces collector : OpenTelemetry Collector → Jaeger ou Tempo
3. Log aggregation : Loki + Promtail (lightweight) OU stack ELK selon volume
4. SLO framework : Pyrra OU Sloth pour générer alertes Prometheus à partir de SLOs déclarés
5. Dashboards Grafana : un set de dashboards par tenant + un dashboard "multi-tenant overview"
6. Conformité RGPD : pas de PHI dans les logs/traces, vérification automatisée

Approche technique proposée

1. Backend :
   • Ajouter `opentelemetry-api`, `opentelemetry-sdk`, `opentelemetry-instrumentation-fastapi`, `opentelemetry-instrumentation-sqlalchemy` à `requirements.txt`
   • Tag automatique `tenant_id` injecté via middleware (extracted from JWT)
   • Logs JSON structurés (déjà partiellement en place via `audit`) avec champ `tenant_id`
2. Stack ops : ajouter Tempo (traces) + Loki (logs) à `docker-compose.yml --profile monitoring`
3. OpenTelemetry Collector : config qui route traces → Tempo, logs → Loki, métriques → Prometheus
4. Frontend : @opentelemetry/sdk-web pour traces UI (clic → API → DB) — optionnel
5. SLO : 4 SLO de référence par tenant (availability 99.9%, P95 latency tile, P95 latency annotation API, error rate < 1%)

Acceptance criteria

• OpenTelemetry instrumentation complet du backend
• Tag `tenant_id` sur toutes les métriques / logs / traces
• Tempo + Loki dans `docker-compose.yml --profile monitoring`
• Dashboards Grafana : per-tenant + multi-tenant overview
• SLO framework déclaratif (Pyrra ou Sloth)
• Tests : trace d'une request "GET /tile" visible end-to-end (frontend → backend → DB → cache → S3)
• Conformité RGPD : test automatisé refuse les logs avec PHI (regex check)
• AI Act audit query : exemple de requête "toutes les inférences ML pour tenant X dans la période Y"
• Documentation runbook `docs/Admin/observability.md`

Dépendances

• Wave 13 feat(scale): multi-tenant data isolation + auth federation #354 (multi-tenant) — `tenant_id` propagation
• Wave 13 #N15 (deployment) — collector déployé en cluster

Aval

• Wave 12 feat(compliance): documentation AI Act (traçabilité, qualité données, transparence) pour Notified Bodies #349 (AI Act doc) — réutilise les capacités d'audit query
• Wave 13 #N16 (perf benchmarks) — utilise SLO framework

Références

• `.claude/memory/VISION_ALIGNMENT.md §0.6`
• OpenTelemetry : https://opentelemetry.io
• Tempo : https://grafana.com/oss/tempo/
• Loki : https://grafana.com/oss/loki/
• Pyrra (SLO) : https://github.com/pyrra-dev/pyrra
• SRE workbook : https://sre.google/workbook/