Santiago.

🔒 Un cadenas pour le vibe coding : un relecteur de PR avec Claude

3 octobre 2026 · 8 min de lecture

Je travaille sur un projet et il m'est arrivé quelque chose qui m'a beaucoup plu : Claude, exécuté dans GitHub Actions, a relu et corrigé mes pull requests (PR). J'ai trouvé ça très bien et très efficace, au point de vouloir comprendre comment ça marche pour vous le raconter ici. Pour moi, c'est comme un cadenas 🔒 pour le vibe coding : il permet d'avancer vite, mais garantit que rien ne passe à travers.

🧠 Le problème : l'agent perd le contexte

Quand on programme avec l'IA, ce que l'on appelle déjà le vibe coding (dire à l'IA ce que l'on veut et la laisser écrire le code, souvent en l'acceptant sans le relire à fond), l'agent avec lequel on programme se perd parfois dans les petits détails. On a beau essayer de toujours lui donner du contexte, plus la session s'allonge, plus il le perd, et certaines choses lui échappent : une règle métier, un cas limite, un fichier qui dépendait aussi de ce qui a changé.

Le relecteur fonctionne autrement. Il démarre à chaque fois l'esprit clair, avec une seule mission : relire cette pull request. Il ne traîne pas des heures de conversation, et c'est pourquoi, d'après mon expérience, il est beaucoup plus efficace pour trouver ce que l'agent de programmation a laissé passer.

🤖 De quoi s'agit-il ?

Claude Code GitHub Actions est une Action GitHub (anthropics/claude-code-action) qui exécute Claude Code dans les workflows de votre dépôt. Elle fonctionne de deux façons :

  • Interactive : vous mentionnez @claude dans un commentaire de PR ou d'issue et il répond sur place.
  • Automatique : vous lui donnez un prompt et elle s'exécute seule quand il se passe quelque chose dans le dépôt, par exemple à chaque ouverture d'une pull request.

Pour un relecteur, c'est la seconde qui nous intéresse.

Attention à une différence : le relecteur que nous montons plus bas commente, il ne modifie pas le code. Si vous voulez aussi que Claude fasse la correction, mentionnez-le avec @claude, et pour qu'il puisse pousser des modifications le workflow a besoin de permissions d'écriture (contents: write et pull-requests: write).

⚙️ Comment la mettre en place

⚡ La voie rapide. Ouvrez claude dans votre dépôt et lancez /install-github-app. La commande installe l'application GitHub, enregistre le secret d'authentification et prépare une pull request avec les workflows. Il faut être administrateur du dépôt, avoir authentifié le GitHub CLI (gh auth login), et le dépôt doit être sur github.com.

🛠️ La voie manuelle. Trois étapes :

  1. Installer l'application Claude sur votre dépôt.
  2. Enregistrer un secret : ANTHROPIC_API_KEY (clé d'API) ou CLAUDE_CODE_OAUTH_TOKEN (si vous utilisez un abonnement).
  3. Créer un workflow dans .github/workflows/.

Ce workflow relit chaque pull request quand elle est ouverte ou mise à jour, avec le plugin de relecture officiel :

name: Code Review
on:
  pull_request:
    types: [opened, synchronize, ready_for_review, reopened]
jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: read
      issues: read
      id-token: write
    steps:
      - uses: actions/checkout@v6
        with:
          fetch-depth: 1
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          plugin_marketplaces: "https://github.com/anthropics/claude-code.git"
          plugins: "code-review@claude-code-plugins"
          prompt: "/code-review:code-review --comment ${{ github.repository }}/pull/${{ github.event.pull_request.number }}"
          claude_args: '--allowedTools "mcp__github_inline_comment__create_inline_comment"'

Ce qui compte dans chaque partie :

  • on: pull_request : il se déclenche à l'ouverture, à la mise à jour, à la réouverture ou quand une PR est marquée comme prête.
  • plugins et prompt : ils installent le plugin code-review et lancent sa relecture sur cette PR.
  • --comment : Claude publie la relecture sur la PR elle-même, avec un commentaire en ligne pour chaque problème, ou un commentaire de synthèse s'il ne trouve rien. Sans cette option, vous ne verriez le résultat que dans le journal d'exécution.
  • claude_args : gardez cette ligne, car c'est elle qui active les commentaires en ligne.
  • Claude ignore les PR en brouillon, les PR fermées, les PR triviales et celles qui ont déjà un commentaire de sa part.

🎯 Ce qui compte le plus : le prompt du relecteur

C'est la différence entre un relecteur qui ne fait que du bruit et un qui vous aide vraiment. La qualité du relecteur dépend en grande partie du prompt que vous lui donnez. Le plugin officiel est déjà livré avec le sien, mais si vous voulez un relecteur qui connaisse votre métier et votre architecture, vous écrivez le vôtre (ou un skill). D'après mon expérience, voici ce qu'il faut lui fournir :

  • 💼 Le contexte métier. Ce que fait le produit et pour qui, les flux critiques et les règles à ne jamais enfreindre : comment les montants sont calculés, qui peut voir ou modifier quoi, quels états sont valides. Sans cela, le relecteur ne voit que du code ; avec cela, il voit si le code fait ce dont le métier a besoin.
  • 🏗️ Le contexte d'architecture. Les couches et leurs responsabilités, les conventions, les modèles à respecter et ce qui est interdit, par exemple mettre de la logique métier dans les contrôleurs. Si vous avez des documents d'architecture ou des décisions consignées, indiquez-les-lui.
  • 📋 Quoi relire et dans quel ordre. D'abord ce qui coûte le plus cher : erreurs de logique et cas limites, sécurité, intégrité des données, risque de casser d'autres parties et tests manquants.
  • 🚫 Quoi ignorer. Le format et le style déjà vérifiés par le linter, et les préférences personnelles. Sinon, il remplit votre PR de bruit.
  • 🔍 Qu'il regarde au-delà du diff. Demandez-lui de vérifier qui utilise ce qui a changé, pas seulement les lignes modifiées. Beaucoup d'erreurs se trouvent dans ce que le diff ne montre pas.
  • 💬 Comment répondre. Qu'il classe chaque constat (bloquant, important ou suggestion), qu'il indique le fichier et la ligne, l'impact et la correction proposée. Qu'il signale un doute plutôt que d'inventer, et que, si tout va bien, il le dise en une seule phrase.

Un modèle pour commencer :

Tu es le relecteur senior de ce dépôt. Relis la pull request en cours.

Contexte métier :
- Ce que fait le produit et pour qui.
- Règles critiques : comment les montants sont calculés, qui peut voir
  ou modifier quoi, états valides de chaque processus.

Contexte d'architecture :
- Couches et responsabilités (API, services, accès aux données).
- Conventions et modèles à respecter.
- Ce qui est interdit (par exemple, de la logique métier dans les contrôleurs).

Quoi relire, dans cet ordre :
1. Erreurs de logique et cas limites.
2. Sécurité et gestion des données sensibles.
3. Intégrité des données et transactions.
4. Risque de casser d'autres parties : vérifie qui utilise ce qui a
   changé, pas seulement le diff.
5. Tests manquants.

Quoi ignorer : le format et le style déjà vérifiés par le linter, et
les préférences personnelles.

Comment répondre :
- Classe chaque constat comme bloquant, important ou suggestion.
- Indique le fichier et la ligne, explique l'impact et propose la correction.
- Si tu n'es pas sûr, signale-le comme un doute ; n'invente pas.
- Si tout va bien, dis-le en une seule phrase.

Où le mettre, selon votre façon de travailler :

  • Dans le prompt du workflow. Avec un texte à vous, Claude n'a pas accès au shell ni à l'API de GitHub tant que vous ne lui donnez pas les outils nécessaires avec --allowedTools dans claude_args. Indiquez-lui aussi quelle PR relire : le numéro est dans ${{ github.event.pull_request.number }}.
  • Dans un skill du dépôt. Vous le rangez dans .claude/skills/, vous faites d'abord le checkout et vous passez /nom-du-skill comme prompt. Ainsi, le prompt est versionné et relu comme n'importe quel autre code.
  • Dans CLAUDE.md. C'est l'endroit pour le style de code, les critères de relecture et les règles du projet. Claude le lit à chaque exécution. Gardez-le court, car il est lu à chaque fois.

Et n'attendez pas que ce soit parfait du premier coup. Regardez quels faux positifs il vous donne, ce qui lui échappe, et ajustez le prompt. C'est un travail itératif, comme pour régler n'importe quel autre outil.

🛡️ Précautions à ne pas oublier

  • 🔑 Secrets : ne poussez jamais de clés dans le dépôt ; stockez-les comme secrets GitHub.
  • 🔐 Permissions minimales : donnez au workflow seulement ce dont il a besoin. Dans l'exemple, lecture seule du code, des PR et des issues, plus id-token: write, dont l'Action a besoin pour s'authentifier. Si vous voulez que Claude pousse des corrections, il lui faudra l'écriture : ne l'accordez qu'au workflow qui l'exige.
  • 💰 Coûts : chaque exécution consomme des minutes GitHub Actions et des tokens d'API (ou votre abonnement, si vous vous authentifiez avec un jeton OAuth). --max-turns, les délais d'expiration et le contrôle de la concurrence aident à les limiter.
  • 🌐 Dépôts publics : GitHub ne transmet pas les secrets aux exécutions déclenchées par des PR venant de forks.
  • 🧑‍💻 C'est vous qui décidez : le relecteur ne remplace pas le jugement humain. Relisez ses commentaires et les modifications de Claude avant de fusionner.

Si vous ne voulez pas maintenir un workflow, il existe aussi Code Review, le produit de Claude qui relit automatiquement chaque pull request sans que vous en écriviez un.

💡 Ma conclusion

🔒 Le vibe coding est puissant, mais il a besoin de son cadenas. Pour moi, l'IA n'enlève pas la responsabilité : elle la partage mieux. J'écris avec l'aide de l'IA, un relecteur à l'esprit clair et bien contextualisé relit, et c'est moi qui décide. C'est cette combinaison qui me permet d'avancer vite l'esprit tranquille.

✍️ Par Santiago Perea Restrepo

← Retour