Le blog technique d’un éditeur de thème WordPress publie régulièrement des tutoriels générés en première version par IA puis retravaillés par un rédacteur. Le risque le plus redouté sur ce type de contenu n’est pas une maladresse de style, mais une fonction ou un hook mentionné qui n’existe tout simplement pas, ou dont la signature est erronée.
Sur un échantillon de contrôle de 60 brouillons non encore vérifiés, notre relecture manuelle a trouvé qu’environ une fonction citée sur douze n’existait pas telle quelle, ou existait sous un nom légèrement différent. Plutôt que de compter uniquement sur la vigilance humaine, nous avons ajouté une étape de vérification automatique avant chaque publication.
Étape 1 : extraire les fonctions et hooks mentionnés
Une expression régulière repère, dans le contenu de l’article, tout ce qui ressemble à un appel de fonction PHP entre balises <code>, ainsi que les noms suivant les conventions habituelles des hooks WordPress (préfixes verbaux, underscores).
preg_match_all(
'/<code>([a-z_][a-z0-9_]*)\s*\(/i',
$contenu_article,
$matches
);
$fonctions_citees = array_unique( $matches[1] );
Étape 2 : croiser avec une liste de référence locale
Plutôt que d’interroger le Code Reference en direct à chaque vérification, ce qui serait lent et fragile, nous maintenons un export local des noms de fonctions et hooks du cœur de WordPress, régénéré périodiquement depuis les fichiers sources officiels via un script d’extraction basé sur les commentaires PHPDoc du projet.
$fonctions_reconnues = require __DIR__ . '/donnees/fonctions-core-wordpress.php';
$fonctions_suspectes = array();
foreach ( $fonctions_citees as $fonction ) {
if ( ! in_array( $fonction, $fonctions_reconnues, true )
&& ! function_exists( $fonction ) ) {
$fonctions_suspectes[] = $fonction;
}
}
La condition function_exists() permet aussi de couvrir les fonctions ajoutées par des extensions tierces courantes déjà chargées dans l’environnement de test, en complément de la liste du cœur.
Étape 3 : afficher un score de confiance avant publication
Le résultat de cette vérification s’affiche dans une méta-boîte sur l’écran d’édition, sous la forme d’une liste des fonctions suspectes accompagnée d’un lien direct vers une recherche sur le Code Reference officiel (developer.wordpress.org), pour que le rédacteur tranche rapidement s’il s’agit d’une véritable erreur ou d’un faux positif du script.
- Fonction reconnue dans le cœur ou une extension chargée : validée automatiquement
- Fonction absente de la liste de référence : signalée en rouge, lien de vérification fourni
- Le statut de publication reste bloqué tant qu’un rédacteur n’a pas traité chaque alerte
Les faux positifs à anticiper
Ce système génère aussi de faux positifs, notamment pour des fonctions issues d’extensions tierces peu répandues absentes de notre environnement de test, ou pour des exemples volontairement fictifs illustrant une convention de nommage. Sur les six premiers mois d’usage, environ 30 % des alertes se sont révélées être des faux positifs, un taux que le rédacteur apprend rapidement à trier en quelques secondes par alerte.
Un script de vérification qui bloque la publication tant qu’un humain n’a pas tranché chaque alerte vaut mieux qu’un script qui corrige silencieusement, au risque de faire disparaître une vraie fonction rare.
Ce que ce contrôle ne détecte pas
Cette vérification porte uniquement sur l’existence des fonctions citées, pas sur l’exactitude de leur usage. Un article peut citer une fonction bien réelle mais avec des paramètres incorrects, ou l’utiliser dans un contexte inapproprié, ce que seule une relecture technique humaine permet de repérer.
En résumé
Croiser automatiquement les fonctions citées dans un brouillon généré par IA avec une liste de référence du cœur WordPress réduit sensiblement le risque de code halluciné publié sur un blog technique, sans pour autant remplacer la relecture d’un développeur qui vérifie, lui, la pertinence réelle de l’usage proposé.
