Agent Composer : conserver WordPress comme CMS du web créé par l’IA

La couche manquante

Générer le frontend n’est que la première livraison

Les outils transformant un prompt en site ou une maquette Figma en code peuvent produire très rapidement un frontend fonctionnel. C’est utile et, pour certains projets, c’est exactement la bonne approche. Ils optimisent toutefois surtout la première génération. Le résultat est souvent une application ou un ensemble de composants frontend, tandis que le modèle de contenu à long terme, le workflow éditorial et les règles des modifications futures restent un problème distinct.

Un site en production est modifié bien plus souvent qu’il n’est créé. Les éditeurs ajoutent des campagnes, des pages de destination et des contenus de connaissance. Les agences introduisent de nouveaux types de contenu et composants réutilisables. Les plugins évoluent. Les règles de marque et d’accessibilité doivent encore s’appliquer six mois plus tard. Si chaque modification devient une nouvelle tâche de génération de code, l’organisation peut gagner un frontend rapide mais perdre le CMS comme source de vérité commune et compréhensible.

• Quels types de contenu, champs et relations existent déjà ?
• Quels modèles de conception et composants réels de plugins l’agent peut-il utiliser ?
• Quelles parties peut-il modifier et que doit approuver une personne ?

Agent Composer traite ce second problème : non pas comment générer une seule page séduisante, mais comment permettre à l’IA de participer à l’évolution continue d’un véritable site WordPress sans transformer chaque mise à jour en exercice de programmation sans limites.

Exécution contrôlée

Agent Composer encadre la modification au lieu de générer une page isolée

Agent Composer est une couche d’exécution et de validation pour le travail WordPress assisté par l’IA. Le site déclare d’abord son contrat : blueprints de pages approuvés, modèles réutilisables, blocs autorisés, règles de conception, exigences de métadonnées, structures de contenu et limites d’écriture. L’agent travaille dans cet environnement déclaré au lieu de deviner comment le site a été construit.

Pour chaque tâche, Agent Composer n’expose que les capacités autorisées par le blueprint choisi et le Site Contract actif. Il assemble les modèles demandés, vérifie l’arbre de blocs et valide les exigences structurelles avant tout enregistrement par WordPress. Un article peut imposer un seul H1, un modèle précis, des sections éditoriales approuvées et des métadonnées SEO. Une page produit peut utiliser une autre famille visuelle et un autre jeu de composants. Les règles suivent le site au lieu de dépendre de la mémoire d’un long prompt par l’agent.

• Les agents créent des brouillons modifiables appartenant à Agent Composer ; ils ne publient pas de manière autonome.
• Le contenu publié reste hors de la limite d’écriture, et l’adoption d’un brouillon existant exige une opération explicite.
• La validation couvre toute la structure des blocs, pas seulement le texte renvoyé par le modèle.

L’implémentation actuelle découvre aussi les capacités produit enregistrées via WordPress Abilities API. Gatey, AI-Kit et Flow exposent déjà leurs propres schémas de composants, matérialiseurs et validateurs. Agent Composer peut donc demander un composant réellement pris en charge avec des réglages validés plutôt que d’en recréer une approximation en Custom HTML.

Un autre modèle de production

WordPress peut rester privé tandis que le site public évolue indépendamment

Conserver WordPress comme CMS ne signifie pas que le site public doit être servi directement par son environnement d’exécution. Dans une architecture WP Suite, WordPress peut rester le plan de contrôle éditorial : le lieu du contenu structuré, des mises en page Gutenberg, des révisions et des décisions de publication. L’installation peut rester derrière un VPN ou un pare-feu au lieu de devenir la surface publique de production.

Un tunnel de connecteur authentifié peut donner à un client d’IA autorisé un accès étroit à Agent Composer sans exposer wp-admin ni l’ensemble du serveur WordPress à Internet. Après la connexion, Agent Composer applique toujours le Site Contract, le blueprint et la limite d’écriture réservée aux brouillons. Le tunnel résout l’accessibilité ; Agent Composer décide ce que l’agent est réellement autorisé à faire. Découvrez comment permettre à l’IA de modifier WordPress sans accès administrateur illimité, ou comment conserver WordPress pour l’édition sans l’exposer publiquement.

• Static Publisher peut exporter le résultat WordPress approuvé pour une diffusion depuis Amazon S3 et CloudFront.
• Static Site Guardian peut ajouter une diffusion protégée lorsque le site exporté ne doit pas être public.
• Les services d’identité, d’API, d’IA et de workflow peuvent fonctionner dans une infrastructure AWS détenue par le client et évoluer indépendamment du serveur de rédaction WordPress.

Cette approche sépare trois responsabilités trop souvent regroupées : WordPress reste la source modifiable, Agent Composer encadre les modifications assistées par l’IA et AWS gère l’environnement public lorsque cela convient. La hausse du trafic ne doit plus nécessairement accroître la charge de l’installation WordPress éditoriale.

L’architecture en un coup d’œil

Un site, trois responsabilités claires

Les couches complémentaires

Agent Composer est au centre ; Canvas et Starter rendent le modèle réutilisable

Agent Composer n’impose pas la même apparence à tous les sites. Son rôle consiste à exécuter le contrat défini pour le site courant. SmartCloud Agent Canvas est la couche de thème blocs de référence qui peut fournir un système de conception cohérent, des modèles sémantiques et des règles de mise en page compris par Agent Composer. Il montre comment concevoir un thème à la fois pour l’édition humaine et l’exécution encadrée des agents. Le modèle sûr de création de pages par l’IA montre comment ces contraintes protègent les pages créées ultérieurement par le client.

SmartCloud Agent Starter est préparé comme fondation commerciale réutilisable pour les agences. Il peut regrouper des variantes de site, des préréglages de conception, des plugins facultatifs, des blueprints, des modèles et un Site Contract initial. Une proposition de configuration propre au site peut ensuite adapter cette fondation au projet réel et être examinée avant adoption.

• Agent Composer exécute et valide le contrat de site approuvé.
• Canvas fournit une fondation de conception et de structure lisible par l’agent.
• Starter réduit le travail nécessaire pour établir cette fondation sur un nouveau projet.

La distinction est importante. Canvas et Starter facilitent le démarrage, mais Agent Composer maintient les modifications ultérieures assistées par l’IA sous contrôle, natives dans WordPress et vérifiables. Le produit durable n’est pas la première page générée : c’est la capacité encadrée de modifier à nouveau le site. Consultez le workflow de contenu assisté par l’IA, natif et modifiable.

Valeur pour les agences

L’agence peut livrer un système prévu pour les changements futurs

Les agences sont de plus en plus comparées à des outils capables de générer la première version d’un site en quelques minutes. Ne rivaliser que sur la vitesse de cette première réalisation réduit leur positionnement. Agent Composer permet une autre proposition : livrer un site WordPress que le client peut continuer à développer avec l’aide de l’IA, tandis que l’agence définit le système de conception, le modèle de contenu, les capacités approuvées et les limites de révision.

Un client peut demander un nouvel article ou une page de destination via un agent connecté et recevoir un brouillon WordPress valide, construit avec les véritables modèles du site. Le résultat reste modifiable. L’agence n’a pas à réparer un nouvel ensemble de balisage généré après chaque demande, et le client n’a pas à donner à l’agent un accès administrateur illimité. Le guide de gouvernance après livraison décrit ce modèle d’exploitation pour les agences.

• Création plus rapide de contenu client dans les limites définies par l’agence.
• Moins de régressions visuelles et structurelles qu’avec une génération de pages sans contraintes.
• Un rôle continu pour l’architecture, la gouvernance, le développement de composants et le support.

Il ne s’agit ni de publication autonome ni d’affirmer que chaque frontend doit être généré depuis WordPress. C’est une troisième option pragmatique : conserver le CMS, le préparer aux agents et découpler la diffusion publique lorsque la sécurité ou l’évolutivité l’exige.