Tutoriel OpenCodeReview 2026 : installer le CLI AI Code Review d’Alibaba, Git Diff, scan, Claude/GPT

Pourquoi « encore un Review Skill » ne répare pas la revue

En 2026, le vrai mal des équipes n’est plus « nous n’avons pas de revue IA ». C’est que l’entrée de revue est collée à un Agent généraliste. Vous dites à Claude Code « review this PR », il lit une partie des fichiers, en saute une autre, les numéros de ligne dérivent de temps en temps, et la qualité tremble dès que vous changez une phrase du prompt. Le README officiel nomme ces douleurs sans détour : couverture incomplète, positions qui glissent, Skill en langage naturel presque impossible à déboguer de façon reproductible.

Vous le voyez surtout le vendredi, quand trois personnes relisent le même pull request avec trois formulations différentes. L’une obtient un commentaire utile sur une condition de course ; la suivante n’a qu’une remarque de style sur un import ; la troisième reçoit un numéro de ligne qui pointe déjà vers autre chose après un rebase. Personne n’a « mal prompté ». Le processus n’a simplement aucune garantie d’ingénierie : chaque session est un nouveau tirage.

La cause racine n’est pas un modèle trop bête. C’est qu’une architecture pilotée uniquement par le langage n’impose aucune contrainte dure au processus de revue. Quels fichiers doivent entrer dans cette passe, lesquels doivent voyager ensemble, quelle règle s’applique à quelle classe de fichiers : ces étapes « n’ont pas le droit de se tromper », et on les abandonne pourtant à la même conversation. Remplacer GPT par Claude, ou l’inverse, ne fait que changer la manière de rater un fichier.

Un Review Skill plus épais aggrave souvent le problème. Plus le prompt est long, plus vous avez l’impression de contrôler la revue — alors que le modèle continue de choisir les fichiers, d’estimer les lignes et de « décider » si une règle s’applique. Vous déboguez alors un texte, pas un pipeline. Quand la CI échoue, vous n’avez ni journal de sélection, ni lot reproductible, ni signal JSON que le reste de la chaîne peut consommer.

La conclusion asymétrique est celle-ci : la ligne de partage n’est pas « Claude contre GPT », c’est l’entrée de revue « ingénierie déterministe + Agent » — sélection des fichiers, groupement en lots, matching des règles garantis par l’ingénierie ; le modèle ne fait que l’enquête dynamique. Ce qu’il faut faire évoluer, c’est l’entrée (ocr review / ocr scan / CI), pas installer encore un Review Skill plus gros. Pour le découpage conceptuel de ce qu’est un harness, voir Omnigent Agent Harness 2026 expliqué ; ici, on se limite à installer OpenCodeReview, faire tourner Git Diff et scan, puis brancher Claude et GPT.

Gardez cette grille en tête pour le reste du texte. Entrée : d’où part la revue — espace de travail, comparaison de branches, commit unique, ou arborescence entière. Exécution : qui choisit les fichiers, qui ancre les numéros de ligne, qui peut lire le dépôt. Contexte : le diff du jour, un chemin complet, ou les extraits qu’une session a « eu la chance » d’ouvrir. Public : qui a vraiment besoin de reproductibilité, et qui veut seulement un avis oral avant de continuer à éditer. Tant que vous discutez d’abord le nom du modèle, vous répondez à la mauvaise question.

OpenCodeReview : Git Diff et scan complet

Classez d’abord, commandez ensuite. OpenCodeReview n’est pas une fenêtre de chat de plus : c’est la même boucle de revue, ouverte de deux façons. Les axes restent l’entrée, l’exécution, le contexte et le public visé. Si vous n’avez qu’une phrase à retenir : ocr review répond à « qu’est-ce qui a changé cette fois », ocr scan répond à « est-ce que ce répertoire, tel qu’il est aujourd’hui, est sûr et lisible ». Les deux partagent le même moteur de lots et de règles ; ils ne partagent pas le même contrat d’entrée.

Le site et la fiche npm énoncent la philosophie sans fard : l’ingénierie déterministe porte les étapes qui n’ont pas le droit de se tromper — sélection précise des fichiers, groupement des fichiers liés (par exemple message_en.properties et message_zh.properties), matching des règles selon les traits du fichier, puis modules externes de localisation et de réflexion pour recaler numéros de ligne et contenu. L’Agent ne fait que les décisions dynamiques et l’enquête : lire un fichier entier, chercher dans le dépôt, regarder les autres fichiers du même changeset. Le benchmark officiel croise 50 dépôts open source, 200 PR réelles et 10 langages annotés : par rapport à un Agent généraliste (Claude Code compris), il revendique un Precision / F1 plus élevé, environ 1/9 des tokens, une fin plus rapide, mais un Recall plus bas — c’est un échange volontaire de précision contre du bruit, pas « un oubli = un échec ».

Ce trade-off change la façon dont vous lisez un rapport. Une revue chat qui « trouve beaucoup de choses » n’est pas forcément meilleure : elle noie souvent l’équipe sous des nits de style, des vrais positifs mal localisés et des commentaires que personne ne peut relancer à l’identique. OCR assume le contraire : moins d’alertes, plus d’entre elles actionnables, et une position de ligne que l’ingénierie recale. Si votre culture de revue récompense le volume de commentaires, le premier contact avec OCR peut sembler « trop silencieux ». C’est souvent le signe que le filtre fonctionne, pas que le modèle est muet.

Le groupement en lots n’est pas un détail d’implémentation. Deux fichiers de messages localisés, un couple test / implémentation, un schéma et son générateur : s’ils partent dans des contextes séparés, l’Agent invente des incohérences ou manque le vrai écart. OCR les lie avant d’appeler le modèle. C’est exactement le genre d’étape que vous ne voulez plus déléguer à un prompt du type « n’oublie pas les fichiers liés ». Sur un gros changeset, chaque lot devient un sous-Agent isolé : la revue se découpe, le contexte n’explose pas, et vous pouvez reprendre une session plutôt que tout relancer.

OCR face à Claude Code, Copilot et l’humain

Si la première question de cadrage est « Claude est-il plus fort que GPT », vous ratez l’écart utile. Alignez OpenCodeReview, un Skill d’Agent généraliste, la revue intégrée à l’IDE et la revue humaine sur la même grille : entrée, exécution, contexte, public. Vous verrez alors que Claude Code reste excellent pour éditer, que Copilot reste pratique quand tout est déjà acheté chez un éditeur, et que l’humain reste le seul à porter l’intention d’architecture. Aucun de ces trois n’offre, à lui seul, une revue de diff reproductible que vous pouvez jeter dans une CI sans réécrire le prompt chaque semaine.

Delegation Mode séduit les équipes qui ont déjà payé un Agent de coding et refusent une deuxième facture. Gardez le contrat en tête : OCR reste le portier déterministe. L’hôte ne reprend pas le droit de choisir les fichiers ni d’inventer les lignes. Si vous « déléguez » en croyant revenir à une revue 100 % chat, vous aurez installé le binaire pour rien. À l’inverse, si l’hôte est déjà authentifié et que vous voulez seulement sortir la sélection de fichiers du prompt, ce mode évite une clé OCR parallèle — utile en local, moins en CI où vous voulez un triplet d’endpoint explicite et des Secrets de dépôt.

Pour installer les clés d’un harness de coding multi-modèles, voir Installation de Pi Coding Agent et multi-modèles. Cet article répond à « comment changer de backend pour écrire du code » ; celui-ci répond à « comment sortir l’entrée de revue du chat pour en faire un CLI reproductible ». Les deux se complètent : écrire et relire n’ont pas à partager le même point d’entrée, ni forcément la même clé.

Installer et brancher le LLM

Prérequis

L’exigence officielle dure est Git ≥ 2.41 : génération du diff, recherche de code et opérations sur le dépôt passent toutes par Git. Lancez d’abord git --version ; sur une vieille distribution, mettez Git à jour avant le CLI. Node n’est pas le seul chemin d’installation, mais npm est le défaut documenté, et c’est celui que vous voulez pour un portable de développeur. En CI, le script d’install ou le binaire de release évite souvent d’embarquer toute une toolchain Node dans l’image, mais le contrat Git reste le même : une version trop ancienne casse le diff avant même que le modèle ne parle.

npm install -g @alibaba-group/open-code-review
ocr version
ocr --help
which ocr

Une fois installé, ocr doit être dans le PATH. Si vous voyez command not found, vérifiez que le bin global npm est bien exporté ; ne confondez pas « le paquet s’est installé » avec « la revue peut tourner » — sans configuration LLM, hors Delegation Mode, la commande échoue tout de suite. C’est volontaire. OCR refuse de feindre une revue locale alors que le cerveau est un endpoint distant non configuré. Traitez ocr version comme une smoke test de binaire, pas comme une validation de revue.

Autres modes d’installation

Les images CI et les environnements headless peuvent passer par le script d’installation (il encapsule le binaire GitHub Release, avec vérification) :

curl -fsSL https://raw.githubusercontent.com/alibaba/open-code-review/main/install.sh | sh
# OCR_INSTALL_DIR=/usr/local/bin（默认）
# OCR_VERSION=v1.2.3   # 可选：钉某个 release

Si vous ne voulez pas de Node, prenez le binaire statique dans GitHub Releases ; pour modifier OCR lui-même, construisez depuis les sources (Go ≥ 1.25 + Make). Les détails de plateforme restent ceux du guide d’installation : les numéros de version bougent, la forme des commandes est plus stable que « le nom de modèle du mois ». En entreprise, épinglez OCR_VERSION comme vous épingleriez un runner : une image « latest » qui change entre deux nuits de scan rend les écarts de rapports illisibles.

Le modèle d’abord, la revue ensuite

La configuration vit dans ~/.opencodereview/config.json. En interactif, le plus simple : ocr config provider pour choisir un fournisseur intégré ou custom, coller la clé, choisir le modèle, puis lancer automatiquement un test de connectivité ; ensuite ocr config model pour changer de modèle. Scripts et CI passent par le non-interactif ocr config set. Sur une machine partagée, verrouillez les droits de ce fichier : il contient l’URL, le jeton et le modèle — le triplet que OCR cherchera en premier.

ocr config provider    # 选 anthropic / openai / 自定义
ocr config model       # 为当前供应商选模型
ocr llm test           # 再测一次连通性
ocr llm providers      # 列出内置供应商

Le test de connectivité n’est pas cosmétique. Il vérifie que le triplet (URL, token, model) parle vraiment à un endpoint de la bonne famille de protocole. Un 401 ou un 403 ici vous évite une heure à blâmer Git, les lots ou « le Skill ». Si le test passe et que ocr review échoue ensuite, alors seulement vous descendez vers le diff, les chemins ignorés et les règles. Inversez cet ordre et vous déboguez le mauvais étage.

Ce point de confidentialité décide souvent du fournisseur plus vite que la qualité de prose du modèle. Si les diffs ne peuvent pas sortir du réseau, vous n’avez pas un débat Claude contre GPT : vous avez besoin d’un custom_providers interne, protocole anthropic ou openai, derrière votre proxy. Si les diffs peuvent sortir mais que la facture doit rester sur un compte déjà ouvert, reprenez la clé existante. Le modèle est un backend ; la politique de sortie des diffs est une contrainte d’entrée.

Trois modes Git Diff, en pratique

La recette d’installation n’est pas ocr version. C’est d’obtenir, dans un vrai dépôt, le premier avis avec un numéro de ligne qui tombe juste. Trois entrées couvrent les modifications locales, la comparaison de branches et le commit unique. Choisissez d’abord le contrat git, pas le modèle : un review lancé sur le mauvais intervalle produit un rapport « juste » sur un mauvais ensemble de fichiers, ce qui est pire qu’un modèle médiocre.

cd your-project

# 工作区：暂存 + 未暂存 + 未跟踪
ocr review

# 分支：相对 merge-base 审 feature 相对 main 的变更
ocr review --from main --to feature-branch

# 单个 commit
ocr review --commit abc123

# 中断后续跑
ocr session list
ocr review --from main --to feature-branch --resume <session-id>

# 给宿主 Agent 或 CI 落盘
ocr review --format json --output result.json

Le mode espace de travail convient à « j’ai fini de coder, je n’ai pas encore ouvert la PR, je veux d’abord me faire gronder ». Il agrège indexé, non indexé et non suivi : c’est le contrat le plus proche de ce que vous voyez dans git status. Le mode branches convient à la CI : la base est la branche par défaut, la tête est celle de la PR, le merge-base évite de relire tout l’historique commun. Le commit unique convient pour rejouer une soumission déjà identifiée comme problématique, ou pour une revue post-mortem sans rouvrir tout l’intervalle de branche. Les gros changements sont découpés en plusieurs bundles ; chaque bundle est un sous-Agent à contexte isolé — le découpage officiel pour éviter qu’un changeset énorme fasse rater des fichiers.

À la première exécution, si vous voyez no valid LLM endpoint configured, la chaîne de config n’a pas assemblé le triplet (URL, token, model). Selon la FAQ officielle : écrivez ~/.opencodereview/config.json, ou exportez OCR_LLM_URL / OCR_LLM_TOKEN / OCR_LLM_MODEL, ou réutilisez les ANTHROPIC_* déjà présents pour Claude Code. OCR prend le premier triplet complet, pas le dernier — si le fichier de config est complet, les variables d’environnement sont ignorées. C’est une source classique de « ça marche sur mon portable, ça échoue dans l’Action » : l’Action croit injecter une clé, alors qu’un config.json d’image a déjà gagné.

Le JSON n’est pas un export cosmétique. C’est le contrat qui permet à un Agent hôte, à un bot de PR ou à une étape CI de consommer des avis sans parser une TUI. Tant que votre critère de succès reste « le texte dans le terminal a l’air intelligent », vous n’avez pas encore un signal de revue. Exigez au minimum : fichier, numéro de ligne, règle ou catégorie, et un identifiant de session. Ensuite seulement vous décidez si ce signal commente, bloque, ou alimente un tableau de bord. --resume devient précieux dès qu’un lot long tombe sur un timeout réseau : vous reprenez l’enquête, vous ne relancez pas la sélection de fichiers.

Quand et comment lancer ocr scan

ocr review répond à « qu’est-ce qui a changé » ; ocr scan répond à « ce répertoire, aujourd’hui, est-il sûr / lisible ». Quand il n’y a pas de diff utile — dépôt inconnu tout juste cloné, baseline de revue à construire depuis zéro, répertoire presque sans commits — n’inventez pas un commit vide pour tromper review. Vous obtiendriez une revue « verte » parce que rien n’a bougé, alors que le code hérité est exactement ce que vous vouliez auditer. Le scan existe pour ce contrat : fichiers entiers, chemin explicite, pas de dépendance à un historique parlant.

ocr scan                          # 扫描整个仓库
ocr scan --path internal/agent    # 目录或具体文件
ocr scan --resume <session-id>    # 中断后恢复

Le scan coûte plus cher que le diff : tokens et temps se comptent en « fichiers entiers », pas en « lignes touchées ». Par défaut, commencez par le sous-arbre que vous reprenez vraiment, pas par un balayage immédiat de vendor/ et des artefacts générés. Les règles et le filtrage de chemins sont dans les Review Rules officielles ; excluez d’abord dépendances et livrables, ensuite seulement discutez du modèle. Un scan qui noie l’équipe sous des alertes issues de code généré ne prouve pas que OCR est bruyant : il prouve que vous lui avez donné le mauvais corpus.

Utilisez le scan comme une photographie de baseline, pas comme un substitut de chaque PR. La première semaine sur un module inconnu, un ocr scan --path produit une liste de dettes. Vous triez, vous corrigez ou vous acceptez, puis vous passez à ocr review sur l’incrémental. Relancer un scan complet à chaque push rouvre le bruit historique, double la facture et habitue l’équipe à ignorer le rapport. Si une session de scan saute — couvercle du portable, timeout CI, quota — --resume reprend le travail ; le temps mur et la facture, eux, ne se reprennent pas. D’où l’intérêt de poser les scans longs sur un nœud qui ne s’endort pas.

Brancher Claude et GPT, lire les résultats

Parmi les fournisseurs intégrés, anthropic vise https://api.anthropic.com, clé dans ANTHROPIC_API_KEY ; openai vise https://api.openai.com/v1, clé dans OPENAI_API_KEY. Si providers.*.api_key est absent, repli sur la variable d’environnement correspondante. Un environnement Claude Code déjà présent fait aussi ramasser les ANTHROPIC_*. Autrement dit : si vous codez déjà avec Claude en local, OCR peut hériter de la clé — pratique pour la première revue, dangereux si cette même clé personnelle atterrit ensuite dans une image CI.

# Claude
ocr config set provider anthropic
ocr config set model claude-opus-4-6
ocr config set providers.anthropic.api_key "$ANTHROPIC_API_KEY"
ocr llm test

# GPT（OpenAI）
ocr config set provider openai
ocr config set model gpt-4o
ocr config set providers.openai.api_key "$OPENAI_API_KEY"
ocr llm test

# 自定义 OpenAI 兼容网关
ocr config set provider my-gateway
ocr config set custom_providers.my-gateway.url https://gateway.internal.com/v1
ocr config set custom_providers.my-gateway.protocol openai
ocr config set custom_providers.my-gateway.model llama-3-70b
ocr config set custom_providers.my-gateway.api_key "$MY_API_KEY"

Les ID de modèle suivent le catalogue du fournisseur. Les exemples officiels ont déjà montré claude-opus-4-6 et gpt-4o ; en production, fiez-vous à la liste de ocr config model, n’écrivez pas un instantané de blog dans le workflow. Sur un 401 / 403, vérifiez d’abord le protocole : Anthropic passe par /v1/messages, le compatible OpenAI par /v1/chat/completions ; llm.protocol / use_anthropic doivent être de la même famille que l’URL. Un endpoint « OpenAI-compatible » déclaré en protocole Anthropic échoue de façon opaque ; ce n’est pas un bug de revue, c’est un mauvais étage HTTP.

Même dépôt, même diff : que lire en changeant de backend

Un test utile ne compare pas « qui écrit les phrases les plus longues ». Fixez une petite PR : un risque de pointeur nul, une absence de test évidente, un bruit de style. Lancez Claude puis GPT avec ocr review --from main --to HEAD --format json --output out.json, et regardez trois choses : le défaut qui devait être signalé a-t-il le bon numéro de ligne, le bruit de style a-t-il été contenu, tokens et temps mur tiennent-ils le budget CI. Le benchmark officiel vise haute précision, bas bruit, bas token ; si GPT est moins cher mais triple les nits, les humains de la CI finiront par couper toute la pipeline. L’inverse existe aussi : un modèle très prudent qui rate le vrai bug tout en restant « propre ». Votre critère n’est pas l’élégance du commentaire, c’est le couple rappel utile / fatigue d’équipe.

Gardez la sélection de fichiers et les règles identiques d’un backend à l’autre — c’est tout l’intérêt d’une entrée déterministe. Vous ne comparez plus deux Agents qui ont lu des sous-ensembles différents. Vous comparez deux cerveaux sur le même lot. Si l’un des deux explose le budget token, vous pouvez le réserver aux PR sensibles et laisser l’autre commenter le quotidien. Cette répartition est une décision d’exploitation, pas un verdict d’intelligence artificielle.

- name: Open Code Review
  uses: alibaba/open-code-review@main
  with:
    provider: openai
    model: gpt-4o
    api-key: ${{ secrets.OPENAI_API_KEY }}

GitLab CI, Gerrit et GitFlic sont aussi documentés. Les clés vont dans les Secrets du dépôt, jamais dans le fichier de workflow. La première semaine, faites commenter sans bloquer : vous mesurez le taux de faux positifs avant d’en faire une barrière. Quand le signal est stable, vous pouvez échouer le job sur une classe de règles — pas sur « le modèle a eu un avis ». Pour l’étagement entre runner macOS auto-hébergé et Mac cloud, voir GitHub Actions : runner macOS auto-hébergé et Mac cloud. Le CLI a découplé le modèle ; Git, le PATH et les droits de ~/.opencodereview restent, eux, collés à la machine qui exécute le processus.

Choisir selon le scénario

La vraie question n’est pas « faut-il installer OpenCodeReview ». C’est la première contrainte : voulez-vous une revue de diff reproductible, un audit de répertoire sans diff, ou seulement un avis oral dans une fenêtre de chat. Répondez à cela avant de parler de Claude, de GPT ou d’un Mac cloud. Beaucoup d’équipes n’ont besoin que du chat : elles éditent, elles demandent un second regard, elles mergent. OCR ne leur apporte rien d’exploitable. D’autres ont déjà un Agent de coding et veulent seulement sortir la couverture du prompt : Delegation Mode suffit en local. D’autres encore doivent commenter chaque PR à 2 h du matin : là, l’entrée CLI et le nœud toujours allumé deviennent le sujet, pas le nom du modèle.

Lisez la dernière ligne de la matrice comme une contrainte d’infrastructure, pas comme un argument marketing. OCR peut être parfaitement configuré et malgré tout rater une nuit entière parce que le portable s’est endormi au milieu d’un scan, ou parce que le runner éphémère a perdu ~/.opencodereview. Quand le processus doit vivre plus longtemps que votre session graphique, le nœud devient un paramètre de la revue au même titre que le fournisseur LLM.

Combinaisons recommandées

Les outils ont le droit de se superposer. OpenCodeReview résout l’entrée de revue reproductible ; il ne vous offre pas un Mac qui reste ouvert, et il ne paie pas non plus la facture Claude ou GPT. Construisez la pile par couches : binaire et Git d’abord, une clé ensuite, un vrai diff, un scan de baseline, puis seulement CI et second fournisseur. Sauter une couche pour « aller plus vite » est le moyen le plus fiable d’attribuer à OCR un échec qui vient du PATH, du protocole HTTP ou d’un corpus mal filtré.

• Pile quotidienne personnelle : ocr global + ANTHROPIC_API_KEY ou OPENAI_API_KEY + ocr review en espace de travail. Une passe avant d’ouvrir la PR ; les fichiers de règles vivent dans le dépôt, pas dans un prompt privé. Vous gardez l’Agent de coding pour éditer, OCR pour relire le diff que vous allez vraiment pousser.
• Pile PR / CI : ocr review --from base --to head --format json + Action GitHub officielle + Secrets. Stratégie d’échec : commenter d’abord, ne bloquer que lorsque le taux de faux positifs est stable. Le JSON devient un artefact ; les humains répondent à des avis ancrés, pas à un mur de prose.
• Pile d’audit de baseline : au premier contact, ocr scan --path pour une liste de problèmes ; ensuite, seulement du review incrémental. Ne scannez pas tout le dépôt à chaque PR. Archivez le rapport de baseline : c’est lui qui justifie les dettes que vous n’êtes pas en train de corriger.
• Pile avec Agent de coding déjà là : Claude Code / Cursor continuent d’écrire en local ; la revue passe par ocr delegate ou par un modèle géré par OCR. Écriture et relecture sont séparées ; les clés peuvent l’être aussi, ce qui évite qu’une session d’édition emporte les secrets de la CI.
• Pile de validation minimale : seulement le CLI, seulement une clé, un petit dépôt, ocr review sur un vrai changement d’espace de travail. Quatre temps (install → identifiants → un review → un scan) avant d’ouvrir la CI. Si l’un des quatre casse, vous savez encore quel étage réparer.

Pièges fréquents

• Prendre OCR pour un clone gratuit de Claude Code. L’outil retire volontairement au modèle le choix des fichiers et des numéros de ligne. Vous voulez une couverture de revue, pas une deuxième fenêtre de chat capable de modifier le code. Si votre critère de succès est « il a refactoré le module pendant la revue », vous êtes sur le mauvais produit.
• Accuser « une install cassée » alors que le LLM n’est pas branché. Hors Delegation Mode, il faut un triplet d’endpoint complet. Tant que ocr llm test échoue, ne touchez pas aux paramètres Git. La plupart des premiers tickets internes sur OCR sont des 401, des protocoles croisés ou un config.json qui masque les variables d’environnement.
• Remplacer chaque revue de PR par un scan. Le scan complet est cher, et il ressort le bruit historique. L’incrémental passe par review, la baseline par scan. Inverser les deux habitue l’équipe à ignorer le rapport — le pire échec pour un outil de revue.
• Durcir dans l’Action l’ID de modèle vu dans un blog. Les catalogues bougent. Traitez model dans l’Action comme une entrée modifiable ; validez d’abord en local avec ocr config model. Un workflow qui casse parce que gpt-4o a changé de nom n’est pas une régression de revue.
• Pousser une clé d’abonnement personnel dans la CI. La CI utilise les Secrets du dépôt ou un config.json machine (droits resserrés). Le code d’entreprise ne pointe pas vers une passerelle non auditée, et encore moins vers une clé gratuite qui expire au milieu d’une nuit de scan.
• Lancer un scan de tout le dépôt sur un portable qui s’endort. La session sait faire --resume, mais le temps mur et la facture deviennent laids. Les scans longs vont sur un nœud toujours allumé, avec Git, PATH et permissions figés. Reprendre trois fois le même lot n’est pas de la résilience, c’est de la dérive de coût.

Étapes de mise en place

1. Écrivez ce qui n’est pas négociable : auto-revue locale seulement, commentaires CI seulement, ou les deux ; faut-il brancher Claude et GPT dès la première semaine ; la CI commente-t-elle d’abord ou bloque-t-elle tout de suite. Ces trois décisions évitent d’installer un outil « pour voir » puis de lui demander, le mois suivant, d’être à la fois chat, barrière et audit de baseline.
2. Installez le CLI et faites un dry-run : npm install -g @alibaba-group/open-code-review, ocr version, confirmez le PATH et Git ≥ 2.41. Si Git est trop vieux, arrêtez-vous ici : aucun modèle ne réparera un diff mal généré.
3. Branchez une seule clé : ocr config provider ou ocr config set, puis ocr llm test avant d’aller plus loin. Une clé qui passe le test vaut mieux que deux catalogues « au cas où ».
4. Lancez ocr review sur une vraie petite PR : espace de travail ou --from/--to. Le critère d’acceptation est « les numéros de ligne tombent juste et le défaut attendu est signalé », pas « le commentaire est plus long ». Gardez le JSON.
5. Ajoutez un ocr scan --path : seulement le sous-arbre que vous reprenez, pour figer la division des rôles : baseline contre incrémental. Si le scan noie le rapport, filtrez les chemins avant de changer de modèle.
6. Ensuite seulement, second modèle ou Delegation : même diff, Claude / GPT, comparez faux positifs et coût ; si un Agent hôte est déjà là, testez ocr delegate. Ne construisez pas une « bake-off » de modèles tant que l’entrée n’est pas stable.
7. Choisissez l’environnement d’exécution, puis ouvrez la CI : l’essai local suffit pour apprendre les commandes ; scans de nuit et barrières vont sur un Mac cloud toujours allumé ou un runner auto-hébergé, journaux désensibilisés, clés hors des artefacts. À ce stade, le modèle est un paramètre parmi d’autres — plus le goulot.

FAQ

Quel rapport entre OpenCodeReview et Claude Code ?

Claude Code est le workflow de coding officiel d’Anthropic : écrire du code et demander un avis oral peuvent vivre dans la même fenêtre. OpenCodeReview est le CLI de revue open source d’Alibaba ; le modèle peut être Claude, GPT ou un endpoint compatible. Il ne remplace pas « l’édition profonde officielle ». Il remplace « la couverture de revue et les numéros de ligne qui ne tiennent que par le prompt ». Vous pouvez — et c’est souvent le bon couple — écrire avec Claude Code et relire avec ocr review, éventuellement en Delegation Mode pour réutiliser le modèle de l’hôte sans deuxième clé.

Faut-il configurer Claude et GPT en même temps ?

Non. Une seule clé suffit pour valider l’installation. La deuxième clé n’a de sens que si vous voulez, à sélection de fichiers et règles identiques, changer de backend selon le coût et les faux positifs. Tant que vous n’avez pas de deuxième facture, n’élargissez pas la surface d’exploitation « pour faire un benchmark ». Un seul fournisseur bien branché, avec un JSON que la CI peut relire, bat deux catalogues mal documentés. Ajoutez le second le jour où un écart mesuré de bruit ou de prix le justifie, pas le jour où un fil Twitter change de favori.

ocr review et ocr scan sont-ils interchangeables ?

Non, ce n’est pas la même commande. review mange un Git Diff, donc les PR et les changements locaux ; scan mange des fichiers entiers, donc l’audit sans diff. Se tromper d’entrée, ce n’est pas « le modèle n’est pas assez malin », c’est l’étage d’ingénierie qui regarde le mauvais input. Un review sur un dépôt sans changement utile vous dira que tout va bien ; un scan sur chaque PR vous ressortira des dettes que personne n’est en train de toucher. Gardez les deux verbes, refusez de les fondre en un seul réflexe.

Windows et un Mac cloud headless peuvent-ils l’installer ?

Oui. Le paquet npm global est multiplateforme ; le script d’install couvre darwin / linux en amd64 et arm64 ; sous Windows, prenez le binaire de Release ou npm. Sur une machine headless, restez en ocr config set non interactif et en --format json : n’attendez rien d’une TUI. Sur un Mac cloud, figez d’abord Git, le PATH et les droits de ~/.opencodereview — le modèle se configure après, pas avant. Un siège sans session graphique n’est pas un obstacle ; une config qui dépend d’un assistant interactif en est un.

Pourquoi un Mac cloud si npm suffit en local ?

Le local suffit pour apprendre les commandes. Il ne suffit pas pour un scan complet de nuit, une barrière de PR après la fermeture du couvercle, ni une CI qui partage l’environnement Xcode / signature. ocr a découplé le modèle, mais Git et les outils fichiers restent liés à la machine où tourne le processus. Si cette machine s’endort, change de PATH à chaque session ou perd les droits du répertoire de config, vous n’avez plus une revue reproductible — seulement un CLI qui marchait hier sur votre bureau. Le Mac cloud n’améliore pas Claude ni GPT ; il stabilise l’étage d’exécution que le CLI, précisément, n’a pas découplé.

Conclusion

Le tutoriel d’installation d’OpenCodeReview, en surface, parle de npm, de variables d’environnement et de ocr review / ocr scan. Ce qu’il faut vraiment poser, c’est une séparation en couches : ingénierie déterministe d’un côté, modèle de l’autre ; entrée Git Diff d’un côté, entrée scan complet de l’autre ; config interactive d’un côté, config CI de l’autre. L’usage qui tient en septembre 2026, c’est une clé en local pour un review qui passe, des règles versionnées dans le dépôt, des Secrets CI qui écrivent du JSON, et le scan réservé à la baseline.

La conclusion asymétrique tient toujours : la ligne de partage n’est pas « Claude ou GPT, qui est le plus fort », c’est votre capacité à transformer l’entrée de revue en contrainte dure. Faites d’abord passer un ocr review avec une seule clé, ajoutez ensuite le scan et un second modèle ; quand il vous faut une surface d’exécution, déplacez le processus du portable qui s’endort vers un Mac cloud. Ce qu’il faut faire évoluer, ce sont l’entrée, les identifiants et le nœud — pas encore un Review Skill.

Si vous ne retenez qu’une séquence : classer le besoin (diff, baseline ou avis oral), installer le binaire, brancher une clé, ancrer un premier rapport JSON sur un vrai changeset, puis seulement parler de CI et de fournisseur. Tout le reste — Delegation Mode, passerelle interne, runner de nuit — se greffe sur cette ossature. Tant que le chat reste l’entrée, changer de modèle ne fera que changer le style des commentaires. Quand l’entrée est déterministe, le modèle redevient ce qu’il aurait dû rester : un backend d’enquête, remplaçable, mesurable, et secondaire par rapport au contrat git.