yggapi.eu, l'API non-officielle qui faisait tourner la plupart des indexeurs Prowlarr/Jackett pour YGG, était morte avec le site original. Les gists GitHub qui traînent encore pointent vers des domaines fantômes. Les forums donnent des conseils pour un écosystème qui n'existe plus. Et ygg.gratis, le “nouveau” YGG, répondait 404 sur tous les chemins d'API que j'essayais.

C'est là que j'ai compris que je cherchais la mauvaise chose.

Ce que ygg.gratis n'est pas

ygg.gratis n'est pas un site de torrents avec une API de scraping. Ce n'est pas non plus un clone de yggapi.eu avec un nouveau domaine.

C'est l'interface publique d'UTOPEER (ou U2P), un projet qui repose sur Nostr — un protocole de messages décentralisé. Les torrents sur ygg.gratis ne sont pas stockés dans une base de données centrale. Ils circulent comme des événements sur un réseau de relays.

Pour comprendre pourquoi ça change tout, il faut deux minutes sur Nostr.

Nostr en deux minutes (vraiment)

Nostr, c'est un protocole de publication décentralisé. Chaque contenu est un “événement” signé par une clé privée (comme une clé GPG), publié sur des “relays” — des serveurs WebSocket qui stockent et redistribuent ces événements.

N'importe qui peut lire, n'importe qui peut publier. Les relays sont interchangeables. Si un relay ferme, les événements qu'il hébergeait peuvent exister ailleurs. L'identité d'un auteur n'est pas liée à un serveur.

Le projet a surtout été utilisé pour les réseaux sociaux décentralisés (c'est une alternative à Mastodon, dans l'esprit). Mais le protocole est agnostique sur le contenu. Une spec appelée NIP-35 définit un format d'événement spécifiquement pour les métadonnées de torrents : infohash, nom, taille, trackers, tout ça.

UTOPEER publie les torrents YGG comme des événements NIP-35 sur un relay Nostr (relay.ygg.gratis). ygg.gratis est juste l'interface web qui connecte à ce relay pour le rendre browsable.

Pourquoi ça compte pour Prowlarr

Le problème avec les APIs de scraping comme yggapi.eu, c'est qu'elles dépendaient d'un site central. Quand le site ferme ou change sa structure HTML, l'API meurt avec lui.

Le modèle Nostr est différent. Le “bot” qui publie les torrents YGG est une clé publique. Tant que cette clé publie sur un relay accessible, n'importe qui peut s'y abonner et indexer le contenu. Le relay peut changer, le front-end peut changer, la clé publique reste.

C'est aussi là que ça devient plus compliqué pour l'intégration Prowlarr : il n'existe pas d'endpoint Torznab public sur ygg.gratis. La spec le dit clairement — U2P expose une API Torznab, mais c'est une instance que tu fais tourner toi-même, qui connecte le relay Nostr et te sert les résultats localement.

L'architecture complète

relay.ygg.gratis (Nostr)
         ↓
Lighthouse          ← tu héberges ça chez toi
(indexeur local)
         ↓
      Prowlarr
         ↓
   Sonarr / Radarr
         ↓
    Transmission

Lighthouse est un indexeur Nostr open-source qui se connecte à un relay, indexe les événements NIP-35 dans une base SQLite locale, et expose une API Torznab standard. Prowlarr le voit comme n'importe quel autre indexeur.

Installation

Prérequis

• Docker et Docker Compose
• Prowlarr déjà en place

1. Créer les répertoires

mkdir -p /data/lighthouse/data /data/lighthouse/config
chown -R 1000:1000 /data/lighthouse

2. Créer le fichier de service

Lighthouse n'a pas d'image Docker publique — il faut la builder depuis les sources. Docker le fait directement depuis GitHub :

# services/lighthouse.yml
services:
  lighthouse:
    build:
      context: https://github.com/gmonarque/lighthouse.git
      dockerfile: Dockerfile
    image: lighthouse:local
    container_name: lighthouse
    environment:
      - TZ=Europe/Paris
    volumes:
      - /data/lighthouse/data:/app/data
      - /data/lighthouse/config:/app/config
    networks:
      - proxy-tier        # même réseau que Prowlarr
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "wget", "-q", "--spider", "http://localhost:9999/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 30s

networks:
  proxy-tier:
    external: true

Lighthouse est un service interne — il n'a pas besoin d'être exposé sur Internet. Prowlarr l'appelle via le nom Docker lighthouse:9999.

3. Créer la configuration

# /data/lighthouse/config/config.yaml
server:
  host: "0.0.0.0"
  port: 9999

database:
  path: "/app/data/lighthouse.db"

nostr:
  relays:
    - url: "wss://relay.ygg.gratis"
      name: "YGG Relay"
      preset: "private"
      enabled: true

trust:
  depth: 1

enrichment:
  enabled: false

4. Builder et démarrer

docker compose -f docker-compose.yml -f services/lighthouse.yml \
  build lighthouse

docker compose -f docker-compose.yml -f services/lighthouse.yml \
  up -d lighthouse

Le build prend 3-5 minutes (Go + Node.js compilés depuis les sources).

5. Compléter le setup via l'API

Au premier démarrage, Lighthouse attend qu'une “identité Nostr” soit générée. Sans ça, il ne se connecte pas au relay. L'interface web est accessible sur le port 9999, mais si Lighthouse est un service interne sans port exposé, voici comment le faire depuis la machine hôte :

# Récupérer l'IP du conteneur
LIGHTHOUSE_IP=$(docker inspect lighthouse \
  --format '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}')

# Générer une identité Nostr
curl -s -X POST \
  "http://$LIGHTHOUSE_IP:9999/api/settings/identity/generate" \
  -H "Content-Type: application/json" -d '{}'

# Valider le setup
curl -s -X POST \
  "http://$LIGHTHOUSE_IP:9999/api/setup/complete" \
  -H "Content-Type: application/json" -d '{}'

Récupère l'API key générée au démarrage — elle apparaît dans les logs :

docker logs lighthouse 2>&1 | grep "API Key"
# → API Key (first 8 chars) api_key=...

L'API key complète est dans /data/lighthouse/config/config.yaml sous server.api_key.

6. Connecter le relay et démarrer l'indexeur

API_KEY="<ta-clé-complète>"

# Démarrer la connexion au relay
curl -s -X POST "http://$LIGHTHOUSE_IP:9999/api/relays/1/connect" \
  -H "X-Api-Key: $API_KEY"

# Démarrer l'indexeur
curl -s -X POST "http://$LIGHTHOUSE_IP:9999/api/indexer/start" \
  -H "X-Api-Key: $API_KEY"

À ce stade, docker logs lighthouse montre des torrents qui arrivent. Mais probablement zéro.

7. Ajouter le bot YGG à la whitelist

C'est le truc que j'ai mis du temps à comprendre. Lighthouse filtre les événements Nostr selon un système de “Web of Trust” — il n'indexe que les torrents publiés par des comptes de confiance. Avec une identité fraîchement générée sans abonnements, la liste des comptes de confiance est vide.

Le bot YGG a un seul pubkey sur le relay : 6aeb55064ea8b777591055e5704612e0e863fcc00bb211741781be299473c54e

En npub : npub1dt442pjw4zmhwkgs2hjhq3sjur5x8lxqpwepzaqhsxlzn9rnc48q5ezkq2

curl -s -X POST "http://$LIGHTHOUSE_IP:9999/api/trust/whitelist" \
  -H "X-Api-Key: $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "npub": "npub1dt442pjw4zmhwkgs2hjhq3sjur5x8lxqpwepzaqhsxlzn9rnc48q5ezkq2",
    "alias": "YGG Bot"
  }'

# Relancer l'indexeur pour prendre en compte la whitelist
curl -s -X POST "http://$LIGHTHOUSE_IP:9999/api/indexer/stop" \
  -H "X-Api-Key: $API_KEY"
curl -s -X POST "http://$LIGHTHOUSE_IP:9999/api/indexer/start" \
  -H "X-Api-Key: $API_KEY"

Les logs montrent maintenant les torrents qui s'indexent.

8. Ajouter dans Prowlarr

Dans Prowlarr → Settings → Indexers → + Add → Generic Torznab :

• URL : http://lighthouse:9999
• API Path : /api/torznab
• API Key : ta clé Lighthouse
• Categories : sélectionne ce qui t'intéresse (Movies, TV, etc.)

Clique sur Test — si tout est en place, Prowlarr valide la connexion. L'indexeur se synchronise ensuite automatiquement avec Radarr et Sonarr.

Ce qui fonctionne, ce qui ne fonctionne pas encore

Le contenu sur le relay ygg.gratis au moment où j'écris ça est clairement en phase de démarrage. Les 500 premiers événements indexés dans ma session étaient surtout des journaux PDF français, des BD et quelques films récents en FRENCH. Le catalogue est loin d'égaler ce qu'était YGGTorrent à son apogée.

C'est logique : la migration vers Nostr est récente. Les utilisateurs qui publiaient sur YGG doivent adopter le nouveau workflow. Le relay grossit progressivement.

La recherche Torznab fonctionne. Les résultats remontaient dans Prowlarr sans problème lors de mes tests. Les métadonnées (taille, seeders) sont présentes sur les torrents bien formatés.

Ce qui manque : un mécanisme pour découvrir automatiquement de nouveaux publishers de confiance sur le relay. Pour l'instant c'est manuel — si quelqu'un d'autre publie du contenu de qualité sur relay.ygg.gratis, il faut ajouter son npub à la whitelist à la main. La spec U2P mentionne un “Import Servarr” en cours de développement, qui devrait automatiser une partie de ça.

Pourquoi j'aime l'idée même si c'est encore chantier

La fragilité des anciens systèmes était structurelle. yggapi.eu existait parce que quelqu'un maintenait un scraper et un serveur. Quand cette personne a arrêté, tout est mort d'un coup. Ce n'est pas un reproche — c'est juste ce que ça coûte de faire tourner une infrastructure comme ça gratuitement sur le long terme.

Le modèle Nostr déplace la dépendance. Il n'y a plus de scraper central à maintenir. Le contenu existe tant que des relays l'hébergent et que des gens le publient. Lighthouse peut être remplacé par un autre client. Le relay peut migrer. La clé publique du bot YGG, elle, reste la même.

Est-ce que ça va tenir ? Je ne sais pas. La décentralisation en pratique produit souvent des systèmes plus fragiles que promis, juste pour des raisons différentes. Mais l'architecture est saine, et le fait qu'UTOPEER soit open-source avec une implémentation Torznab complète change la dynamique par rapport aux solutions précédentes.

Pour l'instant ça tourne chez moi, Prowlarr remonte des résultats, et le relay grossit. C'est suffisant pour que ce soit utile.

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

Le principe

n8n est un outil d'automatisation open-source (comme Zapier, mais auto-hébergeable). L'idée est simple :

1. Récupérer le flux RSS d'une chaîne YouTube
2. Filtrer les vidéos selon nos critères
3. Vérifier si la vidéo existe déjà sur PeerTube
4. Si non, l'importer via l'API PeerTube

Prérequis

• Une instance n8n (ex: n8n.example.org)
• Une instance PeerTube (ex: video.example.org)
• Les credentials OAuth2 de votre PeerTube

Étape 1 : Récupérer le flux RSS YouTube

Chaque chaîne YouTube dispose d'un flux RSS. L'URL est :

https://www.youtube.com/feeds/videos.xml?channel_id=CHANNEL_ID

Pour trouver le CHANNEL_ID, allez sur la chaîne YouTube et regardez l'URL. Par exemple pour la chaîne fictive “TechTalks” :

https://www.youtube.com/channel/UC1234567890abcdef

Dans n8n, créez un nœud HTTP Request : – Method: GET – URL: https://www.youtube.com/feeds/videos.xml?channel_id=UC1234567890abcdef – Response Format: Text

Étape 2 : Parser et filtrer les vidéos

Ajoutez un nœud Code pour extraire les vidéos qui nous intéressent. Par exemple, pour ne garder que les vidéos dont le titre contient “Tutorial” :

const xml = $input.first().json.data;
const entries = xml.split('<entry>');
const videos = [];

for (let i = 1; i < entries.length; i++) {
  const entry = entries[i];
  const videoIdMatch = entry.match(/<yt:videoId>([^<]+)<\/yt:videoId>/);
  const titleMatch = entry.match(/<title>([^<]+)<\/title>/);

  if (videoIdMatch && titleMatch) {
    const title = titleMatch[1];
    // Filtrer : ne garder que les tutoriels
    if (title.toLowerCase().includes('tutorial')) {
      videos.push({
        videoId: videoIdMatch[1],
        title: title,
        url: `https://www.youtube.com/watch?v=${videoIdMatch[1]}`
      });
    }
  }
}

if (videos.length > 0) {
  return [{json: videos[0]}];
}
return [];

Vous pouvez adapter le filtre selon vos besoins : – Mots-clés dans le titre – Exclusion de certains termes – Combinaison de critères

Étape 3 : Vérifier les doublons

Avant d'importer, vérifions que la vidéo n'existe pas déjà. Ajoutez un nœud HTTP Request :

• Method: GET
• URL: https://video.example.org/api/v1/search/videos?search={{ encodeURIComponent($json.title) }}&searchTarget=local

Puis un nœud Code pour filtrer :

const searchResult = $input.first().json;
const videoTitle = $('Parse RSS').first().json.title;
const videoUrl = $('Parse RSS').first().json.url;

const exists = searchResult.data?.some(v => v.name === videoTitle);

if (exists) {
  return []; // Vidéo déjà présente, on arrête
}

return [{json: {title: videoTitle, url: videoUrl}}];

Étape 4 : Obtenir un token PeerTube

Pour utiliser l'API PeerTube, il faut s'authentifier. Ajoutez un nœud HTTP Request :

• Method: POST
• URL: https://video.example.org/api/v1/users/token
• Content-Type: application/x-www-form-urlencoded
• Body:
  • client_id: votre client ID
  • client_secret: votre client secret
  • grant_type: password
  • username: votre username
  • password: votre password

Astuce : Vous pouvez trouver le client_id et client_secret via l'API /api/v1/oauth-clients/local.

Étape 5 : Importer la vidéo

Dernier nœud HTTP Request pour lancer l'import :

• Method: POST
• URL: https://video.example.org/api/v1/videos/imports
• Headers: Authorization: Bearer {{ $json.access_token }}
• Content-Type: multipart/form-data
• Body:
  • targetUrl: l'URL YouTube
  • channelId: l'ID du channel PeerTube destination
  • privacy: 1 (public), 2 (unlisted), 3 (private)
  • name: le titre de la vidéo
  • category: l'ID de la catégorie (optionnel)

Planification

Ajoutez un nœud Schedule Trigger au début du workflow pour exécuter automatiquement l'import :

• Toutes les 6 heures pour un flux actif
• Une fois par jour pour un flux moins actif

Le workflow complet

[Schedule] → [Get RSS] → [Parse & Filter] → [Check Exists] → [Filter New] → [Get Token] → [Import]

Points d'attention

1. Cookies YouTube : Si l'import échoue avec une erreur 403, PeerTube a peut-être besoin de cookies YouTube valides. Consultez la documentation yt-dlp pour configurer les cookies.

2. Rate limiting : N'exécutez pas le workflow trop fréquemment pour éviter d'être bloqué par YouTube.

3. Stockage : Les vidéos importées prennent de l'espace disque. Pensez à créer un workflow de nettoyage pour les anciennes vidéos si nécessaire.

4. Légalité : Assurez-vous d'avoir le droit de republier les vidéos que vous importez (Creative Commons, accord de l'auteur, etc.).

Conclusion

n8n rend l'automatisation accessible à tous. Avec ce workflow, vous pouvez créer votre propre miroir PeerTube de contenus YouTube sélectionnés, tout en gardant le contrôle sur ce qui est importé grâce aux filtres.

Ressources utiles : – Documentation n8n – Documentation PeerTube – API REST PeerTube

Pourquoi Plausible ?

Plausible est une alternative open-source et respectueuse de la vie privée à Google Analytics. Contrairement à ce dernier :

• Pas de cookies : aucune bannière RGPD nécessaire
• Pas de données personnelles : les adresses IP sont hashées puis supprimées
• Léger : le script fait moins de 1 Ko (vs ~45 Ko pour Google Analytics)
• Open-source : vous pouvez l'auto-héberger

Notre infrastructure

Notre homelab utilise Docker Compose avec nginx-proxy pour le reverse proxy et Let's Encrypt pour les certificats SSL. La configuration complète est disponible sur GitHub.

Installation de Plausible

1. Configuration DNS

Ajoutez un enregistrement DNS pour votre sous-domaine analytics. Dans notre cas, nous utilisons plausible.votredomaine.org :

python3 scripts/ovh-dns.py add plausible --type A --ip VOTRE_IP
python3 scripts/ovh-dns.py add plausible --type AAAA --ip VOTRE_IPV6

2. Fichier Docker Compose

Créez le fichier services/plausible.yml :

services:
  plausible:
    image: ghcr.io/plausible/community-edition:v3.1.0
    container_name: plausible
    command: /entrypoint.sh run
    healthcheck:
      test: ["CMD-SHELL", "wget -q --spider http://127.0.0.1:8000/api/health || exit 1"]
      start_period: 2m
      interval: 30s
    environment:
      - BASE_URL=https://plausible.${DOMAIN}
      - SECRET_KEY_BASE=${PLAUSIBLE_SECRET_KEY}
      - TOTP_VAULT_KEY=${PLAUSIBLE_TOTP_KEY}
      - DISABLE_REGISTRATION=invite_only
      - DATABASE_URL=postgres://plausible:${PLAUSIBLE_DB_PASSWORD}@plausible-db:5432/plausible
      - CLICKHOUSE_DATABASE_URL=http://plausible-events-db:8123/plausible_events_db
      - VIRTUAL_HOST=plausible.${DOMAIN}
      - VIRTUAL_PORT=8000
      - LETSENCRYPT_HOST=plausible.${DOMAIN}
      - LETSENCRYPT_EMAIL=${LETSENCRYPT_EMAIL}
    volumes:
      - plausible-data:/var/lib/plausible
    networks:
      - proxy-tier
      - plausible-internal
    depends_on:
      plausible-db:
        condition: service_healthy
      plausible-events-db:
        condition: service_healthy

  plausible-db:
    image: postgres:16-alpine
    container_name: plausible-db
    environment:
      - POSTGRES_USER=plausible
      - POSTGRES_PASSWORD=${PLAUSIBLE_DB_PASSWORD}
      - POSTGRES_DB=plausible
    volumes:
      - /data/plausible-db:/var/lib/postgresql/data
    networks:
      - plausible-internal
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U plausible -d plausible"]
      start_period: 1m
      interval: 10s

  plausible-events-db:
    image: clickhouse/clickhouse-server:24.12-alpine
    container_name: plausible-events-db
    environment:
      - CLICKHOUSE_SKIP_USER_SETUP=1
    volumes:
      - /data/plausible-events-db:/var/lib/clickhouse
      - /data/plausible-clickhouse-config/listen.xml:/etc/clickhouse-server/config.d/listen.xml:ro
    networks:
      - plausible-internal
    healthcheck:
      test: ["CMD-SHELL", "wget --no-verbose --tries=1 --spider http://127.0.0.1:8123/ping || exit 1"]
      start_period: 1m
      interval: 10s

networks:
  proxy-tier:
    external: true
  plausible-internal:
    driver: bridge

volumes:
  plausible-data:

3. Configuration ClickHouse pour IPv4

ClickHouse écoute par défaut sur IPv6. Si votre réseau Docker n'a pas IPv6, créez ce fichier :

sudo mkdir -p /data/plausible-clickhouse-config
sudo tee /data/plausible-clickhouse-config/listen.xml << 'EOF'
<clickhouse>
    <listen_host>0.0.0.0</listen_host>
</clickhouse>
EOF

4. Variables d'environnement

Ajoutez ces variables à votre fichier .env :

PLAUSIBLE_SECRET_KEY=$(openssl rand -base64 48)
PLAUSIBLE_TOTP_KEY=$(openssl rand -base64 32)
PLAUSIBLE_DB_PASSWORD=$(openssl rand -base64 24)

5. Démarrage

docker compose -f docker-compose.yml -f services/plausible.yml up -d

Le premier démarrage peut prendre 1-2 minutes. Vérifiez que tout est healthy :

docker ps | grep plausible

6. Création du compte admin

Rendez-vous sur https://plausible.votredomaine.org et créez votre compte administrateur.

Intégration avec PeerTube

Ajouter le site dans Plausible

1. Connectez-vous à votre instance Plausible
2. Cliquez sur “Add a website”
3. Entrez le domaine de votre PeerTube (ex: video.ut0pia.org)

Injecter le script dans PeerTube

Dans PeerTube, allez dans Administration → Configuration → Advanced → Custom JavaScript et ajoutez :

var script = document.createElement('script');
script.defer = true;
script.dataset.domain = 'video.votredomaine.org';
script.src = 'https://plausible.votredomaine.org/js/script.js';
document.head.appendChild(script);

Attention : Le champ “Custom JavaScript” attend du JavaScript pur, pas de balises HTML <script>.

Conformité RGPD

Plausible est conçu pour être conforme au RGPD sans bannière de consentement. Selon la politique de données de Plausible :

• Aucun cookie n'est utilisé
• Aucune donnée personnelle n'est collectée
• Les adresses IP sont hashées et jamais stockées
• Pas de tracking cross-site

Vous pouvez donc l'utiliser sans afficher de bannière cookie, tout en restant transparent dans votre politique de confidentialité.

Ressources

• Documentation Plausible Self-Hosting
• Plausible Community Edition sur GitHub
• Documentation PeerTube – Personnalisation
• Notre configuration Docker Compose Homelab
• Politique de données Plausible (RGPD)

Sa solution :

x = S/2 + √(S²/4 - P)
y = S/2 - √(S²/4 - P)

où S est la somme et P le produit des deux nombres recherchés.

Intrigué par sa découverte, j'ai voulu vérifier formellement sa démonstration en utilisant un assistant de preuve mathématique. Cet article raconte notre démarche.

Le raisonnement de Jules

L'intuition géométrique

Jules a imaginé le problème à partir d'un grand carré. Son raisonnement était le suivant :

« La somme de deux nombres, c'est forcément égal à la moitié plus quelque chose, plus la moitié moins quelque chose. Du coup on peut barrer les écarts quand on fait la somme. Mais ces écarts sont utiles pour trouver le produit. »

En termes mathématiques, il a posé : – x = S/2 + d (la moyenne plus un écart) – y = S/2 – d (la moyenne moins le même écart)

Pourquoi ça marche pour la somme

x + y = (S/2 + d) + (S/2 - d) = S

Les écarts +d et -d « se barrent » — c'est exactement ce qu'il avait observé.

La visualisation avec le carré

Jules a visualisé le produit x × y comme une opération sur des carrés :

┌─────────────────┐
│                 │
│   Carré de      │    Aire = (S/2)²
│   côté S/2      │
│                 │
└─────────────────┘

Le produit (S/2 + d)(S/2 – d) correspond à l'aire du grand carré moins un petit carré de côté d :

Produit = (S/2)² - d²

C'est l'identité remarquable (a+b)(a-b) = a² – b², qu'il a retrouvée intuitivement.

Déduction de la formule

Puisque P = (S/2)² – d², on isole d :

d² = S²/4 - P
d = √(S²/4 - P)

D'où la formule finale :

x = S/2 + √(S²/4 - P)
y = S/2 - √(S²/4 - P)

Vérification formelle avec Lean 4

Pour m'assurer que le raisonnement de Jules était mathématiquement rigoureux, j'ai décidé d'utiliser Lean 4, un langage de programmation conçu pour écrire des preuves mathématiques vérifiées par ordinateur.

Qu'est-ce que Lean ?

Lean est un assistant de preuve : un langage de programmation où l'on écrit des théorèmes et leurs démonstrations. Le compilateur vérifie automatiquement que chaque étape de la preuve est logiquement correcte. Si le code compile, la preuve est mathématiquement valide.

Installation de Lean 4

J'ai installé Lean 4 en quelques commandes :

# 1. Installer elan (gestionnaire de versions Lean)
brew install elan-init

# 2. Installer Lean 4 stable
elan default stable

# 3. Créer un nouveau projet avec Mathlib
lake new theoremes_jules
cd theoremes_jules

# 4. Ajouter Mathlib comme dépendance (dans lakefile.toml)
# puis télécharger les dépendances
lake update

Le code Lean pas à pas

Voici la formalisation complète du théorème de Jules, avec des explications pour chaque partie :

import Mathlib.Data.Real.Sqrt

Import : On importe le module de Mathlib qui contient la définition de la racine carrée sur les nombres réels (Real.sqrt) et le lemme Real.sq_sqrt qui dit que (√z)² = z.

def EstSolutionSommeProduit (x y S P : ℝ) : Prop :=
  x + y = S ∧ x * y = P

Définition : On définit ce que signifie “x et y sont solutions du problème somme-produit”. C'est une proposition (Prop) qui est vraie si et seulement si : – x + y = S (la somme vaut S) – ET (∧) – x * y = P (le produit vaut P)

theorem formule_jules (S P : ℝ) (h : S^2 / 4 - P ≥ 0) :
    EstSolutionSommeProduit
      (S / 2 + Real.sqrt (S^2 / 4 - P))
      (S / 2 - Real.sqrt (S^2 / 4 - P))
      S P := by

Énoncé du théorème : – S P : ℝ — S et P sont des nombres réels – h : S^2 / 4 - P ≥ 0 — on suppose que S²/4 – P ≥ 0 (sinon la racine carrée n'existe pas dans ℝ) – Les deux arguments suivants sont x et y selon la formule de Jules – EstSolutionSommeProduit ... S P — on veut prouver que x et y sont bien solutions – by — on commence la preuve en mode tactique

  constructor

Tactique constructor : Comme on doit prouver une conjonction (A ∧ B), cette tactique sépare le but en deux sous-buts : 1. Prouver que x + y = S 2. Prouver que x * y = P

  · ring

Première partie (prouver x + y = S) : – ring — résout automatiquement l'égalité algébrique

En effet : (S/2 + √...) + (S/2 - √...) = S/2 + S/2 = S ✓

  · have h1 : (S / 2 + Real.sqrt (S^2 / 4 - P)) * (S / 2 - Real.sqrt (S^2 / 4 - P))
            = (S / 2)^2 - (Real.sqrt (S^2 / 4 - P))^2 := by ring
    rw [h1, Real.sq_sqrt h]
    ring

Deuxième partie (prouver x × y = P) : – have h1 : ... := by ring — on établit un fait intermédiaire : le produit (a+b)(a-b) = a² – b² (identité remarquable), prouvé par ring – rw [h1, Real.sq_sqrt h] — on réécrit en utilisant h1, puis on applique le lemme Real.sq_sqrt qui dit que (√z)² = z quand z ≥ 0 (ce qu'on sait grâce à l'hypothèse h) – ring — on conclut que (S/2)² – (S²/4 – P) = S²/4 – S²/4 + P = P

Le verdict

✓ Build successful

Le code compile — donc la preuve est mathématiquement correcte. Le théorème de Jules est formellement vérifié : sa formule donne bien deux nombres dont la somme est S et le produit est P.

Contexte historique

François Viète (1540-1603)

Jules a redécouvert ce qu'on appelle les relations de Viète, du nom du mathématicien français François Viète.

En 1591, Viète publie In artem analyticem isagoge, un ouvrage qui fonde l'algèbre moderne. Il est le premier à utiliser des lettres pour désigner les inconnues (voyelles A, E, I...) et les constantes (consonnes B, C, D...). On lui doit l'invention du calcul littéral.

Les formules de Viète établissent que pour un polynôme du second degré x² – Sx + P = 0 : – La somme des racines = S – Le produit des racines = P

C'est exactement le problème solutionné par mon fils.

Le lien précis avec la formule de Jules

Jules a résolu le problème inverse de Viète : connaissant S et P, retrouver x et y.

Si x et y vérifient x + y = S et x × y = P, alors x et y sont les racines du polynôme :

t² - St + P = 0

La formule quadratique classique donne :

t = (S ± √(S² - 4P)) / 2

En réécrivant cette formule :

t = S/2 ± √(S² - 4P)/2
t = S/2 ± √((S² - 4P)/4)
t = S/2 ± √(S²/4 - P)      ← C'est la formule de Jules !

Mon fils a donc retrouvé la formule quadratique par un raisonnement purement géométrique, ce qui est exactement dans l'esprit des travaux de Viète — établir le lien entre les racines d'un polynôme et ses coefficients.

Sources : – Formules de Viète – Math93 – François Viète – CultureMath (ENS) – Biographie de Viète – Bibmath

Les mathématiciens grecs et l'algèbre géométrique

L'approche de Jules — raisonner avec des carrés et des aires — rappelle celle des mathématiciens grecs anciens.

Le Livre II des Éléments d'Euclide (vers 300 av. J.-C.) contient ce qu'on appelle l'algèbre géométrique. Euclide y démontre les identités remarquables par des constructions de carrés et de rectangles, exactement comme Jules l'a fait intuitivement.

Par exemple, la proposition 4 du Livre II énonce que « le carré de la droite entière est égal aux carrés des segments, et à deux fois le rectangle contenu sous les deux segments » — c'est notre identité (a+b)² = a² + 2ab + b².

Cette tradition géométrique a influencé les mathématiciens arabes comme Al-Khwarizmi (VIIIe siècle), dont le traité Abrégé du calcul par la restauration et la comparaison utilise les identités remarquables d'Euclide pour résoudre les équations du second degré.

Sources : – Livre II des Éléments d'Euclide – Wikipédia – Identité remarquable – Wikipédia – Les identités remarquables – Automaths

Conclusion

À 15 ans, Jules a redécouvert de manière autonome un résultat fondamental de l'algèbre, en utilisant une intuition géométrique remarquable. Son approche — décomposer deux nombres symétriquement autour de leur moyenne — est élégante et montre une compréhension profonde de la structure mathématique.

Ce qui me frappe, c'est que son raisonnement suit exactement la tradition des mathématiciens grecs : penser l'algèbre géométriquement, avec des carrés et des aires. Sans le savoir, il a refait le chemin d'Euclide.

Grâce à Lean 4, nous avons pu vérifier formellement que sa démonstration est mathématiquement correcte. Le théorème est prouvé.

Preuve formellement vérifiée avec Lean 4 et Mathlib

La migration vers un serveur OVH SYS-1 équipé d'un Intel Xeon E-2136 était l'occasion de moderniser l'infrastructure tout en documentant le processus pour d'autres administrateurs de homelab.

Ce que vous allez apprendre

• Préparer un nouveau serveur Ubuntu 24 pour Docker
• Configurer SSH
• Utiliser rsync avec préservation des hardlinks
• Adapter une stack Docker Compose à un nouvel environnement
• Gérer la migration DNS avec zero downtime

Spécifications des serveurs

Services à migrer

Mon infrastructure Docker Compose comprend :

• Reverse proxy : nginx-proxy + acme-companion (Let's Encrypt automatique)
• Vidéo : PeerTube (plateforme vidéo fédérée)
• Dashboard : Homarr
• Workflow : n8n
• Blog : WriteFreely (fédéré via ActivityPub)

Volume total des données : ~935 Go (réduit à ~350 Go après nettoyage).

1. Préparation du Nouveau Serveur

1.1 Installation de Docker avec stockage dédié

Sur Ubuntu 24 Server, la partition root est souvent limitée (typiquement 20-50 Go sur un serveur OVH). Il est crucial de configurer Docker pour stocker ses images et volumes sur une partition de données séparée.

# Installation de Docker via le script officiel
curl -fsSL https://get.docker.com | sudo sh

# Ajout de l'utilisateur au groupe docker
sudo usermod -aG docker $USER

# Arrêt de Docker pour la configuration
sudo systemctl stop docker

Configuration du stockage Docker sur /data/docker :

# Création du répertoire de données
sudo mkdir -p /data/docker

# Configuration de Docker avec data-root personnalisé
# et limitation des logs pour éviter de saturer le disque
sudo tee /etc/docker/daemon.json << 'EOF'
{
  "data-root": "/data/docker",
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}
EOF

# Redémarrage de Docker
sudo systemctl start docker

# Vérification
docker info | grep "Docker Root Dir"
# Doit afficher: Docker Root Dir: /data/docker

Pourquoi cette configuration ?

• data-root : Évite de saturer la partition root avec les images Docker
• log-driver + log-opts : Limite chaque fichier de log à 10 Mo avec 3 rotations maximum, évitant l'accumulation de logs volumineux

1.2 Installation des dépendances Python (PEP 668)

Ubuntu 24 implémente strictement le PEP 668 qui empêche l'installation de paquets Python via pip au niveau système. Cette décision vise à éviter les conflits entre pip et apt.

# INCORRECT sur Ubuntu 24 - génère une erreur
pip3 install requests python-dotenv
# error: externally-managed-environment

# CORRECT - utiliser les paquets système
sudo apt install -y python3-requests python3-dotenv

Alternatives si vous avez besoin de versions spécifiques :

# Option 1 : Environnement virtuel (recommandé pour le développement)
python3 -m venv ~/venv
source ~/venv/bin/activate
pip install requests python-dotenv

# Option 2 : pipx pour les outils CLI
pipx install <package>

Pour mes scripts d'organisation de médias, les versions système suffisent.

1.3 Installation de Node.js via nvm

NodeSource, longtemps la méthode recommandée, a changé ses conditions en 2023. nvm (Node Version Manager) offre plus de flexibilité :

# Installation de nvm
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash

# Rechargement du shell
source ~/.bashrc

# Installation de la dernière LTS
nvm install --lts

# Vérification
node --version
npm --version

Avantages de nvm : – Installation dans le home utilisateur (pas de sudo) – Possibilité de switcher entre versions – Mise à jour simple via nvm install --lts

2. Configuration SSH Bidirectionnelle

Pour transférer les données de manière sécurisée, nous devons établir une connexion SSH de l'ancien vers le nouveau serveur et inversement.

2.1 Génération de clé sur l'ancien serveur

# Sur l'ANCIEN serveur
ssh-keygen -t ed25519 -N "" -f ~/.ssh/id_ed25519

# Afficher la clé publique à copier
cat ~/.ssh/id_ed25519.pub

Pourquoi ed25519 ? – Plus sécurisé que RSA à taille de clé équivalente – Plus rapide pour la génération et l'authentification – Clés plus courtes (plus faciles à copier/coller)

2.2 Autorisation sur le nouveau serveur

# Sur le NOUVEAU serveur
# Ajouter la clé publique de l'ancien serveur
echo "ssh-ed25519 AAAA... user@ancien-serveur" >> ~/.ssh/authorized_keys

# Vérifier les permissions (crucial pour SSH)
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

2.3 Test de connexion

# Depuis l'ANCIEN serveur, tester la connexion
ssh new_user@nouveau-serveur "hostname && uptime"

3. Synchronisation avec rsync : L'Art de Préserver les Hardlinks

3.1 Comprendre les hardlinks

Dans un système de fichiers, un hardlink est une référence directe au même inode sur le disque. Le fichier n'existe qu'une fois physiquement, mais apparaît à plusieurs endroits dans l'arborescence.

/data/source/fichier.mkv  (fichier original)
         |
         +-- hardlink --> /data/organise/fichier.mkv

Cela permet : – D'organiser les fichiers de différentes manières – De ne pas doubler l'espace disque – D'avoir plusieurs “vues” sur les mêmes données

3.2 L'importance du flag -H

Sans le flag -H, rsync copie chaque chemin comme un fichier séparé :

# MAUVAIS : duplique les données
rsync -avz /data/ user@serveur:/data/
# Résultat : 350 Go de fichiers + 350 Go de hardlinks = 700 Go

# CORRECT : préserve les hardlinks
rsync -avzH /data/ user@serveur:/data/
# Résultat : 350 Go total (hardlinks préservés)

3.3 Commande de synchronisation complète

# Synchronisation avec préservation des hardlinks
rsync -avzH --progress \
  --exclude='*.tmp' \
  --exclude='*.part' \
  /data/ new_user@nouveau-serveur:/data/

# Pour les syncs subséquentes, ajouter --delete
# pour supprimer les fichiers effacés sur la source
rsync -avzH --progress --delete \
  /data/ new_user@nouveau-serveur:/data/

Explication des flags : – -a : Archive (préserve permissions, propriétaire, timestamps, liens symboliques) – -v : Verbose (affiche les fichiers transférés) – -z : Compression durant le transfert – -H : Préserve les hardlinks (crucial pour notre cas) – --progress : Affiche la progression – --delete : Supprime les fichiers absents de la source

3.4 Vérification des hardlinks après transfert

# Sur le nouveau serveur, vérifier qu'un fichier a plusieurs liens
ls -li /data/media/*/fichier.mkv
# La première colonne (inode) et la troisième (link count) doivent montrer > 1

# Exemple de sortie :
# 1234567 -rw-r--r-- 2 new_user new_user 5.0G Dec 31 fichier.mkv
#                    ^-- 2 = le fichier existe à 2 endroits (hardlink)

4. Nettoyage Pré-Migration : 550 Go Économisés

4.1 Identification du problème

En analysant l'espace disque, j'ai découvert que de nombreux hardlinks étaient devenus “orphelins” : les fichiers sources avaient été supprimés, mais les hardlinks restaient dans les répertoires organisés.

Un hardlink orphelin (link count = 1) n'est plus un hardlink — c'est juste un fichier normal qui occupe de l'espace.

4.2 Script de nettoyage des hardlinks orphelins

#!/usr/bin/env python3
"""
clean-orphan-hardlinks.py
Supprime les fichiers qui étaient des hardlinks mais dont la source
a été supprimée (link count = 1).
"""
import os
import sys

# Répertoires à nettoyer
DIRS = ['/data/perso', '/data/pro']
DRY_RUN = '--dry-run' in sys.argv

deleted = 0
freed = 0

for directory in DIRS:
    if not os.path.isdir(directory):
        continue
    
    for root, dirs, files in os.walk(directory, topdown=False):
        for filename in files:
            filepath = os.path.join(root, filename)
            try:
                stat = os.stat(filepath)
                # Un hardlink a un link count > 1
                # Si link count = 1, la source a été supprimée
                if stat.st_nlink == 1:
                    freed += stat.st_size
                    if DRY_RUN:
                        print(f"[DRY-RUN] Would delete: {filepath}")
                    else:
                        os.remove(filepath)
                    deleted += 1
            except OSError:
                pass
        
        # Nettoyer les répertoires vides
        if not DRY_RUN:
            try:
                if not os.listdir(root):
                    os.rmdir(root)
            except OSError:
                pass

print(f"{'[DRY-RUN] ' if DRY_RUN else ''}"
      f"Deleted: {deleted} files, Freed: {freed / (1024**3):.2f} GB")

Utilisation :

# Prévisualisation (recommandé d'abord)
python3 clean-orphan-hardlinks.py --dry-run

# Exécution réelle
sudo python3 clean-orphan-hardlinks.py

4.3 Résultats du nettoyage

Le nettoyage a permis d'économiser environ 550 Go d'espace disque, réduisant le temps de transfert de ~15 heures à ~5 heures.

4.4 Nettoyage des anciens services

Profitez de la migration pour supprimer les données obsolètes :

# Exemples d'anciens services remplacés
rm -rf /data/mysql        # Si remplacé par PostgreSQL

5. Création des Réseaux Docker

Notre architecture utilise des réseaux Docker pour isoler les services :

# Réseau pour le reverse proxy (services publics)
docker network create proxy-tier

# Réseau interne pour les services avec bases de données
docker network create internal

Architecture réseau :

Internet
    |
    v
+-------+     proxy-tier     +-----------+
| nginx |<------------------>| Services  |
| proxy |                    | publics   |
+-------+                    +-----------+
                                   |
                             internal (isolé)
                                   |
                     +-------------+-------------+
                     |             |             |
                 +-------+   +---------+   +--------+
                 |Postgre|   |  Redis  |   | Autres |
                 +-------+   +---------+   +--------+

6. Adaptation des Chemins et Configurations

6.1 Modification des volumes Docker Compose

Les chemins diffèrent souvent entre les deux serveurs :

# Mise à jour automatique dans tous les fichiers de service
cd ~/services-web

# Remplacer les anciens chemins
find services/ -name "*.yml" -exec \
  sed -i 's|/home/ancien_user|/home/new_user|g' {} \;

# Vérification
grep -r "/home/ancien_user" services/
# Ne doit rien retourner

6.2 Migration des fichiers hors /data

Certains fichiers de configuration sont ailleurs :

# Cron jobs
scp ancien_user@ancien:/etc/cron.d/mon-cron /tmp/
sed -i 's|/home/ancien_user/cloud|/home/new_user/services-web|g' /tmp/mon-cron
sudo cp /tmp/mon-cron /etc/cron.d/
sudo chmod 644 /etc/cron.d/mon-cron

# Dotfiles importants
scp ancien_user@ancien:~/.ssh/authorized_keys ~/.ssh/

7. Mise à Niveau des Services (Grâce au Nouveau CPU)

7.1 Homarr : De la version legacy à v1.0+

L'Intel Atom N2800 ne supportant pas AVX, nous étions bloqués sur l'ancienne version de Homarr. Le Xeon E-2136 supporte AVX2, permettant de passer à la nouvelle version.

Ancien fichier (legacy) :

services:
  homarr:
    image: ghcr.io/ajnart/homarr:latest  # Version legacy
    environment:
      - VIRTUAL_PORT=7575  # Port différent
    volumes:
      - /data/homarr/configs:/app/data/configs
      - /data/homarr/icons:/app/public/icons
      - /data/homarr/data:/data

Nouveau fichier (v1.0+) :

services:
  homarr:
    image: ghcr.io/homarr-labs/homarr:latest  # Nouvelle image
    environment:
      - VIRTUAL_PORT=3000  # Nouveau port
      - AUTH_SECRET=${HOMARR_AUTH_SECRET}  # Nouveau : secret d'authentification
    volumes:
      - /data/homarr:/appdata  # Structure de volumes simplifiée

Migration des données :

# La structure de données a changé, il faut repartir de zéro
sudo rm -rf /data/homarr/*
sudo mkdir -p /data/homarr
sudo chown new_user:new_user /data/homarr

# Générer le secret d'authentification
openssl rand -hex 32
# Ajouter dans .env : HOMARR_AUTH_SECRET=<valeur>

7.2 PeerTube : Activation de la transcription Whisper

Avec le support AVX2, nous pouvons maintenant activer la transcription automatique des vidéos :

# Éditer la configuration PeerTube
nano /data/peertube/config/local-production.json

{
  "video_transcription": {
    "enabled": true,
    "engine": "whisper",
    "engine_options": {
      "model": "small"
    }
  }
}

Note : La transcription utilise CTranslate2 qui requiert AVX. Sur l'ancien serveur, cette fonctionnalité causait un “Illegal instruction (core dumped)”.

8. Migration des Volumes Docker

Certains volumes Docker ne sont pas dans /data mais dans le stockage Docker :

# Sur l'ANCIEN serveur : export des volumes
cd /tmp
docker run --rm -v certs:/data -v /tmp:/backup alpine \
  tar cvf /backup/vol-certs.tar -C /data .
docker run --rm -v vhost.d:/data -v /tmp:/backup alpine \
  tar cvf /backup/vol-vhost.tar -C /data .
docker run --rm -v html:/data -v /tmp:/backup alpine \
  tar cvf /backup/vol-html.tar -C /data .

# Transfert vers le nouveau serveur
scp /tmp/vol-*.tar new_user@nouveau:/tmp/

# Sur le NOUVEAU serveur : import des volumes
docker volume create certs
docker volume create vhost.d
docker volume create html

docker run --rm -v certs:/data -v /tmp:/backup alpine \
  tar xvf /backup/vol-certs.tar -C /data
docker run --rm -v vhost.d:/data -v /tmp:/backup alpine \
  tar xvf /backup/vol-vhost.tar -C /data
docker run --rm -v html:/data -v /tmp:/backup alpine \
  tar xvf /backup/vol-html.tar -C /data

Note sur le nommage : Les volumes sont préfixés par le nom du projet Docker Compose (le répertoire). Il faut adapter le nom si le répertoire change.

9. Basculement DNS

9.1 Stratégie zero-downtime

Notre approche : 1. Préparer tout sur le nouveau serveur (services prêts mais non exposés) 2. Faire une dernière synchronisation rsync 3. Arrêter les services sur l'ancien serveur 4. Basculer le DNS 5. Démarrer les services sur le nouveau serveur

9.2 Mise à jour DNS

# Obtenir la nouvelle IP publique
NEW_IP=$(curl -s ifconfig.me)
echo "Nouvelle IP: $NEW_IP"

# Mettre à jour l'enregistrement A chez votre registrar
# Les sous-domaines (CNAME) pointent vers le domaine principal

# Vérification de la propagation
watch -n 30 'dig +short mondomaine.org'

9.3 Vérification des certificats SSL

Les certificats Let's Encrypt ont été importés avec les volumes Docker. Ils seront automatiquement renouvelés par acme-companion :

# Vérifier les certificats existants
docker exec letsencrypt ls -la /etc/nginx/certs/

# Forcer le renouvellement si nécessaire
docker exec letsencrypt /app/signal_le_service

10. Démarrage et Vérification

10.1 Ordre de démarrage

cd ~/services-web

# 1. Infrastructure de base (reverse proxy + SSL)
docker compose up -d
sleep 30  # Attendre que nginx-proxy soit prêt

# 2. Services avec dépendances (ex: PeerTube + PostgreSQL + Redis)
docker compose -f docker-compose.yml -f services/peertube.yml up -d
sleep 30

# 3. Services média
docker compose -f docker-compose.yml -f services/media.yml up -d

# 4. Autres services
docker compose -f docker-compose.yml -f services/homarr.yml up -d
docker compose -f docker-compose.yml -f services/n8n.yml up -d
docker compose -f docker-compose.yml -f services/writefreely.yml up -d

10.2 Vérification des services

# État des conteneurs
docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"

# Tests HTTPS
for host in video www n8n blog; do
  echo -n "$host.mondomaine.org: "
  curl -sI --connect-timeout 5 "https://$host.mondomaine.org" 2>/dev/null | head -1
done

10.3 Vérification des logs

# Logs du reverse proxy
docker logs nginx-proxy --tail=50

# Logs d'un service spécifique
docker logs nom-conteneur --tail=50

# Logs en temps réel
docker compose -f docker-compose.yml -f services/service.yml logs -f

Bonnes Pratiques et Leçons Apprises

Ce qui a bien fonctionné

1. Toujours utiliser -H avec rsync quand des hardlinks sont impliqués. Sans ce flag, nous aurions doublé l'espace disque.

2. Nettoyer avant de migrer : 550 Go économisés = plusieurs heures de transfert en moins.

3. Tester chaque service individuellement avant de basculer le DNS. Cela permet d'identifier les problèmes de configuration.

4. Garder l'ancien serveur fonctionnel pendant quelques jours après la migration. Rollback facile en cas de problème.

5. Documenter les chemins spécifiques : certains chemins sont des héritages d'anciennes installations et peuvent surprendre.

Pièges à éviter

1. Ne pas oublier les volumes Docker : les certificats SSL et autres assets peuvent être dans des volumes, pas dans /data.

2. Attention aux permissions : certains conteneurs tournent avec des UID spécifiques (ex: WriteFreely en UID 5000). Un chown -R new_user:new_user /data peut casser ces services.

3. PEP 668 sur Ubuntu 24 : pip install au niveau système ne fonctionne plus. Utiliser apt ou venv.

4. Noms des volumes Docker : ils sont préfixés par le nom du répertoire projet. Adapter si le répertoire change.

5. Ports des nouvelles versions : vérifier la documentation quand on met à jour une image (ex: Homarr v1.0+ utilise le port 3000, pas 7575).

Améliorations futures

• Automatiser la détection des hardlinks orphelins avec un cron job
• Implémenter une sauvegarde 3-2-1 avec rsync vers un stockage distant
• Ajouter du monitoring (Prometheus + Grafana) pour anticiper les problèmes d'espace disque

Conclusion

Cette migration m'a pris environ une journée complète, dont la majorité pour le transfert des données. Le nettoyage préalable des hardlinks orphelins a été la clé pour réduire ce temps de manière significative.

Le passage à un CPU moderne ouvre de nouvelles possibilités : transcription automatique des vidéos PeerTube, utilisation de la dernière version de Homarr, et de la marge pour de futurs services.

Les points les plus importants à retenir :

1. rsync -H pour préserver les hardlinks
2. Nettoyer avant de migrer pour gagner du temps
3. Tester avant de basculer le DNS
4. Documenter les chemins spécifiques de votre configuration

J'espère que ce guide vous sera utile pour votre propre migration.