Chaque commit que je pousse est maintenant examiné par une IA avant qu’un humain ne le voie. Ce n’est pas parce que je ne fais pas confiance à mon propre code — c’est parce que je ne fais pas confiance à mon attention à 23 heures un vendredi lorsque j’essaie de déployer un correctif avant le week-end.
L’IA réviseur 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 chemin heureux mais qui plante avec une entrée vide. Des petites choses. Le genre de choses que l’examen de code est censé attraper, mais que des réviseurs humains fatigués manquent aussi.
Voici comment j’ai connecté OpenClaw à GitHub Actions pour un examen de code automatisé assisté par IA.
La Configuration
Déclencheur : Un workflow GitHub Action qui s’exécute sur chaque pull request. Lorsqu’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 en tant que commentaire de la PR. Temps d’exécution total : 30 à 60 secondes selon la taille du diff.
Ce que OpenClaw examine :
1. Bugs : références nulles, erreurs de décalage, cas limites non gérés
2. Sécurité : secrets codés en dur, motifs d’injection SQL, valeurs par défaut non sécurisées
3. Style : incohérences avec la base de code, noms de variables peu clairs, commentaires manquants sur une logique complexe
4. Performance : inefficacités évidentes, boucles inutiles, requêtes non optimisées
Ce qu’il n’examine pas : Décisions architecturales, conception de fonctionnalités, exactitude de la logique métier. Cela nécessite un contexte humain que l’IA n’a pas.
Le Workflow GitHub Action
Le workflow est simple :
1. Vérifier le code
2. Extraire le diff entre la branche de la PR et main
3. Envoyer le diff à OpenClaw via son API (ou CLI)
4. Formater la réponse en commentaire de PR
5. Publier 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 nombre de tokens raisonnable (et le coût bas) tout en concentrant l’examen sur ce qui a réellement changé.
Pour les grandes PR (500+ lignes de changements), je divise le diff par fichier et j’examine chaque fichier séparément. Cela produit un retour plus ciblé que de tout envoyer au modèle d’un coup.
La Qualité de l’Examen
Après 3 mois et environ 200 PR examinées :
Vrais positifs (problèmes réels détectés) : Environ 25 % des examens. En gros, une PR sur quatre a quelque chose que l’IA détecte qui compte. Les plus courants : gestion des erreurs manquante, noms incohérents, variables inutilisées.
Suggestions utiles (pas des bugs mais des améliorations) : Environ 40 % des examens. Améliorations style, suggestions de lisibilité, lacunes dans la documentation. Pas critiques mais utiles.
Faux positifs (erreurs ou non pertinentes) : Environ 35 % des examens contiennent au moins une suggestion incorrecte. L’IA ne comprend pas le contexte, suggère des changements qui casseront la fonctionnalité, ou signale des motifs 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.
Rendre Cela Utile Au Lieu de Dérangeant
La différence entre un réviseur IA utile et un dérangeant :
Prioriser les constatations. Étiquetez chaque constatation comme : 🔴 Bug (corriger avant de fusionner), 🟡 Avertissement (envisager de corriger), 🟢 Suggestion (amélioration optionnelle). Les développeurs s’attaquent aux éléments rouges, considèrent les jaunes et survolent les verts.
Être 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 déclenchera une TypeError » est actionnable.
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 constatations spécifiques et non évidentes.
Limiter le nombre de commentaires. Limitez l’examen IA à 5 commentaires par PR. S’il y a plus de problèmes que cela, priorisez et montrez les 5 meilleurs. Une PR avec 20 commentaires IA est entièrement ignorée ; une PR avec 3 à 5 commentaires ciblés est lue.
Au-Delà de l’Examen de Code
Une fois l’intégration des Actions GitHub opérationnelle, 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 lors de l’examen.
Analyse de la couverture des tests. L’IA vérifie si le code modifié a des tests 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 ? »
Suggerer une entrée de changelog. Basé sur le diff, l’IA suggère une entrée de changelog dans le format approprié. Le développeur l’approuve ou l’édite.
Compilation des notes de version. Lorsque vient le temps de publier, l’IA compile toutes les PR fusionnées depuis la dernière publication et génère des notes de version. Cela économise 30 à 60 minutes par publication.
Le Coût
Coût moyen par examen de PR : environ 0,08 $.
Coût mensuel pour 200 PR : environ 16 $.
Pour donner un aperçu, un humain passant 15 minutes à examiner chacune de ces PR passerait 50 heures par mois sur l’examen de code. L’IA ne remplace pas l’examen humain — elle le pré-traite, attrapant les problèmes mécaniques afin que les humains puissent se concentrer sur la conception et la logique.
Le processus d’examen de mon équipe maintenant : examen IA d’abord (automatisé, 30 secondes). Examen humain ensuite (concentré sur ce que l’IA ne peut pas évaluer, généralement 5 à 10 minutes au lieu de 15). Qualité d’examen totale : supérieure à avant, en moins de temps.
🕒 Published: