Un nom de fonction bien formé, avec un préfixe cohérent et des arguments qui semblent logiques, suffit-il à prouver qu’elle existe réellement dans le cœur de WordPress ? Non, et c’est précisément le piège que rencontre tout développeur qui adopte un assistant de code fondé sur un grand modèle de langage pour accélérer l’écriture de son thème ou de son extension.
Ce constat n’a rien d’anecdotique. Sur plusieurs projets menés ces derniers mois, des suggestions de fonctions au nom parfaitement crédible se sont révélées introuvables dans le codex ni dans le code source de WordPress. Comprendre le mécanisme derrière ce phénomène, appelé hallucination, permet de l’anticiper plutôt que de le subir en production.
Ce qu’est une hallucination de fonction
Un assistant de code IA ne consulte pas une base de données de fonctions à chaque suggestion. Il prédit la suite la plus probable d’un texte, jeton après jeton, à partir de tout ce qu’il a lu durant son entraînement : documentation, forums, dépôts publics, tutoriels parfois erronés eux-mêmes. Quand un développeur tape wp_get_, le modèle propose la continuation la plus statistiquement plausible compte tenu du contexte, sans distinguer une fonction réellement déclarée d’une fonction qui « devrait » exister par analogie.
C’est cette logique d’analogie qui produit des noms comme wp_get_post_thumbnail_url_by_id ou des variantes de get_the_ID avec un paramètre inventé. Le modèle a vu tant de fonctions WordPress suivant le schéma wp_verbe_objet qu’il en génère de nouvelles, cohérentes dans la forme, absentes dans les faits.
Deux cas rencontrés sur un projet réel
Sur un thème enfant développé pour un site vitrine, l’assistant a suggéré get_post_meta_single pour récupérer une valeur de champ personnalisé unique. La fonction n’existe pas : la bonne écriture reste get_post_meta( $post_id, $key, true ), avec ce troisième paramètre booléen qui fait toute la différence. Sans vérification, le code aurait levé une erreur fatale Call to undefined function dès la première visite.
Second cas, plus insidieux : une suggestion pour purger le cache d’objet a proposé wp_cache_flush_group. Le nom sonne juste, la fonction wp_cache_flush existe bel et bien, mais la variante « par groupe » n’a jamais été introduite dans le cœur. Seule l’ouverture du fichier wp-includes/cache.php a permis de trancher.
La méthode de vérification à adopter systématiquement
- Rechercher le nom exact sur le Code Reference de developer.wordpress.org avant tout copier-coller.
- En cas de doute, ouvrir les fichiers du cœur en local via
grep -r "function nom_de_la_fonction" wp-includes/ wp-admin/. - Vérifier la version minimale requise indiquée sur la fiche de référence, certaines fonctions récentes n’étant pas disponibles sur les sites encore en 5.x.
- Tester immédiatement en local avec un simple
var_dump()ou un point d’arrêt plutôt que de faire confiance à la lecture visuelle du code.
Un réflexe simple avant tout commit
Ajouter cette vérification à sa propre checklist personnelle change la donne : deux minutes de recherche documentaire évitent une erreur fatale en production, souvent découverte bien plus tard par un client ou un visiteur plutôt que par le développeur lui-même.
Pourquoi cela ne remet pas en cause l’outil
Un assistant de code IA reste précieux pour la structure d’un plugin, la rédaction de commentaires PHPDoc ou la suggestion de boucles WP_Query cohérentes. Le problème ne se situe pas dans l’outil mais dans la confiance aveugle qu’on lui accorde sur les noms exacts d’API. Un développeur expérimenté relit un plan de code généré par un stagiaire avant de le fusionner ; il doit appliquer la même discipline à du code généré par un modèle de langage.
La règle qu’on applique désormais sur chaque projet : aucune fonction issue d’une suggestion IA n’est fusionnée sans une recherche documentaire préalable, même si elle « a l’air » correcte.
En résumé
L’hallucination de fonctions n’est pas un bug ponctuel de tel ou tel assistant : c’est une conséquence structurelle du fonctionnement des modèles de langage, qui prédisent une forme plausible plutôt qu’ils ne consultent une source de vérité. La parade tient en une habitude simple mais non négociable : vérifier chaque fonction citée sur la documentation officielle ou dans le code source avant de l’utiliser, particulièrement pour tout ce qui touche au cache, aux métadonnées ou à la base de données.
