Chaque commit que je pousse est maintenant examiné par une IA avant qu’un humain ne le voit. Ce n’est pas parce que je n’ai pas confiance en mon propre code — c’est parce que je n’ai pas confiance en mon attention à 23 heures un vendredi quand j’essaie de livrer un correctif avant le week-end.
L’examinateur IA détecte des choses que je manque : une variable déclarée mais jamais utilisée, une clé API accidentellement laissée dans un commentaire, une fonction qui gère le cas normal mais se bloque avec une entrée vide. Des petites choses. Ce genre de choses que la révision de code est censée attraper, mais que des examinateurs humains fatigués ratent aussi.
Voici comment j’ai connecté OpenClaw à GitHub Actions pour une révision de code automatisée assistée par IA.
La Configuration
Déclencheur : Un workflow GitHub Action qui s’exécute sur chaque pull request. Quand une PR est ouverte ou mise à jour, le workflow se déclenche.
Ce qu’il fait : Le workflow extrait le diff de la PR, l’envoie à OpenClaw pour révision et publie la révision sous forme de commentaire sur la PR. Temps d’exécution total : 30 à 60 secondes selon la taille du diff.
Ce qu’OpenClaw examine :
1. Bugs : références nulles, erreurs de type “off-by-one”, cas limites non gérés
2. Sécurité : secrets codés en dur, modèles d’injection SQL, paramètres par défaut non sécurisés
3. Style : incohérences avec la base de code, noms de variables peu clairs, commentaires manquants sur une logique complexe
4. Performance : inefficiences évidentes, boucles inutiles, requêtes non optimisées
Ce qu’il ne examine pas : Décisions architecturales, conception de fonctionnalités, correction de la logique métier. Ces éléments nécessitent un contexte humain que l’IA n’a pas.
Le Workflow GitHub Action
Le workflow est simple :
1. Vérifiez le code
2. Extrayez le diff entre la branche PR et la branche principale
3. Envoyez le diff à OpenClaw via son API (ou CLI)
4. Formatez la réponse en tant que commentaire PR
5. Publiez le commentaire
L’extraction du diff est l’étape importante. Vous n’envoyez pas l’ensemble de la base de code — juste les changements. Cela garde le compte de tokens raisonnable (et le coût bas) tout en concentrant la révision sur ce qui a réellement changé.
Pour les grandes PR (plus de 500 lignes de changements), je divise le diff par fichier et révisé chaque fichier séparément. Cela produit des retours plus ciblés que de tout présenter au modèle d’un coup.
La Qualité de la Révision
Après 3 mois et environ 200 PR examinées :
Vrais positifs (problèmes réels détectés) : Environ 25 % des révisions. Environ une PR sur quatre a quelque chose que l’IA détecte qui a de l’importance. Les plus courants : gestion des erreurs manquantes, noms incohérents, variables inutilisées.
Suggestions utiles (pas des bugs mais des améliorations) : Environ 40 % des révisions. Améliorations de style, suggestions de lisibilité, lacunes de documentation. Pas critiques mais utiles.
Faux positifs (incorrects ou non pertinents) : Environ 35 % des révisions contiennent au moins une suggestion incorrecte. L’IA ne comprend pas le contexte, suggère des changements qui rompraient la fonctionnalité, ou signale des modèles intentionnels comme des problèmes.
Le taux de faux positifs de 35 % semble élevé, mais en pratique, c’est gérable. Les commentaires sont clairement étiquetés comme générés par l’IA, et les développeurs apprennent rapidement quelles suggestions prendre au sérieux et lesquelles ignorer.
Le Rendre Utile au Lieu d’Étres Ennuyeux
La différence entre un examinateur IA utile et un ennuyeux :
Prioriser les découvertes. Étiquetez chaque découverte comme : 🔴 Bug (à corriger avant fusion), 🟡 Alerte (à considérer pour correction), 🟢 Suggestion (amélioration facultative). Les développeurs traitent les éléments rouges, considèrent les jaunes et parcourent les verts.
Sois spécifique. « Il pourrait y avoir un problème avec la gestion des erreurs » est inutile. « La fonction `processOrder()` à la ligne 47 ne gère pas le cas où `order.items` est indéfini, ce qui entraînera une TypeError » est exploitable.
Ne pas répéter l’évident. Les développeurs savent qu’ils doivent écrire des tests. Ne leur dites pas à chaque PR. Concentrez-vous sur des découvertes spécifiques et non évidentes.
Limiter le nombre de commentaires. Limitez l’examen de l’IA à 5 commentaires par PR. S’il y a plus de problèmes que cela, priorisez et montrez les 5 premiers. Une PR avec 20 commentaires de l’IA est entièrement ignorée ; une PR avec 3 à 5 commentaires ciblés est lue.
Au-delà de la Révision de Code
Une fois l’intégration GitHub Actions en place, vous pouvez l’étendre :
Génération de description de PR. Lorsqu’une PR est ouverte avec une description vide, l’IA lit le diff et génère un résumé : ce qui a changé, pourquoi cela a probablement changé, et ce qu’il faut rechercher pendant la révision.
Analyse de la couverture des tests. L’IA vérifie si le code modifié a des changements de test correspondants. « Vous avez modifié `auth.js` mais n’avez pas mis à jour `auth.test.js` — la mise à jour du test était-elle intentionnelle ou oubliée ? »
Suggestion d’entrée de changelog. Sur la base du diff, l’IA suggère une entrée de changelog dans le format approprié. Le développeur l’approuve ou l’édite.
Compilation de notes de version. Quand il est temps de publier, l’IA compile toutes les PR fusionnées depuis la dernière version et génère des notes de version. Cela fait gagner 30 à 60 minutes par publication.
Le Coût
Coût moyen par révision de PR : environ 0,08 $.
Coût mensuel pour 200 PR : environ 16 $.
Pour donner un contexte, un humain passant 15 minutes à examiner chacune de ces PR passerait 50 heures par mois sur la révision de code. L’IA ne remplace pas la révision humaine — elle la pré-traite, attrapant les problèmes mécaniques pour que les humains puissent se concentrer sur la conception et la logique.
Le processus de révision de mon équipe maintenant : révision IA d’abord (automatisée, 30 secondes). Révision humaine ensuite (concentrée sur ce que l’IA ne peut pas évaluer, généralement 5 à 10 minutes au lieu de 15). Qualité totale de la révision : supérieure à avant, en moins de temps.
🕒 Published: