Le socle · les agents de terrain
Les données restent chez le client.
Le Hub vient à elles.
Le minihub est un agent posé sur une machine que la plateforme ne possède pas. Il ouvre lui-même un tunnel chiffré vers le Hub, s’y enregistre, et fait tourner des applications sur place. Aucune porte n’est ouverte chez le client, aucun SSH n’est nécessaire.
À quoi il sert
Une application ne tourne pas toujours sur la plateforme. Les données d’un client doivent parfois rester dans ses murs. Un modèle d’IA tourne sur un serveur GPU local. Une machine est derrière un routeur qui n’accepte aucune connexion entrante. Il faut alors que la plateforme aille jusqu’à elle — sans recopier sur chaque site l’annuaire, le coffre, le DNS ou les certificats.
Le minihub répond à ce besoin. C’est un agent Java 21, construit sur le framework Socle V005, qui se pose sur un serveur Linux du client. Le Hub reste la référence pour l’identité, les secrets, les noms et les certificats ; le minihub les consomme à distance et fait tourner les applications sur place.
Son premier usage : un serveur GPU qui servait un modèle d’IA à la passerelle AgentIA du Hub. Le trafic passe désormais par le tunnel, où chaque échange peut être audité.
Comment il marche
Le Hub émet un jeton d’enrôlement
Un jeton à usage unique, lié au nom court de la machine et au client auquel elle appartient.
Le minihub se crée une identité
Il génère lui-même sa paire de clés et sa demande de certificat. La clé privée ne quitte jamais la machine. Le Hub fait signer la demande par l’autorité de certification de son coffre-fort.
Il ouvre le tunnel, vers l’extérieur
Une connexion sortante vers le port 443 du Hub, en gRPC sur HTTP/2, avec une authentification mutuelle par certificats (mTLS). Côté Hub, le tunnel est servi par le serveur web existant : aucun port de plus.
Il bat le cœur
Un battement toutes les trente secondes. Sans nouvelles depuis 90 secondes, le Hub le déclare dégradé ; après 180 secondes, injoignable. Après quatre battements ratés, le minihub recycle lui-même ses connexions.
Il reçoit des ordres
Le Hub pousse ses commandes dans un flux de longue durée : déployer, arrêter, relancer une application, relayer une requête HTTP vers un conteneur, rendre un état, publier le catalogue des outils MCP locaux.
Il sert les applications
Une requête suit le chemin navigateur, Hub, tunnel, minihub, conteneur. Les applications locales ne publient aucun port sur la machine : le Hub ne se connecte jamais directement à elle.
Si le tunnel tombe, le minihub se reconnecte seul, avec une attente qui croît d’une à soixante secondes, légèrement aléatoire pour que toute une flotte ne se rue pas au même instant.
Ce qu’il sait faire
Faire tourner des applications
Installer, arrêter, relancer, mettre à jour une application Docker par la voie gérée du Hub, qui la voit et la pilote comme les siennes.
Exécuter une commande sans SSH
Une commande shell envoyée par le tunnel, auditée. Désactivée par défaut, activée machine par machine.
Servir plusieurs Hubs
Un même agent peut être rattaché à plusieurs Hubs, avec une identité et des droits distincts pour chacun. Une application tourne une fois et s’expose sur plusieurs domaines.
Porter plusieurs instances
Une même application peut tourner en plusieurs exemplaires sur un minihub, chacun avec ses données, chacun visible séparément.
Accueillir des miniMiniHubs
Il sert de parent aux miniMiniHubs : il relaie pour eux la sortie Internet, le courrier, les tâches planifiées, les commandes et leur journal, et garde un an la trace de leurs connexions.
Sur quoi il repose
Le minihub et le Hub se parlent par des contrats gRPC communs, versionnés dans un dépôt dédié : battement et flux de commandes, pilotage des applications, services du Hub consommés à distance (vérifier un jeton, lire un utilisateur, contrôler une portée, lire ou écrire un secret, demander un certificat, mettre à jour un enregistrement DNS), trafic HTTP par le tunnel, remontées d’état. Ce dépôt compte neuf services et quarante-six appels.
Sur la machine, l’installation lance cinq conteneurs : le minihub, une base PostgreSQL, Redis, une file NATS et la console hôte. Il suffit du port 443 en sortie ; aucune règle entrante. Le script d’installation se rejoue sans dommage. Une machine Linux avec 4 Go de mémoire, 20 Go de disque et Docker suffit.
Ses mises à jour ne demandent personne : le gardien de la machine les applique par vagues et revient en arrière seul si la nouvelle version ne tient pas : socle-gardien →
- 443
Le seul port, en sortie - 30 s
Entre deux battements de cœur - 4
Workers Socle V005 dans l’agent - 46
Appels gRPC dans les contrats communs
Ce qu’il apporte
Aucune porte chez le client
Tout part de la machine du client vers le Hub. Son pare-feu reste fermé.
La plateforme sans la recopier
Annuaire, coffre, DNS et certificats restent au Hub ; le site distant les consomme.
Une machine pilotée à distance
Applications, commandes, console : tout passe par le tunnel, audité, sans SSH.
Il sert des cas variés : un modèle d’IA servi depuis un serveur GPU local, un service de plongements vectoriels (Embeddings), une régie, des services du gabarit socle-svc, un moteur de décision publié sur la passerelle d’API.
Faut-il ouvrir un port chez le client ?
Non. Le minihub n’ouvre qu’une connexion sortante vers le Hub, sur le port 443.
Que se passe-t-il si la connexion tombe ?
Le minihub se reconnecte seul. Le Hub le voit passer en dégradé puis en injoignable, et le retrouve dès le retour du tunnel.
Qui met à jour le minihub ?
Le gardien installé sur la même machine, à partir d’un manifeste signé, par vagues, avec retour arrière automatique.
Les autres agents de terrain
Plus léger que le minihub, le miniMiniHub se pose partout ; le gardien les tient à jour.