Dans un précédent article, j’analysais l’AI Client de WordPress 7.0, cette nouvelle API PHP qui permet à n’importe quel plugin d’interagir avec des modèles d’IA via une interface unifiée. Mais l’AI Client ne fonctionne pas seul. Il repose sur une seconde brique, tout aussi structurante, qui mérite une attention particulière : la Connectors API.
Cette API constitue le socle d’infrastructure sur lequel s’appuient les connexions aux services externes dans WordPress 7.0. Si l’AI Client définit « ce que l’on peut faire » avec l’IA, la Connectors API définit « comment le site se connecte » aux providers qui rendent ces fonctionnalités possibles. Et sa portée va bien au-delà de l’IA seule.
Ce qu’est un connector, et pourquoi cela change la donne
Un connector, dans la terminologie WordPress 7.0, représente une connexion à un service externe. Chaque connector porte des métadonnées standardisées : un nom, une description, un logo, une configuration d’authentification, et une association optionnelle avec un plugin du répertoire WordPress.org.
Ce qui est intéressant dans cette approche, c’est le niveau de standardisation qu’elle impose. Jusqu’à présent, chaque plugin gérait ses connexions externes à sa manière, avec ses propres écrans de configuration, sa propre logique de stockage des credentials, ses propres conventions de nommage. Le résultat, pour un administrateur de site, c’était une dispersion totale. Configurer trois services différents impliquait de naviguer dans trois interfaces différentes, sans aucune cohérence.
La Connectors API met fin à cette fragmentation en créant un point d’entrée unique via l’écran Settings > Connectors. Tous les services connectés y sont visibles sous forme de cartes, avec un statut de connexion clair, un bouton d’installation ou d’activation du plugin associé, et un lien direct vers la plateforme du provider pour obtenir ses credentials.
C’est exactement le type de centralisation que nous recommandons chez WexIT quand nous architecturons des plateformes multi-services pour nos clients. On utilise un point de contrôle unique pour la gouvernance des connexions externes, plutôt qu’une mosaïque de configurations éparpillées.
L’auto-discovery : quand l’infrastructure fait le travail
L’un des choix de conception les plus élégants la Connectors API est le mécanisme d’auto-discovery des providers IA.
Le principe est le suivant : si vous développez un plugin AI provider qui s’enregistre auprès du WP AI Client, vous n’avez pas besoin d’enregistrer manuellement un connector. La Connectors API interroge automatiquement le registry de l’AI Client, détecte les providers enregistrés, et crée les connectors correspondants avec les bonnes métadonnées.
Le cycle d’initialisation se déroule en trois étapes. D’abord, les connectors built-in (Anthropic, Google, OpenAI) sont enregistrés avec leurs valeurs par défaut. Ensuite, le système interroge le registry de l’AI Client pour tous les providers enregistrés. Les métadonnées de chaque provider (nom, description, logo, méthode d’authentification) sont fusionnées avec les defaults, les valeurs du registry ayant la priorité. Enfin, le hook `wp_connectors_init´ est déclenché pour permettre aux plugins de surcharger des métadonnées ou d’enregistrer des connectors supplémentaires.
Ce pattern d’auto-discovery est un classique des architectures bien pensées. Il réduit le boilerplate, élimine les risques de désynchronisation entre le registry de l’AI Client et celui des Connectors, et offre une expérience zero-config pour les développeurs de plugins. C’est le même type de convention-over-configuration que l’on retrouve dans les frameworks modernes, et c’est une marque de maturité dans la conception d’une API de plateforme.
La gestion des API keys : un système à trois niveaux de priorité
La question de la gestion des credentials est centrale dans toute architecture de connexion à des services externes. La Connectors API adopte une approche pragmatique avec un système de résolution à trois niveaux pour les connectors de type `api_key´.
Le premier niveau de priorité est la variable d’environnement. Pour les providers IA, la convention de nommage est `{PROVIDER_ID}_API_KEY´ (par exemple `ANTHROPIC_API_KEY´). Le second niveau est la constante PHP, définie typiquement dans `wp-config.php´. Le troisième niveau est la base de données, via l’écran d’administration Settings > Connectors.
Cette hiérarchie de résolution n’est pas anodine. Elle reflète une gradation dans le niveau de sécurité et de contrôle. La variable d’environnement, gérée au niveau de l’infrastructure (serveur, orchestrateur, vault), est la méthode la plus sécurisée : la clé n’apparaît jamais dans le code ni en base de données. La constante PHP offre un compromis : la clé est dans le code de configuration mais pas en base. La base de données est la solution la plus accessible pour un administrateur non technique, mais aussi la moins sécurisée.
C’est un point que nous surveillons de près chez WexIT. Sur les projets que nous pilotons, nous recommandons systématiquement la gestion des secrets via des variables d’environnement ou des solutions de vault, jamais en base de données. Le fait que WordPress intègre nativement cette hiérarchie dans son core est un signal positif, car cela encourage les bonnes pratiques sans les imposer, en laissant chaque site choisir le niveau de sécurité adapté à son contexte.
Il faut toutefois noter un point de vigilance relevé par la communauté WordPress : les clés stockées en base de données ne sont pas chiffrées. Elles sont masquées dans l’interface utilisateur, mais stockées en clair. Le chiffrement est en cours d’exploration dans un ticket dédié. C’est une limitation à avoir en tête, particulièrement pour les sites en environnement mutualisé ou pour les configurations multisite. Pour en savoir davantage sur les risques de sécurité liés à la divulgation des données, se référer à l’article « LLM02 : Sensitive Information Disclosure, la fuite silencieuse« .
L’absence de scoping : un choix architectural à surveiller
Un aspect qui a suscité des discussions dans la communauté WordPress concerne le scoping des API keys. Dans l’implémentation actuelle, une clé enregistrée via la Connectors API est accessible à tous les plugins du site. Il n’existe pas de mécanisme de permission par plugin : si un provider est configuré, n’importe quel plugin peut l’utiliser.
C’est un choix cohérent avec la philosophie actuelle de WordPress, où les plugins partagent un même espace d’exécution. Mais c’est aussi un point d’attention pour les administrateurs de sites qui installent des plugins tiers : configurer un provider IA signifie implicitement autoriser tous les plugins du site à y accéder.
Pour les agences comme la nôtre, qui gèrent des environnements WordPress pour des clients avec des exigences de sécurité élevées, cela renforce l’importance de deux pratiques. D’une part, être sélectif sur les plugins installés, ce qui est une bonne pratique dans tous les cas. D’autre part, utiliser le hook `wp_ai_client_prevent_prompt´ (décrit dans l’article sur l’AI Client) pour contrôler finement quels plugins peuvent effectivement soumettre des requêtes IA.
L’API publique : trois fonctions, un registry, une philosophie
La surface d’API publique de la Connectors API est volontairement minimaliste. Trois fonctions couvrent les besoins courants des développeurs de plugins :
- `wp_is_connector_registered()´ pour vérifier l’existence d’un connector ;
- `wp_get_connector()´ pour récupérer les données d’un connector spécifique ;
- `wp_get_connectors()´ pour lister tous les connectors enregistrés ;
Sous le capot, ces fonctions s’appuient sur un `WP_Connector_Registry´ qui expose des méthodes de manipulation directe : `register()`, `unregister()´, `is_registered()´, `get_registered()´, `get_all_registered()´. Ces méthodes ne sont accessibles que dans le callback du hook `wp_connectors_init´. Toute tentative de modification du registry en dehors de ce hook déclenche un `_doing_it_wrong()´.
Ce verrouillage du lifecycle est un pattern que j’apprécie. Il garantit que l’état du registry est déterministe, toutes les modifications se font dans une fenêtre temporelle définie, après quoi le registry est en lecture seule. C’est exactement le type de contrainte qui prévient les bugs subtils liés à des modifications tardives de l’état global, un problème classique dans les architectures à plugins.
Le pattern de surcharge des métadonnées est également bien conçu, puisque le registry rejette les IDs dupliqués, la modification d’un connector existant passe par une séquence unregister, modify et register. C’est explicite, traçable, et cela évite les effets de bord silencieux.
La vision long terme va bien au-delà de l’IA
Ce qui rend la Connectors API particulièrement intéressante d’un point de vue stratégique, c’est qu’elle n’est pas limitée aux providers IA. L’architecture est conçue pour accueillir n’importe quel type de connexion à un service externe.
Les discussions dans la communauté font déjà état de cas d’usage concrets comme les payment gateways, les intégrations social media, les services d’email transactionnel. Le registry PHP accepte d’ores et déjà n’importe quel type de connector. Ce qui manque encore, c’est l’intégration front-end pour les connectors dont la méthode d’authentification dépasse le simple `api_key´, notamment les flows OAuth.
Pour les agences web, cette trajectoire est significative. Elle dessine un WordPress où la gestion de toutes les connexions externes serait centralisée dans un écran unique, avec une API standardisée pour l’enregistrement, la découverte et la configuration. C’est un pas vers une plateforme plus gouvernable, où l’administrateur dispose d’une vision claire de toutes les dépendances externes de son site.
Chez WexIT, nous travaillons régulièrement sur des architectures WordPress qui s’interfacent avec des ERP, des PIM, des CRM, des services de paiement. La perspective d’une Connectors API étendue à ces cas d’usage est prometteuse, car elle pourrait standardiser des patterns d’intégration que chaque projet réinvente aujourd’hui de zéro.
L’avis de WexIT : la Connectors API comme fondation de gouvernance
Si je devais résumer ce que la Connectors API apporte à l’écosystème WordPress, je dirais qu’elle pose les bases d’une gouvernance centralisée des services externes. C’est un sujet que l’on porte sur les projets complexes, la question n’est pas seulement de savoir quels services sont connectés, mais de savoir qui a accès à quoi, avec quels identifiants, et avec quel niveau de contrôle.
Aujourd’hui, la Connectors API répond à ce besoin pour les providers IA. Demain, si la roadmap se confirme, elle pourrait devenir le point de gouvernance unique pour toutes les connexions externes d’un site WordPress. C’est une évolution architecturale dont la portée dépasse largement le seul sujet de l’IA.
Pour les équipes techniques qui travaillent sur des projets WordPress en 2026, ma recommandation est simple, il faut se familiariser avec la Connectors API dès maintenant, même si vos projets actuels n’utilisent pas encore les fonctionnalités IA. C’est une brique d’infrastructure dont le périmètre va s’élargir, et les patterns qu’elle impose sont des fondamentaux qui méritent d’être maîtrisés.
L’infrastructure de connexion ne se boulonne pas après coup. Elle se pense dès les fondations.
