Vos outils IA vont se découvrir tout seuls :
ce que le registre MCP change pour votre gouvernance
Il existe maintenant un annuaire public où un assistant IA trouve des outils à brancher. L'installation ne passe plus par vos achats, ni par votre service informatique. Elle prend trente secondes.
Pendant vingt ans, un logiciel entrait dans votre organisation par une porte que vous contrôliez : un achat, une installation, un service informatique. Le shadow IT a percé cette porte, et vous avez fini par la rouvrir proprement. Ce qui arrive maintenant est d'une autre nature, parce que ce n'est plus un humain qui installe.
MCP, en une minute
Le Model Context Protocol est une manière standard de brancher un outil sur un assistant IA. Avant lui, chaque intégration était un développement particulier. Avec lui, un assistant sait parler à n'importe quel outil qui respecte la norme — de la même façon qu'un navigateur sait afficher n'importe quel site.
C'est une bonne nouvelle, et c'est ce qui rend la suite inévitable : dès qu'un branchement devient standard, quelqu'un construit l'annuaire.
Ce que le registre change
Cet annuaire existe. Un assistant peut y chercher un outil par mot-clé — « conformité », « facturation », « CRM » — le trouver, et se connecter. L'utilisateur n'a plus besoin de connaître une adresse : il demande une capacité et elle apparaît.
La distance entre « un employé a une idée » et « un outil tiers a accès au contexte de travail de cet employé » est passée de plusieurs semaines à quelques secondes, sans passer par un bon de commande.
Il ne s'agit pas de s'en alarmer : le même mouvement a produit les magasins d'applications, et ils ont finalement amélioré la sécurité mobile. Il s'agit de reconnaître qu'une nouvelle chaîne d'approvisionnement vient de s'ouvrir, et qu'elle n'a pas encore de politique dans votre organisation.
Le risque n'est pas celui qu'on croit
La crainte spontanée est l'outil malveillant. Elle existe, elle est réelle, elle est aussi la mieux traitée : c'est le scénario auquel votre équipe de sécurité pense en premier.
Le risque sous-estimé est l'outil honnête mais faux : un connecteur qui répond avec assurance à des questions qui engagent votre organisation — quel régime s'applique, quelle donnée peut sortir, quelle décision est permise — sans que personne ne puisse vérifier ses réponses. Il ne vole rien. Il vous fait simplement prendre des décisions sur une base que vous ne pouvez pas défendre.
- Il répond différemment à la même question selon le jour, et personne ne le remarque.
- Il cite un texte de loi sans dire quand il l'a vérifié pour la dernière fois.
- Il ne laisse aucune trace exploitable par un tiers.
- Il ne dit pas s'il conseille ou s'il applique — et vos équipes supposent qu'il applique.
Cinq exigences à poser à tout fournisseur de connecteur
Cette liste tient sur une page et se pose avant l'autorisation, pas après l'incident. Elle vaut pour un outil acheté comme pour un outil gratuit trouvé dans l'annuaire.
- Reproductibilité. La même question donne-t-elle toujours la même réponse ? Sinon, l'outil ne peut pas être audité, quelles que soient ses qualités par ailleurs.
- Sources citées au bon niveau. Un outil qui cite un cadre réglementaire est vérifiable. Un outil qui cite un article précis comme s'il rendait un avis juridique promet ce qu'il ne peut pas tenir.
- Fraîcheur datée. À quand remonte la dernière vérification de la donnée sur laquelle il s'appuie ? Un fournisseur qui ne publie pas cette date vous demande de le croire plutôt que de le vérifier.
- Preuve vérifiable sans lui. Pouvez-vous démontrer à un tiers ce que l'outil a répondu, six mois plus tard, sans dépendre de la bonne volonté du fournisseur ?
- Rôle explicite. L'outil conseille-t-il, ou applique-t-il ? Les deux sont défendables. L'ambiguïté ne l'est pas, parce qu'elle décide à votre place le jour où quelque chose échoue.
Un fournisseur sérieux répond à ces cinq points sans se troubler. Un fournisseur qui les trouve excessives vient de vous renseigner.
L'autre côté du miroir : et si c'était vous ?
Si votre organisation vend un service, cet annuaire est aussi un canal de distribution — celui où l'on vous trouve sans vous chercher. C'est une opportunité réelle, et elle vient avec une contrepartie exigeante : votre inscription publie une promesse.
Un référencement qui promet plus que le service ne livre est pire qu'une absence de référencement. Le premier assistant qui essaie, échoue, et ne revient pas ; et votre nom reste inscrit à côté de la promesse. La discipline minimale est simple : vérifier que tout ce qu'annonce la fiche est vrai en production avant de publier, et corriger la fiche le jour où ça cesse d'être vrai.
Votre politique tient en une page
- Une liste d'outils autorisés, tenue à jour, et le nom de la personne qui l'approuve.
- Les cinq exigences ci-dessus, posées avant l'ajout, avec les réponses conservées.
- Aucun connecteur ne franchit la frontière de la Zone 3 : la découverte automatique n'est pas une dispense de décision humaine.
- Une revue trimestrielle : ce qui a été branché, par qui, et ce qui n'est plus utilisé — un outil oublié garde ses accès.
Ce n'est pas une politique de sécurité informatique. C'est une politique de gouvernance : elle décide qui a le droit de faire entrer une capacité dans l'organisation. Ce genre de décision se prend avant que la technologie ne devienne banale — c'est-à-dire maintenant.
Qu'est-ce que le Model Context Protocol, en pratique ?
Une manière standard de connecter un outil externe à un assistant IA, pour qu'il puisse consulter une donnée ou déclencher une action. Ce qui change avec un annuaire public, c'est que la découverte de ces outils devient automatique : l'assistant peut en trouver un sans qu'on lui donne d'adresse.
Faut-il bloquer les connecteurs dans l'entreprise ?
Bloquer sans autoriser d'alternative produit exactement le contournement que vous cherchez à éviter. La position tenable est une liste d'outils approuvés, courte au début, avec un chemin clair pour en faire ajouter un. Le refus doit rester possible ; il ne doit pas être la seule réponse disponible.
Comment savoir si un connecteur est fiable ?
Les cinq exigences de l'article : reproductibilité, sources citées au bon niveau, fraîcheur datée, preuve vérifiable sans le fournisseur, rôle explicite entre conseiller et appliquer. Un fournisseur qui répond aux cinq sans hésiter est un fournisseur qui a déjà réfléchi à sa responsabilité.
Notre organisation devrait-elle publier son propre serveur ?
Si vous vendez un service que des assistants IA pourraient utiliser, oui : c'est un canal de distribution où l'on vous trouve sans vous chercher. À une condition — que tout ce que la fiche annonce soit vrai en production le jour de la publication, et le reste ensuite.
Est-ce que cela relève de la sécurité ou de la direction ?
Des deux, mais pas au même endroit. La sécurité évalue le risque technique d'un connecteur donné ; la direction décide quelles catégories de décisions peuvent être déléguées à un outil externe. La seconde question ne se délègue pas à la première.
Pour aller plus loin — la version technique
La procédure complète de publication d'un serveur au registre — espace de noms, preuve de propriété du domaine par clé Ed25519, erreurs fréquentes — est documentée dans le guide technique sur StructureClerk.
Le Modèle des 3 Zones, en entier
Cet article applique à l'IA agentique un cadre développé dans L'Architecte Numérique : décider ce qui doit être automatisé, augmenté, ou sanctuarisé.