Vos utilisateurs branchent désormais Claude sur votre logiciel tout seuls

Il y a un an, connecter un assistant IA à un système interne relevait du ticket informatique. Un développeur générait une clé d'API, l'envoyait par un canal dont il espérait qu'il était privé, et l'utilisateur la collait dans un fichier de configuration JSON sur son poste. Chacune de ces étapes a son mode de défaillance. La dernière, surtout, condamnait la fonctionnalité à ne jamais sortir du cercle des gens à l'aise avec un éditeur de texte.

Ce n'est plus vrai. La norme d'autorisation du Model Context Protocol a fait du serveur MCP une ressource protégée OAuth 2.1 ordinaire. La conséquence tient en une phrase et change tout : le client IA découvre seul où se trouve l'accueil de votre application, et y conduit l'utilisateur.

Celui-ci colle une URL. Il voit apparaître la page de connexion de sa propre entreprise. Il clique sur Autoriser, et c'est terminé.

Cet article décrit le mécanisme qui rend cela possible, ce qu'il coûte à implémenter, et les cinq détails qui le cassent en silence. Cinq de nos services exposent aujourd'hui un endpoint MCP protégé par OAuth, dont trois portent eux-mêmes tout le serveur d'autorisation, et la même famille d'erreur nous a coûté le plus de temps à chaque fois.

Sommaire

• Ce que fait réellement l'utilisateur
• Une clé d'API, mais sans la clé
• Le mécanisme, étape par étape
• Quelle version de la norme a introduit cela
• ChatGPT autant que Claude
• Ce qu'il faut implémenter
• Cinq détails qui cassent tout en silence
• La sécurité, honnêtement
• Faut-il s'y mettre maintenant

---

Ce que fait réellement l'utilisateur

Nous avons livré la semaine dernière un guide de connexion pour une plateforme de suivi des temps et de rentabilité que nous exploitons pour un cabinet comptable. Quatre pages A4, bilingue, et une section connexion qui tient en trois étapes.

La ligne la plus révélatrice de ce guide est celle des prérequis : « le compte Google avec lequel vous ouvrez déjà le tableau de bord. Si le tableau de bord vous refuse, le connecteur aussi. »

On peut maintenant écrire cette phrase parce que le fournisseur d'identité de l'application fait tout le travail. Personne n'a rien émis pour cet utilisateur, et son accès au connecteur est par défaut son accès à l'application, qui expirera le jour où son compte expirera. L'administrateur du cabinet, lui, n'a eu à se poser aucune question sur l'IA.

Deux mois plus tôt, la même fonctionnalité exigeait que nous créions une clé d'API en base pour chaque personne, puis que nous la lui transmettions. Nous tenions donc une liste, nous répondions aux demandes d'accès une par une, et chaque départ de collaborateur nous valait un aller-retour avec le cabinet. Rien de tout cela n'existe plus, et le gain ne se mesure pas en heures d'ingénierie économisées : il se mesure au nombre de personnes qui peuvent désormais s'en servir sans demander la permission à quiconque.

Une clé d'API, mais sans la clé

Les défauts d'une clé d'API n'ont rien de subtil, ils sont simplement familiers.

• Quelqu'un doit l'émettre, et c'est en général le profil le plus cher de l'équipe.
• Elle doit voyager, par messagerie interne ou par courriel, et atterrir dans un gestionnaire de mots de passe si vous avez de la chance.
• Elle porte les droits de son émetteur plutôt que ceux de son utilisateur, parce que restreindre les droits clé par clé est un travail que les équipes remettent à plus tard.
• Elle n'expire pas, si bien que la révocation repose sur la mémoire de quelqu'un.
• L'utilisateur doit la stocker, donc éditer un fichier, donc être technique.

L'auth MCP remplace tout cela par le flux d'autorisation que le bouton « se connecter avec Google » de n'importe quel site utilise depuis dix ans. La vraie nouveauté est ailleurs : le client n'a jamais entendu parler de votre application. Claude n'embarque aucune intégration pour votre ERP ni pour votre outil métier, et ne dispose que d'une chaîne de caractères, l'URL qu'un utilisateur vient de coller.

La norme devait donc répondre à une question qu'OAuth ne se pose jamais, parce qu'elle ne s'y posait pas : dans une intégration classique, le développeur du client connaît le service qu'il vise, a lu sa documentation et a enregistré son application à l'avance. Ici, rien de tel. À partir d'une simple adresse de ressource, comment un client découvre-t-il où s'authentifier, sous quel identifiant se présenter, et quelle portée demander ? Tout ce qui suit découle de cette question, et c'est aussi pourquoi la réponse s'appuie sur des documents publics plutôt que sur un accord préalable entre deux éditeurs.

Le mécanisme, étape par étape

Cinq allers-retours, dont l'utilisateur ne voit que la connexion et l'écran de consentement.

Chaque requête MCP ultérieure porte son Authorization: Bearer <jeton>. La norme précise que le jeton passe par l'en-tête et jamais par la chaîne de requête, où il finirait dans vos journaux d'accès.

Deux points de cette liste font un vrai travail de sécurité, et se sautent facilement.

Le paramètre resource. Imposé par la RFC 8707, il nomme le serveur auquel le jeton est destiné, et votre serveur doit ensuite vérifier que les jetons qu'on lui présente ont bien été émis pour lui. Sans cette vérification, un serveur MCP malveillant peut récupérer un jeton que l'utilisateur vous destinait et le rejouer contre vous. La norme ne laisse aucune latitude sur ce point : le client doit envoyer ce paramètre, que le serveur d'autorisation le prenne en charge ou non.

PKCE, et son annonce. Le champ code_challenge_methods_supported doit figurer dans vos métadonnées. Son absence signifie qu'un serveur d'autorisation ne prend pas PKCE en charge, et un client correct refusera alors de démarrer. Dans les métadonnées de notre CRM, ce champ porte un commentaire explicite lui interdisant de disparaître : un omitempty bien intentionné à cet endroit ne dégrade rien, il casse tous les clients d'un coup.

Quelle version de la norme a introduit cela

L'histoire de l'authentification MCP compte quatre révisions, et savoir laquelle vous lisez a son importance : beaucoup de tutoriels en ligne décrivent encore une version vieille de deux générations.

Deux de ces éléments méritent mieux qu'une mention. Un troisième mérite une remarque : tant que le serveur MCP devait être son propre serveur d'autorisation, toute entreprise disposant déjà d'un annuaire et d'un SSO se retrouvait à en gérer un second, uniquement pour l'IA. La requalification de 2025-06-18 a levé cet obstacle, et c'est la raison pour laquelle le sujet est devenu abordable pour des applications métier ordinaires.

Tout l'édifice repose sur la RFC 9728, et elle est jeune : OAuth 2.0 Protected Resource Metadata n'a été publiée qu'en avril 2025, après des années de brouillon. C'est elle qui permet à un client de partir d'une adresse et de trouver un accueil. Rien de l'expérience décrite au début de cet article n'existe sans elle.

Le Dynamic Client Registration est appelé à disparaître, et cela devrait changer ce que vous écrivez aujourd'hui. Ce mécanisme demande à un endpoint public de créer un enregistrement en base pour tout client qui en fait la demande, ce qui ouvre une surface d'abus et fait grossir une table sans limite. Les Client ID Metadata Documents lui substituent un modèle décentralisé emprunté à IndieAuth : le client se présente avec une URL HTTPS qu'il contrôle en guise d'identifiant, votre serveur d'autorisation va y lire son nom, son logo et ses URI de redirection, et rien n'est stocké. Prenez encore en charge le DCR pour les clients qui en dépendent, mais n'y adossez pas votre produit. Concrètement, traitez-le comme une compatibilité descendante que vous retirerez un jour, avec les protections qui vont avec : une taille de corps bornée, une validation stricte des URI de redirection, et l'idée qu'un nom de client enregistré de la sorte n'est jamais une donnée de confiance.

ChatGPT autant que Claude

Les deux produits sont des clients MCP et mènent le flux pour l'utilisateur, par des chemins différents.

Claude. Les connecteurs personnalisés en MCP distant sont disponibles sur l'ensemble des offres. Un utilisateur individuel passe par Personnaliser, Connecteurs, Ajouter un connecteur personnalisé, puis colle l'URL. Sur Team et Enterprise, seul un propriétaire ajoute le connecteur à l'organisation, après quoi chaque membre s'y connecte avec son propre compte. Ce découpage convient exactement à un système d'entreprise : une décision administrative, puis une identité par personne. La formule d'Anthropic pour décrire ce que l'utilisateur obtient mérite d'être citée, car c'est elle qui fait passer le sujet en interne : Claude agit pour vous « sans jamais voir votre mot de passe ».

ChatGPT. La prise en charge complète de MCP, écritures comprises, se trouve derrière le mode développeur : Paramètres, Applications, Paramètres avancés. Vous ajoutez ensuite un connecteur personnalisé avec l'URL de votre serveur et choisissez OAuth. L'Apps SDK d'OpenAI constitue la voie séparée, et plus lourde, pour publier une intégration dans l'annuaire d'applications, avec revue et distribution à la clé.

Une contrainte s'applique aux deux et prend beaucoup de monde de court : le serveur doit être un point d'entrée HTTPS public. Aucun des deux produits n'atteint un serveur MCP installé sur un portable ou dans un réseau privé. C'est une décision d'hébergement à prendre avant d'écrire la moindre ligne de code.

Reste une remarque de terrain. Un même serveur ne se comporte pas toujours de façon identique dans les deux clients, alors testez dans les deux, et attendez-vous à ce que les subtilités de découverte de la section suivante soient précisément l'endroit où ils divergent.

Ce qu'il faut implémenter

Moins que ce que les équipes imaginent, à condition que votre application dispose déjà d'une authentification. Toute l'économie du chantier tient à cette condition.

Notre CRM a livré le flux en quatre jours au mois d'août, dans cet ordre, qui vaut pour à peu près n'importe qui.

L'écran de consentement mérite son propre paragraphe, parce que l'instinct d'ingénieur s'y trompe. Ce n'est pas une page, c'est une décision. Le nôtre est volontairement nu, sans navigation ni rien de cliquable en dehors d'Autoriser et Annuler, et il affiche trois faits : quel client demande l'accès, avec quel compte vous êtes connecté, et quelle portée vous êtes sur le point d'accorder. Deux règles derrière cette page valent d'être reprises telles quelles.

• Chaque valeur affichée provient de la requête garée côté serveur, jamais de la chaîne de requête qui déclenche l'affichage. Sans cela, ce que l'utilisateur lit n'est pas nécessairement ce qu'il accorde.
• Le nom du client est fourni par l'attaquant dès lors que l'enregistrement est ouvert. Il est donc échappé et rendu comme du texte, jamais dans un attribut ni dans une URL.

Si ce chantier tient en une semaine plutôt qu'en un trimestre, c'est que l'endpoint d'autorisation vit dans le même binaire que l'application et réutilise la session dont l'utilisateur dispose déjà. Sur la plateforme du cabinet comptable, cela signifie pas de second flux Google, pas de seconde URI de redirection, et la restriction de domaine posée sur la connexion suffit à réserver le connecteur aux salariés du cabinet, sans effort supplémentaire.

Cinq détails qui cassent tout en silence

Chacun nous a coûté au moins une demi-journée, et tous se manifestent de la même façon : la boîte de dialogue du connecteur échoue sans message exploitable.

1. L'émetteur annoncé dans vos métadonnées ne correspond pas à l'iss que portent vos jetons. C'est la première cause d'échec de la fenêtre « Ajouter un connecteur personnalisé », et elle échoue sans rien dire à personne. Le correctif est structurel plutôt qu'attentionnel : lisez les deux valeurs depuis une seule configuration, dans un seul processus, pour qu'elles ne puissent pas diverger.

2. Vous ne servez qu'une seule orthographe des métadonnées du serveur d'autorisation. Les clients ne sondent pas tous la même : les uns vont sur /.well-known/oauth-authorization-server, les autres sur /.well-known/openid-configuration, et certains n'essaient qu'une seule adresse. Un 404 sur celle que le client a choisie met fin au flux sans recours. Servez le même corps aux deux, cela coûte une route.

3. Vous ne servez le document de ressource protégée que sur le chemin nu. La RFC 9728 autorise un client à insérer le chemin de la ressource dans l'URL well-known, si bien qu'un client dont la ressource est https://exemple.fr/mcp peut légitimement sonder /.well-known/oauth-protected-resource/mcp. Montez donc le même gestionnaire sur le chemin nu et sur un joker en dessous.

4. Vos documents de découverte ne sont pas ouverts en CORS. Les clients qui tournent dans un navigateur les récupèrent depuis une autre origine, avant même qu'un identifiant existe. Ces documents sont publics par nature, puisqu'ils expliquent à un appelant non authentifié comment s'authentifier, et un Access-Control-Allow-Origin: * ne donne donc rien de plus que l'ouverture de l'URL dans un onglet.

5. Vous mettez la découverte en cache pour des heures. Ces documents encodent votre émetteur et vos endpoints. Un changement de nom de domaine, ou la correction d'un émetteur erroné, devrait alors attendre l'expiration du cache chez tous les clients qui l'ont conservé. Nous plafonnons à cinq minutes, pour des documents peu coûteux et rarement demandés.

Un sixième point, qui tient de la décision plutôt que du bug : n'émettez jamais un jwks_uri vide. Si vous signez vos jetons de façon symétrique, il n'y a pas de jeu de clés à publier et le champ doit être absent, pas égal à la chaîne vide. Réutiliser une structure prévue pour lire des métadonnées afin d'en produire est précisément la façon dont un champ vide part en production.

Pourquoi nous avons cessé de compter sur notre mémoire

Aucun de ces cinq défauts ne se voit en relecture de code : pris isolément, le code qui les provoque a l'air juste. Après la troisième implémentation, nous avons donc sorti l'endpoint dans une bibliothèque interne partagée, et écrit à côté un paquet de conformité qui vérifie le comportement plutôt que le code source.

La distinction fait tout. Le dispositif précédent était un script de CI qui cherchait des chaînes de caractères, et il a échoué comme échoue toujours l'inspection de source : trois dérogations, une option de sortie, et malgré cela il laissait passer le seul service dont l'endpoint s'appelle /internal/mcp et ne correspondait donc à aucune recherche sur /mcp. Son remplaçant pilote le vrai handler du service avec de vraies requêtes, et démontre qu'un client qui reçoit un 401 peut suivre le défi jusqu'à un document réellement servi, décrivant un chemin qui existe réellement.

Si vous comptez faire cela plus d'une fois, écrivez ce test avant la deuxième.

La sécurité, honnêtement

Ce mécanisme est plus sûr que la clé d'API qu'il remplace, sans être sûr pour autant, et la différence porte un nom : l'autorisation, que le jeton ne vous donne pas.

Ce que vous obtenez sans rien faire : une identité par personne au lieu d'un secret partagé, une étape de consentement explicite, des jetons qui expirent seuls, une révocation centralisée, et, quand vous réutilisez votre fournisseur d'identité, la procédure de départ que vous appliquez déjà.

Ce qui reste à votre charge :

• Cadrer chaque outil sur les droits réels de l'appelant, côté serveur. Le jeton dit qui appelle et ne dit rien de ce que cette personne peut faire. Dans notre CRM, chaque requête est automatiquement restreinte à l'organisation de l'appelant, de sorte que le modèle ne peut pas franchir une frontière de locataire même s'il essaie.
• Valider l'audience. Votre serveur doit rejeter les jetons qui n'ont pas été émis pour lui, et c'est cette exigence qui empêche un jeton récupéré par un autre serveur MCP de fonctionner chez vous. La vérification tient en une ligne de code et ne se voit jamais dans les tests, puisque tout fonctionne parfaitement sans elle tant que personne n'attaque.
• Ne jamais relayer le jeton entrant vers l'aval. Si votre serveur MCP appelle une API tierce, il agit comme client de cette API avec un jeton distinct. Transmettre celui de l'utilisateur, c'est le problème du député confus, et la norme l'interdit sans nuance.
• Instrumenter. Nous enregistrons trois événements, parce qu'ils répondent à trois questions différentes : l'issue de l'écran de consentement, une session MCP qui a abouti, et chaque appel d'outil avec son résultat. Aucun argument n'est jamais enregistré. Sans cela, un cabinet qui ne s'est jamais connecté et un cabinet qui s'est connecté sans rien faire se ressemblent parfaitement, alors qu'ils appellent des réactions opposées de votre part.
• Écrire l'écran de consentement pour celui qui le lit. C'est le seul instant où un humain voit ce qu'il accorde, et une portée décrite dans votre vocabulaire interne transforme ce contrôle en décor.

Reste un sujet que cet article laisse volontairement de côté, parce qu'il relève d'un autre problème : ce qui se passe quand le modèle écrit. L'autorisation détermine si un appel est permis. Elle ne dit rien de la capacité de l'utilisateur à voir ce que le modèle vient de faire, ni à revenir dessus.

Nous avons construit les deux approches, et elles diffèrent profondément. Sur des enregistrements métier bien délimités, l'outil d'écriture accepte un paramètre dry_run, renvoie l'objet qu'il créerait, et l'humain valide avant que quoi que ce soit ne soit enregistré. Sur un document que quelqu'un façonne au fil de l'eau, ce schéma devient inutilisable : demander une confirmation à chaque retouche d'une carte des vins de quatre-vingt-dix références est pire que pas d'assistant du tout. L'agent écrit alors directement, le filet de sécurité étant l'annulation et le panneau de révisions, complétés par un outil qui renvoie le résultat au modèle sous forme de capture d'écran, pour qu'il voie ce qu'il a fait. Nous en sommes venus là en renonçant à une conception de type proposition, aperçu, application.

Le premier cas est détaillé dans ce qui sépare une démonstration MCP d'un service qui tient en production. Le second n'est écrit nulle part pour l'instant.

Une revue de sécurité posera ces questions, et elle les posera là où elle pose toutes les autres, comme nous l'avons décrit à propos du questionnaire de sécurité fournisseur : qui peut l'atteindre, sous quelle identité, et comment coupez-vous l'accès.

Faut-il s'y mettre maintenant

Le calcul ne relève pas de la stratégie IA. Il dépend de qui sont vos utilisateurs.

Allez-y si votre application a déjà un SSO et un modèle de droits. Vous raccordez surtout des pièces existantes, et le flux hérite gratuitement de votre gestion des départs. C'est le cas où une semaine de travail élargit le cercle des personnes qui, chez votre client, peuvent se servir de l'outil.

Allez-y si vous ouvrez l'IA à des profils non techniques. Une clé d'API plafonne votre adoption au sous-ensemble d'utilisateurs prêts à éditer un fichier de configuration, sous-ensemble qui se confond, dans la plupart des entreprises, avec l'équipe technique. Nous l'avons mesuré à nos dépens : la fonctionnalité a existé deux mois derrière une clé sans trouver son public, et c'est le guide en trois étapes qui l'a débloquée.

Attendez si votre serveur MCP est interne et sert cinq développeurs. Un secret statique dans un coffre reste une réponse défendable pour un outil dont les cinq utilisateurs ont tous un terminal ouvert. Le flux décrit ici gagne son coût quand la population s'élargit, sort de l'entreprise, ou change souvent.

Reprenez le sujet autrement si vous n'avez pas d'authentification du tout. Ce chantier tient en une semaine pour une plateforme existante parce que l'identité y est déjà. Construire un fournisseur d'identité dans le seul but d'ouvrir un connecteur MCP est un autre projet, qu'il faut cadrer comme tel. Dans ce cas de figure, la bonne séquence consiste presque toujours à brancher d'abord l'application sur un fournisseur existant, Google Workspace ou Microsoft Entra selon la maison, puis à poser le connecteur par-dessus une fois que les comptes et les rôles sont en place.

Si vous vous reconnaissez dans l'un des deux premiers cas et que vous préférez ne pas le construire en interne, c'est exactement le type de mission que nous prenons en main : nous concevons, développons et exploitons le serveur MCP ainsi que le flux d'autorisation qui le protège, qu'il s'adosse à votre propre plateforme ou à un système existant comme Salesforce.

---

Le motif de fond reste celui qui rendait MCP intéressant dès le départ, et que nous avions détaillé dans ce qu'est MCP et quand il vaut mieux qu'une intégration maison : une norme existe pour éviter que N clients et M serveurs se traduisent par N fois M intégrations. La norme d'autorisation étend ce raisonnement des outils jusqu'à la porte d'entrée. Votre logiciel n'a besoin ni d'une intégration Claude ni d'une intégration ChatGPT, mais d'être une ressource protégée OAuth correcte, une bonne fois.

Pour voir ce que cela donne à l'échelle, nous exposons 91 outils sur un seul serveur MCP couvrant CRM, facturation et stocks, et nous avons écrit ce qui sépare une démonstration MCP d'un service qui tient en production.

Si vous pesez l'intérêt d'en exposer un sur votre propre plateforme, c'est une conversation que nous avons presque chaque semaine : notre travail sur MCP, ou dites-nous ce que vous exploitez.