Un Pull Request avec 47 fichiers modifiés arrive dans la file de revue. Le reviewer l’ouvre, voit le diff et passe les 15 premières minutes à comprendre ce qui a changé et pourquoi. Quels fichiers sont des refactoring structurels ? Lesquels contiennent le changement de logique réel ? La couverture de tests est-elle adéquate ?
Pour une équipe faisant 10 PR par semaine, ce temps d’orientation — les 15 minutes avant que la revue réelle ne commence — s’accumule à 2,5 heures hebdomadaires. La revue de code est précieuse. La phase d’orientation ne l’est pas.
Ce que fait le workflow
Le workflow PR Review Summarizer se déclenche sur les événements PR et produit un résumé de revue structuré :
-
PR ouverte ou mise à jour — Déclenché via webhook GitHub, récupère le diff complet, la description de la PR, les issues liées et l’historique des commits.
-
L’IA analyse le diff — L’IA lit chaque fichier modifié et produit :
- Résumé : 2-3 paragraphes décrivant ce que fait la PR et pourquoi
- Ventilation des changements : fichiers groupés par objectif — tests, configuration, logique principale, refactoring
- Évaluation des risques : notation haut/moyen/bas avec raisons spécifiques
- Problèmes potentiels : préoccupations spécifiques que le reviewer devrait examiner
- Couverture de tests : si le nouveau code a des tests correspondants
-
Résumé posté comme commentaire de PR — L’analyse est postée comme commentaire formaté sur la PR, visible immédiatement par les reviewers.
L’analyse prend 30 à 60 secondes.
Temps économisé
10 PR par semaine : temps d’orientation sans résumé environ 15 min/PR = 2,5 h/semaine, avec résumé environ 3 min/PR = 30 min/semaine. Économie nette : 2 heures/semaine. L’amélioration de la qualité est plus difficile à mesurer mais réelle.
Ce que l’humain continue de faire
L’IA résume et signale, les humains reviewent. Les décisions architecturales, la validation de la logique métier, les standards d’équipe et les approbations restent la responsabilité du reviewer. Les résumés de PR complètent la revue humaine.