WordPress Studio : ce que l’agent officiel fait vraiment

Avant d’entrer dans le détail, l’essentiel. WordPress Studio est un logiciel gratuit qui crée des sites WordPress sur votre propre ordinateur, sans hébergement ni connexion. Vous l’installez comme n’importe quelle application, sur Mac, Windows ou Linux, vous ajoutez un site, et huit secondes plus tard vous disposez d’un WordPress complet pour essayer un thème, une extension ou une refonte sans toucher à votre site en ligne.

Il s’adresse à tous ceux qui fabriquent des sites WordPress : le débutant qui veut s’entraîner, le freelance qui prépare un site client, le développeur qui teste une mise à jour. Et contrairement à ce que laisse penser son éditeur, Studio ne vous enferme pas chez WordPress.com : la création de sites locaux ne demande aucun compte. Un compte WordPress.com ne sert qu’aux options en ligne, les sites de démonstration à partager et la synchronisation, réservée aux sites WordPress.com payants et à ceux de Pressable.

Côté prix, l’application et la création de sites sont gratuites. Studio embarque aussi, depuis cette année, un agent IA, Studio Code, qui construit ou modifie votre site à partir d’instructions en langage courant. C’est la seule partie payante : par WordPress.com, il exige un compte et l’enregistrement d’un moyen de paiement, même pour consommer le crédit offert, et l’agent accepte aussi votre propre clé API Anthropic, en ligne de commande comme dans l’application de bureau.

Voilà pour l’usage. La suite s’adresse à ceux qui veulent savoir ce que Studio fait vraiment sous le capot, parce que j’y ai trouvé une différence importante avec votre futur hébergement.

Beaucoup ont retenu que l’agent officiel de WordPress.com est bâti sur Claude Code. C’est écrit noir sur blanc sur le blog de WordPress.com ("we’re leveraging the incredible tech of Claude Code"), et c’était vrai au lancement. Ça ne l’est plus depuis la version 1.9 du 11 mai : dans le code publié, la bibliothèque d’Anthropic qui fait tourner Claude Code, claude-agent-sdk, a cédé la place à pi-coding-agent, un agent de programmation open source.

Le changement qui vous concerne le plus est ailleurs : Studio n’installe plus de serveur sur votre poste. Il n’y a ni Nginx, ni MySQL, ni MariaDB : votre site tourne sur SQLite, une base de données tenue dans un simple fichier, avec un PHP que Studio installe lui-même. C’est ce qui le rend si rapide. C’est aussi ce qui peut vous surprendre à la mise en ligne, puisque votre hébergeur, lui, utilise MySQL ou MariaDB.

Pour avoir dirigé un hébergeur WordPress pendant des années, je sais que ce genre d’écart entre deux bases de données passe inaperçu pendant le développement et se paie le jour de la mise en ligne. J’ai donc installé Studio, créé des sites et lancé les commandes que recommande la documentation officielle. Trois d’entre elles échouent, et la plus gênante ne signale même pas son échec.

Studio tourne sur Playground, pas sur une pile serveur classique

Commençons par le point que le marketing ne met nulle part en avant. Le code source de Studio est public, sous licence GPL. Jusqu’à la version 1.23, sa fiche technique tenait en une ligne, relevée dans le fichier package.json du dépôt :

"description": "Local WordPress development environment using Playgrounds"

Playground, c’est le projet qui a rendu WordPress exécutable sans serveur, en compilant PHP vers un format que même un navigateur sait faire tourner. C’était une curiosité de démonstration il y a trois ans. Studio en a repris la mécanique de création de sites jusqu’à la 1.23. Depuis la 1.24 du 13 octobre, il s’en est détaché et n’en garde que le format des Blueprints.

La conséquence pratique est simple à formuler : là où un environnement local classique installe une pile complète sur votre machine, Studio empile un moteur PHP autonome et un fichier de base de données. Rien de plus. Pas de service qui tourne en fond, pas de port MySQL, pas de configuration de serveur web à ajuster.

Je l’ai vérifié sur le site que j’ai créé, en interrogeant WordPress lui-même plutôt qu’en croyant la documentation :

$ studio wp eval 'echo PHP_VERSION . " | DB " . DB_ENGINE;'
8.4.24 | DB sqlite

PHP 8.4.24, base SQLite (la 2.0.4 embarque PHP 8.4.27). L’intégration passe par l’extension officielle sqlite-database-integration, celle-là même que l’équipe WordPress maintient depuis des années sans jamais l’avoir activée par défaut, plus un fichier db.php déposé dans wp-content qui détourne toutes les requêtes.

Le plus intéressant se lit dans l’écran d’informations système de WordPress, celui que tout le monde ouvre pour diagnostiquer un souci d’hébergement. Allez-y sur un site Studio et vous verrez WordPress annoncer un serveur de base de données MySQL en version 8.0.38.

Il n’y a évidemment aucun MySQL. La ligne juste au-dessus le dit d’ailleurs sans détour, en nommant l’extension qui fait le travail, et le numéro de version du client correspond à une version de SQLite, pas de MySQL. La couche de compatibilité se présente donc à WordPress comme un serveur MySQL, et WordPress la croit.

Regardez maintenant les champs vides : pas d’hôte, pas d’utilisateur, pas de collation, pas de taille de paquet maximale, pas de nombre de connexions. Ce sont précisément les informations sur lesquelles s’appuient les extensions de diagnostic et d’optimisation. Sur un site Studio, elles travaillent à l’aveugle, et rien ne les en avertit.

Il vous faut 8 secondes pour un WordPress 7.1

J’ai chronométré, parce que c’est l’argument que tout le monde répète sans jamais donner de chiffre. Voici ce que donne la création d’un site neuf, sur un poste Windows ordinaire, avec la dernière version de WordPress :

$ studio create --name "Test WPF" --wp latest --php 8.4 --no-start
✔ WordPress files copied
✔ SQLite integration configured
✔ Port assigned: 8881
✔ Site created successfully

=== DUREE : 8 030 ms ===

Huit secondes. Le démarrage du serveur en prend quatorze de plus, la première fois. Ensuite le site répond, et il répond vite : 274 millisecondes pour recevoir le premier octet de la page d’accueil, mesurées en local. J’ai refait la création le 24 septembre sur la 1.22 : 6,8 secondes, les fichiers déjà en cache. Au passage, l’option --wp latest de ma commande s’écrit désormais --wp auto-update, depuis la 1.21, et l’ancienne écriture fonctionne toujours.

Le site occupe 115 Mo sur le disque, tout compris. À titre de comparaison, les quatre sites que j’ai actuellement dans Local pèsent entre 104 et 306 Mo chacun, et l’application y ajoute 4,1 Go de moteurs partagés dans mon dossier utilisateur. Ce n’est pas une critique de Local, plutôt la contrepartie logique d’un vrai serveur : il faut bien stocker les binaires de MySQL, de MariaDB, de Nginx et des versions de PHP quelque part.

Sur la version installée, WordPress annonce 7.1, la dernière version au moment du test. Le site tourne pour de bon, avec le thème par défaut, l’administration accessible et un compte administrateur généré automatiquement. Un site créé le 24 septembre part directement en 7.1.2.

La ligne de commande, typiquement le genre de choses que personne ne regarde

Toutes les captures d’écran que vous avez vues montrent l’application de bureau. Elle est jolie, elle demande un compte WordPress.com, et elle réclame une carte bancaire enregistrée avant de vous laisser toucher à l’agent, même pendant la période d’essai.

Ce que les captures ne montrent pas, c’est qu’il existe une seconde porte, documentée mais discrète. Studio publie son outil en ligne de commande sur le dépôt public de paquets JavaScript, sous le nom wp-studio. Une seule commande l’installe, celle que donne la documentation du CLI :

npm install -g wp-studio

Quarante secondes d’installation chez moi. Aucun compte demandé, aucune carte, aucune connexion. Vous pouvez créer, démarrer, arrêter et supprimer des sites, et lancer des commandes WordPress dessus, sans jamais ouvrir l’application de bureau.

La commande accepte les options qu’on attend d’un tel outil : le nom du site, son chemin, la version de WordPress, la version de PHP (de 8.2 à 8.5, avec 8.4 par défaut), l’accès aux fichiers (le dossier du site par défaut, ou tout le disque), le domaine, l’activation du HTTPS, un fichier de configuration au format Blueprint pour préparer un site avec ses extensions et ses réglages, et, depuis la 1.21, une source statique à reconstruire en site WordPress (--from).

Studio dépose des consignes pour agents à la racine de votre site

Voici la trouvaille que je n’attendais pas. En listant les fichiers du site fraîchement créé, je suis tombé sur trois fichiers qui n’ont rien à faire dans une installation WordPress : CLAUDE.md, AGENTS.md et STUDIO.md. Ils sont posés à la racine, à côté de wp-config.php.

Leur contenu forme une chaîne. Le premier ne contient qu’une ligne, qui renvoie au deuxième. Le deuxième explique qu’il s’agit d’un site géré par Studio et renvoie au troisième. Le troisième est un mode d’emploi complet, écrit pour être lu par un programme et non par un humain. Depuis la 1.22, le deuxième signale aussi un fichier DESIGN.md, que Studio crée quand vous choisissez une direction visuelle pour le site, et que les agents doivent suivre.

On y trouve par exemple cette consigne, en majuscules dans le texte d’origine :

Quand vous suivez une documentation qui mentionne des commandes wp, vous DEVEZ les préfixer par studio.

Et plus loin, une instruction qui vaut prise de position d’Automattic sur la façon de construire un thème aujourd’hui : " quand vous construisez des thèmes, construisez toujours des thèmes de blocs ".

La portée de ces fichiers dépasse largement l’agent maison. CLAUDE.md et AGENTS.md sont les deux conventions que lisent la plupart des assistants de développement du marché. En les déposant, Studio rend le site immédiatement pilotable par l’outil que vous utilisez déjà, quel qu’il soit. Vous pouvez ouvrir le dossier du site dans votre éditeur, lancer votre assistant habituel, et il saura tout seul qu’il faut écrire studio wp plugin install et non wp plugin install.

Autrement dit, la partie la plus utile de l’offre agentique de Studio est gratuite, ne demande aucun compte, et fonctionne avec la concurrence.

27 outils que Studio expose à votre assistant

Studio ne se contente pas d’avoir un agent. Il expose aussi ses propres capacités à l’assistant que vous utilisez déjà, par le protocole qui sert justement à ça. L’écran de réglages le dit sans détour : " connectez votre assistant de développement au serveur de Studio pour qu’il puisse créer, configurer et manipuler vos sites WordPress locaux ".

La configuration à copier tient en quatre lignes, et le serveur porte un nom fixe :

{
  "wordpress-studio": {
    "command": "studio",
    "args": ["mcp"]
  }
}

J’ai interrogé ce serveur directement, en lui demandant la liste de ce qu’il sait faire. Il en annonçait vingt-six sur la 1.19, et vingt-sept quand je l’ai réinterrogé le 24 septembre sur la 1.22 : le nouveau venu, pick_design, fait choisir une direction visuelle et une mise en page avant de construire. L’outil de génération d’images ajouté en 1.20 n’apparaissait pas dans ma liste, faute de connexion à WordPress.com. La 1.23 du 5 octobre a retiré l’ancienne interface de Studio et un outil, studio_present, absent de ma liste : je n’ai pas réinterrogé cette version. Aucune page officielle ne les énumère, alors les voici, regroupés par usage.

La gestion des sites occupe six outils : création, liste, informations détaillées, démarrage, arrêt et suppression. Quatre autres pilotent les sites de démonstration temporaires, ceux qu’on partage par lien à un client le temps d’une validation. Quatre encore gèrent les échanges avec un hébergement distant, dans les deux sens, plus l’import et l’export.

Le reste est plus inattendu, et c’est le plus intéressant.

Un audit de référencement dans l’outil officiel

L’outil s’appelle rank_me_up, et sa description ne laisse aucun doute sur son ambition : il rend le titre et la méta description, les balises canonique et robots, les cartes de partage pour les réseaux sociaux, la structure des titres, le taux de couverture des textes alternatifs sur les images, le décompte des liens internes et externes, les données structurées et la présence du fichier des règles pour les robots et du plan du site.

C’est un audit sur page tout à fait honorable, livré gratuitement dans l’environnement de développement officiel de WordPress. Son voisin need_for_speed fait la même chose pour la performance : temps de réponse, affichage du premier contenu, plus gros élément affiché, stabilité visuelle, poids de la page, nombre de requêtes et répartition par type de fichier.

Les deux portent la même consigne, en majuscules : " À N’APPELER QUE SUR DEMANDE EXPLICITE DE L’UTILISATEUR ". Automattic a manifestement voulu éviter qu’un agent lance un audit complet à chaque fois qu’on lui demande de changer une couleur. La précaution en dit long sur ce que ces outils coûtent en temps et en jetons.

Un migrateur qui vise nommément les plateformes fermées

L’outil data_liberation est un pont vers un moteur d’extraction livré avec Studio. Sa description nomme ses cibles sans aucune diplomatie : GoDaddy, Hostinger, HubSpot, Shopify, Squarespace, Webflow, Weebly et Wix. Le principe est d’extraire le contenu de ces plateformes et de le reconstruire en site WordPress.

Que le premier éditeur de l’écosystème WordPress embarque un aspirateur de sites Wix dans son outil de développement, et le distribue gratuitement, mérite d’être relevé. La récupération de sites bloqués sur ces plateformes est une demande que je vois passer régulièrement, et elle se réglait jusqu’ici à la main ou avec des services payants.

La validation des blocs annoncée le 24 août

C’était l’argument technique mis en avant le 24 août, et il correspond bien à quelque chose de réel. L’outil validate_blocks travaille en deux temps. Il vérifie d’abord que le contenu ne contient pas de bloc HTML brut là où un vrai bloc ferait l’affaire, et refuse d’aller plus loin tant que c’est le cas. Ensuite seulement, il valide le contenu dans l’éditeur réel du site, applique les corrections sûres au fichier et renvoie le détail de ce qu’il a changé.

Trois outils l’accompagnent pour le travail visuel : une capture d’écran, une inspection du rendu qui renvoie les dimensions réelles et les styles calculés d’un élément, et un mode d’annotation qui ouvre le navigateur pour qu’on désigne à la souris l’élément à modifier. La description de l’inspection résume bien la logique : " la capture montre le symptôme, l’inspection montre la cause ".

Reste enfin scaffold_theme, qui pose un thème de blocs minimal mais complet, avec son fichier de configuration, ses gabarits, ses parties d’en-tête et de pied de page. Deux règles y sont gravées : les thèmes classiques ne sont pas pris en charge, et un thème tiers doit être personnalisé par un thème enfant, " ses fichiers ne devant jamais être modifiés directement ". Sur ce dernier point, la position d’Automattic rejoint mot pour mot ce que je répète en formation depuis toujours.

Des noms de modèles aux paliers anonymes

Le choix du modèle qui anime l’agent n’est pas caché, il est écrit dans le code source, dans un fichier qui liste tout ce que l’application sait servir. Ce fichier a changé de nature en moins d’un mois, et le changement en dit long.

Dans le fichier des modèles de la version 1.19.0, celle de mon test, trois modèles étaient proposés à tout le monde : Sonnet 5, choix par défaut, Opus 5 et GPT 5.6 Sol. Six autres figuraient dans la même liste avec une mention qui les réservait aux salariés d’Automattic : deux modèles Kimi, deux modèles GLM et deux modèles DeepSeek. Le commentaire du développeur précisait que le masquage était cosmétique et que c’était le relais de WordPress.com qui refusait réellement ces destinations aux autres.

Depuis la version 1.22 du 21 septembre, il n’y a plus de noms du tout. Le fournisseur WordPress.com propose trois paliers, Fast, Balanced et Strong, et le code précise qu’il s’agit de niveaux de capacité et non de modèles : le relais de WordPress.com associe chaque palier à un modèle, côté serveur, et peut en changer sans nouvelle version de l’application. Fast est le palier par défaut ; Balanced et Strong demandent des crédits achetés. GPT 5.6 Sol et les six modèles réservés ont disparu du sélecteur. Sonnet 5 et Opus 5 restent accessibles, mais seulement avec votre propre clé API Anthropic.

Deux remarques là-dessus. La première : vous ne savez plus quel modèle travaille sur votre site. Le palier dit ce qu’il vaut, pas qui il est, et la correspondance peut changer du jour au lendemain. La seconde : dans la liste nominative de la 1.19, aucun modèle européen ne figurait, ni chez les modèles publics, ni chez ceux réservés. Avec les paliers, la question n’a même plus de réponse vérifiable. Pour un outil poussé par une entreprise qui insiste régulièrement sur l’ouverture, c’est un angle mort qui mérite d’être noté.

4 mois pour passer d’un outil de développement à un agent

La bascule du 24 août n’est pas sortie de nulle part. En reprenant les annonces officielles et les notes de version, la trajectoire est nette et rapide.

Le 27 avril, Automattic présente une première version d’essai d’un outil de développement assisté, et annonce s’appuyer sur la technologie de Claude Code. Le 11 mai, la version 1.9 remplace ce moteur par pi-coding-agent, un agent open source. Le 15 juin, la chose arrive dans l’application de bureau. Le 24 août, à l’occasion du WordCamp US, l’application entière est reconstruite autour de l’agent, en version d’essai publique sur les trois systèmes.

Les notes de version racontent la même accélération. La 1.17 réorganise les réglages en onglets, dont un pour le protocole de connexion des assistants et un pour les compétences, et ajoute des instructions générales qu’on donne une fois pour toutes à l’agent. La 1.18 fait de l’interface agentique l’expérience par défaut pour les nouveaux venus et remplace le modèle par une version plus récente. La 1.19, celle que j’ai installée, introduit les crédits payants et affiche le solde restant pendant la saisie. La 1.20, sortie le 28 août, quatre jours après mon test, ajoute la génération d’images par l’agent, avec un outil generate_images de plus dans son registre, et un compteur de consommation. La 1.21, le 7 septembre, affiche le solde de crédits partout et sait construire un site à partir de sources statiques. La 1.22, le 21 septembre, remplace les noms de modèles par des paliers et fait choisir une direction visuelle avant de construire. Les commandes de base de données, elles, n’ont pas bougé : je les ai relancées sur la 1.22 le 24 septembre, avec exactement le même résultat.

Un détail de la 1.18 mérite le détour, parce qu’il révèle un choix de conception : désormais, un site dont le code produit une erreur fatale démarre quand même et affiche l’erreur, au lieu de refuser de se lancer. C’est exactement ce qu’il faut quand un agent écrit du code : il doit pouvoir lire son propre échec pour le corriger.

Attention : les commandes de base de données plantent

Passons à la partie qui m’a fait écrire cet article. Le fichier de consignes que Studio dépose lui-même dans votre site donne une liste de commandes courantes, présentées comme les gestes du quotidien. Parmi elles, celle-ci :

studio wp db query "SELECT option_name, option_value FROM wp_options WHERE option_name = 'siteurl';"

Je l’ai lancée. Voici la réponse :

Error: Failed to get current SQL modes. Reason: 'mysql' n'est pas reconnu
en tant que commande interne ou externe.

La raison est mécanique. L’outil en ligne de commande de WordPress délègue cette commande au programme mysql, qu’il s’attend à trouver sur la machine. Or il n’y a pas de MySQL ici, et il n’y en aura jamais : la base est un fichier SQLite. La commande recommandée par la documentation officielle de l’outil échoue donc sur l’outil lui-même.

J’ai poussé le test sur les commandes voisines. La sauvegarde de la base, que ce même fichier de consignes cite en exemple, subit exactement le même sort, pour la même raison :

$ studio wp db export
'mysqldump' n'est pas reconnu en tant que commande interne ou externe.

Celle-ci paraît plus ennuyeuse qu’elle ne l’est, et j’ai bien failli le croire. C’est la commande standard pour extraire une base et l’emporter ailleurs. Sauf que Studio a la sienne, et qu’elle fait le travail.

$ studio export sauvegarde.tar.gz
✓ Backup file created
✓ Site exported successfully

4 316 ms  ·  14 Mo  ·  640 fichiers

J’ai ouvert l’archive pour voir ce qu’elle contenait vraiment, parce que c’est là que se joue la suite. Elle porte les fichiers du site et un fichier SQL. Et ce fichier SQL est écrit en dialecte MySQL, avec les accents graves autour des noms de tables, les moteurs InnoDB et l’encodage utf8mb4 :

CREATE TABLE `wp_comments` (
  `comment_ID` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  ...
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;

Autrement dit, Studio traduit sa base SQLite en SQL importable sur un hébergement classique. La migration vers votre serveur n’est donc pas bloquée, contrairement à ce que l’échec de la commande précédente laisse craindre. Il faut simplement savoir que le geste ne s’écrit pas comme d’habitude.

Et puis il y a la troisième, celle qui m’inquiète vraiment :

$ studio wp db size
Name         Size
wordpress    0 B

Zéro octet. Pas d’erreur, pas d’avertissement, pas de code de sortie en échec. Une réponse propre, bien formatée, et fausse. Le site contient WordPress 7.1 au complet, ses tables, ses options et ses articles par défaut : sa base ne pèse évidemment pas zéro. Sur le site que j’ai recréé le 24 septembre, le fichier SQLite fait 436 Ko, et la commande affiche toujours zéro.

Les deux premières commandes échouent bruyamment, ce qui est le comportement souhaitable : vous savez que vous ne pouvez pas vous en servir. La troisième ment sans rien dire. Si vous surveillez la taille d’une base pour décider d’une purge ou d’une optimisation, vous prenez votre décision sur un chiffre inventé. Et si c’est un agent qui lance la commande à votre place et lit la réponse, il n’a aucun moyen de savoir qu’elle est fausse.

Le contournement tient en une ligne

Tout n’est pas perdu, loin de là. Le reste de l’outil en ligne de commande fonctionne parfaitement, parce qu’il passe par PHP et non par un programme externe. L’installation d’extensions, l’activation de thèmes, la lecture d’options, l’exécution de code : tout répond. J’ai installé et activé une extension en cinq secondes sans le moindre accroc.

Pour interroger la base malgré tout, il suffit de passer par l’objet que WordPress expose depuis toujours :

$ studio wp eval 'global $wpdb;
  echo $wpdb->get_var("SELECT option_value FROM {$wpdb->prefix}options
  WHERE option_name = \"siteurl\"");'

http://localhost:8881

Ça marche. Et vous n’avez pas à écrire pour SQLite : votre requête reste du SQL de MySQL, que la couche de compatibilité traduit au passage. Cette traduction a ses limites.

SQLite en local, MySQL chez votre hébergeur

Une commande qui plante, on la contourne. Le problème de fond est ailleurs, et c’est là que mes années d’hébergement me rendent méfiant.

Votre site local tourne sur SQLite. Votre hébergement, lui, tourne sur MySQL ou MariaDB, dans quasiment tous les cas. Ce sont deux bases différentes, avec deux dialectes différents. Tant que vous restez dans les clous de WordPress et de ses fonctions, la différence est invisible, et c’est précisément tout l’intérêt de la couche de compatibilité.

Mais dès que du code écrit une requête à la main, la garantie s’arrête. Une extension de statistiques qui groupe par mois avec une fonction de date propre à MySQL. Une recherche qui s’appuie sur l’indexation en texte intégral. Une requête qui utilise une expression régulière. Tout cela peut très bien passer chez vous et tomber en production, ou l’inverse. Vous aurez développé, testé et validé sur une base qui n’est pas celle de votre serveur.

Ce n’est pas une raison pour fuir Studio, mais il est important de savoir à quoi il sert. Pour maquetter un thème, essayer une extension, préparer une démonstration ou faire découvrir WordPress à quelqu’un, la vitesse de Studio est un argument sérieux et le risque est nul. Pour développer une extension qui touche à la base, ou pour reproduire un incident de production, il vous faut un environnement qui ressemble à votre serveur.

Le mémo des commandes qui répondent

Pour vous éviter mes tâtonnements, voici ce que j’ai vérifié comme fonctionnel sur la version en ligne de commande, sans compte ni abonnement.

• studio create monte un site neuf. Les options utiles sont le nom, le chemin, la version de WordPress, celle de PHP, et l’option qui évite l’ouverture automatique du navigateur.
• studio start et studio stop démarrent et arrêtent. L’arrêt accepte une option pour tout arrêter d’un coup.
• studio status affiche l’adresse du site, le lien de connexion automatique, les identifiants, les versions de PHP et de WordPress. Préférez-le aux commandes WordPress pour ces informations-là.
• studio config get et studio config set lisent et modifient les réglages d’un site, dont la version de PHP.
• studio wp exécute une commande WordPress. Tout ce qui passe par PHP fonctionne, y compris l’exécution de code arbitraire.
• studio mcp lance le serveur qui expose les vingt-sept outils à votre assistant.

Et ce qui ne répond pas, pour mémoire : l’interrogation directe de la base, son export, et sa taille qui renvoie une valeur fausse au lieu d’une erreur.

Les points forts et faibles de Studio et de Local

J’utilise Local depuis des années, et il tourne toujours sur mon poste avec quatre sites dedans. Voici ce que donne la comparaison sur les points qui se mesurent, plutôt que sur les impressions.

Sur la vitesse de création et la légèreté, Studio gagne largement. Huit secondes contre plusieurs minutes, 115 Mo contre un site plus les quatre gigaoctets de moteurs partagés. Sur la fidélité à la production, Local gagne tout aussi largement, et ce n’est pas discutable : il vous donne Nginx, MySQL ou MariaDB, le choix de la version de la base, et une boîte mail de test.

Sur le pilotage par un agent, Studio a une longueur d’avance, livrée d’origine : ses fichiers de consignes et son outil en ligne de commande font qu’un assistant s’y branche sans réglage. Local n’a rien d’intégré. Il faut passer par un module complémentaire, Agent Tools de 10up, qui ajoute un serveur MCP et des fichiers de contexte pour les assistants, et sait créer des sites depuis sa version du 21 septembre. D’un côté, un outil conçu pour les agents ; de l’autre, un outil qu’on y adapte.

La bonne réponse n’est pas de faire un choix, c’est de garder les deux et savoir lequel on va ouvrir selon ce qu’on s’apprête à faire.

Les limites de mon test

Je n’ai pas essayé l’agent lui-même. Pas par manque d’envie : parce que l’accès par WordPress.com exige un compte et l’enregistrement d’un moyen de paiement, y compris pour consommer le crédit offert. L’agent accepte aussi votre propre clé API Anthropic, facturée par Anthropic, en ligne de commande comme dans l’application de bureau depuis la 1.18 : je n’ai pas essayé cette voie non plus. Tout ce que j’écris plus haut sur l’agent vient du code source publié, des notes de version officielles et des fichiers que l’application dépose sur le disque. Ce sont des sources de première main, mais ce ne sont pas des essais.

Je préfère l’écrire noir sur blanc plutôt que de laisser croire que j’ai passé la journée à faire construire des thèmes par une intelligence artificielle. Ce sera l’objet d’un second article, quand j’aurai réellement consommé les crédits sur un chantier qui en vaut la peine.

Ce que j’ai testé, en revanche, je l’ai testé pour de bon : l’installation, la création de sites, le démarrage, la version de PHP et de la base, l’installation d’extensions, et les commandes de base de données qui échouent. Tous les chiffres de cet article sortent de mon poste, et j’ai refait les mesures clés le 24 septembre sur la 1.22, la dernière version à cette date. Le 22 octobre, la création d’un site et les commandes de base de données ont été rejouées sur la 2.0.4 : mêmes échecs. Le reste n’a pas été rejoué sur les versions 1.23 à 2.0.

Faut-il l’installer ?

Si vous n’avez aucun environnement local, oui, et sans hésiter. C’est aujourd’hui le chemin le plus court entre rien du tout et un WordPress qui tourne, et vous n’avez même pas besoin de l’application de bureau pour en profiter.

Si vous développez des extensions qui écrivent leurs propres requêtes, gardez votre outil actuel comme environnement de référence et servez-vous de Studio pour ce qu’il fait le mieux : monter un site jetable en huit secondes pour vérifier une idée.

Et si vous voulez seulement voir de quoi il retourne sans donner votre carte bancaire à qui que ce soit, installez la version en ligne de commande, créez un site, ouvrez le dossier dans votre éditeur et regardez ce que contient le fichier STUDIO.md. C’est la partie la plus instructive de tout l’ensemble, et elle tient en deux pages.

Moi, j’ai gardé le site de test. Il pèse 115 Mo, il démarre en quatorze secondes, et il me servira la prochaine fois que quelqu’un me demandera de lui montrer un réglage WordPress en direct pendant une heure de conseil WordPress.

Questions fréquentes

WordPress Studio est-il gratuit ?

L’application, la version en ligne de commande et la création de sites sont gratuites et ne demandent aucun compte. C’est l’agent qui ne l’est pas tout à fait : par WordPress.com, son accès exige un compte et l’enregistrement d’un moyen de paiement, y compris pour consommer le crédit offert, et depuis la 1.22 les paliers Balanced et Strong demandent des crédits achetés. Vous pouvez aussi brancher votre propre clé API Anthropic, en ligne de commande comme dans l’application. Vous pouvez donc utiliser Studio comme environnement local sans jamais donner de carte bancaire.

Studio remplace-t-il Local by Flywheel ?

Non, et il vaut mieux garder les deux. Studio gagne largement sur la vitesse et la légèreté : huit secondes contre plusieurs minutes, 115 Mo contre un site plus quatre gigaoctets de moteurs partagés. Local gagne tout aussi largement sur la fidélité à la production, puisqu’il vous donne Nginx, MySQL ou MariaDB, le choix de la version de base et une boîte mail de test. Ouvrez l’un ou l’autre selon ce que vous vous apprêtez à faire.

Pourquoi la commande studio wp db query échoue-t-elle ?

Parce qu’elle délègue le travail au programme mysql, que l’outil s’attend à trouver sur votre machine. Or il n’y a pas de MySQL dans Studio, et il n’y en aura pas : la base est un fichier SQLite. La commande figure pourtant dans le fichier de consignes que Studio dépose lui-même. studio wp db export échoue pour la même raison.

Comment interroger la base malgré tout ?

Par l’objet que WordPress expose depuis toujours, avec studio wp eval et $wpdb. Tout le reste de l’outil en ligne de commande fonctionne parfaitement, parce qu’il passe par PHP et non par un programme externe : installation d’extensions, activation de thèmes, lecture d’options, exécution de code. Votre requête reste écrite pour MySQL : la couche de compatibilité la traduit pour SQLite, avec des limites. Avant la mise en ligne, essayez-la sur la base de votre hébergement.

Développer sur SQLite est-il risqué ?

Tant que votre code reste dans les fonctions de WordPress, la différence est invisible, et c’est tout l’intérêt de la couche de compatibilité. Le risque commence dès qu’une extension écrit ses propres requêtes : une fonction de date propre à MySQL, une recherche en texte intégral ou une expression régulière peuvent très bien passer chez vous et tomber en production, ou l’inverse. Vous auriez alors validé sur une base qui n’est pas celle de votre serveur.

À quoi servent les fichiers CLAUDE.md, AGENTS.md et STUDIO.md ?

Ce sont des consignes destinées aux agents, déposées par Studio à la racine de votre site, à côté de wp-config.php. Elles forment une chaîne : les deux premiers renvoient au troisième, qui est un mode d’emploi complet écrit pour être lu par un programme. Leur portée dépasse l’agent maison, puisque CLAUDE.md et AGENTS.md sont les conventions que lisent la plupart des assistants de développement.

Peut-on brancher son propre assistant sur Studio ?

Oui, et c’est le point le plus intéressant de cette sortie. Studio expose ses capacités par le protocole prévu pour cela, avec un serveur déclaré sous un nom fixe. Il annonçait vingt-six outils sur la version 1.19.0, et vingt-sept sur la 1.22, le 24 septembre, dont six pour la gestion des sites et quatre pour les aperçus. Aucune page officielle ne les énumère : la liste de cet article vient d’une interrogation directe du serveur.

Quels modèles animent l’agent officiel ?

Depuis la version 1.22 du 21 septembre, le fournisseur WordPress.com ne nomme plus aucun modèle : il propose trois paliers, Fast par défaut, puis Balanced et Strong réservés aux crédits achetés, et choisit côté serveur le modèle qui se cache derrière chacun. Sonnet 5 et Opus 5 restent disponibles avec votre propre clé API Anthropic. Sur la 1.19, celle de mon test, le code déclarait neuf modèles, dont trois proposés à tout le monde (Sonnet 5, Opus 5 et GPT 5.6 Sol) et six réservés aux salariés d’Automattic, sans aucun modèle européen.