Relire et réviser du code avec un LLM local (revue avant commit)

#Pourquoi faire de la revue de code en local

Coller un diff dans ChatGPT pour se faire relire, c'est confortable — jusqu'au jour où ce diff contient une clé d'API, la logique métier d'un concurrent, ou du code couvert par un NDA. La révision de code par un LLM local règle ce problème à la racine : le modèle tourne sur votre machine, le code ne quitte jamais le port 11434.

Code propriétaire

Algorithmes maison, logique métier, secrets d'architecture : rien ne part vers un tiers qui pourrait le journaliser ou l'entraîner.

NDA et clauses de confidentialité

Beaucoup de contrats clients interdisent explicitement d'envoyer le code source à un service externe. Le local est souvent le seul choix conforme.

Zéro coût récurrent

Pas de facturation au token. Vous pouvez relire chaque commit, chaque branche, sans surveiller un compteur.

Fonctionne hors ligne

Dans un train, sur un site air-gap, derrière un proxy d'entreprise fermé : la revue reste disponible.

#Ce qu'un LLM détecte bien (et ce qu'il rate)

Avant de câbler quoi que ce soit, il faut caler ses attentes. Un modèle de code local est bon sur les erreurs locales et lisibles dans le diff, faible sur tout ce qui demande de connaître le reste du système.

Bien : bugs locaux

Off-by-one, condition inversée, variable non initialisée, ressource non fermée, oubli de gestion d'erreur.

Bien : failles évidentes

Injection SQL par concaténation, secret en dur, chemin non validé, désérialisation dangereuse, XSS basique.

Bien : lisibilité

Nommage confus, fonction trop longue, code mort, duplication visible dans le diff.

Faible : logique inter-fichiers

Il ne voit que le diff. Un contrat d'API cassé ailleurs, une invariant globale, un effet de bord distant lui échappent.

Faible : intention métier

Il ne sait pas ce que le code est censé faire. Il signale du plausible, pas forcément du juste.

Risque : faux positifs et hallucinations

Il peut inventer une faille inexistante ou proposer un correctif qui casse le comportement. Tout doit être vérifié.

#Prérequis

Ollama installé

Le daemon écoute par défaut sur http://localhost:11434. Si ce n'est pas encore fait, voir le guide d'installation d'Ollama.

Un dépôt Git

La revue s'appuie sur git diff, donc un projet versionné avec des changements à relire.

Un modèle de code

Un modèle orienté code téléchargé localement (voir la section suivante pour le choix selon votre VRAM).

GPU recommandé

Facultatif mais confortable : une RTX 3060 12 Go suffit pour un 14B en Q4. Le CPU seul fonctionne, en plus lent.

# Le daemon répond ?
curl http://localhost:11434/api/tags

# Télécharger un modèle de code (exemple 7B)
ollama pull qwen2.5-coder:7b

# Test rapide
ollama run qwen2.5-coder:7b "Relis ce code : def add(a,b): return a-b"

#Quels modèles locaux pour relire du code

Pour la révision de code, privilégiez un modèle spécialisé code plutôt qu'un généraliste : il comprend mieux la syntaxe, les idiomes et les pièges par langage. La taille se choisit selon votre VRAM, en Q4_K_M (le meilleur compromis qualité/mémoire).

qwen2.5-coder:7b — ~5 Go VRAM

Le point d'entrée. Rapide, tourne sur une RTX 3060 12 Go ou un Mac M-series d'entrée. Bon pour la relecture de petits diffs.

qwen2.5-coder:14b — ~9 Go VRAM

Le sweet spot pour la plupart des postes. Meilleur raisonnement sur les bugs subtils, reste fluide sur une 4070/4080.

qwen2.5-coder:32b — ~19 Go VRAM

Qualité nettement supérieure sur le raisonnement inter-fonctions. Demande une RTX 4090 24 Go ou un Mac à mémoire unifiée généreuse.

Alternatives

Devstral (orienté agent/édition) et deepseek-coder-v2 sont de bonnes options. Un généraliste 14B+ dépanne si vous n'avez qu'un modèle sous la main.

#Relecture manuelle en une commande

Avant d'automatiser, commencez par une revue manuelle à la demande. L'idée : envoyer le diff de vos changements non commités au modèle via l'API d'Ollama, et lire son retour dans le terminal. C'est la brique de base du hook qu'on posera juste après.

#!/usr/bin/env bash
# review.sh — relit les changements indexés (staged)
set -euo pipefail

DIFF=$(git diff --cached)
if [ -z "$DIFF" ]; then
  echo "Rien d'indexé à relire (git add d'abord)."
  exit 0
fi

PROMPT="Tu es un relecteur de code senior. Analyse ce diff Git et liste \
UNIQUEMENT les vrais problèmes (bugs, failles, cas limites). Format : \
- [gravité] fichier:ligne — problème puis correctif suggéré. \
Si le diff est correct, réponds 'RAS'. Diff :\n\n$DIFF"

jq -n --arg m "qwen2.5-coder:14b" --arg p "$PROMPT" \
  '{model:$m, prompt:$p, stream:false}' \
| curl -s http://localhost:11434/api/generate -d @- \
| jq -r '.response'

Rendez le script exécutable (chmod +x review.sh), indexez vos changements avec git add, puis lancez ./review.sh. Vous obtenez une liste de remarques que vous êtes libre d'ignorer ou de suivre. Rien n'est bloquant à ce stade — c'est de la revue assistée, pas un gardien.

#Poser un hook pre-commit avec Ollama, pas à pas

L'étape suivante : déclencher cette revue automatiquement à chaque git commit, via un hook pre-commit. Deux approches — un hook Git natif (zéro dépendance) ou le framework pre-commit. On détaille le hook natif, plus simple à comprendre et à auditer.

1. 01
   1. Créer le fichier de hook

   Les hooks Git vivent dans .git/hooks/. Créez .git/hooks/pre-commit (sans extension). Git l'exécute automatiquement avant de finaliser chaque commit ; un code de sortie non nul annule le commit.
2. 02
   2. Écrire le script de revue

   Le hook récupère le diff indexé, l'envoie à Ollama, et affiche le retour. Choisissez : soit purement informatif (n'annule jamais le commit), soit bloquant sur un mot-clé de gravité que le modèle émet.
3. 03
   3. Rendre le hook exécutable

   chmod +x .git/hooks/pre-commit — sans ça, Git l'ignore silencieusement.
4. 04
   4. Tester

   Faites un git add d'un fichier avec un bug volontaire, puis git commit. Le hook doit afficher la remarque du modèle avant de committer.
5. 05
   5. Partager avec l'équipe (optionnel)

   Les hooks dans .git/hooks/ ne sont pas versionnés. Pour les partager, versionnez un dossier .githooks/ et pointez-y avec git config core.hooksPath .githooks.

#!/usr/bin/env bash
# Revue LLM locale avant commit. Informatif par défaut.
set -euo pipefail

MODEL="qwen2.5-coder:14b"
DIFF=$(git diff --cached --diff-filter=ACM)
[ -z "$DIFF" ] && exit 0

PROMPT="Relecteur senior. Liste seulement les vrais bugs, failles ou cas \
limites de ce diff, format '- fichier:ligne — souci'. Termine par la ligne \
'VERDICT: OK' si rien de bloquant, sinon 'VERDICT: REVOIR'. Diff:\n\n$DIFF"

OUT=$(jq -n --arg m "$MODEL" --arg p "$PROMPT" \
  '{model:$m, prompt:$p, stream:false}' \
  | curl -s http://localhost:11434/api/generate -d @- \
  | jq -r '.response')

echo "────── Revue LLM locale ──────"
echo "$OUT"
echo "──────────────────────────────"

# Mode bloquant optionnel : décommentez pour refuser le commit
# if echo "$OUT" | grep -q 'VERDICT: REVOIR'; then
#   echo "Commit bloqué. Corrigez ou 'git commit --no-verify' pour forcer."
#   exit 1
# fi
exit 0

repos:
  - repo: local
    hooks:
      - id: revue-llm-locale
        name: Revue de code LLM locale (Ollama)
        entry: ./scripts/review.sh
        language: system
        stages: [pre-commit]
        pass_filenames: false

#Soigner le prompt de revue

La qualité de la révision de code par LLM dépend surtout du prompt. Un modèle mal cadré noie le signal sous des remarques de style inutiles. Trois principes rendent la sortie exploitable.

Restreindre le périmètre

Demandez explicitement d'ignorer le style et de ne signaler que bugs, failles et cas limites. Sinon vous obtenez dix remarques cosmétiques par diff.

Imposer un format

Un format strict (- fichier:ligne — souci) rend la sortie scannable et parsable si vous voulez l'exploiter plus tard.

Demander un verdict explicite

Une ligne finale du type 'VERDICT: OK/REVOIR' donne un signal binaire simple à tester dans un hook bloquant.

Donner le langage et le contexte

Précisez le langage et, si utile, la convention du projet. Le modèle adapte ses vérifications (par ex. gestion mémoire en C, promesses en JS).

#Limites honnêtes face à la revue humaine

Soyons clairs sur ce qu'un relecteur LLM local ne fait pas, pour éviter la fausse sécurité — le pire résultat serait de committer moins prudemment en croyant être couvert.

Vision limitée au diff

Il ne connaît pas le reste du dépôt. Un changement qui casse un appelant dans un autre fichier passe inaperçu. Les tests d'intégration restent indispensables.

Pas de compréhension métier

Il ne sait pas si le code fait ce que le ticket demande. Il valide la forme, pas l'intention. Un humain qui connaît le produit reste irremplaçable.

Faux positifs et hallucinations

Il peut inventer une faille ou un correctif erroné. Chaque remarque doit être vérifiée avant d'agir — ne corrigez jamais à l'aveugle.

Ne remplace pas les linters ni les tests

Un linter, un type-checker et une suite de tests attrapent des classes d'erreurs de façon déterministe. Le LLM les complète, il ne s'y substitue pas.

Dépend du modèle et du prompt

Un 7B mal promté rate des choses qu'un 32B bien cadré verrait. La qualité n'est pas garantie ni reproductible au token près.

#Pour aller plus loin

Pour approfondir le choix de modèle, l'intégration IDE ou la mémoire nécessaire, ces guides connexes du site prolongent celui-ci :

Meilleur LLM local pour coder en 2026

Le comparatif détaillé Devstral, Qwen3-Coder et alternatives, avec VRAM et vitesse par modèle.

Copilot gratuit en local dans VS Code

Aller au-delà de la revue en CLI : chat et refactoring dans l'IDE avec Cline, Tabby et CodeGeeX.

Choisir sa quantification (Q4, Q5, Q8, FP16)

Comprendre pourquoi le Q4_K_M est recommandé et comment faire tenir un 32B sur un GPU 16 Go.