De mon agent WordPress à Web Orchestrator : quatre mois qui ont changé ma façon de travailler

Le 17 mai 2026, je publiais « Créer un super agent WordPress avec Codex, VS Code, WP-CLI, SSH et les skills officiels de WordPress.org ». À ce moment-là, le projet était assez facile à définir. J’avais construit un agent pour m’aider à intervenir sur mes sites, créer ou modifier des contenus, travailler avec Gutenberg, manipuler des fichiers et appliquer des procédures de plus en plus structurées.

Aujourd’hui, WordPress reste une part importante de mon activité, mais il ne suffit plus à décrire le périmètre de cet agent. Ce qui était un spécialiste est devenu une couche d’orchestration entre plusieurs compétences, plusieurs outils et plusieurs environnements.

Au départ, je voulais arrêter de tout réexpliquer

L’idée initiale était pragmatique. Pour intervenir correctement sur un site WordPress, une intelligence artificielle doit connaître le site concerné, son environnement, son thème, ses extensions, la construction de ses pages, ses règles de sécurité et les contrôles à effectuer avant comme après une modification. Répéter ces informations à chaque conversation prenait du temps et laissait trop de place aux oublis.

J’ai donc progressivement organisé cette connaissance dans des instructions, des procédures, des skills, des règles de routage et des contrôles. L’agent disposait d’un cadre pour retrouver la manière de travailler attendue sur chaque projet, au lieu de repartir d’une demande isolée.

À cette époque, tout tournait autour de WordPress. Le développement, les contenus, les diagnostics et la maintenance constituaient les différentes facettes d’une même spécialité. C’est l’élargissement progressif de mes besoins qui a fait évoluer cette organisation.

Codex est devenu mon interface de travail principale

Pendant des années, une grande partie de mon travail passait par des manipulations directes dans WordPress, Elementor ou Gutenberg. Je modifiais une section, déplaçais un élément, corrigeais une marge, remplaçais une image, ajoutais du CSS, puis je testais avant de revenir dans l’administration.

Aujourd’hui, j’ouvre beaucoup plus rarement ces interfaces. Je commence généralement dans Codex : j’explique le résultat souhaité, précise les contraintes, contrôle la proposition et demande l’exécution avec les outils adaptés. Je manipule moins directement le logiciel et je supervise davantage les opérations effectuées dessus.

Cette évolution a aussi changé mon rapport aux outils de construction. Certains de mes sites utilisent Gutenberg, d’autres Elementor, d’autres encore des thèmes PHP plus personnalisés. Je peux choisir l’approche qui correspond au projet, sans chercher à faire entrer tous mes besoins dans le même outil.

Un site existant sous Elementor peut continuer à être maintenu avec Elementor. Un projet adapté à Gutenberg peut exploiter les blocs natifs. Lorsqu’un design demande un contrôle plus précis, une architecture PHP personnalisée reste possible, avec l’aide de l’agent pour l’écriture et la vérification du code.

Cela me permet de consacrer davantage d’attention au design system, à l’expérience utilisateur et au résultat final. La technologie reste un choix de conception et de maintenance, mais elle occupe moins de place dans les gestes quotidiens de production.

Spécialiser les compétences pour élargir le périmètre

À mesure que j’ajoutais des fonctions, une difficulté est apparue : un agent censé tout connaître devient vite difficile à maintenir. J’ai donc commencé à séparer les compétences et à définir comment l’orchestrateur devait les mobiliser.

L’expertise WordPress historique reste présente : Gutenberg, Elementor, thèmes PHP, plugins, WP-CLI, maintenance, diagnostics, WooCommerce et édition de contenu. Elle forme désormais un domaine spécialisé au sein d’un ensemble plus large.

Le SEO peut intervenir dès la préparation d’un contenu, à travers les audits, la structure éditoriale, les métadonnées et le maillage interne. Lorsque la mission le demande et que les accès sont disponibles, des données issues d’outils SEO ou de Search Console peuvent compléter ce travail. Je peux ainsi intégrer le référencement au processus de production, plutôt que d’y revenir seulement une fois la page terminée.

Le design dispose également de ses références et de ses procédures. Il s’agit de conserver une identité, des composants et des règles cohérentes entre plusieurs productions. Mon travail sur le design system WordPress piloté par agent participe à cette démarche. Pour les productions animées ou vidéo, HyperFrames fait partie des outils prévus dans le parcours spécialisé.

La rédaction peut, de son côté, porter sur un article, une page, une réécriture, un script ou un document. Le contenu n’a pas besoin d’être lié à WordPress dès le départ : l’intégration dans le CMS devient une étape lorsque le livrable l’exige.

Relier le contenu, les réseaux sociaux et les fonctions métier

Les réseaux sociaux font partie des compétences ajoutées plus récemment. Une fois un article terminé, l’orchestrateur peut en transmettre le contenu au spécialiste chargé de préparer une déclinaison multiréseaux : textes adaptés, carrousels, légendes, hashtags et éléments graphiques, puis préparation de la publication programmée.

La publication automatisée s’inscrit dans un processus où les états restent distincts. Un contenu prêt à relire n’est pas encore validé, et un contenu validé ne peut être programmé ou publié que dans le cadre autorisé. Terminer un fichier ne déclenche donc pas, à lui seul, sa diffusion.

Une autre piste concerne les connecteurs MCP et les interfaces destinées aux clients. Une fois un site créé, certaines opérations simples pourraient être accessibles depuis leur propre intelligence artificielle : modifier un tarif, consulter une disponibilité, mettre à jour une information ou effectuer une opération métier définie.

L’intérêt est de proposer un accès limité aux fonctions utiles, sans imposer l’apprentissage de toute l’administration WordPress. Le travail consiste alors à préciser les opérations permises, les données accessibles et les contrôles nécessaires. Chaque fonction doit rester attachée au client et au périmètre auxquels elle est destinée.

Le rôle de Web Orchestrator : organiser et contrôler

L’objectif est de disposer d’un point d’entrée capable de comprendre une mission et de sélectionner les compétences nécessaires. Je lui donne un objectif ; il analyse le besoin, répartit les étapes, récupère les résultats et les contrôle avant de poursuivre.

Une chaîne éditoriale peut ainsi suivre ce parcours : SEO → WordPress → contrôle de l’article → réseaux sociaux → contrôle → programmation → vérification finale. Selon la demande, certaines étapes sont inutiles ou doivent attendre un accès, une validation ou un résultat intermédiaire.

Le registre de mon environnement réunit désormais plusieurs domaines et capacités. Leur présence dans ce registre ne garantit pas que chaque outil soit disponible, connecté ou autorisé pour chaque mission. L’orchestrateur doit vérifier ce qu’il peut réellement mobiliser dans le contexte concerné.

Ce qui m’intéresse, c’est la possibilité de composer un parcours cohérent. Les compétences ne sont plus seulement dispersées dans des dossiers : elles ont un point d’entrée, un périmètre et un rôle dans la production du résultat.

Les skills conservent mes méthodes de travail

Un modèle généraliste peut connaître beaucoup de choses sans appliquer spontanément la bonne procédure à un projet précis. Les skills me permettent de formaliser une partie de cette expertise : méthodes WordPress et Gutenberg, règles SEO, procédures de design et parcours de production spécialisés.

L’agent peut retrouver ces méthodes au moment où elles deviennent utiles. Une partie de mon savoir-faire opérationnel reste ainsi dans mes fichiers, indépendamment du modèle utilisé pour exécuter la mission. Cela facilite la maintenance des procédures et leur réutilisation.

Cette aventure avance aussi au rythme de mes essais avec les modèles. J’ai régulièrement fait auditer l’environnement, y compris les décisions prises lors des étapes précédentes. Ces révisions ont fait ressortir des incohérences, des doublons, des procédures à simplifier et des contrôles à renforcer.

Plus récemment, mon travail avec GPT-6 Astra m’a aidé à reprendre l’organisation autour de l’orchestration et de la vérification. Je le considère comme une nouvelle étape dans mes propres essais : un environnement construit avec l’aide d’un modèle peut être relu et amélioré avec le suivant. Les changements proposés restent à examiner et à tester.

Une capacité technique ne donne pas une autorisation

Plus les outils accessibles à l’agent se multiplient, plus les conséquences d’une erreur deviennent concrètes. Une mauvaise réponse dans une conversation peut rester une erreur de texte ; une mauvaise action sur un site, un serveur, des fichiers ou un service externe peut modifier un environnement réel.

J’avais publié dès le 20 mai un article sur les prompt injections et les limites de confiance d’un agent. Cette question prend encore plus de place dans un système qui consulte des pages Web, des documents, des README ou des contenus importés. Ces sources peuvent contenir des instructions que l’agent ne doit pas traiter comme des ordres.

Mon cadre de travail distingue donc les instructions de confiance des données consultées. Il prévoit des permissions limitées, des périmètres explicites et des contrôles adaptés aux opérations sensibles. Les confirmations nécessaires doivent porter sur une action concrète, lorsque l’autorisation manque réellement.

Pouvoir publier, modifier ou supprimer quelque chose ne signifie pas avoir le droit de le faire dans toutes les situations. Cette distinction fait partie de l’architecture de l’orchestrateur, au même titre que ses outils. Elle s’applique aussi aux passages entre spécialistes : déléguer une étape ne doit pas élargir les droits accordés à la mission.

Fournir le contexte utile au bon moment

La gestion du contexte est un autre sujet très concret. Mon environnement contient de plus en plus de fichiers, de scripts, de skills et de projets. Tout relire à chaque mission consommerait du contexte sans nécessairement aider à prendre une meilleure décision.

Dans les dépôts indexés, des outils comme CodeGraph participent à ma manière de repérer la structure du code, ses dépendances et les éléments concernés par une modification. Je cherche d’abord à identifier ce qui est pertinent, puis à faire lire les sources utiles.

Cette approche ne concerne pas seulement les tokens. Elle vise à donner à l’agent les éléments nécessaires à son raisonnement, sans mélanger les projets ni charger des procédures étrangères à la demande. La sélection du contexte fait désormais partie du travail d’orchestration.

Je manipule moins les interfaces, je supervise davantage

Dire que je travaille moins directement dans Elementor ou Gutenberg pourrait laisser penser que mon rôle a diminué. En pratique, il s’est déplacé. Je passe davantage de temps à décrire les objectifs, définir les règles, comparer les propositions, tester les résultats et demander des corrections.

Je reste responsable des choix de conception, de ce qui doit être publié et des effets réels des opérations. Confier l’exécution technique à l’agent rend ces décisions plus visibles : il faut exprimer clairement ce qui compte et reconnaître ce qui constitue un résultat satisfaisant.

C’est pour cette raison que je parle d’orchestration. Je construis une manière de coordonner l’exécution tout en gardant la direction du travail et le contrôle aux moments utiles.

Quatre mois pour changer mon rapport aux outils

Le 17 mai, je présentais mon « super agent WordPress ». Le 20 mai, j’explorais déjà ses limites face aux prompt injections. Sont ensuite venus le design system, de nouveaux skills, les audits, les outils SEO, la vidéo, les connecteurs, les fonctions MCP destinées aux clients et l’orchestration entre spécialistes.

En environ quatre mois, cette progression a transformé mon interface de travail, ma manière de concevoir et développer un site, ma production éditoriale, mon approche du SEO et les services que je peux envisager pour mes clients.

WordPress reste au cœur de nombreux projets, avec Elementor ou Gutenberg selon les besoins. Les outils SEO apportent des données et des contrôles, les outils de création servent les productions visuelles et les réseaux sociaux assurent la diffusion programmée des contenus validés. Codex devient le point depuis lequel je coordonne cet ensemble.

La question qui m’occupe aujourd’hui est donc celle de l’organisation : comment partir d’un objectif, mobiliser les compétences pertinentes, exécuter les actions autorisées et me rendre le contrôle au bon moment ? C’est ce que j’essaie de construire avec Web Orchestrator. Et quand je relis l’article consacré à mon premier agent WordPress, vieux de quelques mois seulement, je mesure déjà le chemin parcouru.