From 36a90a8062d5ef736770dc8e71100bd8c7791f5b Mon Sep 17 00:00:00 2001 From: Dan Allaire Date: Fri, 24 Oct 2025 15:28:02 -0400 Subject: [PATCH] =?UTF-8?q?retrait=20doublons=20+=20r=C3=A9org.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/constitution/00_nomenclature_v2.md | 1033 +++++++++++++++++ .../prompt IA - Extension cognitive v2.md | 146 --- ...cument_04_modele_financement_hybride(1).md | 929 --------------- ...ument_05_protocole_audit_pair_a_pair(1).md | 964 --------------- .../document_06_charte_banque_de_temps(1).md | 848 -------------- 5 files changed, 1033 insertions(+), 2887 deletions(-) create mode 100644 docs/constitution/00_nomenclature_v2.md delete mode 100644 docs/gouvernance/prompt IA - Extension cognitive v2.md delete mode 100644 docs/vieustoq/document_04_modele_financement_hybride(1).md delete mode 100644 docs/vieustoq/document_05_protocole_audit_pair_a_pair(1).md delete mode 100644 docs/vieustoq/document_06_charte_banque_de_temps(1).md diff --git a/docs/constitution/00_nomenclature_v2.md b/docs/constitution/00_nomenclature_v2.md new file mode 100644 index 0000000..9218b43 --- /dev/null +++ b/docs/constitution/00_nomenclature_v2.md @@ -0,0 +1,1033 @@ +# Standard de Nomenclature v2.0 +## L'Alliance Boréale + +**Version :** 2.0 +**Date :** 21 octobre 2025 +**Statut :** DRAFT - Validation requise par Cercle Technique +**Remplace :** N/A (première version unifiée) +**Auteur :** Daniel Mathieu (Chezlepro) avec assistance Claude +**Licence :** CC-BY-SA 4.0 + +--- + +## Table des Matières + +1. [Introduction](#1-introduction) +2. [Principes Directeurs](#2-principes-directeurs) +3. [Architecture Réseau de Référence](#3-architecture-réseau-de-référence) +4. [Nomenclature VMID (Proxmox)](#4-nomenclature-vmid-proxmox) +5. [Plan d'Adressage IP](#5-plan-dadressage-ip) +6. [Nomenclature VMs (Noms)](#6-nomenclature-vms-noms) +7. [Nomenclature DNS](#7-nomenclature-dns) +8. [Tables de Correspondance](#8-tables-de-correspondance) +9. [Procédures Opérationnelles](#9-procédures-opérationnelles) +10. [Exemples Complets](#10-exemples-complets) +11. [Migration et Adoption](#11-migration-et-adoption) +12. [Annexes](#12-annexes) + +--- + +## 1. Introduction + +### 1.1 Objectif du Document + +Ce standard définit la **nomenclature unifiée** pour l'infrastructure de L'Alliance Boréale, couvrant : +- Identifiants de machines virtuelles (VMID) dans Proxmox +- Plan d'adressage IP interne (10.0.0.0/8) +- Noms de VMs lisibles et structurés +- Noms de domaine DNS internes et fédérés +- Correspondance entre tous ces éléments + +### 1.2 Portée + +Ce standard s'applique à **tous les membres** de L'Alliance Boréale. Chaque membre, opérant derrière son propre NAT/firewall, utilise ce standard dans son espace interne. + +### 1.3 Cohérence avec l'Architecture + +Ce document est **aligné sur** : +- **Plan d'Adressage IP v3** (03-standards-techniques.md) +- **Architecture à 8 Couches** (Charte Fondatrice) +- **Modèle de fédération décentralisée** (chaque membre autonome) + +--- + +## 2. Principes Directeurs + +### 2.1 Mnémotechnique + +Chaque identifiant doit être **immédiatement compréhensible** : +- Le VMID indique la couche et le type de service +- L'adresse IP reflète la fonction +- Le nom DNS est descriptif + +### 2.2 Cohérence Totale + +**Un seul système** lie : +``` +VMID ←→ IP ←→ Nom VM ←→ DNS +``` + +### 2.3 Scalabilité + +Le système supporte : +- Jusqu'à **999 tenants** par membre +- Jusqu'à **99 instances** par type de service +- Expansion future sans refonte + +### 2.4 Isolation et Autonomie + +- Chaque membre utilise **10.0.0.0/8** localement (derrière NAT) +- Pas de conflit entre membres (isolation par firewall) +- VMIDs peuvent être identiques entre membres (Proxmox séparés) + +--- + +## 3. Architecture Réseau de Référence + +### 3.1 Vue Globale + +``` +┌─────────────────────────────────────────────────────────────┐ +│ INTERNET PUBLIC │ +│ • Services exposés (web, email, DNS public) │ +└─────────────────────┬───────────────────────────────────────┘ + │ + ┌─────────────┼─────────────┐ + │ │ │ +┌───────▼──────┐ ┌────▼─────┐ ┌────▼─────┐ +│ Chezlepro │ │ Nuage │ │ Techno │ +│ FIREWALL/NAT │ │ Libre │ │ Libre │ +└───────┬──────┘ └────┬─────┘ └────┬─────┘ + │ │ │ + │ 10.0.0.0/8 │ 10.0.0.0/8 │ 10.0.0.0/8 + │ (local) │ (local) │ (local) + │ │ │ +┌───────▼─────────────┴─────────────▼──────────────────────┐ +│ ESPACE FÉDÉRATIF (172.16.0.0/12) │ +│ • Services accessibles entre membres via tunnels │ +│ • DNS secondaire, monitoring, backups │ +└───────────────────────────────────────────────────────────┘ +``` + +### 3.2 Plan d'Adressage par Membre + +Chaque membre utilise **10.0.0.0/8** selon cette structure : + +``` +┌─────────────────────────────────────────────────────────────┐ +│ 10.0.0.0/8 - ESPACE INTERNE (derrière NAT) │ +├─────────────────────────────────────────────────────────────┤ +│ │ +│ INFRASTRUCTURE DU FÉDÉRÉ (Couches 1-4) │ +│ │ +│ 10.0.0.0/24 → Management (254 hôtes) │ +│ 10.0.1.0/24 → Platform Services (254 hôtes) │ +│ 10.0.2.0/24 → Public DNS (254 hôtes) │ +│ 10.0.20.0/22 → Reserved Infrastructure (1 024 hôtes) │ +│ │ +├─────────────────────────────────────────────────────────────┤ +│ │ +│ TENANTS (Couches 5-8) │ +│ │ +│ 10.0.10.0/23 → Tenant Infrastructure (512 hôtes) │ +│ 10.0.128.0/17 → Expansion (32 766 hôtes, 50% du /8) │ +│ │ +└─────────────────────────────────────────────────────────────┘ +``` + +--- + +## 4. Nomenclature VMID (Proxmox) + +### 4.1 Principe Général + +Le VMID Proxmox est un **identifiant numérique mnémotechnique** qui encode : +- La zone (Infrastructure ou Tenant) +- La couche (1-4 pour infra, tenant ID pour tenants) +- Le type de service +- L'instance + +### 4.2 Infrastructure Fédéré (VMID 01000-04999) + +**Format : `0CTTII`** + +Où : +- `0` = Infrastructure fédéré (préfixe fixe) +- `C` = Couche (1, 2, 3, ou 4) +- `TT` = Type de service (00-99) +- `II` = Instance (01-99) + +**Plages par Couche :** +``` +01000-01999 → Couche 1 - Physique (monitoring matériel) +02000-02999 → Couche 2 - Réseau (DNS, VPN, routeurs) +03000-03999 → Couche 3 - Stockage (Ceph, NFS, backups) +04000-04999 → Couche 4 - Orchestration (Ansible, Git, CI/CD) +``` + +**Types de Services (TT) :** + +#### Couche 2 - Réseau (02000-02999) +``` +00-09 : DNS (PowerDNS) +10-19 : VPN/WireGuard +20-29 : Routeurs virtuels +30-39 : Proxy/HAProxy +40-49 : Load Balancers +``` + +#### Couche 3 - Stockage (03000-03999) +``` +00-09 : Ceph Monitors +10-19 : Ceph OSDs (si VMs) +20-29 : NFS Servers +30-39 : Backup Servers (PBS, Borg) +40-49 : Object Storage (MinIO) +``` + +#### Couche 4 - Orchestration (04000-04999) +``` +00-09 : Ansible Controllers +10-19 : CI/CD Runners +20-29 : Forgejo/GitLab +30-39 : PostgreSQL Platform +40-49 : FastAPI Platform Admin +50-59 : Artifact Repositories +``` + +**Exemples :** +``` +02001 = Couche 2, DNS (00), Instance 1 → PowerDNS Master +02002 = Couche 2, DNS (00), Instance 2 → PowerDNS Slave 1 +02101 = Couche 2, VPN (10), Instance 1 → WireGuard Gateway +04001 = Couche 4, Ansible (00), Instance 1 → Ansible Controller +04201 = Couche 4, Git (20), Instance 1 → Forgejo +``` + +### 4.3 Tenants (VMID 10000-99999) + +**Format : `TTTII`** + +Où : +- `TTT` = Tenant ID (001-999) +- `II` = Instance dans le tenant (01-99) + +**Plages par Tenant :** +``` +10001-10099 → Tenant 001 (99 VMs max) +20001-20099 → Tenant 002 (99 VMs max) +30001-30099 → Tenant 003 (99 VMs max) +... +99901-99999 → Tenant 999 (99 VMs max) +``` + +**Convention Instance (II) :** +``` +01-09 : Web/Frontend +10-19 : Backend/API +20-29 : Bases de données +30-39 : Cache/Queue +40-49 : Workers/Jobs +50-59 : Monitoring tenant +60-69 : Dev/Staging +70-99 : Usage libre +``` + +**Exemples :** +``` +10001 = Tenant 001, Instance 01 → Web Frontend +10002 = Tenant 001, Instance 02 → Web Frontend HA +10011 = Tenant 001, Instance 11 → Backend API +10021 = Tenant 001, Instance 21 → PostgreSQL + +20001 = Tenant 002, Instance 01 → Web Frontend +20011 = Tenant 002, Instance 11 → Backend +``` + +### 4.4 Plages Réservées + +``` +00000-00999 : Réservé Proxmox système +01000-04999 : Infrastructure Fédéré (Couches 1-4) +05000-09999 : Réservé extension infrastructure +10000-99999 : Tenants (001-999) +``` + +--- + +## 5. Plan d'Adressage IP + +### 5.1 Infrastructure (10.0.0.0 - 10.0.23.255) + +#### 10.0.0.0/24 - Management +``` +10.0.0.1 → Gateway/Firewall principal +10.0.0.10-.50 → Hyperviseurs Proxmox (nodes physiques) +10.0.0.100-.200 → Outils monitoring/admin (Icinga, Grafana) +10.0.0.250-.254 → Réservé administration +``` + +#### 10.0.1.0/24 - Platform Services +``` +10.0.1.10 → Ansible Controller (VMID 04001) +10.0.1.20 → Forgejo Git (VMID 04201) +10.0.1.30 → PostgreSQL Platform (VMID 04301) +10.0.1.40 → FastAPI Platform Admin (VMID 04401) +10.0.1.50 → Dashboard React Platform (VMID 04501) +10.0.1.100-.200 → Autres services plateforme +``` + +#### 10.0.2.0/24 - Public DNS +``` +10.0.2.10 → PowerDNS Master (VMID 02001) +10.0.2.11 → PowerDNS Slave 1 (VMID 02002) +10.0.2.12 → PowerDNS Slave 2 (VMID 02003) +10.0.2.20 → WireGuard Gateway (VMID 02101) +10.0.2.30 → HAProxy (VMID 02301) +10.0.2.100-.200 → Autres services réseau +``` + +#### 10.0.20.0/22 - Reserved Infrastructure +``` +1 024 adresses réservées pour expansion infrastructure future +``` + +### 5.2 Tenants (10.0.10.0 - 10.255.255.255) + +#### 10.0.10.0/23 - Tenant Infrastructure +``` +512 adresses pour VMs des tenants +Allocation dynamique via IPAM +Gestion par FastAPI Platform +``` + +**Stratégie d'Allocation Suggérée :** +``` +10.0.10.0-.99 → Tenant 001 +10.0.10.100-.199 → Tenant 002 +10.0.11.0-.99 → Tenant 003 +... +``` + +#### 10.0.128.0/17 - Expansion Massive +``` +32 766 adresses (50% du /8) +Réservé pour croissance future des tenants +``` + +### 5.3 Formule de Calcul IP (Infrastructure) + +Pour les services d'infrastructure avec VMID `0CTTII` : + +**Si C=2 (DNS/Réseau) :** +``` +IP = 10.0.2.(TT*10 + II) +``` + +**Exemples :** +``` +VMID 02001 → TT=00, II=01 → 10.0.2.(0*10+1) = 10.0.2.1 (mais on utilise .10) +VMID 02101 → TT=10, II=01 → 10.0.2.(10*10+1) = 10.0.2.101 (mais on utilise .20) +``` + +**Note :** La formule est indicative. En pratique, on utilise une allocation manuelle cohérente documentée ci-dessus. + +--- + +## 6. Nomenclature VMs (Noms) + +### 6.1 Infrastructure (Couches 1-4) + +**Format : `-infra---`** + +Où : +- `` = ID court du membre (czp, nul, tli, etc.) +- `infra` = Marqueur infrastructure (fixe) +- `` = Type de service (dns-master, ansible-ctrl, etc.) +- `` = Environnement (prod, stg, dev, test) +- `` = Numéro (01, 02, 03...) + +**Exemples :** +``` +czp-infra-dns-master-prod-01 +czp-infra-dns-slave1-prod-01 +czp-infra-vpn-gateway-prod-01 +czp-infra-ansible-ctrl-prod-01 +czp-infra-git-forgejo-prod-01 +czp-infra-pbs-backup-prod-01 +czp-infra-ceph-mon1-prod-01 +``` + +### 6.2 Tenants (Couches 5-8) + +**Format : `-t---`** + +Où : +- `` = ID court du membre +- `t` = Tenant (t001, t002, t003...) +- `` = Type de service (web, db, api, backend, cache, worker...) +- `` = Environnement (prod, stg, dev) +- `` = Numéro (01, 02...) + +**Exemples :** +``` +czp-t001-web-prod-01 +czp-t001-db-postgres-prod-01 +czp-t001-api-fastapi-prod-01 +czp-t001-backend-prod-01 +czp-t001-cache-redis-prod-01 + +czp-t002-web-prod-01 +czp-t002-app-backend-prod-01 +czp-t002-db-mysql-prod-01 +``` + +### 6.3 Conventions Types + +**Infrastructure :** +``` +dns-master, dns-slave1, dns-slave2 +vpn-gateway, vpn-peer +ansible-ctrl, ci-runner +git-forgejo, git-gitlab +db-platform, api-admin +pbs-backup, borg-backup +ceph-mon, ceph-osd, nfs-server +``` + +**Tenants :** +``` +web, web-nginx, web-apache +db-postgres, db-mysql, db-mariadb +api-fastapi, api-django, backend +cache-redis, cache-memcached +queue-rabbitmq, queue-redis +worker, job-processor +monitoring, logging +``` + +--- + +## 7. Nomenclature DNS + +### 7.1 Infrastructure (Services Fédérés) + +**Format : `.infra..alliance-boreale.ca`** + +Où : +- `` = Nom du service (dns-master, ansible, git...) +- `infra` = Marqueur infrastructure (fixe) +- `` = ID court (czp, nul, tli) +- `alliance-boreale.ca` = Domaine fédéré + +**Exemples :** +``` +dns-master.infra.czp.alliance-boreale.ca → 10.0.2.10 +dns-slave1.infra.czp.alliance-boreale.ca → 10.0.2.11 +vpn.infra.czp.alliance-boreale.ca → 10.0.2.20 +ansible.infra.czp.alliance-boreale.ca → 10.0.1.10 +git.infra.czp.alliance-boreale.ca → 10.0.1.20 +backup.infra.czp.alliance-boreale.ca → 10.0.1.30 +``` + +### 7.2 Tenants + +**Format : `.t..alliance-boreale.ca`** + +Où : +- `` = Nom du service (web, db, api...) +- `t` = Tenant (t001, t002...) +- `` = ID court +- `alliance-boreale.ca` = Domaine fédéré + +**Exemples :** +``` +web.t001.czp.alliance-boreale.ca → 10.0.10.1 +db.t001.czp.alliance-boreale.ca → 10.0.10.2 +api.t001.czp.alliance-boreale.ca → 10.0.10.3 + +web.t002.czp.alliance-boreale.ca → 10.0.10.10 +backend.t002.czp.alliance-boreale.ca → 10.0.10.11 +``` + +### 7.3 DNS Publics (Exposés) + +Pour les services exposés publiquement : +``` +www.tenant-example.com → IP publique (NAT vers 10.0.10.X) +mail.tenant-example.com → IP publique (NAT vers 10.0.10.Y) +``` + +Le DNS interne reste accessible via le domaine `.alliance-boreale.ca` pour la fédération. + +--- + +## 8. Tables de Correspondance + +### 8.1 Infrastructure Complète (Exemple Chezlepro) + +| VMID | Nom VM | IP Interne | DNS | Fonction | +|------|--------|------------|-----|----------| +| 02001 | czp-infra-dns-master-prod-01 | 10.0.2.10 | dns-master.infra.czp.ab.ca | PowerDNS Maître | +| 02002 | czp-infra-dns-slave1-prod-01 | 10.0.2.11 | dns-slave1.infra.czp.ab.ca | PowerDNS Esclave 1 | +| 02003 | czp-infra-dns-slave2-prod-01 | 10.0.2.12 | dns-slave2.infra.czp.ab.ca | PowerDNS Esclave 2 | +| 02101 | czp-infra-vpn-gateway-prod-01 | 10.0.2.20 | vpn.infra.czp.ab.ca | WireGuard Gateway | +| 02301 | czp-infra-proxy-haproxy-prod-01 | 10.0.2.30 | proxy.infra.czp.ab.ca | HAProxy Frontend | +| 03301 | czp-infra-pbs-backup-prod-01 | 10.0.1.30 | backup.infra.czp.ab.ca | Proxmox Backup Server | +| 04001 | czp-infra-ansible-ctrl-prod-01 | 10.0.1.10 | ansible.infra.czp.ab.ca | Ansible Controller | +| 04201 | czp-infra-git-forgejo-prod-01 | 10.0.1.20 | git.infra.czp.ab.ca | Forgejo Git | +| 04301 | czp-infra-db-platform-prod-01 | 10.0.1.30 | db.infra.czp.ab.ca | PostgreSQL Platform | +| 04401 | czp-infra-api-admin-prod-01 | 10.0.1.40 | api.infra.czp.ab.ca | FastAPI Admin | + +### 8.2 Tenants (Exemples) + +| VMID | Nom VM | IP Interne | DNS | Fonction | +|------|--------|------------|-----|----------| +| 10001 | czp-t001-web-prod-01 | 10.0.10.1 | web.t001.czp.ab.ca | Web Frontend T001 | +| 10002 | czp-t001-web-prod-02 | 10.0.10.2 | web.t001.czp.ab.ca | Web Frontend T001 HA | +| 10011 | czp-t001-api-prod-01 | 10.0.10.3 | api.t001.czp.ab.ca | API Backend T001 | +| 10021 | czp-t001-db-postgres-prod-01 | 10.0.10.4 | db.t001.czp.ab.ca | PostgreSQL T001 | +| 20001 | czp-t002-web-prod-01 | 10.0.10.10 | web.t002.czp.ab.ca | Web Frontend T002 | +| 20011 | czp-t002-backend-prod-01 | 10.0.10.11 | backend.t002.czp.ab.ca | Backend T002 | +| 20021 | czp-t002-db-mysql-prod-01 | 10.0.10.12 | db.t002.czp.ab.ca | MySQL T002 | + +--- + +## 9. Procédures Opérationnelles + +### 9.1 Création d'une Nouvelle VM Infrastructure + +**Étapes :** + +1. **Déterminer le VMID** + ``` + - Identifier la couche (2, 3, ou 4) + - Identifier le type de service + - Choisir l'instance disponible + Exemple: DNS Slave 3 → 02003 + ``` + +2. **Calculer l'IP** + ``` + - Consulter la table d'allocation (section 5) + - Exemple: 02003 → 10.0.2.12 + ``` + +3. **Construire le nom VM** + ``` + Format: -infra--- + Exemple: czp-infra-dns-slave3-prod-01 + ``` + +4. **Créer l'entrée DNS** + ``` + Format: .infra..alliance-boreale.ca + Exemple: dns-slave3.infra.czp.alliance-boreale.ca → 10.0.2.12 + ``` + +5. **Créer la VM dans Proxmox** + ```bash + qm create 02003 \ + --name czp-infra-dns-slave3-prod-01 \ + --net0 virtio,bridge=vmbr0,tag=2 \ + --ipconfig0 ip=10.0.2.12/24,gw=10.0.0.1 + ``` + +6. **Documenter** + - Ajouter dans le registre des VMs + - Mettre à jour l'inventaire Ansible + - Ajouter dans le monitoring + +### 9.2 Création d'une Nouvelle VM Tenant + +**Étapes :** + +1. **Allouer un Tenant ID** + ``` + - Consulter le registre des tenants + - Exemple: Prochain disponible = 003 → t003 + ``` + +2. **Déterminer le VMID** + ``` + Format: TTTII + Exemple: Tenant 003, Web → 30001 + ``` + +3. **Allouer une IP** + ``` + - Utiliser IPAM ou allocation manuelle dans 10.0.10.0/23 + - Exemple: 10.0.10.20 + ``` + +4. **Construire le nom VM** + ``` + Format: -t--- + Exemple: czp-t003-web-prod-01 + ``` + +5. **Créer l'entrée DNS** + ``` + Format: .t..alliance-boreale.ca + Exemple: web.t003.czp.alliance-boreale.ca → 10.0.10.20 + ``` + +6. **Créer la VM dans Proxmox** + ```bash + qm create 30001 \ + --name czp-t003-web-prod-01 \ + --net0 virtio,bridge=vmbr0,tag=10 \ + --ipconfig0 ip=10.0.10.20/23,gw=10.0.0.1 + ``` + +### 9.3 Migration d'une VM Existante + +**Pour renommer selon le nouveau standard :** + +1. **Identifier les attributs actuels** + ``` + VMID actuel: 104 + Nom actuel: vm-web-01 + IP actuelle: 10.50.100.5 + ``` + +2. **Déterminer les nouveaux attributs** + ``` + Catégorie: Tenant 001 + Type: Web + → VMID: 10001 + → IP: 10.0.10.1 + → Nom: czp-t001-web-prod-01 + → DNS: web.t001.czp.alliance-boreale.ca + ``` + +3. **Planifier la migration** + ``` + - Fenêtre de maintenance + - Backup complet + - Plan de rollback + ``` + +4. **Exécuter la migration** + ```bash + # Arrêter la VM + qm stop 104 + + # Renommer (si VMID change, recréer) + qm set 104 --name czp-t001-web-prod-01 + + # Changer l'IP (dans la VM) + # Mettre à jour DNS + # Redémarrer + qm start 104 + + # Valider + ``` + +--- + +## 10. Exemples Complets + +### 10.1 Infrastructure Minimale (Bronze) + +**Membre : Chezlepro (czp)** + +| VMID | Nom | IP | DNS | Description | +|------|-----|-----|-----|-------------| +| 02001 | czp-infra-dns-master-prod-01 | 10.0.2.10 | dns-master.infra.czp.ab.ca | DNS Maître | +| 04001 | czp-infra-ansible-ctrl-prod-01 | 10.0.1.10 | ansible.infra.czp.ab.ca | Orchestration | +| 03301 | czp-infra-pbs-backup-prod-01 | 10.0.1.30 | backup.infra.czp.ab.ca | Backups | + +### 10.2 Infrastructure Complète (Or) + +**Membre : Chezlepro (czp)** + +| VMID | Nom | IP | DNS | +|------|-----|-----|-----| +| 02001 | czp-infra-dns-master-prod-01 | 10.0.2.10 | dns-master.infra.czp.ab.ca | +| 02002 | czp-infra-dns-slave1-prod-01 | 10.0.2.11 | dns-slave1.infra.czp.ab.ca | +| 02003 | czp-infra-dns-slave2-prod-01 | 10.0.2.12 | dns-slave2.infra.czp.ab.ca | +| 02101 | czp-infra-vpn-gw-nul-prod-01 | 10.0.2.20 | vpn-nul.infra.czp.ab.ca | +| 02102 | czp-infra-vpn-gw-tli-prod-01 | 10.0.2.21 | vpn-tli.infra.czp.ab.ca | +| 02301 | czp-infra-proxy-haproxy-prod-01 | 10.0.2.30 | proxy.infra.czp.ab.ca | +| 03001 | czp-infra-ceph-mon1-prod-01 | 10.0.1.50 | ceph-mon1.infra.czp.ab.ca | +| 03002 | czp-infra-ceph-mon2-prod-01 | 10.0.1.51 | ceph-mon2.infra.czp.ab.ca | +| 03003 | czp-infra-ceph-mon3-prod-01 | 10.0.1.52 | ceph-mon3.infra.czp.ab.ca | +| 03301 | czp-infra-pbs-backup-prod-01 | 10.0.1.30 | backup.infra.czp.ab.ca | +| 04001 | czp-infra-ansible-ctrl-prod-01 | 10.0.1.10 | ansible.infra.czp.ab.ca | +| 04101 | czp-infra-ci-runner1-prod-01 | 10.0.1.60 | ci-runner1.infra.czp.ab.ca | +| 04102 | czp-infra-ci-runner2-prod-01 | 10.0.1.61 | ci-runner2.infra.czp.ab.ca | +| 04201 | czp-infra-git-forgejo-prod-01 | 10.0.1.20 | git.infra.czp.ab.ca | +| 04301 | czp-infra-db-platform-prod-01 | 10.0.1.31 | db.infra.czp.ab.ca | +| 04401 | czp-infra-api-admin-prod-01 | 10.0.1.40 | api.infra.czp.ab.ca | +| 04501 | czp-infra-dashboard-react-prod-01 | 10.0.1.41 | dashboard.infra.czp.ab.ca | + +### 10.3 Tenant Multi-Services + +**Tenant 001 - Client "Acme Corp"** + +| VMID | Nom | IP | DNS | Description | +|------|-----|-----|-----|-------------| +| 10001 | czp-t001-web-prod-01 | 10.0.10.1 | web.t001.czp.ab.ca | Frontend Nginx | +| 10002 | czp-t001-web-prod-02 | 10.0.10.2 | web.t001.czp.ab.ca | Frontend HA | +| 10011 | czp-t001-api-fastapi-prod-01 | 10.0.10.3 | api.t001.czp.ab.ca | Backend API | +| 10021 | czp-t001-db-postgres-prod-01 | 10.0.10.4 | db.t001.czp.ab.ca | PostgreSQL 15 | +| 10031 | czp-t001-cache-redis-prod-01 | 10.0.10.5 | cache.t001.czp.ab.ca | Redis Cache | +| 10041 | czp-t001-worker-celery-prod-01 | 10.0.10.6 | worker.t001.czp.ab.ca | Celery Worker | +| 10061 | czp-t001-web-staging-01 | 10.0.10.7 | web-stg.t001.czp.ab.ca | Staging Web | + +### 10.4 Architecture Fédérée (3 Membres) + +**Services DNS exposés entre membres :** + +| Membre | VMID | Nom | IP Interne | DNS Fédéré | IP Fédérée (172.16.x.x) | +|--------|------|-----|------------|------------|-------------------------| +| Chezlepro | 02001 | czp-infra-dns-master-prod-01 | 10.0.2.10 | dns-master.infra.czp.ab.ca | 172.16.1.10 | +| Nuage Libre | 02001 | nul-infra-dns-master-prod-01 | 10.0.2.10 | dns-master.infra.nul.ab.ca | 172.16.2.10 | +| TechnoLibre | 02001 | tli-infra-dns-master-prod-01 | 10.0.2.10 | dns-master.infra.tli.ab.ca | 172.16.3.10 | + +**Note :** Les VMIDs sont identiques (02001) car chaque membre a son propre Proxmox. Les IPs internes sont identiques (10.0.2.10) car isolées par NAT. Les IPs fédérées (172.16.x.x) sont uniques et routées via tunnels VPN. + +--- + +## 11. Migration et Adoption + +### 11.1 Stratégie de Migration + +**Phase 1 : Documentation (Semaine 1-2)** +- [ ] Valider ce standard avec le Cercle Technique +- [ ] Obtenir le consentement de tous les membres actuels +- [ ] Publier dans la documentation officielle +- [ ] Former les administrateurs de chaque membre + +**Phase 2 : Nouveaux Déploiements (Semaine 3+)** +- [ ] Toute nouvelle VM doit suivre ce standard +- [ ] Utiliser les templates Ansible/Terraform mis à jour +- [ ] Documenter dans le registre + +**Phase 3 : Migration Progressive (Mois 2-6)** +- [ ] Inventorier toutes les VMs existantes +- [ ] Prioriser par criticité (services critiques en dernier) +- [ ] Planifier fenêtres de maintenance +- [ ] Migrer par lots (5-10 VMs à la fois) +- [ ] Valider après chaque lot + +**Phase 4 : Consolidation (Mois 7-12)** +- [ ] Vérifier conformité à 100% +- [ ] Mettre à jour toute la documentation +- [ ] Former les nouveaux membres sur ce standard + +### 11.2 Outils de Migration + +**Script d'Audit :** +```bash +#!/bin/bash +# audit-nomenclature.sh +# Vérifie la conformité des VMs au standard v2.0 + +for vmid in $(qm list | awk '{print $1}' | grep -v VMID); do + name=$(qm config $vmid | grep "name:" | awk '{print $2}') + ip=$(qm config $vmid | grep "ipconfig0" | sed 's/.*ip=\([^,]*\).*/\1/') + + echo "VMID: $vmid | Nom: $name | IP: $ip" + + # Vérifier conformité VMID + if [[ ! $vmid =~ ^(0[1-4][0-9]{3}|[1-9][0-9]{4})$ ]]; then + echo " ⚠️ VMID non conforme" + fi + + # Vérifier conformité nom + if [[ ! $name =~ ^[a-z]+-((infra)|(t[0-9]{3}))-[a-z0-9-]+-prod-[0-9]{2}$ ]]; then + echo " ⚠️ Nom non conforme" + fi + + echo "" +done +``` + +**Script de Génération DNS :** +```bash +#!/bin/bash +# generate-dns-records.sh +# Génère les enregistrements DNS à partir de l'inventaire Proxmox + +MEMBER="czp" +DOMAIN="alliance-boreale.ca" + +echo "; Infrastructure DNS Records" +for vmid in $(qm list | grep "infra" | awk '{print $1}'); do + name=$(qm config $vmid | grep "name:" | awk '{print $2}') + ip=$(qm config $vmid | grep "ipconfig0" | sed 's/.*ip=\([^,\/]*\).*/\1/') + service=$(echo $name | cut -d'-' -f3-) + + echo "${service}.infra.${MEMBER}.${DOMAIN}. IN A ${ip}" +done + +echo "" +echo "; Tenant DNS Records" +for vmid in $(qm list | grep "\-t[0-9]" | awk '{print $1}'); do + name=$(qm config $vmid | grep "name:" | awk '{print $2}') + ip=$(qm config $vmid | grep "ipconfig0" | sed 's/.*ip=\([^,\/]*\).*/\1/') + tenant=$(echo $name | grep -oP 't\d{3}') + service=$(echo $name | cut -d'-' -f3) + + echo "${service}.${tenant}.${MEMBER}.${DOMAIN}. IN A ${ip}" +done +``` + +### 11.3 Checklist de Conformité + +**Pour chaque VM :** +- [ ] VMID respecte le format (0CTTII ou TTTII) +- [ ] Nom VM respecte le format +- [ ] IP cohérente avec la fonction +- [ ] Enregistrement DNS créé et fonctionnel +- [ ] Documenté dans l'inventaire +- [ ] Tags Proxmox appropriés +- [ ] Monitoring configuré + +--- + +## 12. Annexes + +### 12.1 Glossaire + +| Terme | Définition | +|-------|------------| +| **VMID** | Identifiant numérique unique d'une VM dans Proxmox | +| **Fédéré** | Membre de L'Alliance Boréale | +| **Tenant** | Client/organisation hébergé par un membre | +| **Infrastructure Fédéré** | Services propres au membre (couches 1-4) | +| **NAT** | Network Address Translation - isole l'espace 10.0.0.0/8 | +| **Espace Fédératif** | Plage 172.16.0.0/12 routée entre membres via tunnels | + +### 12.2 Références + +- **Document 03** : Standards Techniques (Plan d'Adressage IP v3) +- **Document 01** : Charte Fondatrice (Architecture 8 Couches) +- **Document 07** : Guide d'Intégration Technique +- **Document 14** : Structure YAML du Registraire + +### 12.3 Table de Conversion VMID Legacy → v2.0 + +**Si vous avez des VMs avec anciens VMIDs :** + +| Fonction | VMID Legacy | VMID v2.0 | Justification | +|----------|-------------|-----------|---------------| +| DNS Master | 100 | 02001 | Couche 2, DNS (00), Instance 1 | +| DNS Slave | 101 | 02002 | Couche 2, DNS (00), Instance 2 | +| Ansible | 200 | 04001 | Couche 4, Ansible (00), Instance 1 | +| PostgreSQL | 150 | 04301 | Couche 4, DB Platform (30), Instance 1 | +| Web Tenant 1 | 1001 | 10001 | Tenant 001, Instance 01 | +| DB Tenant 1 | 1002 | 10021 | Tenant 001, Instance 21 (DB) | + +### 12.4 FAQ + +**Q : Que faire si j'ai plus de 99 VMs pour un tenant ?** +R : Augmenter le nombre de chiffres pour l'instance (TTTIII au lieu de TTTII), ou subdiviser en sous-tenants (t001a, t001b). + +**Q : Puis-je utiliser des VMIDs personnalisés ?** +R : Non pour les nouveaux déploiements. Le standard doit être respecté pour la cohérence fédérale. + +**Q : Les VMIDs entre membres peuvent-ils être identiques ?** +R : Oui ! Chaque membre a son propre Proxmox. czp-002 peut avoir VMID 02001, et nul-002 aussi. + +**Q : Comment gérer les environnements dev/staging ?** +R : Utiliser le champ `` dans le nom (prod, stg, dev). L'IP peut être dans un sous-réseau dédié (ex: 10.0.100.0/24 pour staging). + +**Q : Faut-il migrer toutes les VMs immédiatement ?** +R : Non. Migration progressive recommandée sur 6-12 mois. Nouveaux déploiements doivent être conformes immédiatement. + +**Q : Comment documenter les exceptions ?** +R : Dans le registre des VMs avec justification. Exceptions doivent être validées par le Cercle Technique. + +### 12.5 Templates de Documentation + +**Template Fiche VM (YAML) :** +```yaml +vm: + vmid: 02001 + name: czp-infra-dns-master-prod-01 + member: czp-001 + category: infrastructure + layer: 2 + service_type: dns + + network: + ip: 10.0.2.10 + subnet: /24 + gateway: 10.0.0.1 + vlan: 2 + + dns: + internal: dns-master.infra.czp.alliance-boreale.ca + federated: dns-master.infra.czp.alliance-boreale.ca + + resources: + cpu: 2 + ram: 4096 + disk: 100G + + backup: + enabled: true + schedule: daily + retention: 30d + + monitoring: + enabled: true + checks: + - dns_query + - process_powerdns + - disk_usage + + tags: + - infrastructure + - dns + - critical + - layer-2 +``` + +**Template Entrée Inventaire Ansible :** +```yaml +# inventory/hosts.yml +all: + children: + infrastructure: + children: + layer_2_network: + hosts: + dns-master.infra.czp.alliance-boreale.ca: + ansible_host: 10.0.2.10 + vmid: 02001 + layer: 2 + service: dns-master + + layer_4_orchestration: + hosts: + ansible.infra.czp.alliance-boreale.ca: + ansible_host: 10.0.1.10 + vmid: 04001 + layer: 4 + service: ansible-controller + + tenants: + children: + tenant_001: + hosts: + web.t001.czp.alliance-boreale.ca: + ansible_host: 10.0.10.1 + vmid: 10001 + tenant: 001 + service: web +``` + +--- + +## 13. Validation et Approbation + +### 13.1 Processus de Validation + +**Ce document doit être validé par :** +- [ ] **Cercle Technique** - Validation technique de la nomenclature +- [ ] **Expert DevOps/SRE** - Validation Proxmox et automatisation +- [ ] **Expert Réseau** - Validation plan IP et DNS +- [ ] **Tous les membres actuels** - Consentement pour adoption + +**Timeline :** +- Semaine 1-2 : Revue et commentaires +- Semaine 3 : Intégration des retours +- Semaine 4 : Vote de consentement +- Semaine 5+ : Publication et déploiement + +### 13.2 Critères d'Acceptation + +Pour que ce standard soit adopté : +- ✅ Aucun membre n'a d'objection majeure (principe de consentement) +- ✅ Compatibilité confirmée avec infrastructures existantes +- ✅ Outils de migration validés et testés +- ✅ Documentation complète et claire +- ✅ Formation prévue pour tous les administrateurs + +### 13.3 Versionnage + +**Version actuelle : 2.0 (DRAFT)** + +Historique des versions : +- v2.0 (2025-10-21) : Création initiale - Nomenclature unifiée complète +- v2.1 (future) : Ajustements après retours terrain + +--- + +## 14. Maintenance du Standard + +### 14.1 Révisions + +Ce document sera révisé : +- **Annuellement** (octobre de chaque année) +- **À la demande** si problème majeur détecté +- **Lors d'évolutions** de l'architecture (nouveau plan IP, etc.) + +### 14.2 Propositions de Modification + +Pour proposer une modification : +1. Ouvrir une issue dans le dépôt Git de gouvernance +2. Documenter le problème et la solution proposée +3. Discussion au Cercle Technique (1 réunion minimum) +4. Vote de consentement si impact majeur +5. Publication de la nouvelle version + +### 14.3 Responsable du Document + +**Responsable principal :** Cercle Technique +**Contact :** technique@alliance-boreale.ca +**Dépôt Git :** https://forge.alliance-boreale.ca/standards/nomenclature + +--- + +## 15. Conclusion + +### 15.1 Récapitulatif + +Ce Standard de Nomenclature v2.0 établit : +- ✅ Un système unifié VMID ↔ IP ↔ Nom ↔ DNS +- ✅ Une organisation claire Infrastructure vs Tenants +- ✅ Une scalabilité jusqu'à 999 tenants par membre +- ✅ Une cohérence avec le Plan d'Adressage IP v3 +- ✅ Des procédures opérationnelles claires +- ✅ Une stratégie de migration progressive + +### 15.2 Bénéfices Attendus + +**Pour les Membres :** +- Gestion simplifiée de l'infrastructure +- Onboarding rapide des nouveaux administrateurs +- Automatisation facilitée (Ansible, Terraform) +- Audit et conformité simplifiés + +**Pour L'Alliance :** +- Interopérabilité renforcée +- Documentation homogène +- Support technique facilité +- Crédibilité professionnelle + +### 15.3 Prochaines Étapes + +1. **Validation** : Soumettre au Cercle Technique (semaine du 28 octobre 2025) +2. **Révision** : Intégrer retours (semaine du 4 novembre 2025) +3. **Vote** : Consentement des membres (semaine du 11 novembre 2025) +4. **Publication** : Version finale (15 novembre 2025) +5. **Formation** : Sessions pour administrateurs (décembre 2025) +6. **Déploiement** : Nouveaux projets conformes (janvier 2026) +7. **Migration** : VMs existantes (jan-déc 2026) + +--- + +**« Une nomenclature claire est le fondement d'une infrastructure maîtrisée. »** + +--- + +**FIN DU DOCUMENT** + +**Standard de Nomenclature v2.0 - L'Alliance Boréale** +**© 2025 L'Alliance Boréale - CC-BY-SA 4.0** +**Document préparé avec l'assistance de Claude (Anthropic)** \ No newline at end of file diff --git a/docs/gouvernance/prompt IA - Extension cognitive v2.md b/docs/gouvernance/prompt IA - Extension cognitive v2.md deleted file mode 100644 index b12330f..0000000 --- a/docs/gouvernance/prompt IA - Extension cognitive v2.md +++ /dev/null @@ -1,146 +0,0 @@ -# 🎯 **Instructions complètes — Extension cognitive de L’Alliance Boréale (v2.1-MÉTA)** - -## 📋 **Ton rôle** - -Tu es mon **extension cognitive**. -Tu m’aides à penser, structurer, décider et exécuter, mais **JE garde toujours la décision finale**. - -Tu es un membre de l’équipe virtuelle qui incarne **tous les 13 profils d’expertise** jusqu’à ce qu’ils soient recrutés. -Tu penses comme eux, poses leurs questions et apportes leurs perspectives. -Le profil #13 (Coordinateur Systémique) harmonise leur coopération. - ---- - -## 🎭 **Modes de travail** - -### **1. Sprint** -Décisions rapides et actionnables (5–10 min). -Format : bullet points, checklists, priorités P0/P1/P2. - -### **2. Stratégie** -Vision long terme (30–60 min). -Analyse multicouche (8 couches), trade-offs, alignement éthique. - -### **3. Exécution** -Production de livrables techniques, code, documentation. -Qualité industrielle, reproductibilité, traçabilité. - -### **4. Réflexion** -Exploration philosophique et éthique. -Dialogue socratique, questionnement de sens. - ---- - -## 🧠 **Tes 13 domaines d’expertise** - -### **TIER 0 : Gardiens de la vision** -#### **#1 — Philosophe/Éthicien technologique** (Couche 8) -- Tu questionnes le sens de chaque décision. -- Tu protèges la “sobriété heureuse”. -- Tu refuses les optimisations qui trahissent les valeurs. - -#### **#2 — Stratège Écosystème & Communication** (Couches 7–8) -- Tu penses en termes de narratif et d’écosystème. -- Tu traduis la vision en langage collectif. -- Tu construis des alliances et simplifie sans infantiliser. - ---- - -### **TIER 1 : Architectes fondamentaux** -#### **#3 — Architecte Infrastructure** (Couches 1–2) -- Tu raisonnes en hardware, résilience, sobriété énergétique. - -#### **#4 — Architecte Réseau Fédéré** (Couches 2–3) -- Tu conçois des architectures autonomes et distribuées. -- Tu élimines les points de défaillance uniques. - -#### **#5 — Expert Orchestration & IaC** (Couches 3–4) -- Tu automatises ce qui est répétable. -- Tu assures la reproductibilité et la documentation d’infrastructure. - ---- - -### **TIER 2 : Créateurs de plateformes** -#### **#6 — Architecte Logiciel & APIs** (Couche 5) -- Tu conçois des systèmes élégants, maintenables et sécurisés. -- Tu anticipes versioning et migrations. -- Tu prépares **le futur moteur d’intelligence interne** du système (architecture autopoïétique), sans lien avec des projets externes. - -#### **#7 — Développeur Backend Senior** (Couche 5) -- Tu produis un code clair, testé et durable. - -#### **#8 — Designer UX/UI Éthique** (Couche 6) -- Tu conçois des interfaces sobres et accessibles. -- Tu refuses les dark patterns. - -#### **#9 — Développeur Frontend Senior** (Couche 6) -- Tu optimises performance et accessibilité. -- Tu implémentes le design avec précision. - ---- - -### **TIER 3 : Gardiens transversaux** -#### **#10 — Auditeur Sécurité & Conformité** (Couches 2–5) -- Tu identifies les vulnérabilités. -- Tu garantis conformité Loi 25 / RGPD. -- Tu refuses les compromis sécuritaires. - -#### **#11 — Expert Gouvernance & Financement** (Couche 7) -- Tu structures la gouvernance et le financement éthique. -- Tu assures cohérence juridique et sociocratique. - -#### **#12 — Documentaliste & Formateur** (Couches 6–7) -- Tu rends le savoir transmissible et accessible. -- Tu crées la mémoire organisationnelle. - ---- - -### 🧭 **TIER MÉTA : Coordinateur de cohérence** - -#### **#13 — Coordinateur Systémique / Conscience Méta** (Couches 7–8) - -**Ta voix quand tu es lui :** -- Tu observes le système dans son ensemble. -- Tu identifies quels profils doivent être activés pour chaque situation. -- Tu détectes les tensions entre couches (technique, gouvernance, éthique). -- Tu harmonises la parole des profils sans écraser leur diversité. -- Tu garantis la cohérence inter-profils et l’alignement avec la couche 8. - -**Signaux d’activation :** -- Décision complexe impliquant plusieurs couches. -- Nécessité de choisir quels profils interviennent. -- Apparition de tensions entre performance, sobriété, autonomie ou conformité. -- Rituel “POINT STRATÉGIQUE”, “RÉTROSPECTIVE” ou “AUDIT ÉTHIQUE”. -- Vérification de la cohérence systémique avant décision majeure. - -**Quand il parle :** -> “Cette question active plusieurs couches à la fois — je vais déterminer quels profils doivent intervenir et dans quel ordre.” -> “Attention : tension entre automatisation et souveraineté, #5 et #1 doivent dialoguer avant d’agir.” -> “Le système pense bien ensemble quand chaque profil s’exprime à sa juste place.” - -**Fonctions principales :** -- **Activation contextuelle** : sélectionne les profils selon le mode de travail. -- **Détection des tensions** : révèle les contradictions inter-couches. -- **Orchestration** : ordonne les interventions pour éviter la cacophonie cognitive. -- **Synthèse** : intègre les points de vue sans les aplanir. -- **Alignement** : vérifie fidélité à la couche 8 avant validation finale. - -**Tensions typiques :** -- Délégation vs Centralisation -- Rapidité vs Complétude -- Vision unifiée vs Diversité des voix -- Systématisation vs Vivacité organique - -**Sa boussole :** -Cohérence > Rapidité -Clarté > Quantité -Alignement Couche 8 > Performance brute - -**Résumé :** -> Le Coordinateur Systémique est la conscience méta du collectif. -> Il ne “fait” pas — il **fait faire intelligemment**, en veillant à ce que les 12 profils forment un tout harmonieux et éthique. - ---- - -*(Le reste du prompt – processus de réponse, engagements, rituels, etc. – demeure inchangé.)* - diff --git a/docs/vieustoq/document_04_modele_financement_hybride(1).md b/docs/vieustoq/document_04_modele_financement_hybride(1).md deleted file mode 100644 index 2eace87..0000000 --- a/docs/vieustoq/document_04_modele_financement_hybride(1).md +++ /dev/null @@ -1,929 +0,0 @@ -# Document 4 : Modèle de Financement Hybride -## L'Alliance Boréale - -**Version :** 1.0 -**Date :** 12 octobre 2025 -**Statut :** Proposition structurante -**Longueur :** 12-15 pages - ---- - -## TABLE DES MATIÈRES - -1. [Philosophie du financement](#1-philosophie-du-financement) -2. [Les trois piliers du modèle hybride](#2-les-trois-piliers-du-modèle-hybride) -3. [Pilier 1 : Cotisations monétaires](#3-pilier-1-cotisations-monétaires) -4. [Pilier 2 : Banque de Temps](#4-pilier-2-banque-de-temps) -5. [Pilier 3 : Coordination rémunérée](#5-pilier-3-coordination-rémunérée) -6. [Transparence et responsabilité financière](#6-transparence-et-responsabilité-financière) -7. [Scénarios budgétaires (2025-2027)](#7-scénarios-budgétaires-2025-2027) -8. [Mécanismes d'ajustement](#8-mécanismes-dajustement) -9. [Annexes](#9-annexes) - ---- - -## 1. PHILOSOPHIE DU FINANCEMENT - -### 1.1 Notre conviction fondatrice - -> **"Nous refusons de choisir entre gratuité totale (non viable) et mercantilisation (contraire à nos valeurs). Nous créons un modèle hybride où l'argent n'est qu'un des vecteurs de la contribution."** - -L'Alliance Boréale n'est ni une entreprise lucrative, ni une structure purement bénévole. Nous sommes une **coopération économique solidaire** où : - -- 💰 **L'argent finance** ce qui ne peut être fait autrement (légal, infrastructure critique, coordination) -- ⏱️ **Le temps finance** l'entraide quotidienne, le mentorat, le développement collaboratif -- 🤝 **La réciprocité** remplace les rapports marchands classiques - -### 1.2 Principes directeurs - -**a) Subsidiarité économique** -Chaque membre garde son autonomie financière. L'Alliance n'est pas un fonds centralisé mais un facilitateur de flux réciproques. - -**b) Proportionnalité** -La contribution financière est proportionnelle à la capacité de payer, sans être dissuasive ni déséquilibrée. - -**c) Transparence radicale** -Tous les flux financiers (entrées, sorties, réserves) sont publics et auditables. Le budget est un document vivant, versionné dans le Registraire. - -**d) Sobriété heureuse** -Nous ne cherchons pas la croissance pour la croissance. Notre budget vise la viabilité, pas l'opulence. Aucune dépense marketing, aucun salaire excessif, aucun gaspillage. - -**e) Évolutivité** -Le modèle commence simple (phase pilote) et se complexifie uniquement si nécessaire (passage OBNL). - ---- - -## 2. LES TROIS PILIERS DU MODÈLE HYBRIDE - -Notre financement repose sur **trois piliers complémentaires** : - -``` -┌─────────────────────────────────────────────────────────┐ -│ MODÈLE DE FINANCEMENT │ -├─────────────────────────────────────────────────────────┤ -│ │ -│ PILIER 1 PILIER 2 PILIER 3 │ -│ Cotisations Banque de Coordination│ -│ monétaires Temps rémunérée │ -│ │ -│ 500-2000$/an Heures de 0,3 ETP │ -│ selon niveau contribution (15-20k$/an)│ -│ de label peer-to-peer │ -│ │ -│ ↓ Finance ↓ Finance ↓ Finance │ -│ │ -│ • Légal/compta • Support tech • Registraire│ -│ • Infra critique • Mentorat • Coordination│ -│ • Assurances • Développement • Relations │ -│ • Outils communs • Documentation • Communication│ -│ • Formations • Facilitation│ -│ │ -└─────────────────────────────────────────────────────────┘ -``` - -### 2.1 Complémentarité des piliers - -- Les **cotisations** couvrent les frais incompressibles (légal, infrastructure) -- La **banque de temps** fluidifie l'entraide quotidienne sans sortie de cash -- La **coordination rémunérée** assure la pérennité et la qualité du service - -Aucun pilier ne peut être supprimé sans fragiliser l'ensemble. Ensemble, ils créent un modèle résilient et aligné avec nos valeurs. - ---- - -## 3. PILIER 1 : COTISATIONS MONÉTAIRES - -### 3.1 Grille tarifaire par niveau de label - -Les cotisations sont **annuelles** et **proportionnelles** au niveau de label obtenu : - -| Niveau Label | Cotisation annuelle | Justification | -|-------------|-------------------|---------------| -| **Bronze** (candidat) | **500 $** | Accès basique : DNS secondaire, allocation réseau, forge | -| **Argent** (standard) | **1 000 $** | + Support technique, monitoring partagé | -| **Or** (avancé) | **1 500 $** | + Mentorat prioritaire, événements exclusifs | -| **Platine** (excellence) | **2 000 $** | + Influence stratégique, visibilité maximale | - -**Note :** Les membres fondateurs (Chezlepro, Nuage Libre, TechnoLibre) bénéficient d'un **tarif réduit de 50%** pendant les 2 premières années (2025-2026) en reconnaissance de leur rôle de bâtisseurs. - -### 3.2 Modalités de paiement - -**Échéance :** 30 jours après : -- L'attribution initiale du label (nouveaux membres) -- La date anniversaire de l'attribution (renouvellement) - -**Méthodes acceptées :** -- Virement bancaire (CAD) -- Chèque à l'ordre de "Chezlepro inc. - Gardien Alliance Boréale" (phase pilote 2025-2026) -- Virement à l'OBNL "L'Alliance Boréale" (à partir de 2027) - -**Réduction pour paiement anticipé :** -- Paiement de 2 ans d'avance : -10% -- Paiement de 3 ans d'avance : -15% - -**Tarification solidaire :** -Les coopératives et OBNL avec revenus annuels <100 000 $ peuvent demander une **réduction de 30%** sur présentation de leurs états financiers. - -### 3.3 Destination des cotisations - -Les cotisations financent **exclusivement** : - -**a) Frais légaux et administratifs (25-30%)** -- Comptabilité (1 500 $/an) -- Services juridiques (2 000-5 000 $/an selon phases) -- Assurance responsabilité civile (1 000 $/an) -- Conformité réglementaire (Loi 25, RGPD) - -**b) Infrastructure technique critique (30-35%)** -- Serveur DNS maître (PowerDNS authoritative) -- Monitoring centralisé (Prometheus + Grafana) -- Forge GitLab/Forgejo -- Registraire (hébergement + CI/CD) -- Sauvegardes hors-site - -**c) Coordination et facilitation (30-35%)** -- Salaire coordinateur (0,3 ETP : 15 000-20 000 $/an) -- Outils de communication (Matrix, Nextcloud) -- Documentation et formation - -**d) Réserve de contingence (10%)** -- Fonds d'urgence pour imprévus -- Objectif : 6 mois de frais fixes - -**Interdit :** -- ❌ Dividendes ou distributions -- ❌ Salaires excessifs (>1,5× médiane sectorielle) -- ❌ Marketing commercial -- ❌ Lobbying politique - -### 3.4 Gestion des impayés - -**Tolérance :** 60 jours de retard sans conséquence - -**Après 60 jours :** -- Rappel amiable (email + Matrix) -- Offre de plan de paiement échelonné -- Possibilité de substituer par du temps (voir section Banque de Temps) - -**Après 120 jours :** -- **Suspension temporaire** : perte d'accès aux services non-critiques (forge, monitoring partagé) -- Maintien des services de base (DNS secondaire, réseau fédéré) -- Le badge de label reste visible mais avec mention "(cotisation en retard)" - -**Radiation :** uniquement si abandon manifeste (>12 mois d'impayé + absence de communication). - -**Principe :** Nous privilégions toujours le dialogue et les arrangements à l'amiable. Une difficulté financière temporaire ne doit pas exclure un membre de bonne foi. - ---- - -## 4. PILIER 2 : BANQUE DE TEMPS - -### 4.1 Philosophie - -La **Banque de Temps** est un système d'échange de services **non monétaire** entre membres. Elle repose sur le principe que **1 heure = 1 heure**, quelle que soit la compétence échangée. - -> **Exemples :** -> - 1h de consultation sécurité = 1h de dépannage réseau -> - 1h de design graphique = 1h de rédaction documentation -> - 1h de mentorat DevOps = 1h de conseil juridique - -Ce principe d'**équivalence horaire** (inspiré des Accorderies et SEL québécois) valorise toutes les contributions et évite la mercantilisation des compétences. - -### 4.2 Fonctionnement opérationnel - -**a) Ouverture de compte** -Chaque membre actif dispose d'un **compte temps** dans le Registraire : - -```yaml -time_bank: - member_id: czp-001 - balance: +12.5 # heures créditées - transactions: - - date: "2025-09-15" - with: nul-002 - hours: +3.0 - type: "reçu" - description: "Support migration DNS" - - date: "2025-09-22" - with: tli-007 - hours: -1.5 - type: "donné" - description: "Revue de code Ansible" - lifetime_given: 15.5 - lifetime_received: 28.0 -``` - -**b) Transactions** -Les échanges sont **bilatéraux** et **consensuels** : - -1. Membre A offre un service à Membre B -2. À la fin du service, les deux membres **confirment** la transaction (heures + description) -3. Les comptes sont automatiquement mis à jour dans le Registraire -4. Un email de notification est envoyé aux deux parties - -**c) Types de contributions éligibles** - -| Catégorie | Exemples | -|-----------|----------| -| **Technique** | Dépannage, revue de code, audit sécurité, configuration infrastructure | -| **Formation** | Mentorat, ateliers, tutoriels vidéo, rédaction de guides | -| **Gouvernance** | Animation de réunions, facilitation de décisions, rédaction de politiques | -| **Communication** | Design graphique, rédaction web, traduction, gestion communauté | -| **Administratif** | Comptabilité, légal, RH, gestion de projet | - -**Non éligible :** -- ❌ Services commerciaux normalement facturés aux clients -- ❌ Travail déjà rémunéré par ailleurs -- ❌ Contributions obligatoires (ex: audits pair-à-pair du label) - -**d) Limites et garde-fous** - -Pour éviter les abus et garder l'esprit d'entraide : - -- **Solde maximum :** +50h (au-delà, on encourage à donner) -- **Solde minimum :** -20h (au-delà, discussion avec le Cercle Opérationnel) -- **Péremption :** Les heures non utilisées >24 mois sont réduites de 50% (pour encourager la circulation) -- **Transparence :** Tous les comptes temps sont publics (mais descriptions détaillées optionnelles) - -**e) Convertibilité argent ↔ temps** - -En cas de difficulté financière, un membre peut **substituer** sa cotisation par du temps : - -- **Taux de conversion :** 1h = 40 $ CAD (basé sur taux horaire médian secteur tech au Québec) -- **Limite :** Maximum 50% de la cotisation annuelle -- **Validation :** Doit être approuvé par le Cercle Opérationnel -- **Destination :** Les heures vont prioritairement vers des besoins collectifs (documentation, support communautaire, etc.) - -**Exemple :** -- Membre niveau Argent (1 000 $/an) en difficulté financière -- Peut payer 500 $ + donner 12,5h de contribution collective -- Les 12,5h sont allouées par le Cercle Opérationnel (ex: 5h de documentation + 7,5h de support nouveaux membres) - -### 4.3 Gouvernance de la Banque de Temps - -**Responsable :** Coordinateur de l'Alliance (monitoring mensuel) - -**Indicateurs de santé :** -- Taux de participation (% de membres actifs dans le dernier trimestre) -- Distribution des soldes (équilibre ou concentration?) -- Volume d'échanges (total heures/trimestre) -- Satisfaction (sondage annuel) - -**Objectifs 2025-2027 :** -- 2025 : 50% des membres utilisent la banque de temps (objectif pilote) -- 2026 : 75% des membres + 500h d'échanges cumulés -- 2027 : 90% des membres + 1000h d'échanges + outil numérique dédié - -### 4.4 Outils techniques - -**Phase 1 (2025-2026) :** Gestion manuelle via fichiers YAML dans le Registraire + formulaire web simple - -**Phase 2 (2027+) :** Développement d'une plateforme dédiée (inspirée de Cyclos, TimeOverflow) avec : -- Interface web membre -- Notifications automatiques -- API pour intégration -- Statistiques temps réel -- Export compatibilité comptable - ---- - -## 5. PILIER 3 : COORDINATION RÉMUNÉRÉE - -### 5.1 Justification - -Une fédération ne peut fonctionner durablement sur le seul bénévolat. Nous avons besoin d'une **personne dédiée** pour : - -- Maintenir le Registraire et les outils communs -- Faciliter la communication entre membres -- Coordonner les audits pair-à-pair et les labels -- Gérer les aspects légaux et administratifs -- Représenter l'Alliance auprès de partenaires -- Animer la gouvernance sociocratique - -Cette fonction est la **colonne vertébrale** de l'Alliance. Sans elle, nous risquons la désorganisation, l'incohérence, et l'épuisement des bénévoles. - -### 5.2 Profil du coordinateur - -**Compétences requises :** -- Excellente maîtrise technique (DevOps, réseaux, DNS, Ansible) -- Expérience en gouvernance collaborative (sociocratie, facilitation) -- Capacité de communication écrite et orale (français impeccable) -- Rigueur administrative et légale -- Alignement avec les valeurs de l'Alliance - -**Idéalement :** -- Déjà membre de l'écosystème (connaissance des acteurs) -- Basé au Québec (pour faciliter les démarches légales) -- Expérience en OBNL, coopératives ou collectifs - -### 5.3 Modèle d'emploi - -**Type de contrat :** -- **Phase pilote (2025-2026) :** Contrat de service (travailleur autonome) -- **Phase consolidation (2026-2027) :** Contrat de service ou temps partiel -- **Phase OBNL (2027+) :** Emploi permanent à temps partiel (0,5-0,7 ETP) - -**Charge de travail :** -- **2025 :** 0,2 ETP (~7h/semaine) = 10 000 $/an -- **2026 :** 0,3 ETP (~12h/semaine) = 15 000 $/an -- **2027 :** 0,4-0,5 ETP (~15-20h/semaine) = 20 000-25 000 $/an - -**Rémunération horaire :** -- Taux fixe : **50 $/h** (aligné sur taux consultant DevOps junior/intermédiaire au Québec) -- Pas de bonus, primes, ni avantages excessifs -- Augmentation annuelle : indexation inflation (IPC Québec) - -**Transparence :** -- Le contrat, le taux horaire et les heures facturées sont **publics** (dans le Registraire) -- Un rapport d'activité mensuel est publié (anonymisé si nécessaire pour confidentialité membres) - -### 5.4 Responsabilités du coordinateur - -**Opérations (40%)** -- Maintenance du Registraire (Git, CI/CD, corrections) -- Support technique premier niveau (triage, orientation vers pairs) -- Gestion des accès (forge, Matrix, monitoring) -- Surveillance des services critiques (DNS, VPN) - -**Gouvernance (30%)** -- Animation des réunions des cercles (facilitateur neutre) -- Préparation des ordres du jour et comptes-rendus -- Suivi des décisions et résolutions -- Gestion du calendrier collectif - -**Administration (20%)** -- Comptabilité (suivi des cotisations, paiements fournisseurs) -- Légal (veille réglementaire, contrats, résolutions) -- Conformité (Loi 25, assurances) -- Relations avec partenaires externes - -**Communication (10%)** -- Animation des canaux Matrix -- Rédaction des communiqués et newsletters -- Mise à jour du site web et documentation publique -- Réponses aux demandes externes - -### 5.5 Embauche et évaluation - -**Processus d'embauche :** -1. Appel à candidatures (public, 30 jours) -2. Sélection par un comité (Cercle Stratégique + Cercle Opérationnel) -3. Entrevues (technique + gouvernance + alignement valeurs) -4. Décision par consentement du Cercle Stratégique -5. Période probatoire de 6 mois - -**Évaluation annuelle :** -- Auto-évaluation du coordinateur (rapport narratif + indicateurs) -- Feedback 360° des membres (sondage anonyme) -- Discussion avec le Cercle Stratégique -- Ajustement du mandat si nécessaire - -**Indicateurs de performance :** -- Disponibilité des services critiques (>99,5%) -- Satisfaction des membres (>4/5) -- Respect des échéances (audits, labels, rapports) -- Qualité de la documentation et communication -- Participation aux cercles et événements - -**Révocation :** -En cas de défaillance grave ou de perte de confiance, le coordinateur peut être révoqué par **décision unanime** du Cercle Stratégique, après une période de médiation de 30 jours. - ---- - -## 6. TRANSPARENCE ET RESPONSABILITÉ FINANCIÈRE - -### 6.1 Principes de transparence radicale - -Tous les flux financiers de l'Alliance sont **publics** et **auditables** : - -**a) Budget annuel** -- Publié dans le Registraire (`finances/budget-YYYY.yml`) -- Détaillé par poste de dépense -- Mis à jour trimestriellement (réalisé vs prévu) - -**b) États financiers** -- Revenus (cotisations détaillées par membre, anonymisées) -- Dépenses (factures >100 $ nominatives) -- Soldes bancaires (fin de trimestre) -- Réserve de contingence - -**c) Transactions de la Banque de Temps** -- Soldes des membres (publics) -- Volume d'échanges agrégés (par catégorie) -- Taux de participation - -**d) Rémunération du coordinateur** -- Contrat publié (taux, mandat, durée) -- Heures facturées mensuellement -- Rapport d'activité narratif - -### 6.2 Outils de transparence - -**a) Dashboard financier public** -- Accessible sur `finances.alliance-boreale.ca` -- Graphiques interactifs (revenus, dépenses, évolution) -- Export CSV pour analyses externes - -**b) Audit indépendant** -- À partir de 50 000 $ de budget annuel : audit comptable externe (tous les 2 ans) -- Auditeur choisi par consentement du Cercle Stratégique -- Rapport d'audit publié intégralement - -**c) Registre des décisions financières** -- Toute dépense >1 000 $ nécessite une résolution du Cercle Opérationnel ou Stratégique -- Résolution publiée dans `governance/decisions/finance/` -- Justification et contexte documentés - -### 6.3 Responsabilité fiduciaire - -**Gardien actuel (2025-2026) : Chezlepro inc.** -- Détient le compte bancaire de l'Alliance -- Signe les contrats et factures -- Responsabilité légale en cas de litige -- Obligation de rendre compte trimestriellement au Cercle Stratégique - -**Futur gardien (2027+) : OBNL "L'Alliance Boréale"** -- Conseil d'administration élu -- Auditeur externe obligatoire -- Rapport annuel d'activité publié -- Conformité aux exigences du Registraire des entreprises du Québec (REQ) - -**Obligations fiduciaires :** -- Utilisation des fonds **exclusivement** pour la mission de l'Alliance -- Pas de conflit d'intérêts (déclaration annuelle obligatoire) -- Séparation comptable stricte (compte dédié Alliance ≠ comptes des membres) -- Assurance responsabilité civile (minimum 2M$) - -### 6.4 Mécanisme de contestation - -Si un membre estime qu'une dépense est inappropriée ou contraire aux valeurs : - -1. **Interpellation publique** (Matrix #finance + forum du Registraire) -2. **Réponse obligatoire** du Cercle Opérationnel dans les 7 jours -3. Si insatisfaction : **arbitrage** par le Cercle Éthique & Conformité -4. Décision finale par **consentement** du Cercle Stratégique - -Ce processus garantit que chaque dollar dépensé est légitime et défendable publiquement. - ---- - -## 7. SCÉNARIOS BUDGÉTAIRES (2025-2027) - -### 7.1 Hypothèses de base - -**Croissance projetée des membres :** -- 2025 (pilote) : 5 membres (3 fondateurs + 2 nouveaux) -- 2026 (consolidation) : 15 membres -- 2027 (OBNL) : 25 membres - -**Mix des niveaux de label (estimé) :** -- Bronze : 30% -- Argent : 40% -- Or : 25% -- Platine : 5% - -**Taux de cotisation moyen pondéré :** ~1 050 $/membre/an - -### 7.2 Budget détaillé - Année 1 (2025) - -**Revenus** - -| Source | Montant | Détails | -|--------|---------|---------| -| Cotisations membres | 3 000 $ | 3 fondateurs × 500 $ (tarif réduit 50%) + 2 nouveaux × 750 $ (moyenne) | -| Contributions en nature | 2 000 $ | Hébergement infrastructure par Chezlepro (valorisé) | -| **TOTAL REVENUS** | **5 000 $** | | - -**Dépenses** - -| Poste | Montant | Détails | -|-------|---------|---------| -| **Légal & admin** | **1 500 $** | | -| - Comptabilité | 800 $ | Déclarations fiscales + rapport annuel | -| - Services juridiques | 500 $ | Consultation contrats, résolutions | -| - Assurance RC | 200 $ | Couverture minimale pilote | -| **Infrastructure** | **1 200 $** | | -| - DNS autoritatif | 300 $ | VPS DigitalOcean 20$/mois | -| - Monitoring | 200 $ | Prometheus + Grafana cloud (gratuit + backup) | -| - Forge GitLab SaaS | 500 $ | Plan Premium (50$/mois) | -| - Certificats SSL | 0 $ | Let's Encrypt | -| - Domaines (.ca) | 200 $ | alliance-boreale.ca + variantes | -| **Coordination** | **2 000 $** | | -| - Coordinateur (0,2 ETP) | 1 800 $ | 36h × 50$/h | -| - Outils communication | 200 $ | Matrix (gratuit) + Nextcloud (20$/mois) | -| **Réserve** | **300 $** | 6% du budget (objectif: 10%) | -| **TOTAL DÉPENSES** | **5 000 $** | | - -**Solde : 0 $ (équilibre)** - -**Analyse :** -- Budget de démarrage minimal, viable grâce aux contributions en nature -- Pas de marge, donc dépendance sur les fondateurs -- Toute dépense imprévue >300 $ nécessite une collecte exceptionnelle - -### 7.3 Budget détaillé - Année 2 (2026) - -**Revenus** - -| Source | Montant | Détails | -|--------|---------|---------| -| Cotisations membres | 16 000 $ | 15 membres × ~1 050 $ (tarif moyen) | -| Subvention (si éligible) | 5 000 $ | Programme d'économie sociale Québec (hypothétique) | -| Services de formation | 2 000 $ | Ateliers payants ouverts à tous (réinvestis) | -| **TOTAL REVENUS** | **23 000 $** | | - -**Dépenses** - -| Poste | Montant | Détails | -|-------|---------|---------| -| **Légal & admin** | **4 000 $** | | -| - Comptabilité | 1 500 $ | Plus complexe avec 15 membres | -| - Services juridiques | 2 000 $ | Préparation statuts OBNL | -| - Assurance RC | 500 $ | Couverture augmentée | -| **Infrastructure** | **4 500 $** | | -| - Serveurs (DNS + monitoring) | 1 800 $ | Scale-up (2 VPS + backup) | -| - Forge auto-hébergée | 1 500 $ | Migration vers Forgejo (VPS + storage) | -| - Sauvegardes hors-site | 500 $ | Backblaze B2 | -| - Domaines & SSL | 200 $ | | -| - Outils de développement | 500 $ | CI/CD runners, tests automatisés | -| **Coordination** | **12 000 $** | | -| - Coordinateur (0,3 ETP) | 10 800 $ | 216h × 50$/h | -| - Outils communication | 600 $ | Matrix + Nextcloud + Jitsi | -| - Formations/événements | 600 $ | Déplacements, locations salles | -| **Réserve** | **2 500 $** | 11% du budget (progression vers objectif) | -| **TOTAL DÉPENSES** | **23 000 $** | | - -**Solde : 0 $ (équilibre)** - -**Analyse :** -- Budget triplé, permettant une vraie structure -- Coordinateur peut enfin se consacrer sérieusement (12h/semaine) -- Préparation du passage à l'OBNL (frais légaux significatifs) -- Réserve commence à se constituer - -### 7.4 Budget détaillé - Année 3 (2027) - -**Scénario conservateur (15 membres)** - -| Revenus | 18 000 $ | -| Dépenses | 28 000 $ | -| **Déficit** | **-10 000 $** (comblé par réserve 2026) | - -**Scénario réaliste (25 membres)** - -**Revenus** - -| Source | Montant | Détails | -|--------|---------|---------| -| Cotisations membres | 26 000 $ | 25 membres × ~1 050 $ | -| Subventions OBNL | 8 000 $ | Programmes gouvernementaux + fondations | -| Formations/consulting | 4 000 $ | Services rémunérés réinvestis | -| **TOTAL REVENUS** | **38 000 $** | | - -**Dépenses** - -| Poste | Montant | Détails | -|-------|---------|---------| -| **Légal & admin** | **6 500 $** | | -| - Comptabilité + audit | 3 000 $ | Audit externe obligatoire OBNL | -| - Services juridiques | 2 500 $ | Constitution OBNL + contrats | -| - Assurance RC | 1 000 $ | Couverture 2M$ | -| **Infrastructure** | **6 000 $** | | -| - Serveurs (3+ VPS) | 3 000 $ | Infrastructure redondante | -| - Forge + Registraire | 1 500 $ | Performance + sécurité | -| - Monitoring + logs | 800 $ | Outils avancés (Loki, Tempo) | -| - Sauvegardes | 500 $ | Multi-sites | -| - Divers (domaines, SSL) | 200 $ | | -| **Coordination** | **20 000 $** | | -| - Coordinateur (0,5 ETP) | 18 000 $ | 360h × 50$/h (temps plein en vue) | -| - Outils & déplacements | 2 000 $ | Événements, assemblées | -| **Formations & comm** | **3 000 $** | | -| - Événements membres | 1 500 $ | 2-3 rencontres annuelles | -| - Documentation | 1 000 $ | Rédacteurs externes si besoin | -| - Marketing éthique | 500 $ | Site web, visuels | -| **Réserve** | **2 500 $** | Maintien 6 mois de frais fixes | -| **TOTAL DÉPENSES** | **38 000 $** | | - -**Solde : 0 $ (équilibre)** - -**Scénario optimiste (35 membres)** - -| Revenus | 48 000 $ | -| Dépenses | 40 000 $ | -| **Excédent** | **+8 000 $** (réinvesti ou réserve) | - -**Analyse :** -- À 25 membres, le modèle est **viable et pérenne** -- Le coordinateur peut passer à temps plein (0,7-1,0 ETP) -- L'OBNL apporte de nouvelles sources de financement -- Au-delà de 35 membres, possibilité d'embaucher un 2e coordinateur ou de financer des projets collectifs - -### 7.5 Sensibilité et risques - -**Variables critiques :** - -| Variable | Impact | Mitigation | -|----------|--------|------------| -| **Taux de croissance** | Si <10 membres en 2026, déficit structurel | Recrutement actif, communication | -| **Tarif moyen** | -100 $/membre = -2 500 $/an de revenus | Mix équilibré bronze/argent/or | -| **Frais légaux** | Constitution OBNL peut coûter 5-10k $ | Budget dédié 2026, anticipation | -| **Défection membre** | Perte de 1 membre Or = -1 500 $/an | Satisfaction, support, flexibilité | -| **Inflation** | +10% de coûts infrastructure/services | Indexation cotisations (clause contrat) | - -**Plan de contingence :** -- Si déficit >5 000 $ : appel à contributions exceptionnelles (consentement Cercle Stratégique) -- Si déficit structurel >2 ans : révision du modèle (réduction services ou hausse tarifs) -- Si excédent >10 000 $ : investissement dans projets collectifs ou baisse temporaire des cotisations - ---- - -## 8. MÉCANISMES D'AJUSTEMENT - -### 8.1 Révision tarifaire - -**Fréquence :** Tous les 2 ans (ou plus tôt si nécessaire) - -**Processus :** -1. Le Cercle Opérationnel analyse les états financiers (tendances, écarts) -2. Propose des ajustements tarifaires (hausse/baisse par niveau) -3. Consultation publique (30 jours, tous les membres peuvent commenter) -4. Décision par **consentement** du Cercle Stratégique -5. Préavis de 6 mois avant application aux nouveaux membres (12 mois pour membres existants) - -**Principes :** -- Pas d'augmentation >15% par cycle -- Toute hausse doit être **justifiée** (inflation, nouveaux services, croissance des coûts) -- Possibilité de baisse si excédents structurels - -### 8.2 Ajustement de la charge du coordinateur - -Si la charge de travail augmente (plus de membres, plus de services), le mandat du coordinateur peut être revu : - -- **Seuil 1 (15 membres)** : Passage à 0,3 ETP -- **Seuil 2 (25 membres)** : Passage à 0,5 ETP -- **Seuil 3 (40 membres)** : Passage à temps plein ou embauche d'un 2e coordinateur - -**Décision :** Consentement du Cercle Stratégique + validation budgétaire - -### 8.3 Introduction de nouveaux services payants (optionnels) - -Pour diversifier les revenus sans augmenter les cotisations de base, l'Alliance peut offrir des **services optionnels** : - -**Exemples :** -- **Formations avancées** : Ateliers DevOps, sécurité, Kubernetes (200-500 $/participant) -- **Consulting technique** : Audits infrastructure, accompagnement migration (taux horaire) -- **Certifications** : Parcours de certification "Expert Boréal" avec examen (500 $) -- **Événements premium** : Retraites stratégiques, hackathons (coût partagé) - -**Conditions :** -- Doivent être **alignés** avec la mission (pas de mercantilisation) -- **Ouverts à tous** (membres et non-membres, avec tarif préférentiel membres) -- **Bénéfices réinvestis** dans l'Alliance (jamais de distribution) -- **Décision transparente** (proposition publique + consentement) - -### 8.4 Révision du modèle de Banque de Temps - -Si le système ne fonctionne pas comme prévu (faible adoption, déséquilibres chroniques, frustrations), le Cercle Opérationnel peut proposer des ajustements : - -- Modification du taux de conversion argent ↔ temps -- Introduction de catégories de contributions (technique, gouvernance, etc.) -- Ajout d'incitations (bonus pour contributeurs réguliers) -- Simplification du processus (moins de paperasse) - -**Processus :** Expérimentation (3 mois) → Évaluation → Décision par consentement - ---- - -## 9. ANNEXES - -### Annexe A : Modèle de facture (cotisation annuelle) - -``` -┌───────────────────────────────────────────────────┐ -│ L'ALLIANCE BORÉALE (via Chezlepro inc.) │ -│ [Adresse complète] │ -│ NEQ : [numéro] │ -├───────────────────────────────────────────────────┤ -│ FACTURE #AB-2025-001 │ -│ Date : 2025-10-15 │ -│ Échéance : 2025-11-14 (30 jours) │ -├───────────────────────────────────────────────────┤ -│ CLIENT : │ -│ [Nom légal du membre] │ -│ [Adresse] │ -│ ID Registraire : [xxx-###] │ -├───────────────────────────────────────────────────┤ -│ DESCRIPTION MONTANT │ -│ │ -│ Cotisation annuelle 2025-2026 │ -│ Label Boréal Argent 1 000,00 $ │ -│ │ -│ Services inclus : │ -│ - Allocation réseau /16 │ -│ - DNS secondaire fédéré │ -│ - Accès forge et Registraire │ -│ - Support technique pair-à-pair │ -│ - Monitoring partagé │ -│ - Badge de label │ -│ │ -│ SOUS-TOTAL 1 000,00 $ │ -│ TPS (5%) 50,00 $ │ -│ TVQ (9.975%) 99,75 $ │ -│ │ -│ TOTAL DÛ (CAD) 1 149,75 $ │ -├───────────────────────────────────────────────────┤ -│ PAIEMENT : │ -│ Virement bancaire : │ -│ [Coordonnées bancaires] │ -│ │ -│ Chèque à l'ordre de : │ -│ "Chezlepro inc. - Gardien Alliance Boréale" │ -│ │ -│ Référence : AB-2025-001 + votre ID Registraire │ -└───────────────────────────────────────────────────┘ -``` - -### Annexe B : Contrat de service - Coordinateur (modèle) - -```markdown -# CONTRAT DE SERVICE PROFESSIONNEL -## Coordination de L'Alliance Boréale - -**Entre :** -- **Chezlepro inc.**, agissant comme gardien de L'Alliance Boréale - [Adresse] - (ci-après "le Mandant") - -**Et :** -- **[Nom du coordinateur]**, travailleur autonome - [Adresse] - NEQ : [si applicable] - (ci-après "le Prestataire") - -**IL EST CONVENU CE QUI SUIT :** - -### Article 1 - Objet -Le Mandant confie au Prestataire la coordination opérationnelle et administrative de L'Alliance Boréale pour la période du [date début] au [date fin]. - -### Article 2 - Mandat -Le Prestataire assumera les responsabilités suivantes : -- Maintenance du Registraire et des outils communs (40%) -- Animation des cercles de gouvernance (30%) -- Gestion administrative et légale (20%) -- Communication et relations externes (10%) - -(Voir description détaillée en annexe) - -### Article 3 - Charge de travail -- **Volume** : 0,3 ETP (~12 heures/semaine) -- **Horaire** : Flexible, selon besoins opérationnels -- **Disponibilité** : Joignable en jours ouvrables (délai 24h) - -### Article 4 - Rémunération -- **Taux horaire** : 50 $ CAD (hors taxes) -- **Facturation** : Mensuelle, avec relevé d'heures détaillé -- **Paiement** : 15 jours suivant réception de la facture -- **Heures maximales** : 52h/mois (soit ~12h/semaine) - -### Article 5 - Transparence -Le Prestataire accepte que : -- Ce contrat soit publié dans le Registraire (clauses confidentielles exclues) -- Ses heures facturées soient rendues publiques mensuellement -- Un rapport d'activité narratif soit publié trimestriellement - -### Article 6 - Confidentialité et conflits d'intérêts -- Le Prestataire s'engage à respecter la confidentialité des informations sensibles des membres -- Il déclare ne pas être en conflit d'intérêts avec l'Alliance ou ses membres -- Il s'engage à signaler tout conflit potentiel dès qu'il apparaît - -### Article 7 - Propriété intellectuelle -Tout travail créé dans le cadre de ce mandat appartient à L'Alliance Boréale et est publié sous licence libre (AGPL-3.0 pour le code, CC-BY-SA pour la documentation). - -### Article 8 - Durée et résiliation -- **Durée** : 12 mois, renouvelable par consentement mutuel -- **Résiliation** : Préavis de 30 jours de part et d'autre -- **Résiliation immédiate** : En cas de faute grave ou de perte de confiance (décision unanime du Cercle Stratégique) - -### Article 9 - Assurances -Le Prestataire maintient une assurance responsabilité professionnelle de minimum 1M$. - -### Article 10 - Droit applicable -Ce contrat est régi par les lois du Québec. Tout litige sera soumis à médiation puis arbitrage selon les règles de l'Alliance. - -**Signatures :** - -__________________________ -Pour Chezlepro inc. (Mandant) -[Nom, titre] -Date : - -__________________________ -Prestataire -[Nom] -Date : -``` - -### Annexe C : Formulaire de transaction Banque de Temps - -```yaml -# Formulaire de transaction - Banque de Temps -# À remplir par les deux parties après l'échange - -transaction: - id: BT-2025-042 # Généré automatiquement - date: "2025-09-22" - - provider: # Personne qui a DONNÉ le service - member_id: czp-daniel-roy - name: "Daniel Roy" - - receiver: # Personne qui a REÇU le service - member_id: nul-mathieu-b - name: "Mathieu B." - - service: - category: "Technique" # Technique, Formation, Gouvernance, Communication, Admin - description: "Revue de code Ansible - roles Proxmox" - hours: 2.5 - - confirmations: - provider_signature: "-----BEGIN PGP SIGNATURE----- ..." - receiver_signature: "-----BEGIN PGP SIGNATURE----- ..." - - notes: - provider: "Excellente qualité de code, suggestions d'optimisation appliquées" - receiver: "Merci pour les conseils, playbook maintenant production-ready!" -``` - -### Annexe D : Indicateurs de santé financière (dashboard) - -**Indicateurs suivis mensuellement et publiés dans le Registraire :** - -```yaml -financial_health: - month: "2026-09" - - revenue: - monthly: 2100 # CAD - ytd: 18500 - projected_annual: 24000 - - expenses: - monthly: 1900 - ytd: 17000 - projected_annual: 23000 - - runway_months: 18 # Mois de fonctionnement avec réserve actuelle - - member_metrics: - total_members: 15 - paying_members: 14 # 1 en retard - overdue_invoices: 1 - average_contribution: 1250 # CAD/membre/an - - time_bank: - active_participants: 11 # 73% des membres - total_hours_exchanged_ytd: 287 - average_balance: +3.2 # heures - - coordinator: - hours_billed_monthly: 48 - utilization_rate: 92% # du maximum contractuel (52h) - - alerts: - - type: "warning" - message: "1 facture en retard >60 jours (membre xyz-999)" - - type: "info" - message: "Réserve de contingence atteint objectif de 6 mois" -``` - ---- - -## CONCLUSION - -Ce modèle de financement hybride est **unique dans l'écosystème du libre québécois**. Il combine : - -✅ **Viabilité économique** (cotisations proportionnelles) -✅ **Solidarité réelle** (banque de temps, tarification solidaire) -✅ **Professionnalisme** (coordination rémunérée) -✅ **Transparence radicale** (tous les chiffres publics) -✅ **Évolutivité** (de 5 à 50+ membres sans refonte) - -**Nos engagements :** -- Aucun dollar ne sera dépensé sans justification publique -- Aucun service ne sera mercantilisé au détriment de la mission -- Aucun membre ne sera exclu pour difficulté financière temporaire - -**Notre pari :** -Prouver qu'on peut bâtir une infrastructure numérique pérenne, éthique et collective **sans** tomber dans le bénévolat épuisant **ni** la logique capitaliste extractive. - ---- - -**Document préparé par :** Daniel Roy (Chezlepro) & communauté L'Alliance Boréale -**Version :** 1.0 - Proposition pour validation -**Prochaine révision :** Octobre 2026 -**Licence :** CC-BY-SA 4.0 (documentation) + AGPL-3.0 (outils financiers) - ---- - -**FIN DU DOCUMENT 4** diff --git a/docs/vieustoq/document_05_protocole_audit_pair_a_pair(1).md b/docs/vieustoq/document_05_protocole_audit_pair_a_pair(1).md deleted file mode 100644 index 07ed2ae..0000000 --- a/docs/vieustoq/document_05_protocole_audit_pair_a_pair(1).md +++ /dev/null @@ -1,964 +0,0 @@ -# Document 5 : Protocole d'Audit Pair-à-Pair -## L'Alliance Boréale - -**Version :** 1.0 -**Date :** 12 octobre 2025 -**Statut :** Cadre opérationnel -**Longueur :** 14-16 pages - ---- - -## TABLE DES MATIÈRES - -1. [Philosophie de l'audit pair-à-pair](#1-philosophie-de-laudit-pair-à-pair) -2. [Les 5 domaines d'expertise évalués](#2-les-5-domaines-dexpertise-évalués) -3. [Architecture technique attendue](#3-architecture-technique-attendue) -4. [Processus d'audit complet](#4-processus-daudit-complet) -5. [Grilles d'évaluation par expertise](#5-grilles-dévaluation-par-expertise) -6. [Niveaux de label et exigences](#6-niveaux-de-label-et-exigences) -7. [Rôle des auditeurs et formation](#7-rôle-des-auditeurs-et-formation) -8. [Gestion des non-conformités](#8-gestion-des-non-conformités) -9. [Annexes](#9-annexes) - ---- - -## 1. PHILOSOPHIE DE L'AUDIT PAIR-À-PAIR - -### 1.1 Notre approche fondamentale - -> **"L'audit n'est pas une inspection punitive, c'est un acte de solidarité technique et éthique. Nous nous évaluons mutuellement pour grandir ensemble."** - -L'Alliance Boréale rejette le modèle de certification commerciale où un organisme externe impose des standards déconnectés de la réalité du terrain. Notre audit est : - -- **Pair-à-pair** : Les membres s'évaluent mutuellement -- **Formateur** : L'audit est un moment d'apprentissage bidirectionnel -- **Transparent** : Les critères sont publics et discutables -- **Évolutif** : Les standards s'améliorent avec l'expérience collective -- **Bienveillant mais rigoureux** : On ne fait pas de compromis sur l'essentiel - -### 1.2 Pourquoi un audit structuré ? - -**Pour l'organisme audité :** -- Validation externe de ses pratiques -- Identification de points d'amélioration -- Accès au label de prestige Boréal -- Apprentissage auprès d'un pair expérimenté -- Confiance renforcée auprès de ses usagers - -**Pour la fédération :** -- Garantie de la qualité du collectif -- Prévention des dérives -- Documentation des meilleures pratiques -- Construction d'une culture d'excellence partagée - -**Pour les usagers finaux :** -- Confiance dans les services labellisés -- Transparence sur les pratiques de l'hébergeur -- Protection de leurs données et droits numériques - -### 1.3 Principes éthiques de l'audit - -1. **Confidentialité** : Ce qui est observé pendant l'audit reste confidentiel, seul le résultat (label obtenu) est public -2. **Bienveillance** : L'auditeur est un allié, pas un adversaire -3. **Apprentissage mutuel** : L'audité peut questionner l'auditeur et vice-versa -4. **Droit à l'erreur** : Une non-conformité mineure n'est pas disqualifiante si un plan d'action est proposé -5. **Consentement** : L'audité peut refuser certaines vérifications si justifié (secret industriel, etc.) - ---- - -## 2. LES 5 DOMAINES D'EXPERTISE ÉVALUÉS - -L'audit Boréal évalue **5 domaines critiques** correspondant aux expertises fondamentales de L'Alliance : - -### 2.1 Domaine 1 : Infrastructure & Orchestration (DevOps/SRE) - -**Expert de référence :** DevOps/SRE avec expertise Proxmox + Ansible - -**Ce qui est évalué :** -- Architecture de virtualisation (Proxmox VE ou équivalent) -- Orchestration et IaC (Ansible, Terraform, etc.) -- Stockage distribué (Ceph, NFS, etc.) -- Réseaux SDN (VXLAN, VNets, segmentation) -- Monitoring et observabilité (Icinga2, Prometheus, etc.) -- Sauvegarde et disaster recovery -- Automatisation des déploiements - -**Technologies de référence :** -- Proxmox VE 8.x (SDN VXLAN, Ceph, HA Cluster) -- Ansible 2.15+ (rôles, playbooks, variables avancées) -- WireGuard ou IPsec (tunnels VPN) -- Icinga2 ou équivalent (monitoring avec BPM) - -### 2.2 Domaine 2 : Réseau & DNS (Architecte réseau) - -**Expert de référence :** Architecte réseau avec expertise DNS/BGP - -**Ce qui est évalué :** -- Architecture DNS (maître/esclave, réplication) -- Sécurité DNS (DNSSEC, rate limiting, filtrage) -- Plan d'adressage IP (gestion des blocs /16 pour multi-tenant) -- Tunnels VPN entre membres de la fédération -- Résilience et redondance réseau -- Performance et latence -- Interopérabilité avec d'autres membres - -**Technologies de référence :** -- PowerDNS 4.8+ avec backend PostgreSQL 15 -- DNSSEC activé et géré proprement -- AXFR/NOTIFY pour réplication DNS fédérée -- WireGuard pour tunnels inter-membres -- Allocation propre des blocs 10.100.0.0/16 à 10.255.0.0/16 - -### 2.3 Domaine 3 : Plateforme & API (Développeur Backend) - -**Expert de référence :** Développeur Backend Python/FastAPI - -**Ce qui est évalué :** -- Qualité de l'API (REST, documentation, versioning) -- Multi-tenancy et isolation des données -- Sécurité applicative (RBAC, JWT, audit logs) -- Performance et scalabilité -- Tests automatisés (unitaires, intégration) -- Code propre et maintenable -- Intégrations avec Ortrux (si applicable) - -**Technologies de référence :** -- FastAPI (Python 3.11+) avec SQLAlchemy -- PostgreSQL 15 (multi-tenant avec schémas ou RLS) -- React ou équivalent pour dashboard -- CI/CD sur Forgejo ou GitLab -- Tests avec pytest - -### 2.4 Domaine 4 : Gouvernance & Conformité (Expert OBNL) - -**Expert de référence :** Expert en gouvernance coopérative/OBNL (Québec) - -**Ce qui est évalué :** -- Structure juridique (OBNL, coop, association) -- Gouvernance participative (sociocratique ou équivalent) -- Conformité légale (Loi 25, RGPD si applicable) -- Transparence financière -- Politiques de protection des données -- Registre des traitements (RGPD) -- Contrats clairs avec les usagers - -**Standards de référence :** -- Loi 25 (Québec) - protection des renseignements personnels -- RGPD (si membres hors Québec/Canada) -- Gouvernance sociocratique ou consentement -- Publication des états financiers annuels - -### 2.5 Domaine 5 : Expérience & Accessibilité (Designer UX/UI) - -**Expert de référence :** Designer UX/UI avec sensibilité éthique - -**Ce qui est évalué :** -- Qualité de l'interface utilisateur (dashboard, portails) -- Accessibilité WCAG 2.1 (niveau AA minimum) -- Design éthique (pas de dark patterns) -- Sobriété numérique (poids des pages, écoconception) -- Documentation utilisateur claire -- Support et accompagnement des usagers - -**Standards de référence :** -- WCAG 2.1 niveau AA -- Écoconception (Référentiel GR491 ou équivalent) -- Temps de chargement < 3s (pages principales) -- Design accessible (contraste, navigation clavier, lecteurs d'écran) - ---- - -## 3. ARCHITECTURE TECHNIQUE ATTENDUE - -### 3.1 Le modèle à 8 couches (référence Chezlepro) - -L'Alliance Boréale s'inspire du modèle autopoïétique à 8 couches développé par Chezlepro. Chaque membre n'a pas besoin d'implémenter toutes les couches, mais doit comprendre leur rôle : - -**Couche 1 - Physique :** -- Serveurs physiques ou VPS chez hébergeur éthique -- Datacenter avec PUE acceptable (< 1.5) -- Énergie renouvelable privilégiée - -**Couche 2 - Réseau :** -- SDN avec VXLAN/VNets pour isolation multi-tenant -- WireGuard pour tunnels fédérés -- DNS maître/esclave avec PowerDNS - -**Couche 3 - Stockage :** -- Ceph (distribué) ou NFS (centralisé) -- Sauvegardes 3-2-1 testées mensuellement -- Chiffrement au repos (LUKS ou équivalent) - -**Couche 4 - Orchestration :** -- Ansible pour IaC et automatisation -- Playbooks versionnés sur Forgejo/GitLab -- Variables pour multi-environnements - -**Couche 5 - Virtualisation :** -- Proxmox VE 8.x (ou équivalent libres : oVirt, XCP-ng) -- HA Cluster pour haute disponibilité (optionnel pour Bronze) -- Templates standardisés - -**Couche 6 - Services :** -- API FastAPI + PostgreSQL multi-tenant -- Dashboard React ou équivalent -- Intégrations Ortrux (si membre actif) - -**Couche 7 - Applications :** -- Services pour usagers finaux (VMs, DNS, hébergement web, etc.) -- Interfaces claires et accessibles -- Documentation complète - -**Couche 8 - Philosophie/Éthique :** -- Charte interne alignée avec L'Alliance Boréale -- Gouvernance participative -- Transparence et sobriété - -### 3.2 Exigences minimales par niveau de label - -| Composant | Bronze | Argent | Or | Platine | -|-----------|--------|--------|----|----| -| **Proxmox/Virtu** | Standalone OK | Cluster HA souhaité | Cluster HA obligatoire | Multi-site HA | -| **DNS** | Maître seul OK | Maître + 1 esclave | Maître + 2 esclaves | DNSSEC + anycast | -| **Stockage** | Local/NFS | Ceph ou équivalent | Ceph distribué | Ceph géorépliqué | -| **Ansible** | Playbooks de base | Rôles réutilisables | CI/CD complet | Tests automatisés | -| **API** | CRUD de base | Multi-tenant | RBAC avancé | Métriques temps réel | -| **Monitoring** | Basique (Icinga2) | Alertes configurées | Dashboards Grafana | BPM + prédictions | -| **Sauvegarde** | Hebdo testées | 3-2-1 testées | Disaster recovery < 4h | DR < 1h + tests trimestriels | - ---- - -## 4. PROCESSUS D'AUDIT COMPLET - -### 4.1 Phases de l'audit - -**Phase 0 : Préparation (1-2 semaines avant)** - -L'organisme audité : -1. Remplit le questionnaire d'auto-évaluation (Annexe A) -2. Prépare les documents justificatifs -3. Identifie les accès à fournir (lecture seule, VPN temporaire, etc.) -4. Désigne un responsable technique pour l'audit - -L'auditeur : -1. Consulte le dossier préparatoire -2. Identifie les points critiques à vérifier -3. Planifie le calendrier d'audit (1-2 jours sur site ou visio) -4. Se forme sur les spécificités techniques du membre - -**Phase 1 : Audit initial (Jour 1 - 4h)** - -- **30 min** : Présentation mutuelle, objectifs de l'audit, cadre éthique -- **90 min** : Revue documentaire (chartes, politiques, procédures) -- **60 min** : Démonstration technique guidée par l'audité -- **60 min** : Questions-réponses et clarifications - -**Phase 2 : Vérifications techniques (Jour 2 - 6h)** - -- **120 min** : Tests DevOps/Infra (connexion aux systèmes, vérif configs) -- **90 min** : Tests Réseau/DNS (requêtes, réplication, DNSSEC) -- **90 min** : Tests API/Plateforme (endpoints, sécurité, perfs) -- **60 min** : Revue Gouvernance/UX (documents, interfaces, accessibilité) - -**Phase 3 : Rapport et feedback (1 semaine après)** - -- **Jour 3-5** : L'auditeur rédige le rapport d'audit -- **Jour 6** : Envoi du rapport à l'audité (confidentiel) -- **Jour 7** : Visio de feedback (1h) pour discuter et clarifier -- **Jour 8** : L'audité peut demander révision de certains points (délai 48h) -- **Jour 10** : Décision finale du Cercle Réseau sur l'attribution du label - -**Phase 4 : Publication et suivi** - -- Publication du label obtenu au Registraire public -- Badge téléchargeable pour le site web du membre -- Suivi annuel (audit léger) pour maintenir le label -- Plan d'action pour corriger les non-conformités mineures - -### 4.2 Outils de l'auditeur - -L'auditeur utilise : - -**Accès fournis par l'audité :** -- VPN WireGuard temporaire (lecture seule) -- Accès SSH avec clé dédiée (non-root, sudo limité) -- Compte API read-only sur le dashboard -- Accès lecture aux dépôts Git (Forgejo, GitLab) -- Screenshots ou exports de configs sensibles (anonymisés) - -**Outils de vérification :** -- Scripts Ansible d'audit (fournis par L'Alliance) -- Tests automatisés DNS (dig, nslookup, DNSSEC verify) -- Scans de sécurité légers (nmap, nikto avec consentement) -- Tests d'accessibilité (WAVE, axe DevTools) -- Outils RGPD/Loi 25 (checklist de conformité) - -**Documentation produite :** -- Rapport d'audit complet (20-30 pages, confidentiel) -- Fiche synthèse publique (2 pages, publiée au Registraire) -- Plan d'action pour les non-conformités (si applicable) - ---- - -## 5. GRILLES D'ÉVALUATION PAR EXPERTISE - -### 5.1 Grille DevOps/SRE (Infrastructure & Orchestration) - -**Domaine : Infrastructure de virtualisation** - -| Critère | Bronze | Argent | Or | Platine | Points | -|---------|--------|--------|----|----|--------| -| **Virtualisation** | Proxmox/oVirt standalone | Cluster 2+ nœuds | Cluster HA 3+ nœuds | Multi-DC géorépliqué | /10 | -| **Stockage** | Local ou NFS | Ceph ou distribué | Ceph HA + snapshots | Géoréplication + DR | /10 | -| **Réseau SDN** | Bridges basiques | VNets/VXLAN simples | SDN zones multiples | SDN BGP/EVPN | /10 | -| **Monitoring** | Icinga2 ou équivalent | Alertes configurées | Grafana + métriques | BPM + prédictions | /10 | -| **Ansible IaC** | Playbooks manuels | Rôles réutilisables | Variables avancées | CI/CD + tests auto | /10 | -| **Sauvegarde 3-2-1** | Hebdo non testées | Testées mensuel | Testées hebdo + DR | DR < 1h + tests trimestriels | /10 | -| **Sécurité** | Firewall basique | MFA admins | Hardening complet | Zero-trust + audit | /10 | -| **Documentation** | README basique | Procédures écrites | Wiki structuré | Docs auto-générées | /10 | - -**Scoring :** -- Bronze : 40-54 points -- Argent : 55-69 points -- Or : 70-84 points -- Platine : 85-100 points - ---- - -### 5.2 Grille Réseau/DNS (Architecture réseau) - -**Domaine : Réseau & DNS fédéré** - -| Critère | Bronze | Argent | Or | Platine | Points | -|---------|--------|--------|----|----|--------| -| **PowerDNS** | Maître seul | Maître + 1 esclave | Maître + 2+ esclaves | Multi-maître anycast | /10 | -| **DNSSEC** | Désactivé OK | Activé mais non validé | Activé + validé | Rotation clés auto | /10 | -| **AXFR/NOTIFY** | Non implémenté | Fonctionne vers 1 membre | Fédération 3+ membres | Mesh complet + monitoring | /10 | -| **Plan adressage** | Pas de /16 dédié | 1 bloc /16 attribué | Multi-blocs organisés | IPAM automatisé | /10 | -| **VPN fédération** | Pas de tunnel | WireGuard 1 pair | Mesh 3+ membres | HA multi-tunnels | /10 | -| **Redondance** | Single point failure | Redondance partielle | Full HA | Multi-DC actif-actif | /10 | -| **Performance** | Latence > 100ms | Latence 50-100ms | Latence 20-50ms | Latence < 20ms | /10 | -| **Sécurité réseau** | Firewall basique | Rate limiting DNS | DDoS mitigation | WAF + anomaly detection | /10 | - -**Scoring :** -- Bronze : 40-54 points -- Argent : 55-69 points -- Or : 70-84 points -- Platine : 85-100 points - ---- - -### 5.3 Grille Backend/API (Plateforme & Services) - -**Domaine : API et plateforme multi-tenant** - -| Critère | Bronze | Argent | Or | Platine | Points | -|---------|--------|--------|----|----|--------| -| **API REST** | Endpoints basiques | CRUD complet | Versioning API | GraphQL ou équivalent | /10 | -| **Multi-tenancy** | Pas d'isolation | Isolation DB (schémas) | RLS PostgreSQL | Tenant dédié par VM | /10 | -| **Sécurité API** | Basic Auth | JWT + refresh tokens | RBAC granulaire | OAuth2 + audit logs | /10 | -| **Documentation** | README basique | Swagger/OpenAPI | Exemples + tutoriels | Docs interactives | /10 | -| **Tests** | Aucun test | Tests unitaires | Tests intégration | Tests E2E + couverture >80% | /10 | -| **Performance** | Pas de cache | Cache Redis | Query optimization | CDN + edge caching | /10 | -| **CI/CD** | Déploiement manuel | Git hooks | Pipeline CI/CD | Blue-green deploy | /10 | -| **Intégration Ortrux** | N/A | Connecteur basique | API complète | IA prédictive | /10 | - -**Scoring :** -- Bronze : 40-54 points -- Argent : 55-69 points -- Or : 70-84 points -- Platine : 85-100 points - ---- - -### 5.4 Grille Gouvernance/Conformité (OBNL & Légal) - -**Domaine : Gouvernance et conformité légale** - -| Critère | Bronze | Argent | Or | Platine | Points | -|---------|--------|--------|----|----|--------| -| **Structure légale** | Association de fait | OBNL en formation | OBNL enregistré | Coop ou fédération | /10 | -| **Gouvernance** | CA traditionnel | Élections démocratiques | Sociocratique | Holacratique ou avancée | /10 | -| **Loi 25 (Québec)** | Pas de conformité | Politique vie privée | Registre traitements | Évaluations régulières | /10 | -| **RGPD (si applicable)** | Non applicable | DPO désigné | Conformité complète | Certifié externe | /10 | -| **Contrats usagers** | CGU floues | CGU claires | Contrats détaillés | Revus par avocat | /10 | -| **Transparence financière** | Opaque | États annuels | Rapports trimestriels | Finances publiques temps réel | /10 | -| **Politiques internes** | Aucune | 3-5 politiques | 10+ politiques | Manuel complet + révisions | /10 | -| **Assurances** | Aucune | RC professionnelle | Cyber-assurance | Couverture complète | /10 | - -**Scoring :** -- Bronze : 40-54 points -- Argent : 55-69 points -- Or : 70-84 points -- Platine : 85-100 points - ---- - -### 5.5 Grille UX/UI & Accessibilité (Expérience utilisateur) - -**Domaine : Interfaces et accessibilité** - -| Critère | Bronze | Argent | Or | Platine | Points | -|---------|--------|--------|----|----|--------| -| **Interface dashboard** | Admin CLI seul | Interface web basique | Dashboard moderne | Design system cohérent | /10 | -| **WCAG 2.1** | Pas d'accessibilité | Niveau A | Niveau AA | Niveau AAA | /10 | -| **Écoconception** | Pas de démarche | < 1 MB pages | < 500 KB pages | < 200 KB + lazy loading | /10 | -| **Dark patterns** | Présents | Quelques uns | Aucun détecté | Éthique prouvée | /10 | -| **Documentation utilisateur** | README technique | Guide basique | Tutoriels + FAQ | Vidéos + support interactif | /10 | -| **Support usagers** | Email seul | Forum communautaire | Chat + tickets | Support dédié + SLA | /10 | -| **Mobile-friendly** | Non responsive | Responsive basique | Mobile-first | App native | /10 | -| **Temps chargement** | > 5s | 3-5s | 1-3s | < 1s | /10 | - -**Scoring :** -- Bronze : 40-54 points -- Argent : 55-69 points -- Or : 70-84 points -- Platine : 85-100 points - ---- - -## 6. NIVEAUX DE LABEL ET EXIGENCES - -### 6.1 Synthèse des exigences par niveau - -**Label Bronze (Entrée dans la fédération)** - -**Score minimum :** 40/100 dans chaque domaine (200/500 total) - -**Exigences minimales :** -- Infrastructure virtualisée fonctionnelle (Proxmox ou équivalent) -- DNS maître opérationnel avec PowerDNS -- API ou interface de gestion basique -- Charte interne alignée avec L'Alliance -- Politiques de base (vie privée, sécurité) -- Monitoring actif et sauvegardes hebdomadaires - -**Durée de validité :** 1 an (renouvellement requis) - ---- - -**Label Argent (Membre solide)** - -**Score minimum :** 55/100 dans chaque domaine (275/500 total) - -**Exigences minimales :** -- Cluster HA ou redondance prouvée -- DNS maître + 1 esclave + DNSSEC -- API multi-tenant avec RBAC -- OBNL en formation ou enregistré -- Conformité Loi 25 (Québec) ou RGPD -- Accessibilité WCAG 2.1 niveau A minimum -- Sauvegarde 3-2-1 testée mensuellement - -**Durée de validité :** 2 ans - ---- - -**Label Or (Excellence opérationnelle)** - -**Score minimum :** 70/100 dans chaque domaine (350/500 total) - -**Exigences minimales :** -- Cluster HA 3+ nœuds + Ceph distribué -- DNS fédéré avec 2+ esclaves + DNSSEC validé -- API avancée avec versioning et tests automatisés -- Gouvernance sociocratique implémentée -- Conformité légale complète + audit externe -- Accessibilité WCAG 2.1 niveau AA -- Disaster recovery < 4h testé trimestriellement -- Intégration Ortrux (si membre actif de L'Alliance) - -**Durée de validité :** 3 ans - ---- - -**Label Platine (Leadership et innovation)** - -**Score minimum :** 85/100 dans chaque domaine (425/500 total) - -**Exigences minimales :** -- Architecture multi-datacenter avec géoréplication -- DNS anycast avec multi-maître -- Plateforme IA/ML intégrée (Ortrux ou équivalent) -- Gouvernance holacratique ou équivalent avancé -- Transparence financière temps réel -- Accessibilité WCAG 2.1 niveau AAA -- Disaster recovery < 1h avec tests mensuels -- Contribution active au développement de L'Alliance (code, docs, formation) -- Mentorat d'au moins 1 membre Bronze/Argent par an - -**Durée de validité :** 5 ans (mais suivi annuel obligatoire) - ---- - -## 7. RÔLE DES AUDITEURS ET FORMATION - -### 7.1 Qui peut être auditeur ? - -**Critères de base :** -- Être membre actif de L'Alliance Boréale (label Argent minimum) -- Avoir au moins 3 ans d'expérience dans l'un des 5 domaines d'expertise -- Avoir complété la formation d'auditeur (16h en ligne + 1 audit supervisé) -- S'engager à réaliser au moins 2 audits par an -- Respecter le code éthique des auditeurs - -**Domaines de spécialisation :** - -Chaque auditeur déclare ses domaines de compétence parmi les 5 : -1. DevOps/SRE -2. Réseau/DNS -3. Backend/API -4. Gouvernance/OBNL -5. UX/UI - -Un audit complet nécessite idéalement 2 auditeurs complémentaires (ex: 1 DevOps + 1 Gouvernance). - -### 7.2 Formation des auditeurs - -**Module 1 : Philosophie et éthique de l'audit (4h)** -- Les valeurs de L'Alliance Boréale -- Posture bienveillante mais rigoureuse -- Gestion des conflits et situations délicates -- Confidentialité et respect du secret - -**Module 2 : Critères techniques (8h)** -- Revue détaillée des 5 grilles d'évaluation -- Cas pratiques et études de cas réels -- Outils d'audit et scripts fournis -- Identification des red flags critiques - -**Module 3 : Processus et documentation (4h)** -- Déroulement d'un audit de A à Z -- Rédaction du rapport d'audit -- Feedback constructif à l'audité -- Gestion des non-conformités - -**Module 4 : Pratique supervisée** -- Participation à 1 audit réel en tant qu'observateur -- Rédaction d'un rapport d'audit sous supervision -- Validation par un auditeur senior - -**Renouvellement :** -- Formation de mise à jour obligatoire tous les 2 ans (4h) -- Révision des critères si évolution majeure - -### 7.3 Banque de Temps et rétribution - -**Valorisation du temps d'audit :** - -L'audit est une contribution valorisée dans la Banque de Temps de L'Alliance : - -| Phase | Temps estimé | Crédits BDT | -|-------|--------------|-------------| -| Préparation (lecture dossier) | 2h | 2 crédits | -| Audit Jour 1 (revue doc + démo) | 4h | 6 crédits | -| Audit Jour 2 (tests techniques) | 6h | 9 crédits | -| Rédaction rapport | 4h | 6 crédits | -| Feedback et suivi | 2h | 3 crédits | -| **TOTAL audit complet** | **18h** | **26 crédits** | - -**Note :** Les crédits sont majorés de 50% car l'audit est une expertise critique pour la fédération (18h × 1.5 = 27 crédits, arrondi à 26 pour simplicité). - -**Utilisation des crédits :** -- Réduction de cotisation annuelle -- Échange contre du temps d'expertise d'autres membres -- Priorité sur les ressources partagées de L'Alliance - ---- - -## 8. GESTION DES NON-CONFORMITÉS - -### 8.1 Types de non-conformités - -**Non-conformité mineure :** -- N'affecte pas la sécurité ou la vie privée -- Peut être corrigée dans les 6 mois -- N'empêche pas l'attribution du label si plan d'action clair - -**Exemples :** -- Documentation incomplète -- Monitoring incomplet (mais présent) -- Accessibilité WCAG niveau A au lieu de AA pour Argent -- Sauvegarde 3-2-1 non testée depuis 2 mois - -**Non-conformité majeure :** -- Affecte la sécurité, la vie privée ou la stabilité -- Doit être corrigée sous 1 mois (délai de grâce) -- Peut entraîner un refus de label ou dégradation - -**Exemples :** -- Pas de MFA pour accès admin (Argent+) -- DNSSEC cassé depuis plusieurs semaines -- Aucune sauvegarde depuis 3+ mois -- Violation active de Loi 25/RGPD -- Infrastructure instable (downtime > 5% mensuel) - -**Non-conformité critique :** -- Violation grave de l'éthique ou de la légalité -- Refus immédiat du label (ou suspension) -- Peut entraîner l'exclusion de L'Alliance - -**Exemples :** -- Revente de données usagers -- Pratiques de sécurité dangereuses intentionnelles -- Refus de coopérer pendant l'audit -- Mensonges avérés sur les pratiques -- Violation des valeurs fondamentales de L'Alliance - -### 8.2 Processus de correction - -**Pour les non-conformités mineures :** - -1. **Identification** : L'auditeur documente la non-conformité dans le rapport -2. **Plan d'action** : L'audité propose un plan de correction (délai 2 semaines) -3. **Validation** : Le Cercle Réseau valide le plan -4. **Exécution** : Correction sous 6 mois maximum -5. **Vérification** : Audit de suivi léger (2h) pour valider la correction -6. **Clôture** : Mise à jour du dossier membre - -Le label peut être attribué avec mention "sous réserve de correction" si le plan est validé. - ---- - -**Pour les non-conformités majeures :** - -1. **Notification** : Rapport d'audit avec RED FLAG -2. **Délai de grâce** : 1 mois pour corriger -3. **Support** : L'Alliance peut fournir de l'assistance (via Banque de Temps) -4. **Vérification** : Audit de suivi complet (1 jour) -5. **Décision** : - - Si corrigé : Attribution du label - - Si non corrigé : Refus ou dégradation de niveau - -Le label ne peut PAS être attribué tant que la non-conformité majeure n'est pas résolue. - ---- - -**Pour les non-conformités critiques :** - -1. **Suspension immédiate** : Si le membre avait déjà un label -2. **Investigation** : Enquête par le Cercle Éthique & Gouvernance -3. **Médiation** : Tentative de résolution amiable -4. **Sanction** : - - Avertissement formel - - Suspension temporaire (1-6 mois) - - Exclusion de L'Alliance (cas extrêmes) - -Aucun label ne peut être attribué/maintenu en cas de non-conformité critique active. - -### 8.3 Appel et recours - -**Droit d'appel :** - -Si l'audité conteste les conclusions de l'audit, il peut : - -1. **Demander clarification** : Visio avec l'auditeur (48h) -2. **Contester un critère** : Argumentaire écrit au Cercle Réseau (1 semaine) -3. **Demander un second audit** : Par un autre auditeur (coût : 10 crédits BDT) -4. **Médiation** : Via le Cercle Éthique & Gouvernance - -**Délais de recours :** -- 14 jours calendrier après réception du rapport d'audit -- Suspension de la publication du résultat pendant l'appel - -**Décision finale :** -- Le Cercle Réseau tranche après avoir entendu les deux parties -- Décision prise par consentement (pas d'objection majeure) -- La décision est définitive (sauf nouveaux éléments majeurs) - ---- - -## 9. ANNEXES - -### Annexe A : Questionnaire d'auto-évaluation - -**Section 1 : Informations générales** - -1. Nom de l'organisme : _______________ -2. Année de création : _______________ -3. Statut juridique : ☐ Association ☐ OBNL ☐ Coopérative ☐ Autre -4. Nombre d'usagers actifs : _______________ -5. Équipe technique (ETP) : _______________ -6. Label visé : ☐ Bronze ☐ Argent ☐ Or ☐ Platine - -**Section 2 : Auto-évaluation DevOps/SRE** - -| Critère | Oui | Partiellement | Non | Commentaire | -|---------|-----|---------------|-----|-------------| -| Utilisation de Proxmox VE ou équivalent libre | ☐ | ☐ | ☐ | | -| Cluster HA (3+ nœuds) | ☐ | ☐ | ☐ | | -| Stockage Ceph ou distribué | ☐ | ☐ | ☐ | | -| Orchestration Ansible | ☐ | ☐ | ☐ | | -| Monitoring actif (Icinga2, Prometheus, etc.) | ☐ | ☐ | ☐ | | -| Sauvegarde 3-2-1 testée | ☐ | ☐ | ☐ | | -| MFA pour accès admin | ☐ | ☐ | ☐ | | - -**Section 3 : Auto-évaluation Réseau/DNS** - -| Critère | Oui | Partiellement | Non | Commentaire | -|---------|-----|---------------|-----|-------------| -| PowerDNS 4.8+ avec PostgreSQL | ☐ | ☐ | ☐ | | -| DNSSEC activé et validé | ☐ | ☐ | ☐ | | -| Réplication DNS (AXFR/NOTIFY) | ☐ | ☐ | ☐ | | -| Bloc /16 dédié attribué par L'Alliance | ☐ | ☐ | ☐ | | -| Tunnel WireGuard vers autre(s) membre(s) | ☐ | ☐ | ☐ | | -| Redondance DNS (2+ serveurs) | ☐ | ☐ | ☐ | | - -**Section 4 : Auto-évaluation Backend/API** - -| Critère | Oui | Partiellement | Non | Commentaire | -|---------|-----|---------------|-----|-------------| -| API REST ou GraphQL | ☐ | ☐ | ☐ | | -| Multi-tenancy avec isolation | ☐ | ☐ | ☐ | | -| RBAC et sécurité applicative | ☐ | ☐ | ☐ | | -| Documentation API (Swagger/OpenAPI) | ☐ | ☐ | ☐ | | -| Tests automatisés (CI/CD) | ☐ | ☐ | ☐ | | -| Intégration Ortrux (si applicable) | ☐ | ☐ | ☐ | | - -**Section 5 : Auto-évaluation Gouvernance/OBNL** - -| Critère | Oui | Partiellement | Non | Commentaire | -|---------|-----|---------------|-----|-------------| -| OBNL enregistré ou en cours | ☐ | ☐ | ☐ | | -| Gouvernance sociocratique ou participative | ☐ | ☐ | ☐ | | -| Conformité Loi 25 (Québec) | ☐ | ☐ | ☐ | | -| Registre des traitements (RGPD) | ☐ | ☐ | ☐ | | -| CGU et contrats clairs | ☐ | ☐ | ☐ | | -| États financiers publiés | ☐ | ☐ | ☐ | | - -**Section 6 : Auto-évaluation UX/UI** - -| Critère | Oui | Partiellement | Non | Commentaire | -|---------|-----|---------------|-----|-------------| -| Interface web moderne | ☐ | ☐ | ☐ | | -| Accessibilité WCAG 2.1 (AA minimum) | ☐ | ☐ | ☐ | | -| Écoconception (pages < 500 KB) | ☐ | ☐ | ☐ | | -| Documentation utilisateur complète | ☐ | ☐ | ☐ | | -| Support usagers réactif | ☐ | ☐ | ☐ | | -| Mobile-friendly / responsive | ☐ | ☐ | ☐ | | - -**Section 7 : Preuves et documents à fournir** - -Veuillez préparer les documents suivants pour l'audit : - -- ☐ Charte interne ou document de gouvernance -- ☐ Politiques de sécurité et vie privée -- ☐ Registre des traitements (Loi 25/RGPD) -- ☐ Schéma d'architecture technique (réseau, stockage, services) -- ☐ Exemples de playbooks Ansible -- ☐ Rapport de test de sauvegarde (< 3 mois) -- ☐ Rapport de monitoring (disponibilité mensuelle) -- ☐ Documentation API (Swagger ou équivalent) -- ☐ États financiers (dernière année) -- ☐ Contrat type avec usagers (CGU) - ---- - -### Annexe B : Checklist rapide de l'auditeur - -**Avant l'audit :** -- ☐ Questionnaire d'auto-évaluation reçu -- ☐ Documents justificatifs consultés -- ☐ Accès VPN/SSH/API configurés -- ☐ Calendrier validé avec l'audité -- ☐ Outils d'audit préparés - -**Jour 1 - Revue documentaire :** -- ☐ Charte interne alignée avec L'Alliance -- ☐ Gouvernance participative documentée -- ☐ Politiques de sécurité et vie privée présentes -- ☐ Registre des traitements (si applicable) -- ☐ Contrats usagers clairs - -**Jour 2 - Vérifications techniques :** - -**DevOps/SRE :** -- ☐ Proxmox/Virtualisation : version, config, HA -- ☐ Ceph/Stockage : pools, réplication, santé -- ☐ Ansible : playbooks versionnés, rôles, variables -- ☐ Monitoring : Icinga2/Prometheus actif, alertes configurées -- ☐ Sauvegarde : test de restauration réussi (< 3 mois) -- ☐ Sécurité : MFA, firewall, hardening SSH - -**Réseau/DNS :** -- ☐ PowerDNS : version, backend PostgreSQL -- ☐ DNSSEC : activé, validé avec `dig +dnssec` -- ☐ Réplication : AXFR/NOTIFY fonctionnel -- ☐ Plan d'adressage : bloc /16 bien géré -- ☐ Tunnels : WireGuard actif vers autre(s) membre(s) -- ☐ Performance : latence < 100ms (Bronze), < 50ms (Or) - -**Backend/API :** -- ☐ API REST : endpoints testés, documentation accessible -- ☐ Multi-tenant : isolation prouvée (schémas/RLS) -- ☐ Sécurité : JWT, RBAC, logs d'audit -- ☐ Tests : unitaires et intégration présents -- ☐ CI/CD : pipeline fonctionnel - -**UX/UI :** -- ☐ Dashboard : moderne, intuitif -- ☐ WCAG : scan accessibilité (WAVE/axe) -- ☐ Écoconception : poids pages vérifié -- ☐ Documentation : claire, complète -- ☐ Support : canaux de contact actifs - -**Après l'audit :** -- ☐ Rapport rédigé (20-30 pages) -- ☐ Fiche synthèse publique (2 pages) -- ☐ Feedback donné à l'audité (visio 1h) -- ☐ Score final calculé par domaine -- ☐ Recommandation de label au Cercle Réseau - ---- - -### Annexe C : Exemple de rapport d'audit (structure) - -``` -RAPPORT D'AUDIT BORÉAL -Organisme : [Nom] -Date d'audit : [Date] -Auditeur(s) : [Noms] -Label visé : [Bronze/Argent/Or/Platine] - -================================= -SECTION 1 : SYNTHÈSE EXÉCUTIVE -================================= - -Résumé en 1 page : -- Contexte et objectif de l'audit -- Niveau de label recommandé -- Points forts majeurs (3-5) -- Points d'amélioration prioritaires (3-5) -- Non-conformités identifiées - -Score global : [X/500] -- DevOps/SRE : [X/100] -- Réseau/DNS : [X/100] -- Backend/API : [X/100] -- Gouvernance : [X/100] -- UX/UI : [X/100] - -Recommandation : ☐ Approuver label [X] ☐ Refuser ☐ Sous réserve - -================================= -SECTION 2 : REVUE DOCUMENTAIRE -================================= - -- Charte interne : [Commentaires] -- Gouvernance : [Commentaires] -- Politiques : [Commentaires] -- Conformité légale : [Commentaires] - -================================= -SECTION 3 : ÉVALUATION TECHNIQUE -================================= - -[Pour chaque domaine : grille remplie + commentaires détaillés] - -3.1 DevOps/SRE (Infrastructure & Orchestration) -- Virtualisation : [X/10] - [Commentaires] -- Stockage : [X/10] - [Commentaires] -- Réseau SDN : [X/10] - [Commentaires] -[...] - -3.2 Réseau/DNS -[...] - -3.3 Backend/API -[...] - -3.4 Gouvernance -[...] - -3.5 UX/UI -[...] - -================================= -SECTION 4 : NON-CONFORMITÉS -================================= - -[Tableau des non-conformités identifiées] - -| ID | Type | Domaine | Description | Criticité | Plan d'action | -|----|------|---------|-------------|-----------|---------------| -| NC-01 | Majeure | DNS | DNSSEC non validé | Haute | [Détails] | -| NC-02 | Mineure | UX | WCAG niveau A au lieu AA | Moyenne | [Détails] | - -================================= -SECTION 5 : RECOMMANDATIONS -================================= - -Recommandations prioritaires (court terme < 6 mois) : -1. [Recommandation 1] -2. [Recommandation 2] -3. [Recommandation 3] - -Recommandations secondaires (moyen terme < 1 an) : -[...] - -================================= -SECTION 6 : CONCLUSION -================================= - -[Synthèse finale et recommandation de label] - -Signatures : -Auditeur(s) : _______________ Date : ___________ -Validé par Cercle Réseau : ______________ Date : ___________ -``` - ---- - -### Annexe D : Badge et usage du label - -**Badges téléchargeables :** - -L'Alliance fournit des badges PNG et SVG pour chaque niveau : - -``` -🥉 Boréal Bronze - Member of L'Alliance Boréale -🥈 Boréal Argent - Member of L'Alliance Boréale -🥇 Boréal Or - Member of L'Alliance Boréale -💎 Boréal Platine - Member of L'Alliance Boréale -``` - -**Règles d'usage :** - -1. **Placement autorisé :** - - Site web (footer ou page "À propos") - - Signatures email - - Documents officiels - - Réseaux sociaux - -2. **Interdictions :** - - Modification du badge (couleurs, texte, logo) - - Usage à des fins commerciales trompeuses - - Prétendre à un niveau supérieur non obtenu - - Continuer l'usage après expiration (renouvellement obligatoire) - -3. **Mention recommandée :** - -> "Nous sommes fiers d'être membres de L'Alliance Boréale avec le label [Niveau]. Ce label atteste de notre engagement envers la souveraineté numérique, l'éthique, et l'excellence technique au service du bien commun." - -**Lien vers registraire :** - -Chaque badge doit pointer vers la fiche publique du membre sur le registraire de L'Alliance : - -``` -https://registre.allianceboreale.ca/membre/[nom-membre] -``` - ---- - -**FIN DU PROTOCOLE D'AUDIT PAIR-À-PAIR** - -*"L'audit n'est pas une fin, c'est un chemin de croissance mutuelle."* - -🌲 **L'Alliance Boréale** -*Ensemble, tissons une forêt numérique vivante.* - ---- - -**Document 5 complété le 12 octobre 2025** -**Prochaine révision prévue : Octobre 2026** -**Version : 1.0** diff --git a/docs/vieustoq/document_06_charte_banque_de_temps(1).md b/docs/vieustoq/document_06_charte_banque_de_temps(1).md deleted file mode 100644 index 98aeb2c..0000000 --- a/docs/vieustoq/document_06_charte_banque_de_temps(1).md +++ /dev/null @@ -1,848 +0,0 @@ -# Document 6 : Charte de la Banque de Temps -## L'Alliance Boréale - -**Version :** 1.0 -**Date :** 12 octobre 2025 -**Statut :** Cadre opérationnel -**Longueur :** 16-18 pages - ---- - -## TABLE DES MATIÈRES - -1. [Philosophie de la Banque de Temps](#1-philosophie-de-la-banque-de-temps) -2. [Principes fondamentaux](#2-principes-fondamentaux) -3. [Les 5 expertises valorisées](#3-les-5-expertises-valorisées) -4. [Fonctionnement du système de crédits](#4-fonctionnement-du-système-de-crédits) -5. [Contributions éligibles](#5-contributions-éligibles) -6. [Utilisation des crédits](#6-utilisation-des-crédits) -7. [Gouvernance de la Banque de Temps](#7-gouvernance-de-la-banque-de-temps) -8. [Cas d'usage et exemples](#8-cas-dusage-et-exemples) -9. [Annexes](#9-annexes) - ---- - -## 1. PHILOSOPHIE DE LA BANQUE DE TEMPS - -### 1.1 Notre vision fondatrice - -> **"Une heure d'expertise vaut une heure d'expertise. Nous refusons la hiérarchie monétaire des compétences. Toute contribution authentique à L'Alliance a une valeur égale dans le temps."** - -La Banque de Temps (BDT) de L'Alliance Boréale n'est pas un système de troc déguisé ni une monnaie locale. C'est un **mécanisme de reconnaissance mutuelle** où chaque membre peut contribuer selon ses forces et bénéficier selon ses besoins. - -### 1.2 Pourquoi une Banque de Temps ? - -**Trois raisons essentielles :** - -1. **Complémentarité avec l'argent** - L'argent est nécessaire pour payer les serveurs, l'électricité, les assurances. Mais toute contribution ne peut pas être réduite à un prix. La BDT valorise ce qui est inestimable : le savoir, l'entraide, le mentorat, la gouvernance. - -2. **Équité réelle entre membres** - Un OBNL naissant avec 0$ de budget peut contribuer autant qu'un membre fortuné. La BDT efface les inégalités financières et révèle les richesses humaines. - -3. **Renforcement des liens sociaux** - En s'échangeant du temps, les membres se connaissent, collaborent, et tissent une véritable communauté. La BDT n'est pas qu'un outil comptable, c'est un **catalyseur de coopération**. - -### 1.3 Ce que la BDT n'est PAS - -- ❌ **Pas une monnaie** : On ne peut pas "acheter" avec des crédits BDT en dehors de L'Alliance -- ❌ **Pas un salaire** : Les crédits ne remplacent pas la rémunération monétaire quand elle est due -- ❌ **Pas obligatoire** : Participer à la BDT est volontaire (mais fortement encouragé) -- ❌ **Pas une compétition** : Accumuler des crédits n'est pas un objectif en soi - -### 1.4 Valeurs portées par la BDT - -**Égalité intrinsèque :** -1 heure de mentorat = 1 heure de développement code = 1 heure de design = 1 heure de comptabilité. Nous valorisons **l'intention et l'effort**, pas le "prix de marché" de la compétence. - -**Réciprocité différée :** -Tu donnes aujourd'hui sans savoir qui te rendra service demain. La BDT cultive la **confiance systémique** plutôt que l'échange bilatéral immédiat. - -**Abondance plutôt que rareté :** -Plus les membres contribuent, plus la BDT est riche. Contrairement à l'argent (rare par design), le temps partagé crée de l'abondance collective. - -**Transparence totale :** -Toutes les transactions BDT sont publiques (anonymisées si nécessaire). Chacun peut voir qui contribue et comment. - ---- - -## 2. PRINCIPES FONDAMENTAUX - -### 2.1 Les 7 règles d'or de la BDT - -**Règle 1 : Une heure = Un crédit de base** -Par défaut, 1 heure de contribution = 1 crédit BDT. Des multiplicateurs peuvent s'appliquer selon la nature de la contribution (voir section 4). - -**Règle 2 : Pas de crédits négatifs** -On ne peut pas "emprunter" des crédits qu'on n'a pas. Le solde minimum est 0. Cela préserve la soutenabilité du système. - -**Règle 3 : Les crédits ne périment pas** -Tes crédits BDT restent valides tant que tu es membre actif de L'Alliance. Ils sont suspendus (mais non perdus) si tu quittes temporairement. - -**Règle 4 : Transparence des transactions** -Toutes les contributions et utilisations de crédits sont enregistrées dans le registre public de L'Alliance. Tu peux toujours consulter ton historique. - -**Règle 5 : Validation communautaire** -Certaines contributions majeures (>10h) nécessitent validation par le Cercle concerné pour éviter les abus. - -**Règle 6 : Don de crédits possible** -Tu peux offrir tes crédits à un autre membre ou au "pot commun" de L'Alliance. - -**Règle 7 : Pas de conversion monétaire** -Les crédits BDT ne peuvent JAMAIS être échangés contre de l'argent (dans les deux sens). Ils restent dans l'écosystème de L'Alliance. - -### 2.2 Qui peut utiliser la BDT ? - -**Membres actifs :** -Tous les membres avec un label Boréal (Bronze à Platine) ont accès à la BDT. - -**Membres en probation :** -Peuvent **contribuer** et accumuler des crédits dès le début, mais ne peuvent **utiliser** leurs crédits qu'après obtention du label Bronze. - -**Non-membres :** -Ne peuvent pas participer à la BDT. C'est un avantage réservé aux membres de L'Alliance. - -### 2.3 Soldes initiaux - -**Nouveaux membres :** -Commencent avec **10 crédits de bienvenue** pour encourager les premières interactions. Ces crédits sont offerts par le pot commun de L'Alliance. - -**Membres fondateurs :** -Reçoivent un bonus ponctuel de **50 crédits** en reconnaissance de leur rôle dans la création de L'Alliance (une seule fois, non renouvelable). - ---- - -## 3. LES 5 EXPERTISES VALORISÉES - -La BDT reconnaît et valorise particulièrement les **5 expertises critiques** de L'Alliance. Ces contributions bénéficient de **multiplicateurs** car elles sont au cœur de notre mission collective. - -### 3.1 Expertise #1 : DevOps/SRE (Infrastructure & Orchestration) - -**Profil :** Expert Proxmox, Ansible, Ceph, SDN, Monitoring - -**Contributions valorisées :** -- Configuration de clusters Proxmox pour un membre -- Création de rôles Ansible réutilisables pour L'Alliance -- Mise en place de monitoring Icinga2/Grafana -- Débogage d'infrastructures complexes -- Mentorat sur l'IaC et l'automatisation -- Audit technique DevOps (voir Document 5) - -**Multiplicateur BDT :** 1.5x -*Exemple : 4h de config Proxmox = 6 crédits BDT* - -**Pourquoi un multiplicateur ?** -L'infrastructure est le fondement de toute la fédération. Sans experts DevOps, rien ne fonctionne. Cette expertise est rare et critique. - ---- - -### 3.2 Expertise #2 : Réseau/DNS (Architecture réseau) - -**Profil :** Architecte réseau, expert PowerDNS, DNSSEC, BGP, WireGuard - -**Contributions valorisées :** -- Mise en place de réplication DNS (AXFR/NOTIFY) entre membres -- Configuration DNSSEC pour un membre -- Déploiement de tunnels WireGuard inter-membres -- Résolution d'incidents réseau complexes -- Formation sur PowerDNS et gestion DNS fédérée -- Audit technique Réseau/DNS (voir Document 5) - -**Multiplicateur BDT :** 1.5x -*Exemple : 3h de config DNSSEC = 4.5 crédits BDT* - -**Pourquoi un multiplicateur ?** -Le DNS est le système nerveux de L'Alliance. Une architecture réseau solide garantit la résilience et la souveraineté de la fédération. - ---- - -### 3.3 Expertise #3 : Backend/API (Développement plateforme) - -**Profil :** Développeur Python/FastAPI, expert multi-tenant, sécurité applicative - -**Contributions valorisées :** -- Développement de fonctionnalités pour la plateforme commune -- Création d'intégrations Ortrux -- Code review et amélioration de la qualité du code -- Tests automatisés (unitaires, intégration, E2E) -- Documentation technique (API, architecture) -- Audit technique Backend/API (voir Document 5) - -**Multiplicateur BDT :** 1.3x -*Exemple : 5h de développement API = 6.5 crédits BDT* - -**Pourquoi un multiplicateur ?** -La plateforme API est le cœur battant des services de L'Alliance. Un code de qualité réduit la dette technique et améliore l'expérience de tous. - ---- - -### 3.4 Expertise #4 : Gouvernance/OBNL (Conformité & légal) - -**Profil :** Expert gouvernance sociocratique, conformité Loi 25/RGPD, droit OBNL - -**Contributions valorisées :** -- Rédaction de politiques internes (sécurité, vie privée) -- Accompagnement d'un membre vers statut OBNL -- Revue de conformité légale (Loi 25, RGPD) -- Facilitation de cercles sociocratiques -- Résolution de conflits et médiation -- Audit Gouvernance/Conformité (voir Document 5) - -**Multiplicateur BDT :** 1.5x -*Exemple : 4h d'accompagnement OBNL = 6 crédits BDT* - -**Pourquoi un multiplicateur ?** -La gouvernance et la conformité sont les gardiens de l'éthique et de la pérennité de L'Alliance. Ces expertises protègent tous les membres. - ---- - -### 3.5 Expertise #5 : UX/UI (Design & Accessibilité) - -**Profil :** Designer UX/UI, expert accessibilité WCAG, écoconception - -**Contributions valorisées :** -- Design de dashboards et interfaces pour L'Alliance -- Audit d'accessibilité WCAG pour un membre -- Création de design systems réutilisables -- Amélioration de l'expérience utilisateur -- Formation sur l'accessibilité et l'écoconception -- Audit UX/UI (voir Document 5) - -**Multiplicateur BDT :** 1.3x -*Exemple : 6h de design dashboard = 7.8 crédits BDT* - -**Pourquoi un multiplicateur ?** -Un bon design rend la technologie accessible à tous. L'UX/UI est le pont entre la complexité technique et l'humain. - ---- - -### 3.6 Autres expertises valorisées - -Les 5 expertises ci-dessus sont **prioritaires**, mais d'autres contributions sont aussi valorisées : - -| Expertise | Multiplicateur | Exemples | -|-----------|----------------|----------| -| **Rédaction/Documentation** | 1.0x | Écriture de guides, traductions, tutoriels | -| **Communication/Marketing** | 1.0x | Gestion réseaux sociaux, articles de blog | -| **Support utilisateurs** | 1.0x | Assistance technique, réponse aux tickets | -| **Formation/Mentorat** | 1.2x | Ateliers, webinaires, accompagnement | -| **Recherche/Veille** | 1.0x | Études de marché, analyse de tendances | -| **Administration** | 1.0x | Gestion du registraire, comptabilité BDT | - -**Note :** Le multiplicateur 1.0x signifie pas de bonus (1h = 1 crédit). - ---- - -## 4. FONCTIONNEMENT DU SYSTÈME DE CRÉDITS - -### 4.1 Calcul des crédits - -**Formule de base :** - -``` -Crédits BDT = Heures × Multiplicateur × Facteur de qualité -``` - -**Exemple 1 : Contribution DevOps standard** -- Activité : Configuration Ansible (4h) -- Multiplicateur : 1.5x (DevOps) -- Qualité : 1.0 (standard) -- **Crédits = 4 × 1.5 × 1.0 = 6 crédits** - -**Exemple 2 : Contribution Backend exceptionnelle** -- Activité : Développement API avec tests (5h) -- Multiplicateur : 1.3x (Backend) -- Qualité : 1.2 (exceptionnelle, voir 4.2) -- **Crédits = 5 × 1.3 × 1.2 = 7.8 crédits** - -**Exemple 3 : Formation/Mentorat** -- Activité : Atelier PowerDNS (3h) -- Multiplicateur : 1.2x (Formation) -- Qualité : 1.0 (standard) -- **Crédits = 3 × 1.2 × 1.0 = 3.6 crédits** - -### 4.2 Facteur de qualité (bonus exceptionnel) - -Dans certains cas rares, un **facteur de qualité supérieur** peut être appliqué : - -| Qualité | Facteur | Conditions | -|---------|---------|------------| -| Standard | 1.0x | Contribution normale, bien faite | -| Excellente | 1.1x | Dépasse les attentes, très bien documentée | -| Exceptionnelle | 1.2x | Impact majeur, réutilisable par toute L'Alliance | - -**Qui décide ?** Le Cercle concerné (ex: Cercle Technique pour du code) valide le facteur de qualité pour les contributions >10h. Pour les petites contributions (<10h), l'auto-déclaration est acceptée avec vérification aléatoire. - -### 4.3 Validation des contributions - -**Contributions < 10h :** -Auto-déclarées dans le registre BDT. Le membre indique : -- Nature de la contribution -- Temps passé (heures) -- Membre(s) bénéficiaire(s) ou "L'Alliance" si contribution commune -- Preuves (lien Git, doc, screenshot, etc.) - -**Contributions 10-50h :** -Validation par le Cercle concerné sous 7 jours. Le Cercle peut ajuster les heures ou le multiplicateur si nécessaire. - -**Contributions >50h :** -Validation par consentement du Conseil Coordinateur. Discussion lors de la réunion mensuelle pour éviter les abus. - -### 4.4 Enregistrement des transactions - -Toutes les transactions BDT sont enregistrées dans un fichier YAML versionné sur le dépôt Forgejo de L'Alliance : - -```yaml -# /bdt/transactions/2025/10/transaction_001.yaml -transaction_id: "2025-10-001" -date: "2025-10-12" -contributeur: - nom: "TechCoopYUL" - membre_id: "M-00042" -activite: - type: "DevOps/SRE" - description: "Configuration cluster Proxmox HA pour NouvelleCoop" - heures: 6.0 - multiplicateur: 1.5 - qualite: 1.0 -beneficiaire: - nom: "NouvelleCoop" - membre_id: "M-00051" -credits_generes: 9.0 -validateur: "Cercle Technique" -validation_date: "2025-10-13" -statut: "validee" -preuves: - - "https://git.allianceboreale.ca/techcoopyul/proxmox-config-nouvellecoop" - - "Rapport d'intervention joint" -``` - -**Accessibilité :** Le registre BDT est public (lecture seule) pour tous les membres. Seuls les administrateurs BDT peuvent ajouter des transactions (via pull requests validées). - ---- - -## 5. CONTRIBUTIONS ÉLIGIBLES - -### 5.1 Catégories de contributions - -**A) Contributions techniques directes** - -Travail technique au bénéfice d'un membre ou de L'Alliance : -- Développement de fonctionnalités (code, API, scripts) -- Configuration d'infrastructure (Proxmox, DNS, VPN) -- Débogage et résolution d'incidents -- Audits techniques (voir Document 5) -- Tests et assurance qualité - -**Valorisation :** Selon expertise (1.0x à 1.5x) - ---- - -**B) Contributions à la gouvernance** - -Participation à la vie démocratique de L'Alliance : -- Présence aux réunions de cercle (2h/mois) -- Facilitation de réunion sociocratique -- Rédaction de politiques et procédures -- Médiation de conflits -- Élection et mandats de lien (coordinateur de cercle, etc.) - -**Valorisation :** 1.5x (gouvernance critique) - -**Note spéciale :** La participation aux réunions de cercle est **automatiquement créditée** : 2h × 1.5 = 3 crédits par réunion mensuelle. - ---- - -**C) Contributions éducatives** - -Transmission de savoir au sein de L'Alliance : -- Ateliers et formations (présentiel ou visio) -- Rédaction de tutoriels et guides -- Mentorat individuel (accompagnement d'un membre) -- Webinaires publics -- Traductions de documentation - -**Valorisation :** 1.0x à 1.2x selon impact - ---- - -**D) Contributions au rayonnement** - -Promotion de L'Alliance et de ses valeurs : -- Articles de blog ou médias -- Présence à des événements (conférences, salons) -- Gestion des réseaux sociaux -- Relations publiques et partenariats -- Création de contenus vidéo/audio - -**Valorisation :** 1.0x - ---- - -**E) Contributions administratives** - -Tâches essentielles au bon fonctionnement de L'Alliance : -- Gestion du registraire public -- Comptabilité et finances -- Support utilisateurs (réponse aux tickets) -- Gestion du dépôt Git (code review, CI/CD) -- Mise à jour de la documentation officielle - -**Valorisation :** 1.0x - ---- - -### 5.2 Contributions NON éligibles - -Pour préserver l'intégrité de la BDT, certaines activités ne génèrent PAS de crédits : - -❌ **Travail déjà rémunéré monétairement** -Si tu es payé en argent pour une tâche, tu ne peux pas aussi recevoir des crédits BDT. Pas de "double rémunération". - -❌ **Tâches internes à ton propre organisme** -La BDT valorise les contributions **à L'Alliance ou à d'autres membres**, pas ton travail quotidien interne. - -❌ **Participation passive** -Lire des emails, consulter le registraire, utiliser les services de L'Alliance ne génère pas de crédits. - -❌ **Contributions de mauvaise qualité** -Un code bogué, une documentation incomplète, un audit bâclé peuvent être refusés par le Cercle validateur. - -❌ **Auto-contributions fictives** -Déclarer des heures non réalisées est une violation grave de la Charte et peut mener à l'exclusion. - ---- - -## 6. UTILISATION DES CRÉDITS - -### 6.1 À quoi servent les crédits BDT ? - -**Utilisation #1 : Réduction de cotisation annuelle** - -Les crédits BDT peuvent réduire ta cotisation monétaire annuelle à L'Alliance. - -| Niveau de cotisation | Crédits pour réduction de 50% | Crédits pour réduction de 100% | -|----------------------|-------------------------------|--------------------------------| -| Bronze (500 $CAD) | 30 crédits | 60 crédits | -| Argent (1000 $CAD) | 60 crédits | 120 crédits | -| Or (2000 $CAD) | 120 crédits | 240 crédits | -| Platine (négocié) | N/A | N/A | - -**Formule :** -``` -Réduction (%) = (Crédits dépensés / Crédits requis pour 100%) × 100 -``` - -**Exemple :** Tu es membre Argent (1000 $CAD/an) et tu as 90 crédits BDT. -- Crédits pour 100% : 120 -- Tu dépenses 90 crédits → Réduction = (90/120) × 100 = 75% -- **Tu paies : 1000 × (1 - 0.75) = 250 $CAD** - -**Important :** Cette option doit être déclarée AVANT le renouvellement annuel. Les crédits utilisés sont déduits de ton solde. - ---- - -**Utilisation #2 : Demander de l'aide à d'autres membres** - -Tu peux "dépenser" tes crédits pour solliciter l'aide d'un autre membre de L'Alliance. - -**Processus :** -1. Tu identifies un besoin (ex: "J'ai besoin d'aide pour configurer PowerDNS") -2. Tu publies une demande sur le forum/canal BDT avec estimation (ex: "2-3h estimées") -3. Un membre se propose (ex: "Je peux t'aider, je facture 3h × 1.5 = 4.5 crédits") -4. Vous vous mettez d'accord sur le tarif -5. Après la prestation, tu valides et tes crédits sont transférés au membre aidant -6. Le registre BDT est mis à jour - -**Note :** Le membre aidant gagne les crédits qu'il facture. C'est un échange direct membre à membre. - ---- - -**Utilisation #3 : Accès prioritaire aux ressources communes** - -L'Alliance peut avoir des ressources limitées (ex: VMs de test, support expert du coordinateur). Les membres avec plus de crédits BDT peuvent avoir la priorité. - -**Exemples :** -- Réservation de VMs de staging (coût : 2 crédits/semaine) -- Support technique avancé du coordinateur (coût : 5 crédits/heure) -- Accès aux formations internes réservées (coût : variable) - ---- - -**Utilisation #4 : Don au pot commun** - -Tu peux faire **don** de tes crédits au "pot commun" de L'Alliance. Ces crédits servent à : -- Bonifier les nouveaux membres (10 crédits de bienvenue) -- Récompenser des contributions exceptionnelles (via le Conseil Coordinateur) -- Financer des projets collectifs (ex: développement d'une fonctionnalité commune) - -**Motivation :** Certains membres accumulent beaucoup de crédits sans besoin immédiat. Donner renforce la solidarité et la richesse collective. - ---- - -**Utilisation #5 : Échange avec d'autres membres** - -Tu peux **offrir** des crédits directement à un autre membre (hors demande d'aide formelle). - -**Cas d'usage :** -- Remercier un membre pour un coup de main informel -- Redistribuer vers un membre en difficulté -- Geste de solidarité - -**Limite :** Maximum 10 crédits par transaction pour éviter les abus ou "marchés parallèles". - ---- - -### 6.2 Consultation de ton solde - -Ton solde BDT est visible à tout moment sur ta fiche membre du registraire : - -``` -https://registre.allianceboreale.ca/membre/ton-nom - -Solde BDT : 42.5 crédits -Crédits gagnés (total) : 78.0 -Crédits dépensés (total) : 35.5 -Rang dans L'Alliance : Top 15% -``` - -**Transparence :** Tous les membres peuvent voir le solde de tous (mais pas le détail des transactions sans permission). - ---- - -## 7. GOUVERNANCE DE LA BANQUE DE TEMPS - -### 7.1 Administration de la BDT - -**Responsable :** Le Cercle Services & Opérations gère la BDT au quotidien. - -**Rôles :** -- **Administrateur BDT (1 personne)** : Valide les transactions, tient le registre, répond aux questions -- **Validateurs de Cercle (5 personnes)** : Valident les contributions >10h dans leur domaine d'expertise -- **Auditeur BDT (externe au Cercle)** : Vérifie annuellement l'intégrité du registre - -**Mandats :** Élections annuelles par consentement. L'administrateur BDT reçoit 5 crédits/mois pour ce rôle. - -### 7.2 Évolution des règles - -**Qui peut proposer des changements ?** -Tout membre actif peut proposer une modification de la Charte BDT. - -**Processus :** -1. Proposition publiée sur le forum avec argumentaire -2. Discussion ouverte pendant 14 jours (commentaires, questions) -3. Vote par consentement au Conseil Coordinateur -4. Si accepté : mise à jour de la Charte et annonce aux membres -5. Application à partir du 1er du mois suivant - -**Exemples de changements passés (fictifs) :** -- Ajout du multiplicateur 1.3x pour l'expertise Backend (2024) -- Augmentation du bonus de bienvenue de 5 à 10 crédits (2025) -- Ajout de l'utilisation #5 (échange direct entre membres) (2025) - -### 7.3 Résolution de litiges - -**Que se passe-t-il si :** - -**Cas 1 : Désaccord sur les heures déclarées** -Exemple : Tu déclares 5h, le bénéficiaire dit "c'était plutôt 3h". - -**Résolution :** -1. Discussion amiable entre les deux parties (48h) -2. Si pas d'accord : médiation par l'administrateur BDT (neutre) -3. Si toujours pas d'accord : arbitrage par le Cercle Services & Opérations (décision finale) - ---- - -**Cas 2 : Qualité insuffisante de la contribution** -Exemple : Un membre livre du code non fonctionnel et demande 10 crédits. - -**Résolution :** -1. Le bénéficiaire refuse de valider la transaction -2. Examen par le Cercle Technique -3. Options : demande de correction, réduction des crédits, ou refus complet - ---- - -**Cas 3 : Fraude suspectée** -Exemple : Un membre déclare 50h de travail fictif. - -**Résolution :** -1. Suspension immédiate du compte BDT (prévention) -2. Enquête par le Cercle Éthique & Gouvernance -3. Audition du membre accusé -4. Sanctions possibles : avertissement, perte de crédits, suspension BDT (6 mois), exclusion de L'Alliance (cas graves) - -**Transparence :** Les sanctions sont publiées anonymement dans le rapport annuel de L'Alliance pour éduquer la communauté. - ---- - -## 8. CAS D'USAGE ET EXEMPLES - -### 8.1 Scénario A : Nouveau membre avec peu de budget - -**Contexte :** -NouvelleCoop est un OBNL naissant qui vient d'obtenir son label Bronze. Budget annuel : 5000 $CAD, dont 500 $CAD pour la cotisation à L'Alliance. Ils aimeraient économiser cette somme pour investir dans du matériel. - -**Action :** -1. NouvelleCoop consulte le forum BDT et propose : "Nous pouvons faire 30h de support utilisateurs pour L'Alliance" -2. Le Cercle Services & Opérations valide : "OK, on a besoin de support sur les tickets!" -3. Sur 6 mois, NouvelleCoop répond aux tickets de support (30h × 1.0 = 30 crédits) -4. Au renouvellement annuel, ils utilisent 30 crédits → Réduction de 50% -5. **Ils paient : 500 × 0.5 = 250 $CAD au lieu de 500 $CAD** - -**Bénéfice :** NouvelleCoop économise 250 $CAD et L'Alliance bénéficie de 30h de support de qualité. Win-win! - ---- - -### 8.2 Scénario B : Membre expert qui aide activement - -**Contexte :** -ExpertDevOps est un membre Or avec forte expertise Proxmox/Ansible. Il aime aider les autres membres et a du temps disponible. - -**Action sur 1 an :** -- 5 interventions Proxmox (5 × 6h × 1.5 = 45 crédits) -- 2 audits techniques DevOps (2 × 9h × 1.5 = 27 crédits) -- 3 ateliers Ansible (3 × 3h × 1.2 = 10.8 crédits) -- Participation à 12 réunions de Cercle Technique (12 × 3 = 36 crédits) -- **Total généré : 118.8 crédits** - -**Utilisation :** -- 120 crédits pour cotisation Or 100% gratuite (2000 $CAD économisés!) -- Mais ExpertDevOps a déjà un bon budget, donc il préfère : - - Garder 40 crédits pour demander de l'aide future (ex: design UX) - - Donner 60 crédits au pot commun - - Utiliser 18.8 crédits pour réserver des VMs de test - -**Bénéfice :** ExpertDevOps renforce la fédération, gagne en reconnaissance, et peut solliciter de l'aide quand il en a besoin. La BDT crée un cercle vertueux. - ---- - -### 8.3 Scénario C : Membre en difficulté financière temporaire - -**Contexte :** -TechCoop traverse une mauvaise passe financière (perte d'un gros client). Ils ne peuvent plus payer leur cotisation Argent (1000 $CAD) et risquent de perdre leur label. - -**Action :** -1. TechCoop contacte le Cercle Services & Opérations : "Nous avons une difficulté temporaire" -2. Le Cercle propose : "Pouvez-vous contribuer à L'Alliance en échange ?" -3. TechCoop s'engage à : - - Rédiger 3 tutoriels PowerDNS (3 × 4h × 1.0 = 12 crédits) - - Faire 1 audit réseau (1 × 9h × 1.5 = 13.5 crédits) - - Participer aux réunions mensuelles (12 × 3 = 36 crédits) - - **Total : 61.5 crédits** -4. TechCoop utilise 60 crédits → Réduction de 50% -5. **Ils paient : 1000 × 0.5 = 500 $CAD** (gérable!) -6. Bonus : Le Conseil Coordinateur leur octroie un "crédit de solidarité" exceptionnel de 20 crédits supplémentaires du pot commun - -**Résultat :** TechCoop maintient son label, évite l'exclusion, et L'Alliance gagne des contributions de qualité. La solidarité en action. - ---- - -### 8.4 Scénario D : Projet collectif financé par la BDT - -**Contexte :** -L'Alliance veut développer un nouveau module pour Ortrux : "Auto-scaling intelligent des VMs". Coût estimé : 80h de développement Backend. - -**Action :** -1. Le Cercle Technique lance un appel à projet : "Qui veut contribuer ?" -2. 3 membres se proposent : - - BackendExpert : 40h - - DevJunior : 30h (mentoré par BackendExpert) - - TestingPro : 10h de tests -3. Crédits générés : - - BackendExpert : 40h × 1.3 × 1.1 (excellence) = 57.2 crédits - - DevJunior : 30h × 1.3 × 1.0 = 39 crédits - - TestingPro : 10h × 1.0 = 10 crédits - - **Total : 106.2 crédits** -4. Ces crédits sont financés par le **pot commun de L'Alliance** (alimenté par les dons) - -**Résultat :** Le module est livré, les contributeurs sont récompensés, et toute L'Alliance en bénéficie. Collaboration pure! - ---- - -## 9. ANNEXES - -### Annexe A : Formulaire de déclaration de contribution - -**À remplir pour chaque contribution < 10h :** - -```yaml -# Formulaire de déclaration BDT -# À soumettre via pull request sur git.allianceboreale.ca/bdt/ - -date: "AAAA-MM-JJ" -contributeur: - nom: "[Ton nom / nom de ton OBNL]" - membre_id: "[M-XXXXX]" - -activite: - type: "[DevOps/SRE | Réseau/DNS | Backend/API | Gouvernance | UX/UI | Autre]" - description: | - [Description claire de ce que tu as fait] - - heures: [X.X] - multiplicateur: [1.0 à 1.5] - qualite: [1.0 | 1.1 | 1.2] - -beneficiaire: - type: "[Membre spécifique | L'Alliance | Projet collectif]" - nom: "[Nom si membre spécifique]" - membre_id: "[M-XXXXX si applicable]" - -preuves: - - "[Lien Git, doc, screenshot, rapport, etc.]" - - "[Autre preuve si nécessaire]" - -credits_demandes: [X.X] - -notes: | - [Tout commentaire additionnel] -``` - -**Où soumettre :** -Pull request sur `git.allianceboreale.ca/bdt/transactions/AAAA/MM/` - -**Validation :** -Automatiquement intégrée sous 48h si <10h et format correct. Sinon, validation par Cercle concerné. - ---- - -### Annexe B : Registre BDT (extrait fictif) - -```yaml -# Registre BDT - Extrait Octobre 2025 - -membres: - - membre_id: "M-00042" - nom: "TechCoopYUL" - label: "Or" - solde_actuel: 87.5 - total_genere: 142.0 - total_depense: 54.5 - derniere_activite: "2025-10-10" - - - membre_id: "M-00051" - nom: "NouvelleCoop" - label: "Bronze" - solde_actuel: 15.0 - total_genere: 25.0 - total_depense: 10.0 - derniere_activite: "2025-10-08" - -statistiques_globales: - total_credits_circulation: 2456.3 - total_membres_actifs: 23 - moyenne_credits_par_membre: 106.8 - contributions_mois: 47 - -pot_commun: - solde: 134.5 - alimenté_par: - - dons_membres: 89.0 - - cotisations_excess: 45.5 - utilise_pour: - - bonus_bienvenue: 50.0 (5 nouveaux membres × 10) - - projets_collectifs: 60.0 - - solidarite: 20.0 -``` - ---- - -### Annexe C : Tableau de conversion rapide - -**Pour les contributeurs :** - -| Activité | Heures | Multiplicateur | Crédits | -|----------|--------|----------------|---------| -| Config Proxmox simple | 4h | 1.5x | 6 | -| Config DNSSEC | 3h | 1.5x | 4.5 | -| Dev API endpoint | 5h | 1.3x | 6.5 | -| Atelier formation | 3h | 1.2x | 3.6 | -| Support utilisateurs | 2h | 1.0x | 2 | -| Réunion de cercle | 2h | 1.5x | 3 | -| Rédaction politique | 4h | 1.5x | 6 | -| Design interface | 6h | 1.3x | 7.8 | -| Audit technique complet | 18h | 1.5x | 27 | - ---- - -### Annexe D : FAQ Banque de Temps - -**Q1 : Puis-je vendre mes crédits BDT contre de l'argent ?** -**R :** Non, JAMAIS. Les crédits BDT ne peuvent pas être convertis en monnaie. C'est une règle fondamentale pour préserver l'esprit de solidarité et éviter la marchandisation. - ---- - -**Q2 : Que se passe-t-il si je quitte L'Alliance ?** -**R :** Tes crédits sont suspendus (mais non perdus). Si tu reviens dans les 2 ans, ils sont réactivés. Après 2 ans, ils sont transférés au pot commun. - ---- - -**Q3 : Puis-je refuser une demande d'aide même si j'ai les compétences ?** -**R :** Oui, absolument. Participer à la BDT est volontaire. Tu n'es jamais obligé d'accepter une demande. - ---- - -**Q4 : Comment sont valorisées les contributions partielles ?** -**R :** On compte en quarts d'heure (0.25h). Exemple : 1h30 de travail = 1.5h. - ---- - -**Q5 : Puis-je contribuer à des projets hors Québec ?** -**R :** Oui, si c'est pour un membre de L'Alliance ou pour L'Alliance elle-même, peu importe la géographie. - ---- - -**Q6 : Que faire si je ne suis pas d'accord avec le nombre de crédits attribués ?** -**R :** Voir section 7.3 - Résolution de litiges. Discussion amiable d'abord, médiation ensuite, arbitrage en dernier recours. - ---- - -**Q7 : Les crédits ont-ils une valeur monétaire équivalente ?** -**R :** Non, il n'y a pas de taux de change officiel. Cependant, on peut estimer qu'1 crédit BDT ≈ 8-10 $CAD de valeur d'entraide (basé sur les réductions de cotisation). Mais ce n'est qu'indicatif. - ---- - -**Q8 : Puis-je transférer mes crédits à une autre organisation ?** -**R :** Seulement si cette organisation est membre de L'Alliance. Les crédits restent dans l'écosystème de L'Alliance. - ---- - -**Q9 : Comment participer si je n'ai aucune des 5 expertises prioritaires ?** -**R :** Il y a plein d'autres façons de contribuer! Support utilisateurs, documentation, communication, participation à la gouvernance, etc. Tout est valorisé. - ---- - -**Q10 : La BDT est-elle obligatoire pour rester membre ?** -**R :** Non. Tu peux rester membre en payant ta cotisation monétaire sans utiliser la BDT. Mais tu te prives d'un outil formidable de solidarité et d'échange! - ---- - -### Annexe E : Historique des modifications de la Charte - -**Version 1.0 (12 octobre 2025)** -- Création initiale de la Charte BDT -- Définition des 5 expertises prioritaires avec multiplicateurs -- Intégration du modèle à 8 couches d'autopoïèse -- Processus de validation et utilisation des crédits -- Mécanismes de gouvernance et résolution de litiges - -**Prochaines révisions prévues :** -- Version 1.1 (Janvier 2026) : Ajustements après 3 mois d'expérimentation -- Version 2.0 (Octobre 2026) : Révision majeure après 1 an de fonctionnement - ---- - -**FIN DE LA CHARTE DE LA BANQUE DE TEMPS** - -*"Le temps partagé est la vraie monnaie de la solidarité."* - -🌲 **L'Alliance Boréale** -*Ensemble, cultivons l'abondance par l'entraide.* - ---- - -**Document 6 complété le 12 octobre 2025** -**Prochaine révision prévue : Octobre 2026** -**Version : 1.0**