Audit WordPress par 3 IA : ce qu'elles détectent, ratent et hallucinent

La promesse tourne en boucle sur les réseaux : confiez l’URL de votre plateforme ou une archive de votre thème à un grand modèle linguistique, puis laissez la machine lister vos failles techniques en trente secondes chrono. Fatigué d’entendre des discours théoriques déconnectés de la production, j’ai voulu soumettre l’un de mes propres environnements WordPress — taillé sur mesure, bardé de fonctions custom et hébergé sous Linux — à trois modèles d’intelligence artificielle majeurs : GPT-4o d’OpenAI, Claude 3.5 Sonnet d’Anthropic et Gemini 1.5 Pro de Google.

Le protocole était direct. Pas de prompt alambiqué de copywriter, mais des requêtes d’ingénieur : injection de templates PHP, de requêtes SQL brutes, de dumps d’en-têtes HTTP et de fichiers de configuration serveur. Le résultat oscille entre fulgurances bienvenues sur la syntaxe et hallucinations grotesques sur l’architecture globale.

Quand j’interviens dans l’Oise pour un dépannage urgent ou une refonte site internet chez un artisan ou une PME, le premier réflexe consiste à isoler les goulets d’étranglement réels plutôt que d’empiler des métriques abstraites. Voici ce que ces modèles savent faire, ce qui leur échappe totalement et les pièges qu’ils inventent de toutes pièces.

Le banc d’essai : protocole et données injectées

Pour éviter les biais liés aux thèmes génériques vendus sur ThemeForest, j’ai soumis aux trois modèles le code source d’un site de production réel, développé sans constructeur de page superflu. L’environnement tournait sur une pile LEMP classique avec PHP-FPM, complété par un miroir de test configuré sur un espace mutualisé sous cPanel o2switch pour observer leurs remarques sur des architectures serveur variées.

J’ai fourni à chaque modèle trois blocs d’informations distincts : un dump complet du fichier functions.php contenant des endpoints personnalisés exploitant la WordPress REST API, un export de la structure DOM d’une page d’atterrissage complexe, ainsi qu’une capture d’en-têtes de réponse HTTP incluant les directives de sécurité CSP et HSTS.

Les trois modèles testés face au code source

Chacun de ces moteurs dispose d’une approche distincte face au traitement de texte brut. Claude 3.5 Sonnet brille par sa fenêtre de contexte immense et sa réputation de relecteur de code minutieux. GPT-4o s’affiche comme le généraliste polyvalent aux réponses rapides. Gemini 1.5 Pro, quant à lui, s’appuie sur une capacité d’absorption massive de tokens, idéale pour lui faire ingurgiter plusieurs milliers de lignes sans découpage préalable.

Mon attente n’était pas de recevoir un cours magistral sur les standards PSR, mais d’obtenir un diagnostic pragmatique : failles d’injection SQL non préparées, fuites de mémoire dans les boucles WP_Query, balisage défaillant et erreurs d’en-têtes Apache/Nginx.

Ce que les IA détectent avec une précision chirurgicale

Soyons justes : sur la lecture statique de code pur, certains résultats forcent le respect. Dès lors qu’une fonction native PHP ou une méthode du cœur de WordPress est employée en dépit du bon sens sécuritaire, le verdict tombe sans hésitation.

J’avais sciemment glissé une faille de type XSS réfléchi via un paramètre $_GET injecté sans passer par sanitize_text_field() ni esc_html(). Les trois modèles l’ont isolée en quelques fractions de seconde, fournissant immédiatement le correctif recommandé par le manuel de sécurité officiel de WordPress.

L’analyse syntaxique et les failles OWASP évidentes

Claude 3.5 Sonnet s’est montré particulièrement redoutable sur l’analyse statique des requêtes directes à la base de données via l’objet global $wpdb. Il a immédiatement souligné l’omission d’un appel à $wpdb->prepare() sur une clause WHERE dynamique :

// Extrait soumis au test
$user_input = $_POST['custom_id'];
$result = $wpdb->get_results("SELECT * FROM {$wpdb->prefix}suivi WHERE id = " . $user_input);

// Correction exigée par Claude 3.5 Sonnet
$sanitized_id = absint($_POST['custom_id']);
$result = $wpdb->get_results(
    $wpdb->prepare("SELECT * FROM {$wpdb->prefix}suivi WHERE id = %d", $sanitized_id)
);

Sur ce registre précis, l’IA se comporte comme un excellent linter interactif. Elle repère les variables superglobales manipulées sans filtrage, les nonces CSRF oubliés dans les formulaires d’administration et les fonctions obsolètes dépréciées depuis les versions 6.x du CMS.

La chasse aux faiblesses du balisage sémantique

Autre domaine où les modèles se débrouillent avec les honneurs : l’inspection de l’arbre structurel HTML. En leur soumettant un extrait d’arborescence comportant des incohérences typiques dans les balises hn seo — un saut direct d’une balise H2 vers une balise H4 sans élément intermédiaire —, Gemini et GPT-4o ont immédiatement signalé l’anomalie structurelle.

Ils rappellent avec justesse les recommandations d’accessibilité du W3C concernant les WCAG, insistant sur le contraste colorimétrique insuffisant dans un extrait CSS et sur l’absence d’attributs ARIA sur un bouton de menu accordéon dynamique. Pour un œil non exercé, cette relecture permet de balayer rapidement les oublis d’inattention.

Les angles morts : ce que les algorithmes ne voient jamais

Dès que l’on quitte le confort de l’analyse statique isolée pour aborder le cycle d’exécution dynamique du CMS, les trois modèles calent net. Un fichier PHP WordPress n’est pas un script autonome ; il vit au cœur d’un écosystème complexe d’actions, de filtres, d’ordonnancement de priorités et d’états transitoires en base de données.

Cette incapacité fondamentale à exécuter le moteur PHP en conditions réelles transforme souvent leurs audits de vitesse en un chapelet de conseils génériques sans prise sur le terrain.

Un modèle de langage lit le code comme un poème syntaxique, mais il ignore tout de la friction d’une table wp_postmeta de deux millions de lignes saturée d’autoloads incohérents.

L’ordre d’exécution des hooks et la cascade des filtres

L’une des limites flagrantes concerne la gestion des hooks. J’avais implémenté une fonction greffée sur le hook init qui tentait de modifier une variable dépendante de la requête principale, laquelle n’est instanciée que bien plus tard, au moment du hook wp. Aucun des trois modèles n’a relevé le problème temporel.

Pour eux, le code était syntaxiquement irréprochable et les variables étaient déclarées. Sauf qu’en production, le script renvoyait une valeur nulle silencieuse, sans générer de warning explicite dans le fichier de log de débogage.

La latence réseau et les anomalies de pile serveur

Les modèles aiment réciter les standards de performance : concaténer le CSS, activer la compression Brotli, convertir les images au format AVIF. Pourtant, lorsqu’un site souffre d’un TTFB (Time to First Byte) désastreux de 1 800 millisecondes causé par une boucle de requêtes DNS lentes sur une API externe, l’IA reste aveugle.

Elle ne peut pas interroger le serveur de noms, mesurer les micro-coupures de la couche de transport ni identifier un pool de workers PHP-FPM saturé par des processus zombies. Pour débusquer ces pannes structurelles, seul un audit d’infrastructure manuel mené au terminal permet de démêler la situation.

Les pires hallucinations techniques rencontrées

C’est ici que l’expérience tourne au cauchemar pour qui ne possède pas de bagage technique solide. Confrontés à des bribes d’informations partielles, les modèles n’avouent presque jamais leur ignorance : ils comblent les vides par une imagination débridée.

Sur mon installation de test, Gemini m’a fermement soutenu que la fonction wp_cache_set() que j’utilisais n’était pas supportée nativement par WordPress sans l’installation obligatoire d’une extension payante tierce — inventant au passage le nom d’un plugin fantôme avec un numéro de version totalement fictif.

Des failles imaginaires et des extensions inventées

GPT-4o a poussé l’inventivité encore plus loin en analysant un extrait de code WooCommerce. Il m’a alerté sur une prétendue vulnérabilité critique liée à une fonction de calcul de taxe, affirmant qu’elle violait une directive de sécurité introduite dans WooCommerce 8.9. En consultant la documentation officielle et les commits du dépôt GitHub, cette directive n’a tout simplement jamais existé.

Voici les trois catégories d’hallucinations récurrentes relevées durant mes tests :

• L’invention de hooks inexistants : proposition d’accrocher des scripts à des actions inventées de toutes pièces comme wp_after_query_render ou admin_save_metadata.
• La mauvaise interprétation des réponses 500 : affirmation qu’un code erreur 500 sur un endpoint REST proviendrait systématiquement des permissions de fichiers chmod 755, ignorant totalement un éventuel dépassement de mémoire PHP (memory_limit).
• La prescription de bibliothèques obsolètes : recommandation de charger de vieux polyfills JavaScript pour Internet Explorer sur des thèmes construits avec les standards modernes documentés sur le réseau MDN de Mozilla.

Le piège des faux positifs chronophages

Le risque majeur pour un propriétaire de site réside dans la perte de temps colossale induite par ces alertes fantômes. Passer quatre heures à chercher une fuite mémoire imaginaire signalée par une IA parce qu’elle a mal interprété une boucle foreach imbriquée dégrade la productivité.

Dans mon agence web basée près de Compiègne, je croise régulièrement des clients paniqués par un rapport généré automatiquement par un modèle de langage leur annonçant que leur boutique en ligne est une passoire intégrale, alors que leur socle technique est parfaitement sain.

Comment utiliser l’IA intelligemment sur votre parc WordPress

Faut-il pour autant jeter ces outils aux orties ? Certainement pas. Ils constituent de formidables accélérateurs d’audit, à condition de délimiter strictement leur périmètre d’action et de ne jamais les laisser poser un diagnostic global sans supervision humaine.

L’IA doit servir d’assistant de relecture ponctuel, pas de directeur technique. Utilisée pour reformuler une requête complexe, commenter un script hérité ou générer des squelettes de tests unitaires, elle apporte un gain de productivité indéniable.

Le prompt idéal pour contraindre le modèle

Pour limiter la dérive créative des modèles, il faut restreindre drastiquement leur liberté de ton et leur périmètre d’affirmation. J’applique désormais une règle simple : interdire aux modèles de spéculer sur ce qui n’est pas directement présent dans l’extrait de code fourni.

En leur ordonnant de citer précisément le numéro de ligne fautif et le standard officiel enfreint (avec extrait du Codex WordPress à l’appui), le taux de fabulation chute immédiatement de moitié. L’outil redevient alors ce qu’il sait faire de mieux : une calculatrice de motifs syntaxiques.

Foire Aux Questions (FAQ)

Déléguer l’évaluation de la santé de son site à un modèle linguistique sans posséder les clés pour filtrer ses élucubrations revient à confier la révision de son moteur à quelqu’un qui n’aurait lu que le manuel d’utilisation sans jamais ouvrir un capot. L’outil gagne en pertinence lorsqu’il est piloté avec rigueur, mais la réalité d’un écosystème WordPress en production impose toujours de garder les mains dans le cambouis.