L’idée de départ était simple : ajouter un commentaire automatique de revue sur chaque pull request avant même qu’un développeur humain n’ouvre le diff, pour intercepter les défauts évidents plus tôt dans le cycle. Six mois après la mise en place sur nos projets WordPress internes, le bilan est plus nuancé que ce que nous espérions au lancement, avec des bénéfices réels mais aussi un travail de calibrage qu’on n’avait pas anticipé.
Ce retour d’expérience ne compare pas les différents assistants de code entre eux : il porte sur l’intégration elle-même dans notre flux de revue, indépendamment de l’outil précis retenu.
Ce que l’outil détecte bien, sans intervention
Sur les six premiers mois, les catégories de défauts les mieux détectées sans réglage particulier se sont révélées assez constantes : échappement de sortie manquant sur une variable affichée, absence de vérification de nonce sur un formulaire d’administration, requêtes SQL construites par concaténation plutôt que par $wpdb->prepare(), et fonctions dépréciées encore utilisées dans du nouveau code.
// Exemple de commentaire automatique généré sur une pull request réelle :
// "Cette variable $titre_produit provient d'une entrée utilisateur
// (ligne 42) et est affichée sans échappement ligne 58. Utiliser
// esc_html( $titre_produit ) avant l'affichage."Le bruit initial : plus élevé que prévu
Le premier mois d’utilisation a généré un volume de commentaires bien supérieur à ce que l’équipe pouvait traiter utilement, avec une proportion notable de remarques stylistiques mineures ou de suggestions déjà couvertes par notre linter existant. Ce bruit a rapidement lassé les développeurs, au point qu’une partie de l’équipe ignorait systématiquement les commentaires automatiques après quelques semaines.
Le réglage qui a changé la donne
La correction a consisté à restreindre explicitement le périmètre de la revue automatique aux catégories de défauts à fort impact : sécurité, performance, et compatibilité de version, en excluant volontairement les remarques de pur style déjà couvertes par les outils existants. Ce recentrage a divisé par trois le nombre de commentaires générés par pull request, tout en conservant la quasi-totalité des détections utiles.
Les règles spécifiques à WordPress qu’il a fallu ajouter à la main
Sans configuration additionnelle, l’outil appliquait surtout des règles génériques de sécurité PHP, sans connaissance fine des conventions propres à WordPress. Nous avons dû fournir un contexte explicite pour que la revue automatique reconnaisse correctement les patterns spécifiques au projet.
- Reconnaître que
current_user_can()est la vérification de permission attendue avant toute action d’écriture dans l’administration. - Reconnaître les hooks internes propres au projet, absents du noyau WordPress, pour ne pas les signaler à tort comme des fonctions inexistantes.
- Appliquer les règles des WordPress Coding Standards plutôt que celles d’un style PHP générique différent.
Un cas où l’outil s’est trompé, instructif à retenir
Sur une pull request touchant à un système de cache personnalisé, l’outil a signalé un appel à wp_cache_get() comme potentiellement redondant avec un appel voisin, en se basant sur une lecture superficielle du flux d’exécution. En réalité, les deux appels ciblaient des groupes de cache différents, une distinction que l’analyse automatique n’avait pas correctement interprétée. Ce type d’erreur reste rare, mais rappelle qu’une relecture humaine reste nécessaire avant toute fusion.
La revue automatique ne remplace jamais la personne qui connaît l’historique et les raisons derrière une ligne de code particulière. Elle change surtout ce sur quoi cette personne passe son temps.
Le bilan chiffré sur six mois
Le nombre de défauts de sécurité basiques identifiés en revue humaine tardive a nettement diminué depuis la mise en place de ce premier passage automatique, ces défauts étant désormais corrigés avant même l’ouverture de la revue par un développeur. Le temps de revue humaine par pull request a légèrement diminué également, une fois le recentrage du périmètre effectué, contrairement au premier mois où il avait au contraire augmenté à cause du bruit à trier.
Ce que nous recommandons à qui envisage la même démarche
Prévoir dès le départ une phase de calibrage d’un mois minimum avant de juger l’outil, restreindre le périmètre aux catégories de défauts à fort impact plutôt que de tout couvrir d’emblée, et documenter explicitement les conventions propres au projet que l’outil ne peut pas deviner seul.
Le bilan
Six mois après le lancement, l’outil reste en place sur nos projets, mais dans un rôle plus modeste que celui envisagé initialement : un premier filtre qui absorbe les défauts les plus mécaniques, pas un substitut à la revue humaine qui reste, elle, seule responsable de la décision finale de fusion.
