Application Winux — nature du logiciel

Ce fichier répond à une seule question : qu’est-ce que cette application ?

Réponse en une phrase

L’écosystème s’organise en trois briques : la clé TUTORIAD PLAYSTORE (logithèque portable), la clé LLM « llm-orchestrator » — une plateforme d’exploitation et d’orchestration de LLM/SLM qui administre la flotte de cartes mères (smartphones ARM64 + PC amd64), depuis le boot d’une machine nue jusqu’au déploiement et à la supervision des modèles — et l’extension Agent IA intégrée à l’implémentation Winux, pilotable en clic ou en langage naturel.

Ce que l’application EST

• Une app, pas plusieurs. Le catalogue, le fit, les runtimes, le cluster, le provisioning bare-metal et l’agent IA sont des modules de la même application, pas des outils séparés. Tout se pilote depuis un seul Dashboard.
• Une app de gestion, pas un simple tableau de bord. Elle ne fait pas que afficher : elle installe, lance, arrête, déploie, approvisionne et surveille réellement les machines et les modèles.
• Une app Linux-first. Le cœur (Control Plane) tourne sur le boîtier Winux ; les nœuds (Linux/Android) exécutent les modèles.
• Une app hardware-aware. Elle détecte les capacités réelles de chaque appareil (CPU, RAM, GPU/VRAM, NPU, thermique, batterie) et en déduit le meilleur modèle, la meilleure quantification et le meilleur runtime.
• Une app à deux modes. Cluster : plusieurs machines coopèrent pour un workload distribué. Nœud individuel : chaque smartphone/Edge garde et exécute son propre LLM/SLM, même hors ligne.
• Un Agent IA en extension Winux. Le panneau « AI OPERATIONS AGENT » fait partie de l’implémentation Winux : il pilote la chaîne LLM via le langage naturel et un Tool Registry, avec approbation humaine pour les opérations sensibles.
• Une app capable de provisioning bare-metal. Le panneau « BARE METAL / PROVISIONING » transforme une machine nue en nœud Linux administré (boot USB/PXE/ UEFI HTTP, installation, enrôlement).
• Deux clés logicielles distinctes. La clé TUTORIAD PLAYSTORE (logithèque portable) et la clé LLM « llm-orchestrator » — gestion LLM complète (dashboard, catalogue, fit, runtimes, déploiement, monitoring) + les poids des modèles, montée en lecture-écriture : son état survit aux redémarrages. L’Agent IA n’est sur aucune des deux clés : c’est une extension de l’implémentation Winux, préparée par le pôle Logiciel et installée par l’équipe Électronique. Toutes deux sont distinctes de la clé de boot. Voir Architecture et Matériel.

Ce que l’application N’EST PAS

• Pas un ensemble de scripts disjoints. Les scripts du dossier scripts/ (node-control.sh, deploy-llm.sh, hub-scan.sh…) sont la fondation de calcul, pas l’application. L’application les embarque, ne se réduit pas à eux.
• Pas une vitrine passive. Aucune action ne se limite à un affichage : chaque écran du Dashboard déclenche une vraie opération sur la flotte.
• Pas une app cloud obligatoire. Tout fonctionne en local ; le catalogue et les modèles restent utilisables hors ligne.
• Pas un simple front sur kubectl. Kubernetes n’est qu’un mode d’exécution possible ; le cœur métier (catalogue, fit, runtimes, policies) lui est indépendant.

Organisation du projet : 2 équipes

Le projet est réparti entre deux équipes qui n’ont pas le même périmètre :

Règle de périmètre : l’équipe Électronique & Matériel livre le boîtier physique nu ET configure la couche système du cluster (rootage, OS, k3s, provisioning, contrôle des cartes). L’équipe Logiciel installe et exploite l’application de gestion (dashboard, catalogue LLM, agent IA, monitoring) par-dessus.

Concrètement : l’équipe matériel choisit et assemble le matériel compatible (cf. Matériel), installe l’OS et configure k3s (cf. Équipe Électro / Matériel) puis l’équipe logiciel y déploie l’application de gestion (cf. Équipe Logiciel).

Architecture résumée

┌──────────────────────────────────────────────────────────────┐
│  WINUX (boîtier maître) — Control Plane                      │
│                                                              │
│  ┌─────────────────────────────────────────────┐             │
│  │  LA MÊME APPLICATION DE GESTION             │             │
│  │                                             │             │
│  │  Dashboard (1 interface unique)             │             │
│  │   ├ Overview / Device Fleet / Clusters      │             │
│  │   ├ LLM/SLM Catalog + Fit Analyzer          │             │
│  │   ├ Runtime Manager / Deployment Center     │             │
│  │   ├ Monitoring / Logs / Alerts              │             │
│  │   ├ Users & Roles / Policies / Storage      │             │
│  │   ├ BARE METAL / PROVISIONING  (§65-66)     │             │
│  │   └ AI OPERATIONS AGENT       (§67-81)      │             │
│  │                                             │             │
│  │  Une seule API Gateway (REST + WebSocket)   │             │
│  └──────────────┬──────────────────────────────┘             │
└─────────────────┼────────────────────────────────────────────┘
                  │ réseau (TLS)
   ┌──────────────┴───────────────┐
   ▼ Data Plane — les nœuds        │
   ┌───────────┐  ┌───────────┐   │
   │ Agent     │  │ Agent     │   │
   │ Linux PC  │  │ Smartphone│   │
   │ runtimes  │  │ (Android) │   │
   │ modèles   │  │ modèles   │   │
   └───────────┘  └───────────┘   │

Statut actuel vs cible

Cette page résume la nature de l’app ; le détail des missions se trouve sur la page Équipe Logiciel.

Pages liées

• Équipe Logiciel — feuille de route complète des missions
• Installation — monter l’infrastructure pas à pas
• Opération — piloter le cluster au quotidien
• Matériel — la clé autonome « llm-orchestrator » et les autres clés