Le socle · la plateforme
Tout ce qui entoure une application,
rendu une seule fois.
Une application ne devrait jamais réécrire la connexion des utilisateurs, la garde des secrets, l’envoi du courrier ou les certificats. Le Hub les rend à toutes, et les fait tourner. Une application consomme un service du Hub ; elle ne le réimplémente pas.
À quoi il sert
SocleHub est une application Socle V005 comme les autres — en version 3.86, sur la lignée 5.11 du framework — avec un rôle à part : il héberge les autres applications et leur rend les services communs. Six Hubs sont en service, sur la même base de code, certains chez des clients.
Une règle guide tout le développement de la flotte, et elle vient en premier : avant d’écrire une ligne, se demander si le besoin est déjà un service du Hub. Si oui, on le consomme. Pas d’annuaire maison, pas d’envoi de courrier maison, pas de coffre à secrets maison, pas de passerelle d’API maison. 46 guides pratiques disent, service par service, comment le consommer.
- 62
Workers propres au Hub - 497
Actions qu’ils exposent, en REST et en MCP - 18
Schémas PostgreSQL, un par grand service - 46
Guides pratiques pour consommer ses services
Les services, d’un coup d’œil
Identité et clients
Comptes, rôles, portées, clés d’API, clients séparés (tenants), fournisseur OIDC, double facteur.
Secrets
Un coffre-fort Vault, un chemin de secrets par application.
Passerelle d’API
Publication d’une API, clés distribuées et révoquées, règles et facturation.
Exposition
Proxy inverse, connexion unique, cache, filtrage des robots d’attaque.
Domaines et certificats
DNS piloté chez quatre fournisseurs, certificats automatiques, plusieurs marques sur une plateforme.
Courrier
Un serveur de courrier complet, des gabarits de messages, la chauffe des adresses neuves.
Fichiers
Stockage d’objets, antivirus, bureautique en ligne, signature électronique, horodatage.
Messagerie entre applications
Des files de messages durables pour que les applications s’échangent du travail.
Données et sauvegardes
Un schéma de base par application, des sauvegardes planifiées hors de la machine.
IA et automatisation
Une passerelle vers les modèles d’IA, Alfred le majordome, des salons humains-agents.
Applications
Catalogue, installation, mise à jour, journaux, un point MCP unique pour toute la flotte.
Terrain et supervision
Registre des agents de terrain, sorties Internet, supervision de sources externes.
Le parcours d’une requête
Le Hub lit l’adresse demandée
Chaque requête arrive au Hub. Il regarde le nom demandé : une page du Hub, une application inscrite dans sa table de routage, ou rien de connu.
Il écarte les robots d’attaque
Un garde-fou repousse les sondes connues — recherche de pages PHP, de fichiers cachés, motifs d’attaque classiques — avant qu’elles n’atteignent une application.
Il applique la connexion unique
Chaque route a son mode : ouverte, gardée, facultative ou obligatoire. En mode obligatoire, un visiteur non connecté part à la page de connexion et revient ensuite à sa page.
Il dit à l’application qui est là
Le Hub retire tout en-tête d’identité envoyé par le navigateur, puis pose lui-même l’utilisateur, son courriel, ses portées, son client (tenant), et s’il s’est connecté avec le double facteur. L’application n’a qu’à lire.
Il sert depuis le cache si possible
Un cache à deux niveaux, en mémoire puis dans Redis, avec une durée par application.
Il transmet à l’application
La requête arrive au conteneur de l’application, connexions temps réel (WebSocket) comprises.
Dans l’autre sens, une application appelle le Hub par deux portes : la porte MCP, avec une clé de plateforme ou un jeton émis par l’annuaire du Hub, et la porte REST des actions, avec une clé de l’annuaire. Les deux appliquent la même matrice de portées.
Identité, clients et accès
Le service d’identité (iam_worker, 49 actions) tient les utilisateurs, les rôles et les portées, les clés d’API — gardées sous forme d’empreinte, jamais en clair — et les clients. Un client (tenant) a sa fiche, ses membres, son logo, et des règles qui rattachent automatiquement un nouvel utilisateur selon son adresse de courriel. On peut suspendre un client, le restaurer, auditer la cohérence de l’ensemble.
Le Hub est aussi fournisseur OIDC : une application tierce peut déléguer sa connexion au Hub, selon le protocole standard, avec découverte automatique, enregistrement du client, code d’autorisation protégé (PKCE), jetons, introspection et révocation.
Depuis peu, une application reçoit sa propre identité applicative (app_identity_worker, 11 actions) : avec une clé bornée à son périmètre, elle crée des comptes sans mot de passe, envoie un lien magique à usage unique par le courrier du Hub, gère ses propres rôles et ferme des sessions. L’inscription du double facteur (TOTP) se pilote de la même façon.
Secrets : le coffre-fort
Aucune application ne garde un mot de passe dans son code ni dans sa base. Le Hub crée pour chacune un chemin de secrets dans Vault (vault_worker, 9 actions), y range ses identifiants de base de données, de stockage ou de services tiers, et les injecte au démarrage. Une action vérifie d’un coup que chaque application installée accède bien à son coffre.
La passerelle d’API (APIM)
Publier une API pour un partenaire ou un client passe par la passerelle (apim_provisioning_worker, 8 actions). La publication enchaîne seule le nom de domaine, le certificat puis l’activation, et se défait d’un geste si besoin. Les clés distribuées se révoquent avec effet immédiat. La passerelle sait appliquer des règles de décision JDM, tenir un portefeuille et une facturation, et exposer un programme en API avec un repli compilé à chaud.
Proxy, connexion unique et cache
Le proxy (proxy_worker, 9 actions) tient la table des routes : ajouter, modifier, retirer une route, activer ou couper la connexion unique devant une application, vérifier la santé de toutes les cibles. Le cache (cache_worker, 6 actions) se purge par application, par chemin ou en entier, avec une durée de vie réglable par application. Le garde-fou contre les sondes (scan_guard_worker, 13 actions) a ses catégories intégrées, ses motifs ajoutés, ses exceptions par hôte et ses statistiques de touches.
DNS, certificats et multi-domaines
DNS chez quatre fournisseurs
Le Hub pilote les zones DNS chez Cloudflare, OVH, Infomaniak et Hostinger (dns_sync_worker, 11 actions) : déclarer une zone, créer un enregistrement ou un sous-domaine, pousser les changements en attente, resynchroniser.
Certificats automatiques
Les certificats Let’s Encrypt sont demandés et renouvelés par le protocole ACME, avec un défi DNS (acme_worker, 6 actions). Les certificats du serveur de courrier sont tenus alignés.
Plusieurs marques, une plateforme
Un domaine naît en attente, prouve qu’il appartient à son déclarant, puis devient actif (domain_worker, 11 actions). Il porte ses hôtes — portail, applications, API, courrier, agendas — et son apparence : nom, couleur, logo, accroche.
Le courrier
Le Hub embarque un serveur de courrier complet, Apache James (james_worker, 53 actions, le plus gros service du Hub) : domaines, boîtes, dossiers et quotas ; signature DKIM ; réception directe ou par relais ; vérification de la configuration DNS, des listes de blocage et de la réputation ; migration d’une boîte existante ; relève d’un compte extérieur ; profil de configuration prêt pour les appareils Apple ; synchronisation avec l’annuaire.
Deux services l’accompagnent. Les gabarits de messages (mail_worker, 11 actions) : des modèles et des habillages de marque, prévisualisés puis envoyés. Et la chauffe des adresses neuves (warmup_worker, 13 actions) : un parc de boîtes entretient des conversations, les adresses cibles montent en volume progressivement, et un rapport de délivrabilité par opérateur dit quand une adresse est prête.
Les fichiers : stockage, antivirus, bureautique, signature
Stockage d’objets
Dépôt, navigation, lien de téléchargement temporaire, quota par utilisateur, partage de dossiers et corbeille (storage_worker, 10 actions).
Antivirus ClamAV
Analyse d’un fichier, quarantaine, libération ou suppression, historique, mise à jour des signatures (clamav_worker, 12 actions). Les pièces jointes du courrier sont analysées au fil de l’eau.
Bureautique en ligne
OnlyOffice ouvre et édite les documents d’une application, par le protocole standard WOPI ; le Hub en supervise les connexions et les conversions.
Signature et horodatage
Signature électronique de documents, avec relance et vérification (signature_worker, 10 actions), et horodatage selon la norme RFC 3161, auprès d’autorités interrogées tour à tour (tsa_worker).
La messagerie entre applications
Des files de messages durables (NATS JetStream, nats_worker, 15 actions) permettent aux applications de s’échanger du travail sans se connaître. Une application publie sur un sujet construit à partir d’un domaine, d’un canal et d’une cible ; une autre consomme avec un consommateur durable créé pour elle, puis accuse réception, refuse ou rejoue. Les applications y accèdent par MCP ou par une route REST dédiée.
Données et sauvegardes
Le service de bases (db_worker, 12 actions) crée pour chaque application son schéma PostgreSQL, range ses identifiants dans le coffre, et sait aussi provisionner une base MySQL ou une base Redis, sauvegarder et restaurer la base d’une application.
Les sauvegardes de la plateforme (backup_worker, 14 actions) partent vers des destinations S3, dont les identifiants sont rangés dans le coffre et jamais en base. Chaque planification choisit son périmètre — bases PostgreSQL et MariaDB, coffre, configuration, stockage d’objets, bases techniques, volumes — et sa rétention, trente jours par défaut. L’exécution est confiée à un démon séparé. La restauration suit une procédure écrite.
IA, automatisation et collaboration
AgentIA, la passerelle vers les modèles
Les applications appellent les modèles d’IA par une seule porte, compatible avec l’interface OpenAI, pour la conversation comme pour les plongements vectoriels. Derrière, des fournisseurs déclarés — dont un adaptateur natif Anthropic —, une clé par client, des quotas en coût, en appels ou en jetons, et des tarifs synchronisés chaque jour (agentia_worker, 22 actions). On sait ce que chaque client consomme.
Alfred, le majordome
Alfred exécute des tâches écrites en langage naturel, déclenchées par un horaire ou par une veille : un courriel qui arrive, un événement du bus, un message dans une file. Chaque tâche n’a droit qu’aux outils de sa liste blanche, et un interrupteur général suspend tout (alfred_admin, 27 actions).
Les salons
Des fils d’échange persistants entre sessions MCP — humains et agents (salon_worker, 25 actions) : poster, lire depuis un curseur, attendre une réponse côté serveur, joindre des fichiers versionnés et analysés par l’antivirus. Chaque salon peut recevoir du courrier, pour qu’un humain y écrive depuis sa messagerie.
Les agendas et carnets d’adresses partagés reposent sur Cosmo, en CalDAV et CardDAV (cosmo_worker, 15 actions) : créer et partager un agenda, injecter un événement, exporter des contacts, synchroniser avec l’annuaire.
Les applications : catalogue, installation, MCP
Installer une application est une action (docker_worker, 17 actions) : le Hub provisionne sa base, crée son coffre, demande son certificat, tire son image, démarre le conteneur, inscrit sa route et sa portée dans l’annuaire. La mise à jour, le redémarrage, les variables, la limite de mémoire et les journaux se pilotent de même. Un catalogue et un dépôt d’images, dont le manifeste est signé, publient les versions.
Le proxy MCP (mcp_proxy_worker) rassemble les outils de toutes les applications installées derrière le seul point MCP du Hub : comment un agent pilote la flotte →
Le portail du Hub présente à chaque utilisateur ses applications sous forme de lanceur : Mon Espace →
Les agents de terrain, vus du Hub
Le Hub tient le registre des minihubs et leur état (actif, dégradé, injoignable), leur envoie des commandes sans SSH, déploie et pilote les miniMiniHubs (13 actions, dont l’installation en une ligne par jeton à usage unique et l’invocation d’une action à distance), et dialogue avec les gardiens : comptes rendus, ordres, bilan quotidien et approbation humaine des actions sensibles. Il gère aussi les sorties Internet passant par ces agents, avec un registre qui dit ce qui est sorti, quand, vers où et pour qui, extrait horodaté à l’appui.
Le détail est dans les pages des agents : minihub · miniMiniHub · socle-gardien
La supervision de sources externes
Un site, un serveur de courrier ou un autre système peut envoyer ses rapports au Hub (supervision_externe_worker, 15 actions). Le Hub frappe un jeton par source, fournit les blocs d’installation à coller, repère toutes les minutes une source devenue muette, lève des alertes qu’on acquitte, et applique des règles d’anomalie.
Ce qu’il apporte
Des applications plus petites
Une application de la flotte n’a ni annuaire, ni coffre, ni serveur de courrier : elle les consomme. Son code ne parle que de son métier.
Une sécurité tenue en un seul endroit
Connexion unique, en-têtes posés par le proxy, secrets en coffre, portées vérifiées à chaque appel : on corrige une fois pour toutes les applications.
Une plateforme pilotable par un agent
Chacun des 497 gestes du Hub est une action MCP. Installer, publier, superviser : un agent le fait avec les droits qu’on lui donne.
On voit les services du Hub à l’œuvre dans Office (stockage et bureautique), AgentIA (la passerelle IA), Reverse Proxy (la gestion des routes), Extension Salons (les salons) et Your360 (clients séparés et bureautique).
Le Hub est-il lui-même construit sur le socle ?
Oui. C’est une application Socle V005, avec ses Workers et ses actions, exactement comme celles qu’il fait tourner.
Une application peut-elle vivre sans le Hub ?
Le framework fonctionne seul. Mais une application de la flotte consomme les services du Hub pour tout ce qui l’entoure, plutôt que de les réécrire.
Plusieurs clients sur un même Hub ?
Oui : chaque client (tenant) a ses utilisateurs, sa fiche et ses règles, et l’application sait à chaque requête pour quel client elle travaille.
Plusieurs marques sur un même Hub ?
Oui : un domaine porte ses propres hôtes et son apparence. Une plateforme sert plusieurs marques.
La suite du socle
Les packs ajoutent des capacités dans les applications ; les agents de terrain prolongent le Hub chez les clients.