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, et des agents légers qui la prolongent jusque chez nos clients.

Une application métier passe la moitié de sa vie à refaire ce que toutes les autres ont déjà : la connexion des utilisateurs, la garde des secrets, l’envoi du courrier, les certificats, les sauvegardes, la supervision. Nous avons fait ce travail une fois, et nous le faisons vivre. Chaque nouvelle application consacre son temps à ce qui lui est propre.

Le socle se lit en quatre étages.

Le framework : Socle V005

Le cadre du code. Chaque application est faite de Workers, des unités de traitement autonomes, démarrées et surveillées par un chef d’orchestre commun.

Les packs

Des bibliothèques qu’une application embarque pour gagner une capacité sans la recoder : IA, communication, connecteurs, pipelines, référentiels métiers…

La plateforme : SocleHub

Le Hub fait tourner les applications et leur rend les services communs : comptes, secrets, courrier, certificats, stockage, sauvegardes.

Les agents de terrain

minihub, miniMiniHub et socle-gardien prolongent la plateforme sur les machines d’un client, sans ouvrir de porte entrante chez lui.

Socle V005, le framework

Socle V005 est un framework Java 21 (sur la machine virtuelle GraalVM) que nous avons écrit et que nous maintenons. Il en est à sa version 5.11. Son idée centrale est simple : une application est un ensemble de Workers, et chacun fait une seule chose.

Le MOP, chef d’orchestre

Le Main Orchestrator Process démarre les Workers dans l’ordre, les surveille, relance celui qui tombe et arrête proprement l’ensemble. Un superviseur décide quand insister et quand alerter.

Des actions MCP et REST

Chaque Worker expose ses actions par deux portes : une API REST classique, et MCP (Model Context Protocol), le protocole qui permet à un agent IA d’appeler une application. Toutes nos applications se pilotent donc aussi bien par un humain que par un agent.

Le KvBus

Un bus d’événements interne. Un Worker publie, un autre réagit, sans que l’un connaisse l’autre.

La TechDB et le tableau de bord

Une base technique embarquée garde les résultats, les états et les métriques. Un tableau de bord montre en direct l’état de chaque Worker.

Pipelines et règles

Des chaînes de traitement par étapes, des tables de décision (format JDM) et des scripts compilés à chaud (Janino) : une règle métier change sans redéployer l’application.

gRPC entre socles

Deux applications, ou deux machines, se parlent par contrats gRPC versionnés. Coupe-circuits, reprises et limites de débit sont fournis.

Le framework arrive avec son mode d’emploi : un gabarit qui engendre toute nouvelle application (APP-ZZ-TEMPLATE), 148 cas d’usage qui disent par quel mécanisme écrire chaque besoin, et 43 guides qui disent quel service de la plateforme consommer au lieu de le recoder.

Les socle-packs

Un pack est une bibliothèque qu’une application embarque pour gagner une capacité mutualisée. Quand il manque quelque chose à un pack, on amende le pack, pas l’application : la correction profite à toutes. Dix packs sont en service, plus le gabarit qui fabrique les suivants.

socle-pack-ai

IA générative, plongements vectoriels, recherche augmentée (RAG), classification, lecture du web et agents. 10 Workers, 51 actions.

socle-pack-comm

Communication multicanal : courriel, SMS, Telegram, Slack, webhook, notification dans l’application.

socle-pack-connectors

Connecteurs vers Notion, Google Drive, Stripe et HubSpot. 54 actions.

socle-pack-editorial

La chaîne éditoriale : collecte RSS, tri par l’IA, validation humaine, lettres d’information.

socle-pack-mail

Le courrier avancé : import d’une boîte IMAP, Gmail ou Outlook, envoi depuis la boîte de l’utilisateur, rédaction assistée.

socle-pack-pipeline

Des pipelines en graphe, typés et gouvernés : contrats d’entrée et de sortie, validation humaine, traçabilité, constructeur visuel.

socle-pack-documents

Les fichiers d’une application : analyse antivirus avant garde, chiffrement au repos, quotas.

socle-pack-referentiels

Les référentiels métiers européen ESCO et français ROME 4.0, avec leur table de correspondance.

socle-pack-tenant

La fiche société du client courant, saisie une fois, lue par toutes les applications.

socle-pack-egress

La sortie sur Internet par une antenne choisie de la plateforme, plutôt que par l’adresse de la machine.

SocleHub, la plateforme

Le Hub est lui-même une application Socle V005. Il fait tourner les autres et leur rend tout ce qui les entoure. Six Hubs sont en service, dont deux chez des clients.

Identité et accès

Comptes, rôles, clients séparés (multi-tenant), connexion unique (SSO) devant chaque application, double facteur.

Secrets

Un coffre-fort (Vault) : aucune application ne garde un mot de passe dans son code ou sa base.

Exposition

Proxy inverse, noms de domaine, certificats automatiques (ACME), cache, passerelle d’API (APIM) qui distribue et révoque les clés.

Courrier et agendas

Un serveur de courrier complet (James) avec signature DKIM, et des agendas partagés.

Fichiers et documents

Stockage d’objets, analyse antivirus (ClamAV), édition bureautique en ligne (OnlyOffice), signature électronique et horodatage.

Messagerie entre applications

Des files de messages durables (NATS) pour que les applications s’échangent du travail.

Sauvegardes

Planifiées, envoyées hors de la machine, et rejouées pour prouver qu’elles se restaurent.

IA et automatisation

Une passerelle vers les modèles d’IA avec quotas par client, Alfred, le majordome qui exécute des tâches écrites en français, et des salons où humains et agents échangent.

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. Il faut donc que la plateforme aille jusqu’à lui, sans lui demander d’ouvrir son réseau. C’est le rôle de quatre briques.

minihub

Un agent Java posé chez un client, sur un serveur, un poste ou un Mac. Il appelle lui-même le Hub par un tunnel chiffré à authentification mutuelle, s’enregistre, et fait tourner des applications sur place. Le Hub les voit et les appelle comme si elles étaient chez lui.

miniMiniHub

Un agent écrit en Go, un seul fichier de 12 Mo sans dépendance. Il se pose sur une machine virtuelle, tourne en conteneur dans un cluster Kubernetes, ou s’installe sur un NAS Synology. Il rend des services ciblés : une sortie Internet, l’envoi direct de courrier, des tâches planifiées, ou l’accès à des outils internes. Lui aussi appelle vers l’extérieur : aucun port entrant.

socle-gardien

Un démon Go installé une fois pour toutes 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, 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

Un gabarit de services en Go : une seule image, instanciée une fois par service, qui porte tout le contrat pour être joignable par la passerelle d’API et par MCP. Un service n’écrit que son calcul. Il tourne sur processeurs Intel comme ARM.

Ce que cela permet : une flotte qui se tient seule

Ces briques s’emboîtent. Le Hub publie une version ; les gardiens la déploient par vagues, en commençant par une machine témoin ; chaque minihub et chaque miniMiniHub bat le cœur vers le Hub ; un échec se défait sans intervention. Personne ne se connecte aux machines pour les mettre à jour. On publie, on observe, on décide d’ouvrir la vague suivante.

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, 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é.

Les outils transverses

lmvi-ui

Le cadre d’interface unique de toute la flotte. Une seule implémentation, versionnée, dont les applications dépendent, au lieu d’une copie dans chacune.

lmvi-jdm-editor

Un éditeur visuel de tables et de graphes de décision, livré comme un composant web qui s’intègre dans n’importe quelle page.

socle-host-terminal

Un terminal distant : depuis le navigateur, une console sur la machine d’un minihub, relayée par gRPC.

Contrats gRPC

Les contrats d’échange entre socles, versionnés dans un dépôt dédié et partagés par tous.

Une application à construire ?

Elle part de ce socle : le temps du projet va à votre métier.

Gérer mes cookies