alliance-boreale/docs/opération/06_Standards_Interoperabilite_Technique_v1.md

📄 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) :

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

; 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) :

# 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

□ 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