# 📄 Document 6 : Standards d'Interopérabilité Technique

**Version :** 1.0  
**Date :** 26 octobre 2025  
**Statut :** Document opérationnel  
**Objet :** Définir les standards techniques obligatoires et recommandés pour garantir l'interopérabilité entre membres de l'Alliance Boréale.  
**Compatibilité :** Conforme aux documents `00_Modele_8_couches_v3.md`, `00_Nomenclature_v3.md` et `00_Glossaire_v3.md`.

---

## 🌱 Préambule

> L'interopérabilité n'est pas une contrainte technique — c'est une **garantie de liberté**.  
> Chaque protocole ouvert est une porte de sortie, chaque standard mature est une promesse de pérennité.

Ce document s'inscrit dans le principe de **portabilité des tenants** (§1.2 de `00_Nomenclature_v3.md`) et respecte le principe **adjacent-only** (§2.1 de `00_Modele_8_couches_v3.md`).

---

## 🧬 1. Philosophie de l'interopérabilité

### 1.1 Principes directeurs

Conformément au **Glossaire v3** (Famille C — Lexique cognitif), l'Alliance adopte les principes suivants :

| Principe | Signification | Référence |
|----------|--------------|-----------|
| **Protocoles ouverts avant tout** | Standards publics, documentés, implémentables librement | Modèle v3 §5.1 |
| **Préférence pour standards matures** | RFCs, W3C, spécifications éprouvées | Glossaire v3 |
| **Éviter les silos technologiques** | Refus de toute solution propriétaire sans alternative | Règlement v3 §II |
| **Faciliter la migration des utilisateurs** | Portabilité garantie (export complet testable) | Nomenclature v3 §1.2 |

### 1.2 Hiérarchie des standards

```
Obligatoire → Implémentation requise pour conformité minimale
Recommandé  → Implémentation fortement encouragée
Optionnel   → Valeur ajoutée, non requis pour le label
```

---

## 🔐 2. Identité fédérée (Single Sign-On)

**Couche concernée :** C3 (Gouvernance) → C5 (Pivot) → C6 (Services tenant)

### 2.1 Standards requis (Obligatoires)

Conformément à `00_Nomenclature_v3.md` §1.2.4 (Identité & DNS fédérés) :

| Standard | Version minimale | Usage |
|----------|------------------|-------|
| **OpenID Connect** | 1.0 | Authentification fédérée (recommandé) |
| **SAML 2.0** | 2.0 | Authentification fédérée (accepté) |
| **OAuth 2.0** | 2.1 | Autorisation pour APIs |

### 2.2 Implémentations recommandées

| Solution | Type | Justification |
|----------|------|---------------|
| **Keycloak** | IdP complet | Référence recommandée, mature, open source |
| **Authelia** | Proxy auth | Léger, adapté aux petites structures |
| **Authentik** | IdP moderne | Alternative viable, interface moderne |

**Exigence minimale :** Publication des métadonnées de fédération (.well-known/openid-configuration)

### 2.3 Attributs minimaux échangés

Conformément au principe de **minimisation des données** (Cadre Conformité v3 §2.3) :

```yaml
attributs_obligatoires:
  - sub: Identifiant unique (UUID ou équivalent)
  - email: Adresse courriel de contact
  - name: Nom d'affichage

attributs_optionnels:
  - groups: Appartenance à des groupes/rôles
  - picture: Avatar utilisateur
```

### 2.4 Respect du principe adjacent-only

**IMPORTANT :** Les tenants (C6-C8) **ne communiquent jamais directement** avec l'IdP fédéré (C3).  
Toutes les authentifications passent par **C5 (Pivot)**.

```
Flux correct :
Tenant C6 → C5 (Pivot) → C3 (IdP Keycloak) → C5 → C6

Flux interdit :
Tenant C6 ──X──> C3 (accès direct)
```

---

## 📧 3. Courriel

**Couche concernée :** C2 (Réseau/DNS) + C6 (Services)

### 3.1 Standards obligatoires

| Standard | RFC | Fonction |
|----------|-----|----------|
| **SMTP** | RFC 5321 | Envoi de messages |
| **IMAP / POP3** | RFC 3501 / 1939 | Réception de messages |
| **DKIM** | RFC 6376 | Signature des messages |
| **SPF** | RFC 7208 | Validation expéditeur |
| **DMARC** | RFC 7489 | Politique de validation |
| **TLS** | RFC 8314 | Chiffrement transport (STARTTLS obligatoire) |

### 3.2 Fonctionnalités recommandées

| Fonctionnalité | Standard | Justification |
|----------------|----------|---------------|
| **S/MIME** | RFC 8551 | Chiffrement bout-à-bout |
| **PGP/GPG** | RFC 4880 | Alternative chiffrement E2E |
| **Listes de diffusion** | — | Mailman 3, Sympa (facilite la coopération) |
| **Antispam collaboratif** | — | Rspamd, SpamAssassin (mutualisation possible) |

### 3.3 Configuration DNS minimale

Conformément à `00_Nomenclature_v3.md` §4 (Plan d'adressage) :

```dns
; Exemple pour membre.alliance-boreale.ca
membre.alliance-boreale.ca.    IN MX 10 mail.membre.alliance-boreale.ca.
membre.alliance-boreale.ca.    IN TXT "v=spf1 mx -all"
_dmarc.membre.alliance-boreale.ca. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@membre.ca"
default._domainkey.membre.ca.  IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."
```

---

## 📁 4. Partage de fichiers et collaboration

**Couche concernée :** C6 (Services tenant)

### 4.1 Protocoles ouverts obligatoires

| Protocole | RFC/Standard | Usage |
|-----------|--------------|-------|
| **WebDAV** | RFC 4918 | Partage de fichiers web |
| **CalDAV** | RFC 4791 | Calendriers partagés |
| **CardDAV** | RFC 6352 | Carnets d'adresses |
| **SFTP/SCP** | — | Transfert sécurisé fichiers |

### 4.2 Solutions recommandées

| Solution | Type | Justification |
|----------|------|---------------|
| **Nextcloud** | Suite complète | Référence recommandée (fichiers + calendriers + contacts) |
| **Seafile** | Stockage fichiers | Alternative performante |
| **ownCloud** | Suite complète | Alternative viable |

**Exigence :** Support **obligatoire** de WebDAV pour la portabilité des données.

### 4.3 Partage public

- Liens de partage temporaires (avec expiration configurable)
- Protection par mot de passe optionnelle
- Limitation du nombre de téléchargements

---

## 🎥 5. Visioconférence

**Couche concernée :** C6 (Services tenant)

### 5.1 Standards et protocoles

| Standard | Usage | Statut |
|----------|-------|--------|
| **Jitsi Meet** | Visioconférence web | Recommandé |
| **SIP/RTP** | Protocole téléphonie | Pour interopérabilité |
| **WebRTC** | Communication temps réel | Sous-jacent à Jitsi |

### 5.2 Exigences

- ✅ Hébergement local (pas de relais cloud propriétaire)
- ✅ Chiffrement bout-à-bout optionnel (selon sensibilité)
- ✅ Enregistrement possible (avec consentement explicite des participants)
- ❌ Interdiction de solutions propriétaires sans alternative (Zoom, Teams)

**Conformité éthique :** Respect du principe de **sobriété numérique** (Glossaire v3) — privilégier audio seul si vidéo non nécessaire.

---

## 💬 6. Messagerie instantanée

**Couche concernée :** C6 (Services tenant)

### 6.1 Protocole requis

| Protocole | Version | Statut |
|-----------|---------|--------|
| **Matrix** | 1.0+ | Obligatoire (protocole fédéré) |

**Justification :** Matrix est le seul protocole de messagerie instantanée mature, fédéré et chiffré E2E par défaut.

### 6.2 Implémentation

| Composant | Solution recommandée |
|-----------|---------------------|
| Serveur | **Synapse** (référence) ou Dendrite, Conduit |
| Client web | Element Web |
| Clients mobiles | Element Android/iOS, FluffyChat |

### 6.3 Fonctionnalités requises

- ✅ Chiffrement E2E (Olm/Megolm) activé par défaut
- ✅ Fédération activée avec autres membres Alliance
- ✅ Salons publics pour coordination inter-membres
- ⚠️ Bridges optionnels (IRC, XMPP, Signal) pour interopérabilité externe

### 6.4 Configuration fédérée

Conformément au principe **adjacent-only**, la fédération Matrix passe par **C5 (Pivot)** :

```yaml
# Exemple délégation DNS (.well-known/matrix/server)
{
  "m.server": "matrix.pivot.membre.alliance-boreale.ca:8448"
}
```

---

## 🔨 7. Forge logicielle et gestion de projets

**Couche concernée :** C4 (Forge mutualisée)

### 7.1 Solutions recommandées

Conformément à `00_Modele_8_couches_v3.md` §2 (C4 = Métabolisme commun — Forge mutualisée) :

| Solution | Type | Statut |
|----------|------|--------|
| **Forgejo** | Forge Git | Préféré (fork communautaire de Gitea) |
| **Gitea** | Forge Git | Accepté |
| **GitLab CE** | Forge complète | Accepté (plus lourd) |

### 7.2 Interopérabilité

**Exigences minimales :**

- ✅ Git comme base (push/pull standard entre forges)
- ✅ APIs REST documentées (OpenAPI/Swagger)
- ✅ Webhooks pour intégration CI/CD
- ✅ Support des clés SSH et GPG
- ✅ Gestion des artefacts (packages, conteneurs)

### 7.3 Intégration avec C3 (Gouvernance)

Conformément au `02_Reglement_v3.md` §IV (Processus et flux décisionnels) :

- Toutes les décisions de gouvernance → versionnées dans la forge C4
- Politiques OPA (Open Policy Agent) → stockées et signées dans C4
- Traçabilité complète via Git history

---

## 📊 8. Monitoring et observabilité

**Couche concernée :** C5 (Pivot — collecte) + C3 (Gouvernance — agrégation)

### 8.1 Métriques partagées (Obligatoire)

Conformément à `00_Nomenclature_v3.md` §1.2.5 (Observabilité scindée) :

| Composant | Standard | Usage |
|-----------|----------|-------|
| **Prometheus** | OpenMetrics | Collecte métriques |
| **Grafana** | — | Visualisation |
| **Node Exporter** | — | Métriques système (CPU, RAM, disque) |

**Règle de séparation :**

```
Métriques infrastructure (C1-C4) → Propriété fédération
Métriques applicatives (C6-C8)  → Propriété tenant (exportables)
```

### 8.2 Logs centralisés (Optionnel)

| Standard | Usage | Justification |
|----------|-------|---------------|
| **JSON structuré** | Format logs | Parsing automatisé |
| **Syslog (RFC 5424)** | Transport | Interopérabilité |

**Important :** Respect de la vie privée — anonymisation obligatoire des données personnelles dans les logs.

### 8.3 Traces distribuées (Recommandé)

- OpenTelemetry (pour systèmes complexes multi-services)
- Export au format OTLP

---

## 🔄 9. Exceptions et évolutions

### 9.1 Processus de dérogation

Conformément au `02_Reglement_v3.md` §IV (Processus décisionnels) :

**Un membre peut demander une exception** à un standard obligatoire si :

1. Justification technique solide (incompatibilité avérée)
2. Plan de migration vers le standard (délai raisonnable)
3. Documentation de l'alternative utilisée

**Décision :** Cercle Technique (consentement sociocratique)  
**Validité :** 12 mois maximum, réévaluation obligatoire

### 9.2 Revue annuelle des standards

- **Périodicité :** Revue annuelle obligatoire (trimestre 1 de chaque année)
- **Déclencheurs :** 
  - Obsolescence d'un standard (fin de vie RFC)
  - Émergence de nouvelle technologie mature
  - Demande motivée d'un membre
- **Processus :** 
  1. Proposition documentée
  2. Période de discussion (30 jours)
  3. Décision Cercle Technique
  4. Mise à jour du présent document (v+1)

### 9.3 Intégration de nouveaux protocoles

**Critères d'acceptation :**

- ✅ Standard ouvert (RFC, W3C ou équivalent)
- ✅ Implémentations libres disponibles (≥2)
- ✅ Maturité démontrée (≥2 ans d'existence)
- ✅ Alignement avec les valeurs boréales (Glossaire v3 — Famille C)

---

## 📜 10. Annexe : Matrice de conformité

### 10.1 Niveaux de conformité du Label

Correspondance avec `03_Cadre_Conformite_v3.md` §2.4 (Interopérabilité & Fédération) :

| Niveau Label | Exigences interopérabilité |
|--------------|---------------------------|
| **Bronze** | SSO + Courriel standards + 1 service ouvert au choix |
| **Argent** | Bronze + WebDAV + Matrix |
| **Or** | Argent + Forge Git interopérable + Monitoring Prometheus |
| **Platine** | Or + Visio Jitsi + Traces distribuées |

### 10.2 Checklist d'auto-évaluation

```markdown
□ SSO (OpenID Connect ou SAML) configuré et testé
□ Courriel : DKIM + SPF + DMARC actifs
□ Partage fichiers : WebDAV accessible
□ Messagerie : Serveur Matrix fédéré
□ Forge : Git avec APIs REST documentées
□ Monitoring : Métriques Prometheus exportées
□ DNS : Enregistrements fédération publiés
□ Documentation : Standards implémentés listés publiquement
```

---

## 📖 11. Références documentaires

| Document | Section pertinente | Usage dans ce doc |
|----------|-------------------|------------------|
| `00_Modele_8_couches_v3.md` | §2 (Anatomie), §5 (Symbiose) | Architecture C3-C4-C5-C6 |
| `00_Nomenclature_v3.md` | §1.2 (Portabilité), §4 (Réseau) | Principes adjacency, DNS |
| `00_Glossaire_v3.md` | Famille B (Technique), Famille C (Valeurs) | Terminologie |
| `02_Reglement_v3.md` | §IV (Processus décisionnels) | Exceptions, dérogations |
| `03_Cadre_Conformite_v3.md` | §2.4 (Interopérabilité) | Critères Label |
| `Carte_Equivalence_Standards.md` | §3 (Matrice d'équivalence) | Standards externes |

---

## 📜 ΔLog — Création v1.0 (26-10-2025)

- Création du document selon plan TODO.md §Document 6
- Alignement strict avec documents 00_* (Modèle, Nomenclature, Glossaire)
- Intégration principe adjacent-only pour tous les flux
- Respect séparation fédéré/tenant (observabilité scindée)
- Références croisées avec Règlement v3 et Cadre Conformité v3
- Checklist d'auto-évaluation pour Label

---

## 🌌 Signature Boréale

> *Un protocole ouvert est une promesse tenue.*  
> *Un standard mature est un pont entre générations.*  
> *L'interopérabilité n'est pas une option — c'est notre liberté collective.*

---

**Fin du document**