Mon assistant, autonome, et (presque) souverain

Ou comment j'ai passé une après-midi à choisir une carte graphique avant de réaliser qu'OpenRouter suffisait pour commencer.

Il y a des projets qui commencent par une idée simple et qui se transforment rapidement en un labyrinthe de questions techniques, de compromis budgétaires et de remises en question philosophiques. OpenClaw, c'est exactement ça.

Alors, qu'est-ce qu'OpenClaw ? En deux mots : c'est un agent IA open-source qui tourne sur ta propre machine et que tu pilotes depuis les applications de messagerie que tu utilises déjà — WhatsApp, Telegram, Signal, Discord... Tu lui envoies un message depuis ton téléphone pendant que tu es en réunion, il exécute la tâche pendant que tu fais autre chose. Il gère tes mails, ton calendrier, automatise des workflows, navigue sur le web, remplit des formulaires, et peut même négocier le prix d'une voiture pendant que tu dors (véridique, c'est une des démos virales qui lui a valu 100 000 étoiles GitHub en une semaine début 2026).

Le projet s'appelait ClawdBot à l'origine, puis Moltbot après un litige de marque avec Anthropic, puis OpenClaw. Le homard est resté, le nom a changé, la hype est restée intacte.

Pourquoi ça m'intéresse

Mon obsession pour la souveraineté numérique n'est un secret pour personne sur ce blog. Self-hosting, HomeLab, services hébergés chez moi... l'idée de confier mes données à des tiers me hérisse le poil depuis des années. OpenClaw coche plusieurs cases intéressantes : il est open-source (licence MIT), il est local-first (tout tourne sur ta machine, la mémoire est stockée en fichiers Markdown chez toi), et il est agnostique côté modèle IA (Claude, GPT, DeepSeek, ou un modèle local via Ollama — ton choix).

Mais soyons honnêtes : dans sa configuration idéale, OpenClaw appelle quand même des API cloud pour le cerveau IA. La souveraineté est donc partielle. On y reviendra.

L'autre angle qui me motive, c'est l'automatisation. Dans mon boulot, je gère quotidiennement un volume de mails, de tickets, de demandes qui mériterait bien un assistant capable de trier, prioriser, répondre aux trucs simples et m'alerter sur l'essentiel. Et ça, c'est exactement ce pour quoi OpenClaw a été conçu.

L'architecture que j'ai retenue

Avant d'entrer dans la mise en place, voici les décisions techniques que j'ai prises après pas mal de réflexion (et quelques allers-retours).

La plateforme : Linux, évidemment

OpenClaw est un agent Node.js (version 22 minimum requise) qui tourne en daemon système. Il n'a pas besoin d'interface graphique pour fonctionner — il est son propre interface, via la messagerie. Sous Linux, il s'installe proprement via systemd, consomme peu de ressources, et ne t'impose pas de couche GUI inutile.

J'ai fait le choix de l'intégrer dans mon infrastructure Proxmox existante sous forme de LXC Debian. Propre, isolé, et cohérent avec le reste de mon HomeLab.

À noter pour ceux qui se posent la question : macOS est supporté nativement et un Mac Mini M4 est techniquement une excellente machine pour cet usage (très faible consommation, mémoire unifiée idéale pour faire tourner des LLM locaux). Mais pour moi, hors de question d'ajouter une machine hors de mon infra existante alors que Proxmox tourne déjà.

Le modèle IA : OpenRouter pour commencer

C'est là que la question de la souveraineté prend une petite gifle. Pour faire fonctionner OpenClaw correctement, il lui faut un "cerveau" — un LLM capable de comprendre tes instructions et d'orchestrer des actions complexes.

L'idéal serait de faire tourner ce modèle en local, via Ollama. Avec un bon GPU et 16 Go de VRAM, on peut faire tourner des modèles 13B quantisés qui s'en sortent très bien pour des tâches d'automatisation courantes. C'est ma cible à terme.

Mais pour commencer, et pour écrire cet article dans des conditions réelles, j'ai choisi OpenRouter. Pourquoi ?

• Une seule clé API, accès à plus de 24 modèles (Gemini, DeepSeek, Llama, Mistral...)
• Support natif dans OpenClaw, zéro configuration complexe
• Quelques euros de crédit suffisent pour des semaines de tests en usage personnel
• Possibilité de switcher de modèle en une ligne de config

La contrepartie, assumée : les données de mes requêtes transitent par des serveurs tiers. Pour les tests initiaux sur des tâches non sensibles, c'est acceptable. Pour un usage en production avec mes mails professionnels de la mairie, il faudra passer au local. On verra ça dans un prochain article.

Le modèle recommandé pour débuter

Petite info utile si tu venais à l'idée d'utiliser ton abonnement Claude Max pour alimenter OpenClaw : Anthropic a banni cette pratique. Il faut impérativement passer par l'API payante au token, ou utiliser un autre fournisseur.

Via OpenRouter, mon choix de départ : DeepSeek V3 pour les tâches courantes (excellent rapport qualité/prix, quasi-Claude pour une fraction du coût), et Llama 3.3 70B comme alternative gratuite pour les trucs simples.

Ce qu'on va construire

Dans cette série d'articles, je vais documenter pas à pas :

1. L'installation d'OpenClaw sur un LXC Debian sous Proxmox — configuration du daemon, intégration systemd, premier test via Telegram
2. La configuration d'OpenRouter — quelle clé, quel modèle, comment optimiser les coûts
3. Les premiers skills utiles — gestion des mails, alertes, automatisations simples
4. La migration vers un LLM local — ajout d'un GPU au serveur Proxmox, installation d'Ollama, configuration du passthrough

L'objectif final : un assistant IA 100% hébergé chez moi, sans dépendance cloud pour le cerveau, piloté depuis mon téléphone, qui automatise les tâches répétitives de ma vie numérique pro et perso.

Pas de Mac Mini. Pas de souscription à 90€/mois. Juste du matériel qu'on a déjà (ou presque), du logiciel open-source, et un peu de patience pour la config.

C'est parti.

Installation et premiers pas

OpenClaw sur Proxmox - La rando des galères ?

"Un randonneur averti en vaut deux. Mais même sans carte, on arrive au sommet."

Bon. Dans la partie 1, on a posé les bases théoriques : pourquoi OpenClaw, pourquoi Linux, pourquoi Matrix. Maintenant on retrousse les manches. Et je vais vous raconter l'installation telle qu'elle s'est vraiment passée — pas la version Instagram où tout marche du premier coup, la version authentique avec les détours, les erreurs JSON, et les petites victoires qui font qu'on apprécie vraiment le résultat final.

Accrochez-vous, le dénivelé est réel, mais le sommet aussi.

L'installation

Le terrain de jeu : un LXC Debian 12 sur Proxmox

Première décision : on n'installe pas OpenClaw directement sur l'hôte Proxmox. On crée un conteneur LXC dédié, isolé, propre. C'est la philosophie de la souveraineté numérique appliquée à l'infrastructure : chaque service dans sa boîte.

Dans l'interface Proxmox, on crée un LXC non-privilégié avec Debian 12 comme template. Les ressources minimales qui tiennent la route :

• 2 cœurs CPU
• 4 Go de RAM
• 20 Go de stockage

On nomme le conteneur OpenClaw, on lui attribue une IP fixe sur le réseau local, et on démarre.

Prérequis système

Dans le LXC fraîchement démarré, on commence par la base :

apt update && apt upgrade -y
apt install -y curl wget git build-essential ca-certificates

Rien d'extraordinaire. On s'assure juste que le terrain est propre avant de construire.

Node.js 22 — via nvm, pas via apt

OpenClaw impose Node.js version 22 minimum. C'est une contrainte stricte, pas une suggestion. Le Node.js dans les dépôts Debian standard est trop ancien — on passe donc par nvm (Node Version Manager), ce qui permet aussi de gérer facilement les mises à jour futures :

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
source ~/.bashrc
nvm install 22
nvm use 22
nvm alias default 22

On vérifie :

node --version  # doit afficher v22.x.x
npm --version

Ensuite, on configure un dossier global pour npm afin d'éviter les problèmes de permissions :

mkdir -p ~/.npm-global
npm config set prefix '~/.npm-global'
echo 'export PATH=~/.npm-global/bin:$PATH' >> ~/.bashrc
source ~/.bashrc

Installation d'OpenClaw

Une ligne. C'est tout.

npm install -g openclaw@latest

Ça tire les dépendances, ça installe le CLI. Quelques secondes plus tard, OpenClaw est là.

La configuration (ou : bienvenue dans la vraie vie)

Le wizard d'onboarding

OpenClaw propose un assistant interactif pour la configuration initiale :

openclaw onboard --install-daemon

Le wizard pose des questions dans l'ordre. Voilà ce qu'on y répond et pourquoi.

Étape 1 — Avertissement de sécurité
Le wizard prévient qu'OpenClaw est conçu pour un usage personnel et nécessite un renforcement de sécurité pour un usage multi-utilisateurs. On acquitte et on continue.

Étape 2 — Mode : QuickStart
On choisit QuickStart pour avancer rapidement. La configuration fine se fait après.

Étape 3 — Fournisseur IA : OpenRouter
Pour démarrer sans GPU dédié, on passe par OpenRouter — un agrégateur d'API qui donne accès à des dizaines de modèles via une seule clé. On colle notre clé sk-or-v1-... quand il la demande.

Étape 4 — Modèle : DeepSeek
On sélectionne openrouter/deepseek/deepseek-chat-v3-0324. Excellent pour le "tool-calling" (la capacité de l'agent à utiliser des outils), peu coûteux, et remarquablement efficace pour les tâches d'automatisation.

Étape 5 — Canal : Matrix

Ici, le wizard tente de configurer Matrix mais échoue avec une erreur de module manquant :

ERROR: Cannot find module '@matrix-org/matrix-sdk-crypto-nodejs-linux-x64-gnu'

On skippe pour l'instant — on reviendra configurer Matrix manuellement juste après.

Étape 6 — Skills

Le wizard propose plusieurs compétences à installer :

• clawhub s'installe sans problème ✅
• himalaya (gestion email) échoue — il dépend de Homebrew, un gestionnaire de paquets macOS. On est sur Linux. On l'installera autrement plus tard.
• summarize même problème.

Étape 7 — Clés API optionnelles

Le wizard pose ensuite une série de questions pour des services optionnels (Google Places, Gemini, Notion, OpenAI Whisper, ElevenLabs...). On répond Non à tous — on n'installe que ce dont on a besoin.

Étape 8 — Hooks

Les hooks automatisent des actions sur certains événements. On active les quatre disponibles : boot-md, bootstrap-extra-files, command-logger, et surtout session-memory — ce dernier permet à l'agent de conserver le contexte de session entre les conversations.

Étape 9 — Systemd indisponible

Et là, premier vrai obstacle. Le wizard essaie d'installer un service systemd, mais dans un LXC Proxmox, systemd user services ne fonctionnent pas. Le wizard l'indique clairement et abandonne l'installation du daemon.

Pas de panique — on a une solution : pm2.

pm2 : le systemd des Node.js

pm2 est un gestionnaire de processus Node.js qui fait exactement ce qu'on veut : lancer un processus, le garder en vie, le redémarrer automatiquement au boot.

npm install -g pm2

Première tentative naïve :

pm2 start "openclaw start" --name openclaw

Résultat dans les logs : error: unknown command 'start'. Normal — j'avais mal lu le --help. La bonne commande pour lancer le gateway, c'est openclaw gateway. On corrige :

pm2 delete openclaw
pm2 start "openclaw gateway" --name openclaw
pm2 startup
pm2 save

pm2 startup génère et installe automatiquement un service systemd au niveau système (pas utilisateur — ça, ça fonctionne dans le LXC). pm2 save mémorise la liste des processus pour le redémarrage automatique.

Accès au dashboard depuis votre machine

Le gateway écoute en loopback (127.0.0.1:18789). Pour y accéder depuis votre poste, on ouvre un tunnel SSH :

ssh -N -L 18789:127.0.0.1:18789 root@<IP-du-LXC>

Puis dans le navigateur :

http://localhost:18789/#token=VOTRE_TOKEN

Le token est affiché à la fin du wizard et dans les logs pm2.

Note : Si SSH refuse la connexion root avec un mot de passe, vérifiez /etc/ssh/sshd_config sur le LXC : PermitRootLogin yes et PasswordAuthentication yes doivent être activés. N'oubliez pas systemctl restart ssh après modification.

Configuration Matrix — la vraie

Le wizard n'a pas pu configurer Matrix. On le fait manuellement, étape par étape.

Étape 1 — Créer le compte bot sur Synapse

Mon serveur Synapse tourne via matrix-docker-ansible-deploy. Pour ajouter un utilisateur, il faut activer le virtualenv ansible d'abord :

source /opt/ansible-venv/bin/activate
cd /opt/matrix/matrix-docker-ansible-deploy
ansible-playbook -i inventory/hosts setup.yml \
  --extra-vars='username=openclaw password=VOTRE_MOT_DE_PASSE admin=no' \
  --tags=register-user

Le bot existe maintenant sur le serveur sous l'identifiant @openclaw:goritalk.fr.

Étape 2 — Récupérer l'access token

curl -X POST https://matrix.goritalk.fr/_matrix/client/v3/login \
  -H "Content-Type: application/json" \
  -d '{"type":"m.login.password","user":"openclaw","password":"VOTRE_MOT_DE_PASSE"}'

La réponse JSON contient un access_token qui commence par syt_. C'est lui qu'on va utiliser.

Étape 3 — Corriger le fichier de configuration

C'est là que j'ai commis quelques erreurs instructives. Premier réflexe : mettre la config Matrix dans plugins.entries.matrix. Mauvaise idée — le plugin utilise emptyPluginConfigSchema(), ce qui signifie qu'il n'accepte aucune config à cet endroit. OpenClaw remonte une erreur Unrecognized keys.

En lisant le source du plugin (src/channel.ts), on comprend que la configuration va dans une section channels à la racine du fichier. Voici le fichier ~/.openclaw/openclaw.json correctement structuré :

{
  "channels": {
    "matrix": {
      "homeserver": "https://matrix.goritalk.fr",
      "accessToken": "syt_xxx_VOTRE_TOKEN",
      "encryption": true,
      "dm": {
        "policy": "allowlist",
        "allowFrom": ["@bilou:goritalk.fr"]
      }
    }
  },
  "plugins": {
    "entries": {
      "matrix": {
        "enabled": true
      }
    },
    "installs": {
      "matrix": {
        "source": "npm",
        "spec": "@openclaw/matrix",
        "installPath": "/root/.openclaw/extensions/matrix",
        "version": "2026.2.25"
      }
    }
  }
}

L'option allowlist dans dm.policy est importante pour la sécurité : seul @bilou:goritalk.fr peut envoyer des DM au bot. Tout le reste est ignoré.

Avant de relancer, on valide toujours la syntaxe JSON :

python3 -m json.tool /root/.openclaw/openclaw.json > /dev/null && echo "JSON OK"

Étape 4 — Réparer le module crypto

Même après la correction du JSON, les logs montrent encore :

Cannot find module '@matrix-org/matrix-sdk-crypto-nodejs-linux-x64-gnu'

Ce module binaire n'a pas été compilé pour notre architecture. La solution :

cd /root/.openclaw/extensions/matrix
npm rebuild

npm rebuild recompile les modules natifs pour l'environnement courant. Ça prend quelques secondes.

Étape 5 — Redémarrage final

pm2 restart openclaw && sleep 5 && pm2 logs openclaw --lines 15 --nostream

Et dans les logs, on voit enfin :

[matrix] [default] starting provider (https://matrix.goritalk.fr)
CryptoClient Running @openclaw:goritalk.fr with device Ed25519 identity: ...
End-to-end encryption enabled
[gateway] listening on ws://127.0.0.1:18789

Le moment de vérité

On ouvre Element sur le téléphone. On se connecte avec @bilou:goritalk.fr. On lance un DM vers @openclaw:goritalk.fr. On tape :

Bonjour 👋

Et le bot répond :

Bonjour ! Comment puis-je vous aider aujourd'hui ? 😊

C'est lui. Il tourne sur notre Proxmox. Il parle via notre Synapse. Le chiffrement E2EE est actif. Les données ne passent par aucun cloud tiers sauf l'API OpenRouter pour l'inférence — et ça, c'est temporaire jusqu'à la mise en place d'Ollama en local.

Ce qu'on a appris

Ce parcours n'était pas parfait. Il n'est jamais censé l'être. Voilà les leçons concrètes :

La commande pm2 : openclaw gateway, pas openclaw start. Toujours lire le --help avant.

Le JSON : Valider avec python3 -m json.tool avant chaque redémarrage. Un accolade manquante coûte plus cher en temps de debug qu'en prévention.

La structure de config : La config Matrix va dans channels, pas dans plugins.entries. La documentation OpenClaw n'était pas limpide sur ce point — le source code l'a été.

Les modules natifs : Sur un LXC fraîchement créé, npm rebuild est parfois nécessaire pour recompiler les binaires.

systemd dans un LXC : Les services utilisateur systemd ne fonctionnent pas. pm2 est une excellente alternative.

OpenClaw en action : le homard trie mes mails

"Un agent IA qui range votre boîte mail sans vous demander votre avis toutes les deux lignes. Le rêve."

Après l'installation et la configuration, il était temps de passer aux choses sérieuses. Théorie, c'est bien. Pratique, c'est mieux. Premier cobaye : ma boîte mail sous Mailcow.

Le contexte

J'héberge mon propre serveur mail sur mail.liew.fr via Mailcow. C'est souverain, c'est propre, et c'est chroniquement en bordel comme toutes les boîtes mail de tous les geeks qui passent plus de temps à optimiser leur infra qu'à ranger leurs emails.

L'idée : donner à OpenClaw l'accès IMAP à la boîte, lui expliquer les familles de tri, et le laisser bosser de façon autonome. Un simple "trie mes mails" dans Element, et le homard s'occupe du reste.

L'outillage : himalaya

Pour qu'OpenClaw puisse interagir avec une boîte IMAP depuis un LXC headless, on a besoin d'un client mail en ligne de commande. Le choix s'est porté sur himalaya, un projet Rust du labo Pimalaya — léger, scriptable, parfait pour un agent IA.

Installation via leur script officiel (cargo étant trop vieux sur Debian 12 pour compiler depuis les sources) :

curl -sSL https://raw.githubusercontent.com/pimalaya/himalaya/master/install.sh | PREFIX=/usr/local sh

Configuration du compte via le wizard intégré :

himalaya account configure liew

Le wizard génère un ~/.config/himalaya/config.toml. Par défaut il utilise secret-tool pour stocker les mots de passe — ce qui ne fonctionne pas sur un LXC sans D-Bus. On édite directement le fichier pour remplacer les deux lignes backend.auth.command par :

backend.auth.command = "echo 'MOT_DE_PASSE'"

⚠️ Cette méthode stocke le mot de passe en clair dans un fichier de config. Acceptable sur un LXC isolé dans un réseau local privé, insuffisant pour un serveur exposé. Pour une config de production, envisagez un coffre-fort comme pass ou gopass.

Test de connexion :

himalaya envelope list

Et là, la boîte s'affiche dans le terminal. Synology, Ryanair, Apple, CrowdSec, des newsletters, des reçus de transport... Le bazar habituel. Mais un bazar avec une structure visible.

Connecter himalaya à OpenClaw

OpenClaw injecte le contenu de SOUL.md comme contexte système à chaque session. C'est là qu'on lui explique ses capacités. On ajoute une section dédiée :

cat >> /root/.openclaw/workspace/SOUL.md << 'EOF'

## Capacités email

Tu as accès à la boîte mail de David (david@liew.fr) via la commande `himalaya`.

Commandes disponibles :
- `himalaya envelope list -s 50` — lister les mails
- `himalaya folder list` — lister les dossiers existants
- `himalaya folder create "NomDossier"` — créer un dossier
- `himalaya message move <ID> "NomDossier"` — déplacer un mail
- `himalaya message read <ID>` — lire un mail

Familles de tri connues : Apple, Ryanair, CrowdSec, Synology, Sacem, Planity,
Livraisons, Newsletters, Twitter-X, Securite.

Quand David dit "trie mes mails" ou "range la boîte", tu lances le tri de manière
autonome sans demander de précisions. Tu listes d'abord les dossiers existants,
puis tu tries par batch de 20.
EOF

Redémarrage du gateway, et on teste.

Le moment de vérité

Depuis Element sur le téléphone, un DM à @openclaw:goritalk.fr :

bilou : trie mes mails

La réponse arrive en quelques secondes :

openclaw : Voici les 20 premiers e-mails de votre boîte de réception. Je vais maintenant les trier en fonction des familles de tri connues. Voici les actions que je propose :

1. Synology Newsletter (ID 2211, 2194) → Déplacer vers INBOX/Synology
2. Ryanair (ID 2208, 2195) → Déplacer vers INBOX/Voyages
3. CrowdSec (ID 2209, 2205, 2197) → Déplacer vers INBOX/Securite (à créer)
4. Apple (ID 2207, 2206) → Déplacer vers INBOX/Apple
5. Payzen (ID 2203) → Déplacer vers INBOX/Livraisons
6. KFC France (ID 2193) → Déplacer vers INBOX/Newsletters

Si vous souhaitez ajuster ces actions, dites-le-moi. Sinon, je commence le tri.

Deux choses notables dans cette réponse. Premièrement, l'agent a bien interprété le contexte : il ne demande pas quel logiciel de mail j'utilise, ni comment accéder à la boîte, ni quelles catégories créer. Il sait déjà tout ça grâce au SOUL.md. Deuxièmement, il propose avant d'agir — ce qui est exactement le comportement qu'on veut pour des actions irréversibles comme déplacer des mails.

bilou : vas-y

Et le homard s'est mis au travail. Dossiers créés, mails déplacés, batch après batch. En autonomie. Depuis mon téléphone, via mon serveur Matrix, vers ma boîte Mailcow. Sans aucun service tiers impliqué dans la chaîne de traitement sauf l'API OpenRouter pour l'inférence.

Ce que ça illustre

Ce cas d'usage simple révèle ce qui rend OpenClaw intéressant par rapport à un simple chatbot.

L'agent exécute, il ne suggère pas. La différence entre "voici comment vous pourriez trier vos mails" et "vos mails sont triés" est fondamentale. On est passé de l'assistant consultatif à l'assistant opérationnel.

Le contexte fait tout. Sans le SOUL.md enrichi, l'agent répondait avec des questions génériques sur le type de boîte mail et les critères de tri — exactement comme n'importe quel chatbot. Avec le contexte, il sait qui il est, ce qu'il a comme outils, et ce qu'on attend de lui.

La souveraineté est préservée. Aucun mail n'est passé dans un service cloud. L'agent lit les métadonnées (expéditeur, sujet) via IMAP, décide localement via le modèle, et exécute via himalaya. Le contenu des mails n'a jamais quitté l'infrastructure.

Les limites actuelles

Ce n'est pas parfait, et il serait malhonnête de prétendre le contraire.

L'agent fait des approximations. Il ne lit pas le corps de chaque mail pour décider — il se base sur l'expéditeur et le sujet, ce qui suffit pour 90% des cas mais peut rater des nuances. Un mail de Payzen peut être un reçu légitime ou une tentative de phishing ; l'agent ne fait pas toujours la distinction sans lire le contenu.

Il propose parfois des dossiers qui n'ont pas de sens (dans ma session, il a voulu mettre Ryanair dans un dossier "RED SFR" existant — visiblement des dossiers résiduels dans ma boîte l'ont induit en erreur). C'est pour ça qu'on valide avant d'exécuter.

Le traitement par batch de 20 est prudent mais lent pour une grosse boîte. Avec 2000+ mails, une session de tri complète va prendre un moment.

La suite logique

Deux améliorations naturelles à ce setup :

Un tri automatique à l'arrivée. Plutôt que de trier manuellement sur demande, on peut configurer un cron OpenClaw pour déclencher le tri toutes les heures sur les nouveaux mails uniquement. Un himalaya envelope list subject:"" after:yesterday pour ne cibler que les arrivées récentes.

La migration vers Ollama. Actuellement, la décision de tri passe par DeepSeek via OpenRouter. C'est des données de boîte mail qui quittent l'infrastructure, même si c'est juste les métadonnées. Avec un modèle local via Ollama, même ça disparaît. C'est l'objet de la Partie 5.

Conclusion intermédiaire

En une journée, on est passé d'un LXC vide à un agent IA qui trie les mails de façon autonome, via une messagerie chiffrée de bout en bout, sur une infrastructure 100% auto-hébergée. Le coût mensuel en API : quelques centimes pour une session de tri.

Ce n'est pas de la magie. C'est de l'assemblage intelligent d'outils libres : Proxmox, Debian, OpenClaw, himalaya, Matrix/Synapse, Mailcow. Chaque brique existe indépendamment depuis des années. Ce qui change, c'est la colle — l'agent qui orchestre tout ça depuis votre poche.

Le homard a gagné ses galons.

Prochaine partie : GPU passthrough, Ollama, et la migration vers un LLM 100% local ?