INTÉGRATION / MODEL CONTEXT PROTOCOL
MCP connecte les outils.
Que faut-il décider autour ?
Un connecteur peut rendre une information ou une fonction accessible à un assistant. Il faut encore savoir avec quelle identité, sur quelles données et avec quelles conséquences.
Rédaction Saphan · 7 septembre 2026
Le rôle du protocole
Le Model Context Protocol fournit une manière standardisée de relier des applications IA à des sources de données et à des outils. Il facilite une interface commune ; il ne remplace ni l’application métier, ni ses droits d’accès, ni la qualité des informations.
Une comparaison utile : le protocole organise le raccordement. Il ne décide pas pour votre entreprise qu’un assistant peut modifier une commande ou consulter toutes les fiches clients.
Lecture et écriture sont deux besoins différents
Exemple fictif : consulter l’état d’un stock pour préparer un brouillon de réponse. L’outil expose une lecture précise : une référence, un entrepôt et un résultat daté. Il n’est pas nécessaire, pour cet usage, de lui donner également la possibilité de modifier les quantités ou de supprimer des produits.
Si l’usage évolue vers une action, décrivez l’opération attendue, la validation éventuelle, la trace à conserver et le comportement en cas d’échec. Une réponse « succès » du connecteur doit correspondre à un état vérifiable dans l’outil cible.
Les contrôles avant raccordement
- Identifier la provenance du serveur MCP et les fonctions qu’il expose réellement.
- Vérifier le compte utilisé et restreindre ses droits au besoin.
- Examiner quelles données partent vers quel service.
- Tester un appel valide, une information absente et un accès refusé.
- Vérifier la révocation de l’accès et le comportement si le connecteur est indisponible.
Les instructions trouvées dans une page ou un document ne doivent pas devenir automatiquement des ordres pour l’agent. Les données consultées et les permissions d’exécution sont deux niveaux à traiter séparément.
Un protocole n’impose pas tout un fournisseur
Le même besoin peut parfois être couvert par une API existante ou une intégration plus simple. Le choix dépend des applications clientes, de l’environnement et du travail de maintenance. Saphan peut comparer ces routes sur un parcours métier défini, plutôt que multiplier les connecteurs sans usage.