Comment j’ai créé un Design System WordPress piloté par un agent IA connecté en SSH

Une expérimentation qui dépasse la génération de HTML

Depuis plusieurs jours, je mène une expérimentation qui change profondément ma façon de travailler sur WordPress, Gutenberg et le webdesign assisté par intelligence artificielle. L’objectif n’était pas simplement de demander à une IA de produire du HTML, mais de construire un véritable workflow de production.

• Piloter la production avec un agent spécialisé.
• Structurer un Design System Gutenberg réutilisable.
• Normaliser automatiquement des pages HTML complexes.
• Travailler et tester d’abord en local.
• Déployer ensuite les corrections validées vers le serveur avec SSH et WP-CLI.

L’idée de départ : résoudre un problème de structure

Le principal problème rencontré avec Gutenberg n’est pas toujours le design. Il apparaît surtout lorsque des maquettes ou du HTML sont convertis en une accumulation de groupes et de blocs difficiles à comprendre.

• Les groupes deviennent rapidement illisibles.
• Les blocs sont mal nommés et les structures deviennent incohérentes.
• Les pages sont difficiles à maintenir et à faire évoluer.
• Les blocs HTML personnalisés peuvent casser plus facilement.
• Chaque future modification demande davantage de temps et de prudence.

L’idée était donc de créer un système capable de normaliser les pages, d’imposer une hiérarchie cohérente, de produire des composants réutilisables et de préserver un design homogène sans rendre Gutenberg rigide.

Un bon Design System ne sert pas seulement à rendre les pages plus belles. Il doit aussi les rendre plus lisibles dans l’éditeur et plus simples à maintenir.

L’architecture mise en place

Le système repose sur cinq éléments complémentaires. Chacun conserve un rôle précis dans le workflow.

1. Visual Studio Code comme espace de pilotage

Toute la logique est pilotée depuis Visual Studio Code avec Codex, plusieurs agents spécialisés et des skills WordPress personnalisés. L’éditeur devient un espace central pour lire les fichiers, préparer les changements et suivre leur validation.

2. Un agent WordPress spécialisé

J’ai créé un agent dédié nommé Etchenet-WordPress-Agent. Il est conçu pour comprendre Gutenberg, modifier des templates et des blocs, intervenir sur des thèmes ou des extensions, manipuler des structures complexes et appliquer un Design System.

• Il est connecté à mon environnement local.
• Il peut également accéder au serveur dans le cadre défini par la connexion SSH.

3. Des skills chargés selon le contexte

Le vrai changement vient des skills. Ils ajoutent des capacités spécialisées concernant WordPress, Gutenberg, Polyglots, l’UI/UX, la normalisation, la validation ou la traduction.

4. Le travail et les validations en local

Toute l’expérimentation commence en local. L’agent peut modifier les pages, corriger les blocs, restructurer Gutenberg, normaliser les sections, tester les composants, vérifier les conflits et nettoyer les structures.

De mon côté, je peux tester immédiatement, comparer le résultat, revenir en arrière, valider ou demander une correction progressive. Cette étape apporte un réel confort avant toute intervention en production.

5. La connexion SSH et WP-CLI

Une fois les tests validés, l’agent peut appliquer des mises à jour ciblées sur le serveur réel avec SSH, WP-CLI, des commandes distantes et, lorsque c’est nécessaire, une synchronisation contrôlée de fichiers.

Le Design System Gutenberg obtenu

La normalisation Gutenberg est l’un des aspects les plus intéressants de cette expérimentation. Elle s’appuie sur des conventions que l’agent peut reconnaître et réutiliser.

• Une nomenclature claire pour les groupes et les sections.
• Une hiérarchie cohérente et des conteneurs standardisés.
• Des composants, cartes et boutons réutilisables.
• Des sections transparentes et des badges homogènes.
• Des conventions responsive communes à l’ensemble des composants.

Le but est de transformer Gutenberg en un véritable système de design maintenable, sans supprimer la possibilité de modifier chaque contenu depuis l’éditeur.

Pourquoi cette méthode est importante

Avant la normalisation

• Chaque page devenait un cas particulier.
• Les structures se dégradaient au fil des modifications.
• Les blocs devenaient difficiles à lire et à maintenir.
• Les évolutions futures coûtaient davantage de temps.

Avec un système partagé

• Les pages suivent une structure normalisée.
• Les composants restent réutilisables et identifiables.
• L’agent applique les conventions de manière régulière.
• Les corrections peuvent être déployées progressivement.

Il devient alors possible d’industrialiser une partie du travail sans perdre la souplesse de Gutenberg.

Les outils utilisés

• Visual Studio Code pour travailler sur les projets et leurs fichiers.
• Codex pour les interactions avec les agents et les tâches techniques.
• WordPress et Gutenberg pour la gestion des contenus.
• WP-CLI pour les opérations WordPress en ligne de commande.
• Le Handbook WordPress Polyglots pour les règles de traduction et de localisation.

Ce que je retiens de cette expérimentation

L’intelligence artificielle ne remplace pas le développeur ou le webdesigner. Dans ce workflow, elle devient un assistant structurel, un normalisateur, un opérateur, un validateur et un accélérateur.

Combinée aux agents, aux skills, à SSH, à WP-CLI, au travail local et à Gutenberg, elle ouvre surtout la possibilité de construire un système de travail cohérent, maintenable et évolutif autour de WordPress.