alliance-boreale/docs/00_Nomenclature_v4.md

🌲 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

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.

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

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

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

# É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)