WordPress 7 et l’IA : sécuriser les clés API de l’écran Connecteurs

On me présente WordPress 7 comme LA grande bascule vers l’IA. La version la plus ambitieuse depuis Gutenberg, paraît-il… Oui. C’est vrai. Mais on oublie l’autre moitié : c’est aussi la plus grosse surface d’attaque que le cœur de WordPress ait ouverte depuis des années. J’ai déjà fait le tour de tout ce qui change avec WordPress 7. Cette fois, je creuse l’angle que la hype oublie : la sécurité.

Depuis le 20 mai 2026, un seul écran enregistre les clés API de vos fournisseurs d’IA. Une clé qui vaut de l’argent. Beaucoup… Et que n’importe quel plugin installé peut utiliser sans vous demander la permission.

Trois choses à faire cette semaine, donc : auditer ce que votre site expose, restreindre qui peut y toucher, et savoir couper l’IA si vous n’en voulez pas. Du concret, testé, et sourcé jusqu’au dernier chiffre, parce que je sais que des gens très pointus vont lire ces lignes.

Qu’est-ce que l’écran Connecteurs change vraiment ?

L’écran Réglages > Connecteurs, introduit par WordPress 7.0 "Armstrong", centralise en un seul endroit les connexions aux fournisseurs d’IA externes. Trois sont prêts dès le départ : OpenAI, Anthropic (Claude) et Google (Gemini). Vous collez votre clé API une seule fois, et chaque extension compatible l’utilise ensuite via le composant AI Client.

Précision pour les puristes : ces trois fournisseurs ne sont pas embarqués dans le cœur. La note officielle est limpide, "WordPress Core does not bundle any AI providers directly. Instead, they are developed and maintained as plugins". Ce sont donc trois extensions officielles (AI Provider for OpenAI, for Anthropic, for Google), développées et maintenues par le projet WordPress, mais distribuées séparément.

Avant la 7.0, chaque extension qui causait à une IA gérait sa propre clé, sa propre page de réglages, son propre stockage. Le bazar. WordPress 7 range tout ça derrière une seule porte, le Connectors API, qui tient le registre des fournisseurs, l’authentification et les métadonnées. C’est le même principe que WooCommerce pour les passerelles de paiement.

Sauf qu’avec WooCommerce, vous savez qui touche votre portefeuille. Ici, c’est le silence radio. Je pars du principe que vous êtes déjà passé à la 7.0. Si ce n’est pas le cas, ma checklist pour migrer vers WordPress 7 et PHP 8 couvre les prérequis. Ici, on parle de ce qu’il faut verrouiller une fois que vous y êtes.

Là où ça se corse : où vit la clé ? WordPress la cherche dans un ordre précis. D’abord une variable d’environnement (par exemple ANTHROPIC_API_KEY), puis une constante PHP, et seulement en dernier recours la base de données. Retenez bien cet ordre. C’est le levier numéro un de tout cet article.

Pourquoi les hackers rêvent-ils de votre clé API IA ?

Parce qu’une clé API d’IA est un moyen de paiement. Elle débite votre compte OpenAI, Anthropic ou Google à chaque appel. Volée, elle alimente des réseaux de bots, des campagnes de phishing ou de la fraude sentimentale, le tout facturé sur votre carte. D’après Search Engine Journal, ces identifiants valent des dizaines de milliers de dollars sur le marché.

"WordPress 7.0 combined with plugin vulnerabilities = free AI tokens. There will be an absolute rush by hackers to steal API keys."

Oliver Sild, fondateur de Patchstack (sur X)

Traduit : WordPress 7 plus une faille de plugin, ça donne des jetons d’IA gratuits, et il va y avoir une ruée pour voler les clés. The Repository résume la bascule d’une formule : le retour sur investissement du piratage de WordPress vient de changer. Avant, on volait un accès qu’il fallait ensuite revendre. Maintenant, on vole une carte de crédit déjà branchée.

Et voilà le problème, le vrai, celui qui est architectural. Une fois la clé enregistrée, ce n’est pas SEULEMENT votre extension IA qui peut l’utiliser. C’est le réglage du site. Chaque extension installée peut appeler l’IA via la fonction wp_ai_client_prompt(), sans validation par extension, sans nouveau consentement à chaque appel. Vous êtes passé du courtage au self-service…

À quoi ressemble un vol de clé, concrètement ?

Un vol de clé API sur WordPress 7 suit quatre temps : une faille de plugin est publiée, un attaquant l’exploite pour devenir administrateur, il lit la clé en clair dans la base, puis il déclenche des appels IA en masse facturés sur votre compte. Tout cela peut tenir dans une seule nuit.

Le maillon que personne ne surveille, c’est le temps. D’après le rapport Patchstack 2026, la médiane d’exploitation des failles les plus ciblées tombe à cinq heures après la divulgation publique. Cinq heures. Pas cinq jours. Le temps que vous repériez le pic de consommation sur le tableau de bord du fournisseur, la facture a déjà gonflé… Tout l’enjeu tient là : rendre ce scénario impossible. On s’y met.

L’IA peut-elle agir sur mon site, pas seulement écrire ?

Oui, et c’est le morceau qu’on sous-estime. WordPress 7 ne se limite pas à générer du texte. Avec l’Abilities API, les extensions enregistrent des actions lisibles par une machine, qu’une IA peut exécuter. Une ability peut interroger le site, mais aussi le modifier. Couplée à un adaptateur, elle devient un outil qu’un agent IA peut déclencher à distance.

L’Abilities API existe depuis WordPress 6.9 et monte en puissance avec la 7.0. Le principe : une extension déclare une "ability", une unité de fonctionnalité dans un format "AI-Friendly", avec des fonctions comme wp_register_ability() pour la déclarer et WP_Ability::execute() pour la lancer.

Le mot qui compte, c’est "execute". Une ability n’est pas qu’une fiche de lecture, elle s’exécute. Et depuis février 2026, le WordPress MCP Adapter expose ces abilities comme des outils (exécutables) et des ressources (lecture seule) à des clients IA externes : Claude Desktop, Claude Code, Cursor, VS Code. C’est le mécanisme que je décris dans mon guide pour connecter Claude à votre WordPress. Pratique, mais c’est une porte de plus.

Que se passe-t-il si une ability lit un contenu non fiable ? Vous tombez sur le risque numéro un des applications IA selon l’OWASP, LLM01 Prompt Injection. Imaginez une ability qui résume les commentaires pour en faire un brouillon. Un attaquant glisse une instruction dans un commentaire, et l’IA l’exécute comme si c’était vous. La parade tient en trois réflexes : n’exposer que des abilities sans accès au contenu non fiable, valider les entrées avant de les transmettre, et limiter chaque ability au strict minimum de droits (la lecture seule, idéalement).

La bonne question n’est donc plus "combien ça me coûte si on vole ma clé", mais "qu’est-ce que l’IA a le droit de FAIRE sur mon site". Lire un article, d’accord. Le publier, le supprimer, modifier un réglage, c’est un autre niveau de risque.

Pourquoi les plugins restent-ils le maillon faible ?

91 % des failles WordPress recensées en 2025 viennent des extensions, contre 9 % des thèmes et 6 failles seulement dans le cœur. Le cœur tient bon. Le danger, ce sont les portes que vous ajoutez vous-même. Ces chiffres sortent du rapport Patchstack 2026, et ils n’ont pas bougé dans le bon sens : +42 % de failles en un an.

Faites le calcul. Avant la 7.0, une faille dans un plugin donnait accès à votre site. Pénible, mais le butin était votre contenu. Avec la 7.0, ce même plugin compromis peut désormais toucher une clé qui vaut de l’argent. L’équation a changé : faille de plugin + clé centrale = clé volée et facture qui s’envole.

Et notez bien : Kirki n’est pas un plugin de sécurité. C’est une boîte à outils de personnalisation et un constructeur de pages, exactement le genre d’extension "déco" que tout le monde classe non critique… jusqu’au jour où elle sert de passerelle pour vider un compte OpenAI. La leçon vaut pour toutes vos extensions, pas seulement les plugins de sécurité.

Je surveille ce genre de faille au quotidien depuis que j’ai cofondé WPS Hide Login (plus de 2 millions d’installations actives). Une faille de plugin n’est jamais théorique. Et si vous gardez encore des extensions installées mais inactives "au cas où", c’est le moment d’aller lire pourquoi les plugins abandonnés sont un danger invisible. Un plugin désactivé reste un vecteur d’attaque.

Comment auditer ma surface d’attaque IA ?

Pas besoin d’un outil hors de prix ni d’une demi-journée. Trente minutes, un café, et quatre questions à se poser : quels connecteurs tournent, où vit chaque clé, quelles extensions parlent à une IA, et quel plafond est posé côté fournisseur. Voici la routine que je déroule sur chaque site.

1. Ouvrez Réglages > Connecteurs et notez quels fournisseurs ont une clé active. Un seul suffit dans la plupart des cas. Si trois sont branchés et que vous n’en utilisez qu’un, vous triplez la surface exposée pour rien.
2. Vérifiez où vit la clé. Si elle apparaît dans l’écran, c’est qu’elle est en base, en clair. Si l’écran indique qu’elle provient d’une variable d’environnement ou d’une constante, vous êtes déjà mieux loti.
3. Listez vos extensions qui causent à une IA : génération de texte, alt text, SEO, chatbot, résumé d’articles. Ce sont elles qui appellent le connecteur.
4. Connectez-vous au tableau de bord du fournisseur (OpenAI, Anthropic, Google) et regardez la consommation réelle des derniers jours. Un pic inexpliqué, c’est une alerte. C’est souvent là qu’on repère un vol avant de recevoir la facture.
5. Vérifiez qui peut configurer. Par défaut, seul un compte disposant de la capacité manage_options (un administrateur) touche l’écran Connecteurs. Combien d’admins avez-vous, vraiment ?

Si vous gérez des sites clients, ajoutez une couche. Tous vos comptes admin voient l’écran Connecteurs : combien sont-ils ? L’hébergeur a-t-il pré-configuré un connecteur sans vous le dire ? Chaque client a-t-il SA clé, ou partagez-vous une clé entre plusieurs sites (à proscrire) ? Tenez une liste maître clé par client, c’est votre seule défense le jour d’un incident.

Combien de comptes admin sur votre site n’ont pas la 2FA active ? Si vous ne savez pas répondre dans la seconde, commencez par là. La faille Kirki ci-dessus volait justement des comptes admin. Mon guide sur l’authentification à deux facteurs détaille la mise en place, c’est l’affaire de dix minutes.

Mon conseil : faites cet audit le jour même de votre passage en 7.0, pas "quand vous aurez le temps"… C’est trente minutes, et à minima le meilleur ratio sécurité par minute que je connaisse sur WordPress aujourd’hui. Une fois l’inventaire fait, trois chemins s’offrent à vous, et le bon ne dépend que d’une chose : l’usage réel que vous faites de l’IA sur ce site. Pas d’usage, pas de clé exposée. Un usage cadré, une clé bordée. Voici comment trancher.

Votre situation	Décision	Configuration
Vous utilisez vraiment l’IA (rédaction, alt text, résumés)	Garder	Clé dédiée, scopée au strict besoin, plafonnée, réservée aux admins
Un plugin utilise l’IA mais vous voulez border le risque	Restreindre	Clé hors base, plafond fournisseur, filtre par rôle, surveillance des appels
Aucun usage IA réel sur ce site	Couper	Constante WP_AI_SUPPORT à false dans wp-config.php

Comment restreindre l’IA sans tout casser ?

Vous voulez garder l’IA mais dormir tranquille ? Tout tient en quatre gestes, et l’ordre compte : une clé dédiée à chaque site, un plafond posé côté fournisseur AVANT de coller la clé, la clé sortie de la base, et les prompts réservés aux bonnes personnes. On déroule.

Une clé par site. Jamais la même clé partagée entre plusieurs installations. Créez-en une par site, avec un nom explicite côté fournisseur ("WordPress Production exemple.com"). Si une clé fuite, vous la révoquez sans impacter vos autres sites, et vous savez immédiatement lequel a été touché.

Un plafond côté fournisseur. Le cœur de WordPress 7 ne fournit aucun mécanisme de plafond : ni limite mensuelle, ni limite de débit, ni budget par extension. Le contrôle est donc forcément externe. Allez dans votre compte fournisseur et posez la limite AVANT d’entrer la clé. Attention quand même, c’est un piège classique : les trois ne se comportent pas pareil. Chez OpenAI, le budget d’un projet sert surtout de seuil de suivi et d’alerte : ne comptez pas dessus comme sur un coupe-circuit. Chez Anthropic, le fonctionnement en crédits prépayés joue en votre faveur : crédits épuisés, l’API s’arrête, à condition de ne pas avoir activé la recharge automatique. Chez Google Cloud, les budgets déclenchent des alertes mais ne coupent pas la dépense automatiquement. Résumé : le seul vrai plafond dur, c’est le prépayé sans recharge. Partout ailleurs, l’alerte arrive, mais le compteur continue de tourner.

Sortez la clé de la base. WordPress lit la clé dans un ordre précis : variable d’environnement, puis constante PHP, puis base de données. Plutôt que de la coller dans l’écran (où elle finit en clair), définissez-la dans le wp-config.php. La convention de nommage est stricte, {PROVIDER_ID}_API_KEY : le connecteur Anthropic lit ANTHROPIC_API_KEY, OpenAI lit OPENAI_API_KEY, et ainsi de suite.

// Dans wp-config.php, au-dessus de "That's all, stop editing!"
define( 'ANTHROPIC_API_KEY', 'sk-votre-cle-ici' );

L’écran indique alors que la clé provient d’une constante, le secret n’est plus en base, et un dump SQL volé ne le contient pas. Mieux encore : une vraie variable d’environnement au niveau du serveur la sort même du dépôt de code.

Limitez qui peut lancer des prompts. Le cœur expose un filtre, wp_ai_client_prevent_prompt, qui bloque un appel IA avant qu’il ne parte. Couplé à une vérification de capacité, il réserve l’IA aux administrateurs. Tout autre rôle reçoit une WP_Error, sans aucun appel facturé. Là encore, soyons précis : c’est un filtre du client IA du cœur, pas un pare-feu qui intercepterait tout ce qui sort de votre serveur :

add_filter( 'wp_ai_client_prevent_prompt', function( $prevent ) {
    return current_user_can( 'manage_options' ) ? $prevent : true;
} );

Configurez le strict nécessaire. Un seul fournisseur si un seul suffit, pas les trois "pour voir". Et côté abilities, n’exposez que ce dont vos extensions ont réellement besoin : une IA qui rédige des brouillons n’a aucune raison d’avoir le droit de publier ou de supprimer. Réduire le périmètre des modèles et des capacités, c’est mécaniquement réduire ce qu’un attaquant peut faire avec votre accès. Bref : moins vous accordez, moins on peut vous prendre.

Et si vous tenez vraiment à saisir la clé dans l’écran ? Bonne nouvelle : depuis le 30 juin 2026, l’extension officielle AI (version 1.1.0) embarque une expérience Key Encryption qui chiffre les clés du connecteur avant de les écrire en base, avec libsodium. C’est du code maintenu par le projet WordPress, pas un greffon trouvé au hasard : si vous devez garder la clé en base, c’est cette option-là qu’il faut activer. Sa limite, à connaître : désactivez l’expérience ou l’extension, et les clés repassent en clair.

Une extension communautaire, Encrypt AI Connector Keys, fait la même chose. Mon avis, après des années à maintenir une extension de sécurité : maintenant que l’officielle existe, le tiers n’a plus de raison d’être. Vous ajouteriez du code externe, donc de la surface d’attaque, pour un besoin déjà couvert par le projet lui-même.

Au bout du compte, quatre situations. Et il faut savoir ce que chacune protège réellement :

Où vit la clé	Ce que ça protège vraiment
Variable d’environnement	La clé sort de la base ET du dépôt de code. Un dump SQL volé ne la contient pas, un dépôt exposé non plus. C’est le meilleur des quatre.
Constante PHP (wp-config.php)	La clé sort de la base. Mais elle peut finir dans une sauvegarde de fichiers, ou dans votre dépôt si vous versionnez wp-config.php.
Chiffrement officiel (expérience Key Encryption)	La clé reste en base, mais chiffrée : une lecture directe du stockage ne donne rien d’exploitable.
Aucun des trois	Rien du tout. La clé est en clair en base, lisible dans n’importe quel dump.

Et le point commun aux quatre, celui qu’il faut avoir en tête avant de se croire tiré d’affaire : aucun ne protège d’une extension déjà compromise. Si du code hostile tourne sur votre site, il n’a pas besoin de lire votre clé : il demande à WordPress d’appeler l’IA pour lui, et c’est vous qui payez. Sortir la clé de la base protège du vol de la clé, pas de son usage. Deux problèmes différents, deux parades différentes.

Et l’approbation par extension, alors ? Elle existe déjà, et ça change la donne depuis la rédaction des premiers guides sur le sujet. Depuis la version 1.0.0 de l’extension officielle AI (19 mai 2026), l’expérience Connector Approvals laisse l’administrateur décider quelle extension a le droit d’accéder à quel connecteur. Elle s’active dans les Experiments : elle n’est pas posée par défaut. Une limite à connaître, et elle compte : ce contrôle identifie l’appelant à travers l’API HTTP de WordPress. Une extension malveillante peut retirer le filtre, ou appeler le fournisseur en direct avec curl sans jamais passer par la case contrôle. Les auteurs la présentent eux-mêmes comme une expérience, pas comme une frontière de sécurité. Une fusion dans le cœur est évoquée pour le cycle 7.1. En attendant, le gardien, c’est encore vous.

Comment surveiller l’IA une fois en production ?

Configurer, c’est bien. Surveiller, c’est ce qui vous prévient avant la facture. Et là, une confusion à lever tout de suite, parce qu’elle traîne partout : ce journal n’est pas dans le cœur de WordPress. Il vient de l’extension officielle AI, maintenue par le projet WordPress mais distribuée à part, qui l’expose dans Outils > AI Request Logs. C’est une expérience à activer (Experiments globaux, puis le bouton AI Request Logging), et elle change tout pour détecter une anomalie.

Chaque appel y est enregistré : le fournisseur, le modèle, la durée, le nombre de jetons, le statut, et surtout la source de la requête, autrement dit si elle vient d’un plugin, d’un mu-plugin, d’un thème ou du cœur. C’est exactement ce qu’il faut pour répondre à la question "qui consomme ma clé, et est-ce normal ?". Un pic en pleine nuit, un modèle que vous n’utilisez pas, une source inattendue : voilà vos signaux d’alerte.

Un détail à connaître : par défaut, ces journaux sont conservés indéfiniment. Sur un site à fort trafic, posez une rétention raisonnable avec le filtre prévu pour ça :

add_filter( 'wpai_request_log_retention_days', function() {
    return 30; // ne garder que 30 jours de journaux
} );

Une fois par mois, je rapproche ces journaux de la facture du fournisseur. Un écart entre les deux, c’est souvent le premier indice d’un usage que vous n’avez pas lancé.

Et si je soupçonne un vol ? Trois signaux ne trompent pas : une facture ou un pic de consommation inattendu, des requêtes en dehors de vos heures de travail, un modèle facturé que vous n’utilisez pas. Le réflexe, dans l’ordre : révoquer la clé chez le fournisseur, en générer une nouvelle, mettre à jour le wp-config, vérifier qui a touché à l’écran Connecteurs, puis scanner le site pour trouver le plugin compromis.

Et le RGPD dans tout ça ?

Brancher une IA, c’est potentiellement envoyer des données personnelles (noms, emails, contenu d’utilisateurs) chez OpenAI, Anthropic ou Google. Donc oui, le RGPD s’invite à la fête. Trois points à ne pas zapper, surtout en agence.

D’abord, une base légale (article 6) : vous devez pouvoir justifier pourquoi cette donnée part chez un tiers, et un simple "c’est dans la politique de confidentialité" ne suffit pas toujours. Ensuite, un contrat de sous-traitance (DPA, article 28) avec le fournisseur dès qu’il traite des données personnelles pour votre compte, ce qui est le cas courant sur un usage WordPress. La CNIL recommande d’ailleurs de qualifier le rôle juridique du fournisseur au cas par cas plutôt que de le présumer. Enfin, le bon réflexe : pas de donnée sensible dans un prompt. Le RGPD en interdit le traitement par principe (article 9, avec des exceptions encadrées), et surtout, une fois la donnée partie chez un tiers, le droit à l’effacement devient très difficile à garantir dans les faits. En cas de manquement, le RGPD prévoit des sanctions jusqu’à 20 millions d’euros ou 4 % du chiffre d’affaires mondial (article 83). Si le sujet vous concerne, mon guide RGPD WordPress détaille la marche à suivre, et une IA auto-hébergée (Ollama, par exemple) reste la façon la plus simple de garder 100 % des données chez vous.

Comment désactiver complètement l’IA de WordPress 7 ?

Pas d’usage IA sur ce site ? Alors ne laissez pas la porte entrouverte. Une seule ligne dans wp-config.php, et c’est plié : wp_supports_ai() renvoie false avant même le chargement des extensions, et le cœur n’enregistre aucun connecteur IA. L’interrupteur général du sous-système IA de WordPress.

define( 'WP_AI_SUPPORT', false );

C’est l’équivalent de débrancher la prise au mur. Il existe aussi un filtre, plus souple mais moins fiable, car une extension chargée à une priorité supérieure peut le contourner :

add_filter( 'wp_supports_ai', '__return_false', 1000 );

Pas à l’aise avec wp-config.php ? Une extension dédiée, Turn Off AI Features, pose le même interrupteur depuis l’admin. Elle est encore très jeune, donc sur un site de production, je préfère la constante. On ne sait jamais.

Et si je masque juste l’écran Connecteurs avec un bout de code ? Mauvaise idée. Cacher le menu ne désactive pas l’API : une extension peut toujours appeler wp_ai_client_prompt() en direct, écran visible ou pas. Masquer l’interface, c’est cosmétique. Seule la constante WP_AI_SUPPORT ferme vraiment cette porte-là. Et soyons précis sur ce qu’elle fait, parce que c’est la nuance qui compte : elle coupe le client IA natif de WordPress et les connecteurs du cœur. Elle n’empêche pas une extension d’embarquer sa propre bibliothèque et sa propre clé pour appeler un fournisseur dans son coin. Ça, seul l’audit de vos extensions le voit.

Ma checklist WordPress 7 + IA

De quoi tout boucler en une session, à garder sous la main avant chaque mise en production :

• Une seule clé IA, dédiée à ce site, nommée explicitement chez le fournisseur.
• Un plafond de dépense actif côté OpenAI / Anthropic / Google.
• La clé en variable d’environnement ou en constante, jamais collée dans l’écran.
• Les prompts réservés aux admins via le filtre wp_ai_client_prevent_prompt.
• Le journal de l’extension officielle AI (Outils > AI Request Logs) activé et relu chaque mois face à la facture.
• Seulement les extensions dont j’ai vraiment besoin, et 2FA sur tous les comptes admin.
• Si aucun usage IA : WP_AI_SUPPORT à false, point final.

L’IA n’est pas le problème, la clé l’est

L’IA dans WordPress n’est pas le danger. Le danger, c’est une clé qui vaut de l’argent posée dans un système dont le modèle de confiance a été pensé bien avant que les sites ne contiennent des moyens de paiement. Traitez cette clé comme un accès bancaire : une par site, plafonnée, sortie de la base, réservée aux admins, et surveillée. Et la 7.0 redevient ce qu’elle devrait être, un bon outil.

Voilà. La semaine prochaine, je reviens sur l’autre face de la pièce : comment j’utilise l’IA dans mon travail sans jamais lui faire confiance aveuglément. Spoiler, c’est possible, mais ça se mérite.

En attendant, si vous voulez être prévenu dès qu’une faille touche un de vos plugins (comme Kirki), j’ai construit un outil pour ça : ma veille sécurité WordPress gratuite scanne vos extensions et vous alerte par email dès qu’une vulnérabilité est publiée. Pour le reste, le socle reste le même qu’avant l’IA : moins d’extensions, tout à jour, et un site bien sécurisé de bout en bout.

Article original sur WPFormation