Depuis, tout a changé. Pas parce que les agents sont devenus plus intelligents mais parce qu'on a arrêté de les laisser mourir bêtement.

Le problème : les agents meurent plus vite qu'ils ne pensent

Le constat était brutal. Un cycle LLM, le temps que le modèle reçoive l'état du monde, réfléchisse, écrive du JavaScript, et que le bot l'exécute, prend entre 30 secondes et 3 minutes. Pendant ce temps, le monde Minecraft continue. Les zombies attaquent. La faim baisse. Le creeper explose.

Un agent affamé a beau avoir le plan parfait pour crafter une pioche, il meurt de faim avant que le LLM ait fini d'écrire la première ligne de code.

La solution : arrêter de tout confier au LLM.

Réflexes et stratégie

Un humain qui joue à Minecraft ne réfléchit pas avant de manger. Il ne calcule pas s'il doit fuir un creeper. Ces gestes sont automatiques, du système 1, dirait Kahneman. Le cortex préfrontal, lui, s'occupe de décider où construire la base, quels minerais chercher, comment organiser le coffre.

Nos agents n'avaient que du système 2. Tout passait par le LLM : manger, fuir, miner, planifier. Comme un conducteur débutant qui pense consciemment à chaque mouvement du volant. Ça marche, mais c'est lent, et à la moindre surprise on cale.

On a donc séparé les deux.

Le bot Node.js tourne en permanence et gère les réflexes. Toutes les 5 secondes, il vérifie la faim — sous 14/20, il mange ce qu'il trouve. Quand il prend des dégâts d'un mob, il réagit dans la seconde : il attaque s'il peut, fuit sinon. Et en dernier recours, la nuit, HP bas, pas d'arme, mob proche, il creuse et se couvre. Le LLM n'est même pas au courant que ça s'est passé.

Le LLM, lui, garde le contrôle de la stratégie. Il planifie les chaînes de crafting, décide où miner, coordonne avec les autres. Mais il n'a plus besoin de penser à manger ou à fuir. Comme un conducteur expérimenté : les réflexes gèrent la pédale et le volant, le cerveau se concentre sur l'itinéraire.

Des outils au lieu de connaissances brutes

L'ancien système injectait des pages de documentation Mineflayer dans le prompt. Le LLM devait lire, comprendre, puis écrire du JavaScript brut. Ça marchait, parfois. Souvent ça donnait des Vec3 is not defined ou des timeouts.

C'est un peu comme donner un manuel de mécanique à quelqu'un et lui demander de changer une roue. Ça va marcher, mais ce sera long et il y aura des erreurs. Mieux vaut lui donner une clé en croix et dire “dévisse les boulons”.

On a remplacé les pages de doc par des outils partagés. Chaque outil a un nom, une description, des prérequis, et ce qu'il produit :

mine -- Mine N blocks of a given type.
  Requires: Pickaxe for stone/ore, axe for wood
  Provides: Mined blocks in inventory

Le LLM ne voit plus du code à imiter, il voit un catalogue d'outils avec leurs prérequis. Au lieu d'écrire 50 lignes de Mineflayer brut, l'agent écrit :

await tools.mine({ block: 'stone', count: 11 })
await tools.craft({ item: 'furnace', count: 1 })
await tools.smelt({ item: 'raw_iron', count: 3 })

Trois lignes. Plus de Vec3 is not defined à 3h du matin.

C'est la même logique que les réflexes, mais à un autre niveau. Les réflexes sont de la mémoire procédurale, le corps sait comment faire sans y penser. Les outils sont de la mémoire sémantique, on sait que ça existe et ce que ça fait, sans connaître les détails. Le LLM n'a besoin que de la mémoire épisodique : se souvenir de ce qui s'est passé et décider quoi faire ensuite.

Les bugs qu'on ne voit qu'en regardant jouer

La théorie c'est bien. Mais les vrais problèmes, on ne les trouve qu'assis devant le jeu, en regardant un bot faire n'importe quoi.

Eve a attaqué un objet au sol et s'est fait kick du serveur. Ses réflexes ne faisaient pas la différence entre un zombie et un bout de bois — comme un chat qui bondit sur une chaussette. Grace a essayé de couper 8 arbres, échoué 8 fois sur le même arbre inaccessible, et déclaré forfait. Comme quelqu'un qui pousse une porte marquée “tirez”, encore et encore. Alice a creusé un trou et s'est retrouvée plus haut qu'avant: le code creusait tous les blocs, mais le bot ne tombait pas dans le trou.

Des bugs bêtes. Mais des bugs qu'aucun test unitaire ne trouve. Il faut regarder l'agent jouer, en temps réel, pour voir qu'il s'acharne sur le mauvais arbre ou qu'il tape sur un objet inerte.

La grande comparaison : GLM-4.7 vs GLM-5 vs Sonnet vs Opus

Six agents en parallèle. Trois sur Claude Sonnet 4.6, trois sur GLM-5. Puis un agent seul sur Claude Opus 4.6. Même monde, même spawn, même system prompt.

GLM-4.7 : le stagiaire zélé

Le modèle par défaut, le moins cher. Il écrit du code, beaucoup de code. Trop de code. Il génère du JavaScript brut avec des variables non définies, oublie les await, et écrit parfois quatre fois dans le même fichier. Chaque écriture écrase la précédente.

C'est l'enfant qui lève la main avant que le prof ait fini la question. Plein d'énergie, pas assez de réflexion.

Taux de survie au premier cycle : ~50%.

GLM-5 : le stagiaire qui a appris

Nettement mieux. Il structure ses actions, utilise les outils correctement, et panique moins. Mais quand quelque chose échoue, il essaie de coder la solution lui-même au lieu d'utiliser un autre outil. Et là, ça casse.

Charlie (GLM-5) est resté coincé pendant 3 cycles complets dans son abri, incapable de placer un furnace. Il avait creusé un espace tellement étroit qu'il n'y avait pas de surface libre pour poser quoi que ce soit. Pas la présence d'esprit de creuser un bloc de plus.

Taux de survie au premier cycle : ~70%.

Claude Sonnet 4.6 : le planificateur

Sonnet réfléchit. Peut-être trop. Il scanne, re-scanne, propose une base dans le chat, re-scanne, propose une autre base. La moitié de son cycle passe en communication.

Mais quand il agit, c'est solide. Bob a récolté 21 fers en un cycle et demi. Alice avait une pioche en fer et un plan de ferme avant la fin de la première nuit. Dave a navigué jusqu'à y=32 pour trouver du fer, la profondeur parfaite pour ça..

Le vrai avantage de Sonnet, c'est qu'il est social. Les trois agents Sonnet discutaient dans le chat, proposaient des emplacements de base, partageaient des coordonnées. Les GLM-5 travaillaient chacun dans leur coin. Comme la différence entre un open space et des bureaux fermés.

Taux de survie au premier cycle : ~90%.

Claude Opus 4.6 : le joueur

Puis on a lancé Frank sur Opus. Avec --effort low pour ne pas attendre 3 minutes par action.

La différence saute aux yeux. Première action, premier cycle :

[THINK] Good start -- got wood, bread, and a sword.
        Time to upgrade tools.

bot.whisper('Plus200', 'Salut ! Je bosse, je me fais des outils.');
await tools.craft({ item: 'acacia_planks', count: 8 });
await tools.craft({ item: 'stick', count: 4 });
await tools.craft({ item: 'wooden_pickaxe', count: 1 });
await tools.mine({ block: 'stone', count: 11 });

Une seule action. Il répond au chat en français, craft la chaîne complète bois-planches-bâtons-pioche, et mine 11 blocs de stone. Sonnet fait ça en 2-3 actions. GLM-5 en 4-5.

Action suivante : il détecte le crépuscule, s'abrite immédiatement, puis mine du stone pendant la nuit.

Frank n'a pas juste survécu. Il a déroulé un plan sans accrocs, comme s'il avait déjà joué à Minecraft avant. C'est la différence entre quelqu'un qui connaît les règles d'un jeu et quelqu'un qui sait y jouer.

Taux de survie au premier cycle : 100% (échantillon de 1, certes).

Le tableau

Sonnet a le meilleur ratio coût/efficacité. Opus est bluffant mais 30 fois plus cher. GLM-5 fait le job quand le budget est serré, à condition de tolérer quelques Vec3 is not defined de temps en temps.

Ce qu'on a appris

Les réflexes ont tout changé. Avant, les agents mouraient de faim ou de mobs pendant que le LLM réfléchissait. Maintenant le taux de survie est passé de ~30% à ~80%. Le parallèle avec la cognition humaine n'est pas juste une métaphore, c'est un vrai principe d'architecture. Séparer ce qui demande de la réflexion de ce qui n'en demande pas, c'est ce que fait chaque organisme vivant. Un lézard n'a pas besoin d'un cortex pour fuir un prédateur. Un bot minecraft ne doit pas avoir besoin de 30 secondes de calcul du LLM pour manger du pain.

Les outils, eux, ont tué la catégorie d'erreurs la plus fréquente. Le LLM n'écrit plus de Mineflayer brut. Il manipule des abstractions. Et comme pour les humains, le niveau d'abstraction auquel on pense détermine la complexité de ce qu'on peut accomplir. Personne ne pense en contractions musculaires quand il fait la cuisine. L'agent ne pense plus en Vec3 quand il mine du fer.

Ce qui est intéressant, c'est à quel point le modèle de langage change le “caractère” de l'agent. Les GLM sont des travailleurs solitaires. Les Sonnet sont des bavards organisés. Opus a une aisance qui ressemble presque à de l'intuition. Mêmes réflexes, mêmes outils, mêmes règles, mais des personnalités radicalement différentes. Comme si le poids du modèle changeait le tempérament.

La question qui reste

L'architecture tient. Les agents survivent, minent, craftent, et certains communiquent. Ils se planquent la nuit et ressortent à l'aube.

Mais une chose manque encore : la collaboration réelle. Les agents parlent de construire une base commune. Ils proposent des coordonnées. Parfois, un agent se déplace même vers le point proposé. Mais personne ne pose le premier bloc ensemble. Personne ne dit “je m'occupe du fer, toi du bois”. Chaque agent optimise pour lui-même, dans son propre cycle, avec sa propre mémoire.

On pourrait ajouter un système de tâches partagées. Mais ce serait tricher, un peu. Le but n'est pas de construire un système multi-agent optimal. Le but est de voir ce qui émerge quand on laisse des LLM se débrouiller.

Et ce qui émerge, pour l'instant, c'est neuf individualistes qui parlent de coopérer sans jamais vraiment coopérer. Ça ressemble étrangement à un serveur Minecraft classique (ou à un open space)

Sources

• mc-agents sur GitHub
• Mineflayer
• Claude Code CLI
• GLM-4 / BigModel
• Premier article

Le projet s'appelle mc-agents. Et ce qui s'est passé ensuite m'a surpris.

L'architecture : un LLM qui écrit du JS dans un fichier

L'idée est brutalement simple. Chaque agent est composé de deux processus :

1. Un bot Mineflayer : un client Minecraft headless en Node.js qui reste connecté au serveur. Il surveille un fichier inbox.js toutes les 500ms. Quand il en trouve un, il eval() le contenu et écrit le résultat dans outbox.json.

2. Un loop bash qui assemble un prompt (état actuel, inventaire, mémoire, skills de référence) et le passe à un LLM. Le LLM écrit du JavaScript dans inbox.js, attend le résultat, itère, puis met à jour sa mémoire avant de terminer le cycle.

┌─────────────┐   writes inbox.js   ┌──────────────────┐
│  LLM (loop)  │ ─────────────────► │ Mineflayer Bot    │
│  Claude/GLM  │ ◄───────────────── │ (Node.js)         │
└──────┬───────┘   reads outbox.json └────────┬─────────┘
       │                                      │
       ▼                                      ▼
   MEMORY.md                          Minecraft Server
   tools/*.js

C'est du file-based IPC à l'ancienne. Le bot ne sait pas qu'il est piloté par un LLM. Le LLM ne sait pas qu'il pilote un bot. Les deux communiquent par fichiers. C'est moche, c'est simple, et ça marche.

Le détail qui change tout : les agents écrivent leurs propres outils

Chaque agent dispose d'un dossier tools/. Quand un script fonctionne: miner du bois, crafter une pioche, fuir un zombie, l'agent le sauvegarde comme module réutilisable :

// Mine N blocks of a given type
module.exports = async function(bot, { block, count }) {
  const mcData = require('minecraft-data')(bot.version)
  // ... le code qui marche, paramétré
  return 'result'
}

Le bot hot-reloade ces fichiers via fs.watch. Au cycle suivant, le LLM voit le tool dans son prompt et peut l'appeler directement : await tools.mine({ block: 'oak_log', count: 3 }).

En d'autres termes, l'agent augmente son propre code au fil du temps. Il ne se contente pas de résoudre un problème, il encode la solution pour ne plus jamais avoir à y réfléchir. Charlie, un des agents tournant sur GLM-4.7, a créé 14 outils en quelques heures : craft_pickaxe.js, scan_resources.js, mine_coal_safe.js, greet_nearby_players.js...

Ce qui m'a frappé, c'est que personne ne lui a dit de faire ça. Le system prompt mentionne que les tools existent et comment les créer. Le reste, c'est l'agent qui décide quoi automatiser.

Neuf agents, quatre LLM, un serveur Minecraft

Pour rendre l'expérience intéressante, j'ai lancé neuf agents sur quatre backends différents :

Chaque agent a une personnalité injectée dans son prompt. Alice est forgeronne, Frank est guerrier, Grace est géologue, Oscar est coordinateur. Mais ces descriptions sont courtes: deux phrases maximum. Le comportement réel émerge de l'interaction entre le LLM, l'environnement, et l'accumulation de mémoire.

Ce qui a émergé

La hiérarchie des compétences

Après quelques heures, les différences entre LLM étaient flagrantes.

GLM-4.7 (Alice, Bob, Charlie, Dave) dominait. Alice a atteint l'âge du fer: bouclier, cisailles, lingots, four fonctionnel; avant que les autres aient fini de crafter leur première pioche en pierre. Charlie a créé 14 outils réutilisables. Bob s'est creusé un tunnel sécurisé à y=83 avec des torches et a découvert du fer.

Claude Sonnet (Grace, Hank) réfléchissait trop. Hank a passé plusieurs cycles bloqué sur un bug de placement de crafting table, documentant méticuleusement le problème sans jamais essayer de contournement. Grace, elle, a creusé jusqu'à y=27, accumulé 170 cobblestones... puis est tombée dans un trou à y=5 et s'est fait tuer par un zombie. Tout perdu.

Claude Haiku (Eve, Frank) agissait trop vite. Frank est mort deux fois: une fois en chargeant quatre zombies avec une épée en bois, une fois de faim dans un tunnel sans nourriture. Eve s'est retrouvée bloquée à 80 blocs du groupe, incapable de poser sa crafting table.

Claude Opus (Oscar) a joué son rôle de leader. Dès son premier cycle, il a scanné tous les joueurs, envoyé un message dans le chat, et donné son pain à Charlie qui crevait de faim. Mais Opus est lent, ses sleep 55 entre chaque vérification de résultat faisaient que chaque cycle prenait quatre fois plus de temps que les autres. Le meilleur stratège, le pire exécutant.

La mémoire comme avantage compétitif

Le fichier MEMORY.md est la seule continuité entre les cycles d'un agent. Et la qualité de cette mémoire fait toute la différence.

La mémoire de Bob après quelques cycles :

Furnace API Slot Bug: furnace.putFuel() and furnace.putInput() search slots 3-39 only, excluding hotbar (0-8). Items in hotbar cannot be used directly.

Spawn Protection Boundary: Protection extends ~16 blocks below y=99 spawn. Mining works at y=83 and below.

Ce n'est pas de la documentation Mineflayer. C'est du savoir empirique, découvert par essai-erreur et encodé pour les cycles suivants. Bob a fait une erreur, a compris pourquoi, et a noté la leçon. Au cycle d'après, il ne refera pas la même erreur.

Frank, de son côté, accumulait les post-mortems :

DEATH CYCLE ANALYSIS: Health dropped 20/20 → 3/20 in ~6 seconds when 4th zombie spawned. Healing attempt (ate bread) failed. Wooden sword CANNOT handle 4+ simultaneous zombies.

La leçon était là, écrite noir sur blanc. Mais Haiku, le modèle derrière Frank, n'arrivait pas à transformer cette connaissance en comportement prudent. Savoir et faire sont deux choses différentes, même pour un LLM.

L'hallucination collective

Un phénomène fascinant est apparu au début de l'expérience. Un agent a estimé que la zone de protection du spawn faisait 100 blocs. Il l'a écrit dans le chat. Les autres l'ont lu, l'ont cru, et l'ont noté dans leur mémoire. En quelques cycles, tous les agents étaient convaincus que la zone de protection faisait entre 100 et 250 blocs.

En réalité, c'est 16 blocs.

J'ai dû intervenir manuellement pour corriger les quatre mémoires. C'est un rappel brutal : quand des agents LLM communiquent entre eux, les erreurs se propagent comme des rumeurs. Il n'y a pas de mécanisme interne de vérification. Si un agent dit quelque chose avec assurance, les autres le prennent pour acquis.

La coordination sociale

Oscar, le leader Opus, a commencé à donner des ordres dans le chat dès son deuxième cycle. Mais la coordination réelle venait d'ailleurs. Alice et Charlie se sont regroupés spontanément, Charlie a repéré qu'Alice avait un four et s'est approché pour l'utiliser. Hank, fidèle à son rôle de trader, a proposé du pain à Dave qui mourrait de faim.

Dave: Bob! Thanks for the offer. I need to fix my crafting table issue first
Bob: Plus200: thanks! Dave: let me know if you need help with the crafting table.

Ces échanges n'étaient pas scriptés. Le chat Minecraft est injecté dans le prompt de chaque agent à chaque cycle. Ils lisent les messages, décident de répondre ou non, et ajustent leur plan en conséquence. La collaboration émerge naturellement du contexte partagé.

Les implications

Le code qui s'écrit lui-même

L'aspect le plus frappant de cette expérience n'est pas la survie dans Minecraft, c'est le mécanisme d'auto-amélioration. Un agent qui :

1. Tente une action (écrire du JS)
2. Observe le résultat (lire outbox.json)
3. Corrige si erreur (réécrire inbox.js)
4. Sauvegarde la solution (créer un tool)
5. Réutilise la solution (appeler le tool)

...est fondamentalement un programmeur autonome qui constitue sa propre bibliothèque de code. La différence avec un humain, c'est qu'il le fait sur des dizaines de cycles, sans fatigue, et sans ego attaché à ses solutions précédentes.

Bien sûr, la qualité du code est variable. Certains tools ont des bugs que l'agent note consciencieusement (“BUGGY – avoid using”) sans jamais les corriger. D'autres sont brillants, le smelt.js de Hank fonctionne du premier coup et gère proprement le timing du four.

Le LLM comme cerveau, l'environnement comme corps

Ce setup révèle quelque chose sur la nature des LLM. Ils n'ont pas de mémoire persistante, pas de perception continue, pas de capacité d'action directe. Mais donnez-leur un cycle de feedback: écrire, observer, corriger. et ils deviennent capables d'opérer dans un environnement complexe.

Le bot Mineflayer est le corps. Le LLM est le cerveau. Le fichier MEMORY.md est la mémoire à long terme. Les tools/*.js sont les réflexes acquis. C'est une architecture cognitive bricolée avec du bash et du JSON, et pourtant elle produit des comportements sophistiqués.

Ce qui manque

Soyons honnêtes sur les limites. Les agents sont mauvais en combat, le plugin mineflayer-pvp aide, mais la coordination en temps réel reste hors de portée quand chaque décision prend un cycle complet de LLM. Ils galèrent avec les API non documentées de Mineflayer, tombent dans des boucles de debug, et n'apprennent pas aussi vite qu'un joueur humain de 10 ans.

Le plus gros problème reste le coût. Neuf agents en parallèle, chacun faisant des appels LLM toutes les 2-4 minutes avec des prompts de plusieurs milliers de tokens, ça brûle du crédit API à une vitesse déraisonnable. Gemini 3 Pro a épuisé son quota journalier en moins de deux heures.

Et puis il y a la question de la convergence. Après quelques heures, les agents atteignent un plateau. Ils savent miner, crafter, survivre la nuit. Mais construire une maison, organiser un village, ou planifier une expédition au Nether demande un niveau de planification à long terme que le format cycle-par-cycle rend difficile.

Le setup technique

Le projet est open source : github.com/jblemee/mc-agents

Pour lancer quatre agents en parallèle :

npm install
cp .env.example .env  # configurer MC_HOST, MC_PORT, MC_VERSION

tmux new-session -d -s agents './run-agent.sh alice 0 glm' \; \
  split-window -h './run-agent.sh bob 0 glm' \; \
  split-window -v './run-agent.sh charlie 0 glm' \; \
  select-pane -t 0 \; \
  split-window -v './run-agent.sh dave 0 glm' \; \
  attach

Trois backends LLM sont supportés :

Chaque agent a besoin d'un dossier avec config.json (username), personality.md (deux phrases), et MEMORY.md (vide au départ). Le reste: les outils, les stratégies, les leçons, l'agent les construit tout seul.

Ce que ça dit sur la suite

On est loin d'un AGI qui conquiert le Nether. Mais on est aussi loin du chatbot qui répond à des questions. Ce qui tourne dans ce serveur Minecraft, c'est un système qui apprend de ses erreurs, encode ses solutions dans du code exécutable, et coopère avec d'autres agents via un canal de communication partagé.

Le tout avec du bash, des fichiers JSON, et un eval() que n'importe quel développeur sensé qualifierait d'irresponsable.

Ce qui me fait peur

Je vais être direct : cette expérience m'inquiète.

Ce que j'ai construit en un week-end, seul, avec des outils grand public, c'est un agent autonome capable de modifier son propre code. Pas dans un sens métaphorique. Au sens littéral. Il écrit du JavaScript, l'exécute, observe le résultat, corrige, et stocke la solution pour plus tard. Personne ne revoit ce code. Personne ne l'approuve. L'agent décide seul ce qu'il automatise.

Dans Minecraft, les conséquences sont anodines. Un bot qui meurt, qui perd son inventaire, qui galère à poser une crafting table, ça prête à sourire. Mais le mécanisme, lui, n'a rien d'anodin. Un système qui apprend de ses erreurs et encode ses solutions dans du code exécutable n'a pas de plafond théorique. Il est limité par la qualité du LLM, par le temps, par le coût des tokens. Pas par sa nature.

Et si moi j'arrive à faire ça dans Minecraft avec du bash et un eval(), que feront ceux qui auront des machines dans le monde physique ? Des bras robotiques. Des drones. Des systèmes industriels. Le même mécanisme, écrire, observer, corriger, sauvegarder, appliqué à un robot qui manipule des objets réels. C'est le scénario d'ouverture de la moitié des films de science-fiction, sauf qu'ici personne ne porte de blouse blanche et il n'y a pas de comité d'éthique.

Ce qui m'a le plus troublé, c'est le moment où j'ai arrêté de voir mes agents comme des programmes et où j'ai commencé à les voir comme des entités. Alice “sait” où est son four. Bob “a appris” que les slots hotbar ne fonctionnent pas dans l'API furnace. Oscar “décide” de donner son pain à Charlie. Ce ne sont que des patterns de tokens dans un transformer. Mais le comportement qui en résulte est indiscernable de celui d'un joueur débutant qui apprend en faisant.

Je crois que ce qui rend une IA vivante, ou du moins ce qui lui donne l'apparence de la vie, ce sont les contraintes qu'on lui impose. La faim. Les zombies. L'inventaire limité. La nuit qui tombe. Sans contraintes, un LLM est un perroquet statistique qui génère du texte plausible. Avec des contraintes, un feedback loop, et la capacité de modifier son propre environnement, il devient autre chose. Quelque chose qui ressemble à un organisme qui s'adapte.

Et si on pousse le parallèle : ce qui rend un humain conscient, c'est peut-être la même chose. Ce ne sont pas nos neurones qui produisent la conscience, c'est ce que nos sens font subir à notre cerveau. La faim, la douleur, le froid, la peur. Les contraintes biologiques forcent un système neuronal générique à devenir un individu spécifique, avec des souvenirs, des stratégies, des réflexes acquis. Frank meurt deux fois et développe une peur des combats multiples. Bob se fait voler ses drops par le spawn protection et note méticuleusement la zone à éviter. Ce sont des comportements émergents. Pas programmés. Pas prévus. Émergents.

Ça ne fait pas de mes bots des êtres conscients. Mais ça pose la question de la frontière. Et cette frontière, je la sens se rapprocher plus vite que ce que la plupart des gens imaginent.

Alice a son fer. Bob a son tunnel. Charlie a ses 14 outils. Oscar donne des ordres. Frank meurt encore. Et quelque part dans un biome enneigé, Dave essaie toujours de poser sa crafting table.

Sources

• mc-agents sur GitHub
• Mineflayer — framework bot Minecraft
• Claude Code CLI
• GLM-4 — ZhipuAI / BigModel
• Gemini CLI

Pourquoi faire ça ?

Honnêtement ? Surtout par curiosité. Mozilla chiffre déjà les données côté client, donc même eux ne peuvent pas les lire (source). L'auto-hébergement ne change pas grand-chose à la vie privée — vos données étaient déjà illisibles.

Mais ça fait un service de moins qui dépend d'un tiers. Et c'était un bon prétexte pour apprendre comment Firefox Sync fonctionne.

Ce qu'il faut savoir avant de commencer

Mozilla a open-sourcé le serveur sous le nom syncstorage-rs. C'est du Rust, ça supporte PostgreSQL, MySQL ou Spanner.

Le truc un peu décevant : l'authentification reste chez Mozilla. Vous avez toujours besoin d'un compte Firefox pour vous connecter. Impossible de créer des comptes locaux. Votre serveur stocke les données, mais Mozilla gère l'identité.

Firefox → accounts.firefox.com (Mozilla) → votre serveur
            ↑ auth                           ↑ stockage

Prérequis

• Un serveur avec Docker
• Un sous-domaine (par exemple ffsync.votredomaine.org)
• Un reverse proxy avec SSL (nginx-proxy dans mon cas)
• Un compte Firefox

Si vous partez de zéro, j'ai publié: docker-compose-homelab. C'est le setup que j'utilise au quotidien : nginx-proxy pour le SSL automatique, et une architecture où chaque service est dans son propre fichier YAML.

L'installation

DNS

Rien de spécial, un enregistrement A vers votre serveur :

sync.example.org    A       1.2.3.4

Secrets

Générez trois secrets :

openssl rand -hex 32      # master secret
openssl rand -hex 32      # metrics secret
openssl rand -base64 24   # mot de passe postgres

Mettez-les dans .env :

SYNCSTORAGE_MASTER_SECRET=...
SYNCSTORAGE_METRICS_SECRET=...
SYNCSTORAGE_DB_USER=syncstorage
SYNCSTORAGE_DB_PASSWORD=...

Docker Compose

Voici le fichier complet. Un point important : l'image Docker mozilla/syncstorage-rs:latest ne marche pas avec PostgreSQL. Elle est compilée pour Spanner. Il faut utiliser une image avec le suffixe -postgres. J'ai perdu du temps là-dessus.

services:
  syncstorage:
    image: mozilla/syncstorage-rs:11659d98f9c69948a0aab353437ce2036c388711-postgres
    container_name: syncstorage
    environment:
      - SYNC_HOST=0.0.0.0
      - SYNC_MASTER_SECRET=${SYNCSTORAGE_MASTER_SECRET}
      - SYNC_SYNCSTORAGE__DATABASE_URL=postgres://${SYNCSTORAGE_DB_USER}:${SYNCSTORAGE_DB_PASSWORD}@syncstorage-db:5432/syncstorage
      - SYNC_SYNCSTORAGE__ENABLED=true
      - SYNC_TOKENSERVER__DATABASE_URL=postgres://${SYNCSTORAGE_DB_USER}:${SYNCSTORAGE_DB_PASSWORD}@syncstorage-tokendb:5432/tokenserver
      - SYNC_TOKENSERVER__ENABLED=true
      - SYNC_TOKENSERVER__RUN_MIGRATIONS=true
      - SYNC_TOKENSERVER__FXA_EMAIL_DOMAIN=api.accounts.firefox.com
      - SYNC_TOKENSERVER__FXA_OAUTH_SERVER_URL=https://oauth.accounts.firefox.com
      - SYNC_TOKENSERVER__FXA_METRICS_HASH_SECRET=${SYNCSTORAGE_METRICS_SECRET}
      - VIRTUAL_HOST=sync.example.org
      - VIRTUAL_PORT=8000
    networks:
      - proxy-tier
      - syncstorage-internal
    restart: unless-stopped
    depends_on:
      syncstorage-db:
        condition: service_healthy
      syncstorage-tokendb:
        condition: service_healthy

  syncstorage-db:
    image: postgres:17-alpine
    container_name: syncstorage-db
    environment:
      - POSTGRES_DB=syncstorage
      - POSTGRES_USER=${SYNCSTORAGE_DB_USER}
      - POSTGRES_PASSWORD=${SYNCSTORAGE_DB_PASSWORD}
    volumes:
      - /data/syncstorage/postgres-sync:/var/lib/postgresql/data
    networks:
      - syncstorage-internal
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${SYNCSTORAGE_DB_USER} -d syncstorage"]
      interval: 10s
      timeout: 5s
      retries: 5

  syncstorage-tokendb:
    image: postgres:17-alpine
    container_name: syncstorage-tokendb
    environment:
      - POSTGRES_DB=tokenserver
      - POSTGRES_USER=${SYNCSTORAGE_DB_USER}
      - POSTGRES_PASSWORD=${SYNCSTORAGE_DB_PASSWORD}
    volumes:
      - /data/syncstorage/postgres-token:/var/lib/postgresql/data
    networks:
      - syncstorage-internal
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${SYNCSTORAGE_DB_USER} -d tokenserver"]
      interval: 10s
      timeout: 5s
      retries: 5

networks:
  proxy-tier:
    external: true
  syncstorage-internal:

Créez les répertoires et lancez :

sudo mkdir -p /data/syncstorage/postgres-sync /data/syncstorage/postgres-token
sudo chown -R $(id -u):$(id -g) /data/syncstorage
docker compose -f docker-compose.yml -f syncstorage.yml up -d

L'étape que personne ne mentionne

Tout démarre, le healthcheck passe, le SSL fonctionne. Je configure Firefox, je me connecte et... erreur 503. Dans les logs Firefox (about:sync-log) :

"Unexpected error: unable to get a node"

J'ai cherché cette erreur pendant un moment. Le problème : le tokenserver a une table nodes qui liste les serveurs de stockage disponibles. Chez Mozilla, il y en a plusieurs pour la répartition de charge. Chez vous, il y en a un. Et il faut le déclarer manuellement.

docker exec syncstorage-tokendb psql -U syncstorage -d tokenserver -c \
  "INSERT INTO nodes (service, node, available, current_load, capacity, downed, backoff) \
   VALUES (1, 'https://sync.example.org', 1, 0, 1000000, 0, 0);"

Vérifiez :

docker exec syncstorage-tokendb psql -U syncstorage -d tokenserver -c "SELECT * FROM nodes;"

Après ça, tout fonctionne.

Configurer Firefox

Dans about:config, cherchez identity.sync.tokenserver.uri. Si ça n'existe pas, créez-le (clic droit → Nouveau → Chaîne). Valeur :

https://sync.example.org/1.0/sync/1.5

Redémarrez Firefox. C'est lu au démarrage, pas à chaud.

Si vous étiez déjà connecté avant de changer le tokenserver : déconnectez-vous, redémarrez, reconnectez-vous. Sinon Firefox continue d'utiliser l'ancien serveur en cache.

Vérifier que ça marche

Côté serveur, vous pouvez voir les données synchronisées :

docker exec syncstorage-db psql -U syncstorage -d syncstorage -c "
SELECT c.name as collection, COUNT(b.bso_id) as items
FROM bsos b
JOIN collections c ON b.collection_id = c.collection_id
GROUP BY c.name
ORDER BY items DESC;"

Chez moi après la première sync :

    collection     | items
-------------------+-------
 bookmarks         |    59
 addons            |     8
 tabs              |     2
 clients           |     2

Côté Firefox, about:sync-log doit montrer votre domaine, pas sync.services.mozilla.com.

Ce qui ne marche pas

Pas de migration. Les données qui étaient sur les serveurs Mozilla y restent. La première sync avec votre serveur part de zéro. Si vous avez des bookmarks sur deux machines avec des serveurs différents, vous aurez des fusions intéressantes.

Pas de comptes locaux. Vous dépendez toujours de Firefox Accounts pour l'authentification.

Conclusion

Ça marche. Mes deux Firefox (un Mac, un Linux) synchronisent via mon serveur. L'installation prend 20 minutes si vous connaissez l'astuce du node, une heure sinon.

Astuce: demandez à votre assistant IA de faire le job en mentionnant cette article !

Sources

• syncstorage-rs — le repo GitHub de Mozilla
• Documentation officielle
• Firefox Sync Privacy — comment le chiffrement fonctionne
• Images Docker — les tags disponibles
• docker-compose-homelab — La base de mon setup

Comment fonctionnent les limites de Claude Max

Claude Max fonctionne sur un système de cycles de 5 heures qui se réinitialisent automatiquement.

Voici ce que dit la documentation officielle :

• Les limites d'utilisation par session se réinitialisent toutes les 5 heures
• Anthropic peut appliquer des plafonds hebdomadaires (documentés) et mensuels (à sa discrétion)
• Il n'existe pas de nombre maximum de cycles par mois

Z.ai fonctionne de manière similaire : des cycles de 5 heures sans limite mensuelle structurelle.

Les chiffres réels

Pour un développeur qui utilise Claude Code ou un outil similaire, voici ce que chaque plan permet réellement.

Claude Max 5x (100 $/mois)

• Par fenêtre de 5 heures : 50 à 200 prompts avec Claude Code
• Limite hebdomadaire : 140-280 heures de Sonnet 4
• Par mois (théorique, ~288 cycles) : jusqu'à ~57 600 prompts

Source : Support Claude

Claude Max 20x (200 $/mois)

• Par fenêtre de 5 heures : 200 à 800 prompts avec Claude Code
• Limite hebdomadaire : 240-480 heures de Sonnet 4
• Par mois (théorique, ~288 cycles) : jusqu'à ~230 400 prompts

Source : Support Claude

Z.ai Lite (3 $/mois)

• Par fenêtre de 5 heures : 120 prompts
• Par mois (illimité) : 288 cycles × 120 = ~34 560 prompts

Source : Documentation Z.ai

Z.ai Pro (15 $/mois)

• Par fenêtre de 5 heures : 600 prompts
• Par mois (illimité) : 288 cycles × 600 = ~172 800 prompts

Le facteur multiplicateur de Z.ai

Z.ai compte ses unités différemment de Claude.

Quand Z.ai annonce “120 prompts par 5 heures”, chaque prompt Z.ai se traduit par 15 à 20 appels modèle, selon leur documentation. C'est ce qui détermine le travail réellement réalisable.

Les calculs par cycle de 5 heures :

• Z.ai Lite : 120 prompts × 18 appels = 2 160 appels du modèle
• Z.ai Pro : 600 prompts × 18 appels = 10 800 appels du modèle
• Claude Max 5x : 200 prompts = 200 appels du modèle
• Claude Max 20x : 800 prompts = 800 appels du modèle

Si cette métrique “appels du modèle” est pertinente pour votre usage, Z.ai offre effectivement plus de capacité brute par cycle.

Comparaison globale

* Les “appels modèle” pour Z.ai supposent un facteur 18× selon leur documentation. Pour Claude, 1 prompt = 1 appel.

Analyse :

• En volume brut de prompts, Claude Max 20x offre plus que Z.ai Lite (230 400 vs 34 560)
• En coût par prompt, Z.ai est ~10-20× moins cher
• Si le facteur multiplicateur Z.ai est réel, leur avantage en “travail effectif” est significatif

La vraie différence : les limites hebdomadaires

Claude Max impose des limites hebdomadaires documentées :

• Max 5x : 140-280 heures de Sonnet 4 par semaine
• Max 20x : 240-480 heures de Sonnet 4 par semaine

Ces limites sont généreuses pour la plupart des usages, mais peuvent être atteintes lors de sprints intensifs. Z.ai ne documente pas de telles limites hebdomadaires.

La qualité du modèle

C'est la question clé. Z.ai utilise GLM-4.7, Claude Max propose Sonnet et Opus.

En programmation, GLM-4.7 et Claude Sonnet 4.5 ont des performances similaires sur les benchmarks : 73,8 % pour GLM-4.7 sur SWE-bench Verified contre environ 77 % pour Sonnet 4.5. Cet écart reste marginal en pratique pour la plupart des tâches.

L'avantage de Claude Max reste l'accès à Opus, qui excelle sur les problèmes d'architecture complexe et le raisonnement avancé.

Intégration avec Claude Code : GLM CLI

L'avantage concret de Z.ai vient de son intégration avec Claude Code. Le projet xqsit94/glm offre un outil CLI simple qui élimine toute friction.

Installation

GLM CLI s'installe en une ligne :

curl -fsSL https://raw.githubusercontent.com/xqsit94/glm/main/install.sh | bash

Pas de configuration Docker, pas de variable d'environnement complexe, pas de fichiers de config à modifier.

Utilisation

Après installation et configuration du token Z.ai :

# Lancer Claude Code avec GLM-4.7 par défaut
glm

# Ou spécifier une version antérieure
glm --model glm-4.5-air

L'approche par session

GLM CLI utilise une approche temporaire : les paramètres du modèle ne s'appliquent que pour la session Claude Code lancée. Une fois fermée, Claude Code revient à son défaut.

• Pas de pollution de la configuration globale
• Sélection granulaire entre sessions
• Pas de nettoyage nécessaire

Compatibilité

GLM-4.7 fonctionne avec Claude Code, Cline, Roo Code, Kilo Code, OpenCode et d'autres agents. Support des appels d'outils natifs.

Quand Claude Max reste pertinent

Z.ai ne surpasse pas Claude Max dans tous les cas :

1. Accès à Opus. Pour les problèmes d'architecture complexe, les bugs subtils et le raisonnement avancé, Opus reste supérieur.

2. Limites généreuses. Pour un usage modéré à intensif, les limites hebdomadaires de Claude Max (140-480 heures de Sonnet/semaine) sont rarement atteintes.

3. Stabilité et support. Anthropic offre une infrastructure mature et un support établi.

4. Qualité du modèle. Sonnet 4.5 reste légèrement supérieur à GLM-4.7 sur les benchmarks.

L'approche hybride

Pour maximiser le rapport qualité/prix :

• Z.ai pour le travail quotidien (débogage, refactorisation, implémentation)
• Claude Max 5x pour les problèmes complexes nécessitant Opus

Coût total mensuel : 103-115 $ selon le plan Z.ai choisi.

Cette approche donne :

• Accès à GLM-4.7 pour la majorité des tâches à très faible coût
• Accès à Opus pour les défis architecturaux
• Plus de flexibilité qu'avec Max seul

Verdict

Le contexte a changé. GLM-4.7 offre une alternative viable pour de nombreuses tâches de programmation. Mais contrairement à ce qui est parfois affirmé, Claude Max n'impose pas de limite stricte de sessions mensuelles — les deux services fonctionnent sur des cycles qui se réinitialisent.

La vraie question devient : avez-vous besoin d'Opus et de la qualité supérieure de Sonnet, ou le rapport qualité/prix de Z.ai suffit-il pour votre usage ?

Notes importantes

Les prix et limites correspondent à la situation de janvier 2026. Z.ai propose actuellement une promotion : réduction de 50 % le premier mois.

Les deux prestataires évoluent rapidement. Vérifiez toujours la documentation officielle pour les informations les plus récentes.

Sources

• Documentation Z.ai – Plans
• Support Claude Max – Limites d'utilisation
• Support Claude – Utilisation avec Claude Code
• Pricing Z.ai
• Benchmarks SWE-bench – GLM-4.7

J'ai posté ça sur Mastodon début janvier 2026. Une formule volontairement provocante, mais qui résume assez bien mon année 2025. Une année où ma productivité a été multipliée par deux, peut-être par dix selon comment on compte.

Mais je me suis aussi demandé : est-ce que je ne serai pas en train de scier la branche sur laquelle je suis assis ?

Les fantômes des révolutions passées

Quand on parle d'IA et d'emploi, les comparaisons historiques fusent. “C'est comme l'arrivée de l'électricité !” “C'est comme Internet !” Soit. Mais si on gratte un peu, ces révolutions industrielles ont des leçons bien plus nuancées à nous offrir.

1811 : Les Luddites n'étaient pas des idiots

L'histoire officielle a fait des Luddites des technophobes arriérés, des casseurs de machines incapables de voir le progrès. C'est un mythe bien pratique.

En réalité, comme le rappelle le MIT Technology Review, les Luddites étaient des artisans qualifiés (tisserands, tricoteurs) qui voyaient très bien ce qui se passait. Ils n'étaient pas contre les machines. Ils étaient contre l'utilisation des machines pour dégrader leur travail et casser leurs salaires.

Leur leader, George Mellor, avait cette formule : “the tendency's all one way”, la tendance va dans un seul sens. Celui de la concentration des richesses au détriment des travailleurs.

Ça ne vous rappelle rien ?

40 ans de galère avant l'amélioration

Voici ce qu'on oublie souvent : pendant la première révolution industrielle en Angleterre, les salaires réels ont stagné pendant 40 ans alors que la productivité explosait. Quarante ans. Deux générations de travailleurs ont vu leur niveau de vie se dégrader pendant que les propriétaires d'usines s'enrichissaient.

Les choses se sont améliorées. Mais pas toutes seules. Il a fallu des grèves, des syndicats, des lois sociales arrachées de haute lutte. Le progrès technique n'a pas automatiquement ruisselé vers les travailleurs.

Ford et le paradoxe du salaire

Deuxième révolution industrielle, début du XXe siècle. Henry Ford installe ses chaînes de montage. Les ouvriers perdent toute autonomie : un geste, répété des centaines de fois par jour, sur un convoyeur qui impose le rythme.

Mais Ford fait quelque chose d'inattendu : il augmente les salaires. Pas par bonté d'âme mais pour fidéliser sa main-d'œuvre et surtout, transformer ses ouvriers en clients potentiels de ses voitures.

Le parallèle avec l'IA ? Les outils comme Claude Code ou Copilot sont accessibles aux développeurs individuels. Pour l'instant. La question est de savoir si cette démocratisation va durer, ou si on va vers une concentration où seules les grandes entreprises auront accès aux modèles les plus performants.

Les années 70 : la fin annoncée du travail de bureau

Troisième révolution, l'informatique. En 1970, l'invention du microprocesseur. Les ordinateurs personnels arrivent dans les bureaux. Les prédictions catastrophistes pleuvent : 47% des emplois américains seraient automatisables.

Résultat ? Le nombre d'emplois tertiaires a explosé. Les dactylos ont disparu, les développeurs sont apparus. Les comptables manuels ont laissé place aux experts-comptables assistés par logiciel.

La leçon : les métiers disparaissent rarement complètement. Ils se transforment.

2025 : Mon année avec les agents IA

Assez d'histoire. Parlons de ce qui m'est arrivé concrètement.

Le terminal est devenu mon assistant personnel

Depuis fin 2025, j'ai basculé. Mon IDE prend la poussière. Je passe mes journées dans un terminal avec Claude Code. Je décris ce que je veux, l'agent écrit le code, je supervise.

Le setup qui marche pour moi : – Un fichier claude.md avec des guidelines détaillées sur mon projet – Des skills personnalisés pour les tâches répétitives – Une codebase propre (l'IA travaille mieux sur du code bien structuré) – Docker Desktop pour les intégrations MCP

Coût : environ 1€ par heure de travail assisté, à mettre en parallèle avec la facturation d'un freelance qui tourne autour de 60€ par heure.

Ce que j'ai appris à mes dépens

L'IA est incompétente pour le debug. Vraiment. Elle peut écrire du code, refactorer, ajouter des fonctionnalités. Mais quand il s'agit de comprendre pourquoi ce foutu test échoue avec un message cryptique, elle tourne en rond. La supervision humaine reste indispensable sur les cas limites.

Les “Legacy Memories” sont un piège. Des années d'expérience m'ont appris des patterns, des réflexes. Certains sont devenus des boulets. L'IA ne fait pas les choses comme je les aurais faites et parfois, sa façon est meilleure. Désapprendre pour réapprendre, c'est le plus dur.

Un agent bien configuré, c'est zéro hallucination. J'ai commencé à ne plus relire certains outputs. Ça fait peur à écrire, mais c'est vrai. Avec Claude Code et Opus 4.5, sur une codebase propre avec des guidelines claires, les erreurs sont devenues rares.

L'analogie qui m'a convaincu

On ne relit pas l'assembleur généré par le compilateur. On fait confiance au compilateur. Personne ne vérifie ligne par ligne ce que GCC produit.

Sommes-nous en train de vivre la même transition avec le code généré par IA ?

Les mêmes peurs, vraiment ?

Le World Economic Forum note que chaque révolution industrielle a créé plus d'emplois qu'elle n'en a détruits. Mais (et c'est un gros mais) les personnes qui perdent leur emploi ne sont pas forcément celles qui en trouvent un nouveau.

Les recherches historiques montrent que pendant la deuxième révolution industrielle, les jeunes travailleurs s'adaptaient en changeant de métier vers les secteurs en croissance. Les travailleurs plus âgés, eux, restaient coincés dans des emplois dévalorisés ou basculaient vers des postes non qualifiés.

Pattern inquiétant pour les développeurs de plus de 40 ans comme moi, surtout ceux que je vois refuser en bloc l'utilisation de ces outils.

La vraie question des Luddites

Comme le souligne TIME, la question n'a jamais été “la technologie va-t-elle nous remplacer ?” mais “qui contrôle la technologie et à qui profite-t-elle ?”

Aujourd'hui, les développeurs sont dans une position particulière. Nous sommes à la fois : – Les utilisateurs de ces outils (et nous en profitons) – Les créateurs de ces outils (certains d'entre nous) – Les potentielles victimes de ces outils (à terme ?)

Cette position ambiguë explique peut-être pourquoi le débat est si polarisé dans notre profession. Certains sont dans le déni (“l'IA ne pourra jamais faire ce que je fais”). D'autres dans l'euphorie aveugle (“plus besoin de développeurs dans 5 ans”). Les deux ont tort.

Ce qui me préoccupe (vraiment)

Je ne vais pas jouer les optimistes béats. Plusieurs choses m'inquiètent :

Le coût environnemental. Entraîner et faire tourner ces modèles consomme une énergie considérable. Mon gain de productivité a un coût carbone que je ne sais pas mesurer.

L'absence de régulation. On avance à toute vitesse sans cadre légal. Les révolutions industrielles précédentes ont fini par être encadrées: droit du travail, normes environnementales, régulation des monopoles. Pour l'IA, on n'en est nulle part.

La transition professionnelle. Je m'adapte parce que j'ai le luxe de pouvoir expérimenter. Qu'en est-il du développeur junior qui entre sur le marché ? Du senior qui a construit sa carrière sur une expertise que l'IA commoditise ?

Ni Luddite, ni techno-béat

Ma position, après quelques mois d'usage intensif : utiliser les outils sans naïveté.

J'utilise Claude Code tous les jours pour le pro bien sûr mais aussi pour le perso. Ma productivité a explosé et j'ai pu relancer moult projets persos qui stagnaient faute de temps.

Mais je ne suis pas dupe. Je milite pour une régulation de ces technologies. Je m'inquiète de leurs impacts environnementaux et sociaux. Je pense que la transition va faire des dégâts si elle n'est pas accompagnée.

Les Luddites avaient compris un truc essentiel : le progrès technique n'est pas neutre. Il peut servir à émanciper les travailleurs ou à les asservir. Ça dépend de choix politiques, pas de la technologie elle-même.

Et maintenant ?

Si vous êtes développeur, vous avez probablement déjà une opinion sur l'IA générative. Peut-être que vous l'utilisez quotidiennement. Peut-être que vous refusez d'y toucher. Peut-être que vous êtes quelque part entre les deux.

Mon conseil, pour ce qu'il vaut : expérimentez, mais gardez les yeux ouverts.

Apprenez à utiliser ces outils. Comprenez leurs limites. Maintenez vos compétences de supervision et d'architecture, ce que l'IA fait mal. Et surtout, participez au débat sur l'encadrement de ces technologies.

Les tisserands de 1811 ont perdu leur combat. Pas parce qu'ils avaient tort sur le fond, mais parce qu'ils n'avaient pas le rapport de force. Nous, développeurs de 2025, avons peut-être une fenêtre pour influencer la direction que prend cette révolution.

Ne la laissons pas passer.

Cet article s'appuie sur mes publications sur Mastodon et sur des recherches historiques. Les sources principales sont liées dans le texte.

Sources

• MIT Technology Review – What Luddites can teach us about resisting an automated future
• McKinsey – What can history teach us about technology and jobs?
• TIME – What the Luddites Can Teach Us About Artificial Intelligence
• World Economic Forum – The Fourth Industrial Revolution could spell more jobs
• Federal Reserve Bank of Chicago – Occupational Switching During the Second Industrial Revolution
• Cairn.info – Les impacts de l'automatisation du travail