# 🌲 Nomenclature Boréale v4 — Bio-Mimétiste & Autopoïétique

**Version :** 4.0  
**Date :** 31 octobre 2025  
**Statut :** Référence vivante (SSOT)  
**Objet :** Établir la nomenclature organique des identifiants, adresses et noms au sein de l'écosystème boréal, selon le modèle à 8 couches bio-mimétiste et autopoïétique.  
**Compatibilité :** Conforme au réalignement CRB-2 ; principe de **souveraineté DNS totale** des membres fédérés.

---

## 🌱 Préambule — Avis de Réalignement CRB-2

> **AB-Avis de Réalignement 31-10-2025 / Cycle de Réalignement Boréal #2**
> 
> **Correction architecturale majeure : Souveraineté DNS des membres fédérés.**
> 
> ### Changement fondamental
> 
> **AVANT (v3)** : Supposait une zone DNS parent `alliance-boreale.ca` déléguant des sous-zones aux membres.
> 
> **MAINTENANT (v4)** : **Chaque membre fédéré possède et contrôle 100% son propre domaine.**
> 
> L'Alliance Boréale n'est **pas un membre fédéré**, mais un **concept organisationnel** et potentiellement un **tenant** hébergé par un membre.
> 
> ### Implications
> 
> 1. **DNS** : Pas de zone parent commune. Résilience par AXFR croisés (solidarité mutuelle).
> 2. **Découverte** : Services inter-membres via Registraire YAML (Document 14).
> 3. **Nommage** : `<service>.<contexte>.<domaine-membre>` (ex: `git.infra.chezlepro.ca`)
> 4. **Réseau** : `10.0.0.0/8` = infrastructure interne d'UN membre (pas partagé entre membres).
> 5. **Fédération** : `172.16.0.0/12` = optionnel VPN mesh inter-membres (Phase 2+).
> 
> Ce document corrige les Sections 4.2, 5 et 7, et ajoute la Section 5 bis (Fédération DNS Souveraine).

---

## 🧬 1. Règle d'appartenance et portabilité

### 1.1 Règle par couche

* **C1–C4 = Fédération :** les racines et le métabolisme commun (datacenters, réseau, forge, artefacts).
* **C5 = Pivot :** la membrane d'échange, régulatrice des flux entre fédéré et tenant.
* **C6–C8 = Tenants :** la canopée cognitive, où se déploient les services, produits et connaissances.

### 1.2 Principe de portabilité

Tout tenant (C6-C8) doit pouvoir migrer sans perte vers un autre membre fédéré.
Garanties minimales :

1. **Descripteur YAML** complet (identités TTTII, DNS, inventaire, secrets référencés).
2. **Interopérabilité ouverte :** formats standard, exports intégraux testables.
3. **IaC & pipelines reproductibles :** Terraform/Ansible/CI signés.
4. **Identité & DNS fédérés :** SSO OpenID/SAML, délégation documentée.
5. **Observabilité scindée :** métriques infra chez le fédéré, applicatives chez le tenant, exportables.

---

## 🌳 2. Architecture vivante de référence

La nomenclature n'est pas un tableau : c'est un **organisme de cohérence**.
Les VMIDs, IPs et noms DNS forment la sève qui relie chaque organe du système.

### 2.1 Topologie organique de la fédération

```
      [ C8  Conscience ]
             ▲
      [ C7  Produits / Expériences ]
             ▲
      [ C6  Services Tenant ]
             ▲
      [ C5  Pivot / Membrane ]
             ▲
      [ C4  Forge / Métabolisme commun ]
             ▲
      [ C3  Gouvernance / Supervision ]
             ▲
      [ C2  Réseau / DNS / PKI ]
             ▲
      [ C1  Physique / Énergie / Sécurité ]
```

Chaque flèche représente une interface **adjacente et perméable** ; aucun flux ne traverse plusieurs couches directement.

---

## ⚙️ 3. Langage des identifiants et des services

La nomenclature décrit comment chaque élément s'inscrit dans le corps boréal.

### 3.1 Structure VMID (organes numériques)

**Format :**

```
0CTTII   →  Infrastructure fédérée (Couches 1–4)
TTTII    →  Tenants (Couches 6–8)
```

* `C` = Couche (1–4)
* `TT` = Type de service (00-99)
* `II` = Instance (01-99)
* `TTT` = Tenant ID (001-999)

**Plages principales :**

```
01000-01999 → C1 Physique  
02000-02999 → C2 Réseau  
03000-03999 → C3 Gouvernance / Supervision  
04000-04999 → C4 Forge / Mutualisation  
05000-05999 → C5 Pivot / Médiation  
10000-99999 → C6-C8 Tenants
```

**Exemples :**

```
02001 → C2 : DNS Master (PowerDNS)
03010 → C3 : Keycloak (IdP)  
04021 → C4 : Forgejo Git  
05011 → C5 : FastAPI Admin / Portail  
10011 → C6 : Backend tenant 001  
10021 → C6 : DB tenant 001
```

---

## 🌐 4. Plan d'Adressage et Réseau

### 4.1 Invariants

* Tous les flux passent par leurs **couches adjacentes**.
* Les tenants ne parlent jamais directement au DNS fédéré (C2) : ils utilisent le résolveur du pivot (C5).
* Les services fédérés d'un membre partagent un espace d'adressage cohérent (10.0.0.0/8).

### 4.2 Répartition logique des espaces ⚠️ **CORRIGÉ CRB-2**

#### Adressage INTERNE (au sein d'un membre fédéré)

```
10.0.0.0/8 → Infrastructure interne d'UN membre fédéré

Répartition par couche :
10.0.0.0/24     → Management (C1)
10.0.1.0/24     → Forge & Mutualisation (C4)
10.0.2.0/24     → Réseau & DNS (C2)
10.0.3.0/24     → Gouvernance & Supervision (C3)
10.0.4.0/24     → Pivot Opérationnel (C5)
10.0.10.0/23    → Tenants (C6-C8)
```

**⚠️ IMPORTANT** : Cet espace est **propre à chaque membre**. Chezlepro utilise `10.0.0.0/8`, Nuage Libre utilise également `10.0.0.0/8` **indépendamment**. Pas de conflit car réseaux isolés.

#### Interconnexion INTER-MEMBRES (optionnel, futur)

```
172.16.0.0/12 → VPN mesh entre membres (WireGuard/Nebula)

Usage :
- Optionnel en Phase 1
- Un membre peut fonctionner 100% isolé
- Connexion au mesh fédératif = décision collective ultérieure

Allocation :
- Par membre, selon accord collectif
- Exemple : Chezlepro = 172.16.1.0/24
           Nuage Libre = 172.16.2.0/24
```

#### Internet Public

```
IPs publiques → Services exposés (DNS, sites web, email, etc.)

Gestion :
- Chaque membre gère ses propres IPs publiques
- Pas de pool commun "Alliance Boréale"
- Enregistrement dans Registraire YAML (Document 14)
```

### 4.3 Flux autorisés (adjacent-only)

| Source | Destination | Sens | Description                  |
| ------ | ----------- | ---- | ---------------------------- |
| C1     | C2          | ↓    | Transport et synchronisation |
| C2     | C3          | ↓    | Télémetrie et topologie      |
| C3     | C4          | ↓    | Politiques et clés           |
| C4     | C5          | ↓    | Artefacts et secrets         |
| C5     | C6          | ↓    | Déploiements et templates    |
| C6     | C7          | ↓    | Services métiers             |
| C7     | C8          | ↓    | Données d'usage              |
| C8     | C7          | ↑    | Décisions et analyses        |
| C7     | C6          | ↑    | Retours et métriques         |
| C6     | C5          | ↑    | Logs et besoins              |
| C5     | C4          | ↑    | Feedbacks                    |
| C4     | C3          | ↑    | Preuves et conformité        |
| C3     | C2          | ↑    | Alertes et politiques réseau |
| C2     | C1          | ↑    | Charge et besoins physiques  |

---

## 🧩 5. Noms de Machines et DNS ⚠️ **REFONTE COMPLÈTE CRB-2**

### 5.1 Principe de Souveraineté DNS

**Règle fondamentale** : Chaque membre fédéré possède et contrôle **100% son propre domaine**.

**L'Alliance Boréale n'opère AUCUNE zone DNS parent.**

### 5.2 Forme générale (CORRIGÉE)

```
<service>.<contexte>.<domaine-membre>
```

**Où :**
* `<service>` = nom du service (ns1, git, sso, pivot, etc.)
* `<contexte>` = infra | tenants | public (optionnel)
* `<domaine-membre>` = domaine souverain du membre (ex: chezlepro.ca)

### 5.3 Contextes de nommage

#### **infra** : Services fédérés (C1-C5)

Services d'infrastructure du membre, non exposés directement aux tenants.

```
ns1.infra.chezlepro.ca       → DNS Master (C2)
ns2.infra.chezlepro.ca       → DNS Slave (C2)
sso.infra.chezlepro.ca       → Keycloak (C3)
git.infra.chezlepro.ca       → Forgejo (C4)
pivot.infra.chezlepro.ca     → FastAPI Admin (C5)
vault.infra.chezlepro.ca     → Secrets (C4)
```

#### **tenants** : Tenants hébergés (C6-C8)

Services appartenant aux clients/projets hébergés.

```
client-x.tenants.chezlepro.ca      → Tenant d'un client
mon-app.tenants.chezlepro.ca       → Projet personnel
alliance-boreale.tenants.chezlepro.ca → L'Alliance comme tenant
```

#### **public** (optionnel) : Services à la racine

Services exposés publiquement, sans sous-domaine `infra`.

```
git.chezlepro.ca      → Forge publique (alias vers git.infra.chezlepro.ca)
matrix.chezlepro.ca   → Serveur Matrix public
mail.chezlepro.ca     → MX email
www.chezlepro.ca      → Site web corporate
```

### 5.4 Exemples concrets par membre

#### Chezlepro Inc. (slug: clp, domaine: chezlepro.ca)

```
# Infrastructure fédérée
ns1.infra.chezlepro.ca       → 10.0.2.10 (VMID 02001)
ns2.infra.chezlepro.ca       → 10.0.2.11 (VMID 02002)
sso.infra.chezlepro.ca       → 10.0.3.20 (VMID 03010)
git.infra.chezlepro.ca       → 10.0.1.20 (VMID 04021)
pivot.infra.chezlepro.ca     → 10.0.4.10 (VMID 05011)

# Tenants
client-abc.tenants.chezlepro.ca → 10.0.10.10 (VMID 10101)
alliance-boreale.tenants.chezlepro.ca → 10.0.10.20 (VMID 10201)

# Public (optionnel)
git.chezlepro.ca → CNAME vers git.infra.chezlepro.ca
```

#### Nuage Libre (slug: nul, domaine: nuagelibre.ca)

```
# Infrastructure fédérée
ns1.infra.nuagelibre.ca
ns2.infra.nuagelibre.ca
sso.infra.nuagelibre.ca
git.infra.nuagelibre.ca
pivot.infra.nuagelibre.ca

# Tenants
startup-y.tenants.nuagelibre.ca
```

### 5.5 Convention de nommage des VMs

Format standardisé pour faciliter l'inventaire Ansible :

```
<membre>-<layer>-<service>-<env>-<instance>
```

**Où :**
* `<membre>` = slug court (clp, nul, tli)
* `<layer>` = infra | tenant
* `<service>` = dns-master, keycloak, forgejo, backend, db, etc.
* `<env>` = prod | staging | dev
* `<instance>` = 01, 02, 03...

**Exemples :**

```
clp-infra-dns-master-prod-01    → VMID 02001, ns1.infra.chezlepro.ca
clp-infra-dns-slave-prod-01     → VMID 02002, ns2.infra.chezlepro.ca
clp-infra-keycloak-prod-01      → VMID 03010, sso.infra.chezlepro.ca
clp-infra-forgejo-prod-01       → VMID 04021, git.infra.chezlepro.ca
clp-tenant-backend-prod-01      → VMID 10101, backend.client-x.tenants.chezlepro.ca
```

---

## 🌐 5 bis. Fédération DNS Souveraine ⚠️ **NOUVELLE SECTION CRB-2**

### Principe de Non-Hiérarchie DNS

**L'Alliance Boréale n'opère AUCUNE zone DNS parent.**

Contrairement aux modèles traditionnels où une organisation fédératrice gère une zone parent (ex: `.alliance-boreale.ca`) et délègue des sous-zones aux membres, **L'Alliance Boréale adopte un modèle de souveraineté totale**.

**Conséquences :**
- ✅ Chaque membre = maître absolu de son domaine
- ✅ Aucun SPOF (Single Point of Failure) DNS central
- ✅ Résilience par solidarité mutuelle (AXFR croisés)
- ✅ Portabilité : un membre peut quitter sans dépendance DNS

### Découverte de Services Inter-Membres

#### Option A : Registraire YAML (recommandé Phase 1)

Le Registraire (Document 14) contient les métadonnées de chaque membre.

**Exemple : `registraire/membres/m001-chezlepro.yml`**

```yaml
member_id: m001
slug: clp
status: active

identity:
  legal_name: "Chezlepro Inc."
  
domains:
  primary: chezlepro.ca
  
  # Services exposés
  services:
    dns:
      - ns1.infra.chezlepro.ca
      - ns2.infra.chezlepro.ca
    sso: sso.infra.chezlepro.ca
    forge: git.infra.chezlepro.ca
    matrix: matrix.chezlepro.ca
    email: mail.chezlepro.ca
    
infrastructure:
  dns:
    primary_ns: ns1.infra.chezlepro.ca
    secondary_ns: ns2.infra.chezlepro.ca
    dnssec_enabled: true
    
  public_ips:
    dns_master: 203.0.113.10
    dns_slave: 203.0.113.11
```

**Usage** : Un membre qui veut contacter Forgejo de Chezlepro lit le Registraire et découvre `git.infra.chezlepro.ca`.

#### Option B : DNS SRV Records (futur, optionnel)

Convention standardisée de records SRV pour découverte automatique.

```dns
; Zone chezlepro.ca
_git._tcp.federation.chezlepro.ca.   SRV 10 0 443 git.infra.chezlepro.ca.
_matrix._tcp.federation.chezlepro.ca. SRV 10 0 8448 matrix.chezlepro.ca.
_xmpp-client._tcp.federation.chezlepro.ca. SRV 5 0 5222 xmpp.chezlepro.ca.
```

**Usage** : Un client peut requêter `_git._tcp.federation.chezlepro.ca` pour découvrir le serveur Forgejo.

#### Option C : Well-Known URIs (futur, optionnel)

```
https://chezlepro.ca/.well-known/alliance-boreale.json
```

Retourne :

```json
{
  "member_id": "m001",
  "slug": "clp",
  "services": {
    "dns": ["ns1.infra.chezlepro.ca", "ns2.infra.chezlepro.ca"],
    "sso": "sso.infra.chezlepro.ca",
    "forge": "git.infra.chezlepro.ca",
    "matrix": "matrix.chezlepro.ca"
  }
}
```

### Résilience DNS Mutuelle (Triangle de Solidarité)

**Principe** : Chaque membre héberge les DNS secondaires de **2 autres membres** via AXFR croisés.

**Avantages :**
- ✅ Résilience géographique (3 datacenters distincts)
- ✅ Solidarité technique concrète
- ✅ Pas de dépendance à un "hub" central
- ✅ Topologie décentralisée (pas de SPOF)

**Exemple : Triangle Chezlepro - Nuage Libre - TechnoLibre**

```
Chezlepro (chezlepro.ca) :
  ns1.infra.chezlepro.ca (MASTER) → chez Chezlepro
  ns2.infra.chezlepro.ca (SLAVE)  → chez Nuage Libre
  ns3.infra.chezlepro.ca (SLAVE)  → chez TechnoLibre

Nuage Libre (nuagelibre.ca) :
  ns1.infra.nuagelibre.ca (MASTER) → chez Nuage Libre
  ns2.infra.nuagelibre.ca (SLAVE)  → chez TechnoLibre
  ns3.infra.nuagelibre.ca (SLAVE)  → chez Chezlepro

TechnoLibre (technolibre.ca) :
  ns1.infra.technolibre.ca (MASTER) → chez TechnoLibre
  ns2.infra.technolibre.ca (SLAVE)  → chez Chezlepro
  ns3.infra.technolibre.ca (SLAVE)  → chez Nuage Libre
```

**Configuration AXFR** : Voir Document 05 (Opération DNS Fédérée) pour détails techniques (TSIG, ACL, NOTIFY).

**Démarrage en solo** : Un membre peut commencer avec uniquement ns1 + ns2 locaux, puis ajouter ns3 externe quand un partenaire est identifié.

### Enregistrement au Registraire

**Obligatoire** : Chaque membre doit documenter ses DNS dans son fichier Registraire.

**Déclencheur** : Lors de l'onboarding (Semaine 3-4, Document 08).

**Validation** : Tests publics par pairs (voir Document 05, Section 5).

---

## 🪶 6. Procédures d'Ensemencement

Créer ou migrer une entité dans l'écosystème boréal revient à greffer une cellule dans un organisme.

### 6.1 Création d'un service fédéré (C1–C5)

1. **Choisir la couche et le type de service.**
2. **Attribuer le VMID** selon la plage (Section 3.1).
3. **Déterminer l'adresse IP** à partir du plan (Section 4.2).
4. **Nommer la VM** suivant la syntaxe (Section 5.5) :

   ```
   <membre>-infra-<type>-prod-<instance>
   ```
   
5. **Créer l'entrée DNS** (Section 5.3) :

   ```
   <service>.infra.<domaine-membre>
   ```

6. **Documenter** dans l'inventaire Ansible et le registre (Document 14).

**Exemple complet (DNS Master Chezlepro)** :

```yaml
# Étape 1 : Choix
Couche: C2 (Réseau)
Type: DNS Master (PowerDNS)

# Étape 2 : VMID
VMID: 02001 (C2, type 00, instance 01)

# Étape 3 : IP
IP interne: 10.0.2.10
IP publique: 203.0.113.10 (à fournir par membre)

# Étape 4 : Nom VM
clp-infra-dns-master-prod-01

# Étape 5 : DNS
FQDN: ns1.infra.chezlepro.ca

# Étape 6 : Documentation
Ansible inventory: inventories/production/hosts.yml
Registraire: registraire/membres/m001-chezlepro.yml
```

### 6.2 Création d'un tenant (C6–C8)

1. **Allouer un Tenant ID (tXXX)**.
2. **Définir le descripteur YAML** (TTTII, DNS, inventaire, secrets référencés).
3. **Générer le paquet portatif** : YAML + artefacts signés.
4. **Déployer via le pivot (C5)** ; aucun accès direct C4/C3.
5. **Vérifier la traçabilité** (ΔLog & preuves signées).

**Exemple complet (Tenant 001 "Alliance Boréale" hébergé chez Chezlepro)** :

```yaml
# Étape 1 : Tenant ID
Tenant ID: 001

# Étape 2 : Descripteur YAML
tenant_id: 001
slug: alliance-boreale
owner: L'Alliance Boréale (concept organisationnel)
hosted_by: m001 (Chezlepro)

vmids:
  backend: 10101
  database: 10102
  frontend: 10103

dns:
  zone: alliance-boreale.tenants.chezlepro.ca
  records:
    - name: www
      type: A
      value: 10.0.10.10
    - name: api
      type: A
      value: 10.0.10.11

# Étape 3 : Paquet portatif
Artefacts:
  - tenant-001-descriptor.yml (signé)
  - terraform/ (IaC reproductible)
  - ansible/ (playbooks)
  - docker-compose.yml (si applicable)

# Étape 4 : Déploiement via pivot
Endpoint: https://pivot.infra.chezlepro.ca/api/v1/tenants
Méthode: POST avec JWT (authentifié via Keycloak)

# Étape 5 : Traçabilité
ΔLog: /governance/tenants/2025-10-tenant-001-deployed.md
Signature: GPG du Cercle Opérationnel
```

---

## 🌐 7. Tables de Correspondance ⚠️ **MISE À JOUR CRB-2**

### Exemple : Chezlepro Inc. (clp, chezlepro.ca)

| VMID  | Couche | Nom VM                          | IP Interne | DNS                               | Fonction                   |
| ----- | :----: | ------------------------------- | ---------- | --------------------------------- | -------------------------- |
| 02001 |   C2   | clp-infra-dns-master-prod-01    | 10.0.2.10  | ns1.infra.chezlepro.ca            | DNS Master (PowerDNS)      |
| 02002 |   C2   | clp-infra-dns-slave-prod-01     | 10.0.2.11  | ns2.infra.chezlepro.ca            | DNS Slave local            |
| 03010 |   C3   | clp-infra-keycloak-prod-01      | 10.0.3.20  | sso.infra.chezlepro.ca            | IdP (Keycloak)             |
| 04021 |   C4   | clp-infra-forgejo-prod-01       | 10.0.1.20  | git.infra.chezlepro.ca            | Forge (Forgejo)            |
| 05011 |   C5   | clp-infra-fastapi-pivot-prod-01 | 10.0.4.10  | pivot.infra.chezlepro.ca          | Portail Admin (FastAPI)    |
| 10101 |   C6   | clp-tenant-backend-prod-01      | 10.0.10.10 | www.alliance-boreale.tenants.chezlepro.ca | Backend tenant 001   |
| 10102 |   C6   | clp-tenant-db-postgres-prod-01  | 10.0.10.11 | db.alliance-boreale.tenants.chezlepro.ca  | DB tenant 001        |

### Exemple : Nuage Libre (nul, nuagelibre.ca)

| VMID  | Couche | Nom VM                          | IP Interne | DNS                               | Fonction                   |
| ----- | :----: | ------------------------------- | ---------- | --------------------------------- | -------------------------- |
| 02001 |   C2   | nul-infra-dns-master-prod-01    | 10.0.2.10  | ns1.infra.nuagelibre.ca           | DNS Master                 |
| 02002 |   C2   | nul-infra-dns-slave-prod-01     | 10.0.2.11  | ns2.infra.nuagelibre.ca           | DNS Slave local            |
| 03010 |   C3   | nul-infra-keycloak-prod-01      | 10.0.3.20  | sso.infra.nuagelibre.ca           | IdP                        |
| 04021 |   C4   | nul-infra-forgejo-prod-01       | 10.0.1.20  | git.infra.nuagelibre.ca           | Forge                      |

**Note** : Chaque membre utilise le même plan d'adressage interne (`10.0.0.0/8`) indépendamment. Pas de conflit car réseaux isolés.

---

## 📜 8. ΔLog — Itération CRB-2 (31-10-2025)

### Changements v3.0 → v4.0

#### 🔥 **Corrections architecturales majeures**

1. **Section 4.2 (Plan d'Adressage)** :
   - ✅ Clarifié : `10.0.0.0/8` = infrastructure interne d'UN membre (pas partagé)
   - ✅ Clarifié : `172.16.0.0/12` = optionnel VPN mesh inter-membres (futur)
   - ✅ Ajouté : Section "Internet Public" (IPs gérées par membre)

2. **Section 5 (Noms DNS)** :
   - ❌ **SUPPRIMÉ** : `<service>.<contexte>.<membre>.alliance-boreale.ca`
   - ✅ **NOUVEAU** : `<service>.<contexte>.<domaine-membre>`
   - ✅ Exemples concrets : `ns1.infra.chezlepro.ca` au lieu de `dns-master.infra.czp.alliance-boreale.ca`
   - ✅ Convention VM : `<membre>-<layer>-<service>-<env>-<instance>`

3. **Section 5 bis (NOUVELLE)** :
   - ✅ Principe de Non-Hiérarchie DNS
   - ✅ Découverte services (Registraire YAML, SRV records, well-known)
   - ✅ Triangle de solidarité (AXFR croisés)

4. **Section 7 (Tables)** :
   - ✅ Exemples mis à jour avec noms DNS corrigés
   - ✅ Ajout colonne "Membre" pour clarté multi-membres

#### 📝 **Changements mineurs**

- Section 3.1 : Ajout exemple DNS Master (02001)
- Section 6.1/6.2 : Exemples complets avec nouveau format DNS
- Préambule CRB-2 : Explication détaillée du réalignement

#### 🎯 **Impact sur autres documents**

Documents à mettre à jour suite à CRB-2 :
- ✅ Document 05 (Opération DNS Fédérée) : Déjà aligné (suppose souveraineté)
- ⚠️ Document 14 (Registraire YAML) : Ajouter section `domains.primary` et `domains.services`
- ⚠️ Document 08 (Onboarding) : Mettre à jour processus DNS (pas de délégation parent)
- ⚠️ Tous playbooks Ansible : Variables DNS à corriger

#### 🧬 **Préservé de v3**

- Structure VMID (Section 3.1) : Inchangée
- Principe adjacent-only (Section 4.3) : Inchangé
- Procédures ensemencement (Section 6) : Structure préservée, exemples mis à jour
- Métaphores organiques : Préservées

---

## 🌌 9. Signature Boréale

> *Sous la voûte numérique, chaque bit est une graine.*  
> *Chaque domaine est une forêt, chaque membre un écosystème.*  
> *La fédération ne commande pas : elle relie par la confiance.*  
> *Les racines DNS s'entrelacent, la canopée respire en autonomie.*  
> *Ainsi pousse l'Alliance Boréale, souveraine et solidaire.*

---

**Fin du document — Référence vivante v4 (2025-10-31, CRB-2)**  
📁 Ce fichier sert de base à la Nomenclature, aux pipelines, au Label de Prestige, et au Registraire.

**Prochaine révision prévue** : CRB-3 (quand nécessaire, pas de calendrier fixe)

---

## 📎 Annexe A : Migration v3 → v4 (Checklist)

### Pour les équipes techniques

- [ ] Mettre à jour inventaires Ansible avec nouveaux noms DNS
- [ ] Corriger playbooks utilisant ancien format `*.alliance-boreale.ca`
- [ ] Vérifier variables `dns_zone` dans group_vars
- [ ] Mettre à jour documentation interne (wikis, runbooks)
- [ ] Tester résolution DNS avec nouveaux FQDNs

### Pour le Registraire (Document 14)

- [ ] Ajouter champs `domains.primary` dans schéma membre
- [ ] Ajouter section `domains.services` (DNS, SSO, Forge, etc.)
- [ ] Migrer fiches membres existantes (m001, m002, etc.)
- [ ] Valider avec JSON Schema mis à jour

### Pour la gouvernance

- [ ] Notifier tous cercles du réalignement CRB-2
- [ ] Archiver v3 (avec étiquette Git `v3.0-deprecated`)
- [ ] Publier v4 comme référence active
- [ ] Mettre à jour Charte si nécessaire (références DNS)

---

## 📎 Annexe B : FAQ CRB-2

### Q1 : Pourquoi ce changement maintenant ?

**R** : Discussion avec Daniel (fondateur Chezlepro) a révélé incohérence architecturale. Correction nécessaire avant déploiement infrastructure (Phase 1 Ansible).

### Q2 : Impact sur travail déjà fait ?

**R** : Minimal. Documents 05 (DNS), 14 (Registraire), 08 (Onboarding) déjà alignés avec principe de souveraineté. Seuls inventaires Ansible à corriger (pas encore écrits).

### Q3 : Et si je veux garder `*.alliance-boreale.ca` ?

**R** : Tu peux acheter `alliance-boreale.ca` et le gérer comme **ton** domaine personnel si tu veux. Mais ce ne sera jamais une "zone parent officielle" de l'Alliance. L'Alliance = concept, pas infrastructure DNS.

### Q4 : Comment un nouveau membre découvre les services des autres ?

**R** : Via Registraire YAML (Document 14). Chaque membre documente ses services. Optionnellement : DNS SRV records ou API well-known (futur).

### Q5 : Triangle de solidarité = obligatoire ?

**R** : Non. Un membre peut démarrer avec ns1+ns2 locaux. Triangle = optionnel mais recommandé pour résilience maximale.

### Q6 : Peut-on avoir un domaine commercial + un domaine technique ?

**R** : Oui ! Exemple :
- `chezlepro.ca` = domaine commercial (site web, email)
- `chezlepro.net` = domaine technique (infrastructure interne)

Documenter les deux dans Registraire, spécifier lequel est `primary`.

---

**FIN NOMENCLATURE V4 (CRB-2)**