Désactiver les fonctionnalités IA de WordPress (cœur ou extension, sans détour)

Presque toutes les fonctionnalités IA que l’on cherche à supprimer dans WordPress viennent d’une extension, d’un hébergeur ou de WordPress.com — pas du cœur auto-hébergé. Avant de coller un extrait remove_action dans functions.php, ouvrez votre liste d’extensions et trouvez ce qui affiche réellement ce panneau IA : retirer une fonctionnalité que le cœur ne fournit pas, c’est beaucoup d’énergie perdue sur un site qui dysfonctionne déjà.

Cette distinction compte, parce que les correctifs n’ont rien à voir entre eux. Une fonctionnalité d’extension possède un réglage. Une fonctionnalité injectée par l’hébergeur se trouve dans son tableau de bord, pas dans votre administration WordPress. Et la vraie question derrière « désactiver l’IA » — empêcher les entreprises d’IA d’entraîner leurs modèles sur vos articles — n’est pas un réglage WordPress du tout. C’est une affaire de robots et de configuration serveur.

Ce qui vient du cœur et ce qui n’en vient pas

Le cœur de WordPress auto-hébergé ne fournit aucun assistant de rédaction IA, chatbot IA ou générateur d’images IA activé d’origine. Si vous voyez une icône IA scintillante dans l’éditeur de blocs, c’est que quelque chose l’a installée.

D’où viennent réellement les fonctionnalités IA :

Source	Fonctionnalité typique	Où la désactiver
Jetpack	Bloc et panneau Assistant IA dans l’éditeur	Réglages Jetpack, activation du module
Extensions IA dédiées	Générateurs de contenu, chatbots, rédacteurs de textes alternatifs	L’écran de réglages de l’extension
Extensions SEO	Suggestions IA de titres et de méta-descriptions	Réglages de l’extension, généralement fonctionnalité par fonctionnalité
Constructeurs de pages	Génération IA de textes et d’images dans l’interface du constructeur	Réglages du constructeur ou panneau de compte
Hébergeurs infogérés	Assistants IA injectés via un mu-plugin ou le tableau de bord	Panneau de contrôle de l’hébergeur
WordPress.com	Outils de rédaction IA hébergés	Réglages du compte WordPress.com, pas ceux de votre site

Le projet WordPress mène bien des développements liés à l’IA — des extensions expérimentales qui finiront peut-être dans le cœur. Si vous êtes sur une version récente et que vous voyez quelque chose d’orienté IA que vous n’arrivez à rattacher à aucune extension, vérifiez d’abord votre liste d’extensions installées, puis le journal des modifications de votre version, plutôt que de supposer un réglage par défaut du cœur à neutraliser. Cette prudence est volontaire : les affirmations liées à une version précise vieillissent très vite dans ce domaine, et une information erronée vous fait modifier des fichiers pour rien.

Trouver ce qui l’ajoute réellement

Désactivez vos extensions par lots jusqu’à ce que le panneau IA disparaisse. C’est rudimentaire, mais cela donne une réponse certaine plutôt qu’une intuition.

Si vous avez WP-CLI, commencez par lister ce qui est actif :

wp plugin list --status=active --field=name

Vérifiez ensuite le code injecté par l’hébergeur, qui n’apparaît pas dans l’écran habituel des extensions :

ls -la wp-content/mu-plugins/

Les extensions « must-use » se chargent automatiquement et ne peuvent pas être désactivées depuis l’administration. Si votre hébergeur y a déposé un assistant IA, la seule suppression propre passe par son panneau de contrôle : supprimer le fichier le fait souvent réapparaître à la prochaine mise à jour de la plateforme.

Désactiver proprement

Utilisez le réglage prévu par l’extension. C’est la réponse ennuyeuse, et c’est la bonne. Jetpack en particulier repose sur des modules activables indépendamment : vous pouvez couper l’Assistant IA tout en gardant les statistiques, les sauvegardes ou ce dont vous dépendez. La plupart des extensions IA dédiées proposent une case à cocher par fonctionnalité.

Si vous ne vous servez de l’extension pour rien d’autre, désactivez-la entièrement. Une extension IA laissée installée mais « désactivée » dans ses réglages charge quand même son code à chaque requête. La désactiver est plus rapide, plus sûr et mesurablement plus léger que n’importe quel filtre.

Décrocher un hook avec remove_action est un dernier recours. Cela fonctionne réellement, mais seulement si vous connaissez le nom exact du hook, le callback et la priorité enregistrés par l’extension, et seulement jusqu’à ce qu’elle en renomme un :

// Only if you have verified the exact hook, callback and priority.
// Runs late so the plugin has already registered its own hooks.
add_action( 'init', function () {
    remove_action( 'enqueue_block_editor_assets', array( 'Some_Plugin_Class', 'enqueue_ai_panel' ), 10 );
}, 99 );

Le coût réel : cette approche casse en silence. Une mise à jour change le nom de la classe, votre suppression ne correspond plus, le panneau IA revient, et aucune erreur ne vous prévient. Si vous employez cette méthode, notez ce que vous avez retiré et revérifiez après chaque mise à jour de l’extension concernée.

La même prudence vaut pour le désenregistrement de panneaux d’éditeur en JavaScript. C’est une possibilité réelle, mais vous allez chercher l’enregistrement d’une autre extension par son identifiant textuel, et cet identifiant n’est pas un contrat public.

N’essayez pas de bloquer des fonctionnalités IA en modifiant des constantes wp-config.php trouvées sur un forum. Aucune constante du cœur ne coupe l’IA d’une extension tierce. Si un extrait prétend le contraire et que vous ne retrouvez pas la constante dans la documentation de l’extension, il ne fait rien.

L’autre question : empêcher l’entraînement des IA sur vos contenus

C’est un sujet distinct, et c’est là que se concentre l’essentiel de l’inquiétude. Couper un panneau dans l’éditeur ne change rien à qui explore vos articles. Cela se règle dans robots.txt et, si vous voulez que ce soit contraignant, au niveau du serveur.

WordPress sert un robots.txt virtuel tant qu’aucun fichier réel n’existe à la racine web. Si un fichier physique est présent, WordPress s’efface complètement et c’est ce fichier que reçoivent les robots. Pour modifier la version virtuelle, filtrez-la :

add_filter( 'robots_txt', function ( $output ) {
    $output .= "\nUser-agent: GPTBot\nDisallow: /\n";
    return $output;
}, 10 );

C’est en construisant les règles à la main que les erreurs arrivent : un jeton mal orthographié ne bloque rien, et un Disallow: / égaré sur le mauvais agent peut vous sortir de la recherche classique. Le générateur de robots.txt assemble les blocs de robots IA avec vos directives de recherche habituelles, pour que vous voyiez le fichier complet avant sa mise en ligne.

Les jetons publiés par les grands acteurs et qu’ils déclarent honorer :

Jeton	Acteur	Ce qu’il couvre
GPTBot	OpenAI	Exploration destinée à l’entraînement des modèles
ChatGPT-User	OpenAI	Requêtes déclenchées par la demande d’un utilisateur
ClaudeBot	Anthropic	Exploration
Google-Extended	Google	Usage de vos contenus pour l’entraînement de Gemini, pas l’exploration elle-même
Applebot-Extended	Apple	Usage pour l’entraînement des modèles génératifs d’Apple
PerplexityBot	Perplexity	Exploration
CCBot	Common Crawl	Archive massive sur laquelle s’entraînent de nombreux modèles

Deux réserves honnêtes. D’abord, robots.txt repose sur le volontariat : les acteurs sérieux le suivent, tout ce qui veut l’ignorer l’ignorera. Ensuite, bloquer n’est pas gratuit. Certains de ces jetons déterminent votre présence dans des réponses générées par IA qui vous citent et vous envoient des visiteurs. Tout bloquer, c’est perdre cette source de trafic en même temps que l’exposition à l’entraînement. Décidez de ce qui compte vraiment pour vous.

Pour une contrainte réelle plutôt qu’une demande polie, bloquez au niveau du serveur. Dans le fichier .htaccess sous Apache :

<IfModule mod_setenvif.c>
  SetEnvIfNoCase User-Agent "GPTBot|CCBot|ClaudeBot|PerplexityBot" ai_bot
  <RequireAll>
    Require all granted
    Require not env ai_bot
  </RequireAll>
</IfModule>

Les chaînes user-agent se falsifient sans effort : cela arrête le trafic honnête mais indésirable, pas un aspirateur déterminé. Le blocage par plage d’adresses IP vérifiées sur votre CDN ou votre pare-feu est plus solide, et la plupart des CDN proposent désormais une règle anti-robots IA en un clic, bien plus facile à maintenir qu’une liste écrite à la main.

Ce qui ne fonctionne pas

llms.txt est une proposition, pas un standard. C’est un fichier markdown censé décrire votre site aux modèles de langage. Aucun grand acteur ne s’est engagé à le traiter comme un contrôle d’accès. L’ajouter ne coûte rien et peut aider à la façon dont les modèles vous lisent, mais cela ne bloque rien.

Les balises meta noai et noimageai ne sont honorées par presque personne. Elles sont issues de la politique d’une seule plateforme, pas d’un accord sectoriel. Les ajouter n’est pas nuisible ; compter dessus l’est.

Une extension qui promet de « bloquer l’IA » se contente généralement d’écrire des règles robots. C’est très bien, et c’est exactement ce que vous pouvez faire vous-même en dix lignes. Ce n’est ni une barrière juridique ni une barrière technique, et aucune extension ne peut en faire une.

Bloquer les robots IA ne retire pas les contenus déjà présents dans un modèle entraîné. Rien de ce que vous ajoutez aujourd’hui ne sort rétroactivement vos articles d’un modèle publié l’an dernier. Les règles robots ne valent que pour l’avenir.

Le panneau IA est toujours là

Si toutes les extensions sont désactivées et que le panneau persiste, revérifiez wp-content/mu-plugins/, puis le tableau de bord de votre hébergeur, puis si vous n’êtes pas sur WordPress.com plutôt qu’en auto-hébergé — les réglages s’y trouvent dans les paramètres du compte, pas dans l’administration du site. Et si la fonctionnalité revient après une mise à jour d’extension, c’est la signature typique d’un extrait de décrochage de hook qui ne correspond plus, pas d’un réglage par défaut du cœur.