wp_get_current_screen_id() : cette fonction n’existe pas dans le cœur de WordPress. Elle est pourtant apparue, avec une assurance totale, dans une suggestion de code générée par un assistant IA lors d’une session de développement sur ce site multi-auteurs. Le développeur qui l’a intégrée sans vérification l’a découvert seulement lors d’un test manuel, la fonction retournant une erreur fatale silencieuse en environnement de production. Le choix de l’assistant de code lui-même n’est pas discuté ici.
Sur un mois de revues de code dans cette équipe de trois développeurs, trois occurrences de fonctions ou hooks inexistants ont été repérées avant merge, grâce à une checklist désormais appliquée systématiquement.
Pourquoi ces erreurs passent inaperçues en local
Une fonction inexistante ne provoque pas toujours une erreur immédiate et visible : si elle est appelée dans un contexte conditionnel rarement exécuté en développement local, ou si elle est enveloppée dans un function_exists() mal placé, l’erreur peut rester silencieuse jusqu’à sa première exécution réelle en production. Un assistant de code, entraîné sur un vaste corpus incluant de nombreuses versions de WordPress, mélange parfois des fonctions de versions différentes, ou invente des noms plausibles par analogie avec des fonctions réelles.
Le cas le plus fréquent observé ici : une fonction au nom cohérent avec les conventions de nommage du cœur WordPress, mais qui n’a simplement jamais existé, générée par extrapolation à partir de fonctions réelles similaires comme get_current_screen().
La checklist appliquée avant tout merge
- Toute fonction ou hook nouvellement utilisé est recherché dans la documentation officielle sur developer.wordpress.org/reference/ avant merge.
- Un test exécuté réellement, pas seulement une relecture visuelle du code : la fonction suspecte est appelée dans un contexte réel, pas simplement présente dans un fichier jamais chargé.
- La version minimale de WordPress requise est vérifiée pour toute fonction récente, afin d’éviter une incompatibilité avec la version réellement installée sur le site.
- Les hooks personnalisés supposés existants dans un plugin tiers sont vérifiés directement dans le code source de ce plugin, jamais supposés sur la seule foi de la suggestion générée.
Les trois occurrences détectées ce mois-ci
| Fonction ou hook suggéré | Statut réel | Détecté par |
|---|---|---|
wp_get_current_screen_id() | Inexistante | Test manuel en production |
woocommerce_before_product_price | Hook inexistant dans WooCommerce | Vérification dans le code source |
register_taxonomy_meta() | Inexistante (confondue avec register_meta()) | Recherche dans la documentation |
Dans les trois cas, le code généré était syntaxiquement irréprochable et cohérent avec le reste du fichier, ce qui rendait la détection à l’œil impossible sans vérification active dans une source de référence.
Le réflexe à adopter en revue de code
- Ne jamais faire confiance à la cohérence apparente d’un nom de fonction : elle ne garantit en rien son existence réelle.
- Systématiser une recherche dans la documentation officielle pour toute fonction ou hook peu familier, même suggéré avec assurance.
- Signaler et partager en équipe chaque occurrence détectée, pour affiner collectivement la vigilance sur les motifs récurrents.
Un assistant de code ne connaît pas la différence entre une fonction qui existe et une fonction qui devrait exister selon la logique du cœur WordPress : cette différence reste entièrement à la charge du développeur qui relit.
En résumé
Les fonctions inventées par un assistant de code ne se signalent jamais par une syntaxe suspecte : elles se glissent avec la même assurance que le code correct qui les entoure. Seule une vérification systématique dans la documentation officielle, intégrée comme réflexe de revue de code plutôt que comme contrôle occasionnel, permet de les intercepter avant qu’elles n’atteignent la branche principale.
Cette checklist n’a rien d’un frein à la productivité malgré les quelques minutes qu’elle ajoute à chaque revue : le temps perdu à traquer une erreur fatale en production, une fois le code déjà déployé, dépasse largement celui qu’aurait coûté une vérification systématique en amont. L’équipe considère désormais ce contrôle comme aussi indispensable qu’un test unitaire classique sur toute portion de code générée par un assistant IA.
