# Rédiger des prompts qui produisent du code WordPress exploitable

> Une méthode de prompt pour développeurs WordPress : cibler la version, imposer les contraintes de sécurité, exiger le respect des WPCS et des tests.

- Auteur : Clément Hadrot
- Publié le : 2023-03-28
- Mis à jour le : 2023-03-28
- Catégorie : IA & MCP
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/prompts-code-wordpress-exploitable/

## L’essentiel

- Toujours fixer la version cible
- Sécurité exigée dans le prompt
- Demander les tests avec le code

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()` ou `esc_url()` selon le contexte.
- Validation des entrées avec `sanitize_text_field()`, `absint()` ou `sanitize_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.

> L'essentiel à retenir : Toujours fixer la version cible ; Sécurité exigée dans le prompt ; Demander les tests avec le code

## 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.