Un collègue nous a montré, un peu dépité, une fonction PHP qui appelait wp_get_post_categories_names() pour récupérer les noms de catégories d’un article. Le nom sonnait juste, la syntaxe était cohérente avec le reste de l’API WordPress, et le code semblait s’exécuter sans erreur immédiate en local. Cette fonction n’existe pourtant pas : la bonne fonction s’appelle wp_get_post_categories(), qui renvoie des identifiants, pas des noms directement.
Ce type d’erreur, qu’on appelle une hallucination, est l’un des pièges les plus fréquents et les plus insidieux de l’usage des assistants de code sur un projet WordPress. Voici les cas rencontrés le plus souvent et les réflexes qui permettent de les intercepter avant la mise en production.
Pourquoi les hallucinations sont particulièrement plausibles sur WordPress
WordPress possède un vocabulaire de fonctions extrêmement régulier : get_the_title(), get_the_content(), get_the_excerpt(), get_the_category(). Cette régularité, qui est une qualité pour un développeur humain, devient un piège pour un modèle de langage : il peut générer par analogie un nom de fonction qui suit exactement le même schéma sans que cette fonction n’ait jamais été réellement écrite dans le noyau.
Trois catégories d’hallucinations observées
Les fonctions entièrement inventées
Le cas le plus simple à repérer une fois qu’on le connaît : une fonction qui n’existe nulle part dans le Code Reference officiel. Exemple rencontré sur un projet : get_post_meta_all(), censée renvoyer toutes les métadonnées d’un article en une seule fonction pratique. La fonction réelle est get_post_meta( $post_id, '', true ), avec une chaîne vide comme deuxième argument pour obtenir l’ensemble des métadonnées.
Les hooks qui n’existent pas sous ce nom exact
Plus insidieux encore : des hooks presque corrects. Nous avons vu un code s’accrocher à before_post_save, un nom plausible qui n’existe pourtant pas dans WordPress. Le hook réellement disponible pour intervenir avant l’enregistrement d’un article est pre_post_update, ou selon le besoin exact, save_post avec une vérification du statut de la révision.
Les arguments mal composés pour une fonction qui, elle, existe bien
La troisième catégorie est la plus difficile à détecter, car la fonction appelée existe réellement, mais avec des arguments inventés. Exemple : un appel à register_post_type() avec un argument 'searchable' => true, qui n’est pas un argument reconnu par cette fonction. L’argument correct pour ce comportement est 'exclude_from_search' => false.
Les réflexes de vérification à systématiser
- Rechercher chaque nom de fonction inconnu directement sur le Code Reference du site officiel developer.wordpress.org avant de le laisser dans le code.
- Vérifier la liste des arguments acceptés dans la documentation de la fonction, pas seulement son existence.
- Écrire un test unitaire minimal qui appelle réellement la fonction suspecte : une fonction inexistante provoque une erreur fatale immédiate et sans ambiguïté.
- Se méfier particulièrement des noms « trop propres », qui semblent combler exactement un manque ressenti dans l’API existante.
Un test suffit souvent à trancher
La méthode la plus rapide reste d’exécuter le code dans un environnement de développement jetable. Une fonction inexistante déclenche une erreur fatale Call to undefined function, immédiatement visible. Le vrai danger n’est donc pas la fonction qui plante franchement, mais celle qui existe réellement sous un nom proche et qui s’exécute silencieusement avec un comportement différent de celui attendu.
Une fonction qui plante se corrige en cinq minutes. Une fonction qui existe, mais qui ne fait pas ce que le code suppose, peut rester en production pendant des mois avant d’être repérée.
Ce que nous avons ajouté à notre revue de code
Sur les projets où des suggestions d’assistants de code sont intégrées régulièrement, nous avons ajouté un point de contrôle explicite dans la checklist de revue : chaque fonction ou hook du noyau WordPress utilisé pour la première fois dans une pull request doit être accompagné d’un lien vers sa page de documentation officielle. Ce petit effort supplémentaire a permis de repérer plusieurs hallucinations avant qu’elles n’atteignent la production.
En résumé
Les hallucinations de code ne sont pas un défaut ponctuel appelé à disparaître avec de meilleurs modèles : elles resteront un risque structurel tant qu’un assistant génère du texte statistiquement plausible plutôt que du code vérifié contre une documentation réelle. La seule protection fiable reste la vérification systématique, pas la confiance dans la fluidité apparente du code produit.
