Le Hub · MCP et agents IA
Ce que fait la console,
un agent IA sait le faire.
Créer un compte, installer un programme, lire un journal, envoyer un e-mail : chaque fonction est aussi un outil qu’un agent IA appelle, avec les mêmes droits et la même trace.
À quoi ça sert
Un agent IA n’est utile que s’il peut agir. Pour cela, il lui faut des outils : des fonctions décrites, avec leurs paramètres, qu’il sait appeler. Le protocole qui s’est imposé pour cela s’appelle MCP (Model Context Protocol).
Dans le Hub, il n’y a rien à ajouter. Le Hub est construit sur notre framework, Socle V005, où chaque fonction d’un programme est une action. Et chaque action est, d’office, appelable de deux façons : en REST par du code, en MCP par un agent. Les applications construites sur le même framework héritent de la même propriété. Le Hub les découvre et les rend appelables depuis un seul point.
Ce qu’on voit à l’écran
L’écran est celui du Hub thesocle.net, au 2026-09-23. On y arrive par le menu API, entrée Actions MCP ; l’entrée voisine, Swagger REST, publie la documentation des mêmes fonctions pour les développeurs.
L’en-tête : « Specs API consolidées de toutes les applications déployées », et une pastille 13/21 apps — treize applications sur les vingt et une déployées publient une description de leurs outils.
La colonne de gauche liste ces applications. À côté de chacune, un badge dit comment elle expose ses outils (V005 pour une application construite sur Socle V005, MCP pour une application qui parle MCP autrement), puis le nombre d’actions. Le Hub lui-même, soclehub, en compte 432. Parmi les applications : rssarchiver 172, thedash 110, data-app 96,
office-suite-v2 89, sdr 84, things 75, entreprises 73, thediffuseur 61, carousel 59. Les applications sans badge, comme WordPress ou phpMyAdmin, ne publient pas d’outils : elles sont hébergées, pas pilotables par un agent.
La zone de droite est vide sur la capture : on y lit la spécification d’une application quand on la sélectionne.
Deux boutons : « Spec agrégée JSON », la description de tous les outils en un seul fichier, et « Refresh », pour relancer la découverte.
Comment on s’en sert
L’agent se connecte
Au point d’entrée MCP du Hub, avec une clé ou un jeton : il agit au nom d’un utilisateur, avec ses droits.
Il découvre les outils
Il reçoit la liste des outils du Hub et des applications, chacun décrit avec ses paramètres.
Il appelle
Un outil du Hub, ou celui d’une application, par le même point d’entrée.
On relit
Le geste de l’agent laisse la même trace que celui d’un administrateur dans la console.
Ce que ça vous évite
Une intégration IA à écrire pour chaque outil
Vos programmes parlent déjà le langage des agents. Il n’y a rien à ajouter.
Un agent qui agit hors de tout contrôle
Il s’identifie comme un utilisateur, avec ses droits, et ses gestes sont tracés.
Chercher ce qu’un agent peut faire
Un écran recense tous les outils, application par application.
Les limites d’aujourd’hui
Une application n’apparaît qu’après son déploiement et la découverte suivante : ses outils ne sont pas là à la seconde où elle démarre. Les applications du marché (WordPress, phpMyAdmin…) restent hors du champ des agents.
Un appel d’outil qui dure longtemps, par exemple une génération par un modèle de langage, peut dépasser le délai du point d’agrégation.