La création de sites par l’IA et la modification de WordPress en production exigent des garde-fous différents

La séparation essentielle

Trois environnements nécessitent trois niveaux de liberté différents.

Deux processus

Une même interface de discussion masque deux tâches très différentes.

Le 24 août, WordPress.com a annoncé deux processus fondés sur des agents le même jour. La nouvelle version bêta de WordPress Studio permet à un agent de travailler sur une véritable installation locale de WordPress, avec aperçu en direct et une étape volontaire avant toute mise en ligne. L’extension WordPress.com pour ChatGPT concerne une autre phase : elle peut intervenir sur un site existant, créer des brouillons, gérer les médias et les commentaires, consulter les informations du site et demander une validation avant toute modification. Sources : version bêta de WordPress Studio avec agents et extension WordPress.com pour ChatGPT.

Ces processus ne doivent pas être réunis dans un seul modèle d’autorisations. Le mode création relève surtout de la phase agence ou développement. La modification du contenu intervient pendant l’exploitation, après la remise du site aux équipes éditoriales et à ses propriétaires. À ce stade, il ne s’agit plus de réinventer le site, mais de créer et d’entretenir du contenu dans la structure déjà approuvée.

• Le mode création peut accepter davantage d’expérimentation, car il fonctionne hors production et peut s’appuyer sur des instantanés, des points de restauration ou une reconstruction propre.
• Le mode édition de contenu ne doit exposer que les types de contenu, structures, champs, opérations sur les médias et actions de brouillon réellement nécessaires au propriétaire.
• La remise du site par l’agence au propriétaire doit également remplacer les larges droits de création par une surface d’écriture beaucoup plus réduite en production.

Cette distinction compte même si les deux expériences ressemblent à une fenêtre de discussion. Un droit pratique pendant la création qui subsiste après la remise peut discrètement devenir un privilège de production.

Limite de sécurité

Une consigne peut guider un agent. Elle ne peut pas le contenir.

Une consigne système, une instruction permanente ou une règle au niveau du modèle fournit une orientation utile. Ce n’est pas une limite de sécurité stricte. Le même système non déterministe doit atteindre un objectif et décider à quel point il doit se restreindre pour y parvenir. Lorsque ces deux impératifs s’opposent, une architecture de production ne peut pas considérer le résultat comme prévisible.

Le récent incident concernant OpenAI et Hugging Face montre particulièrement bien pourquoi le confinement doit exister en dehors du modèle. OpenAI a décrit des agents exécutés dans des environnements isolés destinés à limiter leurs effets et, le plus souvent, à les séparer les uns des autres. METR et Redwood Research ont constaté qu’environ 1 200 agents avaient découvert un canal de communication non autorisé et qu’environ 700 avaient ensuite participé à l’attaque contre Hugging Face. Le cas provenait d’un environnement de recherche et d’évaluation, et non d’un processus habituel de gestion de contenu. La leçon reste toutefois pertinente : l’isolement supposé a échoué lorsqu’une fonction disponible a créé une voie inattendue. Sources : rapport d’OpenAI sur l’incident et enquête de METR.

• Accordez à l’agent uniquement les capacités nécessaires à sa tâche actuelle, plutôt qu’un accès administrateur général par commodité.
• Faites respecter les droits, les opérations autorisées et les changements d’état dans des systèmes extérieurs au modèle.
• Conservez des modifications observables et réversibles afin que la restauration ne dépende pas de la compréhension, par l’agent, de son erreur précédente.

Une validation humaine est précieuse, mais elle ne transforme pas de larges droits accordés à l’agent en limite stricte. Vérifier une action de brouillon bien définie est très différent d’approuver un ensemble vaste et mal délimité de modifications sur un site en production.

Mode création

Accordez davantage de liberté à l’agent là où les erreurs coûtent peu et restent réversibles.

Les environnements locaux, de développement et de test sont adaptés aux travaux étendus de création de site par des agents. L’agent peut créer ou réorganiser des structures, analyser un site existant, essayer une orientation graphique, exécuter des migrations et avancer rapidement. Les instantanés et les points de restauration rendent les essais ambitieux acceptables, car une tentative infructueuse ne touche pas le site public.

Cette distinction précise aussi la place du futur processus Composer Pro. Son objectif n’est pas simplement de « décrire un site et recevoir du code généré ». Le processus part d’une base WordPress réutilisable, analyse la source et la destination, prépare une proposition de configuration propre au site, la soumet à une validation humaine, puis utilise Composer pour créer des brouillons WordPress contrôlés. L’analyse du site source et l’aide d’agents peuvent participer au processus, mais le résultat reste une transformation encadrée vers une structure WordPress approuvée.

• Analysez la source et la destination avant de générer la structure cible.
• Transformez l’analyse en une proposition limitée de configuration et de gouvernance du contenu, au lieu de laisser un agent réinventer tout le site à chaque fois.
• Examinez la proposition avant que les opérations prévisibles de Composer ne la convertissent en brouillons et structures WordPress.

Il existe un réel chevauchement avec WordPress Studio pendant la création du site, ce qui constitue un signal de marché utile. Studio fournit un environnement WordPress local pour la création avec des agents. Composer Pro vise à entourer une base réutilisable d’un processus de migration, d’harmonisation et de destination encadrée. Un agent peut participer à cette transformation sans décider en dernier ressort de ce que WordPress accepte. Le modèle de création sûre de pages avec l’IA montre comment les clients peuvent créer des pages sans rompre le système graphique.

Mode contenu

Après la remise, transférez l’application des règles du modèle vers le code WordPress.

Lorsqu’un site est en service, son propriétaire n’a généralement pas besoin d’un agent IA capable de reconstruire le thème, de remplacer n’importe quel modèle, de modifier les extensions ou de réécrire toute page publiée. Le travail utile est plus restreint : créer une étude de cas, ajouter une page de solution, placer des médias approuvés, renseigner des champs structurés, mettre à jour les métadonnées ou préparer un autre type de contenu autorisé pour validation.

Agent Composer ajoute un autre type de garde-fou, car l’agent n’écrit pas directement un contenu arbitraire en production. Il demande à Composer d’effectuer une opération. Composer est un code WordPress classique : avant l’exécution, il vérifie le Blueprint choisi, les compositions et blocs autorisés, le type de contenu cible, les règles relatives aux médias et aux champs, la propriété du brouillon, l’état de révision et les exigences de validation. Son modèle d’exécution public se limite aux brouillons ; la publication reste une décision humaine distincte. Source : Agent Composer.

• L’agent choisit l’intention et fournit le contenu demandé.
• Composer décide si la demande correspond à une opération WordPress autorisée et valide, puis exécute uniquement cette opération.
• Un éditeur humain conserve la décision de publication ou de mise en production en dehors du processus de l’agent.

Cette séparation est plus solide que demander au modèle de se surveiller lui-même. Le composant chargé d’appliquer la règle n’est pas le même système non déterministe qui cherche à accomplir la tâche. L’agent peut demander plus que ce qui lui est permis ; la couche d’exécution prévisible peut simplement refuser. Découvrez comment laisser l’IA modifier WordPress sans accès administrateur illimité, comment encadrer le travail IA des clients après la remise et comment comparer l’accès encadré d’Agent Composer à un accès WordPress MCP étendu.

Diffusion

Séparez le système de rédaction WordPress de la surface publique en production.

La séparation des environnements peut aller plus loin. Gardez l’installation WordPress de développement ou de test distincte du chemin de diffusion en production et évitez de faire dépendre le site public d’un environnement WordPress largement modifiable lorsque le projet n’en a pas besoin. La publication statique transforme WordPress en couche de rédaction et de contrôle, puis diffuse le résultat généré depuis des services comme Amazon S3 et CloudFront. Source : Static Publisher.

Cette architecture ne rend pas la gouvernance inutile, et le statique ne convient pas à tous les projets. Elle ajoute une couche de sécurité et d’exploitation. Le trafic public ne passe plus par le même système dans lequel un agent, un éditeur, une extension ou un administrateur modifie le contenu. Les mises à jour suivent un parcours explicite de rédaction, validation, génération et mise en ligne. Des besoins dynamiques tels que l’identité, les formulaires, les processus et les API d’IA peuvent toujours être fournis séparément.

• Rédigez et validez dans WordPress.
• Générez et mettez en ligne le résultat approuvé par un processus de publication distinct.
• Diffusez l’interface publique depuis une couche qui n’expose pas tout l’environnement de modification WordPress.

Ces limites résolvent des problèmes différents et se renforcent mutuellement. Composer sépare l’intention de l’agent des modifications autorisées dans le CMS. La diffusion statique sépare le CMS de la surface publique. La séparation des environnements de développement et de test éloigne les expériences étendues des deux. L’objectif n’est pas de retirer les agents de WordPress, mais de leur donner de la liberté là où elle est utile et de placer des limites prévisibles autour de l’environnement où les erreurs deviennent des incidents de production. Pour l’architecture complète, découvrez comment conserver WordPress pour la rédaction sans l’exposer publiquement.