Il est 23h, tu veux juste écrire un article et l’envoyer sur ton site depuis Claude comme tous les soirs, et l’app te crache « Impossible de connecter ». Aucun détail, aucune piste, juste une erreur inconnue. J’ai passé une soirée entière à démonter ce bug jusqu’à l’os. Bonne nouvelle, tu vas t’en sortir en dix minutes avec ce que j’y ai trouvé.

Ce tuto est pour toi si tu as branché Claude sur ton WordPress via un connecteur MCP, que ça tournait nickel, et qu’un matin la connexion refuse de repartir. Le mécanisme est le même côté ChatGPT, donc ça vaut aussi pour lui. Et si tu es sur un hébergement mutualisé ou managé façon WordPress.com, tu es pile la cible.

Le connecteur MCP, et pourquoi tu y tiens

Rembobinons deux secondes pour ceux qui débarquent. Un connecteur MCP, c’est le tuyau qui donne à Claude les clés de ton site. Pas juste pour lire, pour agir. Écrire un brouillon d’article et le pousser en ligne, remplir tes champs SEO, aller chercher tes stats GA4 sans que tu bouges de ta conversation. Tu parles à Claude, Claude opère ton WordPress.

Dit comme ça, c’est exactement le futur qu’on nous promet depuis des mois. Une IA qui ne te recrache pas du texte à copier-coller, mais qui met vraiment les mains dans le cambouis à ta place. Sur le papier, c’est génial. Dans la vraie vie, ça tient sur un fil, et ce fil s’appelle l’authentification.

Le symptôme, et pourquoi il t’envoie sur une fausse route

Le premier réflexe quand « Impossible de connecter » s’affiche, c’est de flipper pour ton site. Tu te dis que le serveur est tombé, que le plugin a explosé, que t’as cassé un truc.

Faux. Ton site va très bien. Si tu pousses la reconnexion, tu tombes vite sur le vrai message, planqué dans un coin de l’écran. « L’autorisation a échoué », avec une référence d’erreur cryptique du genre ofid_51510a26.... Ce n’est pas une panne de serveur. C’est l’étape d’autorisation qui se casse la figure, tout à la fin, au moment où Claude et ton site échangent leur poignée de main secrète.

Et cette nuance change tout. Parce que tant que tu crois que ton site est cassé, tu vas passer une heure à redémarrer des trucs qui n’ont jamais eu de problème.

Le diagnostic, ce que personne n’explique en français

Là on rentre dans le dur, et c’est la partie que je n’ai trouvée nulle part expliquée proprement. Accroche-toi, ça vaut le coup.

Un connecteur moderne se branche via OAuth, le même protocole que quand tu cliques « se connecter avec Google » sur un site tiers. Sauf qu’ici tout est automatique. Claude s’enregistre auprès de ton site comme une nouvelle application, ton site lui répond « ok, voici ton identifiant client », tu valides une page d’autorisation, puis Claude échange un code contre un jeton d’accès. Quatre étapes, une chorégraphie bien réglée.

J’ai sondé chaque maillon un par un. La découverte des réglages OAuth répond correctement. L’enregistrement du client renvoie un beau code 201, avec un identifiant tout neuf. Le point d’échange de jeton est vivant. Vu de l’extérieur, tout est vert. Le serveur fait son boulot à la perfection.

Alors pourquoi ça pète ? Parce que ton hébergement mutualisé ne tourne pas sur un seul serveur, il en fait tourner plusieurs derrière la même adresse. Et le plugin qui gère l’OAuth range l’identifiant client fraîchement créé dans une mémoire temporaire locale à un serveur. L’enregistrement atterrit sur le serveur A. Deux secondes plus tard, l’échange de jeton, lui, tombe sur le serveur B. Qui n’a jamais entendu parler de ce client. « Client inconnu », autorisation refusée, ofid dans ta figure.

La chorégraphie OAuth réclame une mémoire partagée entre toutes les requêtes. L’infra mutualisée ne la partage pas. Voilà tout le bug, en une phrase. Ce n’est pas ta faute, ce n’est même pas vraiment la faute du plugin. C’est la rencontre entre un protocole qui suppose un seul serveur et une infra qui en aligne dix.

Les fausses pistes, pour que tu ne perdes pas ta soirée comme moi

Avant de trouver ça, j’ai tout essayé. Autant t’épargner le détour.

Supprimer le connecteur et le rajouter à neuf ne change rien, le nouveau client se cogne au même mur. Faire la manip dans le navigateur plutôt que dans l’app de bureau ne change rien non plus, le bug est en aval de la connexion. Réduire les permissions demandées, pareil. Désactiver puis réactiver le plugin pour qu’il reconstruise ses tables, toujours le même échec.

Le test qui m’a définitivement convaincu, c’est d’avoir installé un plugin MCP concurrent, tout autre, tout neuf. Même mur, exactement au même endroit. Quand deux plugins indépendants échouent pile à la même étape, ce n’est plus le plugin le coupable. C’est l’infra en dessous. À partir de là, inutile de continuer à changer de plugin, la vraie sortie est ailleurs.

La vraie solution, le jeton statique

L’idée est simple. Puisque c’est la chorégraphie OAuth qui se vautre, on la contourne complètement. On passe par un jeton statique, une longue clé secrète que tu génères une fois et que Claude envoie telle quelle à chaque requête. Pas de danse, pas d’échange en plusieurs étapes, pas de mémoire à partager entre serveurs. Juste une clé, direct dans l’en-tête. Impossible de se casser la figure sur l’étape qui n’existe plus.

La plupart des bons plugins MCP proposent cette option, cachée dans leurs réglages sous un nom du genre « Bearer Token » ou « API Token ». Voici la marche à suivre, une fois pour toutes.

D’abord, génère le jeton. Dans ton wp-admin, ouvre les réglages du plugin, trouve la section des tokens API, et crée un nouveau token avec la portée la plus large. Copie la chaîne complète tout de suite, elle ne s’affiche qu’une seule fois.

Ensuite, installe Node.js sur ta machine si ce n’est pas déjà fait, en récupérant la version LTS sur nodejs.org. Le pont qui va porter ta clé en a besoin. Tu vérifies dans un terminal avec node --version, tu dois voir un numéro s’afficher.

Enfin, dis à Claude d’utiliser cette clé. Dans l’app Claude de bureau, direction Réglages, Développeur, Modifier la configuration. Ça ouvre un fichier claude_desktop_config.json. Tu y ajoutes un bloc comme celui-ci, qui lance le pont mcp-remote en lui passant ton jeton dans l’en-tête d’autorisation.

{
  "mcpServers": {
    "mon-wordpress": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://ton-site.com/wp-json/easy-mcp-ai/v1/mcp",
        "--header",
        "Authorization: Bearer TON_TOKEN_ICI"
      ]
    }
  }
}

Tu remplaces ton-site.com par ton domaine et TON_TOKEN_ICI par le jeton que tu viens de générer. L’URL exacte du point de terminaison, elle, est affichée dans les réglages de ton plugin, chacun a la sienne. Attention si le fichier contient déjà des choses, tu n’effaces rien, tu ajoutes ton bloc au bon endroit. Une virgule mal placée et l’app ignore tout le fichier en silence, c’est le piège classique.

Tu enregistres, tu quittes l’app en entier, tu relances. Vingt à trente secondes le temps que le pont se télécharge, et ton serveur apparaît en « running ». Il ne peut plus échouer comme l’OAuth, tout simplement parce qu’il n’y a plus d’OAuth.

Le périmètre, parce que je ne te raconte pas d’histoires

Un tuto honnête pose ses limites, sinon c’est de la vente. Deux points à garder en tête.

Ce diagnostic colle à mon cas, l’hébergement managé multi-serveurs. Sur un VPS à toi, un seul serveur, l’OAuth n’a aucune raison de se planter de cette façon, puisque la mémoire est partagée par défaut. Si tu es sur un VPS et que ça casse quand même, la cause est probablement ailleurs, va voir du côté d’un pare-feu ou d’un cache trop agressif. Le contournement par jeton statique reste valable dans tous les cas, mais le mécanisme du bug, lui, est spécifique au mutualisé.

Second point, le jeton statique vit dans la config de l’app de bureau. Donc ça marche sur Mac et sur PC, pas sur iPad ni sur mobile, qui ne font pas tourner le pont. Sur tablette, tu restes tributaire de l’OAuth, et donc tu attends que l’éditeur du plugin corrige la persistance de son côté. En attendant, tu répartis. La station lourde sur l’ordi, la rédaction simple ailleurs.

Le verdict

Voilà ce que cette soirée m’a confirmé, et c’est plus grand que le bug. La technologie pour confier à une IA les clés entières de ton site existe, elle marche, elle est là maintenant. Le seul truc qui se met en travers, ce n’est pas l’intelligence de la machine, c’est de la plomberie d’hébergement pensée pour une époque où aucun robot ne venait toquer à la porte de ton WordPress.

L’OAuth grand public bute encore sur des détails d’infra pendant que la promesse, elle, est déjà tenue. Un jeton statique, deux minutes de config, et tu shuntes toute cette plomberie d’un coup. La vraie leçon, c’est que tu n’as pas à attendre que tout le monde se mette d’accord. Tu prends la clé, tu la colles où il faut, et c’est toi qui pilotes. Comme toujours, les gens qui avancent sont ceux qui ne demandent pas la permission.

Si cet article t’a été utile, n’hésite pas à me le dire en commentaire. Tu peux aussi soutenir le blog en faisant tes achats Amazon via ce lien.