ADR-OBS-001 — Loki comme backend de logs de référence

Version : 1.0
Date : 25 janvier 2026
Cycle de Réalignement Boréal : CRB-3
Statut : Adopté (référence vivante)
Portée : Fédération (C3), Pivot (C5), Membres affiliés, Tenants (C6–C8)

1. Contexte

L’Alliance Boréale requiert une capacité de journalisation (logs) commune, interopérable et auditable, compatible avec :

La séparation Fédération / Pivot / Tenants
Le principe adjacent-only (aucun flux ne saute une couche)
La portabilité des tenants (export/rejeu possible, preuves de fonctionnement)

Les logs sont un intrant critique pour :

la résilience opérationnelle (diagnostic, incident, détection)
la conformité (preuves, audits, traçabilité)
la gouvernance (ΔLog et boucles de rétroaction)

2. Décision

Grafana Loki est adopté comme backend de logs de référence pour l’architecture de référence Alliance Boréale.

Cela signifie :

Référence technologique

Loki est l’implémentation de référence pour l’ingestion, le stockage, la rétention et la requête de logs.

Référence d’intégration

Les flux logs des tenants (C6–C8) et des services pivot (C5) transitent via le Pivot (C5) vers la capacité observabilité fédérée (C3), conformément à l’adjacent-only.

Référence d’agent

Grafana Alloy est l’agent de collecte/expédition recommandé par défaut.
Les alternatives sont tolérées uniquement si elles respectent le contrat de la politique POL-OBS-LOG-001.

3. Alternatives considérées

A) Stack “full-text” (indexation complète)

Avantage : recherche textuelle plus directe.
Inconvénients : coût/complexité plus élevés, risques de dérives (indexation incontrôlée, PII), difficile à rendre “facile aux petits”.

B) “Un Loki par membre” (décentralisé)

Avantage : simplicité locale, autonomie.
Inconvénients : dispersion des pratiques, consolidation fédérale plus difficile, effort d’opération multiplié.

C) “Loki fédéré + ingestion via Pivot” (modèle retenu)

Avantages : simplicité pour les petits (un seul endpoint), cohérence fédérale, contrôle d’accès et preuves centralisées, isolation par tenant.
Inconvénient : nécessite un pivot/gateway bien cadré (mais c’est déjà un invariant C5).

4. Conséquences (ce que cela change)

4.1 Pour les membres affiliés (petits inclus)

Ils n’ont pas l’obligation d’opérer Loki localement.
Ils doivent être compatibles Loki : capacité d’expédier des logs via l’endpoint standard (TLS, auth, labels conformes).

4.2 Pour la Fédération (C3)

Opération d’un Loki “référence” (au minimum en mode simple) + Grafana de consultation.
Mise en place des politiques : rétention, quotas, RBAC, preuves auditables.

4.3 Pour le Pivot (C5)

Le pivot devient le point d’entrée unique pour l’ingestion et la consultation (proxy/gateway).
Le pivot applique l’authentification, la médiation (multi-tenant masquée) et les contrôles de conformité (labels/quotas).

5. Décision opérationnelle de démarrage (MVP)

Mode de déploiement Loki : démarrage en mode simple (priorité à l’opérabilité).
Chemin d’ingestion : agents (C6/C5) → Gateway Pivot (C5) → Loki (C3).
Chemin de consultation : utilisateurs → Grafana (C3) via Gateway Pivot (C5) + SSO (Keycloak).
Multi-tenant : géré par le Pivot (C5). Les petits n’ont pas à manipuler l’isolation.

6. Critères d’acceptation

La décision est considérée “en place” lorsque :

Un membre affilié peut expédier des logs avec Alloy vers l’endpoint pivot, sans configuration complexe.
Les labels minimaux requis sont présents et conformes (cardinalité maîtrisée).
Un utilisateur autorisé peut consulter les logs dans Grafana via SSO.
La rétention par défaut est appliquée et vérifiable.
Les preuves minimales d’audit (configuration + traces d’exécution + exemple de requêtes) sont archivées.

4.1 KiB Raw Blame History Unescape Escape