Le composant BISCUIT — AI Edge Controller + Intelligent Hardware Hub

Dossier de conception V2 (août 2026). Le BISCUIT n’est pas un 5ᵉ CAS : c’est un contrôleur intelligent qui se branche sur le hub de chacun des 4 CAS existants (CAS 1/2/3/4) pour les rendre autonomes et auto-réparants.

Deux briques : Composant A = AIC (carte mère smartphone + agent IA léger) et Composant B = Intelligent Hardware Hub (MCU déterministe). Le nom « BISCUIT » désigne l’ensemble : un contrôleur compact que l’on enfiche entre le cerveau du boîtier et son hub USB.

1. Vision du produit

Le projet devient un contrôleur d’infrastructure edge compact dont le cerveau est une carte mère de smartphone Linux-compatible. Cette carte exécute un agent IA local, des modèles légers orientés tool-calling/raisonnement, et des outils Linux en ligne de commande. Elle pilote un second composant : l’Intelligent Hardware Hub, chargé des interfaces physiques, de l’alimentation, de l’USB, de l’UART, du reset et des mesures.

• Le Composant A n’est plus un serveur GPU lourd : c’est un AI Edge Controller (AIC).
• Le monitoring lourd est supprimé du chemin critique ; l’agent collecte à la demande via CLI, /proc, /sys, journalctl, dmesg, udev, netlink.
• Le Hub B conserve un MCU et un watchdog afin que la sécurité matérielle ne dépende jamais du LLM.
• Le système peut fonctionner hors cloud.
• A et B communiquent par USB-C / USB 3.x, USB4 ou Ethernet.
• Les cibles peuvent être des SBC, PC, smartphones et autres cartes compatibles.

2. Architecture cible

COMPOSANT A — AIC                          COMPOSANT B — INTELLIGENT HUB
┌─────────────────────────────────┐        ┌─────────────────────────────────┐
│ Carte mère de smartphone ARM64  │        │ MCU + USB MUX + Power/PD        │
│ Linux                           │◄──────►│ UART · GPIO · Sensors           │
│ ├─ CLI / Device Tools           │ USB-C  │ Watchdog                        │
│ ├─ Needle 2 (tool router)       │ USB4   └───────────────┬─────────────────┘
│ ├─ LFM2.5 (350M–2.6B selon RAM) │ Ethernet               │
│ ├─ MCP / Tool Registry          │                        ▼
│ ├─ Policy Engine                │              SMARTPHONES · SBC · PC
│ ├─ Device Manager               │
│ ├─ Recovery Engine              │
│ └─ Hub Gateway                  │
└─────────────────────────────────┘

3. Objectifs

4. Ce qui change par rapport à l’architecture précédente

5. COMPOSANT A — AI Edge Controller

Le Composant A est une carte mère de smartphone réutilisée comme calculateur edge. Elle doit être sélectionnée principalement pour son support Linux et ses interfaces, puis pour sa puissance IA.

5.1 Critères de sélection

5.2 Pourquoi une carte smartphone ?

• CPU ARM performant dans un très petit volume.
• NPU/GPU potentiellement exploitable pour l’inférence.
• RAM et stockage intégrés ; USB-C déjà présent ; Wi-Fi/Bluetooth intégrés.
• Consommation inférieure à une plateforme GPU de bureau.

5.3 Contraintes

• Le support Linux est le facteur critique.
• Un USB-C ne donne pas automatiquement accès au bootloader.
• Les drivers GPU/NPU peuvent être propriétaires ou incomplets.
• UART/test points peuvent nécessiter une carte d’interface.
• Le modem, la caméra et certains périphériques peuvent rester inutilisables sous Linux.
• Chaque carte doit avoir un profil matériel documenté.

6. Stack IA ultra-légère

Architecture IA à deux niveaux

Utilisateur / événement
        │
        ▼
    NEEDLE 2 (~45M)
        ├── action simple ───────► Tool
        └── problème complexe
                    │
                    ▼
            LFM2.5 350M/1.2B
                    │  si nécessaire
                    ▼
              LFM2.5 2.6B
                    │
                    ▼
             Tool Executor

L’objectif : ne réveiller le modèle plus lourd que lorsque le problème exige réellement du raisonnement.

7. Monitoring sans logiciel dédié lourd

Le monitoring devient une capacité native de l’agent : il interroge les interfaces Linux et le Hub au lieu de maintenir une stack d’observabilité lourde.

Commandes agentiques

agent status
agent devices
agent diagnose phone-01
agent diagnose sbc-03
agent logs sbc-03
agent usb status
agent power status
agent recover sbc-03
agent uart open phone-01
agent network diagnose
agent cluster status
agent explain last-error

Exemple de réponse

$ agent diagnose sbc-03
STATE: ERROR
Network: unreachable
Power: 5.1 W
UART: bootloader detected
Kernel: no heartbeat
Diagnosis: probable boot failure
Recovery: 1. collect UART  2. verify power
          3. controlled reset  4. wait for Linux heartbeat
Policy: allowed
Action: RESET
Verification: pending

8. COMPOSANT B — Intelligent Hardware Hub

Le Hub ne doit pas dépendre du LLM pour ses fonctions de sécurité. Il exécute les commandes physiques reçues via un protocole strict et expose son état au Composant A.

Hub
├─ MCU STM32H5/H7 ou RP2350
├─ USB Hub / USB MUX
├─ USB-C ports
├─ USB-PD controller
├─ Power switches / eFuse
├─ UART bridges
├─ GPIO / Reset
├─ Current / Voltage sensors
├─ Temperature sensors
├─ Watchdog
└─ Secure firmware update

Liaison A ↔ B

9. Protocole de contrôle

gRPC/Protobuf recommandé pour l’API structurée ; REST/WebSocket possible pour l’administration.

hub.list_devices()
hub.status()
hub.port_status(port)
hub.power_on(port)
hub.power_off(port)
hub.reset(device)
hub.serial_open(device)
hub.serial_read(device)
hub.measure_power(port)
hub.health()
hub.firmware_version()

⚠️ Le protocole ne doit jamais accepter une commande shell arbitraire envoyée directement au MCU.

10. Device Manager

11. Base de compatibilité

device_profile:
  model:
  vendor:
  soc:
  architecture:
  ram:
  storage:
  linux:
  kernel:
  bootloader:
  adb:
  fastboot:
  uart:
  usb:
  ethernet:
  power_profiles:
  recovery_methods:
  approved_images:
  approved_actions:
  known_errors:

Cette base est indispensable pour empêcher l’agent d’appliquer une procédure Linux/Android ou une image firmware incompatible.

12. Recovery Engine — boucle de contrôle

OBSERVE → COLLECT → INTERPRET → DIAGNOSE → POLICY CHECK → ACT → VERIFY → LEARN / LOG

1. Identifier précisément le périphérique.
2. Collecter alimentation, USB, réseau et console.
3. Collecter les logs disponibles.
4. Comparer l’état à un profil connu.
5. Classer l’erreur → choisir une procédure autorisée.
6. Vérifier la politique → exécuter → vérifier le résultat.
7. Arrêter et escalader si le nombre de tentatives dépasse la limite.

13. Sécurité

Règle fondamentale : le LLM propose, la politique décide, l’outil exécute.

LLM → Tool Call → Policy Engine
                    ├─ identity check
                    ├─ device profile
                    ├─ action allowlist
                    ├─ risk level
                    ├─ rate limit
                    └─ approval requirement
                 → Tool Executor → Linux / Hub

14. Ressources matérielles recommandées

15. Stratégie de sélection de la carte A

La meilleure carte n’est pas celle qui possède le plus grand SoC : privilégier le contrôle logiciel.

16. Scénario complet : smartphone auxiliaire en erreur

1. Hub détecte USB → 2. AIC identifie PHONE-01 → 3. Needle 2 sélectionne diagnose_device() → 4. Agent lit USB + UART + power → 5. LFM2.5 interprète les logs → 6. Policy Engine vérifie recovery → 7. Hub exécute reset contrôlé → 8. AIC attend heartbeat → 9. ADB/SSH disponible → 10. Health check → 11. Incident clôturé → 12. Rapport enregistré.

Si aucune récupération non destructive n’est disponible, le système s’arrête proprement et demande une intervention humaine selon la politique.

17. Ce qu’il faut absolument éviter

• Faire dépendre la sécurité électrique du LLM.
• Donner un shell root sans Policy Engine.
• Installer un monitoring lourd qui consomme la RAM destinée au LLM.
• Choisir une carte smartphone uniquement sur la puissance du SoC.
• Supposer que toutes les cartes Android peuvent démarrer Linux.
• Flasher une image sans profil matériel vérifié.
• Utiliser le modèle comme base de vérité au lieu des données système.
• Construire le Hub autour d’un simple hub USB non protégé.

18. Projets open source à étudier

19. Variantes et positionnement

20. Annexe — Spécification minimale du prototype

21. Intégration dans TUTORIAD (les 4 CAS)

Le BISCUIT se greffe sur le hub de chaque cas existant — il ne remplace ni le cerveau ni le hub :

Règle d’intégration : le BISCUIT est un périphérique du hub, pas un maître supplémentaire. Il expose son API (gRPC/REST) au dashboard et à node-control.sh. La sécurité électrique reste dans le MCU du Hub B, jamais dans le LLM.

📄 Source : dossier de conception BISCUIT V2 (août 2026).