Un projet WordPress concentre plusieurs surfaces de risque dans un même dépôt : PHP, JavaScript, blocs, hooks, requêtes SQL, capacités, nonces, templates, performance front et compatibilité avec le cœur ou les extensions. Ajouter une IA dans la code review peut accélérer le tri des anomalies, mais le dispositif choisi change fortement le niveau de confiance obtenu.
Le bon choix ne consiste pas à demander au modèle de « relire le plugin » en bloc. Une équipe doit décider où l’IA intervient, avec quel contexte, sur quels fichiers, et sous quelle forme le résultat arrive au reviewer humain. Pour un site vitrine, un plugin métier ou une boutique à fort trafic, la réponse ne sera pas la même.
Les quatre dispositifs à comparer
Dans un workflow WordPress, la code review IA peut prendre quatre formes principales. Elles ne s’excluent pas, mais chacune répond à une intention différente : accélérer le développeur, préparer la pull request, renforcer la CI ou connecter l’IA à un contexte WordPress plus riche via des outils contrôlés.
- Assistant dans l’éditeur : utile pendant l’écriture du code, avant le commit.
- Revue IA de pull request : utile pour commenter un diff déjà cadré.
- Contrôles IA en CI : utile pour bloquer ou signaler des familles de risques répétables.
- Revue assistée par MCP : utile quand l’IA doit interroger un contexte projet ou des outils internes sans accès général.
Option 1 : l’assistant IDE pour corriger tôt
L’assistant intégré à l’éditeur est le plus simple à adopter. Il peut relire une fonction PHP, proposer un test, signaler une variable non échappée ou rappeler qu’un callback AJAX doit vérifier les capacités. Sa force tient à la proximité avec le code en cours d’écriture.
Cette option convient bien aux équipes qui veulent réduire les erreurs avant même l’ouverture de la pull request. Elle reste toutefois fragile si elle devient la seule revue. L’assistant voit souvent le fichier actif, quelques voisins, parfois une sélection manuelle. Il peut manquer un hook déclaré ailleurs, une convention du thème parent ou une interaction avec un plugin déjà installé.
Pour WordPress, il faut donc lui donner des consignes très concrètes : vérifier les nonces, les capacités, la validation des entrées, l’échappement des sorties, les accès base de données et la compatibilité avec les hooks utilisés. Le sujet rejoint les contrôles détaillés dans l’audit d’un plugin WordPress avec l’IA, mais ici l’objectif est plus étroit : choisir le bon endroit pour placer cette revue dans le workflow.
Option 2 : la revue IA de pull request
La revue de pull request donne un cadre plus propre. Le diff est visible, les fichiers modifiés sont connus, les tests associés peuvent être cités, et le reviewer humain dispose d’un commentaire exploitable au même endroit que la discussion d’équipe.
Pour un projet WordPress, cette option est souvent le meilleur point de départ. Elle permet de demander une revue orientée risque : changement de permission, nouvelle route REST, modification de template, requête personnalisée, ajout de bloc, altération du rendu SEO ou variation de performance.
Le danger est la revue bavarde. Une IA peut produire des remarques générales sur la sécurité WordPress sans pointer une ligne réellement problématique. La règle pratique est simple : un commentaire IA doit contenir un risque, un emplacement, une raison et une vérification possible. Sans ces quatre éléments, il doit rester une note de contexte, pas une demande de changement.
Option 3 : les contrôles IA dans la CI
La CI ajoute une contrainte utile : elle force la répétabilité. Une équipe peut lancer une analyse IA uniquement sur certains types de changements, par exemple les fichiers de plugin, les templates critiques, les routes REST, les migrations ou les fonctions qui manipulent les rôles utilisateurs.
Cette approche devient intéressante lorsque l’équipe a déjà identifié des familles d’erreurs récurrentes. Elle n’est pas adaptée à une exploration libre. Un contrôle CI doit savoir ce qu’il cherche et comment rendre sa décision lisible. Sinon, il crée du bruit, ralentit les merges et pousse les développeurs à contourner l’étape.
Dans WordPress, la CI IA doit compléter les outils classiques, pas les remplacer. Les linters, tests unitaires, tests d’intégration, scans de dépendances et règles de qualité restent nécessaires. L’IA sert surtout à formuler une hypothèse de risque ou à repérer une incohérence que les contrôles syntaxiques ne décrivent pas bien.
Option 4 : MCP pour une revue contextualisée
Le Model Context Protocol devient pertinent lorsque la revue IA doit accéder à des informations contrôlées : documentation interne, conventions du thème, matrice de compatibilité, liste des plugins autorisés, règles SEO techniques ou historique de décisions. Le modèle ne reçoit pas forcément tout le dépôt ; il interroge des outils bornés.
Cette option demande plus d’architecture. Elle convient aux équipes qui ont plusieurs sites, des extensions internes ou un socle WordPress partagé. Elle peut éviter deux excès : donner trop de fichiers au modèle, ou lui demander une revue sans contexte métier.
Le point critique reste la permission. Un serveur d’outils ne doit pas transformer la code review en accès général à l’environnement. Les actions exposées doivent être limitées, traçables et conçues pour aider la revue. Pour les projets qui explorent déjà des actions WordPress standardisées, la logique rejoint les garde-fous décrits autour de l’Abilities API et des agents IA.
Matrice de décision
| Dispositif | Meilleur usage WordPress | Force principale | Limite à surveiller | Profil d’équipe |
|---|---|---|---|---|
| Assistant IDE | Relire une fonction, un hook, un bloc ou un template avant commit | Retour rapide pendant le développement | Contexte souvent incomplet | Développeur seul ou petite équipe |
| Revue de pull request | Analyser un diff cadré sur plugin, thème ou intégration REST | Commentaires visibles dans le workflow de revue | Risque de remarques génériques | Équipe avec PR régulières |
| Contrôle CI | Surveiller des familles de risques répétables | Exécution systématique et historisable | Bruit si le critère est flou | Équipe avec pipeline déjà stable |
| MCP contextualisé | Connecter la revue aux conventions internes et outils autorisés | Contexte riche sans tout exposer | Conception des permissions plus exigeante | Organisation multi-sites ou plugin métier |
Checklist avant de choisir
- Le dépôt sépare-t-il clairement thème, plugin, mu-plugin, tests et configuration ?
- Les règles WordPress attendues sont-elles écrites, ou seulement connues par les reviewers seniors ?
- La revue doit-elle commenter chaque PR ou seulement certains changements sensibles ?
- Les commentaires IA doivent-ils bloquer, avertir ou préparer la revue humaine ?
- Les données envoyées au modèle peuvent-elles contenir du code propriétaire, des secrets ou des informations client ?
- L’équipe dispose-t-elle déjà de tests et de linters pour éviter de demander à l’IA de tout vérifier ?
- Le résultat attendu tient-il en constats actionnables plutôt qu’en rapport long ?
Le choix pragmatique
Pour la plupart des équipes WordPress, le meilleur démarrage est une revue IA de pull request limitée aux diffs sensibles. Elle s’intègre au workflow existant, ne demande pas d’architecture lourde et laisse le reviewer humain décider. L’assistant IDE vient en complément pour corriger tôt, surtout sur les fonctions isolées ou les templates en cours de modification.
La CI IA devient utile après quelques semaines, lorsque l’équipe sait quels contrôles méritent d’être répétés. MCP arrive plus tard, quand le problème n’est plus seulement de relire du code, mais de relier cette revue à des règles internes, des outils de diagnostic et une documentation maintenue.
Un bon dispositif ne cherche pas à faire approuver automatiquement une pull request WordPress. Il réduit le temps passé à trouver les risques évidents, clarifie les points à vérifier et conserve une frontière nette entre suggestion automatisée et responsabilité de merge.
À relier dans le workflow : une méthode générale de code review avec l’IA, les contrôles spécifiques d’un audit de plugin WordPress et, pour les équipes qui exposent des actions aux agents, l’approche WordPress Abilities API.
où placez-vous aujourd’hui l’IA dans vos revues de code WordPress : éditeur, pull request, CI ou outil contextualisé ?
Publié dans la discussion