ChatGPT n'ouvre plus vos connecteurs MCP ?

En bref

Depuis le 20 août 2026, notre connecteur MCP personnalisé (auto-hébergé, mcp.arleo.eu, conforme OAuth 2.1 + PKCE + spécification MCP) a cessé de fonctionner dans ChatGPT, sans qu’aucune ligne de code ni de configuration n’ait changé côté serveur. Le connecteur avait pourtant fonctionné sans problème jusqu’à la veille.

Symptôme côté ChatGPT : bandeau “connecté, mais toutes les autorisations demandées n’ont pas été accordées”, puis “Aucune action de l’application n’est disponible pour le moment” — zéro outil chargé, à chaque tentative.

Après une investigation exhaustive (logs serveur, capture directe de la réponse initialize, tests A/B sur quatre versions différentes de notre code, contre-épreuve avec un client tiers émulant ChatGPT, vérification Cloudflare, contact du support OpenAI), la cause n’est pas un défaut de notre serveur. Tout indique une restriction récente d’OpenAI limitant le support MCP complet aux offres ChatGPT Business, Enterprise et Edu — retirant de fait cet accès aux comptes Plus, sans changement clairement annoncé ni message d’erreur explicite. Voir aussi l’audit complet mené par Claude.ai (compte Pro) sur ce même serveur, qui n’a rencontré aucun problème.

Résumé technique

OAuth /authorize        : succès
OAuth /token             : succès
Bearer token             : accepté
MCP initialize           : HTTP 200, réponse complète
Mcp-Session-Id            : retourné
notifications/initialized : jamais reçu (ChatGPT réel)
tools/list                 : jamais reçu (ChatGPT réel)
UI ChatGPT                 : "Aucune action de l'application n'est disponible pour le moment"

Reproduit avec :
- v1.8.8, v1.9.0, v1.9.1 et v1.9.2 (4 versions serveur réellement redéployées)
- scopes read, write et admin testés séparément
- lecture seule via ?profile=reader
- client OAuth statique pré-enregistré et client Dynamic Client Registration neuf
- ancien secret et secrets nouvellement générés

Contre-épreuve : un client tiers (MCPJam) configuré pour émuler le profil
"ChatGPT" complète le flow entier — 17 étapes, tools/list réussi, 32 outils
listés. Le protocole passe très bien un client réel jouant "ChatGPT" ; c'est
ChatGPT lui-même, dans les faits, qui n'y arrive pas. Claude.ai (Pro) n'a de
son côté rencontré aucun problème sur ce même serveur.

Ce qu’on a observé côté serveur

À chaque tentative de connexion, la séquence est toujours identique et toujours “réussie” jusqu’à un certain point :

POST /register        → succès (Dynamic Client Registration)
GET  /authorize        → succès, redirection avec code
POST /token             → succès, token émis (PKCE S256 vérifié)
POST /mcp initialize    → HTTP 200 complet, session MCP créée
                        → puis plus rien.

Aucune requête tools/list n’est jamais envoyée par ChatGPT après initialize — ni notifications/initialized. Le client abandonne silencieusement la négociation MCP après avoir reçu une réponse serveur pourtant valide et complète, à chaque fois, sans exception.

La réponse initialize capturée en direct

Pour éliminer tout doute sur la conformité de notre réponse, on a rejoué manuellement la première moitié du handshake (DCR + PKCE + initialize) avec un client de test jetable, en dehors de ChatGPT, pour capturer exactement ce que le serveur renvoie :

HTTP/2 200
content-type: text/event-stream
mcp-session-id: <session-id>

{
  "jsonrpc": "2.0",
  "id": 0,
  "result": {
    "capabilities": {
      "logging": {},
      "prompts": { "listChanged": true },
      "resources": { "listChanged": true, "subscribe": true },
      "tools": { "listChanged": true }
    },
    "protocolVersion": "2025-06-18",
    "serverInfo": {
      "name": "mcp-hugo-server-go",
      "version": "v1.9.2"
    }
  }
}

Réponse complète, protocole 2025-06-18 correctement annoncé, Mcp-Session-Id présent. Rien dans cette réponse ne justifie qu’un client s’arrête là — ce qui recentre le problème sur une décision prise côté ChatGPT après réception de cette réponse, pas sur un défaut de conformité du transport.

Exemple de logs réels — client DCR neuf, scope par défaut

Pour écarter tout effet de cache lié à un client_id déjà connu, on a laissé ChatGPT s’enregistrer lui-même via Dynamic Client Registration (/register), sans lui fournir d’identifiant pré-existant. Notre politique DCR plafonne automatiquement ces clients à read par sécurité, même si le client demande plus large — logs serveur, horodatage UTC, client_id généré côté serveur (aucun secret, ce n’est qu’un identifiant public) :

{"time":"2026-08-20T18:58:51Z","level":"INFO","msg":"oauth_register","outcome":"success","client_id":"yz0f4gYkQUSXbsjjRs5oogGcllRBoisE","redirect_uri_hosts":["chatgpt.com"],"scope":"read"}
{"time":"2026-08-20T18:58:59Z","level":"INFO","msg":"oauth_authorize","outcome":"success","client_id":"yz0f4gYkQUSXbsjjRs5oogGcllRBoisE","redirect_uri_host":"chatgpt.com","pkce_used":true,"scope_requested":"read write admin","response_type":"code"}
{"time":"2026-08-20T18:59:01Z","level":"INFO","msg":"oauth_token","grant_type":"authorization_code","outcome":"success","client_id":"yz0f4gYkQUSXbsjjRs5oogGcllRBoisE","pkce_used":true,"scope":"read"}
{"time":"2026-08-20T18:59:02Z","level":"INFO","msg":"mcp: session created","scope":"read","rank":0,"remote_addr":"192.168.122.1:52080"}

ChatGPT demande read write admin à /authorize, notre politique DCR clampe à read à l’émission du token (comportement attendu et documenté, pas un bug), la session MCP est créée avec succès — puis, comme à chaque fois, aucune requête tools/list ne suit. Le cycle complet s’est répété deux fois de suite dans la même minute, à l’identique.

Exemple de logs réels — connecteur en lecture seule, profil d’exposition restreint

Pour tester l’hypothèse d’un accès “lecture seule” encore disponible sur les comptes Plus, on a créé un client OAuth dédié avec un scope read strict, connecté sur https://mcp.arleo.eu/mcp?profile=reader — ce paramètre ?profile= limite en plus la liste d’outils réellement enregistrée sur la session au sous-ensemble “lecture” uniquement (fonctionnalité indépendante des scopes OAuth, ajoutée en v1.8.9) :

{"time":"2026-08-20T18:50:01Z","level":"INFO","msg":"oauth_authorize","outcome":"success","client_id":"chatgpt-read","redirect_uri_host":"chatgpt.com","pkce_used":true,"scope_requested":"read","response_type":"code"}
{"time":"2026-08-20T18:50:03Z","level":"INFO","msg":"oauth_token","grant_type":"authorization_code","outcome":"success","client_id":"chatgpt-read","pkce_used":true,"scope":"read"}
{"time":"2026-08-20T18:50:04Z","level":"INFO","msg":"mcp: session created","scope":"read","rank":0,"profile":"reader","remote_addr":"192.168.122.1:60656"}

Même résultat : authentification et session réussies, profile:"reader" bien pris en compte côté serveur, et toujours aucun tools/list. Reproduit une seconde fois 27 secondes plus tard, identique.

Contre-épreuve : un client émulant ChatGPT complète le flow sans accroc

Pour vérifier que le protocole MCP + OAuth exposé par notre serveur n’a rien d’anormal, on a rejoué exactement le même flow avec MCPJam, un client de debug MCP dédié — en sélectionnant explicitement son profil client “ChatGPT” (openai-mcp 1.0.0, agent GPT-5 nano), censé reproduire fidèlement le comportement du connecteur ChatGPT réel.

Le diagnostic de l’outil lui-même, à la fin du flow :

« The OAuth auto-discovery looks good — no adjustments needed. […] Full flow finished: All 17 steps completed successfully with an access token and refresh token. Server now authenticated: Final MCP request returned 200 OK with the token. The flow shows 9 info logs, 0 warnings, and 0 errors — everything proceeded as expected. »

Logs serveur correspondants, même fenêtre horaire, même politique DCR (clamp à read) que pour les tentatives ChatGPT réelles ci-dessus — mais cette fois avec la suite complète du protocole :

{"time":"2026-08-20T19:31:44Z","level":"INFO","msg":"oauth_register","outcome":"success","client_id":"cO8t4giwYq-cPwKzIdTm26XKrkhnwKBM","redirect_uri_hosts":["app.mcpjam.com"],"scope":"read"}
{"time":"2026-08-20T19:31:45Z","level":"INFO","msg":"oauth_authorize","outcome":"success","client_id":"cO8t4giwYq-cPwKzIdTm26XKrkhnwKBM","redirect_uri_host":"app.mcpjam.com","pkce_used":true,"scope_requested":"read write admin","response_type":"code"}
{"time":"2026-08-20T19:31:48Z","level":"INFO","msg":"oauth_token","grant_type":"authorization_code","outcome":"success","client_id":"cO8t4giwYq-cPwKzIdTm26XKrkhnwKBM","pkce_used":true,"scope":"read"}
{"time":"2026-08-20T19:31:49Z","level":"INFO","msg":"mcp: session created","scope":"read","rank":0,"profile":"","remote_addr":"192.168.122.1:41268"}

Et, contrairement à ChatGPT, la suite ne s’arrête pas là — de vrais appels POST /mcp avec du temps de traitement réel s’enchaînent sur plusieurs minutes (tools/list, puis des appels d’outils, avec des canaux GET /mcp SSE ouverts en parallèle) :

POST /mcp   200   32ms
POST /mcp   200   23ms
POST /mcp   202   0ms     (notification)
GET  /mcp   200   313ms   (canal SSE)
POST /mcp   200   41ms
POST /mcp   200   28ms
GET  /mcp   200   161ms
POST /mcp   200   60ms

Résultat côté client : 32 outils listés et exploitables (list_pages, search_content, get_site_information, inspect_rendered, plan_page, suggest_links, etc. — le sous-ensemble lecture attendu pour un scope read), avec un résumé explicite : « The tools appear to be for content management and site inspection […] Would you like to run any of these tools? »

Même serveur, même minute, même politique OAuth/DCR, un client qui prétend jouer le rôle de ChatGPT — et le protocole va jusqu’au bout sans le moindre avertissement. Ce n’est donc ni une question de conformité MCP, ni de configuration serveur : c’est le connecteur ChatGPT réel, spécifiquement, qui n’arrive pas à finir ce que sa propre émulation par un tiers finit sans difficulté.

Autre contraste, sur le même serveur, la même semaine : Claude.ai (compte Pro) a audité 72 outils en écriture réelle — pages, bundles bilingues, chunked upload, build/publish, gestion Hugo admin — sans trouver le moindre bug. Ce n’est donc pas non plus une question de robustesse générale du serveur face à des clients IA.

Ce qu’on a exclu, avec preuves

Avant de conclure à une cause externe, on a méthodiquement éliminé toutes les explications internes plausibles :

• Redirect URI / whitelist OAuth : testé directement la fonction de matching côté serveur avec le path exact renvoyé par ChatGPT (https://chatgpt.com/connector/oauth/<id>) — le wildcard enregistré matche correctement. Code inchangé depuis plusieurs semaines.
• Scope de la réponse OAuth (write vs read write) : une théorie plausible (ChatGPT comparerait textuellement les scopes demandés/accordés dans la réponse /token, plutôt que de faire confiance à notre hiérarchie interne admin ⇒ write ⇒ read) a été testée en déployant en production un correctif qui fait exactement ça — la réponse /token contenait bien "read write admin" au lieu de "admin" seul. Le symptôme a persisté à l’identique. Hypothèse invalidée empiriquement, pas seulement par le raisonnement.
• Dépendances Go : un bump récent de 11 modules (SDK MCP, x/net, x/oauth2, etc.) faisait partie des changements les plus récents du dépôt. Le test A/B ci-dessous, qui redéploie aussi des versions antérieures à ce bump, l’exclut implicitement : les versions sans ce bump échouent tout autant.
• Cache de découverte du catalogue d’outils : vérifié qu’un correctif récent lié à la cohérence du catalogue d’outils avait été mergé sur notre dépôt 9 heures après la première panne observée, et déployé en production 9 heures après ça — chronologiquement impossible comme cause.
• Cloudflare (WAF / bot management) : interrogation directe de l’API GraphQL Security Events sur notre zone — zéro événement de blocage, challenge ou rate-limit sur le domaine du connecteur MCP sur 24h glissantes.
• Métadonnées securitySchemes par outil (extension documentée par OpenAI pour son SDK Apps) : implémentées et déployées en test — sans effet, cohérent avec le fait que ChatGPT n’atteint jamais l’étape tools/list où cette métadonnée serait lue.
• Rotation complète des identifiants OAuth (nouveau client_id/client_secret, y compris un client dédié au scope admin complet) : même échec, à l’identique.
• Scope réduit à la lecture seule (read uniquement, profil d’exposition restreint aux outils de lecture) : même échec, à l’identique — logs ci-dessus.
• Conformité du protocole MCP/OAuth exposé : un client tiers émulant fidèlement ChatGPT complète le flow entier sans le moindre avertissement, et Claude.ai audite 72 outils sans anomalie sur le même serveur — voir contre-épreuve ci-dessus.

Le test décisif : A/B sur 4 versions serveur réelles

Pour trancher définitivement la question “est-ce une régression de notre code ?”, on a rebuild et redéployé en conditions réelles, l’une après l’autre, quatre versions distinctes de notre serveur — dont celle qui avait servi la dernière session ChatGPT réussie, redéployée bit pour bit :

Quatre versions, y compris v1.9.1 qui avait réellement servi une session ChatGPT réussie quelques jours plus tôt, redéployée bit pour bit sans aucune modification : même échec, à chaque fois. Ce résultat élimine toute hypothèse de régression logicielle de notre côté, à n’importe quel niveau du code testé, sur plus de dix jours d’historique — dépendances comprises.

Ce que dit OpenAI

La documentation officielle est actuellement contradictoire entre deux pages officielles.

La page d’aide Mode développeur et applications MCP dans ChatGPT, section “Disponibilité et exigences”, indique désormais :

« Les applications, la prise en charge complète de MCP et le mode développeur sont disponibles sur la version web de ChatGPT pour les clients ChatGPT Business et Enterprise/Edu. »

Aucune mention de l’offre Plus.

Le guide développeur officiel dit pourtant l’inverse à ce jour :

« Available to Pro, Plus, Business, Enterprise, and Education accounts. […] ChatGPT developer mode is a beta feature that provides full Model Context Protocol (MCP) client support for all tools, both read and write. »

Ces deux pages officielles se contredisent directement au moment de la rédaction : l’une inclut Plus avec un accès MCP complet read/write, l’autre l’exclut entièrement de la liste des offres éligibles.

Interrogé directement via son propre assistant de support (help.openai.com), OpenAI confirme la version restrictive sans ambiguïté :

« Le support MCP “complet” (avec actions write/modify) et le “developer mode” associé ne sont pas disponibles sur les comptes Plus : ils sont déployés en bêta pour ChatGPT Business, Enterprise et Edu. Les offres personnelles ont au mieux un accès limité en lecture (fetch/read) quand c’est proposé — le “full MCP” reste réservé aux plans Business/Enterprise/Edu. »

Le même assistant a ensuite suggéré, comme test de diagnostic, de publier temporairement un profil “lecture seule” (scopes read/fetch uniquement, aucune action write/admin) pour voir si l’onglet Actions se remplit — exactement le test qu’on avait déjà mené, en conditions réelles, avec le scope read strict et ?profile=reader documentés plus haut. Le résultat contredit leur propre hypothèse : même ce profil strictement en lecture n’a jamais atteint tools/list avec le vrai client ChatGPT, alors que le même profil fonctionne parfaitement avec un client tiers — ce qui suggère que l’« accès limité en lecture » évoqué pour les offres personnelles ne s’applique pas (ou plus, ou pas encore) au connecteur ChatGPT réel, du moins pas au moment de la rédaction.

Pourquoi ça ressemble à un bug alors que ça n’en est pas un

Le vrai problème ici n’est pas technique, il est communicationnel côté OpenAI :

• Le message d’erreur affiché (“toutes les autorisations demandées n’ont pas été accordées”) suggère un problème d’autorisation ou de configuration côté serveur du développeur — alors que le flow d’autorisation se termine avec succès à chaque étape mesurable, initialize inclus, et qu’un client tiers émulant ChatGPT réussit intégralement le même flow.
• Aucune bannière, aucun changelog visible, aucune notification n’accompagne ce changement de politique d’éligibilité — un développeur qui n’a pas la patience de refaire cette investigation complète conclura probablement, à tort, à un bug de son propre serveur.
• Les deux pages de documentation officielle se contredisent directement au moment de la rédaction, ce qui n’aide pas à diagnostiquer rapidement.
• Le support lui-même, via son propre assistant, propose un test de contournement (profil lecture seule) qui ne fonctionne pas dans la pratique — signe que même en interne, le comportement réel du produit n’est pas encore totalement documenté ni cohérent avec la doc publique.

Comment vérifier si vous êtes dans le même cas

Si votre connecteur MCP personnalisé fonctionnait et s’arrête brutalement de charger des outils dans ChatGPT (avec un message d’autorisation incomplète) :

1. Vérifiez dans vos logs serveur si initialize répond bien 200 et si une session est créée.
2. Vérifiez si une requête tools/list suit — si non, ce n’est très probablement pas votre serveur.
3. Rejouez le même flow avec un client de debug MCP tiers (MCPJam ou équivalent) en émulant le profil ChatGPT — s’il complète le flow sans problème, la responsabilité se déplace clairement vers le connecteur ChatGPT réel.
4. Vérifiez votre offre ChatGPT : si vous êtes en Plus, c’est probablement la cause ; sur Pro, seul un accès en lecture serait théoriquement disponible selon le Help Center (mais le guide développeur dit le contraire) — à vérifier au cas par cas.
5. Testez un client OAuth Dynamic Client Registration entièrement neuf pour écarter un problème de cache local — si l’échec persiste, la piste “compte/plan” se renforce.
6. Testez un scope et un profil strictement en lecture seule (?profile=reader) avant de conclure — si même ça échoue, ce n’est très probablement pas une question de permissions write/admin.

Ce qu’on a fait de notre côté

Rien — c’est bien le point. Après cette investigation, aucune modification n’a été conservée en production côté serveur (les tests A/B et binaires expérimentaux ont tous été rollback). Le serveur reste en version stable, avec l’ensemble de la matrice de compatibilité clients (Claude.ai, Le Chat, MCP Inspector, MCPJam, connecteurs tiers) fonctionnelle et inchangée — voir l’audit Claude.ai complet pour le détail.

Sources officielles OpenAI (contradictoires au 20/08/2026)

• Mode développeur et applications MCP dans ChatGPT — Help Center — réserve le MCP complet à Business/Enterprise/Edu, n’inclut pas Plus
• Developer mode — developers.openai.com — indique Pro/Plus/Business/Enterprise/Education tous éligibles au MCP complet read/write

Si vous rencontrez le même symptôme et disposez d’un compte Business/Enterprise/Edu pour comparer, ou si OpenAI a communiqué depuis la rédaction de cet article sur ce changement, n’hésitez pas à partager l’information.