Le socle · les services
Un service n’écrit que son calcul.
Le gabarit porte le reste.
Exposer un calcul — une transcription, un modèle d’IA, une décision — demande toujours la même plomberie : vérifier qui appelle, publier des routes, gérer les appels longs, parler MCP. socle-svc l’écrit une fois. Chaque service est un rôle de la même image.
À quoi il sert
Certains services ne sont pas des applications complètes : ils font un calcul, souvent sur une machine dotée d’un processeur graphique. Leur écrire à chacun un serveur, une authentification, des routes et une gestion des appels longs serait refaire dix fois la même chose.
socle-svc est un gabarit de services en Go : une image, un conteneur par service. L’image est construite une fois ; le rôle du conteneur se choisit à son démarrage. Le gabarit n’utilise que la bibliothèque standard de Go, sans aucune dépendance extérieure. L’image tourne sans droits d’administrateur, sur un seul port interne jamais publié sur la machine, et elle est construite pour les processeurs Intel comme ARM.
Le contrat que porte chaque service
Il vérifie qui appelle
Deux voies d’identité : un jeton signé par la passerelle d’API du Hub, vérifié contre ses clés publiques, ou l’identité posée par le Hub quand l’appel arrive par le tunnel d’un minihub.
Il publie ses routes
Une route de santé et le catalogue des outils, ouverts ; puis la description du service, une route par opération, et l’envoi de fichiers par morceaux.
Il parle MCP
Une porte MCP, avec les méthodes standard : se présenter, lister les outils, appeler un outil.
Une opération, trois usages
Une opération déclarée devient à la fois une route REST, un outil MCP et un schéma de validation de ses entrées.
Il gère les appels longs
Au-delà de vingt secondes, l’appel devient une tâche : le service répond aussitôt avec un identifiant à suivre.
Il partage la machine
Un verrou par processeur graphique empêche deux calculs de se marcher dessus.
Les rôles
Transcription
Le rôle stt transforme la parole en texte, sur la machine où il tourne.
Modèles de langage
Le rôle llm sert un modèle de langage.
Décisions KEV
Le rôle kev répond aux questions de décision : décider, répondre oui ou non, choisir, noter.
Relecture de code
Le rôle opencode relit du code en lecture seule et signale au plus douze défauts. Mesuré : environ deux sur trois sont réels.
Agents IA
Quatre harnais d’agents IA derrière un même contrat de treize opérations ; leur administration passe par une approbation, via le gardien de la machine.
Relais de modèle
Une interface compatible avec celle d’OpenAI — conversation avec outils, en flux — vers un modèle servi localement, avec le suivi de la consommation par appelant et par jour, et un plafond de concurrence.
Le rôle de relecture de code existe aussi en plusieurs instances sur un même minihub, et s’installe depuis le catalogue du Hub en deux applications, le moteur et le relecteur, sans script.
- 1
Image pour tous les services - 0
Dépendance hors de la bibliothèque standard de Go - 2
Architectures de processeur : Intel et ARM - 20 s
Au-delà, un appel devient une tâche suivie
Ce qu’il apporte
Un nouveau service en écrivant son seul calcul
Identité, routes, MCP, tâches longues, validation : déjà là.
Le même contrat partout
Tous les services se ressemblent : la passerelle d’API et les agents IA les appellent de la même façon.
Des services là où est la machine
Posés sur un minihub, ils tournent près du processeur graphique ou des données, et restent joignables depuis le Hub.
On le voit à l’œuvre dans KEV, une famille de petits modèles de décision servis par le rôle kev.
La suite du socle
Les services socle-svc tournent sur les machines des minihubs, que le gardien tient à jour.