J'ai donné à Claude Code un mot de passe d'app WordPress et une phrase. Il a géré tout le site.
Un client m'envoie un email. Rien de dramatique : remplacer le drapeau espagnol par un drapeau mexicain dans le sélecteur de langue de son site WP. Le genre de truc qu'on ne fait pas tous les jours et qui peut facilement bouffer toute votre matinée.
Je n'ai pas touché à ce site depuis une éternité. Un prestataire l'a construit il y a des années. Je ne me souviens même plus comment il a configuré l'i18n. Et franchement ? Pas envie.
Puis j'ai eu une idée. Et si Claude Code pouvait juste... s'en occuper.
Alors j'ai fait le truc : généré un mot de passe d'application WordPress, collé ça dans Claude Code avec l'URL du site et la demande du client, et je suis parti faire autre chose.
TL;DR : Claude Code a trouvé Polylang tout seul, changé le drapeau, purgé le cache Elementor, vérifié le front-end. Je n'ai jamais mentionné quel plugin gérait les langues. Puis il a audité le reste du site. Puis j'ai ouvert mes 54 autres sites clients. Ce qui était une corvée est devenu un workflow.
Le Ticket Client Que J'ai Failli Ignorer
La demande était assez simple. Le client a un site bilingue (espagnol/anglais), et le sélecteur de langue affiche un drapeau espagnol pour la version espagnole. Il veut le drapeau mexicain à la place. Logique pour son audience.
Normalement, vous vous connectez, trouvez les paramètres du plugin de traduction, localisez la config des drapeaux, changez ça, purgez le cache qui traîne, vérifiez le front-end, répondez au client. Vingt minutes si vous connaissez le site. Quarante-cinq si vous ne le connaissez pas.
Je ne connaissais pas ce site. Je l'avais sous-traité à un prestataire il y a deux ou trois ans. Je ne me souviens pas de ce qu'il a utilisé pour les traductions, quel page builder il y a dedans, quel plugin de cache tourne. Toute la mise en place d'une install WordPress de quelqu'un d'autre, et je suis censé plonger dedans à l'aveugle.
Alors au lieu de me connecter à wp-admin comme un adulte responsable, je suis allé dans Réglages > Utilisateurs > Mots de passe d'application. Trente secondes. J'ai collé l'URL, le mot de passe d'app, et l'email du client dans Claude Code. Une phrase de contexte de ma part : "occupe-toi de ça."
Et je suis parti.
Je lui ai donné les clés. Je ne lui ai pas dit quel type de voiture c'était.
Il a Trouvé Polylang. Je N'ai Jamais Dit Polylang.
Drapeau changé. Cache purgé. Front-end vérifié. Cinq minutes au total. C'est le résultat.
La transcription raconte une histoire différente de ce que j'attendais (je l'ai lue après coup, parce qu'à ce moment-là j'étais complètement ailleurs).
Claude Code a récupéré le code source HTML du site. Il a repéré une classe CSS : cpel-switcher__flag--es. À partir de cette seule classe, il a compris que Polylang gérait les traductions. Il a interrogé /pll/v1/languages via l'API REST, trouvé l'entrée de langue pour l'espagnol, changé flag_code de es à mx via PUT, puis s'est attaqué au cache.
La partie cache était bordélique (comme toujours avec Elementor). Claude Code a essayé plusieurs endpoints avant de trouver celui qui déclenchait vraiment une purge. Puis il a récupéré le HTML du front-end à nouveau et fait un grep sur les classes pour confirmer que le nouveau drapeau était en ligne.
Note honnête : Claude Code ne l'a pas réussi du premier coup. Il a d'abord essayé d'ouvrir Chrome et de se connecter via le formulaire wp-admin. Il avait le mot de passe d'app mais l'a interprété comme des identifiants normaux. J'ai envoyé une correction : "utilise l'API REST, pas le navigateur." Une phrase. Après ça, complètement autonome.
Il a inféré toute la stack à partir du HTML brut. J'aurais passé dix minutes juste à cliquer dans les panneaux de paramètres.
Puis J'ai Demandé Si Quelque Chose Clochait. C'était une Erreur.
Le drapeau était fait. Mais j'avais encore Claude Code connecté au site, et je suis le genre de personne qui ne peut pas laisser un outil tourner sans le titiller. Alors j'ai tapé : "tant que tu y es, quelque chose semble bizarre ? Lecture seule. Ne change rien."
Je m'attendais peut-être à un alt tag manquant. Un plugin obsolète. Quelque chose de poli.
Trois minutes plus tard : huit problèmes. Et pas du genre cosmétique.
Sitemap XML incomplet : les pages mexicaines étaient complètement absentes. Sur un site commercial bilingue, c'est votre SEO pour la moitié de votre contenu qui n'est juste... pas indexé. Aucun plugin SEO installé du tout. Page titrée "About US" où les majuscules la faisaient lire comme "États-Unis" (probablement un vestige de trois redesigns que personne n'avait remarqué). Traductions Polylang pas correctement inter-liées, ce qui signifie que le sélecteur de langue envoyait les utilisateurs vers la page d'accueil de l'autre langue au lieu de la page traduite sur laquelle ils étaient réellement. En-têtes de sécurité absents partout : pas de HSTS, pas de X-Frame-Options, pas de CSP. Le nom d'utilisateur admin était littéralement admin. Un fichier ZIP aléatoire traînant dans la bibliothèque média que personne ne pouvait expliquer. Et une page mexicaine sans équivalent anglais, cassant la structure bilingue.
Voici ce qui rendait ça inconfortable : c'est moi qui suis censé maintenir ce site. Ces problèmes traînaient là tout le temps. Un client qui paie pour la maintenance, et le prestataire (puis moi, par extension) avait raté tout ça. Claude Code l'a trouvé en trois minutes en interrogeant méthodiquement chaque endpoint REST et en comparant ce qui devrait exister avec ce qui existe vraiment.
Un consultant WordPress facture minimum 2 heures pour ce genre d'audit. Certaines agences l'emballent comme un livrable autonome.
Ça a coûté une phrase que j'ai tapée sur un coup de tête.
Pourquoi Ça Marche sur N'importe Quel Site WordPress Que Vous N'avez Jamais Touché
L'API REST WordPress n'est pas une fonctionnalité. C'est tout le site, exposé comme endpoints, nativement, depuis la version 5.6. Et ça change ce que "donner accès à une IA" signifie vraiment.
Pas de plugin à installer. Pas de serveur MCP à lancer. Pas de fichier de config, pas de conteneur Docker, rien du tout. L'API tourne déjà sur chaque site WordPress qui ne l'a pas explicitement désactivée (presque aucun ne le fait). Posts, pages, médias, utilisateurs, plugins, config du site. Et l'écosystème a suivi : Polylang livre /pll/v1/. WooCommerce livre /wc/v3/. Yoast, RankMath, même pattern. Tout documenté, tout interrogeable.
Un mot de passe d'application donne au porteur exactement les mêmes permissions que l'utilisateur WordPress qui l'a généré. C'est toute la configuration. Trente secondes dans wp-admin. Pas de danse OAuth. Pas de tableau de bord d'API key. Pas d'enregistrement de webhook.
Maintenant associez ça avec ce que Claude Code fait déjà bien : lire la documentation, explorer les surfaces d'API, inférer le contexte à partir des réponses. Il lit le HTML du site, repère Polylang à partir d'une classe CSS, interroge le bon endpoint, valide le résultat. C'est le même pattern que le serveur MCP n8n qui donne à Claude Code un accès structuré à l'API complète de n8n, avec une autonomie complète et zéro UI. Sauf qu'avec WordPress vous n'installez rien. C'est là depuis des années, assis bien en vue.
Le pont entre Claude Code et WordPress existe depuis 2021. On vient juste de le remarquer.
J'avais 54 Autres Sites. Voici Ce Qui S'est Passé.
Je gère 54+ sites clients. La session drapeau a pris moins de dix minutes. Alors j'ai continué, et au cours des jours suivants j'ai fait trois vrais tests sur différents sites.
Mises à jour de contenu et création d'articles. Claude Code lit les pages existantes via l'API, capte le ton et la structure de ce qui est déjà publié, génère du contenu correspondant, et le pousse via POST/PUT sur /wp/v2/posts et /wp/v2/pages. Pas de wp-admin, pas de copier-coller dans Gutenberg, pas de reformatage. Un brief d'une ligne entre, une page publiée sort.
Mises à jour d'alt-tags en lot. Claude Code a récupéré tous les médias via /wp/v2/media, identifié chaque image avec un alt text manquant ou vide, et les a mis à jour lot par lot. Un site avait 200+ images. C'est un après-midi à cliquer dans la bibliothèque média, écrire de l'alt text un par un, sauvegarder, scroller, suivant. Une session s'en est occupée.
Durcissement sécurité. Renommer le nom d'utilisateur admin prévisible, vérifier les en-têtes de réponse, auditer les permissions et rôles utilisateurs. Le truc qui vit sur votre liste "je le ferai le mois prochain" pour chaque site client que vous gérez.
Voici le truc qui ne vous frappe que quand vous regardez l'image complète : aucune de ces tâches n'est difficile individuellement. N'importe quel dev peut mettre à jour des alt tags. N'importe quel dev peut renommer un utilisateur admin. Le problème n'a jamais été la difficulté. C'était que le faire sur un site c'est bien, le faire sur 54 sites c'est une raison d'être pour la procrastination. L'API transforme chaque tâche en session répétable. Claude Code transforme la session en lot. La multiplication compte, pas l'unité.
Divulgation honnête : j'ai testé les workflows de contenu et d'alt-tags sur 3-4 sites, pas les 54. Mais le pattern s'est maintenu identiquement à chaque fois, et passer à l'échelle sur tout le portfolio c'est de l'arithmétique à ce stade, pas de la spéculation.
54 sites. Avant : une corvée par site. Maintenant : une session par lot.
La Partie Que Personne Ne Vous Dit Sur Donner un Accès Admin à une IA
Bon. Parlons du truc auquel vous pensez déjà.
Un mot de passe d'app avec des privilèges admin donne un accès en écriture complet via l'API REST. Complet. Ça signifie créer, modifier, et supprimer du contenu. Sur une demande ambiguë comme "nettoie les médias inutilisés," Claude Code pourrait interpréter "nettoie" plus généreusement que vous ne l'aviez prévu.
Sur un test, j'ai demandé à Claude Code de "réviser et organiser la bibliothèque média." Il a signalé des fichiers pour suppression potentielle et a demandé avant de procéder. Il était prudent. Mais prudent est un comportement, pas un contrat. Le modèle décide comment interpréter votre demande, et vous ne contrôlez pas toujours cette interprétation à l'avance.
Règle non-négociable : sauvegarde complète avant toute session. Ou travaillez sur staging. Choisissez.
Deuxième chose : dérive de scope. La session drapeau l'a montré clairement. Claude Code a essayé la connexion navigateur avant que je le corrige. Sans périmètre explicite dans le prompt, il va explorer ce qu'il peut accéder, et cette surface pourrait être plus large que ce que vous attendiez.
C'est exactement là où définir le scope d'exécution avant de lancer Claude Code sur un site client fait la différence entre une session fluide et un incident. "Modifie seulement la config Polylang. Ne touche pas au contenu des pages." Ce genre de limite explicite.
Encore une chose que l'API REST ne couvre pas : les fichiers PHP, le code de thème, le core WordPress. Pour ça vous avez besoin d'un accès SSH. Claude Code le sait et le dit quand il frappe ce mur.
Le mot de passe d'app vous donne les clés du camion. Vous feriez mieux d'avoir dit où vous allez avant de démarrer le moteur.
L'année prochaine quelqu'un va livrer un plugin WordPress à 29€/mois qui fait exactement ça. UI propre. Onboarding en sept étapes. Les gens vont payer.
Pendant ce temps, l'API REST est là depuis 2021. Le mot de passe d'app prend trente secondes. Claude Code comprend le reste. Pas de plugin. Pas de setup. Pas d'abonnement.
(Et pour la rotation des mots de passe d'app sur tous vos sites ? Vous demandez juste à Chrome dans Claude de les générer en lot. Chut.) 🤫
Sources
WordPress REST API Handbook: developer.wordpress.org/rest-api
Si votre workflow implique plus Claude Code que Stack Overflow ces temps-ci, j'écris sur les patterns qui livrent vraiment. Suivez si c'est votre genre de lecture.
(*) La couverture est générée par IA. Les drapeaux sont exacts cependant, ce qui m'a plus surpris que l'article lui-même.
Quand l'IA gère vos tâches WordPress en mode autonome, la productivité prend un tout autre sens. Découvrez comment transformer vos corvées en workflows intelligents.