Comment créer un agent de review de code automatisé avec GitHub Actions et des outils open source en 7 étapes

La review de code est le goulot d'étranglement numéro un des équipes de développement. Une étude GitHub de 2025 montre que les pull requests attendent en moyenne 4,3 jours avant d'être revuées — et 23% ne sont jamais revuées du tout. Pour les équipes de 3-5 développeurs à Paris, Lyon ou Bordeaux, ce délai coûte en productivité, en qualité de code et en motivation. La solution n'est pas de supprimer la review humaine — c'est de lui retirer les tâches mécaniques que les outils font mieux.

Un agent de review de code automatisé analyse chaque pull request dès qu'elle est ouverte : style, formatage, vulnérabilités connues, dépendances obsolètes, patterns dangereux, couverture de tests. Il poste ses résultats directement en commentaires sur la PR — exactement comme le ferait un collègue reviewer. Le développeur corrige les problèmes mécaniques avant même que le reviewer humain ne regarde le code. Résultat : la review humaine se concentre sur l'architecture, la logique métier et la lisibilité — les aspects à haute valeur ajoutée.

Ce guide vous montre comment construire cet agent en 7 étapes, entièrement avec des outils open source gratuits et GitHub Actions. Pas de SaaS payant, pas de dépendance propriétaire. Chaque étape inclut le workflow YAML complet et des exemples de configuration adaptés aux projets francophones. Si vous êtes développeur freelance ou lead tech dans une PME, vous pouvez mettre en place ce pipeline en un à deux jours de travail.

Étape 1 : Concevoir l'architecture du workflow

Avant d'écrire la première ligne de YAML, il faut définir l'architecture de votre agent de review. La question clé est : un seul workflow ou plusieurs workflows spécialisés ? La réponse dépend de la taille de votre équipe et de la complexité de votre codebase, mais pour la majorité des projets, nous recommandons une approche modulaire avec trois workflows distincts.

Le premier workflow, lint-format.yml, s'exécute sur chaque push et chaque pull request. Il vérifie le style du code (ESLint ou Biome), le formatage (Prettier), et les conventions de nommage. C'est le workflow le plus rapide — il doit finir en moins de 2 minutes pour ne pas bloquer les développeurs. Le deuxième workflow, security-analysis.yml, s'exécute uniquement sur les pull requests. Il lance Semgrep pour l'analyse de sécurité custom et CodeQL pour l'analyse statique avancée. Ce workflow peut prendre 5-10 minutes. Le troisième workflow, tests-coverage.yml, exécute les tests unitaires et d'intégration, et vérifie la couverture de code.

Pourquoi trois workflows plutôt qu'un seul ? Parce que GitHub Actions exécute les jobs d'un même workflow en parallèle, mais les workflows eux-mêmes sont indépendants. Si le linting échoue, les tests continuent de tourner — le développeur voit tous les problèmes en une seule itération au lieu de devoir relancer le workflow après chaque correction. C'est une différence subtile qui fait gagner 15-20 minutes par cycle de review sur un projet de taille moyenne.

# .github/workflows/lint-format.yml
name: Lint & Format Check
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main, develop]

permissions:
  contents: read
  pull-requests: write

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'
      - run: npm ci
      - run: npx eslint . --format json --output-file eslint-report.json || true
      - uses: reviewdog/action-eslint@v1
        with:
          reporter: github-pr-review
          eslint_flags: '--max-warnings 0'

  format:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'
      - run: npm ci
      - run: npx prettier --check .

Notez les permissions définies au niveau du workflow : contents: read et pull-requests: write. C'est le principe du moindre privilège — votre workflow ne peut pas modifier le code source, seulement poster des commentaires sur les PR. C'est une bonne pratique de sécurité que nous détaillons dans notre guide sur la sécurisation des pipelines GitHub Actions.

Étape 2 : Configurer le linting intelligent avec ESLint ou Biome

Le linting est la première ligne de défense de votre agent de review. Un bon linter détecte les variables inutilisées, les imports manquants, les types incorrects, les patterns dangereux comme eval() ou innerHTML, et les violations de conventions d'équipe. Pour les projets TypeScript, deux options dominent en 2026 : ESLint (le standard historique) et Biome (le challenger ultra-rapide).

ESLint reste le choix le plus sûr pour les projets existants. L'écosystème de plugins est immense : @typescript-eslint pour le typage, eslint-plugin-react pour React, eslint-plugin-security pour les patterns dangereux, eslint-plugin-import pour la gestion des imports. Le fichier eslint.config.mjs (format flat config, standard depuis ESLint 9) permet de définir des règles différentes par répertoire — utile pour les monorepos où le backend et le frontend ont des conventions différentes.

Biome est l'alternative si la vitesse est votre priorité. Écrit en Rust, il combine linting et formatage en un seul outil et traite les fichiers 10 à 30 fois plus vite qu'ESLint + Prettier. Pour une codebase de 500+ fichiers — typique d'une application Next.js d'une startup parisienne ou lyonnaise — la différence passe de 45 secondes (ESLint) à 2 secondes (Biome). Dans un workflow CI qui tourne 20 fois par jour, cela représente 14 minutes économisées quotidiennement.

// eslint.config.mjs — configuration recommandee
import eslint from '@eslint/js';
import tseslint from 'typescript-eslint';
import security from 'eslint-plugin-security';

export default tseslint.config(
  eslint.configs.recommended,
  ...tseslint.configs.strictTypeChecked,
  {
    plugins: { security },
    rules: {
      // Regles critiques pour la review automatisee
      'no-eval': 'error',
      'no-implied-eval': 'error',
      'security/detect-object-injection': 'warn',
      'security/detect-non-literal-regexp': 'warn',
      'security/detect-unsafe-regex': 'error',
      '@typescript-eslint/no-explicit-any': 'error',
      '@typescript-eslint/no-unused-vars': ['error', {
        argsIgnorePattern: '^_',
      }],
      // Convention equipe : pas de console.log en production
      'no-console': ['error', { allow: ['warn', 'error'] }],
    },
  },
);

Étape 3 : Imposer un formatage uniforme avec Prettier

Les débats sur le formatage — tabs vs spaces, point-virgules ou non, simple ou double quotes — consomment un temps disproportionné en review humaine. La solution est radicale : Prettier décide, tout le monde suit. En configurant Prettier dans votre pipeline CI, vous éliminez 100% des commentaires de review liés au formatage. Zéro discussion, zéro exception.

Le workflow vérifie que le code poussé est correctement formaté avec prettier --check .. Si un fichier n'est pas formaté, le workflow échoue et le développeur doit lancer prettier --write . localement avant de repousser. Pour éviter cet aller-retour, configurez un hook pre-commit avec Husky et lint-staged : Prettier s'exécute automatiquement sur les fichiers modifiés avant chaque commit. Le workflow CI devient alors un filet de sécurité — il attrape les rares cas où le hook a été contourné.

// .prettierrc — configuration standard pour les equipes FR
{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "all",
  "printWidth": 100,
  "arrowParens": "always",
  "endOfLine": "lf"
}

Conseil pratique pour les équipes à Nantes, Toulouse ou Lille qui migrent vers Prettier : lancez prettier --write . une seule fois sur toute la codebase, commitez le résultat dans une PR dédiée ("chore: apply prettier formatting"), et activez le check CI immédiatement après. Faire la migration en une seule PR évite les conflits de merge interminables.

Étape 4 : Ajouter l'analyse de sécurité avec Semgrep et CodeQL

Le linting et le formatage attrapent les problèmes de style. L'analyse de sécurité attrape les problèmes qui peuvent coûter de l'argent, des données ou de la réputation. Deux outils open source couvrent l'essentiel : Semgrep pour les règles personnalisées et CodeQL pour l'analyse dataflow.

Semgrep est un scanner d'analyse statique qui utilise des patterns textuels pour trouver des vulnérabilités. Sa force est la simplicité des règles : vous écrivez le pattern du code vulnérable, et Semgrep le trouve dans votre codebase. Par exemple, une règle qui détecte l'utilisation de dangerouslySetInnerHTML dans un composant React sans sanitisation prend 5 lignes de YAML. Semgrep fournit également un registre public de règles communautaires — plus de 3 000 règles couvrant Python, JavaScript, TypeScript, Go, Java et d'autres langages.

CodeQL est le moteur d'analyse statique de GitHub, intégré nativement dans GitHub Actions. Il va plus loin que Semgrep en effectuant une analyse dataflow : il trace le parcours des données depuis les sources (entrées utilisateur, variables d'environnement) jusqu'aux sinks (requêtes SQL, commandes système, sorties HTML). Si une donnée non sanitizée atteint un sink dangereux, CodeQL la signale. Cette analyse détecte des vulnérabilités que le linting et les patterns Semgrep manquent — comme une injection SQL qui traverse trois fichiers et deux fonctions avant d'atteindre la requête.

# .github/workflows/security-analysis.yml
name: Security Analysis
on:
  pull_request:
    branches: [main, develop]

permissions:
  contents: read
  security-events: write
  pull-requests: write

jobs:
  semgrep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: returntocorp/semgrep-action@v1
        with:
          config: >-
            p/default
            p/typescript
            p/react
            p/security-audit
          generateSarif: '1'
      - uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: semgrep.sarif

  codeql:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: javascript-typescript
          queries: security-and-quality
      - uses: github/codeql-action/analyze@v3

Étape 5 : Intégrer les tests automatisés et la couverture de code

Le troisième pilier de votre agent de review est l'exécution automatique des tests. Pas besoin de réinventer la roue ici — l'objectif est de s'assurer que chaque PR passe les tests existants et que la couverture de code ne régresse pas. Le workflow lance npm test (ou vitest run --coverage pour les projets Vitest) et échoue si un test casse ou si la couverture descend en dessous d'un seuil défini.

Pour les équipes qui débutent avec les tests, notre recommandation est pragmatique : fixez un seuil de couverture bas au départ (50%) et augmentez-le de 5% par trimestre. Imposer 80% de couverture sur une codebase qui en a 20% est contre-productif — les développeurs écriront des tests inutiles juste pour passer le seuil. En revanche, un seuil progressif crée une amélioration continue sans friction.

# .github/workflows/tests-coverage.yml
name: Tests & Coverage
on:
  pull_request:
    branches: [main, develop]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'
      - run: npm ci
      - run: npx vitest run --coverage --reporter=json --outputFile=test-results.json
      - uses: davelosert/vitest-coverage-report-action@v2
        if: always()
        with:
          json-summary-path: coverage/coverage-summary.json
          json-final-path: coverage/coverage-final.json

Étape 6 : Poster les résultats sur la PR avec reviewdog

reviewdog est l'outil qui transforme votre pipeline CI en véritable agent de review. Au lieu d'afficher les erreurs dans les logs du workflow — que personne ne lit — reviewdog les poste directement en commentaires inline sur la pull request, exactement là où le problème se trouve dans le code. Le développeur voit l'erreur dans le diff, comprend le contexte, et corrige immédiatement.

reviewdog supporte tous les formats de sortie courants : ESLint JSON, SARIF (Semgrep, CodeQL), JUnit XML (tests), et un format générique pour les outils custom. Il peut poster en mode github-pr-review (commentaires inline avec suggestion de correction), github-pr-check (annotations dans l'onglet Checks), ou github-check (status checks bloquants). Pour un agent de review complet, nous recommandons github-pr-review — c'est le mode le plus visible et le plus actionnable pour les développeurs.

Un point important pour les équipes à Marseille, Strasbourg ou Rennes qui gèrent des projets privés : reviewdog nécessite un GITHUB_TOKEN avec les permissions pull-requests: write. Le token par défaut fourni par GitHub Actions a ces permissions si vous les déclarez dans le bloc permissions du workflow. Pas besoin de créer un PAT (Personal Access Token) séparé — c'est plus simple et plus sécurisé.

Étape 7 : Configurer les alertes de maintenance et la mise à jour des règles

Un agent de review qui n'est pas maintenu devient un obstacle. Les règles ESLint évoluent, Semgrep publie de nouveaux patterns de vulnérabilités, les actions GitHub reçoivent des mises à jour de sécurité. Sans maintenance, votre agent rate des vulnérabilités récentes ou génère des faux positifs sur du code valide — et les développeurs commencent à l'ignorer.

La solution est un workflow de maintenance trimestriel qui vérifie automatiquement les mises à jour disponibles. Configurez Dependabot pour surveiller les actions GitHub (dans .github/dependabot.yml) et les dépendances npm. Ajoutez une alerte Slack ou email quand Dependabot crée une PR de mise à jour. Et planifiez un créneau trimestriel de 2-3 heures pour revoir les règles ESLint et Semgrep, supprimer les faux positifs récurrents, et ajouter des règles pour les nouveaux patterns de vulnérabilités.

# .github/dependabot.yml
version: 2
updates:
  # Mise a jour des actions GitHub
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
    labels:
      - "dependencies"
      - "ci"

  # Mise a jour des dependances npm
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    labels:
      - "dependencies"
    open-pull-requests-limit: 10

Dernière recommandation : épinglez vos actions GitHub par hash SHA plutôt que par tag. Au lieu de actions/checkout@v4, utilisez actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11. Cela protège contre les attaques supply chain où un attaquant compromet le tag d'une action pour injecter du code malveillant. Nous avons documenté ce risque en détail dans notre article sur les attaques supply chain GitHub Actions.

Bonnes pratiques et pièges à éviter

Après avoir configuré des dizaines de pipelines de review automatisée pour des équipes à Paris, Lyon, Nantes et Bruxelles, voici les leçons apprises.

Ne bloquez pas le merge pour les avertissements. Votre agent doit avoir deux niveaux : les erreurs (vulnérabilités de sécurité, tests cassés, types incorrects) bloquent le merge. Les avertissements (style, complexité élevée, couverture en baisse) sont signalés mais ne bloquent pas. Si tout bloque, les développeurs contournent l'agent — et vous perdez la confiance de l'équipe.

Commencez avec peu de règles et augmentez progressivement. Un agent qui remonte 200 erreurs sur la première PR sera désactivé le jour même. Démarrez avec les règles critiques (sécurité, types, tests) et ajoutez une catégorie par sprint. En trois mois, vous aurez un agent complet que l'équipe respecte.

Mesurez l'impact. Avant d'activer l'agent, notez votre temps moyen de merge et le nombre de bugs en production par mois. Après trois mois, comparez. Les équipes que nous accompagnons constatent typiquement une réduction de 60-70% du temps de review et une baisse de 40% des bugs en production. Ces chiffres justifient l'investissement initial auprès du management.

Documentez les règles custom. Chaque règle Semgrep ou ESLint custom doit avoir un commentaire expliquant pourquoi elle existe — pas seulement ce qu'elle fait. Quand un développeur voit "Erreur: pattern interdit" sans explication, il contourne la règle. Quand il voit "Erreur: SQL non-paramétrisé — risque d'injection (voir CVE-2026-XXXX)", il comprend et corrige.

FAQ — Questions fréquentes