Introduction
Faire appel à un seul grand modèle de langage pour arbitrer un changement d’architecture critique ou un durcissement de sécurité expose à un risque bien connu : le biais d’auto-confirmation. Même les meilleurs modèles peuvent halluciner un paramètre réseau, oublier une contrainte de verrou SQLite sur NFS ou sous-estimer une surface d’injection indirecte.
En nous inspirant du concept open-source LLM Council (karpathy/llm-council) popularisé par Andrej Karpathy, nous avons déployé sur notre infrastructure un protocole de délibération collégiale en 3 étapes (scripts/karpathy_council.py). L’objectif n’est pas de faire bavarder des modèles entre eux, mais d’obtenir une confrontation indépendante, évaluée à l’aveugle, avec un droit de veto formel sur la sécurité et la résilience.
Rôles asymétriques et droits de veto
Plutôt que d’interroger quatre fois le même prompt générique, chaque membre du conseil possède une spécialité d’ingénierie et, pour deux d’entre eux, un veto bloquant :
| Membre du Conseil | Modèle sous-jacent | Rôle technique | Pouvoir d’arbitrage |
|---|---|---|---|
| Fable | Claude Opus 5.5 | CISO Zero-Trust, isolation des enclaves, anti-injection | VETO_SECURITY (Bloquant) |
| Astra | GPT-6 | Architecte Cloud & SRE, cgroups Docker, verrous BDD/NFS | VETO_SRE (Bloquant) |
| Sol | GPT-5.6 | Lead Software Engineer, concision algorithmique Ponytail | Vote de Borda & revue de complexité |
| Argon | Gemini 4 VIP | Corrélation holistique long-context (2M+ tokens) | Vote de Borda & détection d’angles morts |
| AGY (Chairman) | Agent Exécutif | Synthèse, exécution des tests sur le serveur et preuve empirique | Arbitrage final fondé sur le test réel |
Le pipeline de délibération en 3 étapes
1. Stage 1 : Opinions initiales en parallèle
Les modèles reçoivent exactement le même contexte factuel (extrait de code, logs système, topologie réseau) et répondent en parallèle via asyncio.gather. Aucun modèle ne voit la proposition des autres, ce qui élimine tout biais d’ancrage.
2. Stage 2 : Revue par les pairs anonymisée et score de Borda
L’orchestrateur mélange et renomme les propositions en Response A, Response B, Response C, Response D en conservant la table de correspondance en mémoire privée. Chaque modèle évalue les propositions à l’aveugle, signale d’éventuelles failles critiques (VETO_SECURITY ou VETO_SRE) et produit un classement strict converti en points de Borda.
3. Stage 3 : La preuve empirique bat le vote
Un consensus théorique entre LLM ne remplace jamais l’exécution réelle. Le Chairman écarte toute proposition frappée d’un veto, retient la solution la plus sobre (filtre Ponytail) et l’exécute face à notre suite de 252 canaries anti-régression.
# Lancer une délibération complète du Conseil en 3 étapes (JSON structuré)
python3 scripts/karpathy_council.py --question "Audit d'isolation de la Data Diode HMAC-SHA256 vers https://blog.ravindra-job.fr/" --context-file src/security/data_diode.py --mode full
# Vérifier l'état des garde-fous après application de la recommandation
pytest -q tests/test_security_canaries.py
| Commande | Description |
|---|---|
`python3 scripts/karpathy_council.py --question '...'`
| Exécuter les 3 étapes (First Opinions, Anonymized Peer Review, Chairman Synthesis). |
`VETO_SECURITY / VETO_SRE`
| Marqueurs bloquants déclenchés en Stage 2 si une proposition viole l'isolation Zero-Trust ou la résilience. |
`label_to_model (Response A..D)`
| Table d'anonymisation empêchant un modèle de favoriser sa propre famille lors de l'évaluation. |
`Mode A / Mode B / Mode C`
| Calibrage du conseil selon le risque : Mode A (local direct), Mode B (revue ciblée), Mode C (Conseil complet). |
`pytest -q tests/test_security_canaries.py`
| Validation empirique finale sur le serveur après synthèse du Chairman. |
Conclusion
En combinant l’indépendance du Stage 1, l’évaluation à l’aveugle du Stage 2 et la vérification empirique du Stage 3, le pattern LLM Council transforme plusieurs modèles généralistes en une véritable cellule d’ingénierie contradictoire, capable d’attraper des failles subtiles avant qu’elles n’atteignent la production.
Si vous voulez plus d’information sur l’infrastructure vous pouvez voir mon repo à ce sujet : https://github.com/ravindrajob/InfraAtHome