Le socle · les packs

Une capacité écrite une fois,
embarquée par toutes les applications.

Un socle-pack est une bibliothèque qu’une application ajoute à ses dépendances pour gagner une capacité entière — ses Workers, ses actions, ses tables — sans en écrire une ligne. Quand il manque quelque chose, on amende le pack : la correction profite à toutes.

Les dix packs

Retour au socle

À quoi ça sert

Entre le framework, qui donne la structure d’une application, et le Hub, qui rend les services d’infrastructure, il reste un étage : des capacités métier réutilisables. Faire appel à un modèle d’IA, envoyer une notification sur six canaux, lire Notion, collecter des flux RSS, importer une boîte mail, orchestrer un pipeline en graphe… Plusieurs applications en ont besoin, et aucune ne devrait l’écrire seule.

Un socle-pack, selon la définition de son gabarit, est « une bibliothèque Maven qu’une application V005 embarque pour gagner une capacité mutualisée sans la recoder ».

La règle : on amende le pack, pas l’application

Elle est écrite dans notre méthode de conception, en toutes lettres : tout ce qui peut être mutualisé l’est. S’il manque à un pack un réglage, un fournisseur, une action, ou s’il a un défaut, on corrige ou on étend le pack ; on n’écrit pas un contournement parallèle dans l’application. Le pack d’IA le répète en tête de son mode d’emploi : aucune application ne réimplémente localement une capacité couverte par ce pack — deux implémentations divergent toujours, et l’une est moins bonne que l’autre.

L’inverse compte aussi : on embarque un pack quand on en a besoin, pas par défaut.

Comment ça marche

Tous les packs sont alignés sur la même lignée : le framework 5.10 à 5.11, Spring Boot 4.1.2, avec le parent Maven commun du socle. Un pack construit contre une autre version de Spring Boot compilerait puis casserait à l’exécution : chaque application prend donc la version du pack qui correspond à sa lignée de socle, et les lignées antérieures restent maintenues.

• 10
  Packs en service, plus un gabarit
• 39
  Workers apportés par les packs
• 215
  Actions MCP déclarées, comptées dans le code
• 15
  Applications de la flotte qui embarquent au moins un pack

Le catalogue

socle-pack-ai — l’IA générative

Le plus complet des packs, en version 2.9. Il donne à une application tout ce qu’il faut pour travailler avec des modèles de langage : une passerelle vers plusieurs fournisseurs, des plongements vectoriels, une recherche augmentée par les documents (RAG), de la classification, la lecture de pages web, un navigateur automatisé et un cadre pour écrire des agents.

Worker	Rôle	Actions
rag_worker	recherche augmentée par les documents	9
llm_gateway_worker	appel des modèles de langage	8
web_worker	lecture et extraction de pages web	8
workspace_manager_worker	espaces de travail	7
classification_worker	classification de textes	6
embedding_worker	plongements vectoriels	4
generation_worker	génération de contenus	4
browser_worker	navigateur automatisé	3
agent_toolset	outils mis à disposition des agents	2
workspace_gc_worker	nettoyage des espaces	0

Les fournisseurs de modèles sont Anthropic, OpenAI (adresse configurable, donc tout service compatible), Ollama pour les modèles locaux, et AgentIA, la passerelle du Hub. Les vecteurs sont rangés dans PostgreSQL avec son extension vectorielle. Le pack crée 29 tables par 27 migrations, et se règle par une vingtaine de variables, toutes facultatives. Une classe de base permet à une application d’écrire ses propres agents.

Il équipe notamment BilanSocle, NotionSocle, AgentIA, Régies, RssArchiver, SmartDailyReach, UniqPersonnality, IdéeBox et LeSachant.

socle-pack-comm — les notifications

Une application prévient ses utilisateurs sans connaître les canaux. Le pack en gère six :

Canal	Par quoi
Courriel	SMTP ou l’API Brevo
SMS	Twilio, OVH ou Vonage
Telegram	l’API des robots Telegram
Slack	webhook ou robot Slack
Webhook	signé par HMAC, pour un système tiers
In-app	une notification dans l’application

Quatre Workers — notify_worker (8 actions), telegram_worker (5), sms_worker (5), slack_worker (4) — et quatre tables. Les identifiants des canaux sont lus d’abord dans le coffre-fort du Hub. Le pack est indépendant du pack d’IA. Utilisé par RssArchiver, UniqPersonnality et BingFetch.

socle-pack-connectors — les services SaaS

Des connecteurs standardisés, sans logique métier : l’application décide, le connecteur exécute. Chacun s’allume séparément par la configuration.

Worker	Service	Actions
notion_worker	Notion : lecture, écriture, import massif, webhooks	20
stripe_worker	Stripe : clients, abonnements, paiement, webhooks	12
hubspot_worker	HubSpot : contacts, affaires, entreprises	12
gdrive_worker	Google Drive, par compte de service	10

Chaque connecteur porte sa résilience : coupe-circuit, nouveaux essais exponentiels, limite de débit propre au fournisseur. Un journal des appels et le suivi des imports Notion tiennent en deux tables. Utilisé par NotionSocle.

socle-pack-editorial — la chaîne éditoriale

De la source à la lettre d’information, en quatre temps : collecter les flux RSS et Atom, trier par l’IA, faire valider par un humain, publier une lettre. Quatre Workers : newsletter_worker (9 actions), rss_collect_worker (8), hitl_worker (8, la validation humaine), curation_worker (6). Huit tables et trois gabarits de lettre. Le pack s’appuie sur les packs d’IA et de notifications. Utilisé par RssArchiver.

socle-pack-mail — la boîte de l’utilisateur

Là où le Hub fournit le serveur de courrier de la plateforme, ce pack travaille avec la boîte de l’utilisateur : importer une boîte IMAP, Gmail ou un export Outlook avec ses contacts ; envoyer depuis cette boîte ; générer un courriel contextualisé par l’IA ; épurer les messages ; relever une boîte applicative ; envoyer un lien d’activation de compte.

Sept Workers, dont deux passerelles internes, pour 17 actions : import (6), envoi (4), rédaction (4), épuration (2), boîte applicative (1). Sept tables.

socle-pack-pipeline — les pipelines gouvernés

Un moteur de pipelines en graphe posé sur le Pipeline V2 du framework, qui ajoute ce qu’un traitement sérieux demande :

• des étapes typées, réparties en sept natures ;
• une validation du graphe par six contrôles successifs ;
• l’idempotence : rejouer ne produit pas de doublon ;
• une étape humaine quand une décision ne peut pas être automatique ;
• la traçabilité de chaque donnée (le lineage) ;
• un catalogue de pipelines qu’on duplique, des sous-pipelines ;
• une file au choix — base technique, mémoire ou NATS — et une projection pour un constructeur visuel.

Un seul Worker, pipeline_worker, et 24 actions. Six tables. Utilisé par NotionSocle, RssArchiver, Régies, BilanSocle et TheDiffuseur.

socle-pack-tenant — la fiche société

Une application qui sert plusieurs clients a besoin de savoir, à chaque requête, qui est le client : sa raison sociale, ses coordonnées, son dirigeant, sa marque, son équipe. Ce pack lit cette fiche depuis le Hub, la garde en cache et la revalide. L’application ne stocke rien et ne gère pas les clients : elle lit.

Deux Workers : tenant_fiche_worker (4 actions) et tenant_ecarts_worker (4 actions), qui ne s’allume qu’en mode de lecture double, pour suivre les écarts. Le client courant est lu dans le contexte de journalisation de la requête. La fiche se saisit une fois dans TheSociety ; elle est lue par Your360 et UniqPersonnality.

socle-pack-egress — la sortie réseau

Certains appels sortants doivent partir d’ailleurs que de la machine de l’application : pour varier les adresses de collecte, par exemple. Ce pack ouvre dans l’application un petit proxy local ; chaque connexion sortante y devient un tunnel gRPC vers une antenne de sortie de la plateforme, un miniMiniHub. Le chiffrement TLS reste de bout en bout : ni le Hub ni l’antenne ne voient le contenu, et le trafic en clair est refusé.

Il n’a ni Worker ni action : une ligne de code branche le client HTTP de l’application sur le proxy. Utilisé par KEW et RssArchiver. Les antennes elles-mêmes : le miniMiniHub →

socle-pack-documents — les fichiers reçus

Garder les fichiers d’une application sur le stockage du Hub, proprement : analyse antivirus avant garde, chiffrement au repos, plafond par fichier, quota par propriétaire. L’API est Java : un service pour garder, un service pour analyser sans garder. C’est un choix assumé : aucune action métier n’est exposée en MCP — seul l’état du Worker l’est. Trois Workers, dont deux passerelles vers le stockage et l’antivirus du Hub. Utilisé par TheBeneficiaire.

socle-pack-referentiels — les référentiels métiers

Charger et versionner les référentiels officiels des métiers et des compétences :

• ESCO, le référentiel européen de la Commission, en français et en anglais ;
• ROME 4.0, le référentiel de France Travail ;
• la table de correspondance entre les deux.

Licences et mentions sont vérifiées et gardées ; aucune version antérieure n’est réécrite ; la recherche à la frappe ignore accents et majuscules ; la dernière version donne les compétences d’un métier. Un Worker, referentiels_worker, 7 actions, six tables. Utilisé par TheBeneficiaire.

Fabriquer un nouveau pack

Le gabarit socle-pack-ZZ-TEMPLATE engendre un pack complet sur le parent Maven du socle, avec Log4j2 et PostgreSQL. Il rend impossibles par test les défauts déjà rencontrés : deux composants qui portent le même nom, un manifeste en retard sur la version du pack, un Spring Boot différent de celui du socle.

Avant de créer, une méthode écrite tranche : une demande devient soit l’extension d’un pack existant, soit un pack neuf. Dans le doute, on étend. Chaque pack tient sa documentation dans le même travail que son code.

Ce que cela apporte

La suite du socle

Les packs vivent dans les applications ; le Hub leur rend les services d’infrastructure.

Le Hub

La fabrique d’applications