Résumé

Cet outil de revue de code IA estime la durée de relecture d'une pull request à partir des lignes modifiées, des fichiers touchés, du type de changement et de la profondeur de relecture. La formule s'appuie sur l'étude de relecture par les pairs de Cisco et SmartBear, qui montre que les taux de relecture efficaces se concentrent autour de 200 à 400 lignes de code par heure, et que la détection des défauts chute au-delà d'une heure de session. Entrez vos chiffres, l'outil renvoie un temps estimé, un niveau de concentration, et un signal pour scinder la PR ou lancer une passe IA. Rien de ce que vous saisissez ne quitte votre navigateur.

Combien de temps une pull request doit-elle vraiment prendre à relire ?

Cet outil de revue de code IA gratuit transforme les lignes modifiées, les fichiers touchés et la profondeur de relecture en une estimation de temps, pour savoir si un diff se survole en cinq minutes ou s'il mérite une passe IA avant qu'un humain ne l'ouvre.

Estimez votre relecture
Développeur relisant un diff de pull request avec du code en rouge et vert sur deux écrans, de nuit

Estimateur de temps de relecture

Indiquez la taille et le type du changement. L'estimation se met à jour au fil de la saisie, et rien de ce que vous entrez ne quitte votre navigateur.

-- min estimées

    Lire le résultat

    Comment lire votre estimation

    1. 1

      Décrivez la forme du diff

      Lignes modifiées, fichiers touchés, type de changement, et la profondeur que mérite cette relecture précise.

    2. 2

      Lisez l'estimation de temps

      Les minutes combinent un taux de relecture de base, un multiplicateur de risque selon le type de changement, et une petite pénalité de changement de contexte entre fichiers.

    3. 3

      Vérifiez les badges

      Le niveau de concentration attendu, s'il faut scinder la PR, et si une passe IA sur le diff vaut le coup avant qu'un humain ne l'ouvre.

    4. 4

      Décidez comment la planifier

      Un survol de cinq minutes tient entre deux réunions. Une relecture de 130 minutes demande un vrai créneau au calendrier, ou une PR plus petite.

    Comment ça marche

    Ce sur quoi repose l'estimation

    Les lignes modifiées, pas le feeling

    Le taux de base vient de la fourchette citée par l'étude de relecture par les pairs de Cisco et SmartBear : 200 à 400 lignes de code par heure tiennent la route, au-delà, le taux de détection des défauts chute. La taille de votre diff passe directement dans ce taux.

    Un multiplicateur de risque par type de changement

    Un correctif de bug et un changement d'infra avec le même nombre de lignes ne sont pas la même relecture. Les modifications de config et d'infrastructure reçoivent un multiplicateur de 1.4x, les refactorisations 1.3x, les fonctionnalités 1.15x, parce que le rayon d'impact est plus large même quand le diff est petit.

    Un signal pour savoir quand passer par l'IA en premier

    Au-delà d'environ 400 lignes, ou de 90 minutes de relecture estimée, l'attention au détail d'un humain baisse de façon mesurable. L'outil signale ce seuil et vous indique de lancer une passe IA sur le diff avant qu'une personne ne le lise en entier.

    Pourquoi estimer, au juste

    « Combien de temps ça va prendre ? » mérite une réponse avant de commencer

    La plupart des équipes ne budgétisent pas explicitement le temps de relecture. Une pull request arrive, quelqu'un l'ouvre entre deux réunions, et la relecture est soit bâclée, soit elle traîne deux jours. Aucune des deux options n'est bonne : une relecture bâclée rate ce qu'un second regard est censé attraper, et une relecture qui traîne ralentit toute l'équipe. L'estimation ci-dessus n'a pas vocation à être exacte à la minute près. Elle répond à une seule question avant d'ouvrir le diff : est-ce un survol de cinq minutes, ou est-ce qu'il faut un vrai créneau de concentration ? Cette décision change la façon dont vous le planifiez, et si ça vaut le coup de lancer d'abord une passe IA sur le diff pour repérer les problèmes mécaniques, afin que le relecteur humain concentre son attention sur les choix de jugement : est-ce la bonne approche, est-ce que ça s'intègre à l'architecture, est-ce que ça aura encore du sens dans six mois.

    • Au-delà d'environ 400 lignes, les études publiées montrent un taux de détection des défauts mesurablement plus faible
    • Les changements de config et d'infra portent plus de risque par ligne que le code de fonctionnalité, même à taille égale
    • Une passe IA sur le diff libère le relecteur humain pour les choix de jugement plutôt que la syntaxe
    Deux ingénieurs pointant un diff de code sur un ordinateur portable pendant une relecture de pull request

    Questions fréquentes

    Est-ce vraiment un outil de revue de code IA, ou juste un chronomètre ?
    C'est un outil de planification qui se place en amont de ce que vous utilisez déjà pour la relecture, humaine ou IA. Il ne lit ni ne juge votre code : il estime le temps que mérite un changement et vous indique quand une passe IA sur le diff vaut le coup avant qu'un humain ne l'ouvre.
    D'où viennent les chiffres de 200 à 400 lignes par heure ?
    De l'étude Cisco et SmartBear « Best Kept Secrets of Peer Code Review », basée sur environ 2 500 relectures chez Cisco Systems. Elle a montré que les taux de relecture efficaces se concentrent dans cette fourchette, et qu'au-delà d'environ 500 lignes par heure, de vrais défauts passent inaperçus.
    Mon code quitte-t-il un jour mon navigateur ?
    Non. Le calculateur ne lit que les chiffres que vous saisissez, lignes modifiées et fichiers touchés, et calcule l'estimation localement en JavaScript. Il n'y a aucun champ où coller du code et rien n'est envoyé nulle part.
    Pourquoi un changement de config est-il pénalisé par rapport à une fonctionnalité avec le même nombre de lignes ?
    Parce que le rayon d'impact n'évolue pas de la même façon avec le nombre de lignes. Un changement d'infra de cinq lignes peut casser un pipeline de déploiement ; un ajustement de fonctionnalité de cinq lignes, généralement pas. Le multiplicateur de 1.4x sur la config et l'infra reflète qu'une attention supplémentaire se justifie par ligne, pas par fonctionnalité.
    Faut-il vraiment scinder chaque pull request de plus de 400 lignes ?
    Par défaut, oui, si le changement peut être séparé par responsabilité sans casser chaque morceau. L'exception, ce sont les diffs générés ou mécaniques, comme une montée de dépendance ou un renommage à travers plusieurs fichiers, où le nombre de lignes est élevé mais la profondeur de relecture nécessaire est faible. Faites confiance à votre jugement : l'outil signale le seuil, il ne le remplace pas.
    Un résultat « Concentration faible » veut-il dire que mon code est mauvais ?
    Non. Il mesure la session de relecture, pas le code. Une refactorisation de 900 lignes peut être du code propre et mériter quand même un avertissement de concentration faible, parce qu'aucun relecteur ne garde une attention complète pendant trois heures d'affilée. Combinez-le avec un contrôle de qualité de code si vous voulez noter le code lui-même.
    L'estimation suppose-t-elle que la CI est déjà verte avant le début de la relecture ?
    Oui. La formule estime le temps de lecture humain ou IA sur un diff qui passe déjà le lint et les tests. Si la CI est encore rouge, prévoyez une marge : les relecteurs passent du temps réel à traquer des échecs qui auraient dû être détectés avant l'ouverture de la PR.

    Comprenez le diff avant de l'ouvrir

    codebasechat répond en langage clair aux questions sur votre codebase, si bien qu'au moment d'ouvrir une pull request, vous savez déjà ce qui a changé et pourquoi, et la relecture elle-même va plus vite.

    Essayez codebasechat gratuitement