Documentation

Exposer les capacités de vos machines aux IA

Chaque machine du mesh exécute des logiciels qui savent des choses et savent faire des choses : un contrôleur de robot connaît ses erreurs, une supervision connaît l’état d’une ligne, un logiciel métier sait déclencher une action. Le pont MCP local permet à n’importe quel logiciel de publier ces capacités auprès du client VIGIL de sa machine, qui les expose au mesh. Un assistant IA relié au workspace découvre alors un inventaire vivant — quelles machines, quels logiciels, quelles capacités — et peut superviser une flotte entière sans qu’aucun port ne soit ouvert nulle part.

À quoi ça sert

Aujourd’hui, brancher une IA sur un parc de machines demande du sur-mesure : chaque logiciel a son API, chaque machine son accès réseau, chaque site son VPN. Le pont MCP local renverse le problème : c’est le logiciel qui déclare ce qu’il sait faire, la machine qui le publie, et le mesh qui transporte. L’assistant n’a qu’un seul point d’entrée — le connecteur MCP du workspace — pour toute la flotte.

Inventaire vivant

L’assistant voit quelles machines existent, quels logiciels y tournent et quelles capacités ils offrent — nom de machine, logiciel, version, étiquette d’instance.

Diagnostic à distance

Récupérer les erreurs d’un contrôleur de robot, l’état d’une ligne, un journal — sans accès physique et sans exposer la machine à Internet.

Action outillée

Déclencher une capacité — recalibrage, redémarrage d’un service, export — dans les limites exactes de la politique de la console.

Comment ça marche : publication, bail, proxy

Le mécanisme tient en trois idées : le logiciel garde la main sur son serveur, la publication est un bail qui se renouvelle, et c’est le client VIGIL qui expose. Le logiciel n’a rien à savoir du mesh ; le mesh n’apprend du logiciel que ce qu’il publie.

1
Un serveur MCP local sur un port aléatoireLe logiciel démarre un serveur MCP standard sur l’interface locale de la machine (loopback), sur un port aléatoire choisi au lancement. Rien n’est joignable depuis le réseau : le port n’existe que pour la machine elle-même.
2
La publication ouvre un bailLe logiciel annonce au client VIGIL de la machine ce qu’il expose : nom du logiciel, version, étiquette d’instance, description des capacités et port local où les trouver. Cette annonce ouvre un bail d’une durée courte.
3
Renouveler, sinon disparaîtreTant que le logiciel tourne, il renouvelle son bail. À la fermeture propre, il le clôt. S’il plante, le bail expire de lui-même : la capacité disparaît de l’inventaire au lieu d’y rester en fantôme.
4
Le client VIGIL proxifie vers le meshLe client VIGIL relaie les appels du mesh vers le port local du logiciel. Vu du réseau, la capacité appartient à la machine ; vu du logiciel, tout arrive du loopback. Aucun port ouvert, aucune exposition directe.

Plusieurs logiciels, plusieurs instances

Une machine réelle n’héberge pas « un » logiciel : elle en fait tourner plusieurs, parfois plusieurs copies du même — deux instances d’un contrôleur, chacune pilotant un bras. Le modèle en tient compte dès le départ : l’unité de publication n’est pas le logiciel, c’est l’instance.

Chaque instance ouvre son propre bail, avec son propre port aléatoire : deux copies du même logiciel ne se marchent jamais dessus.
L’identité d’une capacité combine la machine, le logiciel et une étiquette d’instance (« bras-07 », « ligne-3 ») fournie à la publication.
L’inventaire agrège tout : l’assistant peut demander quelles machines offrent telle capacité sans connaître les ports ni les processus.
La disparition d’une instance ne touche qu’elle : les autres baux de la machine restent valides.

Gérer une flotte avec un assistant IA

Le cas d’usage qui a motivé la conception est industriel : une flotte de robots ou d’équipements répartis sur plusieurs sites, chacun derrière son réseau, sans adresse publique. Chaque équipement embarque le client VIGIL ; chaque logiciel de bord publie ses capacités. L’assistant, lui, se connecte à un seul endroit — le connecteur MCP du workspace — et voit la flotte entière.

Interroger l’état de santé de tous les équipements d’un site en un appel d’outil.
Récupérer les erreurs d’un contrôleur précis et les corréler avec celles du reste de la flotte.
Déclencher une action de maintenance sur l’équipement concerné, si la politique l’autorise.
Documenter automatiquement un incident : quelles machines, quels logiciels, quelles versions, quelles erreurs.

Un protocole ouvert, un transport VIGIL

La frontière est nette. Le protocole de publication — comment un logiciel annonce ses capacités, ouvre et renouvelle son bail — a vocation à être public, avec un pont open source de référence pour l’intégrer en quelques lignes ou accompagner un serveur MCP existant. Le transport, lui, est le métier de VIGIL : identité des machines, chiffrement de bout en bout, traversée sans port ouvert, politique d’accès de la console.

Le pont open source

Une petite brique libre : elle annonce le serveur MCP du logiciel au client VIGIL et tient son bail — c’est le client VIGIL qui relaie les appels. À intégrer dans un logiciel, à poser à côté d’un serveur MCP existant, ou à utiliser en façade d’un serveur MCP stdio.

MCP standard, pas un format maison

Les capacités sont décrites et appelées en MCP, le protocole que les assistants parlent déjà. Tout serveur MCP existant est candidat à la publication, sans modification.

Le mesh comme garantie

Ce qui est propriétaire, c’est ce qui doit être garanti : qui est la machine, qui a le droit, comment le trafic voyage. Le reste est ouvert.

Sécurité

Le pont MCP local touche à deux surfaces sensibles : ce qu’un processus local peut publier, et ce qu’un assistant distant peut atteindre. La conception borne les deux.

Le serveur MCP du logiciel n’écoute que sur l’interface locale : rien n’est joignable depuis le réseau, seul le client VIGIL relaie.
La publication locale est visible et gouvernée : les baux vivants s’affichent auprès de l’opérateur de la machine, et rien n’est exposé au mesh sans le consentement explicite donné dans la console pour ce device.
Côté assistant, tout passe par le connecteur MCP du workspace : OAuth, portées, et héritage des règles de la console — voir /docs/plateforme-mcp.
Le moindre privilège s’applique aux deux bouts : publier peu de capacités, accorder peu de machines à chaque connecteur.
Le bail limite la fenêtre d’erreur : une capacité oubliée disparaît d’elle-même quand son logiciel s’arrête.

Le port aléatoire du logiciel est-il exposé sur le réseau ?

Non. Il n’écoute que sur l’interface locale de la machine. Seul le client VIGIL le relaie, à travers des sessions mesh chiffrées de bout en bout, sans qu’aucun port ne soit ouvert sur le réseau.

Que voit l’assistant si un logiciel plante ?

Son bail cesse d’être renouvelé et expire : la capacité disparaît de l’inventaire. L’assistant ne voit pas de capacité fantôme ; il voit une instance qui n’est plus là — ce qui est en soi une information de supervision.

Un assistant peut-il atteindre une machine que sa politique ne couvre pas ?

Non. Les capacités publiées s’atteignent au travers du connecteur MCP du workspace, qui hérite des règles de la console : machines et portées accordées au connecteur bornent ce que l’assistant peut voir et appeler.

Puis-je publier un serveur MCP open source existant tel quel ?

C’est l’objectif du pont : posé à côté du serveur, il annonce le port et tient le bail — et il sait servir de façade locale à un serveur MCP stdio. C’est ensuite le client VIGIL qui relaie les appels. Le serveur n’a pas besoin de connaître VIGIL.

Lire ensuiteConnecteurs MCP pour les assistants IA →