WordPress vient de franchir un cap qui mérite qu’on s’y arrête. Avec la version 7.0, sortie fin mars 2026, le CMS le plus utilisé au monde intègre nativement un AI Client dans son Core. Pas un plugin tiers, pas une extension communautaire, mais une API PHP directement embarquée dans WordPress Core, conçue pour que n’importe quel plugin puisse interagir avec des modèles d’IA à travers une interface unifiée.
En tant que CTO d’une agence qui travaille quotidiennement avec l’écosystème WordPress et qui accompagne des clients sur des projets de développement web complexes, je trouve que cette évolution est l’une des plus structurantes de ces dernières années pour la plateforme. Voici pourquoi.
Le principe : une couche d’abstraction provider-agnostic
La philosophie de l’AI Client repose sur un principe architectural qui consiste à séparer ce que l’on veut faire de la manière dont on le fait.
Concrètement, un plugin décrit ses besoins, comme le type de contenu à générer et ses contraintes associées, et WordPress se charge de router la requête vers un modèle adapté, chez le provider que l’administrateur du site a configuré. Le plugin n’a pas besoin de savoir si c’est Claude, GPT ou Gemini qui traite la demande. Il n’a pas besoin de gérer les API keys. Il n’a pas non plus besoin de connaître les spécificités d’implémentation de chaque provider.
C’est exactement le type d’abstraction qui manquait à l’écosystème. Jusqu’ici, chaque plugin qui voulait intégrer de l’IA devait embarquer sa propre logique de connexion, ses propres dépendances, sa propre gestion de credentials … Ce qui occasionnait une fragmentation massive, des incompatibilités entre plugins, et une expérience incohérente pour l’utilisateur final.
L’architecture en deux couches : SDK + wrapper WordPress
Ce qui m’intéresse particulièrement dans cette implémentation, c’est la séparation en deux couches distinctes. C’est un choix d’architecture qui en dit long sur la maturité de la réflexion.
La première couche est un SDK PHP générique (`wordpress/php-ai-client´), embarqué dans Core comme library externe. Ce SDK est provider-agnostic et techniquement indépendant de WordPress, il utilise des conventions PHP standard (camelCase, exceptions), gère la communication avec les providers, la sélection des modèles et la normalisation des réponses. Il est réutilisable en dehors de WordPress.
La seconde couche est un wrapper WordPress (`WP_AI_Client_Prompt_Builder´) qui adapte le SDK aux conventions du CMS : méthodes en snake_case, retours sous forme de `WP_Error´, intégration avec le transport HTTP de WordPress, les Abilities API, l’infrastructure Connectors/Settings et le système de hooks.
Cette séparation est un pattern que j’apprécie beaucoup. Elle permet au SDK sous-jacent d’évoluer indépendamment des spécificités de WordPress, tout en offrant aux développeurs de plugins une surface d’API parfaitement idiomatique. C’est le même type de réflexion que l’on retrouve dans les architectures headless que nous concevons chez WexIT, en découplant les responsabilités pour que chaque couche puisse évoluer à son propre rythme.
Le fluent builder : une API pensée pour les développeurs
L’entry point de l’AI Client est la fonction `wp_ai_client_prompt()´, qui retourne un objet `WP_AI_Client_Prompt_Builder´. L’API suit un pattern de fluent builder qui permet de lier les méthodes de configuration, puis on appelle une méthode de génération pour obtenir le résultat.
Ce qui est bien conçu dans cette API, c’est sa capacité à couvrir un spectre très large de cas d’usage tout en restant lisible. La génération de texte et la génération d’images sont des fonctionnalités de base, mais l’API va bien au-delà car ses réponses sont
- réponses structurées à l’aide d’un schéma JSON ;
- génération multimodale (texte et image dans une même requête) ;
- synthèse vocale (text-to-speech) ;
- génération vidéo ;
- gestion de l’historique de conversation pour les interactions multi-tours.
Les paramètres de configuration sont complets : system instructions, temperature, max tokens, top-p/top-k, stop sequences, model preferences, output modalities et types de fichiers. Pour un développeur de plugins, cela signifie un contrôle plus affiné sur le comportement du modèle, sans jamais manipuler directement les API des providers.
Feature detection : ne jamais supposer que l’IA est disponible
Un aspect de la conception que je trouve particulièrement bien pensé, et qui reflète une vraie maturité en termes de développement de plateforme, c’est le système de feature detection.
WordPress 7.0 n’impose pas l’IA. Tous les sites ne configureront pas un provider, et tous les providers ne supporteront pas toutes les modalités. L’AI Client fournit donc des méthodes de vérification — `is_supported_for_text_generation()´, `is_supported_for_image_generation()´… qui permettent à un plugin de vérifier en amont si une fonctionnalité est disponible avant de l’exposer dans l’interface.
Ces vérifications n’effectuent aucun appel API : elles utilisent de la logique déterministe pour croiser la configuration du builder avec les capabilities des modèles disponibles. C’est rapide, gratuit, et cela permet aux plugins de dégrader gracieusement leur interface quand l’IA n’est pas disponible.
Pour les agences comme la nôtre qui développent des solutions sur mesure pour des clients, c’est un point important. Cela signifie qu’on peut concevoir des fonctionnalités enrichies par l’IA, qui restent parfaitement fonctionnelles sans elle.
La gestion des providers ouverte et sans vendor lock-in
WordPress Core ne bundle aucun provider IA directement. Les providers sont intégrés via des plugins dédiés, et trois implémentations officielles sont déjà disponibles : AI Provider for Anthropic, AI Provider for Google et AI Provider for OpenAI.
En séparant le Core du Client IA des implémentations spécifiques à chaque provider, WordPress garantit que la fondation reste stable et agnostique, tandis que la couche provider peut itérer rapidement pour suivre l’évolution des API, ce qui change parfois du jour au lendemain dans le domaine de l’IA.
L’administrateur du site configure ses providers dans un écran Settings > Connectors, et la gestion des API keys se fait automatiquement via la Connectors API. Les développeurs de plugins n’ont jamais besoin de manipuler des credentials. C’est un gain de sécurité non négligeable, car les secrets restent dans l’infrastructure WordPress, et non pas dans le code des plugins.
Le système de model preferences est également bien conçu. Un plugin peut exprimer une liste ordonnée de modèles préférés, et l’AI Client sélectionne le premier disponible, avec fallback sur n’importe quel modèle compatible. Cela signifie qu’un plugin fonctionne quel que soit le provider configuré par le site.
Le contrôle granulaire : filtres et prévention
Un point qui intéressera les administrateurs de sites et les agences qui gèrent des parcs WordPress : l’AI Client intègre un système de filtres pour contrôler finement quels prompts sont autorisés. Via le hook `wp_ai_client_prevent_prompt´, il est possible de bloquer sélectivement des requêtes IA, comme par exemple, réserver l’accès aux administrateurs, ou limiter certains types de génération.
Quand un prompt est bloqué, les méthodes `is_supported_*()´ retournent `false´` et les méthodes `generate_*()´ retournent un `WP_Error´. Le plugin peut réagir proprement sans crash ni dégradation de l’expérience.
C’est le genre de garde-fou indispensable à l’échelle d’une plateforme utilisée par des millions de sites. L’IA intégrée dans le Core ne signifie pas l’IA sans contrôle.
Ce que cela change concrètement pour les agences web
Du point de vue d’un CTO d’agence, l’intégration de l’AI Client dans WordPress Core a des implications concrètes sur la manière dont nous concevons et développons des projets.
- La fin de la fragmentation IA dans WordPress. Jusqu’ici, chaque plugin qui intégrait de l’IA le faisait à sa manière, avec ses propres dépendances et sa propre gestion de providers. Désormais, il existe une interface standard. Les plugins peuvent se concentrer sur la valeur fonctionnelle plutôt que sur la plomberie technique de l’intégration IA.
- Un nouveau terrain pour la création de valeur. Pour les agences qui développent des solutions WordPress sur mesure, l’AI Client ouvre un champ de possibilités considérable. Génération de contenu assistée, personnalisation dynamique, enrichissement automatique de fiches produits, traduction, résumé, aide à la rédaction. Tout cela devient accessible via une API standard, sans dépendance à un provider spécifique.
- Un enjeu de montée en compétence. L’écosystème WordPress va voir émerger une nouvelle catégorie de plugins et de fonctionnalités alimentées par l’IA. Les agences qui sauront exploiter l’AI Client de manière pertinente, plus précisément en créant des fonctionnalités utiles et bien intégrées, prendront un avantage concurrentiel significatif.
- Un renforcement de l’approche agnostique. Chez WexIT, nous défendons depuis toujours l’indépendance technologique et le refus du vendor lock-in. Voir WordPress adopter cette philosophie pour son intégration IA est un signal fort. Le provider d’IA devient interchangeable, et c’est le site owner qui garde le contrôle.
L’avis de WexIT : une brique fondatrice, pas une fin en soi
Il ne faut pas s’y tromper, l’AI Client de WordPress 7.0 est une brique d’infrastructure, pas une solution clé en main. Il fournit le mécanisme, et non pas l’intelligence fonctionnelle. C’est bien aux développeurs de plugins et aux agences de construire des expériences pertinentes par-dessus.
Et c’est précisément ce qui nous plaît dans cette approche. WordPress ne prétend pas savoir mieux que les développeurs ce qu’il faut faire avec l’IA. Il fournit une fondation solide, ouverte et bien architecturée, en laissant l’écosystème innover. C’est la même logique que le Block Editor, que l’API REST ou que le système de hooks. WordPress fournit les primitives, les développeurs créent la valeur.
Pour les équipes qui travaillent déjà sur des architectures WordPress modernes : headless, API-first ou découplées, cette nouvelle brique s’intègre naturellement dans la stack. Et pour les autres, c’est peut-être l’occasion de reconsidérer la manière dont elles architecturent leurs projets WordPress.
L’IA ne se boulonne pas à la fin d’un projet. Elle se pense dès l’architecture.
Laisser un commentaire