LLM Local en CI/CD : Révision de Code Automatisée Sans Cloud

Faits Rapides

• Modèle recommandé: Qwen3-Coder 30B à Q4_K_M (~17 GB VRAM, Apache 2.0).
• Exécution recommandée: Ollama pour la simplicité de configuration ; vLLM si vous avez besoin d'une concurrence plus élevée sur le même GPU.
• GPU minimum pour les équipes sérieuses: RTX 4090 (24 GB). Les cartes plus petites forcent le modèle 7B et une qualité de révision notablement pire.
• Concurrence sur un seul GPU 24 GB: confortablement 1–3 révisions simultanées sur Qwen3-Coder 30B ; queue au-delà.
• Cible de latence: moins de 30 secondes pour une différence de 200 lignes. Au-delà, le comportement de l'auteur RP change et les révisions sont contournées.
• Posture d'audit: zéro sortie sortante sur le serveur GPU est prouvable ; la surface entière est ollama serve + un seul fichier journal.
• Parité avec GitHub Advanced Security (19 $/dev/mois): 15–25 sièges payants couvrent une génération RTX 4090 en 5–10 mois.
• Parité GitLab CI: architecture identique, remplacez l'action GitHub par un travail CI appelant le même point de terminaison HTTP.

Comparaison d'Architecture : Trois Véritables Options pour la Révision de Code en CI

La Stack Recommandée : Ollama + Qwen3-Coder + une Action GitHub Légère

• Serveur GPU exécutant Ollama (ou vLLM pour une concurrence plus élevée). Ollama expose une API HTTP compatible OpenAI sur localhost:11434 par défaut ; liez-la à une interface réseau privée ou à un proxy inverse avec auth avant d'exposer aux exécuteurs.
• Modèle optimisé pour le codage: Qwen3-Coder 30B à Q4_K_M est la norme de mai 2026 — plus forte direction open-weight coding, contexte 256K, licence Apache 2.0, s'adapte à une GPU 24 GB. Pour les GPU 8–16 GB, utilisez Qwen3-Coder 7B en comprenant que la qualité de révision baisse notablement.
• Intégration CI: un exécuteur GitHub Actions auto-hébergé sur le même réseau que le serveur GPU, ou vos exécuteurs GitHub-hébergés existants atteignant le serveur GPU via un réseau privé (Tailscale, WireGuard ou appairage VPC).
• Action GitHub personnalisée (JavaScript ou composite) qui récupère la différence RP via l'API GitHub, la POSTE au point de terminaison Ollama avec un prompt de révision, analyse la réponse structurée et poste les commentaires en ligne de la RP.
• Optionnel: un petit cache Redis ou SQLite codé par hash fichier + hash diff pour éviter les re-révisions de fichiers inchangés dans les exécutions CI suivantes.
• Parité GitLab: la même architecture, avec un travail GitLab CI remplaçant l'action GitHub. L'appel LLM est identique.

Un Flux de Travail GitHub Actions Fonctionnant

• L'exécuteur doit pouvoir atteindre OLLAMA_HOST via le réseau — auto-hébergé sur le même VPC, ou via Tailscale / WireGuard si le serveur GPU est ailleurs.
• Le prompt système impose une réponse JSON structurée pour que l'action puisse se brancher sur le verdict proprement. Sans format: "json" et un schéma strict dans le prompt, vous passerez du temps opérationnel à analyser la sortie free-form.
• Le checkout fetch-depth: 0 est nécessaire pour calculer une vraie diff contre la branche de base — les checkouts superficiels produisent des diffs malformées.
• Pour les dépôts au-dessus d'environ 50K lignes de code modifié par RP, tronquez ou fragmentez la diff avant d'envoyer. Le contexte 256K sur Qwen3-Coder 30B est généreux, mais le contexte de travail pratique est plus proche de 64K–128K (voir Best Local Coding Models in 2026).
• Pour la profondeur du design de prompt — prompts système vs utilisateur, exemples, résultats structurés — voir System Prompt vs User Prompt: What's the Difference.

# .github/workflows/local-llm-review.yml
name: Local LLM Code Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: self-hosted   # ou n'importe quel exécuteur pouvant atteindre OLLAMA_HOST
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Generate diff
        id: diff
        run: |
          git diff origin/${{ github.base_ref }}...HEAD > /tmp/pr.diff
          echo "size=$(wc -c < /tmp/pr.diff)" >> "$GITHUB_OUTPUT"

      - name: Call local LLM for review
        id: review
        env:
          OLLAMA_HOST: ${{ secrets.OLLAMA_HOST }}   # ex. http://gpu-server.internal:11434
        run: |
          DIFF=$(jq -Rs . < /tmp/pr.diff)
          curl -sS "$OLLAMA_HOST/api/chat" \
            -H 'Content-Type: application/json' \
            -d "{
              \"model\": \"qwen3-coder:30b\",
              \"stream\": false,
              \"format\": \"json\",
              \"messages\": [
                {\"role\": \"system\", \"content\": \"You are a senior code reviewer. Return JSON: {verdict: 'approve'|'comment'|'block', summary: string, comments: [{path, line, severity, message}]}\"},
                {\"role\": \"user\", \"content\": $DIFF}
              ]
            }" > /tmp/review.json
          echo "verdict=$(jq -r '.message.content | fromjson | .verdict' < /tmp/review.json)" >> "$GITHUB_OUTPUT"

      - name: Post review comment
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const review = JSON.parse(JSON.parse(fs.readFileSync('/tmp/review.json')).message.content);
            const body = `### Local LLM Review: \`${review.verdict}\`\n\n${review.summary}`;
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              body
            });

      - name: Block on critical verdict
        if: steps.review.outputs.verdict == 'block'
        run: exit 1

Dimensionnement du Matériel par Taille d'Équipe

Partage GPU Across Builds et Autres Charges

• GPU dédiée pour la révision seulement: modèle le plus simple. La latence est prévisible ; la planification de capacité est simple ; les modes de défaillance sont isolés. La recommandation pour toute équipe n'exécutant pas déjà une infra GPU.
• GPU partagée avec inférence ML: faisable si la charge inférence a une enveloppe stable (par ex., un petit service d'intégration s'adaptant à 4–6 GB). Le modèle de révision occupe le reste du VRAM. Les collisions de planification sont rares sur ce motif.
• GPU partagée avec entraînement ML: fortement déconseillé. Les travaux d'entraînement font sauter l'utilisation du VRAM au limite et affament le modèle de révision, causant des latences de révision de 30–120 secondes qui érodent la confiance des développeurs dans le système.
• vLLM avec attention paginée: purpose-built pour le service LLM haute-concurrence. La même RTX 4090 qui gère 1–3 révisions simultanées sous Ollama peut gérer 4–8 sous vLLM, au prix d'une configuration plus complexe. Ça vaut le coup au-delà de 25 développeurs.
• Multi-tenant sur H100: à l'échelle 100+ développeurs, partitionnez un H100 en tranches MIG ou exécutez vLLM avec des quotas par tenant. C'est du territoire plateforme-engineering ; n'improvisez pas.

Comparaison des Coûts avec GitHub Advanced Security

• GitHub Advanced Security (Code Security): 19 $/développeur/mois au prix catalogue (vérifiez sur la page de tarification GitHub ; les remises de volume sont disponibles pour les clients enterprise).
• API LLM Cloud (ex. OpenAI, Anthropic): environ 50–200 $/mois par développeur actif au volume RP typique ; varie énormément selon la taille de la base de code et la conception du prompt de révision.
• Self-Hosted Local LLM, build RTX 4090: environ 2 299 € de matériel une seule fois (GPU + un boîtier serveur de base). Consommation électrique : ~50W au repos, ~350W sous charge — disons env. 18–28€/mois en électricité à l'utilisation typique. Pas de frais par siège.
• Parité à 10 développeurs: GHAS 190 $/mois vs self-hosted env. 25€/mois exploité + env. 2 299 € capex. Capex se rentabilise en ~14 mois.
• Parité à 25 développeurs: GHAS 475 $/mois vs self-hosted env. 25€/mois exploité + env. 2 299 € capex. Capex se rentabilise en ~5–6 mois.
• Parité à 50 développeurs: GHAS 950 $/mois vs self-hosted env. 40€/mois exploité + env. 7 500 € capex (GPU 48 GB). Capex se rentabilise en ~8 mois.
• Le chiffre capex domine les mathématiques. Si vous achetez une GPU spécifiquement pour cela, la rentabilité est réelle. Si vous avez une capacité GPU existante, le coût marginal est plus proche de zéro et l'auto-hébergement gagne immédiatement.

Modèle de Sécurité et Posture d'Audit

• Le modèle ne voit que la diff que votre action envoie. Pas de télémétrie, pas d'appels réseau cachés. Confirmable avec tcpdump ou nft monitor sur l'interface sortante du serveur GPU — sous opération état-stable, vous devriez voir zéro paquets sortants vers les hôtes non-internes.
• La surface d'audit complète est un processus et un fichier journal. ollama serve est l'intégralité de la pile LLM. Ses logs (corps de requête, latence, événements de chargement de modèle) sont l'enregistrement d'audit. Pas de tableau de bord SaaS à interroger, pas de politique de conservation tiers à lire.
• L'isolement du réseau est simple. Liez ollama serve à une interface privée ; mettez un proxy inverse avec auth mTLS ou shared-secret devant ; refusez sortant sur le namespace réseau du serveur GPU sauf vers votre sous-réseau exécuteur CI. Motif zero-trust standard, pas de magie LLM-spécifique.
• Les poids du modèle sont des artefacts statiques signés par le vendeur. Tirez-les une seule fois via Ollama, épinglez le digest et le modèle ne peut pas changer sans action opérateur. C'est une histoire de chaîne d'approvisionnement plus forte qu'une API SaaS où le modèle amont peut être silencieusement échangé.
• Posture de conformité: zéro sortie de données est simple à documenter pour SOC 2, ISO 27001, GDPR et la classification EU AI Act limited-risk. La partie la plus difficile de la conformité auto-hébergée est généralement de documenter le serveur d'inférence lui-même ; Ollama et vLLM sont tous deux bien documentés.
• Le modèle voit toujours votre code. L'auto-hébergé ne signifie pas privé du modèle — cela signifie privé des tiers. Les scénarios d'insider-threat (ingénieur avec accès serveur GPU lit les logs contenant les diffs RP passées) sont toujours dans le scope ; rotez les logs et limitez l'accès en conséquence.

Conception de Prompt pour la Révision de Code

• La sortie structurée est non-négociable. Imposez JSON avec un schéma strict (verdict, summary, comments[]). Sans cela, l'action passe 30% de son code à analyser la sortie free-form et les modes de défaillance sont subtils.
• Pour le guide complet sur l'application de la sortie structurée sur les modèles, voir structured output and JSON mode.
• Les seuils de sévérité appartiennent au prompt, pas à l'action. Dites au modèle ce qui compte comme critique, haut, moyen, bas ; dites-lui de filtrer les résultats bas-sévérité sauf explicitement demandés. C'est beaucoup plus fiable que le filtrage post-hoc sur un champ sévérité free-form.
• Ancrez le prompt avec des exemples. Un prompt 1–2-shot avec une diff réelle et une JSON de révision idéale surpasse massif zero-shot pour le même modèle et la même taille de diff.
• Distinguez l'intention "révision" de "commentaire". Un commentaire critique ("envisagez d'extraire ceci vers un helper") et un blocker ("ceci introduit une injection SQL") ont besoin d'actions différentes en CI. Tagguez-les dans la sortie structurée et faites bloquer l'action seulement sur les bloqueurs.
• Les variantes de prompt par langue aident au-delà d'une certaine taille. Une base de code polyglotte bénéficie d'un prompt qui référence les idiomes de langue pertinents (Pythonic vs Rust idiomatique). C'est optionnel au-dessous d'environ 25 développeurs ; précieux au-dessus.
• Pour l'ancrage de l'ingénierie de prompt plus profond — prompts système vs utilisateur, résultats structurés, few-shot prompting — voir System Prompt vs User Prompt: What's the Difference.

Gestion des Faux Positifs Sans Éroder la Confiance des Développeurs

• Fixez un seuil "block" haut. Un verdict block qui s'active sur chaque problème lint mineur entraîne les développeurs à contourner la vérification. Réservez block aux problèmes de sécurité, aux tests cassés et aux défaillances de correctness clairs.
• Rendez les commentaires non-bloquants bon marché. Les commentaires en ligne où le modèle est incertain devraient être tagués ("tentative" / "envisager") pour que les auteurs puissent les rejeter rapidement sans cérémonie.
• Construisez une boucle de rétroaction au mois un. Ajoutez une réaction (👍 / 👎) à chaque commentaire de révision. Périodiquement (hebdomadairement fonctionne) examinez les 👎s et mettez à jour le prompt système avec des instructions explicites "ne pas signaler X" pour les catégories les plus courantes de faux positifs.
• Taux-limites le volume de commentaires par RP. Une seule RP ne devrait pas recevoir plus de 5–10 commentaires du LLM ; au-delà, le rapport signal-bruit s'effondre. Limitez l'action au niveau du prompt ("retour au maximum N commentaires").
• Suivez la corrélation verdict-to-merge hebdomadairement. Si 80% des verdicts block fusionnent de toute façon, votre seuil est trop agressif. Si 0% des verdicts comment obtiennent toute action humaine, votre prompt produit du bruit.

Pièges Opérationnels au Deuxième Mois

• Les mises à jour de modèle cassent les prompts. Une nouvelle version Qwen3-Coder change subtilement le formatage de sortie ; l'analyse JSON structurée échoue en CI ; les révisions cessent de poster. Épinglez le digest du modèle avec ollama show <model> --modelfile ; mettez à niveau dans une branche staging avant de promouvoir.
• Fragmentation mémoire GPU sous longue uptime. Un serveur GPU exécutant 24/7 peut fragmenter le VRAM et refuser les allocations nouvelles après des semaines d'opération. Redémarrez ollama serve hebdomadairement via un travail cron ; c'est bon marché et évite complètement le mode de défaillance.
• Contention exécuteur CI. Un exécuteur auto-hébergé hébergeant à la fois le serveur LLM et d'autres travaux CI verra la latence de révision monter en flèche sous charge de build. Séparez l'exécuteur et le serveur GPU quand la taille d'équipe dépasse ~25 développeurs.
• Croissance taille diff. Les tailles RP dérivent vers le haut ; finalement une RP dépasse le contexte de travail pratique du modèle et les révisions dégradent silencieusement. Ajoutez un garde dans l'action qui divise ou tronque les diffs au-dessus d'env. 30K tokens et avertit l'auteur.
• Puissance et refroidissement. Une RTX 4090 continuellement chargée tire env. 350W sous inférence et produit une quantité signifiante de chaleur. Une salle serveur de taille placard sans refroidissement actif affamera la GPU ; l'affamement coûte la latence et les développeurs remarquent.
• Rotation de log oubliée. Ollama enregistre chaque corps de requête par défaut. Après trois mois de révisions RP, le fichier journal est grand et contient les diffs RP historiques en texte clair. Rotez les logs hebdomadairement ; archivez ou purgez par votre politique de conservation de données.

Erreurs Courantes lors de la Configuration de la Révision de Code LLM Local

• Erreur 1 : commencer avec un modèle 7B sur une GPU 16 GB. Les révisions Qwen3-Coder 7B sont notablement pires que les révisions 30B ; les développeurs perdent rapidement confiance et le projet est étagéré. Si vous ne pouvez pas adapter le 30B, mettez à niveau la GPU ou utilisez une API cloud pour les six premiers mois pendant que vous sécurisez le budget.
• **Erreur 2 : bloquer les RP sur les verdicts block dès le jour un.** Le premier mois est calibrage ; traitez toute sortie comme conseiller jusqu'à ce que vous ayez mesuré le taux de faux positifs. Promouvez le blocage seulement après que le taux soit au-dessous d'env. 5%.
• **Erreur 3 : exposez ollama serve sur 0.0.0.0:11434 sans auth.** C'est l'équivalent ère-LLM de laisser Redis liée à une interface publique. Liez-la à une interface privée et mettez auth devant avant toute exposition cross-host.
• Erreur 4 : ignorez le cache. Re-révisez les fichiers inchangés à chaque exécution CI gaspille env. 80% du budget d'inférence sur une RP typique. Un petit cache hash fichier + hash diff (Redis ou SQLite) réduit la latence de révision et la charge GPU dramatiquement.
• Erreur 5 : exécutez les travaux entraînement sur la même GPU. L'entraînement fait monter en flèche l'utilisation du VRAM à la limite et affame le modèle de révision. Utilisez des GPU séparées ou, si vous devez partager, exécutez l'entraînement sur un planning strict qui ne chevauche pas les heures RP de pointe.
• Erreur 6 : construisez l'action GitHub sans boucle de rétroaction. Un système de révision sans réactions 👍/👎 ne peut pas s'améliorer. Construisez la boucle la semaine un ; collectez des données ; itérez sur le prompt mensuellement.

Sources

• Documentation Ollama — Référence officielle API HTTP pour /api/chat, /api/generate, sortie structurée et gestion des modèles.
• Documentation vLLM — Documentation serveur inférence haute-débit ; le chemin de mise à niveau au-delà d'Ollama pour les équipes haute-concurrence.
• Documentation GitHub Actions — Référence officielle pour les exécuteurs auto-hébergés, les secrets et le SDK JavaScript Actions utilisé dans le flux de travail ci-dessus.
• Tarification GitHub Advanced Security — Référence prix catalogue pour la comparaison des coûts ; vérifiez par rapport à vos termes réellement négociés.
• Fiche Technique Qwen3-Coder — Architecture, fenêtre de contexte et conditions de licence pour le modèle de révision recommandé.
• Référence GitLab CI/CD — Référence équivalente pour les équipes GitLab ; la portion LLM-call du flux de travail est identique.

FAQ

Lectures Associées

• Replace GitHub Copilot With a Local LLM — contexte plus large de remplacement des coûts pour les équipes envisageant les outils IA auto-hébergés.
• Continue.dev vs Cline vs Aider: Best Local Coding Agent in 2026 — ce qui exécute en pipelines vs travail éditeur interactif ; la couche harness sous le modèle.
• Best Local Coding Models in 2026 — côté modèle de l'équation : Qwen3-Coder, DeepSeek, Codestral et le paysage de licence.
• System Prompt vs User Prompt: What's the Difference — ancrage d'ingénierie de prompt pour le prompt système révision.
• llama.cpp vs Ollama vs vLLM — comparaison moteur inférence ; vLLM est le chemin mise à niveau au-delà d'Ollama pour les équipes haute-concurrence.
• Power Local LLM Hub — bibliothèque guides complète.