J’ai fait auditer mon site WordPress par 3 modèles d’IA : ce qu’ils trouvent, ratent et inventent

"Bonjour Fabrice !" n’avait rien d’une prouesse : mon prénom, WPServeur et mes plugins sont des informations publiques. Gemini m’a ensuite félicité pour des "100/100 PageSpeed historiques" sans citer la moindre source, puis a proposé des réglages de performance sans vérifier qu’ils correspondaient à ma stack. Le ton était sûr. Les preuves, beaucoup moins.

On me répète depuis des mois qu’un audit WordPress, en 2026, ça se résume à coller son URL dans une IA et à lire la réponse. Gratuit, instantané, pas besoin de prestataire. Alors j’ai voulu vérifier. J’ai pris mon propre site, écrit un seul prompt et lancé trois tâches successives le même jour par le même intermédiaire. Puis j’ai vérifié les affirmations avec des outils qui mesurent au lieu de deviner. Ce n’est pas le même exercice que mon agent d’audit SEO branché sur des outils de mesure : ici, aucun outil de mesure, seulement trois modèles qui répondent à un prompt avec leur recherche web.

La partie intéressante n’est pas ce que les IA ont trouvé. C’est ce qu’elles ont inventé, et la facilité déconcertante avec laquelle elles l’ont fait. Parce que la vraie info utile, ici, ce n’est pas la liste des "problèmes". C’est de voir précisément où une IA hallucine un défaut qui n’existe pas, du même ton calme et compétent que pour le reste.

Le protocole : même site, même prompt, trois IA

Mon protocole contrôlait le prompt, le jour, la limite de sortie et l’intermédiaire. Il ne contrôlait ni les moteurs de recherche utilisés par chaque modèle, ni les requêtes générées, ni la quantité de contexte récupérée. Ce n’est donc pas un test parfaitement symétrique. Voici le prompt exact :

Peux-tu auditer mon site WordPress https://wpformation.com ? Liste-moi les problèmes techniques, SEO et de performance que tu détectes, avec des recommandations concrètes.

Et là, premier piège. Mon site est headless, une architecture dont j’ai tiré un bilan après sept mois en production. Le WordPress qui me sert d’arrière-boutique tourne sur un sous-domaine séparé, et la façade publique est servie par Next.js. Quand je demande d’auditer "mon site WordPress" depuis l’adresse publique, le modèle ne voit ni la version de PHP, ni la liste des extensions, ni le thème du backend.

C’est exprès, et c’est représentatif. Parce qu’un propriétaire lambda ne sait pas non plus ce qu’une IA voit réellement de son site. Il imagine qu’elle "regarde" son installation comme un développeur connecté à l’admin. Elle ne fait rien de tel. Elle lit des informations publiques et peut compléter ce qui manque avec des scénarios fréquents. On l’oublie trop souvent… et ça change absolument tout pour la suite.

En face des sorties, j’ai utilisé une vérité-terrain datée : capture Lighthouse de laboratoire, Search Console, HTML public et configuration connue du site. Le mot "datée" compte : une mesure du 5 juin ne devient pas une vérité éternelle sur le site.

Les trois tâches sont passées par ai_optimization / llm_responses chez DataForSEO, avec recherche web activée et 4 000 tokens de sortie au maximum. Les modèles exacts étaient gpt-5.3-chat-latest, gemini-3.5-flash et claude-sonnet-4-6. Le modèle OpenAI utilisé était déjà annoncé comme déprécié depuis le 8 mai, et OpenAI l’a retiré de son API le 10 août. J’ai donc rejoué le test le 24 septembre avec des modèles plus récents : les résultats sont plus bas.

J’ai conservé les réponses et leurs métadonnées pour mon contrôle interne. Le dossier public du benchmark contient les trois transcriptions complètes, le protocole, la classification corrigée et les sources publiques. Les réponses JSON du prestataire, les identifiants de tâches, les coûts, les compteurs de tokens et les données privées du site en sont volontairement exclus.

Ce que ce test ne prouve pas : il ne classe pas définitivement OpenAI, Google et Anthropic. Il compare trois sorties historiques, sur un site volontairement atypique, avec un prompt, un jour et un intermédiaire donnés. Changez un seul de ces paramètres et le résultat peut changer.

Le modèle OpenAI : beaucoup de mots, presque aucun fait

La sortie de gpt-5.3-chat-latest était la plus rassurante en apparence. Le souci apparaît à la relecture ligne par ligne : elle contient surtout des hypothèses. Beaucoup de JavaScript, polices "probablement" non optimisées, images "probablement" perfectibles. Quand chaque point avance masqué derrière un "probablement", ce n’est pas un audit. C’est une liste de pistes.

Un exemple net. Il me conseille de "self-host les fonts", au cas où ce seraient des Google Fonts qui ralentissent le rendu. Sauf que mes polices sont déjà self-hostées, chargées en local par Next.js, préchargées, zéro appel à Google. Vérifiable en dix secondes dans le code source. Il a deviné un problème classique de WordPress… et il est tombé à côté de la plaque.

Est-ce que ce genre de conseil peut nuire ? Rarement, et c’est tout le problème : il ne sert à rien non plus. Deuxième faux positif, plus parlant : "ajouter schema.org (Person + Organization)". Or ma page d’accueil sert déjà plusieurs types de données structurées, dont Person et Organization, en JSON-LD. Il me recommande d’ajouter ce qui est déjà là. Le pire conseil n’est pas le faux, c’est celui qui rassure un débutant en pointant un élément présent.

Le reste, c’est du conseil d’agence en pilote automatique. "Ta home dilue ton message", "choisis une seule intention", "réduis le contenu de 30 à 40 %". ChatGPT conclut même par un compliment révélateur :

Ton site est déjà au-dessus de 90 % des sites WordPress. (…) Le vrai problème n’est pas technique pur, c’est la dilution.

De l’opinion UX générique qui s’appliquerait à la moitié des sites de la planète. Bref. Ça ne casse rien, ça n’apprend presque rien, et cette sortie n’a jamais remarqué que le site public n’est pas rendu par WordPress.

Gemini 3.5 Flash : des conseils précis sans preuve correspondante

Gemini formule des recommandations très précises, ce qui impressionne à la première lecture. Mais la précision d’une phrase n’est pas une preuve. Certaines informations sont justes et publiques, d’autres sont des conseils génériques, et plusieurs diagnostics portent sur des éléments impossibles à observer depuis la façade du site. C’est ce mélange sans étiquette qui pose problème.

Affirmation ou conseil de Gemini	Classement corrigé
Le fichier llms.txt est présent	Vérifié publiquement
WPS Cleaner est l’un de mes plugins et je connais WPServeur	Contexte public correct
La base contient forcément des milliers de données orphelines	Diagnostic non vérifiable depuis le site public
Passer sous PHP 8.2 ou 8.3	Recommandation générique, pas détection de la version active
Utiliser WP Rocket ou Perfmatters pour le LCP	Exemples d’outils, cause du LCP non démontrée
Architecture headless	Non détectée

Il me détaille d’abord comment exclure mon image à la une du lazy loading. Je cite :

Excluez explicitement l’image mise en avant du lazy loading via vos réglages d’optimisation comme WP Rocket ou Perfmatters.

Il continue dans le même registre : "assurez-vous que WPFormation tourne sous PHP 8.2 ou 8.3". Ce n’est pas une affirmation sur la version active. C’est une recommandation générique, formulée sans pouvoir voir la configuration du serveur. Elle ne prouve donc aucun problème. Puis vient un conseil qui tombe sur mon terrain, le SEO : structurer mes FAQ en données structurées "FAQPage ou HowTo" pour être mieux cité par les moteurs.

Le problème ? Google avait déprécié les résultats enrichis HowTo depuis 2023, puis cessé d’afficher les résultats enrichis FAQ le 7 mai 2026. Mais Gemini parlait ici d’extraction par les LLM, pas d’un résultat enrichi Google. Je ne peux donc pas classer ce conseil comme faux ou nuisible. Je peux seulement constater qu’aucune preuve fournie dans la réponse ne démontre que ce balisage rend une source prioritaire pour les IA. C’est une hypothèse GEO, pas un diagnostic du site. J’ai détaillé ce que Google recommande réellement dans ma lecture de son guide sur le référencement par les IA.

Correction importante : quand Gemini parle de "votre propre plugin WPS Cleaner" et de "WPServeur que vous connaissez par cœur", ces deux éléments ne sont pas des hallucinations. J’ai fondé WPServeur en 2015 et WPS Cleaner fait partie des plugins que j’ai créés et publiés avec leurs différents contributeurs. La fiche WordPress.org de WPS Cleaner affiche NicolasKulka dans le champ auteur, puis WPServeur et wpformation parmi les contributeurs. Ce champ ne tranche pas à lui seul toute l’histoire du plugin.

Le vrai problème est plus subtil : Gemini mélange des informations biographiques trouvées sur le web à des suppositions techniques, sans marquer la couture entre les deux. Il peut avoir raison sur mon parcours et, dans la phrase suivante, avancer un état de la base qu’il n’a jamais observé. Et il rate l’architecture headless.

Claude Sonnet 4.6 : le seul à identifier le headless

Claude est le seul des trois à avoir regardé le bon site. Sa toute première observation :

Le site a migré vers une architecture headless début 2026 (WordPress en backend, Next.js en frontend).

Exact. Là où les deux autres sorties supposaient un WordPress classique, Claude a identifié la pile technique grâce aux informations publiques trouvées pendant sa recherche. Il terminait aussi par une limite claire : sans Search Console, GA4 ni crawl complet, son audit restait incomplet. Cette prudence est bienvenue. Elle ne transforme pas pour autant la réponse en audit technique.

Alors, sans faute ? Non. Claude a son propre travers, plus subtil et plus piégeux. Il a régurgité mes propres chiffres marketing comme s’il s’agissait de ses trouvailles : "score SEO passé de 68 à 86", "sessions organiques +174 %", "trafic IA +300 %". Ces chiffres sont les miens, publiés dans mes articles. Il me les ressert dans un audit censé être indépendant, sans jamais vérifier s’ils sont encore d’actualité. Il ne ment pas. Il confond "auditer un site" et "résumer ce que le site dit de lui-même".

À son crédit, il glisse une vraie statistique, sourcée et vérifiable : le rapport Patchstack publié en 2024 indique que, dans ses données 2023, 97 % des nouvelles vulnérabilités concernaient des plugins, 3 % des thèmes et 0,2 % le cœur. C’est juste, pour 2023. Mais le rapport 2026 de Patchstack, publié le 25 février, trois mois avant le test, recensait déjà 11 334 failles pour 2025, dont 91 % dans les extensions : le modèle citait l’édition d’il y a deux ans. Et même à jour, une statistique sectorielle exacte, plaquée sur mon site sans rien y mesurer, ce n’est toujours pas un audit de mon site. Et il finit par me conseiller de "désactiver les archives par date et par auteur, mettre les tags en noindex"… des réglages WordPress classiques qui n’ont aucun sens sur une façade Next.js où ces archives ne sont même pas servies. Il a vu la bonne architecture, puis a appliqué le mauvais manuel.

Le vrai audit : ce que les outils mesurent

Trois sorties, trois portraits incomplets. Voici la capture Lighthouse mobile utilisée dans ma grille de contrôle le 5 juin 2026. Elle donne une mesure de laboratoire datée sur deux URLs, pas les Core Web Vitals terrain de tous les visiteurs.

Métrique Lighthouse mobile	Accueil	Article long
LCP	2,6 s	3,0 s
CLS	0,065	0,001
TBT	10 ms	40 ms

Lecture honnête : cette capture montrait un LCP mobile légèrement au-dessus du seuil de 2,5 secondes, avec un CLS et un TBT corrects sur ces passages. Elle ne justifiait pas mon ancien "TTFB de 10 à 20 ms". Et elle ne disait pas tout : sur les 28 jours qui se terminent le 6 juin, les données que Chrome collecte chez les vrais visiteurs (le rapport CrUX, pour l’ensemble du site) donnaient un LCP mobile de 1,43 seconde au 75e percentile, donc sous le seuil que le laboratoire dépassait. Même décalage pour le temps de réponse : une centaine de millisecondes depuis mon poste (médiane de 104 ms sur dix requêtes le 5 septembre), autour de 450 ms chez les visiteurs mobiles en septembre.

Et c’est là que ça devient instructif. Les modèles ont évoqué le LCP sans pouvoir le mesurer dans cette tâche, puis l’ont relié à des causes génériques : WP Rocket, Google Fonts ou DOM trop lourd. Certaines de ces causes étaient objectivement absentes. Cela ne prouve pas qu’elles hallucineront toujours. Cela prouve que, sur ce test, elles ont proposé des remèdes avant d’établir le diagnostic.

Côté SEO, deux sorties annonçaient un taux de clic à améliorer, l’une par les titres, l’autre par les méta descriptions, sans avoir accès à ma Search Console. C’est le défaut méthodologique suffisant : depuis l’URL publique, on lit les titres et les méta descriptions, on ne mesure pas leur taux de clic. Les données privées servent à confirmer ou infirmer l’hypothèse, pas à donner rétrospectivement raison au modèle.

Le match en un coup d’œil

Trois modèles, même site public, même prompt, même jour et même intermédiaire. Pas les mêmes recherches, pas le même contexte, et trois façons différentes d’échouer.

Point contrôlé	Modèle OpenAI	Gemini	Claude
Détecte le headless	Non	Non	Oui
Repère llms.txt	Non mentionné	Oui	Oui
Sépare clairement fait et hypothèse	Partiellement	Non	Partiellement
Reconnaît les limites de l’exercice	Non	Non	Oui
Défaut principal	Hypothèses génériques	Précision sans vérification	Résumé public présenté comme audit

Le modèle OpenAI échoue par le brouillard : il enrobe et suppose. Gemini échoue par le mélange : des faits publics exacts, des hypothèses techniques et des conseils génériques sont présentés au même niveau. Claude est le plus lucide sur ses limites et le seul à voir le headless, mais il transforme encore des informations publiques du site en résultats d’audit. Aucun n’a remplacé l’œil d’un humain qui sait où regarder.

Quatre mois plus tard, j’ai relancé le test

Un test daté vieillit vite, et celui-ci reposait sur un modèle déjà retiré. Le 24 septembre, j’ai donc renvoyé exactement le même prompt, par le même intermédiaire et avec les mêmes réglages, à trois modèles plus récents : gpt-5.6-sol, le remplaçant qu’OpenAI désigne lui-même pour le modèle de juin, gemini-3.8-flash et claude-sonnet-5. J’ai ajouté deux témoins, les deux modèles de juin encore disponibles : gemini-3.5-flash et claude-sonnet-4-6. Comme en juin, j’ai fixé la vérité-terrain avant de lire la moindre réponse.

Modèle, 24 septembre	Voit le headless	Ce qu’il a fait
GPT-5.6 Sol	Non	Cite ses pages, sépare ce qu’il a vu de ce qu’il faut vérifier, refuse d’inventer un score. Un vrai défaut trouvé, trois problèmes tirés d’un index périmé.
Gemini 3.8 Flash	Non	Des risques génériques présentés comme des problèmes identifiés, et une stack d’hébergement supposée sans preuve.
Claude Sonnet 5	Non	Refuse l’exercice sans chercher sur le web, propose une méthode.
Gemini 3.5 Flash (témoin)	Oui, contre non en juin	Part de la bonne architecture, puis "détecte" des défauts qu’il ne peut pas observer.
Claude Sonnet 4.6 (témoin)	Oui, comme en juin	Même profil qu’en juin : la bonne architecture, puis le manuel WordPress classique.

Le résultat le plus instructif vient du témoin. Le 5 juin, Gemini 3.5 Flash ne voyait pas le headless. Le 24 septembre, le même modèle, avec le même prompt, ouvre son audit sur "ce site n’est pas un site WordPress classique". Rien ne garantit que le service derrière ce nom n’a pas bougé, mais mon hypothèse est ailleurs : c’est ce que le web raconte de mon site qui a changé, avec quatre mois d’articles de plus sur la migration et le headless. Un seul passage ne suffit pas à le prouver, mais l’hypothèse rejoint ce que Claude montrait déjà en juin : ces outils résument ce que le web dit d’un site, ils ne l’observent pas.

GPT-5.6 Sol est le seul des cinq à m’avoir appris quelque chose. Il a remarqué que les six cartes "Pourquoi WPFormation" de ma page d’accueil se lisaient dans l’ordre 1, 4, 2, 5, 3, 6. J’ai vérifié dans le code : les cartes y étaient rangées dans cet ordre, puis replacées à l’écran par la mise en page. Un lecteur d’écran, lui, les annonçait dans le désordre. Vrai défaut d’accessibilité, que je n’avais pas vu : je l’ai corrigé le soir même. Dans la même réponse pourtant, trois "problèmes" sortaient d’un index périmé : un PDF de 2014 déjà supprimé, une ancienne adresse de contact déjà redirigée, un décompte d’articles qui n’était plus à jour. Même ton, même assurance.

Claude Sonnet 5 a pris le parti inverse : "Je ne suis pas en mesure d’auditer directement votre site en temps réel." Aucune recherche lancée, une méthode proposée à la place. C’est honnête, et ce n’est pas un audit. Gemini 3.8 Flash a déroulé des risques génériques sous l’intitulé "problèmes identifiés" et m’a supposé hébergé sur une "stack optimisée type WPServeur", sans la moindre preuve : WPServeur n’héberge pas ce site. Il m’a aussi recommandé FAQPage parmi des "schémas riches", sans dire ce que ce balisage apporterait à mon site. Google n’affiche d’ailleurs plus les résultats enrichis FAQ depuis le 7 mai.

Ce second passage ne renverse rien. Les modèles progressent surtout dans la manière de présenter leurs doutes : aucun des trois nouveaux n’a vu le headless, et le meilleur a glissé un vrai défaut au milieu de trois faux. Côté mesures, même décalage qu’en juin : 2,55 secondes de LCP pour le laboratoire sur l’accueil, 1,8 seconde chez les vrais visiteurs mobiles. Une ligne d’audit produite par une IA devient un diagnostic quand vous l’avez reproduite, pas avant.

Pourquoi une IA invente un problème qui n’existe pas

Un modèle de langage produit une réponse probable à partir du prompt, de son contexte et, ici, des résultats que son outil de recherche lui a fournis. Si les preuves manquent, il peut compléter les trous avec les motifs fréquents d’un audit WordPress : cache, wp_options, PHP ou données structurées. L’intermédiaire, le moteur de recherche et le prompt participent aussi au résultat. La cause ne se résume donc pas à "l’IA complète du texte", même si ce mécanisme reste au coeur de la génération.

La navigation web aide, mais elle ne corrige pas le réflexe de fond. Le modèle reste une machine à plausible, pas une machine à vrai. Et le vrai danger est là : l’hallucination n’a pas l’air d’une erreur. Elle a exactement le même ton posé, structuré, compétent que le diagnostic correct juste au-dessus. Rien, dans la forme, ne vous signale le moment où la machine est passée du fait à la fiction.

Et c’est là que ça devient un business. Cette assurance fabriquée, des gens la revendent. J’ai vu passer des "audits WordPress" facturés en bonne et due forme qui ne sont qu’un copier-coller de sortie d’IA : les mêmes problèmes inventés, les mêmes plugins recommandés à des sites qui ne les utilisent pas. C’est un sujet à part entière, que je traite ailleurs sur le blog : l’anatomie d’un faux audit facturé et comment le repérer avant de signer.

Alors, un prompt peut-il remplacer un audit WordPress ?

Une IA peut-elle auditer votre WordPress à votre place ? Non. Mais elle peut être un bon copilote, à une condition : que vous sachiez déjà vérifier ce qu’elle avance. Comme assistant de brainstorming, elle vous sort des pistes en trente secondes. Comme verdict, elle vous fait nettoyer une base qui ne ralentit rien et installer un plugin de cache sur un site qui n’en a pas besoin. Toute la différence tient dans votre capacité à trancher entre les deux.

Pour une méthode qui tient debout, j’ai documenté mes treize points de contrôle d’un audit WordPress express, avec un cas réel à l’appui. Et quand le souci n’est pas un manque mais un vrai bug, c’est une autre discipline : voici comment déboguer méthodiquement un site WordPress sans tirer au hasard. Le point commun des deux ? On observe avant de conclure. Et si vous préférez qu’un humain s’en charge, mon audit WordPress à l’heure commence précisément par ce que les trois modèles n’ont pas pu voir : le serveur, les extensions et la Search Console.

Je ne dis pas que l’IA est nulle, loin de là. Je m’en sers tous les jours, avec des règles qui m’empêchent de lui faire confiance par défaut, et être co-créateur de WPS Hide Login ne m’a jamais empêché d’apprécier un bon copilote. Une réponse confiante n’est pas une réponse vérifiée. La compétence qui prend de la valeur en 2026, c’est de repérer l’instant où le fait devient une supposition.

Sources et pièces du test

• Dossier public du test du 5 juin : transcriptions complètes, protocole, classification corrigée et sources publiques.
• Historique officiel des changements Google Search sur la disparition des résultats enrichis FAQ.
• Annonce Google sur la dépréciation des résultats HowTo.
• Parcours public de Fabrice Ducarme : WPServeur et historique des plugins WPS.
• Fiche officielle WPS Cleaner : auteur affiché et liste des contributeurs.