Plugin WordPress modifié par IA : isoler le changement avant la pull request

Une modification de plugin WordPress proposée par IA peut sembler locale : un hook déplacé, une condition ajoutée, un callback AJAX réécrit, une option renommée. Le diff reste court, mais l’effet réel dépend souvent du contexte WordPress : rôle utilisateur, nonce, données déjà stockées, autre extension active, thème chargé, version PHP, ordre d’exécution des hooks. Accepter la proposition parce qu’elle « a l’air correcte » revient à relire du PHP sans vérifier le comportement du plugin.

Le bon réflexe n’est pas de demander à l’IA une seconde explication plus convaincante. C’est de transformer sa proposition en changement reproductible, dans une copie isolée, avec des données synthétiques et des critères de refus visibles. Cette approche complète un audit de plugin WordPress avec l’IA : ici, on ne cherche pas à couvrir tout le plugin, mais à décider si une modification précise mérite d’entrer dans une pull request.

Le cas : un correctif IA sur un callback d’administration

Scénario hypothétique : un assistant IA reçoit un ticket indiquant qu’un réglage d’administration ne se sauvegarde pas toujours. Il lit le plugin, identifie un callback lié à une action AJAX, puis propose de simplifier la fonction en changeant la lecture de la valeur, la validation et la mise à jour de l’option. Le diff tient en une dizaine de lignes.

Le danger ne vient pas seulement d’une erreur de syntaxe. Le callback peut perdre un contrôle de capacité, vérifier le nonce au mauvais moment, accepter une valeur ambiguë ou échapper une donnée trop tôt. La documentation WordPress rappelle que le code de plugin doit traiter les données comme non fiables et utiliser les API de validation, de sanitisation et d’échappement adaptées. La page officielle sur le développement sécurisé de plugins insiste aussi sur la vérification des requêtes, notamment avec les nonces, avant de poursuivre l’exécution.

Problème : la revue du diff ne suffit pas

Dans WordPress, une ligne correcte isolément peut devenir fragile dans le cycle complet. Une valeur peut provenir d’un formulaire, d’une option ancienne, d’un autre plugin ou d’une requête préparée manuellement. Une fonction d’échappement peut être correcte dans du HTML mais inadaptée dans un attribut. La documentation WordPress sur l’échappement des données recommande d’échapper au moment de la sortie, pas bien plus tôt dans le traitement, afin de garder la revue lisible et de limiter les ambiguïtés.

Pour une équipe qui utilise déjà un assistant dans l’IDE, un agent de pull request ou un workflow plus structuré, ce point rejoint le choix de surface traité dans l’intégration d’un assistant IA dans un projet WordPress. L’outil peut proposer le changement ; le dépôt doit exiger une preuve comportementale avant fusion.

Solution 1 : réduire le changement à une fixture

La fixture n’est pas une copie complète de production. C’est un environnement minimal qui reproduit seulement ce que le correctif prétend résoudre. Elle contient le plugin, une version WordPress explicite, une configuration PHP connue, un jeu d’options synthétiques et deux ou trois utilisateurs de test avec des rôles distincts. Les données doivent être volontairement banales : aucun contenu client, aucun jeton réel, aucun export de production.

WordPress documente l’ajout de tests automatisés pour plugin, avec un environnement de test et des assertions ciblées. Le tutoriel officiel sur les tests automatisés de plugin WordPress distingue notamment les tests unitaires, les tests d’intégration et les vérifications de comportement dans un environnement WordPress. Pour ce cas, un test d’intégration minimal est souvent plus utile qu’un test unitaire pur, car le callback dépend de WordPress lui-même.

Solution 2 : écrire les critères avant de relancer l’agent

Avant de demander une correction, l’équipe écrit les critères qui décideront du merge. Ce petit contrat évite de juger la proposition à son apparence. Il rend aussi le travail de l’IA plus étroit : modifier la fonction, ajouter ou ajuster les tests, expliquer les limites, mais ne pas déplacer l’architecture du plugin.

Solution 3 : limiter ce que l’IA a le droit de faire

Le protocole doit empêcher l’agent de résoudre le ticket en élargissant discrètement le périmètre. Une consigne utile peut être simple : ne modifier que le callback concerné, le test associé et, si nécessaire, une fixture de données. Toute modification de schéma, de rôle, de route REST, de table personnalisée ou de dépendance doit être déclarée comme hors périmètre.

Cette limite rejoint la logique d’un bac à sable pour agents IA de code : l’autonomie augmente seulement quand l’environnement rend les écarts visibles. Sur un plugin WordPress, la frontière doit être encore plus explicite, car un correctif peut toucher à la sécurité applicative sans que le diff paraisse spectaculaire.

Solution 4 : joindre les preuves à la pull request

La pull request ne devrait pas seulement contenir le code final. Elle doit permettre au reviewer de rejouer mentalement, ou réellement, le raisonnement. Un format court suffit.

• Ticket traité : symptôme initial, fichier concerné, fonction modifiée.
• Environnement : version WordPress, version PHP, type de base locale, plugin seul ou dépendances activées.
• Données synthétiques : options, rôles, valeurs valides et invalides utilisées dans le test.
• Commandes exécutées : tests lancés, analyse statique éventuelle, résultat brut résumé sans embellissement.
• Limites : cas non couverts, hypothèses WordPress, comportements qui exigent une validation manuelle.

Ce format évite deux erreurs courantes : faire confiance à un commentaire généré qui n’est pas vérifié, ou exiger un rapport trop lourd que personne ne maintiendra. La bonne preuve est celle qui aide le reviewer à décider rapidement si le changement est borné.

Anecdote hypothétique : le correctif qui supprimait le bug et le garde-fou

Une équipe demande à un assistant de corriger une option booléenne qui ne se sauvegarde pas. L’IA remplace plusieurs lignes par une affectation plus directe, le test manuel passe avec un compte administrateur, et le ticket semble clos. En revue, un développeur rejoue la fixture avec un utilisateur moins privilégié : la sauvegarde échoue visiblement dans l’ancienne version, mais passe dans la nouvelle. Le bug a disparu parce que le contrôle de capacité a disparu aussi.

Dans ce scénario, l’IA n’a pas « attaqué » le plugin. Elle a optimisé autour du symptôme fourni. La fixture a servi de contrepoids : même action, autre rôle, résultat interdit. C’est exactement le type de preuve qu’une simple lecture du diff peut manquer.

Checklist avant merge

• Le changement est limité à une fonction, un hook ou un flux précisément nommé.
• Les données de test sont synthétiques et suffisantes pour reproduire le symptôme.
• Un cas valide, un cas invalide et un cas non autorisé sont vérifiés.
• Les contrôles WordPress restent dans le bon ordre : capacité, intention, validation, écriture, sortie.
• La pull request indique ce qui n’a pas été testé.
• L’IA n’a pas ajouté de dépendance, de route ou de comportement secondaire sans décision humaine explicite.

Décision de l’étude de cas

Pour une modification de plugin WordPress proposée par IA, le seuil raisonnable n’est pas « le diff est propre ». Le seuil est : le symptôme est reproduit dans une copie isolée, le correctif passe les cas attendus, les garde-fous de sécurité sont encore observables et le reviewer peut comprendre les limites sans relancer toute l’enquête.

Sans fixture, il vaut mieux traiter la proposition comme une piste de diagnostic, pas comme un correctif prêt à merger. Avec une fixture courte, l’IA garde son intérêt : accélérer l’identification et l’écriture du patch, tout en laissant au workflow WordPress ce qu’il doit conserver, c’est-à-dire la preuve, le contrôle et la responsabilité de livraison.