- Ubuntu Server 24.04 LTS
- 4 vCPU, 8 Gio de mémoire, 64 Gio de stockage système
- Identité propre issue d'un clone complet du template Ubuntu Server
- Cloud-Init, SSH et agent invité validés
- OpenCode 1.18.25
- Hermes Agent 0.20.6
- Aucun modèle ni GPU local
- Installation et version d'OpenCode contrôlées
- Installation Hermes contrôlée par son diagnostic intégré
- Endpoint compatible OpenAI d'Ollama atteint depuis VM301
- Modèle
qwen3.6:35bdétecté par le client - Génération directe réussie
- Génération réelle OpenCode réussie avec le même modèle
- Génération réelle Hermes réussie avec
qwen3.6:35b— contexte servi de 65 536 tokens, jeu d'outils volontairement restreint - Benchmark OpenCode réussi sur des tâches Python, HTML et JSON n8n (revue et corrections ciblées si nécessaire)
Cette validation démontre la chaîne complète entre un agent de développement isolé et l'inférence locale accélérée par GPU.
VM301
├── Hermes Agent
├── OpenCode
└── API d'inférence autorisée sur le réseau privé
└── Ollama sur la VM GPU
└── modèles locaux chargés sur la RTX 5090La VM cliente reste légère. Le stockage des modèles, leur chargement en mémoire vidéo et les optimisations d'inférence restent centralisés sur le nœud GPU. L'API n'est pas publiée directement sur Internet et son accès est limité aux clients explicitement autorisés.
qwen3.6:35b est la référence validée pour Hermes, avec un contexte de
65 536 tokens.
qwen3-coder:30b est validé avec OpenCode pour les tâches de développement :
Python a réussi directement, tandis que HTML et JSON n8n ont chacun nécessité une correction ciblée
avant validation finale.
- Génération et maintenance de code Python
- Création de pages et composants HTML
- Production de données structurées JSON
- Préparation de workflows n8n
- Analyse de dépôts et modification multi-fichiers
- Rédaction de documentation technique
Les workflows n8n générés restent soumis à une validation humaine : contrôle syntaxique, import désactivé et revue avant toute activation, surtout en présence d'expressions, d'appels réseau ou d'identifiants.
- Aucun port d'inférence directement publié sur Internet
- Filtrage explicite des machines clientes
- Configuration cliente sans jeton lorsque l'endpoint privé n'en requiert pas
- Secrets, adresses et règles internes exclus de la source publique
- Futur accès distant prévu par tunnel privé authentifié, et non par ouverture du port Ollama
- Création reproductible d'une VM depuis un template assaini
- Installation et diagnostic de clients agentiques récents
- Intégration d'une API compatible OpenAI auto-hébergée
- Séparation entre poste agentique et calcul GPU
- Filtrage réseau selon le principe du moindre privilège
- Validation progressive d'une chaîne LLM complète
- Distinction documentaire entre état validé et expérimentation en cours
- la persistance applicative de VM301 doit encore être contrôlée après redémarrage ;
- la station de développement Windows est documentée séparément sur la page VM302, avec ses propres validations du 20 septembre 2026 — celles-ci ne valident pas la reprise de VM301 ;
- l'accès distant des postes clients devra passer par une architecture VPN dédiée et validée.