431 lines
No EOL
14 KiB
Markdown
431 lines
No EOL
14 KiB
Markdown
# 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é. »** |