Revue de code automatisée en 2026 : faites-la fonctionner sur chaque PR sans acheter de siège.

La revue de code automatisée est un job de CI qui envoie votre diff à un modèle de langage, affiche les constatations sur les lignes concernées et fait échouer un contrôle de statut lorsqu'elle détecte un problème sérieux. Pour que cela tourne sur chaque pull request sans abonnement par siège, il faut auto-héberger un harnais open source : copier un workflow d'une quinzaine de lignes dans votre dépôt, ajouter une clé API, et ne payer que les jetons consommés par chaque revue. Il n'y a pas de nombre de sièges à acheter, car il n'y a pas de siège. L'implémentation de référence que nous maintenons est le dépôt Orca-Code-Review — public, sous licence MIT, et depuis sa création le 25 juin 2026, le code derrière l'action GitHub OrcaCode Review. Sa configuration de routage fournie attribue par défaut le passage de revue à DeepSeek V4 Flash et le juge de vérification indépendant à GLM-5.3, et vous êtes libre de les modifier tous les deux. Cet article détaille ce qui s'exécute réellement à chaque push, ce que vous configurez, ce que cela coûte en jetons, et les modes de défaillance que vous rencontrerez à la deuxième semaine.

La version courte. Chaque push reçoit une revue. Les remarques sont publiées directement sur les lignes modifiées. Les remarques P0 et P1 font échouer le contrôle et bloquent la fusion ; une exécution sans anomalie passe. Vous pouvez relire à la demande en commentant /orcacode-review. Le workflow réside dans votre dépôt ; la logique de revue réside dans l'action publiée ; le choix du modèle réside dans une recette de routage que vous pouvez modifier dans votre propre espace de travail. Le relecteur lit le diff et les fichiers du dépôt et n'exécute jamais le code de votre PR. Et l'avertissement honnête d'emblée : il détecte de vrais bugs et laisse encore passer ceux qui nécessitent un humain qui sait pourquoi le code est ce qu'il est.

• Un workflow + un secret + une facture de jetons. Pas de licence par siège, à aucun moment.

• Le harnais est open source. Copiez-le, forkez-le, auditez-le, épinglez-le à un SHA de commit.

• Le modèle est un paramètre, pas un fournisseur. Changez le relecteur en modifiant une recette de routage, pas en réécrivant YAML ou en modifiant l'action.

• Les diffs trop volumineux ne coûtent rien. La vérification de taille s’exécute avant le modèle.

• Il lit votre code, mais ne l’exécute jamais. C’est la propriété de sécurité qui rend pull_request_target sûr à utiliser.

Comment fonctionne réellement la revue de code automatisée

Tout système de revue automatisé est les mêmes trois ingrédients portant des habits différents : un événement, un exécuteur et un réviseur.

L'événement est le déclencheur. Le workflow fourni se déclenche sur les événements de pull request — opened, synchronize (un nouveau push), ready_for_review (une ébauche devient prête) — et sur un commentaire de PR. Parce qu'il s'exécute sur pull_request_target, la définition du workflow est lue à partir de la branche de base, c'est pourquoi le workflow doit exister sur la branche de base avant de pouvoir s'exécuter pour une PR. Une revue par push ; le concurrency (bloc qui annule l'exécution précédente, de sorte qu'une séquence rapide de pushes ne met pas en file cinq revues de code obsolète).

Le runner est GitHub Actions sur ubuntu-latest. Le travail nécessite trois permissions : accès en lecture aux contenus, accès en écriture aux pull requests (pour poster des commentaires en ligne), et accès en écriture aux issues (pour poster le résumé et nettoyer les commentaires obsolètes).

Le relecteur est un modèle de langage. L'action récupère la tête de la PR, assemble le diff et le contexte du dépôt que le moteur sélectionne, puis l'envoie au modèle de relecture. Le résultat est un ensemble de constatations, chacune étiquetée avec une gravité et ancrée à un fichier et une ligne. L'action les publie comme commentaires en ligne sur la PR et écrit un commentaire récapitulatif dans une zone de marqueurs en haut de la description de la PR, remplacé sur place à chaque push.

Le gate est une vérification de statut. GitHub ne sait pas ce que signifie “review” ; il sait uniquement si la vérification review passe. Vous rendez le gate réel en marquant cette vérification comme requise dans la protection de branche. Voilà tout le mécanisme de blocage de fusion — aucun appel à l'API admin, aucune étiquette, juste une vérification requise qui échoue.

Ce qui ne se produit pas : rien n'exécute le code de la PR. Le moteur ne fait que lire. C'est cet unique invariant qui rend le déclencheur privilégié pull_request_target sûr à utiliser avec une clé API payante.

Le harnais open-source est le différenciateur.

Tout ce qui précède vaut pour de nombreux outils. Ce qui n'est pas vrai pour la plupart d'entre eux, c'est que l'ensemble est inspectable et auto-hébergeable, ce que vous apporte le dépôt Orca-Code-Review. Il s'agit d'un dépôt GitHub public sous licence MIT (JavaScript, créé le 25 juin 2026) qui empaquette la revue sous la forme d'une action GitHub composite réutilisable et d'un installateur, et c'est le même code que l'application OrcaCode Review hébergée fait tourner.

Passez dix minutes dans l'arbre et vous pourrez nommer chaque élément qui touche votre PR :

• action.yml — l’action composite, environ quinze entrées documentées. Aucun nom de modèle n’y est codé en dur.

• workflows/orca-code-review.yml — le workflow consommateur d'exemple, les quinze lignes environ que vous copiez dans .github/workflows/.

• recipes/ — le DSL de routage. C'est ici que le modèle est réellement choisi.

• rules/ — la grille de sévérité (P0–P3), le format de sortie obligatoire, et une directive de conventions qui injecte le document de conventions du projet dans la revue en tant que données de référence non fiables.

• scripts/ — le filtre de précision (un juge L1 plus un L2), le garde de diff, la porte de fusion, le rapport d’exécution et le compteur de jetons. Chacun est un petit fichier.mjs lisible avec des tests.

• skills/setup-orca-code-review — la compétence que l’installateur dépose dans votre agent de codage, couvrant l’installation, la reconfiguration, le dépannage et la désinstallation.

• .claude-plugin/ — ce qui permet à Claude Code d'installer la compétence en tant que plugin à mise à jour automatique.

L'installation est une commande unique qui apprend à votre IA ce qu'est le produit puis s'arrête :

npx @orcarouter/code-review

La CLI détecte quels agents de codage vous utilisez — le catalogue recense 36 plateformes, de Claude Code, Cursor, Codex, OpenCode et Windsurf à GitHub Copilot, Gem​ini CLI, Amazon Q Developer, Cline, RooCode et d'autres — installe la compétence, puis passe la main. Vous demandez alors à votre agent en langage naturel : “configurez OrcaCode Review dans ce dépôt,” “ne bloquez que P0,” “pourquoi la revue n’a-t-elle pas tourné ?” La compétence assure le cycle de vie : elle écrit le workflow, vous accompagne dans la configuration de la clé API, définit le seuil de blocage et ne pose que les questions qui relèvent réellement de vous.

Claude Code peut installer la compétence comme plugin à la place, ce qui la maintient à jour à mesure que le dépôt évolue :

/ajouter au marketplace de plugins Continuum-AI-Corp/orca-code-review

/plugin install orca-code-review

Pas d'agent du tout ? Le même cycle de vie se résume à de simples sous-commandes — init écrit le workflow, reconfigure modifie les règles de blocage et les limites de diff, doctor diagnostique les revues qui ne s'exécutent pas ou ne publient pas, uninstall le supprime (en retirant d'abord la vérification requise). La compétence est la porte d'entrée, pas la seule porte. Ou branchez-le à la main : copiez le workflow, ajoutez un secret nommé ORCAROUTER_API_KEY, puis marquez la vérification review comme requise.

The engine underneath is Ali​baba’s Open Code Review, pinned by exact version and Apache-2.0 licensed. OrcaCode decides how to review; OrcaRouter decides what model runs it. The self-host-versus-hosted ledger — what “free” actually costs when you self-host an open-source reviewer — is worked through in our article on open code review.

Qu'est-ce qui s'exécute, dans l'ordre, à chaque push ?

Il est utile de connaître l'ordre, car chaque étape peut échouer ou être sautée indépendamment :

• La protection de diff s'exécute en premier, avant même que le modèle n'entre en jeu. Si le diff de la base de fusion dépasse 512 Ko ou touche plus de 300 fichiers, la revue est ignorée et un avis est publié. La valeur par défaut est on-oversized-diff: fail, donc un diff gonflé au-delà des limites ne peut pas franchir un portail obligatoire sans avoir été revu. C'est aussi le contrôle des dépenses : une PR surdimensionnée ne coûte aucun token.

• Le moteur examine le diff. Un passage, avec une concurrence par fichier par défaut de 24, et un plafond de temps réel de 20 minutes par passage.

• Le filtre de précision post-traite les résultats bruts. L1, un filtre déterministe, vérifie l’extrait de code existant revendiqué par chaque résultat par rapport au commit examiné et réaffecte ou supprime les éléments non concordants. L2, un juge LLM, regroupe les résultats par cause racine et supprime les groupes à faible confiance. Les deux couches sont à défaillance douce : une erreur conserve les résultats de l’étape précédente et n’interrompt jamais l’examen.

• Le contrôle s'applique. Les constats P0 et P1 font échouer le contrôle ; le résumé de la PR compte chaque constat, y compris ceux masqués dans le diff.

• Le compteur imprime ce que cela a coûté. Le compteur d’entrée enregistre le décompte des tokens par appel — prompt, complétion, tokens en cache, et le modèle que le routeur a résolu — et imprime un tableau des totaux dans le journal des tâches.

• Un rapport d'exécution facultatif envoie les décomptes de sévérité et les métadonnées de gate au plan de contrôle OrcaRouter pour le tableau de bord d'analyse. Il ne contient ni code, ni diff, ni texte de constatation.

Ce que vous configurez réellement

Il y a trois surfaces, et elles ont des rayons d'explosion très différents.

1. Le fichier de workflow. Le workflow consommateur est volontairement minimal. Les entrées qui méritent d’être modifiées se trouvent dans l’action : block-on (quelles sévérités font échouer le contrôle — par défaut P0,P1), fix-first (quelles sévérités interrompent prématurément une revue exhaustive), auto-review-authors (une liste blanche des personnes qui obtiennent une revue automatique), max-diff-kb et max-diff-files et on-oversized-diff (la protection contre les diffs trop volumineux), timeout-minutes, concurrency, meter, et report. Chacune a une valeur par défaut documentée, donc un nouveau workflow se résume à cinq lignes de YAML plus un secret.

2. Le tableau de bord. Avec settings: true (par défaut), chaque exécution récupère les paramètres par dépôt depuis OrcaRouter → Apps → OrcaCode Review : le modèle, le mode de revue, la politique de fusion, les sévérités de rapport, le mode silencieux, la revue exhaustive, une rubrique personnalisée et les garde-fous. Définissez settings: "false" et le fichier de workflow fait autorité — aucune valeur du tableau de bord ne peut le remplacer. Si vous n'ouvrez jamais la console, vous ne perdez rien du harnais ; vous configurez simplement en YAML.

3. La recette de routage — celle que l'on néglige.L'action ne nomme jamais de modèle. Elle injecte plutôt des faits bruts en tant qu'en-têtes de requête — le niveau sous lequel l'exécution a été enregistrée, si le passage précédent a trouvé un P0/P1, et un marqueur de lentille lorsque la requête est le juge L2 — et la recette DSL du routeur de l'espace de travail mappe ces en-têtes à un modèle concret. La recette fournie attribue par défaut la revue à DeepSeek V4 Flash et le juge à GLM-5.3, en les routant volontairement vers des modèles distincts. Modifier le modèle qui révise votre code revient à modifier cette recette dans votre propre espace de travail : pas d'incrémentation de version d'action, pas de réécriture de YAML, pas de redéploiement.

Le contrat de sévérité est composé de deux paramètres indépendants, et non d'un seul. La politique de fusion décide ce qui bloque la fusion ; les sévérités de rapport décident ce qui est publié sur le diff. Les réglages par défaut sont : P0/P1 bloquent, P2/P3 passent. Une sévérité qui bloque est toujours publiée, quelle que soit la configuration du rapport — un contrôle en échec sans rien sur le diff pour l'expliquer est pire qu'un contrôle bruyant. P0 signifie une faille de sécurité exploitable, une perte de données, un plantage sur un chemin normal, ou une compilation cassée ; P1 désigne un bug réel mais contenu ; P2 désigne un défaut réel qui ne se déclenche que sous une précondition anormale ; P3 est une question de style. En cas d'hésitation entre deux niveaux, la règle dit de choisir le plus bas.

Ce que ça coûte

Par jeton, pas par siège. Vous choisissez le modèle sur OrcaRouter, la facturation s’effectue par jeton consommé, et le compteur rend le nombre par exécution visible plutôt que mystérieux. Les mécanismes de GitHub, la revue de code facturée à la consommation de Copilot depuis le 1er juin 2026, et la façon dont les réviseurs tiers s’intègrent à ce flux de travail sont couverts dans notre guide de revue de code GitHub. La comparaison complète des coûts champ par champ — produits par siège vs produits par jeton, avec un exemple concret — figure dans notre comparatif des outils de revue de code IA, et la question de savoir ce qu’une seule passe de revue coûte en jetons lorsque le réviseur explore réellement le dépôt (la distinction bot vs agent) est traitée dans notre article sur les agents de revue de code. L’apport de cet article, c’est la forme de la facture : elle évolue avec le code que vous révisez, pas avec l’effectif qui révise.

Deux contrôles de dépenses comptent dès le premier jour. Sur un dépôt public, pull_request_target contourne la barrière d’approbation des forks de GitHub, et la clé de revue est comptée via le portefeuille — un inconnu peut ouvrir une PR et déclencher des revues payantes. Configurez un budget de portefeuille avec alertes sur la clé, puis définissez auto-review-authors sur quelque chose comme OWNER,MEMBER,COLLABORATOR,CONTRIBUTOR afin que les contributeurs inconnus ne soient pas examinés automatiquement. Et le garde-fou de diff, comme indiqué, fait que les PR trop volumineuses ne coûtent rien du tout.

Qu'est-ce qui casse

La révision automatisée, c'est la CI. Elle casse comme la CI, et les modes de défaillance ne sont pour la plupart pas imputables au modèle :

• Le workflow ne s'exécute jamais. Pour pull_request_target, le workflow est lu depuis la branche de base — un workflow ajouté uniquement dans la branche PR ne s'exécutera pas tant qu'il n'aura pas été fusionné. Vérifiez également que l'application est activée, que l'option auto_review est activée, que la PR n'est pas un brouillon (les brouillons sont ignorés en mode ready_for_review), et que Actions est activé sur le dépôt (les dépôts fork sont livrés avec cette option désactivée).

• /orcacode-review ne fait rien. Le déclencheur de commentaire exige que le commentaire commence par l'une des quatre orthographes — /orcacode-review, /orcacode review, @orcacode-review, @orcacode review — et l'auteur du commentaire doit être un PROPRIÉTAIRE, un MEMBRE ou un COLLABORATEUR. Un espace en début de ligne casse la correspondance. La commande d'un contributeur externe est silencieusement ignorée, intentionnellement : la commande exécute un workflow privilégié qui détient la clé payante.

• Une erreur d'authentification. Le secret est mal nommé ou manquant, la clé est révoquée ou hors budget, ou le workflow a été basculé vers pull_request (qui ne peut pas lire les secrets des forks).

• Le contrôle est rouge avec une mention “diff too large”. C'est la protection de taille, qui fonctionne comme configuré. Divisez la PR, ou augmentez les limites, ou définissez on-oversized-diff: pass — et comprenez qu'avec un contrôle requis, pass signifie qu'une PR suffisamment grande franchit directement la porte sans revue.

• La revue s'exécute mais aucun commentaire n'apparaît. Trois causes, toutes bénignes ou configurées : une exécution propre publie un résumé plutôt que des commentaires en ligne ; le mode silencieux masque P2 au moment de la publication (le contrôle et le rapport l'ont quand même compté) ; ou le filtre de précision a écarté les constatations — L1 écarte les constatations dont l'extrait ne correspond pas au commit, L2 écarte les clusters à faible confiance. Les décomptes de sévérité du journal de tâche vous indiquent laquelle.

La posture de sécurité mérite d'être énoncée clairement, car c'est elle qui rend l'ensemble du design sûr. Le moteur ne lit que les fichiers du diff et du dépôt ; il n'exécute jamais le code des PR. Le relecteur n'a aucune autorité de fusion — les constatations peuvent bloquer une fusion ou ajouter un commentaire, mais aucun chemin de code ne permet à la sortie du modèle d'approuver ou de modifier le dépôt. Une constatation non étiquetée échoue en mode sûr, traitée comme bloquante plutôt que consultative. Et le rapport d'exécution ne contient ni code ni texte de constatation. La configuration à deux couches qui détecte ce qu'une revue en un seul passage manque fait l'objet de notre article sur la sécurité de la revue de code par IA ; le modèle de menace ci-dessus est documenté dans le SECURITY.md du dépôt.

Lorsque la revue automatisée est le mauvais outil

C'est plus souvent faux que ne l'admettent les fournisseurs d'outillage. Ne vous engagez pas lorsque :

• Le problème, c’est le contexte, pas le volume. Si les revues sont lentes parce que les relecteurs doivent comprendre pourquoi le code a été écrit de cette façon, un LLM qui lit le diff n’apporte pas grand-chose. Il n’a aucune mémoire du fil du mois dernier ni aucune conscience de l’historique du système.

• Le diff est principalement du code généré ou importé. Sortie auto-formatée, fichiers d’échafaudage, instantanés de dépendances. Le passer en revue brûle des tokens et produit du bruit, et c’est exactement là où la directive de conventions aide le moins — le code n’est pas le style du projet par choix.

• L'équipe examine déjà tout en binôme. La revue automatisée est un levier de volume. Si chaque modification est déjà relue par une personne qui était dans la pièce, la machine ajoute un deuxième avis généralement moins informé que le premier.

• Personne ne lit les conclusions. Une revue à laquelle personne ne donne suite est un workflow qui échoue en restant vert indéfiniment. C'est l'échec silencieux le plus courant, et aucun filtre de précision n'y remédie.

• La revue doit exécuter le code.Si ce dont vous avez besoin est une suite de tests pour la PR, une revue LLM est le mauvais outil. Elle lit ; elle n'exécute pas. Un scan de sécurité qui nécessite de construire et d'exécuter l'artefact relève d'un job séparé, au périmètre soigneusement défini — rappelez-vous, le workflow de revue ne doit jamais être étendu pour exécuter du code contrôlé par la PR.

• Le dépôt est minuscule ou jetable. En dessous d'un certain rythme de modification, la revue génère plus de surcharge que les bugs qu'elle détecte.

Faux positifs, et ce que le filtrage de précision corrige et ne corrige pas.

L'accusation contre tout réviseur IA est qu'il crie au loup. Le harnais attaque cela sur deux niveaux, et il est utile d'être précis sur quel niveau corrige quelle défaillance.

La couche déterministe (L1) élimine la détection fantôme : un moteur prétend parfois que du code est présent alors qu’il n’y est pas — un extrait qui a dérivé, une détection copiée sur un fichier voisin. L1 vérifie l’extrait de code existant de chaque détection par rapport au commit réellement examiné et réaffecte ou supprime les discordances. Cela corrige la classe de faux positifs du type “cette ligne n’existe même pas”, qui est mécanique et vérifiable.

La couche de jugement (L2) élimine le doublon et l’affirmation non étayée : un juge LLM regroupe les constatations par cause racine et écarte les groupes dont la confiance passe sous le seuil du juge (par défaut 0,5). Cela corrige le “même bug signalé de trois façons” et la constatation spéculative.

Ce qu’aucune des deux couches ne corrige mérite d’être dit à voix haute. Une fausse mais confiante conclusion survit au juge — le juge est un LLM, et un LLM qui semble sûr de lui n’est pas la même chose qu’une conclusion vraie. Un juge qui tourne sur le propre modèle du relecteur est d’accord avec lui-même, et la validation devient inerte tout en continuant de rapporter un succès. C’est pourquoi la recette livrée achemine le juge vers un modèle différent de celui du relecteur. Et la grille de sévérité est délibérément prudente — « quand on hésite entre deux niveaux, choisir le plus bas » — ce qui signifie qu’un bug réel mais conditionnel a plus de chances d’atterrir comme avis P2 que comme P1 bloquant. C’est le bon calibrage pour un outil qui ne doit pas tout bloquer, mais c’est un calibrage : il échange des blocages manqués contre moins de fausses alertes. Le résumé de la PR recense toujours chaque constat, donc les P2 atténués restent là, à lire. Si le compromis ne convient pas à votre équipe, la grille et le seuil du juge sont de la configuration, pas un ticket de support.

En résumé

Pour une équipe qui vit déjà dans GitHub Actions, le harnais open-source est le moyen le moins cher d'obtenir une revue de code automatisée sur chaque PR : un fichier de workflow, un secret, une facture de tokens qui évolue avec le code examiné, et un choix de modèle qui vous appartient. Achetez un produit par utilisateur lorsque vous voulez zéro opération et un fournisseur à appeler — pas parce que la revue est meilleure, mais parce que vous achetez le problème de quelqu'un d'autre au lieu de gérer le vôtre. Et avant de mettre en place tout cela, demandez-vous si la revue sera lue. Le harnais peut faire en sorte que la revue ait lieu automatiquement. Il ne peut pas forcer quelqu'un à la lire.

Vous voulez le même réviseur sans avoir à l'exécuter vous-même ? OrcaCode Review exécute ce même harnais en tant qu'application GitHub hébergée — même recette ouverte, même facturation par jeton, aucun siège.