OpenCodeReview AI Code Review sur le terrain : combien de bugs, failles et remarques qualité sur un vrai Git diff ?

D’abord : ce qu’OpenCodeReview relit vraiment

On le mélange souvent avec OpenCode (l’agent de code derrière opencode serve). Autre produit. OpenCodeReview est l’assistant de relecture interne d’Alibaba, publié en CLI : il lit les changements Git, émet des commentaires structurés, embarque des règles (NPE, threads, XSS, injection SQL) et parle à des endpoints compatibles OpenAI / Anthropic. Source : alibaba/open-code-review. Docs : open-codereview.ai.

Ce n’est pas « encore un bot qui félicite la PR ». Un modèle de chat ne voit que le fragment collé. Il n’ouvre pas les appelants et ignore si le fichier voisin tient déjà le verrou. Le pari : triage déterministe + agent profond. Décider quoi relire, injecter une checklist par type de fichier, puis file_read, recherche, comparaison des autres fichiers touchés.

Nous avons déjà publié comment dimensionner 4 Go / 8 Go / 16 Go pour OpenCode self-hébergé — c’est la facture RAM de l’agent de code. Ici, uniquement ocr review : contrôle automatique du Git diff, des bugs, de la sécu et de la qualité, et combien de problèmes un vrai projet sort.

Le discours vendeur parle de « dizaines de milliers de développeurs, millions de défauts ». C’est l’historique Alibaba, pas une promesse pour votre prochaine PR. Un second regard avant le merge : oui. Une machine qui signe la prod : ni le README ni cet essai ne signeront.

Lire un Git diff : trois modes

Si vous avez cherché « vérifier automatiquement un Git diff », vous voulez « ce que j’ai changé ». La CLI découpe ça en trois modes exclusifs — les mélanger est une erreur dure. Drapeaux : CLI Reference.

Le mode plage utilise merge-base, plus proche d’une relecture humaine qu’un diff brut entre deux branches : les commits arrivés ensuite sur main n’inondent pas. L’Action GitHub officielle fait pareil : merge-base, puis ocr review --from MERGE_BASE --to HEAD_SHA --format json, commentaires inline.

Quatrième voie : ocr scan — fichiers entiers, sans historique Git utile, pour hériter d’un dossier. Tokens et bruit montent. Pour merger, commencez par un diff ; scannez l’arbre legacy plus tard.

Toujours ocr review --preview d’abord. Filtre seul, zéro argent modèle. Vous voyez will_review contre extension / suppression / chemin de test. Chez nous, une PR avec images et lockfiles a perdu environ la moitié des fichiers « ça a l’air énorme » avant le LLM — à raison.

Cinq minutes : install, modèle, preview

npm global est l’install par défaut. Il existe aussi install.sh et un binaire GitHub Release. Git ≥ 2.41. Sans modèle, ocr review n’invente pas de commentaires (sauf Delegation Mode vers un agent de code déjà payé).

npm install -g @alibaba-group/open-code-review
ocr version
ocr config provider
ocr config model
ocr llm test

cd /path/to/your-repo
ocr review --preview
ocr review --from main --to HEAD --format json --audience agent

La config vit dans ~/.opencodereview/config.json. En CI, ocr config set ou réutiliser ANTHROPIC_* / OCR_LLM_*. Langue des avis : ocr config set language French (anglais par défaut). Committez .opencodereview/rule.json ; pas les clés.

Le wrapper npm se met à jour en fond (~18 min de cooldown). En CI, épinglez la version et OCR_NO_UPDATE=1. Sessions sous ~/.opencodereview/sessions/. ocr viewer sur localhost:5483 pour rejouer, pas un service public.

Ne copiez pas l’article RAM d’OpenCode. Le lourd, c’est l’API LLM et les sous-processus git ; pas de LSP chaud. --concurrency vaut 8 par défaut. Fermer le capot au milieu d’une plage laisse une session à --resume. Une machine qui reste éveillée est plus honnête qu’un pari sur un ultrabook de voyage.

Terrain : trois vrais paquets de changements

Même config (protocole compatible OpenAI, modèle conversationnel moyen, règles système fusionnées au projet) sur trois paquets en forme de PR — pas un jouet de dix lignes. Chaque paquet : --preview, puis ocr review --from --to --format json. Étiquettes : à corriger, devrait, style, faux positif. Un instantané ; changez le modèle, les comptes bougent. Le mélange compte plus que le total.

À corriger (7) : trois sécu, quatre défauts. Sécu : requêtes construites en chaîne, sortie HTML non échappée, texte d’erreur interne renvoyé au client. Défauts : nil traité comme objet, écriture de map sans verrou, erreurs sans %w. Ça tombe dans le ruleset annoncé — NPE, threads, XSS, SQL — pas une dissertation.

Devrait (6) : timeouts absents, retries sur appels non idempotents, logs avec e-mail ou corps. Un humain devrait les lever ; le vendredi après-midi souvent pas. L’agent ne fatigue pas.

Style (10) est le plus gros seau. Noms, early return, « extraire cette fonction ». Utile, et ça dilue le signal. Sans réglage, à la troisième semaine l’équipe plie toute la relecture — même pathologie que les bots de PR bruyants.

Faux positifs (4) étaient ennuyeux, tant mieux : SQL de fixture pris pour une injection prod ; requête déjà paramétrée recadrée ; note de variable de boucle d’avant Go 1.22. Trois sur quatre meurent si vous excluez les tests après --preview. Accusez le filtre avant le modèle.

L’échelle colle à l’exemple officiel : une relecture de plage ressemble souvent à « 9 fichiers, une douzaine d’avis, environ une minute, ~20k tokens ». Nos trois paquets sont trois plages isolées, pas une méga-PR. Un diff fichier qui mange ~80 % de la fenêtre est jeté avant le LLM — blobs générés et lockfiles doivent disparaître au preview, pas sur la facture.

Bugs, sécu, qualité : ce qu’il attrape

Découper les 27 avis selon les quatre mots du titre est plus proche de l’usage qu’un seul « problèmes trouvés ».

Parce que l’agent lit le fichier entier, il bat « lignes vertes seulement ». L’exemple officiel de map sans verrou est le type : le diff ajoute une affectation ; l’état partagé vivait déjà plus haut. Les bots diff-only ratent ; file_read ramène le contexte. C’est l’écart annoncé face aux relecteurs de PR qui ne voient que le patch — plus rapides, plus calmes, plus faibles en transversal.

Manques plantés exprès : mauvaise formule de remise, champ devise lu en USD, endpoint qui doit rester fermé avant validation. Zéro avis. Le modèle n’a pas votre glossaire. --background avec la description de PR aide. Ça ne remplace pas un humain sur le besoin.

Traitez les avis sécu comme des pistes, pas des verdicts. « Ici on concatène du SQL » exige encore driver, rôle et classe de données. Cet article ne montre pas comment exploiter ces lignes — seulement si le relecteur les a marquées. Pour borner l’écriture des agents de code : éditer des fichiers en sécurité avec un VFS — la relecture est en lecture seule ; l’agent de code écrit le disque.

CI : GitHub Actions, règles, faux positifs

Une fois le local OK, les équipes veulent des commentaires inline. L’Action composite officielle checkout une base de confiance (pas l’arbre d’un fork non fiable), récupère les objets git head, calcule merge-base, lance ocr review --format json, poste lignes + résumé sticky. Déclencheurs : PR opened/synchronized, ou commentaire /open-code-review.

Moindre privilège : contents: read ; pull-requests: write seulement pour poster. Clés dans Secrets, noms de modèle dans Variables. Les forks n’ont pas les secrets du dépôt — protection, pas un bug. Ne couplez pas pull_request_target à un checkout de code non fiable pour relire les forks ; ça fuit les secrets. GitHub : Security hardening for GitHub Actions.

Quatre couches de règles : --rule, projet .opencodereview/rule.json, global home, système. ocr rules check montre qui a gagné. merge_system_rule: true pour que deux notes de logs n’effacent pas la checklist NPE Java. Exclure tests, généré et vendor coûte moins cher que se battre ensuite sur les faux positifs.

Sous macOS, relire un diff Xcode est facile ; garder le runner vivant ne l’est pas. Montage : CI iOS lente et runner Mac self-hébergé. Une machine qui ne dort pas, avec des clés qui ne partagent pas le quota du portable, rend la relecture reproductible.