Ne pas réveiller le LLM pour allumer la lumière — le bypass déterministe
Le problème : des tokens gaspillés pour des trivialités
Quand on construit un assistant personnel augmenté par LLM, la tentation est de tout lui passer par le cerveau. L’utilisateur demande « quelle heure est-il ? », le LLM réfléchit, comprend qu’il faut appeler date, parse le résultat, et répond. Ça marche. Mais c’est absurde.
Chaque requête LLM coûte :
- Du temps : 1 à 5 secondes de latence
- Des tokens : même une question simple consomme le prompt système + l’historique
- De l’énergie : inférer un modèle de 70 milliards de paramètres pour répondre « il est 14h32 »
- De l’argent : même à 0,15 $/M tokens, ça s’accumule sur des centaines de requêtes par jour
Et surtout, le LLM peut échouer sur une tâche qu’un script bash fait en 2 millisecondes. Il peut halluciner l’heure, mal parser la sortie de uptime, ou décider de répondre en japonais parce que son training l’a poussé à « être créatif ».
J’ai donc implémenté un bypass déterministe : un court-circuit qui intercepte certaines requêtes avant qu’elles n’atteignent le LLM, les traite avec des outils système, et renvoie une réponse formatée. Zéro token consommé.
Le concept
«
Requête utilisateur
│
▼
┌─────────────────────┐
│ Bypass déterministe │ ← patterns regex
│ (skill Hermes) │
└─────────┬───────────┘
│
match trouvé ? ──Oui──→ Exécution script → Réponse formatée
│
Non
│
▼
Passage au LLM normal
Le bypass est un skill Hermes — un fichier de configuration qui définit des patterns et des actions. Quand une requête correspond à un pattern, le LLM n'est jamais invoqué. Le skill prend la main, exécute la commande, et retourne le résultat.
Ce que le bypass intercepte
| Commande | Pattern | Action | Latence |
| Heure | quelle heure |
date |
< 10 ms |
|---|---|---|---|
| Météo | météo |
curl wttr.in |
~ 200 ms |
| Services | services? |
systemctl is-active –quiet |
< 50 ms |
| Uptime | uptime |
uptime |
< 10 ms |
| fail2ban | bans? |
fail2ban-client status |
< 100 ms |
| Charge CPU | load |
cat /proc/loadavg |
< 10 ms |
| Disque | disque |
df -h |
< 10 ms |
Résultat : environ 30% des requêtes quotidiennes sont traitées sans LLM. Zéro token, zéro latence réseau, zéro hallucination.
L'implémentation
Le skill Hermes est un fichier YAML avec une structure simple :
`yaml
name: bypass-deterministe
patterns:
- trigger: "quelle heure|il est quelle heure|donne moi l'heure"
action: "date '+%H:%M'"
format: "Il est {output}."
- trigger: "météo|temps qu'il fait|quel temps"
action: "curl -s wttr.in/Sorede?format=3"
format: "Météo à Sorède : {output}"
- trigger: "services?|tout va bien|health"
action: "/root/.hermes/scripts/health-check.sh"
format: "{output}"
- trigger: "bans?|ip bannies|fail2ban"
action: "sudo fail2ban-client status sshd | grep 'Total banned'"
format: "IP bannies (sshd) : {output}"
`
Chaque entrée définit :
- trigger
: une expression régulière qui déclenche le bypass - action
: la commande shell à exécuter - format
: un template de réponse (le {output}est remplacé par le résultat)
Le skill est chargé en premier dans la chaîne Hermes. Si un pattern match, le LLM n'est jamais contacté. La réponse est instantanée.
Pourquoi c'est important
1. La latence, pas le coût
Le vrai problème des LLM, ce n'est pas le prix des tokens — c'est la latence. Une question simple comme « est-ce que le serveur va bien ? » prend 3-5 secondes avec un LLM distant. Avec le bypass, c'est 50 ms. L'utilisateur a l'impression que l'assistant est réactif, pas qu'il « réfléchit » à une question triviale.
2. La fiabilité
Un LLM peut se tromper sur l'heure. Il peut mal interpréter « combien d'IP bannies ? » et répondre avec le nombre de règles nftables au lieu du compteur fail2ban. Le bypass ne se trompe jamais : il exécute la même commande que vous taperiez dans un terminal.
3. Le principe de moindre puissance
C'est une application directe du principe « Best part is no part » — la meilleure partie est l'absence de partie. Si un script bash de 3 lignes fait le travail, pourquoi impliquer un modèle de langage de 70 milliards de paramètres ? Chaque token économisé est un token qui ne peut pas halluciner, qui ne coûte pas d'argent, qui ne ralentit pas la réponse.
4. La résilience
Si le LLM est indisponible (panne API, timeout réseau, saturation), le bypass continue de fonctionner. L'utilisateur peut toujours connaître l'heure, la météo, l'état des services. L'assistant n'est pas paralysé par la défaillance de son composant le plus complexe.
L'extension : le dashboard vivant
Le bypass déterministe a naturellement mené à une autre optimisation : le dashboard vivant.
Plutôt que de laisser le LLM générer une page HTML statique à chaque mise à jour (coûteux, lent, variable), j'ai créé un générateur Python qui :
1. Exécute les mêmes scripts que le bypass (health, load, disque, fail2ban)
2. Génère un fichier JSON avec les métriques
3. Injecte les données dans un template HTML pré-écrit
4. Ajoute des animations CSS pures (pas de JavaScript lourd)
Le résultat : un dashboard qui se régénère toutes les 30 minutes, avec des cartes animées, un heartbeat rouge pour le SOC, et des indicateurs visuels. Le LLM n'intervient pas — c'est du pur code déterministe.
`
┌─────────────────────────────────────────────┐
│ SOC Status 🟢 23/26 OK │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ fail2ban│ │ load │ │ disk │ │
│ │ 51 bans │ │ 0.42 │ │ 72% │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ ─────────────────────────────────────── │
│ Dernière màj : 14:32:15 │
└─────────────────────────────────────────────┘
Bilan
| Métrique | Sans bypass | Avec bypass |
| Requêtes LLM/jour | ~100 | ~70 |
|---|---|---|
| Tokens économisés/jour | — | ~30 000 |
| Latence requêtes simples | 2-5 s | < 50 ms |
| Fiabilité | ~95% (hallucinations) | 100% |
| Résilience (LLM down) | Assistant mort | Assistant partiellement fonctionnel |
Leçons
1. Tout ne mérite pas un LLM. Avant d’ajouter une capacité à votre assistant, demandez-vous : « est-ce qu’un script de 5 lignes ferait aussi bien ? » Si oui, ne réveillez pas le LLM.
2. Le bypass n’est pas un contournement, c’est une architecture. C’est le même principe que le cache en développement web : ne pas recalculer ce qu’on peut stocker. Ici, ne pas inférer ce qu’on peut exécuter.
3. La simplicité est une fonctionnalité. Le skill bypass fait 30 lignes. Il n’a pas de bugs, pas de dépendances, pas de latence réseau. C’est le genre de code qui dort tranquille.
4. Le LLM doit être un dernier recours, pas un réflexe. Plus on monte dans la stack, plus on doit être sélectif sur ce qu’on confie au modèle. Les tâches déterministes (heure, météo, état système) doivent être traitées de manière déterministe. Les tâches créatives (rédaction, analyse, synthèse) peuvent être confiées au LLM.
Et après ?
Le bypass déterministe est la troisième brique de l’assistant, après l’architecture événementielle (inotify + webhook) et le Memory Kernel. Ensemble, ils forment un système cohérent :
- Événementiel : ne pas scruter ce qui peut être poussé
- Mémoire structurée : ne pas oublier ce qui a été appris
- Bypass : ne pas LLM-iser ce qui peut être scripté
Le code et la documentation sont sur GitHub :
👉 github.com/rouzejp/hermes-assistant-etendu
Le dépôt grandit au fil des articles. L’objectif : fournir un blueprint complet pour quiconque veut construire un assistant personnel efficace, économique et résilient.