# RÉSOLUTION D'ADOPTION
## Standard de Nomenclature v2.0
### L'Alliance Boréale

---

**Numéro de résolution :** 2025-TECH-001  
**Date de proposition :** 21 octobre 2025  
**Cercle émetteur :** Cercle Technique  
**Processus :** Consentement Sociocratique  
**Statut :** PROPOSITION (en attente de validation)

---

## CONTEXTE

### Situation Actuelle

L'Alliance Boréale compte actuellement **3 membres actifs** (Chezlepro, Nuage Libre, TechnoLibre) avec une infrastructure totale d'environ **120 machines virtuelles** réparties entre infrastructure propre et tenants hébergés.

**Problématiques identifiées :**

1. **Absence de standard unifié** pour l'identification des ressources
2. **Nomenclature incohérente** entre les membres (VMIDs, noms, IPs)
3. **Difficultés d'automatisation** (Ansible, Terraform) dues au manque de structure
4. **Complexité d'audit** pour la labellisation (Bronze, Argent, Or, Platine)
5. **Onboarding lent** des nouveaux administrateurs
6. **Risques opérationnels** (erreurs de manipulation, confusion)

### Besoins Exprimés

Lors des réunions du Cercle Technique (août-octobre 2025), les membres ont exprimé le besoin de :

- ✅ **Standardiser** l'identification de toutes les ressources (VMs, IPs, DNS)
- ✅ **Faciliter l'automatisation** avec des patterns prévisibles
- ✅ **Simplifier les audits** de conformité pour la labellisation
- ✅ **Accélérer l'onboarding** avec une documentation claire
- ✅ **Améliorer la scalabilité** (prévoir 999 tenants par membre)

---

## PROPOSITION

### Objet de la Résolution

**IL EST PROPOSÉ** d'adopter le **Standard de Nomenclature v2.0** comme standard officiel de L'Alliance Boréale pour l'identification et l'organisation des ressources d'infrastructure.

### Composants du Standard

Le Standard de Nomenclature v2.0 comprend :

#### 1. Spécification Technique (60+ pages)
- Format VMID mnémotechnique (0CTTII pour infra, TTTII pour tenants)
- Plan d'adressage IP unifié (10.0.0.0/8 par membre, derrière NAT)
- Nomenclature VMs (<membre>-infra/t<XXX>-<type>-<env>-<inst>)
- Nomenclature DNS (<service>.infra/t<XXX>.<membre>.alliance-boreale.ca)
- Tables de correspondance complètes

#### 2. Outillage (6 scripts)
- `audit-nomenclature.sh` - Audit de conformité
- `generate-dns-records.sh` - Génération zone DNS
- `generate-inventory.sh` - Génération inventaire Ansible
- `migrate-vm.sh` - Migration assistée avec simulation
- `validate-vmid.sh` - Validation format VMID
- `allocate-ip.sh` - Allocation IP tenants (IPAM)

#### 3. Formation et Documentation
- Guide de formation (40+ pages, 8 exercices pratiques)
- Test de certification (10 questions + exercice final)
- Templates Ansible et Terraform
- Aide-mémoire imprimable

#### 4. Gouvernance
- Processus de révision annuelle
- Procédures de modification (RFC)
- Versionnage sémantique (v2.x.x)

---

## MODALITÉS D'ADOPTION

### 1. Adoption du Standard

**IL EST RÉSOLU :**

**QUE** le Standard de Nomenclature v2.0, tel que documenté dans le package complet daté du 21 octobre 2025, soit adopté comme **standard officiel obligatoire** pour tous les membres de L'Alliance Boréale.

### 2. Date d'Entrée en Vigueur

**QUE** ce standard entre en vigueur selon le calendrier suivant :

- **Immédiat (21 octobre 2025)** : Publication officielle du standard
- **1er décembre 2025** : Formation obligatoire de tous les administrateurs
- **1er janvier 2026** : Obligation pour tous **nouveaux déploiements**
- **31 décembre 2026** : Objectif de conformité à 100% pour l'existant

### 3. Obligations des Membres

**QUE** chaque membre s'engage à :

#### A) Formation (avant 1er décembre 2025)
- [ ] Former tous les administrateurs système (min. 1 par membre)
- [ ] Certifier au moins 1 administrateur par membre (niveau 2)
- [ ] Désigner 1 "référent nomenclature" par membre

#### B) Nouveaux Déploiements (à partir du 1er janvier 2026)
- [ ] Respecter le standard v2.0 pour **toute nouvelle VM**
- [ ] Utiliser les scripts fournis pour validation (validate-vmid.sh)
- [ ] Documenter toute exception (avec justification validée)

#### C) Migration de l'Existant (avant 31 décembre 2026)
- [ ] Réaliser un audit initial (avant 31 janvier 2026)
- [ ] Établir un plan de migration (avant 28 février 2026)
- [ ] Migrer par lots (5-10 VMs/mois minimum)
- [ ] Atteindre 80% de conformité avant 30 juin 2026
- [ ] Atteindre 100% de conformité avant 31 décembre 2026

#### D) Reporting
- [ ] Rapport mensuel de conformité au Cercle Technique
- [ ] Partage des retours d'expérience (bonnes pratiques, difficultés)

### 4. Ressources Allouées

**QUE** L'Alliance Boréale alloue les ressources suivantes :

#### Coordination (Banque de Temps)
- **30 heures** : Animation sessions de formation (réparties entre experts)
- **20 heures** : Support technique aux membres (canal dédié Matrix)
- **10 heures** : Maintenance documentation et scripts

#### Infrastructure Commune
- **Forge Git** : Hébergement du code et documentation
- **Wiki** : Documentation interactive et exemples
- **Forum** : Entraide entre membres

#### Budget Financier (si nécessaire)
- **0 $** : Tout en logiciel libre et Banque de Temps
- **Réserve** : 500 $ pour formation externe si expertise manquante

### 5. Exceptions et Dérogations

**QUE** des exceptions puissent être accordées selon ce processus :

#### Cas Justifiant une Exception
- Contraintes techniques insurmontables (matériel legacy)
- Dépendances externes non migrables à court terme
- Coût de migration disproportionné pour VM en fin de vie

#### Processus d'Exception
1. **Demande écrite** au Cercle Technique (formulaire dédié)
2. **Justification technique** détaillée + impact + alternatives explorées
3. **Validation** par 2 experts du Cercle Technique
4. **Durée limitée** : Max 12 mois, renouvellement possible 1 fois
5. **Plan de mise en conformité** obligatoire dans la demande

#### Registre des Exceptions
- Tenu à jour dans `governance/nomenclature-exceptions.yml`
- Consultation publique par tous les membres
- Révision trimestrielle par le Cercle Technique

### 6. Maintenance et Évolution

**QUE** le standard soit maintenu selon ces principes :

#### Responsabilité
- **Propriétaire** : Cercle Technique de L'Alliance Boréale
- **Gardien du standard** : 1 membre désigné (rotation annuelle)
- **Contributeurs** : Tous les membres (via RFC)

#### Révisions
- **Mineures (v2.x)** : Corrections, clarifications → Validation Cercle Technique
- **Majeures (v3.0)** : Changements structurels → Consentement tous membres
- **Fréquence** : Révision annuelle obligatoire (octobre)

#### Processus RFC (Request for Comments)
1. Proposition ouverte sur la forge (`rfc/NNNN-titre.md`)
2. Discussion publique (min. 2 semaines)
3. Présentation au Cercle Technique
4. Décision par consentement (si impact majeur)
5. Intégration dans version suivante

---

## IMPACTS ET BÉNÉFICES ATTENDUS

### Impacts Positifs

#### Court Terme (6 mois)
- ✅ **Clarté opérationnelle** : Toute ressource identifiable immédiatement
- ✅ **Réduction erreurs** : -80% d'erreurs de manipulation (estimation)
- ✅ **Automatisation** : Playbooks Ansible génériques réutilisables
- ✅ **Onboarding** : Temps de formation -50% pour nouveaux admins

#### Moyen Terme (1 an)
- ✅ **Conformité audits** : Simplification audits de labellisation
- ✅ **Scalabilité** : Capacité d'accueillir 999 tenants par membre
- ✅ **Professionnalisme** : Crédibilité renforcée de L'Alliance
- ✅ **Collaboration** : Entraide facilitée entre membres

#### Long Terme (2 ans)
- ✅ **Maturité** : Infrastructure de niveau "entreprise"
- ✅ **Résilience** : Documentation permettant continuité en cas de départ
- ✅ **Innovation** : Base solide pour outils avancés (IPAM auto, API)
- ✅ **Rayonnement** : Standard pouvant influencer la communauté Proxmox

### Impacts Négatifs (Mitigations)

#### Charge de Travail Initiale
- ⚠️ **Impact** : ~40h par membre pour migration complète
- ✅ **Mitigation** : Migration progressive sur 12 mois, scripts d'assistance

#### Courbe d'Apprentissage
- ⚠️ **Impact** : 3h de formation par administrateur
- ✅ **Mitigation** : Documentation claire, exercices pratiques, certification

#### Résistance au Changement
- ⚠️ **Impact** : Confort avec l'existant, peur de la complexité
- ✅ **Mitigation** : Démonstrations, retours d'expérience, support dédié

---

## MÉTRIQUES DE SUCCÈS

### Indicateurs Quantitatifs (KPIs)

| Métrique | Valeur Actuelle | Cible 6 mois | Cible 12 mois |
|----------|-----------------|--------------|---------------|
| **Taux de conformité VMs** | 0% | 50% | 100% |
| **Admins formés** | 0/9 | 6/9 (67%) | 9/9 (100%) |
| **Admins certifiés** | 0/9 | 3/9 (33%) | 6/9 (67%) |
| **Temps onboarding nouvel admin** | 2 jours | 1 jour | 0.5 jour |
| **Erreurs de manipulation/mois** | ~10 | <5 | <2 |
| **Temps audit conformité** | 4h | 1h | 0.5h (automatisé) |

### Indicateurs Qualitatifs

- **Satisfaction administrateurs** : Sondage trimestriel (cible >4/5)
- **Qualité documentation** : Feedback utilisateurs (cible >4/5)
- **Facilité d'automatisation** : Nombre de playbooks réutilisables
- **Rayonnement externe** : Mentions dans communauté Proxmox

---

## RISQUES ET PLAN DE CONTINGENCE

### Risques Identifiés

#### Risque 1 : Faible Adoption
- **Probabilité** : Faible
- **Impact** : Élevé
- **Mitigation** : Obligation pour nouveaux déploiements, formation obligatoire
- **Contingence** : Accompagnement renforcé, exemples concrets

#### Risque 2 : Standard Trop Complexe
- **Probabilité** : Moyenne
- **Impact** : Moyen
- **Mitigation** : Formation de qualité, scripts d'assistance
- **Contingence** : Simplification v2.1 si feedback négatif massif

#### Risque 3 : Coût Migration Sous-Estimé
- **Probabilité** : Moyenne
- **Impact** : Moyen
- **Mitigation** : Timeline souple (12 mois), migration progressive
- **Contingence** : Extension deadline si justifié (vote)

#### Risque 4 : Obsolescence Rapide
- **Probabilité** : Faible
- **Impact** : Élevé
- **Mitigation** : Processus RFC, révision annuelle
- **Contingence** : Refonte v3.0 si changement technologique majeur

---

## PROCESSUS DE VALIDATION

### Étapes de Validation

#### 1. Révision Technique (Semaine 1-2)
- [ ] Lecture du package complet par tous les membres du Cercle Technique
- [ ] Identification des points d'amélioration
- [ ] Soumission des commentaires (forge Git ou Matrix)

#### 2. Intégration Retours (Semaine 3)
- [ ] Consolidation des retours par le responsable du standard
- [ ] Modifications du standard (version 2.0.1 si nécessaire)
- [ ] Publication version révisée

#### 3. Réunion de Validation (Semaine 4)
- [ ] Réunion du Cercle Technique (2-3 heures)
- [ ] Présentation du standard (30 min)
- [ ] Questions/Réponses (30 min)
- [ ] Tour de consentement (30 min)
- [ ] Formalisation de la résolution

#### 4. Vote de Consentement
- [ ] Chaque membre exprime son consentement ou objection
- [ ] Si objection : Discussion et recherche de solutions
- [ ] Si aucune objection bloquante : **Résolution adoptée**

### Critères de Consentement

Un membre donne son **consentement** s'il peut affirmer :

> "Je n'ai pas d'objection raisonnable et argumentée qui rendrait l'adoption de ce standard **nuisible** pour L'Alliance ou pour mon organisation."

**Note** : Le consentement n'est PAS l'unanimité. Un membre peut avoir des réserves mineures tout en donnant son consentement.

---

## SIGNATURES ET ADOPTION

### Proposition Initiale

**Proposé par :**
- **Daniel Mathieu** - Président, Chezlepro (czp-001)
- **Cercle Technique** - L'Alliance Boréale

**Date de proposition :** 21 octobre 2025

---

### Consentement des Membres

#### Chezlepro (czp-001)
- [ ] **Consentement** donné le : ________________
- [ ] **Objection** (détails ci-dessous) :

**Signature :** ________________________  
**Nom :** Daniel Mathieu  
**Fonction :** Président / Administrateur Système

---

#### Nuage Libre (nul-002)
- [ ] **Consentement** donné le : ________________
- [ ] **Objection** (détails ci-dessous) :

**Signature :** ________________________  
**Nom :** ______________________________  
**Fonction :** ______________________________

---

#### TechnoLibre (tli-003)
- [ ] **Consentement** donné le : ________________
- [ ] **Objection** (détails ci-dessous) :

**Signature :** ________________________  
**Nom :** ______________________________  
**Fonction :** ______________________________

---

### Validation Finale

**Résolution adoptée par consentement le :** _______________

**Validé par le Cercle Technique :**

**Signature du Facilitateur :**  
________________________  
**Nom :** ______________________________  
**Date :** ______________________________

---

## ANNEXES

### Annexe A : Documents de Référence

1. **Standard de Nomenclature v2.0** (60+ pages)
   - Fichier : `Standard_Nomenclature_v2.0.md`
   - Hash SHA256 : `[à calculer après finalisation]`

2. **Scripts de Migration** (6 scripts)
   - Répertoire : `scripts/`
   - Version : 1.0

3. **Guide de Formation** (40+ pages)
   - Fichier : `Guide_Formation_v2.0.md`

4. **Templates Ansible/Terraform**
   - Répertoires : `ansible/` et `terraform/`

### Annexe B : Calendrier Détaillé

| Date | Étape | Responsable | Statut |
|------|-------|-------------|--------|
| 21 oct 2025 | Proposition résolution | Daniel Mathieu | ✅ Fait |
| 28 oct 2025 | Révision technique | Cercle Technique | ⏳ En cours |
| 4 nov 2025 | Intégration retours | Daniel Mathieu | 🔜 À venir |
| 11 nov 2025 | Réunion validation | Tous membres | 🔜 À venir |
| 18 nov 2025 | Adoption officielle | Cercle Technique | 🔜 À venir |
| 1 déc 2025 | Début formations | Référents nomenclature | 🔜 À venir |
| 1 jan 2026 | Entrée en vigueur | Tous membres | 🔜 À venir |

### Annexe C : Contacts et Responsabilités

**Gardien du Standard (2025-2026) :**
- Nom : Daniel Mathieu
- Email : daniel@chezlepro.ca
- Matrix : @daniel:chezlepro.ca

**Support Technique :**
- Email : technique@alliance-boreale.ca
- Matrix : #nomenclature:alliance-boreale.ca

**Forge Git :**
- URL : https://forge.alliance-boreale.ca/standards/nomenclature
- Issues : https://forge.alliance-boreale.ca/standards/nomenclature/issues

---

## HISTORIQUE DES RÉVISIONS

| Version | Date | Auteur | Modifications |
|---------|------|--------|---------------|
| 1.0 | 21 oct 2025 | Daniel Mathieu | Proposition initiale |
| 1.1 | [future] | [nom] | [modifications après retours] |

---

**FIN DE LA RÉSOLUTION**

**Résolution n° 2025-TECH-001**  
**Standard de Nomenclature v2.0**  
**L'Alliance Boréale**

---

**« Un standard adopté par consentement est un standard respecté. »**