AI 1.3.0 pour WordPress : les contrôles avant déploiement Avant d’ouvrir les capacités IA
La version 1.3.0 du plugin AI pour WordPress, publiée le 18 août 2026, ajoute plusieurs fonctions directement utiles aux éditeurs et aux équipes techniques. Traduction de contenus, génération de slugs, exposition contrôlée de capacités personnalisées, import-export de réglages et durcissement de plusieurs traitements : l’évolution est intéressante, mais elle ne doit pas être activée sans vérification préalable sur les sites clients.
Le plugin AI officiel évolue rapidement. La version 1.3.0 a été publiée le 18 août 2026, dans le prolongement des travaux menés autour de l’Abilities API et des connecteurs de modèles. Elle apporte des fonctions visibles dans l’éditeur, mais aussi des changements importants pour les équipes qui administrent plusieurs sites WordPress.
Pour une agence, le sujet n’est donc pas seulement de savoir si une fonction produit un texte ou un slug correct. Il faut surtout déterminer quelles données sont accessibles, quelles capacités peuvent être appelées, quel fournisseur traite les informations et comment un administrateur peut contrôler ou retrouver les actions effectuées.
Ce que change AI 1.3.0
La version 1.3.0 ajoute une expérimentation de traduction de contenu dans l’éditeur. Les blocs Paragraph et Heading pris en charge peuvent être traduits vers une langue choisie, avec la possibilité d’inclure le titre de l’article. Le résultat remplace le contenu dans l’éditeur, où il peut être relu et ajusté avant publication.
Elle ajoute aussi une génération de slugs à partir du titre et du contenu. La suggestion peut être examinée, modifiée ou régénérée avant application. Cette fonction ne remplace donc pas une stratégie SEO, mais elle peut réduire une tâche répétitive sur des sites éditoriaux ou des catalogues structurés.
Premier contrôle : quelles capacités sont exposées ?
Le changement le plus important pour une agence concerne le réglage qui permet d’exposer les capacités personnalisées du plugin AI via l’Abilities API. Une seule option peut rendre disponibles plusieurs capacités, notamment la lecture de contenus, de réglages, d’utilisateurs, de taxonomies ou de détails d’articles. Cette exposition doit être considérée comme un choix d’architecture et non comme une simple préférence d’interface.
Si un agent ou une intégration n’a besoin que de lire un catalogue public, il n’est pas pertinent d’exposer des capacités liées aux utilisateurs, aux réglages internes ou à des contenus confidentiels. Le principe à retenir est simple : activer le périmètre minimal, puis élargir uniquement après un test documenté.
Troisième contrôle : la recette et le suivi
La traduction et la génération de slugs doivent être testées avec des contenus représentatifs. Vérifiez les blocs personnalisés, les champs ACF, les contenus multilingues, les caractères spéciaux, les taxonomies et les règles de permaliens. Pour WooCommerce, testez séparément les produits, les variations, les attributs, les commandes et les données clients. Une fonction prévue pour l’éditeur ne doit jamais modifier involontairement le parcours public ou le checkout.
La version 1.3.0 ajoute aussi des contrôles Site Health, des journaux de requêtes IA et des protections supplémentaires autour du rendu de contenu, des actions groupées et du téléchargement d’images. Ces éléments doivent être consultés après installation, puis intégrés à la procédure de maintenance de l’agence. Ils ne remplacent ni les sauvegardes ni les tests de restauration.
Poursuivez votre lecture
Trois articles pour aller plus loin.
Besoin d’un avis clair sur votre site ?
Premier échange clair · Priorités concrètes
Je peux vous aider à comprendre la situation, identifier les points importants et définir une intervention adaptée.
Premier échange gratuit · Sans engagement · Réponse rapide