diff --git a/docs/opération/06_Standards_Interoperabilite_Technique_v1.md b/docs/opération/06_Standards_Interoperabilite_Technique_v1.md
new file mode 100644
index 0000000..efd33ef
--- /dev/null
+++ b/docs/opération/06_Standards_Interoperabilite_Technique_v1.md
@@ -0,0 +1,399 @@
+# 📄 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**