---
title: "Vos outils IA vont se découvrir tout seuls : ce que le registre MCP change pour votre gouvernance"
description: "Un annuaire public permet désormais aux assistants IA de trouver et brancher des outils tiers en quelques secondes. Les cinq exigences à poser avant d'en autoriser un."
url: https://larchitectenumerique.com/articles/registre-mcp-gouvernance-outils-ia.html
canonical_url: https://larchitectenumerique.com/articles/registre-mcp-gouvernance-outils-ia.html
language: fr
published: 2026-08-20
author: Michel Fotsing, CISSP
publisher: L'Architecte Numérique
---

# 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 conséquence, en une phrase** — 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.

1. **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.
2. **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.
3. **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.
4. **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 ?
5. **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

1. Une liste d'outils autorisés, tenue à jour, et le nom de la personne qui l'approuve.
2. Les cinq exigences ci-dessus, posées avant l'ajout, avec les réponses conservées.
3. Aucun connecteur ne franchit la frontière de la Zone 3 : la découverte automatique n'est pas une dispense de décision humaine.
4. 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.
