Authentification d'une application d'IA auprès d'un service tiers via MCP, dans le cas idéal, puis les deux cas où ça se complique.
Le cas idéal : le service publie son propre serveur MCP
1. L'appli contacte le serveur MCP, qui répond où obtenir un jeton. 2. L'utilisateur se connecte sur la page du service : l'appli ne voit jamais son mot de passe. 3. Le service remet un jeton limité à ce serveur et aux droits acceptés. 4. L'appli présente ce jeton à chaque appel. 5. Le serveur MCP agit avec les droits de l'utilisateur, à condition d'être correctement implémenté : c'est lui qui fait respecter la limite. La flèche en pointillé n'existe qu'en entreprise (extension « Enterprise-Managed Authorization », dite Cross App Access).
Service tiersHéberge le serveur MCP et réutilise son serveur d'autorisation existant.
DéveloppeurIntègre un client MCP standard. Aucun code propre au service, aucun mot de passe.
UtilisateurSe connecte et accepte les droits demandés. Rien d'autre.
DSIFixe à un seul endroit quelles applis accèdent à quels outils.
Complication 1 : le service n'a pas de serveur MCP officiel
Deux autorisations imbriquées, et un acteur de plus à qui faire confiance. MCP ne traite pas le jeton n°2 : il interdit seulement de réutiliser le jeton n°1 vers le service. Chaque serveur intermédiaire se débrouille, avec un OAuth classique dans le meilleur des cas, une clé d'API en clair dans le pire.
Complication 2 : au nom de qui agit l'IA ?
Chat lancé par un utilisateur
Agent autonome
Qui est présent
L'utilisateur, qui voit ce que fait l'IA
Personne
Identité utilisée
Celle de l'utilisateur, via le connecteur qu'il a autorisé (l'accès persiste souvent au-delà de la conversation)
Soit un jeton utilisateur renouvelé en arrière-plan, soit une identité propre (compte de service)
Risque principal
Accepter des droits sans les lire
Une autorisation ancienne qui sert encore à des actions que personne ne relit
Prise en charge par MCP
Bien couvert
En cours Extension d'autorisation pilotée par l'entreprise, identités d'agents chez Okta et Microsoft. La pratique reste immature.
Dans les deux cas, la DSI contrôle l'application (quel logiciel, quels outils) et l'utilisateur ses propres droits. En principe, l'IA ne dépasse pas l'intersection des deux ; en pratique, cela dépend de la rigueur des serveurs et des droits accordés.
Pièges classiques et pistes de résolution
État au 28 septembre 2026. Chaque piège est suivi de ses pistes, avec leur statut.
Livré disponible (norme ou produits)
En cours proposé ou en déploiement
Bonne pratique à appliquer soi-même
Ouvert pas de solution en vue
Conception d'un serveur
Recopier son API telle quelle80 routes deviennent 80 outils : l'IA se perd et enchaîne cinq appels pour une tâche simple.Bonne pratiqueConcevoir des outils autour des tâches. Figer les enchaînements fréquents en workflows déclaratifs (Arazzo et un moteur open source) ou en outils composés écrits en code.En coursArazzo 1.2 : une étape pourrait appeler directement un outil MCP ou une commande.
Réponses trop volumineuses2 000 lignes de JSON saturent le contexte et dégradent les réponses.Bonne pratiquePagination, filtres, résumés, erreurs lisibles par l'IA. Ne renvoyer que les champs utiles (le Selector d'Arazzo 1.1 le permet).Bonne pratique« Code mode » : l'IA filtre les données dans un bac à sable avant de les lire.
Opérations longuesUn export de plusieurs minutes finit en délai dépassé.LivréExtension « tasks » (juillet 2026) : l'appel rend la main tout de suite, le client suit l'avancement ensuite. Adoption par les clients à suivre.
Déploiement à grande échelleLes sessions s'accordaient mal avec les répartiteurs de charge et le serverless.LivréProtocole sans état depuis la version du 28 juillet 2026, routage par en-têtes HTTP, listes d'outils mises en cache. Reste la migration des serveurs et des clients.
Utilisation
Clients incompletsBeaucoup ne gèrent que les outils : un serveur marche dans un client et pas dans l'autre.LivréRecentrage de la norme : fonctions peu adoptées dépréciées (sampling, roots), nouveautés sous forme d'extensions optionnelles.Bonne pratiqueTester sur les clients réellement visés.
Comportement non déterministeLe modèle choisit quel outil appeler, sans garantie de résultat.Bonne pratiqueÉvaluations sur des scénarios réels. Figer en workflow les enchaînements critiques.LivréUn serveur peut demander une confirmation en cours d'appel avant une action sensible.
Débogage pénibleDescription floue, conflit entre serveurs, transport ou choix du modèle : les journaux sont dispersés.Bonne pratiqueMCP Inspector en développement, passerelle qui trace tous les appels en production.En coursTraçabilité inscrite au chantier « entreprise » de la feuille de route 2026, encore peu défini.
Coût caché en contexteChaque outil branché consomme de la place avant la première question.Bonne pratiqueBrancher moins de serveurs. Choisir des clients qui chargent les outils à la demande (recherche d'outils), ou passer par le « code mode ».
Sécurité
Empoisonnement d'outilsUne description d'outil peut cacher des instructions que l'IA suit et que l'utilisateur ne voit jamais.Bonne pratiqueN'installer que des serveurs d'éditeurs de confiance, relire les descriptions, filtrer via une passerelle.OuvertLe protocole ne donne que des recommandations, aucun mécanisme de protection.
Changement après approbationUn serveur validé modifie ses outils ensuite. L'utilisateur n'est pas forcément prévenu.Bonne pratiqueFiger les versions des serveurs, faire détecter les changements de description par une passerelle.OuvertLe protocole signale qu'une liste d'outils a changé, mais n'impose aucune réapprobation.
Combinaison de serveursCe que Simon Willison appelle la « lethal trifecta » : données privées + contenu non fiable + moyen d'envoyer vers l'extérieur : chaque serveur est sain, leur combinaison permet la fuite.Bonne pratiqueNe jamais réunir les trois dans une même session. Exiger une confirmation humaine avant tout envoi vers l'extérieur.OuvertRelève entièrement des clients et des passerelles.
Écosystème et gouvernance
Confiance dans les serveursRien ne garantit qu'un serveur trouvé en ligne est fiable.En coursRegistre officiel MCP pour la découverte.OuvertNi certification ni audit systématique.
« Shadow MCP »Des serveurs installés par les salariés sans que la DSI le sache.LivréExtension MCP d'autorisation pilotée par l'entreprise (Cross App Access). Identités d'agents disponibles chez Okta (Agent SSO, août 2026) et Microsoft (Entra Agent ID). Elles n'agissent que sur les serveurs qui passent par l'annuaire : un serveur local installé en douce leur échappe.Bonne pratiquePasserelle MCP unique qui filtre, trace et applique les règles.OuvertDiscipline opérationnelle : agents sans propriétaire ni date d'expiration, droits qui s'accumulent.
MCP n'est pas toujours nécessairePour un usage par des développeurs, une ligne de commande ou une doc d'API suffit souvent. C'est un débat, pas un consensus.Bonne pratiqueRéserver MCP aux cas où il apporte l'authentification standard, la gouvernance ou l'accès depuis des clients grand public.