# Document 5 : Architecture de Référence & Standards Techniques
## L'Alliance Boréale — Couches 1 à 4

**Version:** 1.0  
**Date:** 23 octobre 2025  
**Statut:** Document opérationnel  
**Adopté par :** Cercle Opérationnel  
**Licence:** CC BY-SA 4.0

---

## PRÉAMBULE

L'interopérabilité ne se décrète pas. Elle se construit sur des **standards partagés** et des **conventions claires**.

**Ce document établit les règles techniques pour les couches 1 à 4** de l'architecture boréale :
- Couche 1 : Physique (serveurs, réseau)
- Couche 2 : Réseau (DNS, connectivité)
- Couche 3 : Stockage (volumes, backups)
- Couche 4 : Orchestration (IaC, automatisation)

**Principe fondamental : Nomenclature mnémotechnique**

> *"Un nom doit se comprendre sans documentation. Si tu dois chercher dans un wiki pour savoir ce que signifie `srv-xz42-prod`, le nom est mauvais."*

**Nos conventions suivent trois règles d'or :**

1. **Clarté > Concision**  
   Préférer `mail-prod-01` à `mp1` (3 caractères économisés ne valent pas la confusion).

2. **Patterns répétés**  
   Si un pattern fonctionne pour le membre A, il doit fonctionner pour le membre B (prédictibilité).

3. **Lecture par humains ET machines**  
   Les noms doivent être parsables automatiquement SANS sacrifier la lisibilité humaine.

**Ce document est vivant.** Il évoluera avec nos apprentissages. Toute proposition d'amélioration est bienvenue (pull request sur Registraire).

---

## SECTION 1 : CONVENTIONS DE NOMENCLATURE

### 1.1 Membres — Identifiants et Slugs

Chaque membre possède **deux identifiants** :

#### ID Numérique (Machine-Readable)

**Format :** `mXXX` où XXX est un entier séquentiel sur 3 chiffres.

**Exemples :**
- `m001` : Premier membre (fondateur)
- `m002` : Deuxième membre
- `m042` : Quarante-deuxième membre

**Usage :**
- Clé primaire dans Registraire YAML
- Références internes (décisions, audits)
- URLs de vérification (`registraire.alliance-boreale.ca/membres/m001`)

**Avantages :**
- Unique
- Court
- Facile à parser
- Ordre d'arrivée visible

**Inconvénients :**
- Pas mnémotechnique (on ne sait pas qui est m042 sans chercher)

---

#### Slug Textuel (Human-Readable)

**Format :** `[a-z0-9-]{3,20}` (minuscules, chiffres, tirets, 3-20 caractères)

**Exemples :**
- `chezlepro` (Chez le Pro)
- `technolibre` (TechnoLibre)
- `coop-nordique` (Coopérative Nordique)
- `hebergement-ethique` (Hébergement Éthique Inc.)

**Règles :**
- Pas d'accents (compatibilité DNS/URLs)
- Pas d'espaces (remplacés par tirets)
- Pas de caractères spéciaux (@, %, &, etc.)
- Unique dans L'Alliance (vérification lors de l'admission)

**Usage :**
- Sous-domaines DNS (`chezlepro.boreal.ca`)
- Communication informelle (Matrix, email)
- URLs publiques (`chezlepro.ca`)

**Avantages :**
- Mnémotechnique (on sait immédiatement de qui on parle)
- Identité de marque préservée
- SEO-friendly

---

#### Mapping ID ↔ Slug

**Fichier de référence :** `registraire/membres/[ID]-[slug].yml`

**Exemple :**
```yaml
# Fichier : registraire/membres/m001-chezlepro.yml
member_id: m001
slug: chezlepro
legal_name: "Chez le Pro Technologies Inc."
...
```

**Convention de nommage du fichier :**  
Toujours `[ID]-[slug].yml` pour lier visuellement les deux identifiants.

---

### 1.2 Domaines — Architecture DNS Fédérée

#### Domaine Racine de la Fédération

**Décision stratégique requise (à valider par Cercle Stratégique) :**

**Option A : `boreal.ca`**
- Court, mémorable
- Identité forte (référence directe au nom de l'Alliance)
- Disponibilité à vérifier

**Option B : `alliance-boreale.ca`**
- Explicite (aucune ambiguïté)
- Plus long (impact sur sous-domaines)
- Probablement disponible

**Option C : `.coop` ou autre TLD**
- Signal identitaire (mouvement coopératif)
- TLD `.coop` = réservé aux coopératives (pas applicable aux OBNL)

**Recommandation temporaire (ce document) :**  
Utiliser `boreal.ca` dans les exemples, mais décision finale à valider avant déploiement.

---

#### Structure des Sous-domaines

**Hiérarchie standard :**

```
boreal.ca (racine fédérée)
│
├── membre.[slug].boreal.ca     → Zone déléguée au membre
│   ├── mail.[slug].boreal.ca   → Service email
│   ├── cloud.[slug].boreal.ca  → Nextcloud/stockage
│   ├── matrix.[slug].boreal.ca → Serveur Matrix
│   ├── status.[slug].boreal.ca → Page de statut
│   └── www.[slug].boreal.ca    → Site web (optionnel)
│
├── outils.boreal.ca            → Outils communs L'Alliance
│   ├── registraire.boreal.ca   → Registraire public
│   ├── forge.boreal.ca         → Forge logicielle
│   ├── wiki.boreal.ca          → Documentation
│   └── matrix.boreal.ca        → Matrix fédéral
│
└── ns[1-3].boreal.ca           → Serveurs DNS autoritaires
    ├── ns1.boreal.ca           → Serveur primaire (membre fondateur)
    ├── ns2.boreal.ca           → Serveur secondaire (autre membre)
    └── ns3.boreal.ca           → Serveur tertiaire (optionnel)
```

---

#### Exemple Concret : Membre "Chez le Pro" (m001 / chezlepro)

**Domaine délégué :** `chezlepro.boreal.ca`

**Services standards :**
```
mail.chezlepro.boreal.ca         → Postfix/Dovecot
cloud.chezlepro.boreal.ca        → Nextcloud
matrix.chezlepro.boreal.ca       → Synapse
status.chezlepro.boreal.ca       → Upptime/Cachet
www.chezlepro.boreal.ca          → Site vitrine
```

**Serveurs DNS (internes) :**
```
ns1.chezlepro.boreal.ca          → Serveur DNS primaire du membre
ns2.chezlepro.boreal.ca          → Serveur DNS secondaire (si redondance)
```

**Zone DNS déléguée (fichier) :**  
`registraire/dns/zones/chezlepro.boreal.ca.zone`

---

#### Services Réservés (Tous les Membres)

**Ces sous-domaines DOIVENT suivre la convention :**

| Service | Sous-domaine | Protocole | Port | Obligatoire ? |
|---------|--------------|-----------|------|---------------|
| Email (SMTP) | `mail.[slug].boreal.ca` | SMTP/S | 25, 587 | ✅ Oui |
| Email (IMAP) | `mail.[slug].boreal.ca` | IMAP/S | 143, 993 | ✅ Oui |
| Webmail | `webmail.[slug].boreal.ca` | HTTPS | 443 | ⚠️ Recommandé |
| Stockage cloud | `cloud.[slug].boreal.ca` | HTTPS | 443 | ⚠️ Recommandé |
| Calendrier/Contacts | `dav.[slug].boreal.ca` | HTTPS | 443 | ⚠️ Recommandé |
| Messagerie Matrix | `matrix.[slug].boreal.ca` | HTTPS | 8448 | ⚠️ Recommandé |
| Status page | `status.[slug].boreal.ca` | HTTPS | 443 | ✅ Oui |
| Monitoring (Prometheus) | `prometheus.[slug].boreal.ca` | HTTPS | 443 | ⚠️ Recommandé |
| Monitoring (Grafana) | `grafana.[slug].boreal.ca` | HTTPS | 443 | ⚠️ Recommandé |

**Flexibilité autorisée :**  
Si un membre utilise un service équivalent sous un autre nom (ex: `files` au lieu de `cloud`), c'est acceptable, mais la convention doit être documentée dans la fiche membre.

---

#### Anti-Patterns (À Éviter)

❌ **Sous-domaines opaques :**
- `srv1.boreal.ca` (quel service ?)
- `app.boreal.ca` (quelle application ?)
- `prod.boreal.ca` (trop vague)

❌ **Hiérarchie trop profonde :**
- `mail.services.production.chezlepro.boreal.ca` (6 niveaux = trop)

❌ **Mélange ID et slug :**
- `mail.m001.boreal.ca` (incohérent, choisir ID OU slug)

---

### 1.3 Infrastructure — Serveurs, VMs, Conteneurs

#### Serveurs Physiques

**Format :** `srv-[rôle]-[numero].[slug].internal`

**Exemples :**
```
srv-compute-01.chezlepro.internal   → Serveur de calcul (hyperviseur)
srv-compute-02.chezlepro.internal   → Deuxième serveur de calcul
srv-storage-01.chezlepro.internal   → Serveur de stockage (NAS/SAN)
srv-network-01.chezlepro.internal   → Routeur/firewall
```

**Rôles standards :**
- `compute` : Hyperviseur (Proxmox, OpenStack, ESXi)
- `storage` : Stockage (NAS, SAN, Ceph)
- `network` : Infrastructure réseau (routeur, firewall, load balancer)
- `backup` : Serveur de backups dédié
- `monitoring` : Serveur monitoring/logging dédié

**Numérotation :**  
Séquentielle par rôle (compute-01, compute-02, etc.)

**Domaine `.internal` :**  
Réservé à l'infrastructure interne (non exposée publiquement).

---

#### Machines Virtuelles (VMs)

**Format :** `vm-[service]-[techno]-[numero].[slug].internal`

**Exemples :**
```
vm-web-nginx-01.chezlepro.internal      → VM web avec Nginx
vm-web-nginx-02.chezlepro.internal      → Deuxième VM web (load balancing)
vm-db-postgres-01.chezlepro.internal    → Base de données PostgreSQL
vm-db-postgres-02.chezlepro.internal    → Réplica PostgreSQL
vm-mail-postfix-01.chezlepro.internal   → Serveur mail Postfix/Dovecot
vm-cloud-nextcloud-01.chezlepro.internal → Nextcloud
```

**Pattern :**
- `vm-` : Préfixe (identifie type ressource)
- `[service]` : web, db, mail, cloud, matrix, backup, monitoring
- `[techno]` : nginx, apache, postgres, mysql, postfix, nextcloud, etc.
- `[numero]` : Séquentiel (01, 02, 03...)

**Avantages :**
- On sait immédiatement ce que fait la VM
- On sait quelle techno est utilisée (utile pour troubleshooting)
- On sait s'il y a redondance (02, 03...)

---

#### Conteneurs (Docker, LXC, Kubernetes)

**Format :** `ct-[service]-[techno]-[numero].[slug].internal`

**Exemples :**
```
ct-web-nginx-01.chezlepro.internal      → Conteneur web Nginx
ct-api-nodejs-01.chezlepro.internal     → API Node.js
ct-cache-redis-01.chezlepro.internal    → Cache Redis
ct-queue-rabbitmq-01.chezlepro.internal → File d'attente RabbitMQ
```

**Distinction VM vs Conteneur :**
- `vm-` : Machine virtuelle complète (kernel propre)
- `ct-` : Conteneur (partage kernel avec l'hôte)

**Kubernetes :**  
Si utilisation de Kubernetes, convention adaptée :
```
k8s-[namespace]-[pod]-[replica].[slug].internal
k8s-prod-web-nginx-01.chezlepro.internal
k8s-prod-api-nodejs-01.chezlepro.internal
```

---

#### DNS Interne (Zone `.internal`)

**Serveur DNS interne :**  
Chaque membre DEVRAIT opérer un DNS interne pour résolution locale (dnsmasq, Bind9, Unbound).

**Zone recommandée :** `[slug].internal`

**Exemple de zone pour Chez le Pro :**
```
chezlepro.internal. SOA ns1.chezlepro.internal. admin.chezlepro.ca. (...)

; Serveurs physiques
srv-compute-01.chezlepro.internal.  A  10.0.1.10
srv-storage-01.chezlepro.internal.  A  10.0.1.20

; Machines virtuelles
vm-web-nginx-01.chezlepro.internal. A  10.0.2.10
vm-db-postgres-01.chezlepro.internal. A  10.0.2.20

; Conteneurs
ct-cache-redis-01.chezlepro.internal. A  10.0.3.10
```

**Isolation :**  
La zone `.internal` n'est PAS déléguée à la fédération. Elle reste privée au membre.

---

### 1.4 Stockage — Volumes, Backups, Archives

#### Volumes de Stockage

**Format LVM :** `vg-[rôle]/lv-[service]-[numero]`

**Exemples :**
```
vg-data/lv-postgres-01   → Volume logique pour PostgreSQL
vg-data/lv-nextcloud-01  → Volume logique pour Nextcloud
vg-backup/lv-daily-01    → Volume logique pour backups quotidiens
```

**Format ZFS :** `pool-[rôle]/dataset-[service]`

**Exemples :**
```
pool-data/vm-web-nginx-01     → Dataset ZFS pour VM web
pool-data/vm-db-postgres-01   → Dataset ZFS pour VM base de données
pool-backup/snapshots         → Dataset pour snapshots ZFS
```

---

#### Backups — Fichiers d'Archive

**Format :** `backup-[frequence]-[slug]-[service]-[YYYYMMDD]-[HHMMSS].tar.gz.gpg`

**Exemples :**
```
backup-daily-chezlepro-postgres-20251023-020000.tar.gz.gpg
backup-weekly-chezlepro-nextcloud-20251020-030000.tar.gz.gpg
backup-monthly-chezlepro-full-20251001-040000.tar.gz.gpg
```

**Éléments :**
- `frequence` : daily, weekly, monthly
- `slug` : Identifiant du membre
- `service` : Service sauvegardé (postgres, nextcloud, mail, full)
- `YYYYMMDD` : Date (format ISO 8601, triable)
- `HHMMSS` : Heure (optionnel mais recommandé pour multiples backups/jour)
- `.tar.gz.gpg` : Compression + chiffrement (GPG)

**Avantages :**
- Tri alphabétique = tri chronologique
- On sait immédiatement : quoi, quand, par qui
- Parsing facile pour scripts de rétention

---

#### Rétention et Rotation

**Politique recommandée (modèle 3-2-1) :**

| Fréquence | Rétention | Copies | Localisation |
|-----------|-----------|--------|--------------|
| Quotidien | 7 jours | 2 | Local + Pair |
| Hebdomadaire | 4 semaines | 2 | Local + Pair |
| Mensuel | 12 mois | 3 | Local + Pair + Cloud |

**Rotation automatisée :**  
Script ou outil (restic, borg, rsnapshot) selon préférence du membre.

**Nommage des destinations :**
```
/backup/local/daily/
/backup/local/weekly/
/backup/local/monthly/
/backup/remote/pair-m002/   → Backup chez un pair (membre m002)
/backup/remote/offsite/     → Backup hors-site (cloud éthique)
```

---

### 1.5 Secrets & Credentials

#### Ansible Vault — Variables Chiffrées

**Format :** `vault_[slug]_[service]_[credential_type]`

**Exemples :**
```yaml
vault_chezlepro_db_postgres_password: "!vault |..."
vault_chezlepro_api_matrix_token: "!vault |..."
vault_chezlepro_backup_gpg_passphrase: "!vault |..."
vault_chezlepro_ssl_privkey_password: "!vault |..."
```

**Pattern :**
- Préfixe `vault_` (obligatoire, Ansible)
- `[slug]` : Identifiant membre
- `[service]` : Service concerné (db, api, backup, ssl)
- `[credential_type]` : password, token, passphrase, key, secret

**Fichier de stockage :**  
`ansible/inventories/[slug]/group_vars/all/vault.yml`

**Chiffrement :**  
`ansible-vault encrypt vault.yml`

---

#### Secrets Kubernetes (si applicable)

**Format :** `secret-[namespace]-[service]-[type]`

**Exemples :**
```
secret-prod-postgres-credentials
secret-prod-matrix-api-token
secret-staging-nextcloud-admin-password
```

**Gestion :**  
Sealed Secrets, External Secrets Operator, ou Vault (HashiCorp).

---

#### Certificats SSL/TLS

**Format :** `cert-[slug]-[type]-[YYYYMMDD].[extension]`

**Exemples :**
```
cert-chezlepro-wildcard-20251023.pem     → Certificat wildcard
cert-chezlepro-wildcard-20251023.key     → Clé privée
cert-chezlepro-mail-20251023.pem         → Certificat service mail
cert-chezlepro-matrix-20251023.pem       → Certificat service Matrix
```

**Types :**
- `wildcard` : Certificat wildcard (`*.chezlepro.boreal.ca`)
- `[service]` : Certificat spécifique à un service (mail, matrix, cloud)

**Renouvellement :**  
Let's Encrypt renouvelle tous les 90 jours. Le timestamp dans le nom aide à tracer les versions.

**Stockage :**
```
/etc/ssl/certs/alliance/cert-chezlepro-wildcard-20251023.pem
/etc/ssl/private/alliance/cert-chezlepro-wildcard-20251023.key (chmod 600)
```

---

### 1.6 Récapitulatif des Conventions

| Objet | Format | Exemple |
|-------|--------|---------|
| **Membre ID** | `mXXX` | `m001` |
| **Membre Slug** | `[a-z0-9-]{3,20}` | `chezlepro` |
| **Domaine public** | `[service].[slug].boreal.ca` | `mail.chezlepro.boreal.ca` |
| **Domaine interne** | `[type]-[service]-[num].[slug].internal` | `vm-web-nginx-01.chezlepro.internal` |
| **Serveur physique** | `srv-[role]-[num].[slug].internal` | `srv-compute-01.chezlepro.internal` |
| **VM** | `vm-[service]-[tech]-[num].[slug].internal` | `vm-db-postgres-01.chezlepro.internal` |
| **Conteneur** | `ct-[service]-[tech]-[num].[slug].internal` | `ct-cache-redis-01.chezlepro.internal` |
| **Volume LVM** | `vg-[role]/lv-[service]-[num]` | `vg-data/lv-postgres-01` |
| **Backup** | `backup-[freq]-[slug]-[service]-[YYYYMMDD].tar.gz.gpg` | `backup-daily-chezlepro-postgres-20251023.tar.gz.gpg` |
| **Secret Ansible** | `vault_[slug]_[service]_[type]` | `vault_chezlepro_db_password` |
| **Certificat SSL** | `cert-[slug]-[type]-[YYYYMMDD].pem` | `cert-chezlepro-wildcard-20251023.pem` |

---

## SECTION 2 : ARCHITECTURE RÉSEAU FÉDÉRÉE

### 2.1 Topologie de Référence

#### Vue d'Ensemble

```
                    ┌─────────────────────────────────────┐
                    │   Internet Public                   │
                    └──────────┬──────────────────────────┘
                               │
          ┌────────────────────┼────────────────────┐
          │                    │                    │
   ┌──────▼──────┐      ┌──────▼──────┐     ┌──────▼──────┐
   │  Membre A   │      │  Membre B   │     │  Membre C   │
   │  (m001)     │      │  (m002)     │     │  (m003)     │
   └─────────────┘      └─────────────┘     └─────────────┘
          │                    │                    │
          │   VPN maillé (optionnel, si besoin)    │
          └────────────────────┼────────────────────┘
                               │
                    ┌──────────▼─────────────┐
                    │  DNS Fédéré (AXFR)     │
                    │  ns1, ns2, ns3         │
                    └────────────────────────┘
```

**Principes :**
1. **Autonomie locale** : Chaque membre opère son infrastructure indépendamment
2. **Interconnexion par standards ouverts** : DNS (AXFR), SMTP, Matrix, etc.
3. **VPN optionnel** : Uniquement si besoin (administration mutuelle, backups croisés)
4. **Pas de point central** : Pas de serveur "maître" contrôlant tout

---

### 2.2 Plages IP et Adressage

#### IP Publiques

**Recommandation :** Chaque membre conserve ses propres IP publiques (hébergeur, ISP).

**Pas d'allocation centrale.** L'Alliance ne fournit pas d'IPs publiques.

**BGP Peering (Optionnel, Avancé) :**  
Si plusieurs membres ont des AS (Autonomous Systems), peering BGP possible pour optimiser routes. Non requis pour phase pilote.

---

#### IP Privées (RFC 1918)

**Recommandation par membre :**

**Plage recommandée :** `10.[ID].[0-255].[0-255]/16`

**Exemples :**
- Membre m001 : `10.1.0.0/16`
- Membre m002 : `10.2.0.0/16`
- Membre m003 : `10.3.0.0/16`

**Découpage suggéré :**
```
10.1.0.0/24    → Gestion (switches, IPMI, ILO)
10.1.1.0/24    → Serveurs physiques
10.1.2.0/24    → VMs production
10.1.3.0/24    → VMs staging
10.1.4.0/24    → Conteneurs
10.1.10.0/24   → VPN (interconnexion)
10.1.100.0/24  → Réseau invités (si applicable)
```

**Avantages :**
- Pas de collision entre membres (ID unique)
- Lisibilité (10.1.x.x = m001, 10.2.x.x = m002)
- Scalabilité (65k IPs par membre)

---

### 2.3 Pare-feu — Ports Standards Ouverts

#### Ports Obligatoires (Services Publics)

| Service | Port(s) | Protocole | Commentaire |
|---------|---------|-----------|-------------|
| **HTTP** | 80 | TCP | Redirection vers HTTPS |
| **HTTPS** | 443 | TCP | Tous les services web |
| **SMTP** | 25 | TCP | Réception email (MX) |
| **Submission** | 587 | TCP | Envoi email (STARTTLS) |
| **IMAPS** | 993 | TCP | Lecture email (SSL/TLS) |
| **DNS** | 53 | TCP/UDP | DNS autoritaire public |
| **Matrix Federation** | 8448 | TCP | Fédération Matrix (si applicable) |

#### Ports Recommandés (Services Optionnels)

| Service | Port(s) | Protocole | Commentaire |
|---------|---------|-----------|-------------|
| **SSH** | 22 ou custom | TCP | Admin (filtré par IP si possible) |
| **SMTP/S** | 465 | TCP | Envoi email SSL/TLS legacy |
| **POP3S** | 995 | TCP | Si POP3 supporté |
| **CalDAV/WebDAV** | 443 | TCP | Via HTTPS (port standard) |
| **XMPP** | 5222, 5269 | TCP | Si XMPP utilisé |

#### Ports VPN (Si Interconnexion)

| VPN | Port(s) | Protocole | Commentaire |
|-----|---------|-----------|-------------|
| **WireGuard** | 51820 (défaut) | UDP | Recommandé (moderne, performant) |
| **OpenVPN** | 1194 (défaut) | UDP/TCP | Alternative |
| **IPsec** | 500, 4500 | UDP | Si besoin (complexe) |

---

### 2.4 VPN Site-à-Site (Optionnel)

**Cas d'usage :**
- Backups croisés entre membres
- Monitoring mutuel (accès Prometheus/Grafana)
- Administration mutualisée (support technique)

**Technologie recommandée : WireGuard**

**Avantages :**
- Simple à configurer
- Performant (kernel-space)
- Sécurisé (cryptographie moderne)
- Multi-plateformes

**Topologie recommandée : Maillée (Full-Mesh)**

**Exemple 3 membres :**
```
m001 ↔ m002
m001 ↔ m003
m002 ↔ m003
```

**Configuration WireGuard (Exemple m001 → m002) :**

**Sur m001 :**
```ini
[Interface]
PrivateKey = <clé_privée_m001>
Address = 10.100.1.1/32
ListenPort = 51820

[Peer]
# m002
PublicKey = <clé_publique_m002>
AllowedIPs = 10.100.2.1/32, 10.2.0.0/16
Endpoint = m002.example.com:51820
PersistentKeepalive = 25
```

**Sur m002 :**
```ini
[Interface]
PrivateKey = <clé_privée_m002>
Address = 10.100.2.1/32
ListenPort = 51820

[Peer]
# m001
PublicKey = <clé_publique_m001>
AllowedIPs = 10.100.1.1/32, 10.1.0.0/16
Endpoint = m001.example.com:51820
PersistentKeepalive = 25
```

**Plage VPN : `10.100.0.0/16`**
- m001 : `10.100.1.1/32`
- m002 : `10.100.2.1/32`
- m003 : `10.100.3.1/32`

**Routes autorisées :**  
Chaque membre expose son réseau interne (`10.[ID].0.0/16`) via le VPN.

---

## SECTION 3 : DNS FÉDÉRÉ

### 3.1 Architecture DNS

#### Serveurs DNS Autoritaires

**Minimum requis : 2 serveurs DNS**  
Un serveur primaire + un ou plusieurs secondaires (redondance).

**Recommandation : 3 serveurs répartis chez différents membres**

**Exemple :**
```
ns1.boreal.ca  → Hébergé chez m001 (Chez le Pro)
ns2.boreal.ca  → Hébergé chez m002 (TechnoLibre)
ns3.boreal.ca  → Hébergé chez m003 (Coop Nordique)
```

**Enregistrements NS (au registrar) :**
```
boreal.ca.  NS  ns1.boreal.ca.
boreal.ca.  NS  ns2.boreal.ca.
boreal.ca.  NS  ns3.boreal.ca.

ns1.boreal.ca.  A  <IP_publique_m001>
ns2.boreal.ca.  A  <IP_publique_m002>
ns3.boreal.ca.  A  <IP_publique_m003>
```

---

#### Zone Parente (boreal.ca)

**Gestion :** Cercle Opérationnel (rotation des responsabilités).

**Contenu minimal :**
```
$ORIGIN boreal.ca.
$TTL 3600

@  SOA  ns1.boreal.ca. admin.alliance-boreale.ca. (
    2025102301  ; Serial (YYYYMMDDNN)
    3600        ; Refresh
    1800        ; Retry
    1209600     ; Expire (2 semaines)
    3600        ; Minimum TTL
)

; Serveurs DNS autoritaires
@  NS  ns1.boreal.ca.
@  NS  ns2.boreal.ca.
@  NS  ns3.boreal.ca.

ns1  A  <IP_m001>
ns2  A  <IP_m002>
ns3  A  <IP_m003>

; Outils communs L'Alliance
registraire  A  <IP_tool_server>
forge        A  <IP_tool_server>
wiki         A  <IP_tool_server>
matrix       A  <IP_tool_server>

; Délégation zones membres
; (voir Section 3.2)
```

---

### 3.2 Délégation de Zones aux Membres

**Principe :**  
Chaque membre reçoit une zone DNS déléguée (`[slug].boreal.ca`) qu'il gère de manière autonome.

**Processus de délégation :**

1. **Membre configure ses serveurs DNS**
   - Serveurs autoritaires pour sa zone (ns1/ns2.[slug].boreal.ca)
   - Zone `[slug].boreal.ca` avec enregistrements de services

2. **Membre communique IPs de ses NS au Cercle Opérationnel**
   - ns1.chezlepro.boreal.ca → 203.0.113.10
   - ns2.chezlepro.boreal.ca → 203.0.113.11

3. **Cercle Opérationnel ajoute délégation dans zone parente**

**Exemple de délégation (dans zone boreal.ca) :**
```
; Membre m001 (Chez le Pro)
chezlepro         NS  ns1.chezlepro.boreal.ca.
chezlepro         NS  ns2.chezlepro.boreal.ca.
ns1.chezlepro     A   203.0.113.10
ns2.chezlepro     A   203.0.113.11

; Membre m002 (TechnoLibre)
technolibre       NS  ns1.technolibre.boreal.ca.
technolibre       NS  ns2.technolibre.boreal.ca.
ns1.technolibre   A   198.51.100.20
ns2.technolibre   A   198.51.100.21
```

**Résultat :**  
Le membre contrôle totalement sa zone. Il peut ajouter/modifier/supprimer enregistrements sans intervention de L'Alliance.

---

### 3.3 Réplication AXFR entre Pairs

**AXFR = Zone Transfer (RFC 5936)**

**Objectif :** Permettre la réplication complète d'une zone DNS entre serveurs primaire et secondaires.

**Configuration (Bind9 exemple) :**

**Serveur primaire (m001 - ns1.chezlepro.boreal.ca) :**
```
zone "chezlepro.boreal.ca" {
    type master;
    file "/etc/bind/zones/chezlepro.boreal.ca.zone";
    allow-transfer { 203.0.113.11; };  // ns2.chezlepro
    notify yes;
};
```

**Serveur secondaire (ns2.chezlepro.boreal.ca) :**
```
zone "chezlepro.boreal.ca" {
    type slave;
    file "/var/cache/bind/chezlepro.boreal.ca.zone";
    masters { 203.0.113.10; };  // ns1.chezlepro
};
```

**Sécurisation :**
- Restreindre `allow-transfer` aux IPs des secondaires
- Utiliser TSIG (Transaction Signature) pour authentification

**TSIG (Exemple) :**
```
key "chezlepro-axfr-key" {
    algorithm hmac-sha256;
    secret "base64EncodedSecretKey==";
};

zone "chezlepro.boreal.ca" {
    type master;
    file "/etc/bind/zones/chezlepro.boreal.ca.zone";
    allow-transfer { key chezlepro-axfr-key; };
};
```

---

### 3.4 DNSSEC (Recommandé)

**DNSSEC = DNS Security Extensions**

**Objectif :** Authentifier les réponses DNS (prévenir spoofing, cache poisoning).

**Processus :**

1. **Génération de clés (ZSK + KSK)**
   ```bash
   dnssec-keygen -a RSASHA256 -b 2048 -n ZONE chezlepro.boreal.ca  # ZSK
   dnssec-keygen -a RSASHA256 -b 4096 -n ZONE -f KSK chezlepro.boreal.ca  # KSK
   ```

2. **Signature de la zone**
   ```bash
   dnssec-signzone -o chezlepro.boreal.ca chezlepro.boreal.ca.zone
   ```

3. **Publication DS record chez parent (boreal.ca)**
   ```
   chezlepro  DS  12345 8 2 <hash>
   ```

4. **Automatisation du renouvellement**
   - Les clés DNSSEC expirent (30-90 jours typiquement)
   - Script cron pour re-signer automatiquement

**Complexité :**  
DNSSEC ajoute de la complexité opérationnelle. Recommandé pour niveau label Or/Platine, optionnel pour Bronze/Argent.

---

### 3.5 Monitoring DNS

**Vérifications essentielles :**

1. **Résolution publique**
   ```bash
   dig @8.8.8.8 mail.chezlepro.boreal.ca
   dig @1.1.1.1 chezlepro.boreal.ca NS
   ```

2. **Réplication AXFR**
   ```bash
   dig @ns2.chezlepro.boreal.ca chezlepro.boreal.ca AXFR
   ```

3. **DNSSEC (si activé)**
   ```bash
   dig +dnssec chezlepro.boreal.ca
   ```

4. **Santé des NS**
   ```bash
   dig +trace chezlepro.boreal.ca
   ```

**Outils recommandés :**
- DNSViz (visualisation DNSSEC)
- Zonemaster (analyse qualité DNS)
- Nagios/Icinga checks DNS

---

## SECTION 4 : STANDARDS DE STOCKAGE

### 4.1 Systèmes de Fichiers Recommandés

**Pour VMs et conteneurs :**

| Use Case | Recommandation | Rationale |
|----------|----------------|-----------|
| **VM disks** | LVM + ext4 | Simplicité, maturité |
| **VM disks (avancé)** | ZFS | Snapshots, compression, checksums |
| **Conteneurs** | Overlay2 (Docker) | Standard Docker |
| **NAS/SAN** | ZFS ou Ceph | Résilience, scalabilité |
| **Backups** | Ext4 ou XFS | Performance séquentielle |

**ZFS avantages :**
- Snapshots instantanés
- Compression (LZ4, ZSTD)
- Checksums (détection corruption)
- Réplication (zfs send/recv)

**ZFS inconvénients :**
- Consommation RAM (1 GB RAM / 1 TB stockage recommandé)
- Complexité configuration

**LVM avantages :**
- Simple
- Flexible (resize volumes)
- Standard Linux

---

### 4.2 Chiffrement au Repos

**Obligatoire pour :**
- Backups (GPG, borg, restic)
- Bases de données contenant données personnelles
- Volumes contenant secrets (clés, tokens)

**Technologies recommandées :**

| Couche | Technologie | Usage |
|--------|-------------|-------|
| **Disque complet** | LUKS (dm-crypt) | Chiffrement bloc entier |
| **Système de fichiers** | eCryptfs, ZFS native encryption | Chiffrement par fichier/dataset |
| **Application** | GPG, age, borg, restic | Chiffrement archives |

**Exemple LUKS :**
```bash
cryptsetup luksFormat /dev/sdb1
cryptsetup open /dev/sdb1 cryptvol
mkfs.ext4 /dev/mapper/cryptvol
```

**Gestion des clés :**
- Clés stockées dans Ansible Vault (chiffrées)
- Ou TPM 2.0 (Trusted Platform Module) si disponible
- Ou HSM (Hardware Security Module) pour haute sécurité

---

### 4.3 Backups — Stratégie 3-2-1

**Règle 3-2-1 :**
- **3** copies des données (originale + 2 backups)
- **2** supports différents (ex: disque local + NAS distant)
- **1** copie hors-site (géographiquement séparée)

**Application dans L'Alliance :**

| Copie | Localisation | Technologie | Fréquence |
|-------|--------------|-------------|-----------|
| **1. Production** | Serveur local | VM/conteneur | Temps réel |
| **2. Backup local** | NAS local ou autre serveur | rsync, borg, restic | Quotidien |
| **3. Backup pair** | Chez un autre membre (VPN) | rsync, borg + chiffrement | Quotidien |
| **4. Backup offsite** | Cloud éthique (ex: Wasabi, Backblaze B2) | rclone, restic | Hebdomadaire |

**Outils recommandés :**

**Borg Backup :**
- Déduplication (économie espace)
- Compression (LZ4, ZSTD)
- Chiffrement (AES-256)
- Snapshots incrémentaux

**Restic :**
- Similaire à Borg
- Multi-backend (local, SFTP, S3, B2, etc.)
- Vérification d'intégrité intégrée

**Exemple Borg :**
```bash
# Initialisation repo
borg init --encryption=repokey /backup/local/borg

# Backup quotidien
borg create /backup/local/borg::daily-{now} /data \
    --compression lz4 \
    --exclude /data/cache

# Pruning (rétention)
borg prune /backup/local/borg \
    --keep-daily=7 \
    --keep-weekly=4 \
    --keep-monthly=12
```

---

### 4.4 Tests de Restauration (Obligatoire)

**Règle d'or :** Un backup non testé est un backup inexistant.

**Fréquence minimale :** Trimestrielle (tous les 3 mois).

**Procédure :**
1. Sélectionner un backup aléatoire (ex: backup mensuel du mois dernier)
2. Restaurer dans environnement isolé (VM de test)
3. Vérifier intégrité (checksums, démarrage services)
4. Documenter résultat (runbook ou wiki)

**Critères de succès :**
- Restauration complète en < [RTO] (ex: 4h)
- Données intègres (aucune corruption)
- Services redémarrables

**Documentation obligatoire :**  
`wiki/runbooks/test-restauration-YYYY-MM-DD.md`

---

## SECTION 5 : ORCHESTRATION (IaC)

### 5.1 Ansible — Structure Recommandée

**Ansible = Infrastructure as Code pour L'Alliance**

**Philosophie :**
- Déclaratif (décrire l'état désiré, pas les étapes)
- Idempotent (exécuter N fois = même résultat)
- Agentless (SSH uniquement, pas d'agent installé)

---

#### Structure de Répertoire Standard

```
ansible/
├── inventories/
│   ├── production/
│   │   ├── hosts.yml          # Inventaire membres prod
│   │   └── group_vars/
│   │       ├── all/
│   │       │   ├── vars.yml   # Variables publiques
│   │       │   └── vault.yml  # Variables chiffrées (Vault)
│   │       └── membres/
│   │           ├── m001.yml   # Variables spécifiques m001
│   │           └── m002.yml
│   └── staging/
│       └── hosts.yml          # Inventaire staging (si applicable)
│
├── playbooks/
│   ├── site.yml               # Playbook principal
│   ├── dns-setup.yml          # Setup DNS
│   ├── monitoring-setup.yml   # Setup monitoring
│   └── backup-setup.yml       # Setup backups
│
├── roles/
│   ├── common/                # Rôle commun (tous serveurs)
│   │   ├── tasks/
│   │   ├── handlers/
│   │   ├── templates/
│   │   └── vars/
│   ├── dns-server/            # Rôle serveur DNS
│   ├── mail-server/           # Rôle serveur mail
│   └── web-server/            # Rôle serveur web
│
├── group_vars/                # Variables par groupe
│   └── all.yml                # Variables globales
│
├── host_vars/                 # Variables par hôte
│   └── ns1.chezlepro.boreal.ca.yml
│
└── ansible.cfg                # Configuration Ansible
```

---

#### Inventaire (Exemple)

**Fichier : `inventories/production/hosts.yml`**

```yaml
all:
  children:
    alliance_members:
      children:
        membre_m001:
          hosts:
            srv-compute-01.chezlepro.internal:
              ansible_host: 203.0.113.10
            vm-web-nginx-01.chezlepro.internal:
              ansible_host: 10.1.2.10
        
        membre_m002:
          hosts:
            srv-compute-01.technolibre.internal:
              ansible_host: 198.51.100.20

    dns_servers:
      hosts:
        ns1.boreal.ca:
          ansible_host: 203.0.113.10
          member_id: m001
        ns2.boreal.ca:
          ansible_host: 198.51.100.20
          member_id: m002

    mail_servers:
      hosts:
        mail.chezlepro.boreal.ca:
          ansible_host: 10.1.2.20
        mail.technolibre.boreal.ca:
          ansible_host: 10.2.2.20
```

---

#### Variables (Exemple)

**Fichier : `group_vars/all/vars.yml`**

```yaml
# Variables publiques (non sensibles)

alliance_domain: "boreal.ca"
alliance_ns_servers:
  - ns1.boreal.ca
  - ns2.boreal.ca
  - ns3.boreal.ca

# Paramètres DNS
dns_ttl_default: 3600
dns_refresh: 3600
dns_retry: 1800
dns_expire: 1209600

# Paramètres backup
backup_retention_daily: 7
backup_retention_weekly: 4
backup_retention_monthly: 12

# Paramètres monitoring
prometheus_scrape_interval: 30s
prometheus_retention: 30d
```

**Fichier : `group_vars/all/vault.yml` (chiffré)**

```yaml
# Variables sensibles (Ansible Vault)

vault_alliance_dns_tsig_key: "base64SecretKey=="
vault_alliance_backup_gpg_passphrase: "SuperSecretPassphrase123"
vault_prometheus_admin_password: "AnotherSecretPass456"
```

**Chiffrement :**
```bash
ansible-vault encrypt group_vars/all/vault.yml
```

---

#### Playbook (Exemple)

**Fichier : `playbooks/dns-setup.yml`**

```yaml
---
- name: Setup DNS Servers
  hosts: dns_servers
  become: yes
  
  roles:
    - common
    - dns-server
  
  tasks:
    - name: Configure Bind9 zones
      template:
        src: "templates/bind/{{ item }}.zone.j2"
        dest: "/etc/bind/zones/{{ item }}.zone"
        owner: bind
        group: bind
        mode: '0644'
      loop:
        - boreal.ca
        - "{{ member_slug }}.boreal.ca"
      notify: reload bind9
    
    - name: Enable DNSSEC
      command: dnssec-signzone -o {{ item }} /etc/bind/zones/{{ item }}.zone
      loop:
        - boreal.ca
        - "{{ member_slug }}.boreal.ca"
      when: dnssec_enabled | default(false)
  
  handlers:
    - name: reload bind9
      service:
        name: bind9
        state: reloaded
```

---

### 5.2 Secrets Management

**Options recommandées :**

1. **Ansible Vault** (simple, intégré)
2. **HashiCorp Vault** (avancé, dynamique)
3. **SOPS (Mozilla)** (Git-friendly)

**Ansible Vault (recommandé pour débuter) :**

```bash
# Créer fichier chiffré
ansible-vault create secrets.yml

# Éditer fichier chiffré
ansible-vault edit secrets.yml

# Utiliser dans playbook
ansible-playbook site.yml --ask-vault-pass
# ou avec fichier de mot de passe
ansible-playbook site.yml --vault-password-file ~/.vault_pass
```

**HashiCorp Vault (pour production avancée) :**

**Avantages :**
- Secrets dynamiques (génération à la demande)
- Rotation automatique
- Audit trail complet
- APIs RESTful

**Intégration Ansible :**
```yaml
- name: Read database password from Vault
  set_fact:
    db_password: "{{ lookup('hashi_vault', 'secret=secret/data/postgres:password') }}"
```

---

### 5.3 CI/CD pour Infrastructure

**GitOps pour IaC :**  
Tout changement d'infrastructure passe par Git → Review → Déploiement automatisé.

**Workflow recommandé (GitLab CI ou GitHub Actions) :**

```yaml
# .gitlab-ci.yml (exemple)

stages:
  - validate
  - test
  - deploy

ansible-lint:
  stage: validate
  script:
    - ansible-lint playbooks/*.yml

ansible-syntax:
  stage: validate
  script:
    - ansible-playbook playbooks/site.yml --syntax-check

ansible-test-staging:
  stage: test
  script:
    - ansible-playbook -i inventories/staging playbooks/site.yml --check
  only:
    - merge_requests

ansible-deploy-production:
  stage: deploy
  script:
    - ansible-playbook -i inventories/production playbooks/site.yml
  only:
    - main
  when: manual
```

**Protection :**
- Déploiement production = manuel (éviter accidents)
- Review obligatoire (2 pairs minimum)
- Tests automatisés (lint, syntax, dry-run)

---

## SECTION 6 : CERTIFICATS SSL/TLS

### 6.1 Let's Encrypt (Recommandé)

**Let's Encrypt = CA gratuite, automatisée, ouverte**

**Avantages :**
- Gratuit
- Automatisé (renouvellement tous les 90 jours)
- Reconnu universellement (trust stores)
- Support wildcards

**Client recommandé : Certbot**

```bash
# Installation (Debian/Ubuntu)
apt install certbot python3-certbot-nginx

# Obtenir certificat (HTTP-01 challenge)
certbot --nginx -d mail.chezlepro.boreal.ca

# Obtenir wildcard (DNS-01 challenge)
certbot certonly --dns-cloudflare \
    --dns-cloudflare-credentials ~/.secrets/cloudflare.ini \
    -d '*.chezlepro.boreal.ca'
```

**Renouvellement automatique :**
```bash
# Cron (vérifie quotidiennement, renouvelle si < 30 jours)
0 3 * * * certbot renew --quiet
```

---

### 6.2 Certificat Wildcard vs Spécifique

**Wildcard (`*.chezlepro.boreal.ca`) :**

**Avantages :**
- Un seul certificat pour tous les sous-domaines
- Simplifie gestion

**Inconvénients :**
- Nécessite DNS-01 challenge (accès API DNS)
- Si compromis, tous les sous-domaines affectés

**Certificats spécifiques (`mail.chezlepro.boreal.ca`) :**

**Avantages :**
- HTTP-01 challenge (plus simple)
- Isolation (compromission limitée)

**Inconvénients :**
- Plusieurs certificats à gérer

**Recommandation :**  
Wildcard pour simplifier, SAUF si services très sensibles (séparer).

---

### 6.3 Chaîne de Confiance et Formats

**Formats de certificats :**

| Format | Extension | Usage |
|--------|-----------|-------|
| **PEM** | .pem, .crt, .cer | Standard (texte base64) |
| **DER** | .der | Binaire (rare) |
| **PKCS#12** | .p12, .pfx | Bundle (cert + clé, Windows) |

**Fichiers Let's Encrypt (après certbot) :**
```
/etc/letsencrypt/live/mail.chezlepro.boreal.ca/
├── fullchain.pem    → Certificat + chaîne complète (à utiliser)
├── cert.pem         → Certificat seul
├── chain.pem        → Chaîne intermédiaire
└── privkey.pem      → Clé privée (chmod 600 !)
```

**Configuration Nginx :**
```nginx
server {
    listen 443 ssl http2;
    server_name mail.chezlepro.boreal.ca;
    
    ssl_certificate /etc/letsencrypt/live/mail.chezlepro.boreal.ca/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mail.chezlepro.boreal.ca/privkey.pem;
    
    # Protocoles et ciphers sécurisés
    ssl_protocols TLSv1.3 TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256...';
    ssl_prefer_server_ciphers off;
    
    # HSTS
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}
```

---

### 6.4 Monitoring Expiration

**Outils recommandés :**

**1. SSL Labs (manuel)**
```
https://www.ssllabs.com/ssltest/analyze.html?d=mail.chezlepro.boreal.ca
```

**2. Nagios/Icinga check**
```bash
/usr/lib/nagios/plugins/check_http -H mail.chezlepro.boreal.ca -S -C 30
# Alerte si expiration < 30 jours
```

**3. Prometheus + Blackbox Exporter**
```yaml
- job_name: 'ssl-expiry'
  metrics_path: /probe
  params:
    module: [http_2xx]
  static_configs:
    - targets:
      - https://mail.chezlepro.boreal.ca
  relabel_configs:
    - source_labels: [__address__]
      target_label: __param_target
    - target_label: instance
      replacement: blackbox-exporter:9115
```

**Alerte Prometheus :**
```yaml
- alert: SSLCertExpiringSoon
  expr: probe_ssl_earliest_cert_expiry - time() < 30 * 24 * 3600
  annotations:
    summary: "SSL certificate expiring soon for {{ $labels.instance }}"
```

---

## SECTION 7 : MONITORING ET OBSERVABILITÉ

### 7.1 Stack Recommandée

**Prometheus + Grafana + Loki + Alertmanager**

| Composant | Rôle | Port | Stockage |
|-----------|------|------|----------|
| **Prometheus** | Métriques (time-series) | 9090 | Local ou remote (Thanos) |
| **Grafana** | Visualisation | 3000 | PostgreSQL ou SQLite |
| **Loki** | Logs (agrégation) | 3100 | S3 ou local |
| **Alertmanager** | Alertes (routing) | 9093 | Volatile (config) |
| **Node Exporter** | Métriques serveur | 9100 | N/A (agent) |
| **Blackbox Exporter** | Probes externes | 9115 | N/A (agent) |

---

### 7.2 Métriques à Exporter (Obligatoire Label)

**Pour conformité Label (Domaine 1 + 5) :**

**1. Disponibilité des services**
```
up{job="web-server", instance="vm-web-nginx-01"}
```

**2. Latence HTTP**
```
http_request_duration_seconds{handler="/", method="GET"}
```

**3. Utilisation ressources**
```
node_cpu_seconds_total
node_memory_MemAvailable_bytes
node_disk_io_time_seconds_total
```

**4. État backups**
```
backup_last_success_timestamp_seconds
backup_size_bytes
```

**5. Certificats SSL**
```
probe_ssl_earliest_cert_expiry
```

**Configuration Prometheus (scrape) :**
```yaml
scrape_configs:
  - job_name: 'node-exporter'
    static_configs:
      - targets:
        - srv-compute-01.chezlepro.internal:9100
        - vm-web-nginx-01.chezlepro.internal:9100
    relabel_configs:
      - source_labels: [__address__]
        target_label: member
        replacement: chezlepro
```

---

### 7.3 Dashboard Partagé (Optionnel)

**Concept :**  
Dashboard Grafana centralisé montrant métriques agrégées de tous les membres (avec consentement).

**Métriques partagées (anonymisées si sensible) :**
- Disponibilité globale (%)
- Incidents P0/P1 (nombre, durée)
- Consommation énergétique agrégée (kWh)

**Accès :**
- Membres actifs : lecture complète
- Public : tableau de bord synthétique (stats globales)

**URL :** `grafana.boreal.ca/d/alliance-overview`

**Implémentation :**  
Prometheus Federation ou Thanos (query multi-tenancy).

---

## SECTION 8 : CONFORMITÉ ET AUDITS

### 8.1 Checklist Infrastructure (Label Domaine 1)

**Avant demande de labellisation, vérifier :**

- [ ] DNS configuré (ns1, ns2 minimum)
- [ ] AXFR fonctionnel entre ns1 et ns2
- [ ] DNSSEC activé (recommandé pour Or/Platine)
- [ ] Certificats SSL/TLS valides (grade A SSL Labs)
- [ ] Backups automatisés quotidiens
- [ ] Test de restauration réalisé (< 6 mois)
- [ ] Monitoring actif (Prometheus + Node Exporter)
- [ ] Alerting configuré (Alertmanager ou équivalent)
- [ ] Status page publique (Upptime, Cachet, ou custom)
- [ ] Documentation architecture à jour (wiki)
- [ ] Runbooks pour procédures critiques (≥ 3)

---

### 8.2 Preuves Techniques à Fournir

**Lors de l'audit (voir Document 3) :**

**DNS :**
- Capture `dig` résolution publique
- Capture `dig AXFR` réplication
- DNSViz report (si DNSSEC)

**SSL/TLS :**
- Scan SSL Labs (grade A- minimum)
- Liste certificats avec dates expiration

**Backups :**
- Logs de backups (derniers 30 jours)
- Rapport test restauration (avec capture écran)

**Monitoring :**
- Capture Grafana dashboard disponibilité
- Métriques Prometheus (query échantillon)
- Logs Alertmanager (alertes déclenchées)

**Infrastructure :**
- Inventaire serveurs/VMs/conteneurs (CSV ou YAML)
- Diagramme architecture (Diagrams.net, Draw.io)
- Configuration IaC (playbooks Ansible, extraits)

---

## CONCLUSION

**Ce document pose les fondations techniques de la fédération.**

**Sans conventions partagées, pas d'interopérabilité.**  
**Sans standards, pas de résilience.**  
**Sans nomenclature mnémotechnique, pas de transmissibilité.**

**Ces règles ne sont pas des carcans.** Elles sont des chemins tracés dans la forêt pour faciliter la coopération. Chaque membre reste souverain sur son infrastructure, mais nous parlons le même langage.

**Les conventions évoluent.** Si une règle pose problème, proposez un amendement (pull request sur Registraire). Si un pattern fonctionne mieux, partagez-le (wiki).

**L'objectif n'est pas la perfection immédiate, c'est la cohérence progressive.**

**Bienvenue dans l'architecture boréale.** 🌲

---

## ANNEXES

### Annexe A : Templates de Fichiers

#### A.1 Zone DNS (Bind9)

**Fichier : `/etc/bind/zones/chezlepro.boreal.ca.zone`**

```
$ORIGIN chezlepro.boreal.ca.
$TTL 3600

@  SOA  ns1.chezlepro.boreal.ca. admin.chezlepro.ca. (
    2025102301  ; Serial
    3600        ; Refresh
    1800        ; Retry
    1209600     ; Expire
    3600        ; Minimum TTL
)

; Serveurs DNS
@  NS  ns1.chezlepro.boreal.ca.
@  NS  ns2.chezlepro.boreal.ca.

ns1  A  203.0.113.10
ns2  A  203.0.113.11

; Services publics
mail      A  203.0.113.20
webmail   A  203.0.113.20
cloud     A  203.0.113.30
matrix    A  203.0.113.40
status    A  203.0.113.50
www       A  203.0.113.60

; MX records
@  MX  10  mail.chezlepro.boreal.ca.

; SPF, DKIM, DMARC
@  TXT  "v=spf1 mx -all"
_dmarc  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@chezlepro.ca"
default._domainkey  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA..."
```

---

#### A.2 Configuration Ansible (ansible.cfg)

```ini
[defaults]
inventory = inventories/production/hosts.yml
roles_path = roles
host_key_checking = False
retry_files_enabled = False
gathering = smart
fact_caching = jsonfile
fact_caching_connection = /tmp/ansible_facts
fact_caching_timeout = 86400

[privilege_escalation]
become = True
become_method = sudo
become_user = root
become_ask_pass = False

[ssh_connection]
pipelining = True
control_path = /tmp/ansible-ssh-%%h-%%p-%%r
```

---

#### A.3 Playbook Backup (backup-daily.yml)

```yaml
---
- name: Daily Backup
  hosts: all
  become: yes
  
  vars:
    backup_date: "{{ ansible_date_time.iso8601_basic_short }}"
    backup_base: "/backup/local/daily"
    backup_gpg_key: "{{ vault_backup_gpg_key }}"
  
  tasks:
    - name: Create backup directory
      file:
        path: "{{ backup_base }}"
        state: directory
        mode: '0700'
    
    - name: Backup PostgreSQL databases
      shell: |
        pg_dumpall | gzip | gpg --encrypt --recipient {{ backup_gpg_key }} \
          > {{ backup_base }}/backup-daily-{{ inventory_hostname_short }}-postgres-{{ backup_date }}.sql.gz.gpg
      when: "'db_servers' in group_names"
    
    - name: Backup /etc configuration
      archive:
        path: /etc
        dest: "{{ backup_base }}/backup-daily-{{ inventory_hostname_short }}-etc-{{ backup_date }}.tar.gz"
        format: gz
    
    - name: Encrypt /etc backup
      shell: |
        gpg --encrypt --recipient {{ backup_gpg_key }} \
          {{ backup_base }}/backup-daily-{{ inventory_hostname_short }}-etc-{{ backup_date }}.tar.gz
        rm {{ backup_base }}/backup-daily-{{ inventory_hostname_short }}-etc-{{ backup_date }}.tar.gz
    
    - name: Prune old backups (keep 7 days)
      shell: |
        find {{ backup_base }} -type f -mtime +7 -delete
```

---

### Annexe B : Scripts Utilitaires

#### B.1 Vérification DNS Fédéré

**Fichier : `scripts/check-dns-federation.sh`**

```bash
#!/bin/bash
# Vérification santé DNS fédéré

DOMAIN="boreal.ca"
MEMBERS=("chezlepro" "technolibre" "coop-nordique")

echo "=== Vérification DNS Fédération Alliance Boréale ==="
echo ""

# Test résolution NS racine
echo "1. Serveurs NS racine ${DOMAIN}:"
dig +short ${DOMAIN} NS
echo ""

# Test délégation membres
for member in "${MEMBERS[@]}"; do
    echo "2. Délégation ${member}.${DOMAIN}:"
    dig +short ${member}.${DOMAIN} NS
    echo ""
    
    echo "3. Services ${member}.${DOMAIN}:"
    dig +short mail.${member}.${DOMAIN} A
    dig +short cloud.${member}.${DOMAIN} A
    echo ""
done

# Test AXFR (si autorisé)
echo "4. Test AXFR (depuis ns1):"
dig @ns1.${DOMAIN} ${DOMAIN} AXFR +short | head -10
echo ""

echo "=== Fin vérification ==="
```

---

#### B.2 Génération Certificat Let's Encrypt

**Fichier : `scripts/certbot-wildcard.sh`**

```bash
#!/bin/bash
# Obtenir certificat wildcard Let's Encrypt avec Cloudflare DNS

DOMAIN="$1"
EMAIL="admin@${DOMAIN}"
CLOUDFLARE_CREDS="/root/.secrets/cloudflare.ini"

if [ -z "$DOMAIN" ]; then
    echo "Usage: $0 <domain>"
    echo "Exemple: $0 chezlepro.boreal.ca"
    exit 1
fi

certbot certonly \
    --dns-cloudflare \
    --dns-cloudflare-credentials ${CLOUDFLARE_CREDS} \
    --email ${EMAIL} \
    --agree-tos \
    --non-interactive \
    -d "*.${DOMAIN}" \
    -d "${DOMAIN}"

echo "Certificat généré dans /etc/letsencrypt/live/${DOMAIN}/"
```

---

### Annexe C : Checklist Démarrage Membre

**Pour nouveau membre rejoignant la fédération :**

#### Phase 1 : Préparation (Semaines 1-2)

- [ ] Choisir slug (unique, vérifier disponibilité)
- [ ] Obtenir domaine public propre (optionnel mais recommandé)
- [ ] Configurer infrastructure de base (1+ serveur)
- [ ] Installer OS (Debian/Ubuntu/autre Linux)
- [ ] Configurer réseau interne (10.[ID].0.0/16)

#### Phase 2 : DNS et Connectivité (Semaine 3)

- [ ] Installer serveur DNS (Bind9, PowerDNS)
- [ ] Configurer zone `[slug].boreal.ca`
- [ ] Demander délégation au Cercle Opérationnel
- [ ] Tester résolution publique
- [ ] Configurer AXFR avec 1+ pair
- [ ] Configurer firewall (ports standards ouverts)

#### Phase 3 : Services de Base (Semaines 4-6)

- [ ] Déployer serveur email (Postfix, Dovecot)
- [ ] Configurer DKIM, SPF, DMARC
- [ ] Obtenir certificats SSL/TLS (Let's Encrypt)
- [ ] Déployer services optionnels (Nextcloud, Matrix)
- [ ] Configurer backups quotidiens
- [ ] Tester restauration

#### Phase 4 : Monitoring et Documentation (Semaines 7-8)

- [ ] Installer Prometheus + Node Exporter
- [ ] Configurer Grafana
- [ ] Créer status page publique
- [ ] Documenter architecture (wiki)
- [ ] Rédiger runbooks (≥ 3 procédures)

#### Phase 5 : Intégration (Semaines 9-12)

- [ ] Participer à audits pair-à-pair
- [ ] Contribuer à documentation commune
- [ ] Établir VPN avec 1+ pair (si besoin backups croisés)
- [ ] Demander labellisation (Bronze minimum)

**Durée totale estimée : 3 mois (phase probatoire)**

---

## MÉTADONNÉES

**Document :** 05_Architecture_Reference_Standards_Techniques.md  
**Version :** 1.0  
**Date de création :** 23 octobre 2025  
**Auteur :** Claude (profils #3 Infrastructure, #4 Réseau, #5 IaC, #12 Documentaliste)  
**Révision par :** Cercle Opérationnel  
**Statut :** À adopter par Cercle Stratégique  
**Longueur :** ~15 000 mots (30 pages équivalent)  
**Licence :** CC BY-SA 4.0

**Sources utilisées :**
- `00_Glossaire_et_Definitions.md`
- `01_Charte_Fondatrice_v2_1.md`
- `02_Reglement_de_Regie_Interne.md`
- `03_Cadre_Conformite_Label_Prestige.md`
- `devis_alliance_boreale_v2.md`

**Prochaine révision prévue :** Octobre 2026 (après 1 an d'usage terrain)

---

**Changelog :**
- 2025-10-23 v1.0 : Création initiale Architecture & Standards Techniques

---

**FIN DE L'ARCHITECTURE DE RÉFÉRENCE**

*"Un nom bien choisi vaut mieux qu'une longue documentation."*

🌲 **L'Alliance Boréale**  
*Standards mnémotechniques pour une fédération durable.*