01 — VISION : le concept en détail

1. L’objectif

Construire un boîtier passif qui s’associe à une première carte mère — devenue carte maîtresse (control-plane / cerveau) — et qui permet d’ajouter des cartes mères auxiliaires : cartes mères de smartphones (ARM64) et de PC (amd64). Les deux familles forment deux clusters distincts — PCs reliés par câble USB4/Thunderbolt ou switch Ethernet (sharding LLM), smartphones en WiFi (nœuds SLM individuels) — pilotés par le même cerveau et réunis au besoin par un routeur central, extensible par plugins USB.

Trois contraintes validées dans le cahier des charges :

1. 10+ ports serveurs, 6+ ports clés (logiciels / LLM), WiFi et Bluetooth en modules optionnels.
2. Contrôle des cartes mères sans aucun bouton physique (power / reboot / format / install par scripts).
3. Clés USB contenant des LLM portables qui exploitent la RAM des nœuds.

2. Architecture en 3 couches

┌────────────────────────────────────────────────────────────────────┐
│ COUCHE 1 · BOÎTIER = CERVEAU (control-plane)                       │
│   SBC (Zero 3E, Pi 4/5, Orange Pi…) · Debian ARM64 · ≥ 8 Go        │
│   ├─ k3s server (taint NoSchedule, aucun workload)                 │
│   ├─ PORT SERVEURS (base 5, plugins ×5) → 1 carte mère par port    │
│   ├─ PORT CLÉS (base 3, plugins ×3) → logiciels + LLM portables    │
│   ├─ (OPTIONNEL) DONGLE WIFI + BLUETOOTH (plugins ×1)              │
│   ├─ CONTRÔLE SANS CONTACT (adb/fastboot/SSH/WoL/PMM)              │
│   └─ MicroSD : etcd + état du cluster                              │
├────────────────────────────────────────────────────────────────────┤
│ COUCHE 2 · NŒUDS DE CALCUL                                         │
│   Nœuds ARM64 (smartphones)   → Debian ARM64 + k3s agent           │
│   Nœuds amd64 (PC)            → Proxmox VE (VMs) + k3s agent       │
│                                  ou Debian amd64 + k3s agent       │
├────────────────────────────────────────────────────────────────────┤
│ COUCHE 3 · RÉSEAU                                                 │
│   LAN local (switch) + Tailscale · une IP fixe par nœud            │
└────────────────────────────────────────────────────────────────────┘

Les 2 idées fortes

• Le boîtier ne calcule pas, il commande. Aucun workload ne tourne dessus (taint NoSchedule) : il est 100 % disponible pour orchestrer.
• Chaque carte mère a SON port. 1 port serveur = 1 nœud. Le boîtier voit chaque port comme un canal de contrôle (console série / ADB / SSH).

Bonus : un tel port expose aussi le bootloader (UART) → on peut débloquer, flasher, formater un téléphone même écran mort ou PIN verrouillé.

3. Architecture modulaire des ports (base + plugins)

Socle minimal + plugins empilables sur un bus d’extension (USB 3.0 + 5V + I2C d’identification) :

Total base : 8 ports (5 serveurs + 3 clés). WiFi/BT ne sont PAS dans la base. Extensible sans limite : chaque PLUG-SRV-5 ajoute 5 serveurs. hub-scan.sh lit l’ID I2C de chaque plugin et compte les ports réels tout seul.

Pourquoi USB-C host (pas gadget) ? Un SoC ARM n’a qu’un seul contrôleur USB OTG : il ne peut pas se faire passer pour 10 périphériques devant 10 cartes mères. Les 10 ports sont donc host-mode via un hub USB 3.0 — détail technique, mais qui explique toute la conception des ports.

4. Le choix du cerveau (SBC)

Exigence unique et non négociable : Ethernet Gigabit. L’etcd du control-plane a besoin d’un réseau stable, pas de WiFi.

8 Go de RAM minimum pour un control-plane confortable (etcd + API).

Pourquoi pas un Arduino ? Microcontrôleur sans MMU ni Linux → incapable de faire tourner k3s/etcd. Rôle possible : capteur/relais satellite USB. Pourquoi pas une carte smartphone ? 1 seul port USB, pas d’Ethernet, bootloader verrouillé. Elle reste un nœud de calcul, jamais le cerveau.

Variante Winux (interface Windows-like sur x86) : si le boîtier doit tourner sous Winux (Ubuntu x86-64, cf. winux.is), le cerveau devient forcément du x86-64 : LattePanda 3 Delta (carte nue) ou carte mère PC récupérée (mini-PC) + dock passif USB4 — toujours en custom case. Variante légère sans Winux : Armbian minimal + Raspberry Pi 5 8 Go (dashboard web remplace l’interface Windows-like, rouvre la porte à l’ARM). Les 4 cas sont détaillés dans la page Matériel.

5. Design du boîtier (physique)

Le boîtier contrôleur est une small enclos alu noir (~230×170×60 mm) avec :

• Face avant : 5 ports USB-C pour serveurs (base) + 3 ports USB-A pour clés, chaque port avec sa LED d’état ; emplacements de plugins sur les côtés.
• Face arrière : 1 port Ethernet Gigabit (le pilier du control-plane), 1 sortie Micro-HDMI (dashboard kiosque en local), 2 entrées DC (rail contrôleur isolé + rail serveurs séparés), 1 port USB du boîtier pour ses propres accessoires.
• Intérieur : la SBC (Zero 3E 8 Go) + les hubs USB port serveurs (host-mode)
  • le régulateur 5V/20A du rail serveurs (polyfuse par port) + un ventilateur 40 mm. Les PCs ne sont jamais alimentés par le boîtier (rail ATX dédié).

6. Les 3 rails d’alimentation (indispensables)

┌─ Rail 1 · Contrôleur : 5V/3A propre + UPS (jamais impacté) ──────────┐
┌─ Rail 2 · Ports serveurs : 5V/20A, polyfuse par port (1 court-circuit = 1 port) ┐
┌─ Rail 3 · PCs : alimentation ATX séparée ─────────────────────────────┐

Pourquoi : 10 phones × 2 A = 20 A sur un rail → chutes de tension, surtensions de charge qui réinitialisent le contrôleur (etcd corrompu), un court-circuit qui ferait tomber tout le boîtier. Toujours séparer.

7. Le port HDMI : attention, c’est une SORTIE

Le Zero 3E a une sortie Micro-HDMI (1080p60) → port HDMI du boîtier pour monitoring local (dashboard en kiosque sur un écran de rack).

⚠️ SORTIE uniquement. Regarder l’écran d’une carte mère = un capteur USB HDMI (dongle UVC, comme l’USBridge) branché sur un port serveur.

8. Ce qui suit

Le matériel (quoi acheter, coûts, conso) → Matériel. Tester en 2 semaines avec ~144 000 FCFA → MVP.

Détails techniques de conception : Architecture et Matériel.