Résumé

Ce vérificateur de code review IA gratuit est un contrôleur de pré-revue fondé sur des règles, sans modèle d'IA. Collez un diff git ou un extrait : il analyse les lignes ajoutées avec treize règles couvrant les secrets écrits en dur, le SQL construit par concaténation, les exceptions avalées, les tests désactivés et le code de debug oublié. Il signale aussi les changements trop volumineux et les tests manquants, puis renvoie une note de 0 à 100 avec des constats numérotés par ligne. Tout s'exécute dans votre navigateur, pour éliminer les problèmes mécaniques avant qu'un humain ne relise.

Vérifiez votre diff avant qu'un relecteur le fasse

Collez un git diff ou un extrait de code. Ce vérificateur de code review IA gratuit repère les secrets, le SQL construit par concaténation, les erreurs avalées, le code de debug oublié et les changements trop volumineux, directement dans votre navigateur, puis attribue à la pull request une note sur 100.

Vérifier mon diff
Ingénieur qui examine un diff de code côte à côte sur un écran

Vérificateur de diff avant relecture

Collez un diff unifié ou n'importe quel code. Seules les lignes ajoutées sont vérifiées quand un diff est détecté. Rien de ce que vous collez ne quitte votre navigateur.

--/100
Collez du code pour commencer
Aucun contrôle effectué pour l'instant.
    Fonctionnement

    Ce que le vérificateur examine, et ce qu'il ignore

    Lignes ajoutées uniquement

    Si vous collez un diff unifié, le vérificateur lit les en-têtes de hunk, compte les numéros de ligne dans le nouveau fichier et ne scanne que les lignes que vous avez ajoutées. Les lignes supprimées et le contexte inchangé ne produisent jamais de constat : vous n'êtes donc pas tenu responsable du code ancien.

    Score pondéré par la gravité

    Treize règles se répartissent en trois niveaux. Élevé retire 15 points : secrets écrits en dur, eval, SQL construit par concaténation, vérifications TLS désactivées. Moyen retire 7 : exceptions avalées, tests isolés, innerHTML, diff de 400 lignes. Faible retire 2 : TODO, sorties de debug, code commenté. Chaque règle compte au maximum trois fois.

    Contrôles de taille et de tests

    Au-delà de 200 lignes ajoutées, on vous invite à découper le changement ; au-delà de 400, l'invitation se fait plus ferme. Cela suit la constatation de l'étude SmartBear sur les revues Cisco : la qualité de revue baisse dès qu'un relecteur doit examiner plus de 200 à 400 lignes à la fois. Un diff de plus de 50 lignes ajoutées sans fichier de test est aussi signalé.

    Mode d'emploi

    De la copie à une pull request propre en quatre étapes

    1. 1

      Collez votre diff

      Lancez git diff main...HEAD, ou git diff --staged avant de committer, puis collez le résultat. Un simple extrait fonctionne aussi, mais vous perdez les noms de fichiers et la détection des fichiers de test.

    2. 2

      Lisez d'abord les constats élevés

      Les éléments en rouge sont ceux sur lesquels un relecteur s'arrêtera. Une clé écrite en dur reste dans l'historique même après la suppression de la ligne : changez-la, ne vous contentez pas de la retirer.

    3. 3

      Corrigez ou justifiez le reste

      Chaque constat s'accompagne d'une correction d'une ligne. Si un signal est un faux positif, dites-le dans la description de la PR. Vous évitez ainsi au relecteur la même question.

    4. 4

      Copiez la checklist

      Le bouton de copie transforme les constats en checklist Markdown que vous pouvez coller dans le corps de la PR, pour que le relecteur voie ce que vous avez déjà trouvé.

    Pourquoi une pré-vérification

    Les trente premières secondes d'une revue ne devraient pas porter sur un console.log

    Vous avez reçu une pull request d'un collègue et vous connaissez la routine. Vous parcourez le diff, repérez une sortie de debug oubliée, un TODO sans ticket, un test sauté et un bloc catch qui avale l'erreur. Rien de tout cela n'exige un humain. Il faut une checklist qui tourne avant que la demande de revue parte. C'est le manque que cet outil comble. L'attention d'un relecteur est limitée : l'étude SmartBear sur les revues Cisco montre que la détection de défauts tient quand on examine 200 à 400 lignes en 60 à 90 minutes, puis se dégrade au-delà. Chaque minute passée sur des constats mécaniques est une minute qui ne va pas aux questions que seul un humain peut trancher : est-ce la bonne approche, cela s'intègre-t-il à l'architecture, cela aura-t-il encore du sens dans six mois ? Il ne remplacera pas un relecteur, et il ne prétend pas le faire. Il retire les objections bon marché pour que la revue humaine commence par la partie intéressante.

    • Détecte les constats mécaniques avant l'envoi de la demande de revue
    • Donne à chaque constat un numéro de ligne tiré des en-têtes de hunk du diff
    • S'exécute localement, donc sans risque pour du code propriétaire
    Deux ingénieurs qui discutent d'une modification de code devant un ordinateur portable
    FAQ

    Questions sur le vérificateur

    Est-ce un vérificateur de code review IA ou un linter ?
    Ni l'un ni l'autre, à proprement parler. C'est un vérificateur de pré-revue fondé sur des règles. Aucun modèle ne lit votre code et rien n'est généré. Treize règles de motifs analysent les lignes ajoutées à la recherche de ce qu'un relecteur repère dans les trente premières secondes : secrets, SQL construit par concaténation, exceptions avalées, sorties de debug oubliées. Nous le disons clairement, car un vérificateur qui devine est pire qu'une checklist qui ne devine pas.
    Mon code quitte-t-il mon navigateur ?
    Non. Les contrôles s'exécutent en JavaScript sur cette page. Il n'y a ni envoi, ni appel d'API, ni compte. Le seul élément enregistré est un événement anonyme indiquant que l'outil a été utilisé, sans aucun contenu du champ de saisie.
    D'où viennent les règles des 200 à 400 lignes et des fichiers de test ?
    Le seuil de taille suit l'étude SmartBear sur les données de revue de Cisco, qui recommande de ne pas relire plus de 200 à 400 lignes à la fois. La règle sur les petits changements suit les pratiques d'ingénierie publiques de Google sur les petites CL. La règle sur les tests manquants est une convention de notre part : un diff de plus de 50 lignes ajoutées sans fichier de test est signalé, car c'est une question que les relecteurs posent de toute façon.
    Comment le score est-il calculé ?
    Il part de 100. Chaque constat retire des points selon sa gravité : 15 pour élevé, 7 pour moyen, 2 pour faible. Chaque règle compte au maximum trois fois, pour qu'une règle bruyante ne puisse pas annuler le score. C'est une convention pour ordonner le travail, pas une mesure de la qualité du code. Un score de 100 signifie qu'aucune règle ne s'est déclenchée, pas que le code est correct.
    Que manque-t-il ?
    Tout ce qui demande de la compréhension : une logique métier erronée, des conditions de concurrence, une mauvaise abstraction, une API qui vieillira mal. Les règles fondées sur des expressions régulières donnent aussi des faux positifs, par exemple une fixture de test qui contient un faux mot de passe. Traitez chaque constat comme une question à trancher, pas comme un verdict.
    Quels langages sont pris en charge ?
    Les règles sont des motifs de texte : elles fonctionnent donc sur JavaScript, TypeScript, Python, Java, Go et la plupart des langages de la famille C. Certaines règles sont propres à un langage : except nu relève de Python, System.out.println de Java, InsecureSkipVerify de Go. Collez un diff git unifié et les numéros de ligne viennent des en-têtes de hunk.
    Est-ce gratuit ?
    Oui, sans inscription. Si vous voulez des réponses sur le reste de votre dépôt pendant la revue, par exemple qui appelle cette fonction ou où une valeur de configuration est lue, c'est à cela que sert codebasechat.

    Relisez avec tout le dépôt sous les yeux

    Un diff montre ce qui a changé, pas ce que cela touche. codebasechat répond en langage clair aux questions sur votre code, pour que vous vérifiiez qui appelle la fonction modifiée avant d'approuver.

    Essayer codebasechat gratuitement