Le socle
Une seule fondation.
Toutes nos applications dessus.
Nous n’écrivons pas deux fois la même chose. Un framework commun pour le code, des packs pour les capacités partagées, une plateforme pour tout ce qui entoure une application, des agents légers qui la prolongent jusque chez nos clients, une interface commune et une fabrique qui fait naître chaque application de la même façon.
Pourquoi un socle
Une application métier passe une grande part de sa vie à refaire ce que toutes les autres ont déjà fait. Elle doit connecter ses utilisateurs, séparer ses clients, garder ses mots de passe, envoyer du courrier, obtenir des certificats, se sauvegarder, se superviser, journaliser, résister aux pannes de ses fournisseurs, s’ouvrir aux agents IA. Rien de cela n’est son métier, et tout cela doit être fait bien.
Nous avons fait ce travail une fois, et nous le faisons vivre. C’est le socle : un ensemble de briques que nous écrivons et maintenons nous-mêmes, sur lequel repose chacune de nos applications. Une nouvelle application consacre son temps à ce qui lui est propre.
Ce que le socle évite de réécrire, application après application :
- le squelette : démarrer, surveiller, relancer, arrêter proprement les traitements ;
- l’ouverture aux agents IA : chaque action d’une application est déjà un outil MCP ;
- l’identité : comptes, rôles, clients séparés, connexion unique, double facteur ;
- les secrets : un coffre-fort, aucun mot de passe dans le code ni dans la base ;
- l’exposition : proxy, noms de domaine, certificats, passerelle d’API ;
- le courrier, les fichiers, les agendas, la bureautique, la signature ;
- la résilience : coupe-circuits, nouveaux essais, limites de débit ;
- l’exploitation : tableau de bord, métriques, journaux, sauvegardes, livraisons ;
- les capacités métier récurrentes : IA générative, notifications, connecteurs, pipelines, référentiels.
Le socle en chiffres
- 5.11
La lignée actuelle du framework Socle V005 - 21
Workers intégrés au framework, 96 actions prêtes - 10
Packs de capacités partagées, 215 actions - 62
Workers dans le Hub, 497 actions - 148
Cas d’usage documentés pour écrire le code - 46
Guides pratiques pour consommer le Hub - 6
Hubs en service sur la même base de code - 35
Interfaces qui partagent le même cadre lmvi-ui
Les étages, de l’intérieur vers l’extérieur
Le socle se lit en étages. Chacun répond à une question différente, et chacun a sa page.
Le framework : comment s’écrit une application
Socle V005 donne la structure du code : des Workers autonomes, un orchestrateur, des actions ouvertes aux humains et aux agents, un bus, une base technique, des règles.
Les packs : quelles capacités elle embarque
Des bibliothèques qu’une application ajoute pour gagner une capacité entière sans la recoder.
Le Hub : ce qui l’entoure
La plateforme qui installe et fait tourner les applications, et leur rend tous les services communs.
Les agents de terrain : jusqu’où va la plateforme
minihub, miniMiniHub, gardien et socle-svc prolongent le Hub sur des machines de clients, sans ouvrir de porte chez eux.
L’interface : à quoi elle ressemble
lmvi-ui, un cadre d’écran unique, versionné, partagé par toutes les applications.
La fabrique : comment elle naît
Un cadrage, un gabarit, des fiches, une chaîne de livraison : de l’idée à la production par le même chemin.
Les briques, une par une
Le framework Java 21 orienté Workers : MOP, actions, KvBus, TechDB, JDM, pipelines, gRPC.
Comment un agent IA découvre et pilote une application, et toute la flotte par le Hub.
La plateforme : identité, secrets, API, DNS, courrier, fichiers, IA, sauvegardes.
Dix capacités embarquées : IA, notifications, connecteurs, éditorial, courrier, pipelines…
L’agent Java chez un client : un tunnel sortant, des applications sur place.
L’agent Go d’un seul fichier, sur une VM, dans Kubernetes ou sur un NAS Synology.
Le démon qui met à jour les agents par vagues et revient en arrière seul.
Une image Go, un conteneur par service : transcription, modèles, décisions, agents.
Le cadre d’interface unique de toute la flotte, et l’éditeur de décisions.
De l’idée à la production : cadrage, bootstrap, build, recette, même tag en production.
socle-host-terminal
Une console de la machine d’un minihub, dans le navigateur, relayée par le tunnel.
Les contrats gRPC
Les échanges entre le Hub et ses agents, versionnés dans un dépôt partagé.
Socle V005, le framework
Socle V005 est un framework Java 21, bâti sur Spring Boot et exécuté sur la machine virtuelle GraalVM. Nous l’écrivons et nous le maintenons ; il en est à sa lignée 5.11. Son idée centrale tient en une phrase : une application est un ensemble de Workers, et chacun fait une seule chose.
Un chef d’orchestre et des Workers
Le MOP (Main Orchestrator Process) démarre les Workers dans l’ordre, les surveille, relance celui qui tombe et arrête proprement l’ensemble. Aucun Worker ne se planifie lui-même.
Un Worker s’exécute à intervalle régulier, à heure fixe, ou seulement quand on l’appelle. Des gabarits existent pour chaque forme : appeler un service externe avec ses protections, scruter, planifier, réagir à des événements, consommer Kafka, agréger sur une fenêtre de temps, enchaîner des étapes, recevoir des webhooks, servir des pages.
Autour, le framework fournit un bus d’événements (le KvBus), une base technique embarquée (la TechDB), des tables de décision (JDM) et des scripts compilés à chaud (Janino), des pipelines typés, le gRPC entre socles, la résilience, un superviseur, un tableau de bord et des journaux structurés.
Il arrive avec vingt et un Workers intégrés, qui exposent d’emblée quatre-vingt-seize actions : le serveur web, le tableau de bord, la sauvegarde et la purge de la base technique, l’accès aux bases H2, PostgreSQL et MariaDB, le moteur de décisions, le moteur de règles, le serveur gRPC…
Tout le framework, brique par brique →
Des applications pilotables par un agent IA
Chaque Worker décrit ses actions une seule fois. Elles deviennent à la fois des points d’API REST et des outils MCP — le Model Context Protocol, le protocole ouvert qui permet à un agent IA de découvrir et d’appeler les outils d’une application.
Une action, deux portes
Un agent demande la liste des outils, lit leur description et leurs paramètres, et appelle celui qu’il lui faut. Chaque appel rend une enveloppe fixe et s’écrit dans le journal de l’application.
Le Hub, lui, rassemble les outils de toutes les applications installées derrière un seul point MCP, et ne montre à chacun que ce que ses droits lui permettent d’appeler. Toutes nos applications se pilotent donc aussi bien par un humain que par un agent.
Comment un agent pilote une application →
SocleHub, la plateforme
Le Hub est lui-même une application Socle V005, avec un rôle à part : il installe et fait tourner les autres, et leur rend tout ce qui les entoure. La règle de toute la flotte en découle : si le Hub rend un service, l’application le consomme ; elle ne le réimplémente pas.
Identité et clients
Comptes, rôles, portées, clés d’API, clients séparés (tenants), connexion unique devant chaque application, double facteur, fournisseur OIDC pour des applications tierces.
Secrets
Un coffre-fort Vault : un chemin de secrets par application, injecté au démarrage.
Exposition
Proxy inverse, cache, filtrage des robots d’attaque, passerelle d’API qui publie, distribue et révoque les clés.
Domaines et certificats
DNS piloté chez quatre fournisseurs, certificats Let’s Encrypt automatiques, plusieurs marques sur une même plateforme.
Courrier et agendas
Un serveur de courrier complet avec signature DKIM et chauffe des adresses neuves, des gabarits de messages, des agendas et carnets d’adresses partagés.
Fichiers et documents
Stockage d’objets avec quotas et partages, antivirus ClamAV, bureautique en ligne OnlyOffice, signature électronique, horodatage certifié.
Messagerie et données
Des files de messages durables (NATS) entre applications, un schéma PostgreSQL par application, des sauvegardes planifiées hors de la machine.
IA et automatisation
AgentIA, la passerelle vers les modèles avec quotas et tarifs par client ; Alfred, le majordome qui exécute des tâches écrites en langage naturel ; des salons où humains et agents échangent.
Applications et terrain
Catalogue et installation des applications en une action, point MCP unique, registre des agents de terrain, supervision de sources externes.
Six Hubs sont en service, sur la même base de code. Chacun des 497 gestes du Hub est une action, donc un outil pour un agent : installer une application, publier une API, vérifier un certificat, lire un journal.
Le parcours d’une requête
Chaque requête arrive au Hub. Il lit le nom demandé, écarte les sondes d’attaque connues, applique la connexion unique selon le mode de la route, puis pose lui-même les en-têtes qui disent à l’application qui est l’utilisateur, ses droits et son client — après avoir retiré ceux qu’aurait pu envoyer le navigateur. L’application n’a qu’à lire.
Tous les services du Hub, un par un →
Les socle-packs
Entre le framework et le Hub, il reste un étage : les capacités métier réutilisables. Un pack est une bibliothèque qu’une application embarque pour les gagner sans les recoder — ses Workers, ses actions, ses tables. Quand il manque quelque chose à un pack, on amende le pack, pas l’application : la correction profite à toutes.
IA générative
socle-pack-ai : modèles de langage de plusieurs fournisseurs, plongements, recherche augmentée, classification, lecture du web, agents. 10 Workers, 51 actions.
Notifications
socle-pack-comm : courriel, SMS, Telegram, Slack, webhook signé, notification dans l’application. 22 actions.
Connecteurs SaaS
socle-pack-connectors : Notion, Google Drive, Stripe, HubSpot. 54 actions.
Chaîne éditoriale
socle-pack-editorial : collecte RSS, tri par l’IA, validation humaine, lettres d’information. 31 actions.
Courrier de l’utilisateur
socle-pack-mail : import d’une boîte IMAP, Gmail ou Outlook, envoi depuis cette boîte, rédaction assistée, épuration. 17 actions.
Pipelines gouvernés
socle-pack-pipeline : graphes typés, validation, étape humaine, traçabilité, constructeur visuel. 24 actions.
Fiche société et sortie réseau
socle-pack-tenant lit la fiche du client courant depuis le Hub ; socle-pack-egress fait sortir les appels par une antenne de la plateforme, chiffrement de bout en bout.
Fichiers et référentiels
socle-pack-documents garde les fichiers reçus après antivirus, chiffrés ; socle-pack-referentiels charge les référentiels métiers ESCO et ROME 4.0.
Le gabarit
socle-pack-ZZ-TEMPLATE engendre un nouveau pack, avec des garde-fous testés contre les défauts déjà rencontrés.
Chaque pack, ses Workers et ses actions →
Prolonger la plateforme chez le client
Les données d’un client ne quittent pas toujours ses murs. Un modèle d’IA tourne parfois sur sa machine. Un NAS de bureau garde ses fichiers. Il faut alors que la plateforme aille jusqu’à lui, sans lui demander d’ouvrir son réseau. C’est le rôle de quatre briques, qui ont en commun de n’ouvrir que des connexions sortantes.
minihub, l’agent Java
Un agent Java posé sur un serveur du client. Il se crée une identité dont la clé privée ne quitte jamais la machine, ouvre lui-même un tunnel gRPC chiffré à authentification mutuelle vers le Hub, sur le seul port 443 en sortie, bat le cœur toutes les trente secondes et reçoit ses ordres par ce tunnel. Il fait tourner des applications sur place, que le Hub voit et appelle comme les siennes, et ouvre au besoin une console de la machine dans le navigateur — sans SSH.
miniMiniHub, l’agent Go
Un seul binaire Go d’environ 13 Mo, sans dépendance. Il se pose de trois façons : sur une machine virtuelle ou un serveur, en conteneur dans un cluster Kubernetes pour rendre appelables ses serveurs MCP internes, ou sur un NAS Synology pour servir un de ses services locaux. Il rend des services ciblés : une sortie Internet au chiffrement de bout en bout, l’envoi direct de courrier, des tâches planifiées, des outils sur la machine, un relais vers un service local. Sans permission, il n’exécute rien.
socle-gardien, le démon de mise à jour
Un démon Go installé une fois sur chaque machine qui porte un minihub ou un miniMiniHub. Toutes les trente minutes, il lit un manifeste signé, vérifie sa signature et son empreinte publiée dans le DNS, installe la nouvelle version par vagues, contrôle qu’elle tient, et revient en arrière tout seul sinon. Il se met à jour lui-même en dernier, avec un filet de secours.
socle-svc, le gabarit de services
Une seule image Go, instanciée une fois par service, qui porte tout le contrat : vérifier qui appelle, publier une route REST et un outil MCP par opération, transformer un appel long en tâche suivie. Un service n’écrit que son calcul — transcription, modèle de langage, décisions, relecture de code, agents IA. Il tourne sur processeurs Intel comme ARM.
Comment ces briques construisent les gardiens et la flotte
Ces briques s’emboîtent, et c’est leur assemblage qui fait une flotte.
Le Hub publie
Une nouvelle version d’agent est décrite dans un manifeste signé, dont l’empreinte est publiée dans le DNS.
Les gardiens vérifient
Sur chaque machine, le gardien contrôle la signature, l’empreinte DNS et celle de chaque fichier. Un seul écart, et il ne fait rien.
La machine témoin d’abord
La première vague ne touche qu’une machine témoin ; la flotte suit plus tard, si la version tient.
Les agents prouvent qu’ils tiennent
Un minihub doit battre le cœur vers chacun de ses Hubs, un miniMiniHub voir son battement acquitté par son parent — dans un délai fixé.
L’échec se défait seul
Sinon, l’ancienne version revient, la série s’arrête, et la version refusée n’est jamais retentée.
Le Hub observe et décide
Les gardiens rendent compte dans un salon du Hub, qui repère les muets et poste un bilan chaque matin. On ouvre la vague suivante en connaissance de cause.
Personne ne se connecte aux machines pour les mettre à jour. On publie, on observe, on décide.
Le même mécanisme sert des cas très différents : un modèle d’IA exécuté sur un serveur GPU local, des outils internes d’un cluster rendus appelables sans ouvrir le cluster, des agents IA planifiés sur des machines fermées, ou les vidéos d’un NAS de bureau lues par un serveur Jellyfin hébergé sur la plateforme, sans copie, sans port ouvert sur la box et sans mot de passe publié.
L’interface commune : lmvi-ui
Toutes nos applications partagent le même cadre d’écran. Il n’est plus recopié dans chacune : c’est une bibliothèque versionnée, @lmvi/ui, dont 35 interfaces dépendent. Elle fournit les mises en page, les barres de titre, d’activités et d’état, la palette de commandes, le thème et ses 25 palettes, un graphe, un studio de pipeline et des pièces de tableau de bord. Chaque application monte de version quand elle le décide.
À côté, lmvi-jdm-editor est un éditeur visuel de tables de décision, livré comme un composant web qui s’insère dans n’importe quelle page : les décisions qu’il dessine sont celles qu’exécute le framework.
La fabrique d’applications
Une application de la flotte ne part jamais d’une page blanche.
De l’idée à la production
Un cadrage écrit, sans code avant le go. Un gabarit, APP-ZZ-TEMPLATE, dont le script
bootstrap engendre en une commande le projet complet : code de départ, manifeste, image, livraison, chantier de la méthode, et les 148 fiches de cas d’usage recopiées dans l’application. Un dépôt Maven embarqué, mvn-repo/, pour qu’un clone frais compile sans rien installer. Des
StarterPacks et des UpgradePacks pour démarrer ou monter de version.
Puis la livraison : une image publiée, posée en recette, éprouvée preuves à l’appui, et le même tag promu en production — les mêmes octets que ceux qu’on a vérifiés.
Les outils transverses
socle-host-terminal
Une console de la machine d’un minihub, ouverte dans le navigateur, relayée par le tunnel et gRPC, avec le nom du demandeur dans l’audit. Aucun SSH.
Les contrats gRPC
Les échanges entre le Hub, les minihubs et les miniMiniHubs sont décrits dans un dépôt partagé : neuf services, quarante-six appels, versionnés.
Ce que le socle apporte
Le temps du projet va au métier
Identité, secrets, courrier, exposition, supervision : déjà là. Une application commence par ce qui la distingue.
Des corrections qui profitent à tous
Un défaut corrigé dans le framework, un pack ou le Hub l’est pour toutes les applications.
Toute la flotte ouverte aux agents
Chaque action de chaque application, et chaque geste du Hub, est un outil MCP, avec des droits vérifiés et un journal.
Pourquoi un framework maison plutôt qu’un cadre du marché ?
Socle V005 s’appuie sur des fondations du marché — Java 21, Spring Boot, GraalVM — et y ajoute ce qu’aucun cadre ne donne d’emblée : l’orchestration des Workers, les actions ouvertes aux agents IA par MCP, la base technique, les règles et la supervision, identiques dans toutes nos applications.
Toutes vos applications reposent-elles sur ce socle ?
Nos applications métier, oui : ce sont des applications Socle V005, qui consomment les services du Hub. Quelques services d’IA locaux de nos réalisations reposent sur d’autres techniques, choisies pour leur matériel.
Une application peut-elle tourner chez le client ?
Oui. Un minihub posé sur sa machine fait tourner des applications sur place, sans port entrant ; le Hub les voit comme les siennes.
Faut-il ouvrir son réseau pour les agents de terrain ?
Non. minihub, miniMiniHub et gardien n’ouvrent que des connexions sortantes.
Comment les agents de terrain sont-ils mis à jour ?
Par le gardien de chaque machine, sur manifeste signé et vérifié dans le DNS, par vagues, avec un retour arrière automatique.
Un agent IA peut-il tout faire sur la plateforme ?
Il ne voit et n’appelle que les outils que ses droits lui ouvrent. Une portée en lecture seule ne laisse passer que des actions sans effet, et chaque appel est consigné.
Qu’est-ce qui distingue un pack d’un service du Hub ?
Un pack s’embarque dans l’application et y ajoute des Workers ; un service du Hub tourne autour des applications, une fois pour toutes, et elles le consomment.
Comment une nouvelle application démarre-t-elle ?
Par un cadrage, puis par le gabarit de la fabrique, qui pose le projet complet en une commande.
Une application à construire ?
Elle part de ce socle : le temps du projet va à votre métier.