La première fois que nous avons demandé à un assistant de langage d’écrire un shortcode pour un client, le résultat compilait, s’affichait correctement dans la page de démonstration, et échappait un tout petit peu trop peu les données utilisateur pour qu’on le laisse passer en revue de code sans y toucher. Rien de dramatique, mais un rappel utile : un prompt vague produit du code vague.
Depuis, nous avons construit une méthode de prompt que toute l’équipe applique avant de coller la moindre suggestion dans un projet client. Elle tient en quatre exigences, détaillées ci-dessous avec des exemples concrets.
Préciser la version cible de WordPress et de PHP
Un modèle de langage entraîné sur un corpus large mélange des pratiques de plusieurs générations de WordPress. Sans précision, il peut suggérer create_function(), supprimée depuis PHP 8, ou ignorer les fonctions ajoutées récemment. Nous commençons donc systématiquement le prompt par le contexte technique exact du projet.
Contexte : WordPress 6.1, PHP 8.1, thème enfant basé sur Twenty Twenty-Two.
Écris une fonction qui enregistre un custom post type "temoignage",
public en lecture, non hiérarchique, avec support du titre et de l'éditeur.
Utilise register_post_type() avec les arguments recommandés pour WordPress 6.1.Cette précision évite aussi les suggestions basées sur des extensions tierces obsolètes ou des hooks dépréciés depuis plusieurs versions majeures.
Imposer les contraintes de sécurité dans le prompt lui-même
Demander « sécurisé » ne suffit pas : le terme est trop vague pour orienter la génération. Nous listons explicitement les fonctions d’échappement et de validation attendues, en les nommant.
- Échappement en sortie avec
esc_html(),esc_attr()ouesc_url()selon le contexte. - Validation des entrées avec
sanitize_text_field(),absint()ousanitize_email(). - Vérification des permissions avec
current_user_can()avant toute action d’écriture. - Nonce vérifié avec
wp_verify_nonce()pour tout formulaire ou action déclenchée en POST.
Exiger le respect des WordPress Coding Standards
Le code généré par un LLM suit rarement les WPCS par défaut : indentation par espaces incohérente, accolades mal placées, absence de commentaires de fonction au format attendu par le générateur de documentation. En demandant explicitement la conformité aux WPCS dans le prompt, on réduit nettement les allers-retours de relecture.
Respecte les WordPress Coding Standards (indentation par tabulations,
espace avant les parenthèses des structures de contrôle, accolades sur
une nouvelle ligne pour les fonctions). Ajoute un DocBlock avant chaque
fonction avec @param et @return.Un exemple avant/après
Sur une fonction de récupération de champs personnalisés, la première version obtenue sans consigne de style utilisait des guillemets doubles partout, des espaces incohérents et aucun DocBlock. La version obtenue avec le prompt complet respectait les conventions à quelques détails près, corrigés en quelques secondes plutôt qu’en plusieurs minutes.
Demander systématiquement les tests avec le code
Un prompt qui se termine par « écris aussi un test PHPUnit pour cette fonction » change la qualité du code produit, pas seulement la couverture de tests. Le modèle, contraint de décrire un scénario de test cohérent, a tendance à corriger de lui-même des cas limites qu’il aurait autrement laissés de côté.
Ajoute un test PHPUnit qui vérifie que la fonction retourne un
WP_Error si le custom post type existe déjà, en utilisant
WP_UnitTestCase.Ce que nous relisons toujours nous-mêmes
Même avec un prompt complet, trois points restent sous la responsabilité du développeur : la vérification que les hooks utilisés existent réellement dans la version ciblée, le comportement en cas d’erreur réseau ou de valeur nulle inattendue, et la cohérence avec les conventions internes propres au projet, que le modèle ne peut pas deviner.
Un prompt bien écrit fait gagner du temps sur la première version du code. Il ne dispense jamais de la relecture qu’on ferait pour le code d’un collègue junior.
Pour aller plus loin
Cette méthode en quatre points — version cible, sécurité nommée, WPCS explicites, tests demandés — tient sur une fiche que nous gardons ouverte à côté de l’assistant. Elle ne garantit pas un code parfait du premier coup, mais elle transforme des suggestions génériques en points de départ réellement exploitables dans un projet WordPress professionnel.
