# 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 :

1. **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.

1. **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.

1. **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 :

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

---