Kohinos v3 Doc générée le 2026-05-19 commit 8d60b1904

Raspberry Pi & low-tech — déploiement à domicile

Kohinos n'est pas un SaaS. La cible naturelle d'une MLCC (Monnaie Locale Complémentaire Citoyenne) est un déploiement à domicile, sur du matériel modeste, auto-hébergé, branché sur la box internet de l'association ou d'un bénévole. Un Raspberry Pi 4 ou 5 suffit largement : sobriété matérielle = sobriété énergétique = résilience face aux pannes et aux dépendances cloud. Cette page décrit le hardware recommandé, les optimisations indispensables, et la roadmap mesh (Reticulum/LoRa) pour fonctionner même sans internet.

Pourquoi auto-héberger une MLCC ?

Une monnaie locale est par définition locale : la souveraineté sur les flux et les soldes ne doit pas dépendre d'AWS, OVH ou Hetzner. Un Pi posé chez la trésorière, dans un local associatif, ou dans un FabLab du territoire, c'est cohérent avec l'esprit du projet. C'est aussi la priorité 2 du global.md : souveraineté.

1. Hardware recommandé

Composant	Recommandation	Pourquoi	Prix indicatif
SBC (carte mère)	Raspberry Pi 5 — 8 Go RAM	Recommandé pour MLCC jusqu'à ~5000 adhérents. CPU ARM Cortex-A76 4 cœurs, PCIe pour SSD NVMe via HAT.	~85 €
SBC (alternative)	Raspberry Pi 4 — 4 Go RAM	Suffisant pour MLCC < 1000 adhérents. À éviter si la BDD dépasse 2 Go.	~55 €
Stockage	SSD USB 3.0 — 256 Go min., 512 Go recommandé	JAMAIS sur carte microSD pour la base Doctrine. Voir section anti-patterns.	~45 € (512 Go)
Alimentation	Bloc officiel Pi 5 (27 W, USB-C PD)	Sous-alimentation = throttling + corruption SSD. Pas de chargeur smartphone aléatoire.	~12 €
Onduleur (UPS)	600 VA (Eaton, APC) — petite capacité	Protège des coupures EDF brèves. 5 à 10 min d'autonomie suffisent pour un shutdown propre du SGBD.	~55 €
Boîtier	Passif (Argon NEO, FLIRC) ou ventilé silencieux	Dissipation thermique impérative — un Pi qui throttle perd 30 % de perf.	~20 €
Réseau	Switch Gigabit + câble RJ45 cat.6	Ethernet > WiFi pour un serveur fixe. Latence et stabilité décisives.	~20 €
Carte microSD	SanDisk Industrial 32 Go (boot uniquement)	Sert juste à amorcer le système, vrai stockage sur SSD. Une microSD bas de gamme meurt en 6 mois.	~15 €

2. Coût total — BOM (Bill of Materials)

Poste	Détail	Coût
Hardware one-shot	Pi 5 8 Go + alim + SSD 512 Go + UPS + boîtier + switch + microSD boot	~250 €
Énergie annuelle	~5 à 10 W moyen × 8760 h × 0,20 €/kWh	~15 €/an
Internet	Box déjà en place (mutualisée avec usage personnel/associatif)	0 €/an additionnel
Nom de domaine	.fr ou .org (Gandi, OVH, Hetzner DNS)	~10 €/an
TLS	Let's Encrypt (certbot)	0 €
Total premier exercice		~275 €
Total années suivantes		~25 €/an

Comparatif VPS x86 mutualisé

Un VPS équivalent en perf (4 vCPU, 8 Go RAM, 100 Go SSD) coûte 15 à 25 €/mois TTC, soit 180 à 300 €/an, indéfiniment. Le Pi est amorti en ~14 mois — sans compter l'autonomie politique (pas de migration forcée, pas de hausse tarifaire).

3. OS & installation logicielle

OS : Debian Bookworm 64-bit (Raspberry Pi OS Lite ARM64). Pas de Desktop, pas de Snap, pas de NetworkManager — systemd-networkd suffit.
PHP 8.4 : dépôt Sury (Ondřej Surý) qui compile pour ARM64. Alternative : compilation manuelle avec --enable-zts désactivé.
MariaDB 10.11 LTS ARM64 — paquet Debian standard. Stable et maintenu jusqu'en 2028.
Nginx ARM64 — plus léger qu'Apache sur Pi (moins de RAM par connexion grâce à l'IO asynchrone).
PHP-FPM : pool dédié, pm = ondemand, pm.max_children = 8 (Pi 5) ou 4 (Pi 4).
Pas de Docker en prod sur Pi. Overhead inutile sur ARM64, runtime natif suffit. Docker reste OK en dev.

La procédure pas-à-pas est dans installation.html : les commandes apt sont identiques sur Pi, seul le repo Sury est ajouté pour PHP.

4. Optimisations Pi-spécifiques

4.1 SSD obligatoire pour la base

# Migrer rootfs et /var/lib/mysql sur SSD
# Boot reste sur microSD (firmware) — root sur SSD via cmdline.txt
sudo nano /boot/firmware/cmdline.txt
# Remplacer root=PARTUUID=... par root=/dev/sda2 rootwait

# Vérifier que MariaDB pointe bien sur le SSD
sudo systemctl stop mariadb
sudo rsync -av /var/lib/mysql/ /mnt/ssd/mysql/
# Modifier datadir dans /etc/mysql/mariadb.conf.d/50-server.cnf
datadir = /mnt/ssd/mysql
sudo systemctl start mariadb

4.2 Préserver le SSD (write amplification)

# /etc/sysctl.d/99-kohinos.conf
vm.swappiness = 10          # quasi pas de swap (SSD = écritures coûteuses)
vm.dirty_ratio = 10
vm.dirty_background_ratio = 5
fs.inotify.max_user_watches = 524288

# /etc/fstab — tmpfs pour /tmp et /var/log volatile
tmpfs   /tmp        tmpfs   defaults,noatime,size=256M    0  0
tmpfs   /var/log    tmpfs   defaults,noatime,size=128M    0  0

⚠ tmpfs sur /var/log = logs perdus au reboot

Si /var/log est en tmpfs, configurer Monolog (côté Kohinos) pour pousser les logs critiques (SEPA, SSA, transactions) vers un fichier hors tmpfs (/mnt/ssd/log/kohinos/) ou vers un syslog distant. Voir monitoring.html. Le binlog MariaDB doit lui aussi vivre sur le SSD pour permettre la restauration PITR : voir backup-restore.html.

4.3 Désactiver le superflu

# /boot/firmware/config.txt
dtoverlay=disable-bt              # Bluetooth off
dtoverlay=disable-wifi            # WiFi off si Ethernet présent
gpu_mem=16                        # GPU à 16 Mo (pas d'affichage)
disable_splash=1
boot_delay=0

# Services inutiles
sudo systemctl disable bluetooth.service
sudo systemctl disable hciuart.service
sudo systemctl disable avahi-daemon.service     # mDNS, optionnel
sudo systemctl disable triggerhappy.service     # GPIO events, inutile pour serveur

4.4 Throttling thermique

# Surveiller en temps réel
vcgencmd measure_temp
vcgencmd get_throttled        # 0x0 = nominal, autre = throttling actif

# Limite à surveiller : 80°C en charge soutenue = boîtier sous-dimensionné

5. Réseau & exposition

IP fixe sur LAN : réservation DHCP par MAC dans la box, ou configuration statique dans /etc/systemd/network/.
Wireguard pour l'accès SSH/admin (jamais SSH exposé en clair sur Internet). Détails dans securite-serveur.html.
DynDNS si l'IP box est dynamique : DuckDNS (gratuit), Hetzner DNS API, ou OVH. Script de mise à jour en cron tous les 5 min.
Port forwarding sur la box : 443 → Pi:443 et 80 → Pi:80 (redirige vers HTTPS). Pas d'autre port ouvert vers l'extérieur.
Backup tunnel : clé 4G/LTE USB en failover si la box tombe (utile en environnement associatif où le débit fibre n'est pas garanti). Le Pi peut basculer automatiquement avec mwan3 ou un script simple.

5.1 Diagramme réseau type

┌─────────────────────────────────────────────────────────┐
│  Internet                                               │
│     │                                                   │
│     ▼  IP publique dynamique (DuckDNS → kohinos.duckdns)│
│  ┌─────┐                                                │
│  │ Box │  port forwarding 80/443                        │
│  └──┬──┘                                                │
│     │                                                   │
│  ┌──┴────────────────┐                                  │
│  │ Switch Gigabit    │                                  │
│  └──┬─────────┬──────┘                                  │
│     │         │                                         │
│  ┌──▼──┐   ┌──▼─────────┐                               │
│  │ Pi5 │   │ NAS (rsync)│  ← backup local quotidien     │
│  │ UPS │   │   2 To     │                               │
│  └─────┘   └────────────┘                               │
│     │                                                   │
│     ▼  (Wireguard tunnel pour admin)                    │
│  Laptop trésorière                                      │
└─────────────────────────────────────────────────────────┘

6. Sauvegarde Pi-friendly

Le plan complet est dans backup-restore.html. Pour une cible Pi, les particularités sont :

Rsync incrémental vers un NAS local (Synology, OMV sur autre Pi, ou Mini PC) — exécution quotidienne à 03h00.
Offsite chiffré : disque dur USB par mois rotatif (3 disques tournants chez 3 membres différents), chiffré luks2 + Argon2id.
Snapshots btrfs ou zfs sur le SSD si le filesystem le supporte — restauration en quelques secondes en cas de mauvaise migration Doctrine.
mysqldump + binlog binaire pour PITR (Point-In-Time Recovery) jusqu'à la dernière transaction SEPA.
Test mensuel de restauration sur un second Pi (ou un VM) : un backup non testé n'est pas un backup.

7. Résilience hors-réseau

⚠ Continuer à fonctionner quand le monde tombe

Une MLCC doit survivre à :

Coupure internet : Kohinos doit rester accessible sur le LAN (trésorerie, comptoirs locaux). Pas de dépendance CDN externe, pas de Google Fonts en runtime, pas d'auth fédérée obligatoire.
Coupure courant : l'UPS donne 5-10 min, suffisant pour un shutdown propre (MariaDB flush + sync SSD). nut ou apcupsd déclenche l'arrêt automatique à 20 % de batterie.
Sinistre majeur (incendie, vol) : backup offsite chiffré (cf. backup-restore.html) garantit une reprise sur un Pi neuf en moins d'une journée.
Effondrement réseau régional : roadmap Reticulum / LoRa pour fonctionner en mode mesh hors-internet, avec signatures Ed25519 et chiffrement Curve25519 (cf. dev/cryptographie.html). Les transactions s'accumulent localement et se synchronisent quand la liaison radio remonte.

7.1 Mode dégradé LAN-only

# Tester périodiquement (mensuel) : couper l'uplink box et vérifier
# que l'interface Kohinos reste accessible depuis le LAN
# - http://kohinos.local (mDNS) ou http://192.168.x.y
# - login trésorier OK
# - paiement comptoir OK (pas de webhook externe attendu)
# - cron SSA s'exécute, alertes Monolog enregistrées localement

8. Monitoring matériel

Voir monitoring.html pour le stack complet (Prometheus + Grafana ou alternatives plus légères). Côté Pi, les seuils critiques sont :

Métrique	Outil	Seuil d'alerte
Température CPU	`vcgencmd measure_temp`	> 70 °C sustained
Throttling	`vcgencmd get_throttled`	≠ 0x0
SSD SMART	`smartctl -a /dev/sda`	CRC errors > 0, Wear > 80 %
RAM	`free -m` ou node_exporter	> 80 % sustained > 5 min
Charge système	`uptime`	load > nb_cœurs sustained
UPS batterie	`nut` / `apcaccess`	< 80 % charge, ou mode batterie
Disponibilité services	Uptime Kuma (local, ~30 Mo RAM)	HTTP 5xx ou timeout

9. Anti-patterns à éviter

⛔ Ce qui tue un Pi en production

Base Doctrine sur carte microSD : corruption garantie en 6-12 mois. Les microSD ne sont pas conçues pour le pattern d'écriture d'un SGBD.
Pi 3 ou Pi Zero : RAM insuffisante (1 Go), CPU 32-bit problématique pour les calculs bcmath sur grosses sommes.
Hébergement chez FAI grand public sans port forwarding correct : IP CGNAT ou bridée → utiliser un VPS de rebond Wireguard ou un tunnel Cloudflare Tunnel (à l'extrême limite de la priorité 2, à valider en revue).
Pas d'UPS sur un Pi exposé au public : une coupure EDF en plein milieu d'un cron SEPA = état de transaction incohérent.
WiFi pour le serveur : latence variable, déconnexions régulières du driver brcm. Toujours Ethernet.
Boîtier sans dissipation : throttling silencieux, perf qui s'effondre en été sans qu'on comprenne pourquoi.
Pas de logs hors tmpfs : si /var/log est en tmpfs et qu'on n'envoie rien ailleurs, le post-mortem d'un crash devient impossible.
Compiler PHP en mode debug : opcache mal configuré + xdebug chargé = perf divisée par 5.

10. Sobriété mesurable

Quelques ordres de grandeur que la doc utilisateur peut citer pour justifier le choix auprès de l'AG :

Conso électrique : ~10 W moyen pour un Pi 5 chargé vs ~60 W pour un VPS x86 équivalent (côté datacenter, hors PUE et refroidissement) → division par 6 de la consommation directe.
Émissions GES : ~3 kg CO₂eq/an pour le Pi (mix électrique français ~50 g/kWh) vs ~50 à 150 kg CO₂eq/an pour un VPS cloud incluant le PUE datacenter et la fabrication amortie.
Pas de climatisation : le Pi tient dans une pièce non climatisée jusqu'à 35 °C ambiant. Pas de salle serveur, pas de free-cooling.
Recyclage : composants ARM standards, pas de boîtier propriétaire scellé, durée de vie attendue 5-8 ans, reprise possible en kit éducatif en fin de vie chez un FabLab local.
Réversibilité : l'instance entière (BDD + uploads + config) tient sur un SSD de 512 Go. Migrer vers un autre Pi = brancher le SSD et booter.

11. Checklist déploiement Pi

[ ] Pi 5 8 Go acheté, alim officielle, boîtier ventilé/passif
[ ] SSD USB 3.0 testé (badblocks), monté sur /mnt/ssd
[ ] microSD boot flashée avec Raspberry Pi OS Lite ARM64
[ ] Hostname défini (ex: kohinos-prod.local)
[ ] IP fixe LAN (réservation DHCP ou config statique)
[ ] SSH par clé uniquement, port 2222, pas de root login
[ ] Wireguard configuré, port UDP exposé (ou pas, si via VPS rebond)
[ ] Port 80/443 forwardés vers le Pi sur la box
[ ] DynDNS opérationnel (DuckDNS update toutes les 5 min)
[ ] Let's Encrypt certbot installé + renewal cron
[ ] PHP 8.4 + extensions (cf. installation.html)
[ ] MariaDB 10.11 LTS, datadir sur SSD, binlog activé
[ ] Nginx + PHP-FPM pool dédié, pm = ondemand
[ ] /tmp et /var/log en tmpfs, logs Kohinos sur SSD
[ ] swappiness=10, dirty_ratio=10
[ ] UPS branché, nut configuré, shutdown auto à 20 % batterie
[ ] vcgencmd surveillé (cron mensuel, alerte si throttling)
[ ] SMART du SSD surveillé hebdomadaire
[ ] Backup rsync nocturne vers NAS local
[ ] Disque offsite chiffré préparé chez membre tiers
[ ] Restauration testée sur un second Pi (mensuel)
[ ] Doc remise à la trésorerie : runbook + contacts + accès

Le runbook opérationnel (incidents fréquents, redémarrage, escalade) est dans runbooks.html.