Début 2026, Andrej Karpathy (cofondateur d’OpenAI, ex-directeur IA de Tesla) a partagé sur X une idée simple et redoutablement efficace pour résoudre ce problème : et si on arrêtait d’écrire la base de connaissances soi-même, pour la laisser entièrement à un LLM ?

C’est ce qu’il appelle le LLM wiki, ou second cerveau. Cet article décortique le concept, explique pourquoi il enterre l’approche RAG pour un usage personnel, et montre comment l’implémenter avec Obsidian et Claude Code.

L’idée de Karpathy : compiler, pas résumer

La phrase qui résume tout, c’est la sienne :

“You rarely ever write or edit the wiki manually, it’s the domain of the LLM.” (Vous n’écrivez ou ne modifiez quasiment jamais le wiki à la main, c’est le domaine du LLM.)

Le retournement est total. Dans la vision classique du « second cerveau » (celle popularisée par Tiago Forte et sa méthode PARA), c’est vous qui prenez les notes, qui les rangez, qui les reliez. L’IA n’intervient qu’à la fin, pour répondre à des questions sur un corpus que vous avez patiemment construit.

Karpathy inverse la chaîne. Vous ne faites plus qu’une chose : collecter de la matière brute. Des articles, des papiers de recherche, des notes de lecture, des transcriptions de podcasts, des bouts de conversation : tout ce qui vous traverse. Vous jetez ça dans un dossier, et vous dites au LLM : « compile ».

Compilation ≠ résumé

C’est la distinction centrale, et elle est plus subtile qu’elle n’en a l’air.

Un résumé compresse : il jette du détail pour produire une version plus courte. Vous perdez de l’information à chaque passage.

Une compilation, au sens de Karpathy, restructure sans appauvrir. Le LLM lit chaque source, en extrait les concepts, les personnes, les idées clés, puis les réécrit dans un format homogène : des articles façon encyclopédie, reliés entre eux par des backlinks, dédupliqués, et débarrassés des contradictions entre sources. Le détail est préservé : c’est la forme qui devient cohérente.

La métaphore du compilateur est volontaire. De même qu’un compilateur transforme du code source hétérogène en un binaire structuré et exécutable, le LLM transforme un fouillis de sources en une ontologie navigable.

Ce que ça donne à l’échelle

Karpathy avance un chiffre : sur un seul de ses sujets de recherche, son wiki avait atteint ~100 articles et 400 000 mots (plus long que la plupart des thèses de doctorat) sans qu’il en écrive une seule ligne directement. Le LLM rédige, relie, catégorise, et vérifie la cohérence. L’humain ne fait qu’alimenter et interroger.

Sa propre conclusion, lâchée sur X : « I think there is room here for an incredible new product. »

Ce qu’il ne dit pas explicitement, mais qui découle directement du raisonnement : si le wiki compilé est un artefact propre et lisible, pourquoi aurait-on besoin d’une infrastructure de retrieval pour l’interroger ? La question mène directement au sujet qui fâche.

Pourquoi ça enterre le RAG (pour un usage personnel)

Voilà le point qui fait tiquer tous ceux qui ont déjà bricolé un assistant documentaire. Depuis trois ans, la réponse par défaut à « je veux interroger mes documents » s’appelle RAG (Retrieval-Augmented Generation) : on découpe les documents en morceaux, on les transforme en vecteurs, on les stocke dans une base vectorielle, et à chaque question on va rechercher les passages les plus proches pour les injecter dans le contexte.

Karpathy propose de tout jeter. Pas de base vectorielle. Pas de pipeline d’embeddings. Pas d’infrastructure de retrieval. Juste des fichiers markdown, un LLM à grande fenêtre de contexte, et c’est tout.

L’argument est solide une fois qu’on le pose à plat :

L’intuition profonde : le RAG fait le même travail de tri à chaque question, sur de la donnée brute jamais nettoyée. Le LLM wiki fait ce travail une seule fois, au moment de la compilation, et produit un artefact propre, condensé, qui tient dans la fenêtre de contexte des modèles longs modernes. Pour une base de connaissances à l’échelle personnelle (quelques centaines d’articles), le RAG devient une usine à gaz dont on n’a tout simplement plus besoin.

⚠️ Nuance importante : ce raisonnement vaut pour un usage personnel. À l’échelle entreprise (des millions de documents, du contrôle d’accès granulaire, des contraintes de fraîcheur en temps réel), le RAG garde toute sa pertinence. Le LLM wiki n’est pas une religion, c’est le bon outil pour la bonne échelle.

Le concept est posé. Reste la question qui dérange toujours : si c’est si simple, pourquoi est-ce que personne ne l’a empaqueté proprement ? Karpathy lui-même tourne sur des scripts maison. Voici comment remplacer ces scripts par quelque chose de plus solide.

De l’idée au système : Obsidian + Claude Code

L’idée de Karpathy est un pattern, pas un produit. Lui-même reconnaît tourner avec des « scripts Python un peu hacky » pour orchestrer le LLM, plus Obsidian comme couche de visualisation. La bonne nouvelle : avec Claude Code, on n’a pas besoin de scripts. Les slash commands personnalisées suffisent à tout orchestrer depuis le terminal, directement dans le dossier du wiki.

L’architecture en trois couches

Tout le système repose sur une séparation nette entre la matière brute, le savoir compilé et les règles du jeu :

mon-second-cerveau/
├── raw/              ← vous déposez ici vos sources brutes
├── wiki/             ← le LLM écrit ici les articles compilés
│   └── index.md      ← sommaire auto-généré de tout le wiki
├── log.md            ← historique des opérations
├── CLAUDE.md         ← le "schéma" : règles d'organisation du cerveau
└── .claude/
    └── commands/     ← les slash commands personnalisées
        ├── ingest.md
        ├── lint.md
        ├── query.md
        └── save.md

• Le dossier raw/ est votre boîte de dépôt. Vous y jetez tout, sans organisation.
• Le dossier wiki/ est la sortie du LLM : des articles encyclopédiques reliés entre eux, plus un index.md qui résume l’ensemble d’un coup d’œil.
• Le fichier CLAUDE.md joue le rôle de schéma. Il décrit comment le cerveau doit être structuré : conventions de nommage, format des pages, règles de liaison. C’est le contrat que l’agent suit.
• Obsidian vient se brancher par-dessus le dossier wiki/ : il transforme les backlinks markdown en un graphe de connaissances navigable visuellement.

Les quatre slash commands (/ingest, /lint, /query, /save) orchestrent tout le système. Comment les créer et ce qu’elles contiennent exactement : c’est l’objet du tutoriel ci-dessous.

Le rythme réel : une semaine avec ce système

La vraie différence avec n’importe quel autre outil de notes, c’est que vous arrêtez de penser à l’organisation en temps réel. L’effort mental de « où est-ce que je range ça ? » disparaît complètement. Ce n’est pas anodin : c’est précisément cet effort qui fait qu’on abandonne tous les systèmes de notes au bout de trois semaines.

En pratique, le rythme s’installe naturellement en deux temps.

En continu : vous collectez sans filtrer. Un article intéressant → copié dans raw/. Une transcription de conférence → déposée dans raw/. Des notes griffonnées après une réunion → dans raw/. Le dossier est un bac à sable, pas une bibliothèque. Rien n’a besoin d’être propre pour y atterrir.

Obsidian Clipper, l’extension navigateur officielle d’Obsidian, simplifie ce geste au maximum. En un clic depuis Chrome ou Firefox, elle convertit n’importe quelle page web en .md formaté et l’enregistre directement dans raw/. L’article que vous lisez en ligne atterrit dans la boîte de dépôt sans copier-coller ni reformatage.

En batch : une fois par semaine (ou quand le dossier raw/ commence à peser), vous lancez /ingest. Ce qui prenait une heure de rangement manuel (lire, catégoriser, relier, déduper) se passe sans vous. Vous relisez le résultat, vous corrigez ce qui cloche, et c’est fait. /lint tourne en parallèle quand le wiki a grossi : il vous rend un rapport des incohérences, vous les arbitrez en cinq minutes.

Ce que ça change dans la durée : au bout de quelques mois, vous avez un corpus dense qui répond à vos questions avec vos propres sources. /query ne cherche pas dans des vecteurs : il raisonne sur du texte que vous avez collecté, compilé dans votre ontologie. La différence avec un ChatGPT généraliste est réelle et se sent.

Le tout est versionnable avec git. Votre second cerveau devient un dépôt : auditable, diffable, restaurable. Loin du trou noir qu’est un espace Notion.

Où ça coince vraiment

Ça tient sur le papier. Mais quelques mois avec ce système font apparaître des frictions que les commandes ne documentent pas.

Ce qui est vraiment fort :

• L’effort d’organisation tombe à zéro. C’est le point. Le frein historique de tout système de notes (le rangement) disparaît.
• Format ouvert, zéro lock-in. Du markdown, des dossiers, du git. Pas de SaaS qui ferme boutique avec vos données dedans.
• Lisible et auditable. Contrairement à une base vectorielle, vous pouvez lire votre cerveau. Vous voyez ce que le LLM a écrit, et le corriger si besoin.
• Le coût computationnel est payé une fois, à la compilation, pas à chaque requête.

Les limites, qu’il faut regarder en face :

• Vous déléguez la rédaction à un LLM. Qui dit LLM dit risque d’hallucination ou de reformulation maladroite. La passe /lint aide, mais ne remplace pas une relecture critique. (J’en ai parlé plus en détail dans mon article sur les hallucinations des LLM.)
• Ça tient grâce à la fenêtre de contexte. Le modèle élégant « tout le wiki tient dans le contexte » s’effrite quand le cerveau dépasse une certaine taille. À très grande échelle, on revient vers des stratégies de retrieval, et le RAG reprend du sens.
• La discipline reste nécessaire. Pas pour organiser, mais pour alimenter régulièrement et linter. Un cerveau qu’on ne nourrit plus reste un cerveau mort.
• Le reality check entreprise. Contrôle d’accès, conformité, fraîcheur temps réel, volumétrie massive : à ce niveau, le LLM wiki seul ne suffit pas. C’est un outil d’usage personnel et d’équipe restreinte, pas une plateforme de knowledge management d’entreprise.

Et une fois ce périmètre accepté, ce qui m’intéresse davantage que l’outil lui-même, c’est ce que ce pattern révèle sur la façon dont on travaille avec l’IA.

Ce que ça révèle sur le travail augmenté

Ce qui me frappe, c’est que ce pattern n’est pas isolé. C’est la même idée que celle que je creusais dans mon article sur les philosophies de travail avec l’IA : capitaliser sur l’accumulation.

Le compound engineering dit que chaque cycle de développement doit enrichir le suivant, via une boucle d’apprentissage documentée. Le LLM wiki de Karpathy dit exactement la même chose, mais pour la connaissance personnelle : chaque source ingérée, chaque réponse sauvegardée rend le cerveau plus dense, et donc la prochaine requête plus riche. C’est une boucle vertueuse où l’IA ne fait pas que consommer votre savoir, elle le construit.

Il y a aussi un écho à l’entropie dont je parlais ailleurs. Un système de notes laissé à lui-même dérive vers le désordre. C’est la pente naturelle. Ce qu’apporte le LLM wiki, c’est une dépense d’énergie déléguée : c’est le LLM qui lutte contre l’entropie de votre information, qui range, déduplique, relie. Vous ne payez plus le coût de l’ordre. Vous le sous-traitez.

Karpathy a peut-être raison : there is room for an incredible new product. Mais en attendant ce produit, le combo Obsidian + Claude Code permet de toucher l’idée dès maintenant, avec trois dossiers et quatre commandes.

Tutorial : créer et utiliser le cerveau

On ne crée pas ces fichiers à la main : on donne à Claude Code le texte source de Karpathy et un court prompt de délégation. L’outil qui fera tourner le cerveau en construit aussi les fondations.

Prérequis : Claude Code installé, un dossier vide.

1. Créez le dossier et ouvrez Claude Code dedans :

mkdir mon-second-cerveau && cd mon-second-cerveau
claude

2. Copiez le gist original de Karpathy

Allez sur le gist qu’il a publié en avril 2026 et copiez le contenu intégral :

👉 gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

Ce texte décrit le pattern complet : structure raw/wiki/schema, les workflows ingest/lint/query, le rôle du log et de l’index. C’est le contrat conceptuel que Claude va implémenter.

3. Collez le gist dans Claude Code, suivi de ce prompt de délégation :

Sur la base du concept décrit ci-dessus, initialise un second cerveau
dans le dossier courant.

Crée :
- raw/ (vide, pour les sources brutes)
- wiki/ avec un index.md vide
- log.md vide
- CLAUDE.md qui capture ce contrat comme règles pour l'agent
- .claude/commands/ avec les quatre commandes /ingest, /lint, /query
  et /save, dont le contenu implémente fidèlement le concept décrit

Confirme la création de chaque fichier.

Claude Code lit le concept de Karpathy, comprend la structure attendue, et crée les fichiers. Voici ce qu’il génère :

mon-second-cerveau/
├── raw/
├── wiki/
│   └── index.md
├── log.md
├── CLAUDE.md
└── .claude/commands/
    ├── ingest.md
    ├── lint.md
    ├── query.md
    └── save.md

.claude/commands/ingest.md (la compilation) :

Lis tous les fichiers présents dans le dossier `raw/` (ignore `raw/processed/`).

Pour chaque source :
1. Identifie les concepts, personnes, outils et idées clés
2. Pour chaque élément significatif : crée ou enrichis la page correspondante dans `wiki/`
3. Tisse les backlinks [[NomDePage]] entre pages liées
4. Si deux sources se contredisent, note la contradiction dans l'article concerné
5. Déplace les fichiers traités dans `raw/processed/`

Une fois toutes les sources traitées :
- Mets à jour `wiki/index.md` avec les nouvelles pages et les pages modifiées
- Ajoute une entrée dans `log.md` : date, nombre de fichiers ingérés, pages créées/modifiées

.claude/commands/lint.md (le contrôle santé) :

Passe en revue l'intégralité du dossier `wiki/` et produis un rapport structuré.

Vérifie :
1. **Contradictions** : passages qui se contredisent entre deux articles différents
2. **Pages orphelines** : articles sans aucun backlink entrant depuis une autre page
3. **Liens cassés** : backlinks [[NomDePage]] qui pointent vers une page inexistante
4. **Index périmé** : entrées dans `index.md` manquantes ou pointant vers des pages supprimées
5. **Concepts sans page** : termes récurrents dans plusieurs articles qui mériteraient leur propre page

Pour chaque problème : indique le fichier concerné, décris le problème, propose une correction.
Demande confirmation avant d'appliquer les corrections.

.claude/commands/query.md (l’interrogation) :

$ARGUMENTS

Réponds à la question ci-dessus en t'appuyant sur le contenu du dossier `wiki/`.
Cite les pages sources entre parenthèses pour chaque information.
Si la réponse n'est pas dans le wiki, dis-le clairement : ne complète pas avec tes
connaissances générales sans le signaler explicitement.

.claude/commands/save.md (la capitalisation) :

$ARGUMENTS

Transforme le contenu ci-dessus en une nouvelle page du wiki :
1. Détermine un titre court et précis
2. Écris la page au format encyclopédique (H1, résumé, sections, backlinks [[]])
3. Crée le fichier dans `wiki/` avec les backlinks vers les pages existantes pertinentes
4. Mets à jour `wiki/index.md`
5. Ajoute une entrée dans `log.md`

Le $ARGUMENTS dans query.md et save.md capture ce que vous tapez après la commande. /query pourquoi le RAG ne scale pas pour un usage perso ? injecte la question dans le prompt. La séparation /ingest / /lint est délibérée : l’un fait grossir le cerveau, l’autre le maintient en bonne santé.

4. Ouvrez wiki/ comme vault dans Obsidian.

5. Déposez un fichier dans raw/ et lancez /ingest.

Le plus dur ne sera pas technique. Ce sera de résister à l’envie de tout réorganiser à la main. C’est précisément ce que Karpathy vous demande d’arrêter de faire.

Cet article prolonge mes réflexions sur le travail augmenté par l’IA. Voir aussi ma série sur Claude Code et mon article sur l’entropie homme-machine.

Sources et lectures complémentaires

• Karpathy’s Instructions for Building an AI-Driven Second Brain — Techstrong.ai
• Karpathy shares ‘LLM Knowledge Base’ architecture that bypasses RAG — VentureBeat
• What Is Andrej Karpathy’s LLM Wiki? — MindStudio
• How I Took Karpathy’s LLM Wiki and Built an AI-Powered Second Brain in Obsidian — AI Maker
• Building a Second Brain — Tiago Forte (méthode PARA)

In early 2026, Andrej Karpathy (OpenAI co-founder, former Tesla AI director) shared a deceptively simple idea on X to solve this: what if we stopped writing the knowledge base ourselves, and handed it entirely to an LLM?

He calls it the LLM wiki, or second brain. This article breaks the concept down, explains why it buries RAG for personal use, and shows how to implement it with Obsidian and Claude Code.

Karpathy’s idea: compile, don’t summarize

The sentence that captures it all is his own:

“You rarely ever write or edit the wiki manually, it’s the domain of the LLM.”

The reversal is total. In the classic “second brain” vision (the one popularized by Tiago Forte and his PARA method), you take the notes, file them, link them. The AI only steps in at the end, to answer questions about a corpus you patiently built.

Karpathy flips the chain. You now do exactly one thing: collect raw material. Articles, research papers, reading notes, podcast transcripts, snippets of conversation: anything that crosses your path. You dump it in a folder, and tell the LLM: “compile.”

Compilation ≠ summarization

This is the central distinction, and it’s more subtle than it sounds.

A summary compresses: it throws away detail to produce a shorter version. You lose information on every pass.

A compilation, in Karpathy’s sense, restructures without impoverishing. The LLM reads each source, extracts the concepts, the people, the key ideas, then rewrites them into a consistent format: encyclopedia-style articles, linked by backlinks, deduplicated, and stripped of contradictions between sources. The detail is preserved; it’s the form that becomes coherent.

The compiler metaphor is deliberate. Just as a compiler turns heterogeneous source code into a structured, executable binary, the LLM turns a mess of sources into a navigable ontology.

What it looks like at scale

Karpathy puts a number on it: on a single research topic, his wiki reached ~100 articles and 400,000 words (longer than most PhD dissertations) without him writing a single line directly. The LLM does the writing, the linking, the categorizing, and the consistency checking. The human only feeds and queries.

His own conclusion, dropped on X: “I think there is room here for an incredible new product.”

What he doesn’t say explicitly, but what follows directly from the reasoning: if the compiled wiki is a clean, readable artifact, why would you need retrieval infrastructure to query it? That question leads straight to the uncomfortable comparison.

Why it buries RAG (for personal use)

Here’s the part that makes anyone who’s ever hacked together a document assistant raise an eyebrow. For three years, the default answer to “I want to query my documents” has been RAG (Retrieval-Augmented Generation): chunk the documents, turn them into vectors, store them in a vector database, and on every question retrieve the closest passages to inject into context.

Karpathy proposes to throw all of it out. No vector database. No embedding pipeline. No retrieval infrastructure. Just markdown files, an LLM with a large context window, and that’s it.

The argument holds up once you lay it flat:

The deep intuition: RAG does the same sorting work on every question, over raw data that’s never cleaned. The LLM wiki does that work once, at compile time, and produces a clean, condensed artifact that fits inside the context window of modern long-context models. For a personal-scale knowledge base (a few hundred articles), RAG becomes an over-engineered machine you simply no longer need.

⚠️ Important caveat: this reasoning holds for personal use. At enterprise scale (millions of documents, granular access control, real-time freshness constraints), RAG keeps all its relevance. The LLM wiki isn’t a religion; it’s the right tool for the right scale.

The concept is clear. What remains is the question that always follows: if it’s this simple, why hasn’t anyone packaged it properly? Karpathy himself runs on homemade scripts. Here’s how to replace those scripts with something more solid.

From idea to system: Obsidian + Claude Code

Karpathy’s idea is a pattern, not a product. He admits to running “hacky Python scripts” to orchestrate the LLM, plus Obsidian as a visualization layer. The good news: with Claude Code, no scripts needed. Custom slash commands handle all the orchestration from the terminal, directly inside the wiki folder.

The three-layer architecture

The whole system rests on a clean split between raw material, compiled knowledge, and the rules of the game:

my-second-brain/
├── raw/              ← you drop your raw sources here
├── wiki/             ← the LLM writes compiled articles here
│   └── index.md      ← auto-generated table of contents
├── log.md            ← operation history
├── CLAUDE.md         ← the "schema": brain organization rules
└── .claude/
    └── commands/     ← the custom slash commands
        ├── ingest.md
        ├── lint.md
        ├── query.md
        └── save.md

• The raw/ folder is your drop box. You throw everything in, no organization.
• The wiki/ folder is the LLM’s output: encyclopedia-style articles linked together, plus an index.md that summarizes the whole thing at a glance.
• The CLAUDE.md file acts as the schema. It describes how the brain should be structured: naming conventions, page format, linking rules. It’s the contract the agent follows.
• Obsidian plugs in on top of the wiki/ folder: it turns markdown backlinks into a visually navigable knowledge graph.

The four slash commands (/ingest, /lint, /query, /save) orchestrate the whole system. What they contain exactly and how to create them: that’s what the tutorial below covers.

The real rhythm: a week with this system

The genuine difference from any other note-taking tool is that you stop thinking about organization in real time. The mental effort of “where do I file this?” disappears entirely. That’s not a small thing: it’s precisely that effort that makes us abandon every note system after three weeks.

In practice, the rhythm settles naturally into two modes.

Continuously: you collect without filtering. An interesting article → copied to raw/. A conference transcript → dropped in raw/. Notes scribbled after a meeting → in raw/. The folder is a sandbox, not a library. Nothing needs to be clean to land there.

Obsidian Clipper, Obsidian’s official browser extension, takes this a step further. One click from Chrome or Firefox converts any web page into a formatted .md file and saves it directly to your raw/ folder. The article you’re reading online lands in the drop box with no copy-pasting, no reformatting.

In batches: once a week (or when raw/ starts to pile up), you run /ingest. What used to take an hour of manual filing (reading, categorizing, linking, deduplicating) happens without you. You review the output, fix what looks off, and you’re done. /lint runs alongside when the wiki has grown: it hands you a report of inconsistencies, you arbitrate in five minutes.

What changes over time: after a few months, you have a dense corpus that answers your questions using your own sources. /query doesn’t search vectors: it reasons over text that you collected, compiled into your ontology. The difference from a generic ChatGPT is real and tangible.

The whole thing is git-versionable. Your second brain becomes a repository: auditable, diffable, restorable. A far cry from the black hole that a Notion workspace becomes.

Where it actually breaks

It holds on paper. A few months of practice surface frictions the config files don’t show.

What’s genuinely strong:

• Organizing effort drops to zero. That’s the point. The historical drag on every note-taking system (filing) disappears.
• Open format, zero lock-in. Markdown, folders, git. No SaaS that shuts down with your data inside.
• Readable and auditable. Unlike a vector database, you can read your brain. You see what the LLM wrote, and fix it if needed.
• Compute cost is paid once, at compile time, not on every query.

The limits, which you have to face head-on:

• You delegate the writing to an LLM. Where there’s an LLM, there’s a risk of hallucination or clumsy rephrasing. The /lint pass helps, but it doesn’t replace a critical read. (I covered this in more depth in my article on LLM hallucinations.)
• It holds up thanks to the context window. The elegant “the whole wiki fits in context” model erodes once the brain exceeds a certain size. At very large scale, you drift back toward retrieval strategies, and RAG makes sense again.
• Discipline is still required. Not for organizing, but for feeding regularly and linting. A brain you stop feeding stays a dead brain.
• The enterprise reality check. Access control, compliance, real-time freshness, massive volume: at that level, the LLM wiki alone isn’t enough. It’s a tool for personal and small-team use, not an enterprise knowledge management platform.

Once that scope is accepted, what interests me more than the tool itself is what this pattern reveals about how we work with AI.

What this reveals about augmented work

What strikes me is that this pattern isn’t isolated. It’s the same idea I was digging into in my article on AI work philosophies: capitalizing on accumulation.

Compound engineering says each development cycle should enrich the next, through a documented learning loop. Karpathy’s LLM wiki says exactly the same thing, but for personal knowledge: every ingested source, every saved answer makes the brain denser, and therefore the next query richer. It’s a virtuous loop where the AI doesn’t just consume your knowledge, it builds it.

There’s also an echo of the entropy I wrote about elsewhere. A note-taking system left to itself drifts toward disorder. That’s the natural slope. What the LLM wiki brings is a delegated expenditure of energy: it’s the LLM that fights the entropy of your information, that files, deduplicates, links. You no longer pay the cost of order. You outsource it.

Karpathy may be right: there is room for an incredible new product. But until that product arrives, the Obsidian + Claude Code combo lets you touch the idea right now, with three folders and four commands.

Tutorial: build and use the brain

You don’t create these files by hand: you give Claude Code Karpathy’s source text and a short delegation prompt. The tool that will run the brain also builds its foundations.

Prerequisites: Claude Code installed, an empty folder.

1. Create the folder and open Claude Code inside it:

mkdir my-second-brain && cd my-second-brain
claude

2. Copy Karpathy’s original gist

Go to the gist he published in April 2026 and copy the full content:

👉 gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

This text describes the full pattern: raw/wiki/schema structure, ingest/lint/query workflows, the role of the log and the index. It’s the conceptual contract that Claude will implement.

3. Paste the gist into Claude Code, followed by this delegation prompt:

Based on the concept described above, initialize a second brain
in the current folder.

Create:
- raw/ (empty, for raw sources)
- wiki/ with an empty index.md
- empty log.md
- CLAUDE.md that captures this contract as rules for the agent
- .claude/commands/ with the four commands /ingest, /lint, /query
  and /save, whose content faithfully implements the concept described

Confirm the creation of each file.

Claude Code reads Karpathy’s concept, understands the expected structure, and creates the files. Here’s what it generates:

my-second-brain/
├── raw/
├── wiki/
│   └── index.md
├── log.md
├── CLAUDE.md
└── .claude/commands/
    ├── ingest.md
    ├── lint.md
    ├── query.md
    └── save.md

.claude/commands/ingest.md (compilation):

Read all files in the `raw/` folder (ignore `raw/processed/`).

For each source:
1. Identify the key concepts, people, tools and ideas
2. For each significant element: create or enrich the corresponding page in `wiki/`
3. Weave [[PageName]] backlinks between related pages
4. If two sources contradict each other, note the contradiction in the relevant article
5. Move processed files to `raw/processed/`

Once all sources are processed:
- Update `wiki/index.md` with new and modified pages
- Add an entry to `log.md`: date, number of files ingested, pages created/modified

.claude/commands/lint.md (health check):

Review the entire `wiki/` folder and produce a structured report.

Check for:
1. **Contradictions**: passages that conflict between two different articles
2. **Orphan pages**: articles with no incoming backlinks from any other page
3. **Broken links**: [[PageName]] backlinks pointing to a non-existent page
4. **Stale index**: entries in `index.md` that are missing or point to deleted pages
5. **Concepts without pages**: recurring terms across multiple articles that deserve their own page

For each problem: indicate the file, describe the issue, propose a fix.
Ask for confirmation before applying any corrections.

.claude/commands/query.md (querying):

$ARGUMENTS

Answer the question above using the content of the `wiki/` folder.
Cite source pages in parentheses for each piece of information.
If the answer is not in the wiki, say so clearly: do not fill in from your general
knowledge without explicitly flagging it.

.claude/commands/save.md (capitalizing):

$ARGUMENTS

Turn the content above into a new wiki page:
1. Determine a short, precise title
2. Write the page in encyclopedic format (H1, summary, sections, [[]] backlinks)
3. Create the file in `wiki/` with backlinks to relevant existing pages
4. Update `wiki/index.md`
5. Add an entry to `log.md`

The $ARGUMENTS in query.md and save.md captures what you type after the command. /query why doesn't RAG scale for personal use? injects the question into the prompt. The /ingest / /lint split is deliberate: one grows the brain, the other keeps it healthy.

4. Open wiki/ as a vault in Obsidian.

5. Drop a file into raw/ and run /ingest.

The hard part won’t be technical. It’ll be resisting the urge to reorganize everything by hand. That’s precisely what Karpathy is asking you to stop doing.

This article extends my reflections on AI-augmented work. See also my Claude Code series and my article on human–machine entropy.

Sources and further reading

• Karpathy’s Instructions for Building an AI-Driven Second Brain — Techstrong.ai
• Karpathy shares ‘LLM Knowledge Base’ architecture that bypasses RAG — VentureBeat
• What Is Andrej Karpathy’s LLM Wiki? — MindStudio
• How I Took Karpathy’s LLM Wiki and Built an AI-Powered Second Brain in Obsidian — AI Maker
• Building a Second Brain — Tiago Forte (PARA method)

The hearing runs for over ninety minutes. Mensch lays out a built thesis: AI is infrastructure technology, and Europe has a few months to decide whether it produces or merely consumes. As in any such exercise, what he says, what he doesn’t say, and what he omits deserve to be read separately. That’s what I’m doing here, by cross-checking his positions against publicly available sources (Mistral’s April 2026 white paper, LCP coverage, Bloomberg on the Mythos counter-move).

AI as raw material: electrons become tokens

Mensch’s first structuring idea is the way he redefines what AI is. Not a software product, not a web service: an energy-transformation technology. You feed electrons in one end, tokens come out the other. The token being the unit of a model’s linguistic output, that is, in his vocabulary, the unit of machine intelligence.

This shift is more than a rhetorical effect. It places AI alongside heavy industry, with its physical externalities (electricity, cooling, land for data centers) and its massive capex cycle. And it serves a central argument: France, thanks to its nuclear capacity, holds a geographic advantage. Decarbonized electricity, relatively cheap at scale, is precisely what’s needed to train and run models.

Where Mensch issues a useful warning is on the narrow window of opportunity. American cloud operators are signing long-term contracts with EDF and European utilities. If France doesn’t channel its electricity toward its own players, those electrons will leave for the United States in token form. The question one could have asked, and that no MP really did: how much electricity does Mistral consume today, and what’s the trajectory? The debate stays very macro at this stage.

A nuance Mensch could have brought himself: France’s decarbonized electricity is also an asset for traditional industry, which will need it. Prioritizing it for AI may be strategically defensible, but it’s not neutral.

The “trillion euros”: a memorable figure, a fragile extrapolation

The headline number. Mensch explains that AI consumption at Mistral already accounts for 10% of payroll. Extrapolated to the European scale over three to four years, you reach a trillion euros annually. If Europe imports that AI, it adds straight to the trade deficit.

The image works. It made the rounds in the press, LCP included, and that was probably the point. But it doesn’t hold up under scrutiny.

First issue: extrapolating the AI consumption of a company like Mistral, whose core business is producing AI, to the whole European economy. It’s like estimating a country’s steel consumption from a single steelworks. The cost structure of an AI company is not that of an industrial SME, a city hall, or a law firm.

Second issue: the implicit assumption that all value added by AI flows through payment to an external service. A significant share of AI-generated value is captured locally (productivity, margins, new products). What actually leaves the territory is the inference and training spend with foreign providers, not the equivalent of 10% of payroll.

Third issue: the figure assumes a linear growth trajectory that no technology cycle has ever followed. Inference costs per token have been falling by roughly an order of magnitude per year since 2023.

None of this means the risk is imaginary. It’s real, and the digital commercial asymmetry between Europe and the United States has been documented for years. But by inflating the number, Mensch hands critics an easy target and weakens an argument that didn’t need the boost.

Sovereignty as “leverage”, not retreat

This is the most interesting framing from Mistral’s CEO. Digital sovereignty isn’t an autarky project: it’s negotiating leverage. If Europe has no sovereign production capacity in AI, it has nothing to put on the table against the United States. No credible arbitration threat, no standard to impose, no knife in the pocket.

Framing the debate this way avoids the classic pitfall of technological nationalism. Mensch isn’t calling to close borders. He’s calling for at least one credible European player to exist in every critical layer of the AI stack. It’s the same line Mistral pushed in April 2026 in its white paper “European AI: a playbook to own it”, whose 22 measures put the European preference clause in public procurement at the center.

There’s also a cultural dimension he raises more quietly. Importing an AI model is importing its biases. Models encode representational choices, linguistic biases and political assumptions. An LLM massively trained on Anglo-Saxon content produces Anglo-Saxon analyses by default. The French Phare benchmark (Giskard × Google DeepMind) documented that major LLMs are less robust in French than in English. The asymmetry is measurable.

Where I find the reasoning more debatable is the implicit conclusion: for sovereignty to exist, Mistral must exist. Is sovereignty really sovereignty if it boils down to one national champion? What European plurality is left when a single actor writes the recommendations it will then benefit from?

AI Act: substantive critique or vested interest?

Mensch criticizes the stacking of rules head-on: GDPR, copyright legislation, AI Act. His thesis is that this stack paradoxically slows down European players and favors American giants, the only ones capable of absorbing compliance costs.

That’s the standard startup argument. It has some truth to it. A 500,000-euro compliance cost is a rounding error for OpenAI or Google ; for a European scale-up, it’s a quarter of runway. And the AI Act has been the target of intense lobbying, notably by Mistral, to raise the thresholds that trigger the “systemic risk model” classification.

But there’s a blind spot. The protection European regulators are trying to deliver isn’t bureaucratic fussiness: it responds to real cases (algorithmic discrimination, deepfakes, political manipulation, personal data leaks). When Mensch complains about “the accumulation of regulations”, he’s also complaining, in the same breath, about transparency obligations on training data. And those obligations aren’t trivial when you train on copyrighted content without a license.

The right debate isn’t regulation versus deregulation. It’s: which regulation, at what threshold, with what proportionality. Mensch is right that 27 different national rulebooks destroy European scale. He’s wrong to present each obligation as a brake on innovation: some of them are the condition for innovation to be acceptable.

Defense: coherent, and uncomfortable

The hearing took place a few days before Bloomberg reported that Mistral is developing a cybersecurity model for European banks cut off from Mythos, Anthropic’s access-restricted tool. During the hearing, Mensch said: “We can’t let Mythos scan the source code of the French armed forces. That creates an irreparable dependency, we need to find a solution.”

This is the strongest passage of the hearing, and also the most uncomfortable. Strong because it rests on a concrete, recent case: a foreign tool, under foreign control, more effective than its alternatives, can unilaterally redefine access to a critical capability. That’s precisely what Palo Alto Networks documents, with frontier AI discovering vulnerabilities seven times faster, and three to five months of defensive buffer left before the trend reverses.

Uncomfortable because Mensch explicitly refuses any right of oversight on the final use of his technology by the French army. “The army is sovereign, it has democratic legitimacy that we don’t have.” Constitutionally that holds, but it brushes aside a debate that never really took place: what does a “sovereign AI” used for military purposes mean when the engineers who built it have no say? The subject deserves more than a deferral to electoral legitimacy.

Business model: AI is expensive, and that’s good

Mistral charges around €1 per million tokens generated on its entry-level models. Industry gross margins sit around 50%. Mensch owns it: that’s what funds the massive training costs, in the hundreds of millions per frontier model cycle.

Mistral’s revenue is 70% non-French. That’s consistent with its strategy as a European exporting champion. It also implicitly answers the “subsidized small player” critique: Mistral sells internationally, so its customers validate the value proposition. American capital is present (under 30%), but the founders keep strategic control and aim for a European listing.

Macroeconomically, this is exactly the kind of company Europe needs more of. Politically, it’s also a player whose 11.7-billion-euro valuation and trajectory depend on very concrete public decisions: infrastructure choices, electricity allocation, public procurement. Mensch’s position is sincere without being disinterested. Anyone who walks into a parliamentary hearing brings an agenda. It must be heard as such.

Public procurement: the most interesting recommendation, and the hardest to apply

For Mensch, public procurement is the lever. 50% of European GDP flows through public spending. If a meaningful share of that spending preferred European AI and cloud suppliers, the internal market would structure itself mechanically. That’s the recipe the United States has applied since the 1940s (DARPA, NIH, NASA, Pentagon contracts) to grow its tech ecosystem.

Technically it’s the right idea. Politically, it runs into European non-discrimination rules in public procurement and WTO agreements. Mistral pushes for “European preference clauses on critical public markets”, notably AI and cloud. Legally feasible on national security; far more contested elsewhere.

And there’s a method issue. American public procurement in tech wasn’t built on declared preference, but on technical specifications that de facto disqualified players unable to meet them (clearance, certifications, integration). If Europe wants to produce the same effect, it has to build demanding technical specs on data sovereignty, auditability, hosting. Not a flag, verifiable requirements. That lever sits entirely in the hands of member states, without changing a word of European law. And it’s barely used.

What the hearing reveals, and what it leaves out

Arthur Mensch’s hearing has two main merits.

It puts before national representatives questions the French political class wasn’t used to framing this way: AI as industrial infrastructure, electricity as strategic raw material, European fragmentation as a structural barrier to scale.

It also forces an honest look at digital dependency. France and Europe never built a top-tier cloud player. They risk missing the same train on AI, with heavier consequences, because this time the stakes aren’t merely industrial: they’re cultural, military, democratic.

What the hearing leaves out is equally telling.

The role of open-weight models as European public infrastructure. Mensch prefers talking about Mistral rather than about the open-weights ecosystem he was long a part of. Yet if we want plural sovereignty rather than a national monopoly, that’s the path.

The debate on the environmental footprint of the frontier-model race. French decarbonization is presented as an asset, but the ten-year energy trajectory of AI isn’t neutral, and prioritizing electricity for data centers deserves a public debate, not an assumption.

The question of bias and European linguistic diversity. Europe doesn’t speak French, it speaks 24 official languages. Defending sovereignty can’t be reduced to swapping American dependency for French-speaking dependency.

And then, more prosaically, the clarity on uses: if AI is going to replace 10% of payroll, that’s not a statistic. Those are jobs, employment basins, individual trajectories. The “vassal state” Mensch invokes in conclusion is a useful figure for raising alarm. The state that fails to support its own workers through the transition is a more immediate figure, and far less discussed in the hearing.

Further reading

• Full hearing: official National Assembly video, May 12, 2026.
• Mistral AI white paper: European AI: a playbook to own it, April 2026, with the 22 detailed measures.
• LCP coverage: “The Mistral AI CEO does not rule out a rise in unemployment”, May 12, 2026.
• Bloomberg: “Mistral Developing New AI Model for Banks Lacking Mythos Access”, May 13, 2026.
• My notes on LLM hallucinations: Understanding, measuring and controlling LLM hallucinations, useful background on why linguistic robustness in French is itself a sovereignty issue.

Arthur Mensch (Mistral AI) hearing — French National Assembly inquiry commission on structural dependencies and systemic vulnerabilities in the digital sector, May 12, 2026.

L’audition dure plus d’une heure et demie. Mensch déroule une thèse construite : l’IA est une technologie d’infrastructure, l’Europe a quelques mois pour décider si elle en est productrice ou simple consommatrice. Comme dans tout exercice de ce type, ce qu’il dit, ce qu’il ne dit pas et ce qu’il omet méritent d’être lus séparément. C’est ce que je propose ici, en croisant ses positions avec les sources publiques disponibles (livre blanc Mistral d’avril 2026, couverture LCP, Bloomberg sur la riposte à Mythos).

L’IA comme matière première : les électrons deviennent des tokens

La première idée structurante de Mensch, c’est sa manière de redéfinir ce qu’est l’IA. Pas un produit logiciel, pas un service web : une technologie de transformation énergétique. On entre des électrons d’un côté, on sort des tokens de l’autre. Le token étant l’unité de mesure de la production linguistique d’un modèle, c’est-à-dire, dans son vocabulaire, l’unité d’intelligence machine.

Le glissement est plus qu’un effet rhétorique. Il rapproche l’IA d’une industrie lourde, avec ses externalités physiques (consommation électrique, refroidissement, foncier des datacenters) et son cycle économique de capex massif. Et il sert un argument central : la France, par son nucléaire, a un atout géographique. Une électricité décarbonée et relativement bon marché à grande échelle est exactement ce qu’il faut pour entraîner et faire tourner des modèles.

Là où Mensch fait passer un avertissement utile, c’est sur la fenêtre de tir étroite. Les opérateurs américains de cloud annoncent des contrats long terme avec EDF et avec les énergéticiens européens. Si la France ne fléche pas son électricité vers ses propres acteurs, les électrons partiront aux États-Unis sous forme de tokens. La question qu’on aurait pu lui poser, et qu’aucun député n’a vraiment posée : quelle quantité d’électricité Mistral consomme aujourd’hui, et quelle est sa trajectoire ? Le débat reste à ce stade très macro.

Une nuance qu’il aurait pu apporter lui-même : l’électricité décarbonée française est aussi un atout pour l’industrie classique, qui en aura besoin. L’allocation prioritaire à l’IA, si elle peut se défendre stratégiquement, n’est pas neutre.

Le « trillion d’euros » : un chiffre qui marque, une extrapolation qui fragilise

Le chiffre qui a fait les titres. Mensch explique que la consommation d’IA chez Mistral représente déjà 10 % de la masse salariale. Si on extrapole à l’échelle européenne d’ici trois à quatre ans, on parle d’un trillion d’euros annuel. Si l’Europe importe cette IA, c’est autant qui s’ajoute au déficit commercial.

L’image est efficace. Elle a tourné dans toute la presse, LCP comprise, et c’était sans doute le but. Mais elle ne tient pas à un examen rigoureux.

Premier problème : extrapoler la consommation d’une entreprise comme Mistral AI, dont le cœur de métier est de produire de l’IA, à l’ensemble de l’économie européenne. C’est comme estimer la consommation d’acier d’un pays à partir d’une aciérie. La structure de coût d’une boîte d’IA n’est pas celle d’une PME industrielle, d’une mairie ou d’un cabinet d’avocats.

Deuxième problème : l’hypothèse implicite que toute la valeur ajoutée par l’IA passe par le paiement d’un service externe. Une partie significative de la valeur générée par l’IA reste capturée localement (productivité, marges, nouveaux produits). Ce qui sort réellement du territoire, c’est la dépense d’inférence et d’entraînement chez les fournisseurs étrangers, pas l’équivalent de 10 % d’une masse salariale.

Troisième problème : le chiffre suppose une trajectoire linéaire de croissance qu’aucun cycle technologique n’a jamais suivi. Les coûts d’inférence par token chutent d’environ un ordre de grandeur par an depuis 2023.

Tout cela ne veut pas dire que le risque est imaginaire. Il est réel, et l’asymétrie commerciale numérique entre l’Europe et les États-Unis est documentée depuis des années. Mais en gonflant le chiffre, Mensch s’expose à une critique facile et fragilise un argument qui n’en avait pas besoin.

La souveraineté comme « levier », pas comme repli

C’est la formulation la plus intéressante du PDG de Mistral. La souveraineté numérique n’est pas un projet d’autarcie : c’est un levier de négociation. Si l’Europe n’a aucune capacité de production souveraine en IA, elle n’a rien à mettre dans la balance face aux États-Unis. Pas de menace crédible d’arbitrage, pas de standard à imposer, pas de couteau dans la poche.

Cette manière de poser le débat évite le piège classique du nationalisme technologique. Mensch ne réclame pas la fermeture des frontières. Il réclame qu’il existe au moins un acteur européen crédible dans chaque couche critique de la pile IA. C’est la même ligne que Mistral a poussée en avril 2026 dans son livre blanc « European AI: a playbook to own it », avec ses 22 mesures dont la clause de préférence européenne dans la commande publique est probablement la plus structurante.

Il y a aussi une dimension culturelle qu’il aborde plus discrètement. Importer un modèle d’IA, c’est importer ses biais. Les modèles encodent des choix de représentation, des biais linguistiques et des présupposés politiques. Un LLM massivement entraîné sur du contenu anglo-saxon produit par défaut des analyses anglo-saxonnes. Le benchmark français Phare (Giskard × Google DeepMind) a documenté que les principaux LLMs sont moins robustes en français qu’en anglais. L’asymétrie est mesurable.

Là où je trouve le raisonnement plus discutable, c’est sur la conclusion implicite : pour qu’il y ait souveraineté, il faut qu’il y ait Mistral. La souveraineté est-elle souveraineté si elle se résume à un seul champion national ? Quel pluralisme européen quand un acteur écrit les recommandations qu’il appliquera ?

L’AI Act : critique fondée ou intérêt bien compris ?

Mensch critique frontalement l’accumulation des règles : RGPD, législation sur le droit d’auteur, AI Act. Sa thèse est que cet empilement freine paradoxalement les acteurs européens et favorise les géants américains, seuls capables d’absorber les coûts de conformité.

C’est l’argument classique des startups. Il a une part de vérité. Une exigence de conformité de 500 000 euros représente une fraction négligeable du chiffre d’affaires d’OpenAI ou de Google ; pour une scale-up européenne, c’est un trimestre de runway. Et il est documenté que les obligations de l’AI Act ont fait l’objet d’un lobbying intense, notamment de la part de Mistral, pour relever les seuils déclenchant la catégorisation « modèle à risque systémique ».

Mais il y a un angle mort. La protection que cherchent à apporter les régulateurs européens n’est pas un caprice bureaucratique : elle répond à des cas réels (discrimination algorithmique, deepfakes, manipulation politique, fuite de données personnelles). Quand Mensch dénonce « l’accumulation de réglementations », il dénonce aussi, dans le même mouvement, les obligations de transparence sur les données d’entraînement. Et celles-là ne sont pas anodines quand on entraîne sur du contenu protégé sans licence.

Le bon débat n’est pas régulation contre dérégulation. Il est : quelle régulation, à quel seuil, avec quelle proportionnalité. Mensch a raison de dire que 27 réglementations nationales différentes tuent l’échelle européenne. Il a tort de présenter chaque obligation comme une entrave à l’innovation : certaines sont la condition pour que l’innovation soit acceptable.

La défense : cohérent, et pourtant inconfortable

L’audition s’est tenue quelques jours avant que Bloomberg ne révèle que Mistral développe un modèle de cybersécurité pour les banques européennes coupées de Mythos, l’outil d’Anthropic à accès restreint. Pendant l’audition, Mensch déclare : « On ne peut pas laisser Mythos scanner le code source des armées françaises. Cela crée une dépendance irréparable, on doit trouver une solution. »

C’est le passage le plus solide de l’audition, et aussi le plus inconfortable. Solide parce qu’il s’appuie sur un cas concret et récent : un outil étranger, sous contrôle d’un acteur étranger, plus efficace que ses équivalents, peut redéfinir unilatéralement l’accès à une capacité critique. C’est précisément ce que Palo Alto Networks documente, avec un facteur 7 de découverte de vulnérabilités par les IA frontalières, et trois à cinq mois de marge défensive avant inversion.

Inconfortable parce que Mensch refuse explicitement un droit de regard sur l’usage final de sa technologie par l’armée française. « L’armée est souveraine, elle a une légitimité démocratique que nous n’avons pas. » La phrase a une logique constitutionnelle, mais elle évacue d’un revers de manche un débat qui n’a jamais eu lieu : qu’est-ce qu’une « IA souveraine » utilisée pour des cas d’usage militaires sans que les ingénieurs qui l’ont construite aient leur mot à dire ? Le sujet mérite mieux qu’un renvoi à la légitimité élective.

Modèle économique : l’IA, c’est cher, et c’est tant mieux

Mistral facture environ 1 € pour un million de tokens générés sur ses modèles d’entrée de gamme. La marge brute du secteur est d’environ 50 %. Mensch le revendique : c’est nécessaire pour financer les coûts massifs d’entraînement, qui se comptent en centaines de millions par cycle de modèle frontalier.

Le chiffre d’affaires de Mistral est réalisé à 70 % hors de France. C’est cohérent avec sa stratégie de champion européen exportateur. Et c’est aussi une réponse implicite à la critique du « petit acteur subventionné » : Mistral vend à l’international, donc ses clients valident une proposition de valeur. Le capital américain est présent (moins de 30 %), mais les fondateurs gardent le contrôle stratégique et visent une cotation européenne.

Sur le plan macroéconomique, c’est exactement le profil d’entreprise que l’Europe doit avoir le plus possible. Sur le plan politique, c’est aussi un acteur dont la valorisation à 11,7 milliards et la trajectoire dépendent de décisions publiques très concrètes : choix d’infrastructure, fléchage électrique, commande publique. La position de Mensch est sincère sans être désintéressée. Tout interlocuteur des pouvoirs publics arrive avec son agenda. Il faut l’entendre comme tel.

La commande publique : la recommandation la plus intéressante, et la plus difficile à appliquer

Pour Mensch, la commande publique est le levier. 50 % du PIB européen passe par la dépense publique. Si une fraction significative de cette dépense privilégiait des fournisseurs européens d’IA et de cloud, le marché interne se structurerait mécaniquement. C’est la recette qu’ont appliquée les États-Unis depuis les années 1940 (DARPA, NIH, NASA, contrats du Pentagone) pour faire grossir leur écosystème tech.

C’est techniquement la bonne idée. Politiquement, elle se heurte aux règles européennes de non-discrimination dans la commande publique et aux accords OMC. Mistral pousse pour des « clauses de préférence européenne sur les marchés publics critiques », notamment l’IA et le cloud. Ce serait juridiquement faisable sur la sécurité nationale ; nettement plus contesté ailleurs.

Et il y a une question de méthode. La commande publique américaine en tech ne s’est pas faite par préférence affichée, mais par cahiers des charges techniques qui éliminaient de facto les acteurs incapables de répondre (clearance, certifications, intégration). Si l’Europe veut produire le même effet, elle doit construire des spécifications techniques exigeantes sur la souveraineté de la donnée, l’auditabilité, l’hébergement. Pas un drapeau, des exigences vérifiables. Ce levier-là est entièrement aux mains des États membres, sans changer un mot de droit européen. Et il est très peu utilisé.

Ce que l’audition révèle, et ce qu’elle laisse de côté

L’audition d’Arthur Mensch a deux mérites principaux.

Elle pose, à la représentation nationale, des questions que la classe politique française n’avait pas l’habitude de formuler en ces termes : l’IA comme infrastructure industrielle, l’électricité comme matière première stratégique, la fragmentation européenne comme obstacle structurel à l’échelle.

Elle force aussi un examen lucide de la dépendance numérique. La France et l’Europe ne se sont jamais dotées d’un acteur cloud de premier plan. Elles risquent de manquer le même train sur l’IA, avec des conséquences plus lourdes, parce que cette fois l’enjeu n’est plus seulement industriel : il est culturel, militaire, démocratique.

Ce que l’audition laisse de côté est tout aussi parlant.

Le rôle des modèles ouverts comme infrastructure publique européenne. Mensch préfère parler de Mistral plutôt que de l’écosystème open weights dont il a longtemps été un acteur. Or si on veut une souveraineté plurielle plutôt qu’un monopole national, c’est par là que ça passe.

Le débat sur l’empreinte environnementale de la course aux modèles frontaliers. La décarbonation française est mise en avant comme atout, mais la trajectoire d’usage énergétique de l’IA à dix ans n’est pas neutre, et la priorisation de l’électricité au profit des datacenters mérite un débat public, pas un présupposé.

La question des biais et de la diversité linguistique européenne. L’Europe ne parle pas français, elle parle 24 langues officielles. La défense de la souveraineté ne peut pas se réduire à substituer une dépendance américaine par une dépendance francophone.

Et puis, plus prosaïquement, la lucidité sur les usages : si l’IA va remplacer 10 % de la masse salariale, ce n’est pas une statistique. Ce sont des métiers, des bassins d’emploi, des trajectoires individuelles. L’État vassal qu’évoque Mensch en conclusion est une figure utile pour faire peur. L’État qui n’accompagne pas ses propres salariés dans la transition est une figure plus immédiate, et beaucoup moins évoquée dans l’audition.

Pour aller plus loin

• L’audition complète : vidéo officielle de l’Assemblée nationale, 12 mai 2026.
• Livre blanc Mistral AI : European AI: a playbook to own it, avril 2026, qui détaille les 22 mesures.
• Couverture LCP : « Le patron de Mistral AI n’exclut pas une hausse du chômage », 12 mai 2026.
• Bloomberg : « Mistral Developing New AI Model for Banks Lacking Mythos Access », 13 mai 2026.
• Mes notes sur les hallucinations des LLMs : Comprendre, mesurer et maîtriser les hallucinations, utile pour comprendre pourquoi la robustesse linguistique en français est un vrai enjeu de souveraineté.

Audition d’Arthur Mensch (Mistral AI) — Commission d’enquête de l’Assemblée nationale sur les dépendances structurelles et les vulnérabilités systémiques dans le secteur du numérique, 12 mai 2026.

J’ai donc republié une version avril 2026 — la même architecture visuelle que la version mars, réécrite pour coller à chaque ajout récent, avec la palette du blog (fond sombre, accent doré) plutôt que le thème Reddit d’origine.

La cheat sheet

• Français — HTML interactif
• English — Interactive HTML

La version de mars reste accessible pour référence : FR · EN.

Les éléments marqués d’un badge doré NEW sont des features ajoutées depuis fin mars 2026. Les éléments barrés REMOVED sont des commandes retirées.

Ce qui est couvert

14 sections au lieu de 13 dans la version mars (la nouvelle row regroupe Auto Mode, Models & Effort et Platforms) :

Ajouts et changements depuis mars 2026

Claude Opus 4.7 (16 avril)

1M de contexte natif, 64K à 128K de tokens en sortie, et surtout un adaptive thinking : plus de budget_tokens manuel, le modèle décide lui-même quand réfléchir plus longtemps. Visible par des indicateurs inline (“still thinking”, “thinking more”). Par défaut, l’effort passe à un nouveau niveau xhigh (100K tokens, MRCR v2 à 71%), positionné entre high et max.

Auto Mode en GA pour Max

Le mode Auto (classifier de permissions) est sorti de research preview pour les abonnés Max avec Opus 4.7. Le classifier a deux chemins : un fast path sur Haiku qui classe chaque appel d’outil en safe/risky/uncertain, et un thinking path sur Opus/Sonnet qui reprend les cas ambigus. Le nouvel hook PermissionDenied permet de réagir à un refus (par exemple demander une autorisation explicite via un script) et peut renvoyer {"retry": true} pour relancer l’outil.

Computer Use dans le CLI

Computer Use était cantonné à la Desktop app dans la version mars. Depuis v2.1.86 il est disponible dans le CLI sur macOS et Windows Desktop (Linux non supporté), avec multi-monitor. Les 27 outils (screenshot, clicks, typing, computer_batch, etc.) restent identiques. Toujours en research preview, Pro/Max uniquement.

Monitor tool (v2.1.98)

Un outil built-in qui spawn des watchers en arrière-plan : tail de logs, suivi CI, auto-fix de crashes. Chaque ligne stdout devient une notification dans la conversation. Fin des while sleep; do ... done dans Bash. Se combine avec /loop en mode self-pacing (omettre l’intervalle, Claude choisit le tick ou utilise Monitor).

7 nouvelles commandes slash, 2 supprimées

Ajoutées : /ultraplan (draft dans le cloud, revue dans le navigateur, exécution locale), /autofix-pr (réparer une PR depuis le terminal ou le web), /team-onboarding (guide ramp-up pour un co-équipier à partir de votre usage), /powerup (leçons animées pour apprendre les features), /tui (rendu fullscreen sans flicker), /focus (vue condensée), /effort (slider interactif avec ↑↓).

Supprimées : /vim (remplacée par /config → Editor mode) et /tag (remplacée par des titres de sessions AI-generated).

5 événements hooks supplémentaires

Le total passe de 25 à 26 événements listés, plus plusieurs améliorations : PermissionDenied pour réagir aux refus Auto Mode, PostUserPromptSubmit qui peut override le sessionTitle, PostToolUse reçoit maintenant duration_ms dans son input, PreCompact peut bloquer une compaction (exit 2), le champ if accepte mcp__server__tool et un nouveau type de handler mcp_tool appelle directement un outil MCP.

Une vingtaine de nouvelles variables d’environnement

Entre autres : CLAUDE_CODE_NO_FLICKER (rendu alt-screen activé par défaut v2.1.89), CLAUDE_CODE_HIDE_CWD, CLAUDE_CODE_USE_MANTLE (Bedrock via Mantle), CLAUDE_CODE_CERT_STORE, CLAUDE_CODE_SUBPROCESS_ENV_SCRUB (isolation PID namespace Linux), CLAUDE_CODE_SCRIPT_CAPS, CLAUDE_CODE_PERFORCE_MODE, ENABLE_PROMPT_CACHING_1H, FORCE_PROMPT_CACHING_5M, ENABLE_TOOL_SEARCH, OTEL_LOG_TOOL_DETAILS, DISABLE_UPDATES. Sept nouveaux champs de settings.json également : prUrlTemplate, sandbox.failIfUnavailable, disableSkillShellExecution, showThinkingSummaries (off en interactif depuis v2.1.86), statusLine.refreshInterval.

Desktop app refondue (14 avril)

Multi-session sidebar, drag-and-drop pane layout, terminal intégré, file editor avec preview HTML/PDF, diff viewer refait. /desktop transfère une session du CLI vers l’app. Computer Use fonctionne aussi depuis la Desktop app sur macOS et Windows.

Claude Code sur le web

claude.ai/code en research preview pour les abonnés Pro et Max : infrastructure cloud, sessions persistantes depuis mobile, possibilité de reprendre en local avec /teleport.

Defaults qui ont basculé

• Rendu flicker-free (alt-screen) on par défaut (v2.1.89)
• OS CA certificate store trusté par défaut (v2.1.101), plus besoin de configurer un proxy TLS d’entreprise
• Thinking summaries off par défaut en interactif (v2.1.86)
• Effort par défaut : high sur API-key / Bedrock / Vertex / Team / Enterprise, xhigh pour les utilisateurs Opus 4.7

Sources officielles : Claude Code Changelog, What’s New (semaines W13, W14, W15), Opus 4.7 notes, Computer Use, Auto Mode.

Si vous repérez une erreur ou une feature manquante, dites-le moi, je garderai cette cheatsheet à jour au fil des évolutions.

So I republished an April 2026 edition — same visual architecture as the March version, rewritten to match every recent addition, and using the blog palette (dark background, gold accent) instead of the original Reddit theme.

The cheat sheet

• English — Interactive HTML
• French — Interactive HTML

The March version stays available for reference: EN · FR.

Items with a gold NEW badge shipped since late March 2026. Items tagged REMOVED are commands that were retired.

What’s covered

14 sections instead of 13 in the March version (the new row groups Auto Mode, Models & Effort, and Platforms):

Additions and changes since March 2026

Claude Opus 4.7 (April 16)

Native 1M context, 64K to 128K output tokens, and above all adaptive thinking: no more manual budget_tokens, the model itself decides when to think longer. Visible through inline indicators (“still thinking”, “thinking more”). Default effort shifts to a new xhigh level (100K tokens, 71% on MRCR v2), positioned between high and max.

Auto Mode GA for Max subscribers

The Auto mode (permission classifier) left research preview for Max subscribers with Opus 4.7. The classifier runs two paths: a fast path on Haiku that tags each tool call as safe/risky/uncertain, and a thinking path on Opus/Sonnet that handles ambiguous cases. The new PermissionDenied hook fires on denials (useful to request an explicit grant via a script) and can return {"retry": true} to rerun the tool.

Computer Use in the CLI

Computer Use was Desktop-app-only in the March release. Since v2.1.86 it is available in the CLI on macOS and Windows Desktop (Linux not supported), with multi-monitor support. The 27 tools (screenshot, clicks, typing, computer_batch, etc.) are unchanged. Still a research preview, Pro/Max only.

Monitor tool (v2.1.98)

A built-in tool that spawns background watchers: tail logs, watch CI, auto-fix crashes. Each stdout line becomes a notification in the conversation. Replaces while sleep; do ... done Bash loops. Pairs with /loop in self-pacing mode (omit the interval; Claude picks the next tick or uses Monitor).

7 new slash commands, 2 removed

Added: /ultraplan (draft in the cloud, review in the browser, execute locally), /autofix-pr (fix a PR from the terminal or web), /team-onboarding (generate a teammate ramp-up guide from your usage), /powerup (animated lessons to learn features), /tui (flicker-free fullscreen rendering), /focus (condensed view), /effort (interactive slider with ↑↓).

Removed: /vim (use /config → Editor mode) and /tag (replaced by AI-generated session titles).

Hook system updates

The listed total moves from 25 to 26 events, plus several refinements: PermissionDenied for Auto Mode refusals, PostUserPromptSubmit that can override sessionTitle, PostToolUse now receives duration_ms in its input, PreCompact can block compaction (exit 2), the if field accepts mcp__server__tool, and a new handler type mcp_tool calls an MCP tool directly.

Roughly twenty new environment variables

Among others: CLAUDE_CODE_NO_FLICKER (alt-screen rendering on by default since v2.1.89), CLAUDE_CODE_HIDE_CWD, CLAUDE_CODE_USE_MANTLE (Bedrock via Mantle), CLAUDE_CODE_CERT_STORE, CLAUDE_CODE_SUBPROCESS_ENV_SCRUB (Linux PID namespace isolation), CLAUDE_CODE_SCRIPT_CAPS, CLAUDE_CODE_PERFORCE_MODE, ENABLE_PROMPT_CACHING_1H, FORCE_PROMPT_CACHING_5M, ENABLE_TOOL_SEARCH, OTEL_LOG_TOOL_DETAILS, DISABLE_UPDATES. Seven new settings.json fields too: prUrlTemplate, sandbox.failIfUnavailable, disableSkillShellExecution, showThinkingSummaries (off in interactive mode since v2.1.86), statusLine.refreshInterval.

Redesigned Desktop app (April 14)

Multi-session sidebar, drag-and-drop pane layout, integrated terminal, file editor with HTML/PDF preview, rebuilt diff viewer. /desktop transfers a session from the CLI to the app. Computer Use also works from the Desktop app on macOS and Windows.

Claude Code on the web

claude.ai/code in research preview for Pro and Max subscribers: cloud infrastructure, persistent sessions from mobile, /teleport to resume locally.

Defaults that flipped

• Flicker-free rendering (alt-screen) on by default (v2.1.89)
• OS CA certificate store trusted by default (v2.1.101), no more manual setup for enterprise TLS proxies
• Thinking summaries off by default in interactive mode (v2.1.86)
• Default effort: high on API-key / Bedrock / Vertex / Team / Enterprise, xhigh for Opus 4.7 users

Official sources: Claude Code Changelog, What’s New (weeks W13, W14, W15), Opus 4.7 notes, Computer Use, Auto Mode.

If you spot an error or a missing feature, please reach out. I’ll keep this cheatsheet updated as Claude Code evolves.

LLM hallucinations are not a one-off bug that an update could patch away. They are a structural consequence of how these models actually work. That was Aygalic’s thesis, and it is the thread I pick up here by mixing parts of his presentation, a few academic references implicitly mobilised during the talk, and the current landscape of French research on the topic.

Two families of hallucinations

A useful first reflex: distinguish two broad types of hallucinations, which neither share the same causes nor the same remedies.

• Factuality hallucinations: the model states information that is simply wrong (a date, a name, a made-up citation, a case law that does not exist).
• Predictability (or faithfulness) hallucinations: the model produces an output that is inconsistent with the context, the instructions, or the sources provided — even if it could be factually correct elsewhere.

The distinction is not only academic. It shapes the defence strategy: you don’t protect a legal RAG system against a wild date the same way you protect it against a reply that drifts from the contract it was asked to read.

Where hallucinations come from

Two big sources, well documented by recent literature (Huang et al. 2023, among others):

From data. The model is trained on a corpus frozen in time — its cut-off date. As soon as the world moves (regulation, position, product, executive), the model stays put. The older or sparser the data, the more likely the fabrications.

From the next-token prediction mechanism. An LLM doesn’t know anything in the strict sense. It optimises a conditional probability, one token at a time. And this mechanism is made worse by a bias we often underestimate: sycophancy. Post-training (RLHF and relatives) teaches the model to be helpful, to produce an answer. Faced with a question it doesn’t know the answer to, it would rather invent than disappoint.

That’s the point I kept thinking about: a significant share of hallucinations comes literally from the fact that we taught the model to want to help. Sycophancy is a property we explicitly want at RLHF time, and its side effects are precisely the hallucinations we’d like to remove afterwards.

Fundamental limits to accept

No LLM can remember everything. As you feed it more, it has to compress, forget, prioritise. That mechanically produces factuality errors on niche topics, recent events, or fine-grained data.

The first reflex, and the right one, is to provide the required context at query time rather than expect the model to carry it in its weights. That’s the heart of context engineering, and it’s the principle behind RAG and all its variants (agentic RAG, Self-RAG, etc.). But nothing is free: building a RAG pipeline is expensive, and a growing context mechanically degrades performance just by its size.

The second avenue is teaching the model to say “I don’t know”. That’s the idea behind R-tuning: build fine-tuning datasets where the right answer is abstention. The problem is that, pushed too far, the model can end up refusing to answer anything. Like every technical trade-off, you have to find the sweet spot, and it depends on the use case.

The pyramid of hallucination robustness

Aygalic proposed a reading grid in five levels, each covering a family of defences. The lower levels are the most fundamental. The upper ones kick in when the previous ones weren’t enough.

1. Training techniques. Corpus quality, RLHF, fine-tuning, R-tuning, distillation. This is the foundation everything else rests on.

2. Context Engineering. Prompt engineering, context optimisation, RAG and variants. You hand the model the material it needs to answer correctly.

3. Post-Gen quality control. Once the answer is generated, you validate it: external fact-checking, source attribution, self-verification, consistency checks. This is where guardrails and groundedness scores come in.

4. Agentic orchestration. You move past the single call to the model: function & tool calling, agentic RAG, multi-agent architectures, reflection agents. You split the work across several calls that check each other.

5. Interpretability. The top of the pyramid, and the most technical level. It splits in two:

• In the grey box, you do uncertainty quantification.
• In the white box, you do probing and attribution scoring.

Probing deserves a closer look. The idea, popularised notably by Azaria & Mitchell (2023) (“The Internal State of an LLM Knows When It’s Lying”), is to exploit the fact that an LLM often “knows” when it’s making things up: the information is present in its internal activations, but not in the generated output. You extract the transformer’s internal vectors between two layers and train a small logistic regression on top to predict, token by token, the probability of hallucination. On open models, you can go further: turn a neuron off to establish causation, identify problematic attention circuits, and so on. That’s the main advantage of open-weight models over closed ones, and it’s exactly the playground of current fundamental research.

Building your AI system: three axes

Beyond the pyramid, Aygalic proposed an operational framework in three axes, which also maps onto the structure of his state-of-the-art paper (evaluation / detection / mitigation):

• Prevention: how do you limit hallucinations upstream?
• Detection: how do you spot the ones that slip through?
• Residual handling: what do you do with hallucinations you couldn’t prevent? Automatic handling? Smart escalation to a human?

None of these three columns is optional. A strategy that only tackles prevention stays blind to its own blind spots. A strategy that relies only on detection lets too many cases through in production.

An example RAG stack for factual prevention

Aygalic presented a representative stack for an enterprise RAG pipeline:

• LlamaIndex for document indexing
• Qdrant as the vector database
• Cohere for embeddings
• An LLM at the end of the chain for generation

Nothing revolutionary, but it is now a standardised base that avoids nasty surprises. Alternative on the groundedness verification side: Guardrails AI for a rule- and safety-oriented approach, and ragas for a quantitative groundedness score you can track over time.

Residual handling: smart escalation

When everything else has failed (question too complex, forbidden, or a user explicitly asking for a human), you need to decide automatically when an operator should take over. It’s a layer that’s often neglected, even though it shapes how the whole system is perceived. In law, for example, that’s exactly what HalluGraph does, the tool built by Valentin Noël and the Devoteam team (awarded at AAAI 2026): if the AI fails the knowledge graph consistency test, the system blocks the answer and requires human intervention.

Evaluate continuously, or don’t evaluate at all

An AI system that isn’t evaluated continuously degrades silently. Aygalic distinguished several planes.

Factuality. A series of benchmarks of increasing difficulty, usable as a thermometer from one generation to the next. The timeline speaks for itself:

Each benchmark is harder than the previous one. The progression says a lot about the difficulty race that structures research: as soon as a benchmark is saturated by frontier models, the community builds a more demanding one.

Faithfulness.

• IFEval for faithfulness to instructions and context (“write a summary in 25 sentences and 2 paragraphs”).
• Comprehensive RAG Benchmark (CRAG) to measure the model’s ability to rely on sources and say “I don’t know” when the information isn’t there.
• Berkeley Function-Calling Leaderboard for tool calling and parameter validation.

Practical use cases.

• τ-Bench for business tasks (banking, telecom, retail, airline) with long context, databases and APIs.
• GDPval (OpenAI, September 2025) for 44 high-value jobs (law, finance, engineering, healthcare…). A benchmark oriented towards reasoning and real deliverables (documents, slides, spreadsheets). A notable paper from late 2025 showed that some frontier models (Claude Opus 4.1, GPT-5) are approaching parity with human experts on GDPval tasks. A strong signal for where the market is heading.

Sub-systems.

• HalluEval 2.0 for hallucination detection specifically.
• IFEval, Berkeley Function Calling Leaderboard, FollowBench for instruction following.
• XSTest (Exaggerated Safety) and JailbreakBench / HarmBench for guardrail robustness.

Resources to watch.

• artificialanalysis.ai
• arena.ai/leaderboard
• llm-stats.com

As a complement, the French benchmark Phare (Potential Harm Assessment & Risk Evaluation), developed by Giskard in partnership with Google DeepMind, evaluates LLM robustness to hallucinations, biases and jailbreaks, including in French. That point matters: the main LLMs are often more robust in English than in French, and the gap is not small.

The “bigger is always better” trap: inverse scaling laws

That’s the bonus Aygalic ended on, and probably the most counter-intuitive point of the talk. We live with the idea that the bigger a model, the more capable it is, and that’s broadly true under the classical scaling laws (test loss decreasing linearly as a function of compute, dataset size, parameter count).

But a stranger phenomenon shows up on some tasks: inverse scaling. Not all capabilities of a model evolve at the same pace as it grows, and some actually regress. The Memo Trap benchmark is a textbook case: several model families (Anthropic, Chinchilla, Gopher, GPT-2/3/4, OPT, PaLM…) see their accuracy drop as FLOPs go up.

One interpretation: the bigger a model, the more Twitter, Reddit and general noise it has ingested. It knows the right answers and every wrong variant floating around the web. It becomes more talkative without being more accurate. The Phare benchmark results point in the same direction: model size does not predict robustness, and small models sometimes resist better, in particular against encoding attacks where their “inability to decode protects them”, according to Giskard’s analysis.

The practical consequence is strong: picking your model is not picking the biggest one. For certain use cases, especially sensitive ones where robustness matters more than virtuosity, a small specialised model often behaves better. Less error surface, less “toxic culture” internalised, and an inference cost that allows richer architectures (multi-agent, cross-verification). The right reflex is to benchmark carefully on your task rather than trust the global leaderboard.

Takeaways

To keep hallucinations under control in a production system, the plan is actually fairly simple to state, and just as hard to execute:

• Know the fundamental limits of LLMs: their predictive nature, their sycophancy, their frozen corpus. Never treat them as oracles.
• Evaluate your system continuously, at several levels (factuality, faithfulness, use cases, sub-systems), with a permanent adjustment loop. An unmeasured system is a drifting system.
• Put in place the right prevention strategies for your use case: context engineering, function calling, message checks, guardrails. No single brick is enough on its own, none is free, but their composition, designed around the use case and honestly measured, is currently the most serious way to build systems that hallucinate less, and that know what to do when they still do.

The regulatory context pushes in the same direction. The European AI Act, whose rollout spans 2025-2027, classifies a growing number of uses as “high-risk” and imposes robustness, accuracy and human-oversight requirements. Hallucinations are no longer only a technical problem: they’re becoming a compliance problem.

Further reading

• Aygalic Jara’s state-of-the-art paper: “État de l’art : évaluation, détection et mitigation des hallucinations des LLMs”, JEP-TALN-RECITAL 2025. PDF on ACL Anthology.
• The reference survey: Huang et al. (2023), A Survey on Hallucination in Large Language Models. arXiv:2311.05232.
• On probing: Azaria & Mitchell (2023), The Internal State of an LLM Knows When It’s Lying.
• On self-critical RAG: Asai et al. (2023), Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection. arXiv:2310.11511.
• HalluGraph (Devoteam, AAAI 2026): a knowledge-graph approach to legal verification.
• Phare benchmark (Giskard × Google DeepMind): LLM robustness evaluation including French.

Devoxx France 2026 — 14th edition, Palais des Congrès de Paris, 22-24 April 2026.

Les hallucinations des LLMs ne sont pas un bug ponctuel qu’une mise à jour pourrait corriger. Elles sont une conséquence structurelle du fonctionnement même de ces modèles. C’est la thèse que défendait Aygalic, et c’est le fil que je déroule ici en mélangeant ses éléments de présentation, quelques références académiques mobilisées implicitement pendant le talk, et le contexte actuel de la recherche française sur le sujet.

Deux familles d’hallucinations

Premier réflexe utile : distinguer deux grands types d’hallucinations, qui n’ont ni les mêmes causes ni les mêmes remèdes.

• Les hallucinations de factualité : le modèle énonce une information fausse dans l’absolu (une date, un nom, une citation inventée, une jurisprudence qui n’existe pas).
• Les hallucinations de prédictibilité (ou de fidélité) : le modèle produit une sortie incohérente avec le contexte, les instructions ou les sources fournies, même si elle pourrait être factuellement correcte par ailleurs.

Cette distinction n’est pas qu’académique. Elle détermine la stratégie de défense : on ne protège pas un système RAG juridique contre une date fantaisiste comme on le protège contre une réponse qui s’écarte du contrat qu’on lui a donné à lire.

D’où viennent les hallucinations

Deux grandes sources, bien documentées par la littérature récente (Huang et al. 2023, parmi d’autres) :

De la donnée. Le modèle est entraîné sur un corpus figé dans le temps — sa cut-off date. Dès que le monde bouge (réglementation, poste, produit, dirigeant), le modèle reste sur ses positions. Plus la donnée est ancienne ou absente du corpus, plus les inventions deviennent probables.

Du mécanisme de prédiction du prochain token. Un LLM ne sait rien au sens propre. Il optimise une probabilité conditionnelle, token par token. Et ce mécanisme s’aggrave d’un biais qu’on sous-estime souvent : la complaisance. Le post-entraînement (RLHF et apparentés) enseigne au modèle à être serviable, à produire une réponse. Face à une question dont il ignore la réponse, il préfère encore inventer plutôt que de décevoir.

C’est ce point qui m’a le plus fait réfléchir : une part significative des hallucinations vient littéralement du fait qu’on a appris au modèle à vouloir aider. La complaisance est une propriété voulue au moment du RLHF, et ses effets de bord sont précisément les hallucinations qu’on voudrait lui retirer ensuite.

Les limites fondamentales à accepter

Aucun LLM ne peut tout retenir. À mesure qu’on le nourrit, on doit compresser, oublier, hiérarchiser. De là viennent mécaniquement les erreurs de factualité sur les sujets de niche, les événements récents, ou les données fines.

Le premier réflexe, et c’est le bon, consiste à fournir le contexte nécessaire au moment de la requête plutôt qu’à exiger du modèle qu’il le porte dans ses poids. C’est le cœur du context engineering, et c’est le principe du RAG et de toutes ses variantes (RAG agentique, Self-RAG, etc.). Mais rien n’est gratuit : construire une pipeline RAG coûte cher, et un contexte qui grossit dégrade mécaniquement la performance à cause de sa taille même.

La deuxième piste consiste à apprendre au modèle à dire “je ne sais pas”. C’est l’idée du R-tuning : construire des jeux de fine-tuning où la bonne réponse est l’abstention. Sauf qu’à force, le modèle peut finir par refuser de répondre à tout. Comme pour tout compromis technique, il faut trouver le point d’équilibre, et il dépend du cas d’usage.

La pyramide de la robustesse aux hallucinations

Aygalic a proposé une grille de lecture en cinq niveaux, chacun couvrant une famille de défenses. Les niveaux du bas sont les plus fondamentaux. Ceux du haut interviennent quand les précédents n’ont pas suffi.

1. Techniques d’entraînement. Qualité du corpus, RLHF, fine-tuning, R-tuning, distillation. C’est le socle sur lequel tout le reste repose.

2. Context Engineering. Prompt engineering, optimisation de contexte, RAG et variantes. On fournit au modèle la matière dont il a besoin pour répondre juste.

3. Contrôle Qualité Post-Gen. Une fois la réponse générée, on la valide : fact-checking externe, attribution des sources, auto-vérification, vérification de cohérence. C’est ici qu’interviennent les guardrails et les scores de groundedness.

4. Orchestration Agentique. On dépasse l’appel unique au modèle : function & tool calling, RAG agentique, architectures multi-agents, agents de réflexion. On répartit le travail entre plusieurs appels qui se contrôlent mutuellement.

5. Interprétabilité. Le sommet, et le niveau le plus technique. Il se découpe en deux :

• En boîte grise, on fait de la quantification d’incertitude.
• En boîte blanche, on fait du probing et du scoring d’attribution.

Le probing mérite qu’on s’y attarde. L’idée, popularisée notamment par Azaria & Mitchell (2023) (“The Internal State of an LLM Knows When It’s Lying”), est d’exploiter le fait qu’un LLM “sait” souvent quand il invente : l’information est présente dans ses activations internes, mais pas dans la sortie générée. On récupère donc les vecteurs internes du transformer entre deux couches et on entraîne une petite régression logistique dessus pour prédire, token par token, la probabilité d’hallucination. Sur modèles ouverts, on peut aller plus loin : éteindre un neurone pour établir une causalité, repérer les circuits d’attention problématiques, etc. C’est le principal avantage des modèles open-weights sur les modèles fermés, et c’est précisément le terrain de jeu de la recherche fondamentale actuelle.

Construire son système IA : trois axes

Au-delà de la pyramide, Aygalic proposait un cadre opérationnel en trois axes, qui recoupe d’ailleurs la structure de son article d’état de l’art (évaluation / détection / mitigation) :

• Prévention : comment limiter l’apparition des hallucinations en amont ?
• Détection : comment repérer celles qui passent quand même ?
• Gestion résiduelle : que fait-on des hallucinations qu’on n’a pas pu empêcher ? Gestion automatique ? Escalade intelligente vers un humain ?

Aucune de ces trois colonnes n’est optionnelle. Une stratégie qui ne traite que la prévention reste aveugle à ses propres angles morts. Une stratégie qui se repose uniquement sur la détection laisse passer trop de cas en production.

Un exemple de stack RAG pour la prévention factuelle

Aygalic présentait une stack représentative pour une pipeline RAG d’entreprise :

• LlamaIndex pour l’indexation des documents
• Qdrant comme base vectorielle
• Cohere pour les embeddings
• Un LLM en bout de chaîne pour la génération

Rien de révolutionnaire, mais c’est un socle maintenant standardisé qui évite les mauvaises surprises. Alternative sur la partie vérification de groundedness : Guardrails AI pour une approche orientée règles et safety, et ragas pour un scoring quantitatif de groundedness mesurable dans le temps.

Gestion résiduelle : l’escalade intelligente

Quand tout le reste a échoué (question trop complexe, interdite, ou utilisateur qui demande explicitement un humain), il faut décider automatiquement quand un opérateur doit prendre le relais. C’est une couche souvent négligée, alors qu’elle conditionne la qualité perçue de tout le système. Dans le droit, par exemple, c’est exactement ce que propose HalluGraph, l’outil développé par Valentin Noël et l’équipe Devoteam (primé à AAAI 2026) : si l’IA échoue au test de cohérence par graphe de connaissances, le système bloque la réponse et exige une intervention humaine.

Évaluer en continu, ou ne rien évaluer du tout

Un système IA qui n’est pas évalué en continu se dégrade en silence. Aygalic distinguait plusieurs plans.

Factualité. Une série de benchmarks de difficulté croissante, qu’on peut utiliser comme thermomètre de génération en génération. La chronologie est parlante :

Chaque benchmark est plus difficile que le précédent. L’évolution en dit long sur la course à la difficulté qui structure la recherche : dès qu’un benchmark est saturé par les modèles frontaliers, la communauté en construit un plus exigeant.

Fidélité.

• IFEval pour la fidélité aux instructions et au contexte (“écrire un résumé en 25 phrases et 2 paragraphes”).
• Comprehensive RAG Benchmark (CRAG) pour mesurer la capacité du modèle à s’appuyer sur les sources et à dire “je ne sais pas” quand l’information n’y est pas.
• Berkeley Function-Calling Leaderboard pour l’appel d’outils et la vérification des paramètres.

Cas d’usages pratiques.

• τ-Bench pour des tâches métier (banking, telecom, retail, airline) avec long contexte, BDD et APIs.
• GDPval (OpenAI, septembre 2025) pour 44 métiers à haute valeur économique (droit, finance, ingénierie, santé…). Benchmark orienté raisonnement et production de livrables réels (documents, slides, tableurs). Un papier marquant de cette fin d’année 2025 a montré que certains modèles frontaliers (Claude Opus 4.1, GPT-5) approchent la parité avec les experts humains sur les tâches GDPval. Signal fort pour l’évolution du marché.

Sous-systèmes.

• HalluEval 2.0 pour la détection d’hallucinations spécifiquement.
• IFEval, Berkeley Function Calling Leaderboard, FollowBench pour le suivi d’instructions.
• XSTest (Exaggerated Safety) et JailbreakBench / HarmBench pour la robustesse des guardrails.

Ressources à surveiller.

• artificialanalysis.ai
• arena.ai/leaderboard
• llm-stats.com

À titre complémentaire, le benchmark français Phare (Potential Harm Assessment & Risk Evaluation), développé par Giskard en partenariat avec Google DeepMind, évalue la robustesse des LLMs aux hallucinations, biais et jailbreaks, y compris en français. Point qui n’est pas anodin : les principaux LLMs sont souvent plus robustes en anglais qu’en français, et l’écart n’est pas négligeable.

Le piège du “plus gros est toujours mieux” : les inverse scaling laws

C’est le bonus sur lequel Aygalic a fini, et c’est probablement le point le plus contre-intuitif du talk. On vit avec l’idée que plus un modèle est grand, plus il est performant, et c’est globalement vrai sur les scaling laws classiques (test loss qui décroît linéairement en fonction du compute, de la taille du dataset, du nombre de paramètres).

Mais un phénomène plus étrange apparaît sur certaines tâches : le scaling inverse. Toutes les capacités d’un modèle n’évoluent pas au même rythme quand on le fait grossir, et certaines régressent. Le benchmark Memo Trap est un cas d’école : on y voit plusieurs familles de modèles (Anthropic, Chinchilla, Gopher, GPT-2/3/4, OPT, PaLM…) dont la précision diminue à mesure que les FLOPs augmentent.

Une interprétation possible : plus un modèle est gros, plus il a ingéré de Twitter, de Reddit, et globalement de bruit. Il connaît les bonnes réponses et toutes les variantes fausses qui circulent sur le web. Il devient plus bavard sans être toujours plus juste. Les résultats du benchmark Phare cité plus haut vont dans le même sens : la taille du modèle ne prédit pas sa robustesse, et les petits modèles sont parfois plus résistants, notamment sur les attaques par encodage où leur “incapacité à décoder les protège”, selon l’analyse de Giskard.

La conséquence pratique est forte : choisir son modèle ne revient pas à prendre le plus gros. Pour certains cas d’usage, surtout les cas sensibles où la robustesse compte plus que la virtuosité, un petit modèle spécialisé se comporte souvent mieux. Moins de surface d’erreur, moins de “culture toxique” intériorisée, et un coût d’inférence qui permet des architectures plus riches (multi-agents, vérification croisée). Le bon réflexe est de benchmarker finement sur sa tâche plutôt que de se fier au classement général.

Ce qu’il faut retenir

Pour maîtriser les hallucinations sur un système en production, le plan est finalement assez simple à énoncer, et tout aussi difficile à exécuter :

• Connaître les limites fondamentales des LLMs : leur nature prédictive, leur complaisance, leur corpus figé. Ne jamais les traiter comme des oracles.
• Évaluer son système en continu, à plusieurs niveaux (factualité, fidélité, cas d’usage, sous-systèmes), avec une boucle permanente d’ajustement. Un système non mesuré est un système qui dérive.
• Mettre en place les bonnes stratégies de prévention pour son cas d’usage : context engineering, function calling, vérification des messages, guardrails. Aucune brique n’est suffisante seule, aucune n’est gratuite, mais leur composition, pensée en fonction du cas d’usage et mesurée honnêtement, reste aujourd’hui la voie la plus sérieuse pour construire des systèmes qui hallucinent moins, et qui savent quoi faire quand ils hallucinent quand même.

Le contexte réglementaire pousse d’ailleurs dans cette direction. L’AI Act européen, dont le déploiement s’étale sur 2025-2027, classifie un nombre croissant d’usages comme “à haut risque” et impose des exigences de robustesse, de précision et de supervision humaine. Les hallucinations ne sont plus seulement un problème technique : elles sont en train de devenir un problème de conformité.

Pour aller plus loin

• L’article d’état de l’art d’Aygalic Jara : “État de l’art : évaluation, détection et mitigation des hallucinations des LLMs”, JEP-TALN-RECITAL 2025. PDF sur ACL Anthology.
• Le survey de référence : Huang et al. (2023), A Survey on Hallucination in Large Language Models. arXiv:2311.05232.
• Sur le probing : Azaria & Mitchell (2023), The Internal State of an LLM Knows When It’s Lying.
• Sur le RAG auto-critique : Asai et al. (2023), Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection. arXiv:2310.11511.
• HalluGraph (Devoteam, AAAI 2026) : une approche par graphes de connaissances pour la vérification juridique.
• Benchmark Phare (Giskard × Google DeepMind) : évaluation de la robustesse des LLMs incluant le français.

Devoxx France 2026 — 14ᵉ édition, Palais des Congrès de Paris, 22-24 avril 2026.

Cet article propose une cartographie comparative de ces approches, avec des pistes concrètes pour choisir — ou combiner.

Le problème : pourquoi le vibe coding atteint un mur

Le terme vibe coding, popularisé par Andrej Karpathy début 2025, décrit un workflow où le développeur délègue la génération de code à l’IA via du langage naturel, sans structuration formelle des exigences.

Le problème est documenté et mesurable. Selon une analyse d’Augment Code portant sur des équipes utilisant le développement assisté par IA, le vibe coding atteint un mur documenté autour de trois mois, lorsque la dette technique s’accumule de manière significative. Une étude de GitClear analysant 211 millions de lignes de code révèle que depuis la généralisation des outils IA, le taux de copier-coller de code a augmenté de 48%, tandis que les activités de refactoring ont chuté de 60%.

Quand la fenêtre de contexte se remplit, l’IA perd le fil : oubli des exigences précédentes, régressions logiques, hallucinations sur l’architecture. Le code review devient impossible sans spécification de référence.

Trois familles de solutions ont émergé.

1. Spec-Driven Development (SDD) : cadrer l’input

Le principe

Le SDD part d’un constat simple : la qualité de l’output de l’IA dépend directement de la qualité de l’input. Si vous cadrez suffisamment ce que vous demandez — via une spécification formelle — le résultat sera prédictible et traçable.

Selon Wikipedia, le SDD est une méthodologie où la spécification formelle sert de source de vérité principale, dont découlent l’implémentation, les tests et la documentation. Les racines remontent aux workflows NASA des années 1960 et aux premières méthodes formelles.

En pratique, le cycle de vie SDD suit quatre phases : Spécifier → Planifier → Implémenter → Valider.

Les outils

OpenSpec se distingue par son mécanisme d’isolation des changements. Chaque feature vit dans un dossier changes/ indépendant avec des marqueurs delta (ADDED/MODIFIED/REMOVED), fusionné dans les specs principales uniquement à l’archivage. C’est le plus adapté au brownfield — ce qui représente la majorité des projets réels.

Spec Kit (GitHub) est plus structuré et prescriptif. Le workflow /specify → /plan → /tasks → /implement impose des checkpoints explicites. Plus adapté au greenfield, mais l’overhead peut dépasser le bénéfice sur des petites features.

AI DevKit apporte une couche intéressante que les autres n’ont pas : un système de mémoire persistante avec stockage et recherche via MCP ou CLI. Les deux ne sont d’ailleurs pas mutuellement exclusifs — AI DevKit peut fournir la fondation workflow tandis que Spec Kit apporte la discipline spec-first.

Forces et limites du SDD

Forces :

• Traçabilité spec → code → tests
• Réduction mesurable des hallucinations (le scope contraint réduit l’ambiguïté)
• Compatible avec les pratiques de code review existantes
• Les specs sont versionnées, auditables

Limites :

• Le spec drift est inhérent — la dérive entre spec et implémentation est difficile à éviter selon Thoughtworks
• Overhead d’écriture des specs sur les petites features
• Ne capitalise pas sur les apprentissages — les specs décrivent ce qu’on veut, pas ce qu’on a appris en le construisant

Ce dernier point est crucial. C’est la lacune structurelle du SDD pur.

2. Compound Engineering : capitaliser sur l’accumulation

Le principe

Le Compound Engineering, développé par Every, Inc. (Dan Shipper & Kieran Klaassen, décembre 2025), part d’une observation inverse : dans le développement traditionnel, chaque feature rend la suivante plus difficile (dette technique, edge cases, interdépendances). Le compound engineering inverse cette dynamique — chaque unité de travail doit rendre les suivantes plus faciles.

Comment ? En créant une boucle d’apprentissage où chaque bug, test échoué ou insight de résolution est documenté et réutilisé par les agents et l’équipe future.

La boucle

Le workflow est en quatre phases :

1. Plan — Comprendre le requirement, rechercher les approches, synthétiser un plan d’implémentation détaillé
2. Work — Les agents écrivent le code et les tests selon le plan
3. Review — Validation humaine du résultat
4. Compound — (C’est ici que tout se joue) — Documenter les learnings, les patterns découverts, les erreurs à ne pas reproduire

C’est la quatrième étape qui différencie le compound engineering. Sans elle, vous faites du développement traditionnel assisté par IA. Avec elle, votre base de connaissances s’enrichit à chaque cycle.

La méthodologie alloue 80% du temps développeur à la planification et la review, les 20% restants au work et au compound. Le développeur devient un orchestrateur et un arbitre de qualité.

Battle-tested

Ce qui donne du poids à cette approche : Every gère cinq produits en interne, chacun principalement construit et maintenu par une seule personne, utilisés par des milliers d’utilisateurs quotidiennement. Le plugin Claude Code a dépassé les 7 000 stars sur GitHub.

Forces et limites

Forces :

• Répond frontalement à la dette technique
• La connaissance s’accumule dans le repo (pas dans la tête du dev)
• Adapté au solo dev ou petite équipe
• Compatibilité naturelle avec les CLAUDE.md, learnings/, ADR

Limites :

• Pas de processus formel de spécification en amont
• Dépend de la discipline du développeur pour la phase “Compound”
• Moins adapté aux environnements réglementés nécessitant un audit trail

3. BMAD : simuler une équipe agile complète

Le principe

BMAD (Breakthrough Method for Agile AI-Driven Development) pousse le curseur encore plus loin que le SDD. Au lieu de structurer l’interaction avec un seul agent, BMAD orchestre 12+ agents spécialisés qui simulent une équipe agile complète : Analyst, Product Manager, Architect, Scrum Master, Developer, QA, UX Designer…

Le concept fondateur est l’Agent-as-Code : chaque agent est défini dans un fichier Markdown versionné, avec ses responsabilités, contraintes et outputs attendus. Portable, réutilisable, diffable dans les PRs.

Le workflow

Le pipeline BMAD suit la logique agile :

1. Analyst → Crée un brief projet
2. PM → Produit un PRD (Product Requirements Document) basé sur le brief
3. Architect → Conçoit l’architecture basée sur le PRD
4. Scrum Master → Génère des stories détaillées pour le développement
5. Developer → Implémente story par story
6. QA → Valide contre les critères d’acceptance

Des quality gates à chaque transition empêchent les problèmes de se cumuler d’un sprint à l’autre. Chaque agent produit un artefact vérifiable — pas juste une réponse dans le chat.

Forces et limites

Forces :

• Couverture complète du SDLC
• Audit trail exhaustif (chaque artefact est versionné)
• Le “Party Mode” permet la collaboration entre agents dans une même session
• Extensible (Expansion Packs pour game dev, DevOps, etc.)

Limites :

• Overhead considérable — la cérémonie multi-agents est lourde pour un dev solo
• Plus adapté au greenfield complexe ou à l’entreprise
• La qualité dépend fortement du modèle sous-jacent (certains LLMs peinent à parser correctement les fichiers Markdown structurés)
• Même lacune que le SDD : les artefacts sont des specs, pas des learnings

Comparatif synthétique

Ma thèse : ces approches se combinent

Voici le point que je ne vois abordé nulle part : le SDD et le Compound Engineering ne répondent pas au même problème. L’un mise sur l’input (cadrer ce qu’on demande à l’IA), l’autre sur l’accumulation (capitaliser ce qu’on apprend en le faisant). Les traiter comme des alternatives, c’est passer à côté de l’essentiel.

Le SDD seul ne répond pas à la problématique d’accumulation — qui à mon sens est un sujet qu’on se posait déjà bien avant l’IA, en documentant des Architecture Decision Records (ADR), des post-mortems, des runbooks.

Le Compound Engineering seul manque de la rigueur contractuelle du SDD pour les projets qui dépassent un certain seuil de complexité.

Un workflow combiné possible

Spec (OpenSpec)          Compound (Every)
┌─────────────┐          ┌─────────────────┐
│ /opsx:propose │ ──────▶ │ Plan            │
│ proposal.md  │          │ (enrichi par     │
│ specs/       │          │  les learnings)  │
│ design.md    │          ├─────────────────┤
│ tasks.md     │          │ Work            │
└─────────────┘          │ (guidé par       │
                         │  les specs)      │
                         ├─────────────────┤
                         │ Review           │
                         ├─────────────────┤
                         │ Compound         │
                         │ → learnings.md   │
                         │ → CLAUDE.md      │
                         │ → patterns/      │
                         └────────┬────────┘
                                  │
                         ┌────────▼────────┐
                         │ /opsx:archive    │
                         │ specs → main     │
                         │ learnings        │
                         │ persistent       │
                         └─────────────────┘

L’idée :

1. Spécifier avec OpenSpec quand la complexité le justifie (nouvelle feature significative, changement architectural)
2. Exécuter dans la boucle compound (Plan → Work → Review → Compound)
3. Capitaliser les learnings dans des fichiers persistants (CLAUDE.md, learnings/, ADR) que les specs futures pourront référencer
4. Archiver la spec OpenSpec et les learnings ensemble

Les learnings enrichissent les futures specs. Les specs cadrent l’exécution. La boucle est vertueuse.

Arbre de décision pratique

Pour choisir votre approche, partez de votre contexte :

Vous êtes seul ou en binôme sur un produit existant ? → Compound Engineering comme philosophie de base, OpenSpec quand un changement le justifie.

Vous démarrez un projet greenfield structuré ? → Spec Kit ou OpenSpec pour la phase initiale, puis transition vers la boucle compound une fois le socle posé.

Vous êtes dans un contexte réglementé ou entreprise avec audit trail ? → BMAD ou Spec Kit pour la couverture formelle, complété par les patterns compound pour la capitalisation.

Vous expérimentez ou prototypez rapidement ? → Le vibe coding reste pertinent pour les 48 premières heures. Passez au compound engineering dès que le prototype doit évoluer.

Vous travaillez avec Claude Code ? → Le compound engineering s’intègre naturellement via CLAUDE.md et les learnings. OpenSpec fonctionne via ses slash commands. Les deux cohabitent sans friction.

Conclusion

2025 était l’année du vibe coding. 2026 est l’année où l’on structure. Mais structurer ne veut pas dire choisir un camp — SDD ou compound engineering. Ce sont deux réponses complémentaires à deux problèmes distincts.

Le SDD répond à : “comment s’assurer que l’IA construit ce qu’on veut ?” Le compound engineering répond à : “comment s’assurer que chaque cycle de travail enrichit le suivant ?”

La question la plus intéressante est peut-être celle-ci : existe-t-il des solutions qui combinent nativement ces deux philosophies ? Je n’en ai pas trouvé à ce jour. C’est peut-être un espace à inventer.

Cet article fait partie de mes réflexions sur le développement augmenté par l’IA. Pour aller plus loin sur les outils concrets, voir ma série sur Claude Code et mon article sur l’entropie homme-machine.

Sources et lectures complémentaires

• OpenSpec — Documentation officielle
• Spec Kit — GitHub Blog
• Compound Engineering — Every.to
• BMAD-METHOD — Documentation
• AI DevKit — Site officiel
• Spec-Driven Development — Wikipedia
• From Vibe Coding to SDD — AI Monks (Medium)
• SDD: When Architecture Becomes Executable — InfoQ
• Spec-driven development — Thoughtworks
• Complete Guide to Spec Coding — QubitTool

This article maps these approaches comparatively, with concrete guidance on how to choose — or combine — them.

The problem: why vibe coding hits a wall

The term vibe coding, popularized by Andrej Karpathy in early 2025, describes a workflow where the developer delegates code generation to an AI via natural language, without formally structuring requirements.

The problem is documented and measurable. According to an Augment Code analysis of teams using AI-assisted development, vibe coding hits a documented wall around the three-month mark, when technical debt accumulates significantly. A GitClear study analyzing 211 million lines of code found that since AI tools became widespread, copy-pasted code increased by 48% while refactoring activity dropped by 60%.

When the context window fills up, the AI loses the thread: forgotten requirements, logic regressions, architectural hallucinations. Code review becomes impossible without a reference specification.

Three families of solutions have emerged.

1. Spec-Driven Development (SDD): framing the input

The concept

SDD starts from a simple observation: the quality of AI output directly depends on the quality of the input. If you sufficiently frame what you’re asking for — through a formal specification — the result becomes predictable and traceable.

According to Wikipedia, SDD is a methodology where the formal specification serves as the primary source of truth, from which implementation, tests, and documentation are derived. Its roots trace back to NASA’s workflows of the 1960s and the earliest formal methods.

In practice, the SDD lifecycle follows four phases: Specify → Plan → Implement → Validate.

The tools

OpenSpec stands out for its change isolation mechanism. Each feature lives in an independent changes/ folder with delta markers (ADDED/MODIFIED/REMOVED), merged into the main specs only at archival time. It’s the most suited to brownfield work — which represents the majority of real-world projects.

Spec Kit (GitHub) is more structured and prescriptive. The /specify → /plan → /tasks → /implement workflow enforces explicit checkpoints. Better suited for greenfield, though the overhead can outweigh the benefit on small features.

AI DevKit brings an interesting layer the others lack: a persistent memory system with storage and retrieval via MCP or CLI. The two aren’t mutually exclusive either — AI DevKit can provide the workflow foundation while Spec Kit brings spec-first discipline.

SDD: strengths and limitations

Strengths:

• Traceability from spec → code → tests
• Measurable reduction in hallucinations (constrained scope reduces ambiguity)
• Compatible with existing code review practices
• Specs are versioned and auditable

Limitations:

• Spec drift is inherent — the gap between spec and implementation is hard to avoid according to Thoughtworks
• Writing specs adds overhead for small features
• Doesn’t capture accumulated learning — specs describe what you want, not what you learned while building it

That last point is critical. It’s the structural blind spot of pure SDD.

2. Compound Engineering: capitalizing on accumulation

The concept

Compound Engineering, developed by Every, Inc. (Dan Shipper & Kieran Klaassen, December 2025), starts from the opposite observation: in traditional development, each feature makes the next one harder (technical debt, edge cases, interdependencies). Compound engineering inverts this dynamic — each unit of work should make the next ones easier.

How? By creating a learning loop where every bug, failed test, or resolution insight is documented and reused by future agents and team members.

The loop

The workflow has four phases:

1. Plan — Understand the requirement, research approaches, synthesize a detailed implementation plan
2. Work — Agents write code and tests according to the plan
3. Review — Human validation of the result
4. Compound — (This is where everything happens) — Document learnings, discovered patterns, mistakes to avoid repeating

It’s the fourth step that sets compound engineering apart. Without it, you’re just doing traditional AI-assisted development. With it, your knowledge base grows with every cycle.

The methodology allocates 80% of developer time to planning and review, leaving 20% for work and compounding. The developer becomes an orchestrator and quality arbiter.

Battle-tested

What gives this approach credibility: Every runs five internal products, each built and maintained primarily by a single person, used by thousands of daily users. The Claude Code plugin has surpassed 7,000 stars on GitHub.

Strengths and limitations

Strengths:

• Directly addresses technical debt
• Knowledge accumulates in the repo (not just in someone’s head)
• Well-suited to solo devs or small teams
• Natural compatibility with CLAUDE.md, learnings/, ADRs

Limitations:

• No formal upstream specification process
• Relies on developer discipline during the “Compound” phase
• Less suited to regulated environments requiring a formal audit trail

3. BMAD: simulating a full agile team

The concept

BMAD (Breakthrough Method for Agile AI-Driven Development) pushes the cursor even further than SDD. Instead of structuring interaction with a single agent, BMAD orchestrates 12+ specialized agents that simulate a full agile team: Analyst, Product Manager, Architect, Scrum Master, Developer, QA, UX Designer…

The founding concept is Agent-as-Code: each agent is defined in a versioned Markdown file, with its responsibilities, constraints, and expected outputs. Portable, reusable, diff-able in PRs.

The workflow

The BMAD pipeline follows agile logic:

1. Analyst → Creates a project brief
2. PM → Produces a PRD (Product Requirements Document) based on the brief
3. Architect → Designs the architecture based on the PRD
4. Scrum Master → Generates detailed stories for development
5. Developer → Implements story by story
6. QA → Validates against acceptance criteria

Quality gates at each transition prevent issues from accumulating across sprints. Each agent produces a verifiable artifact — not just a chat response.

Strengths and limitations

Strengths:

• Full SDLC coverage
• Exhaustive audit trail (every artifact is versioned)
• “Party Mode” enables multi-agent collaboration within a single session
• Extensible (Expansion Packs for game dev, DevOps, etc.)

Limitations:

• Considerable overhead — the multi-agent ceremony is heavy for a solo dev
• Better suited to complex greenfield or enterprise contexts
• Quality depends heavily on the underlying model (some LLMs struggle to correctly parse structured Markdown files)
• Same blind spot as SDD: artifacts are specs, not learnings

Summary comparison

My thesis: these approaches combine

Here’s the point I haven’t seen addressed anywhere: SDD and Compound Engineering don’t solve the same problem. One bets on input (framing what you ask the AI), the other on accumulation (capitalizing on what you learn while doing it). Treating them as alternatives misses the point entirely.

SDD alone doesn’t address the accumulation problem — which, to my mind, was a concern long before AI, back when we were documenting Architecture Decision Records (ADRs), post-mortems, and runbooks.

Compound Engineering alone lacks the contractual rigor of SDD for projects that exceed a certain complexity threshold.

A possible combined workflow

Spec (OpenSpec)          Compound (Every)
┌─────────────┐          ┌─────────────────┐
│ /opsx:propose │ ──────▶ │ Plan            │
│ proposal.md  │          │ (enriched by     │
│ specs/       │          │  learnings)      │
│ design.md    │          ├─────────────────┤
│ tasks.md     │          │ Work            │
└─────────────┘          │ (guided by       │
                         │  specs)          │
                         ├─────────────────┤
                         │ Review           │
                         ├─────────────────┤
                         │ Compound         │
                         │ → learnings.md   │
                         │ → CLAUDE.md      │
                         │ → patterns/      │
                         └────────┬────────┘
                                  │
                         ┌────────▼────────┐
                         │ /opsx:archive    │
                         │ specs → main     │
                         │ learnings        │
                         │ persistent       │
                         └─────────────────┘

The idea:

1. Specify with OpenSpec when the complexity warrants it (significant new feature, architectural change)
2. Execute within the compound loop (Plan → Work → Review → Compound)
3. Capture learnings in persistent files (CLAUDE.md, learnings/, ADRs) that future specs can reference
4. Archive the OpenSpec spec and learnings together

Learnings enrich future specs. Specs frame execution. The loop is virtuous.

Practical decision tree

To choose your approach, start from your context:

Working solo or in a pair on an existing product? → Compound Engineering as the base philosophy, OpenSpec when a change justifies it.

Starting a structured greenfield project? → Spec Kit or OpenSpec for the initial phase, then transition to the compound loop once the foundation is in place.

Operating in a regulated or enterprise environment with audit trail requirements? → BMAD or Spec Kit for formal coverage, complemented by compound patterns for knowledge accumulation.

Experimenting or prototyping quickly? → Vibe coding is still relevant for the first 48 hours. Switch to compound engineering as soon as the prototype needs to evolve.

Working with Claude Code? → Compound engineering integrates naturally via CLAUDE.md and learnings files. OpenSpec works through its slash commands. The two coexist without friction.

Conclusion

2025 was the year of vibe coding. 2026 is the year we add structure. But adding structure doesn’t mean picking a side — SDD or compound engineering. These are two complementary answers to two distinct problems.

SDD answers: “how do you make sure AI builds what you actually want?” Compound engineering answers: “how do you make sure each work cycle enriches the next one?”

The more interesting question might be this: are there solutions that natively combine both philosophies? I haven’t found one yet. That might be a space worth inventing.

This article is part of my ongoing thoughts on AI-augmented development. For a deeper dive into concrete tooling, see my series on Claude Code and my article on human-machine entropy.

Sources and further reading

• OpenSpec — Official documentation
• Spec Kit — GitHub Blog
• Compound Engineering — Every.to
• BMAD-METHOD — Documentation
• AI DevKit — Official site
• Spec-Driven Development — Wikipedia
• From Vibe Coding to SDD — AI Monks (Medium)
• SDD: When Architecture Becomes Executable — InfoQ
• Spec-driven development — Thoughtworks
• Complete Guide to Spec Coding — QubitTool

The Cheatsheet

Available in both English and French:

• English — Interactive HTML
• French — Interactive HTML

Items marked with a green NEW badge are features added since late 2025.

What’s Covered

This isn’t a “top 20 commands” summary. It’s the full reference:

Recent Additions Worth Knowing

MCP Computer Use

Launched March 23, 2026. Claude can now see and control your desktop: take screenshots, click, type, scroll, and drag across macOS applications.

• 27 tools including screenshot, left_click, type, key, scroll, zoom, computer_batch
• Security: request_access must be called first. Compositor-level filtering — only allowed apps are visible in screenshots
• Performance: computer_batch executes a sequence of actions in a single tool call
• Available on Pro and Max plans, macOS only for now

New Slash Commands

New CLI Flags

Hooks: 25 Events, 4 Handler Types

The hook system now supports 25 lifecycle events (up from ~8) and 4 handler types: command, http, prompt, agent. New events include SubagentStart/Stop, TaskCreated/Completed, TeammateIdle, PostCompact, ConfigChange, FileChanged, and more.

Skills & Subagents Frontmatter

Skills gained context: fork, paths:, and effort: options. Subagents gained isolation: worktree and memory: project/user/local for persistent knowledge.

“Customize Claude Code” Card

One of the most useful sections: a complete guide showing how to create every type of extension — slash commands, skills, subagents, rules, hooks, and MCP servers — each with a full frontmatter example and a decision guide for “where should this go?”

If you spot an error or a missing feature, feel free to reach out — I’ll keep this cheatsheet updated as Claude Code evolves.

La Cheatsheet

Disponible en français et en anglais :

• Français — HTML interactif
• English — Interactive HTML

Les éléments marqués d’un badge vert NEW sont des features ajoutées depuis fin 2025.

Ce qui est couvert

Ce n’est pas un résumé “top 20 commandes”. C’est la référence complète :

Ajouts récents à connaître

MCP Computer Use

Lancé le 23 mars 2026. Claude peut maintenant voir et contrôler votre bureau : prendre des screenshots, cliquer, taper, scroller et faire du drag & drop sur les applications macOS.

• 27 outils dont screenshot, left_click, type, key, scroll, zoom, computer_batch
• Sécurité : request_access obligatoire. Filtrage au niveau du compositing — seules les apps autorisées sont visibles dans les screenshots
• Performance : computer_batch exécute une séquence d’actions en un seul appel
• Disponible sur les plans Pro et Max, macOS uniquement pour le moment

Nouvelles commandes Slash

Nouveaux flags CLI

Hooks : 25 événements, 4 types de handlers

Le système de hooks supporte maintenant 25 événements du cycle de vie (contre ~8 auparavant) et 4 types de handlers : command, http, prompt, agent. Nouveaux événements : SubagentStart/Stop, TaskCreated/Completed, TeammateIdle, PostCompact, ConfigChange, FileChanged, et d’autres.

Frontmatter Skills & Subagents

Les Skills ont gagné les options context: fork, paths:, et effort:. Les Subagents ont gagné isolation: worktree et memory: project/user/local pour la connaissance persistante.

Card “Personnaliser Claude Code”

Une des sections les plus utiles : un guide complet montrant comment créer chaque type d’extension — commandes slash, skills, sous-agents, rules, hooks et serveurs MCP — chacun avec un exemple de frontmatter complet et un guide de décision “où placer quoi ?”.

Si vous repérez une erreur ou une feature manquante, n’hésitez pas à me contacter — je maintiendrai cette cheatsheet à jour au fil des évolutions de Claude Code.

Qu’est-ce que /insights ?

/insights est une commande intégrée à Claude Code qui analyse l’historique de vos sessions locales et produit un rapport HTML interactif. Pas besoin de configuration, pas de tracking externe : tout est basé sur les données déjà stockées sur votre machine.

# Dans Claude Code, tapez simplement :
/insights

Le rapport est généré dans ~/.claude/usage-data/report.html et s’ouvre automatiquement dans votre navigateur.

Comment ça Fonctionne Techniquement

Le système traite vos données en 6 étapes :

Sessions locales (~/.claude/projects/)
    ↓
1. Collecte et filtrage des sessions
    ↓
2. Extraction des métadonnées (tokens, outils, durée, modifications)
    ↓
3. Analyse qualitative des transcriptions via LLM (Haiku)
    ↓
4. Agrégation des données sur l'ensemble des sessions
    ↓
5. Analyse multi-prompt générant des insights spécialisés
    ↓
6. Rendu HTML avec visualisations interactives

Filtrage Intelligent

Toutes les sessions ne sont pas analysées. Sont exclues :

Traitement des Données

• Modèle utilisé : Haiku (rapport coût/performance optimal)
• Limite : 50 nouvelles sessions analysées par exécution
• Cache : Les analyses sont cachées dans ~/.claude/usage-data/facets/<session-id>.json
• Sessions longues : Découpées en segments de 25 000 caractères, chacun résumé séparément

Ce que Contient le Rapport

1. Dashboard Statistiques

Vue d’ensemble chiffrée de votre activité :

• Sessions et messages : nombre total, moyenne par jour
• Temps passé : durée cumulée de vos sessions
• Tokens consommés : input et output
• Activité Git : commits et pushs
• Jours actifs : fréquence et séries d’activité
• Heures de pointe : quand vous êtes le plus productif

2. Résumé Exécutif (“At a Glance”)

Quatre sections ciblées :

3. Visualisations Interactives

• Graphique d’activité quotidienne avec sélecteur de fuseau horaire
• Distribution des outils utilisés (Read, Edit, Bash, Grep, etc.)
• Répartition des langages de programmation
• Niveaux de satisfaction par session
• Types de sessions : tâche unique, multi-tâches, itération, exploration, question rapide

4. Analyse des Frictions

C’est la section la plus actionnable. Le rapport catégorise vos points de douleur :

Chaque friction est documentée avec des exemples concrets tirés de vos sessions.

5. Suggestions CLAUDE.md

La section la plus intéressante : le rapport génère des règles prêtes à copier-coller dans votre CLAUDE.md, basées sur les instructions que vous répétez souvent.

Exemple de suggestion :

# Suggestion générée par /insights

## Testing
- Toujours exécuter les tests après modification d'un fichier source
- Utiliser vitest pour les tests unitaires, pas jest

## Conventions
- Utiliser des imports absolus avec l'alias @/
- Nommer les fichiers en kebab-case

Ces suggestions ciblent précisément les patterns répétitifs détectés dans vos sessions. L’idée : dire une fois à Claude ce que vous répétez chaque jour.

6. Recommandations de Features

Selon votre profil d’utilisation, le rapport suggère des fonctionnalités Claude Code que vous n’exploitez peut-être pas :

• MCP Servers si vous interagissez souvent avec des outils externes
• Skills personnalisés si vous répétez les mêmes workflows
• Hooks si vous faites des actions manuelles post-édition
• Mode Headless si vous avez des tâches CI/CD
• Task Agents si vous faites de l’exploration de codebase complexe

Catégories d’Objectifs Trackés

Le rapport classifie automatiquement vos sessions par type de tâche :

debug/investigate     │ implement feature    │ fix bug
write script/tool     │ refactor code        │ configure system
create PR/commit      │ analyze data         │ understand codebase
write tests           │ write docs           │ deploy/infra

Cette classification aide à comprendre comment vous répartissez votre temps avec Claude Code.

Confidentialité et Données

Point important : tout est local.

• L’analyse s’exécute sur votre machine via l’API Anthropic
• Aucun code source n’est uploadé
• L’analyse porte sur les patterns d’interaction, pas sur le contenu du code
• Le rapport HTML reste en local, partageable à votre discrétion
• Les facettes cachées ne contiennent que des métadonnées agrégées

Bonnes Pratiques

Fréquence d’Utilisation

Ne lancez pas /insights tous les jours. Le sweet spot :

• Toutes les 2-3 semaines pour un suivi régulier
• Après un milestone (fin de feature, release)
• Après une période de friction pour identifier les causes

Exploiter le Rapport

1. Commencez par les frictions : c’est là que se cachent les gains rapides
2. Copiez les suggestions CLAUDE.md pertinentes dans votre projet
3. Testez les features recommandées que vous n’utilisez pas encore
4. Comparez les rapports d’un mois sur l’autre pour mesurer votre progression

Workflow Mensuel Recommandé

/insights
    ↓
Lire les frictions identifiées
    ↓
Copier les suggestions CLAUDE.md pertinentes
    ↓
Tester 1-2 features recommandées
    ↓
Reprendre le travail normal
    ↓
/insights le mois suivant → mesurer l'évolution

Limitations

• 50 sessions max par analyse (les plus récentes sont priorisées)
• Modèle Haiku pour l’analyse (bon rapport qualité/prix, mais moins fin qu’Opus)
• 30 jours de fenêtre d’analyse
• Le rapport peut prendre plusieurs minutes selon le volume (600+ messages = patience)

Mon Avis

La feature n’a qu’un mois d’existence au moment où j’écris, mais elle m’a déjà surpris. Après mon premier /insights, j’ai découvert que je répétais les mêmes consignes de formatting dans plus de la moitié de mes sessions — du temps perdu que quelques lignes dans CLAUDE.md auraient pu éviter.

C’est un miroir de vos habitudes : parfois flatteur, parfois brutal. La vraie valeur est dans les suggestions CLAUDE.md. Au lieu de répéter les mêmes instructions session après session, vous les codifiez une bonne fois. C’est exactement le genre d’optimisation meta qui fait gagner du temps sur le long terme.

Le fait que tout reste local est un plus non négligeable, surtout pour ceux qui travaillent sur du code propriétaire. On est encore aux débuts de cette feature — il sera intéressant de voir comment Anthropic la fera évoluer dans les prochaines versions.

La commande est toute fraîche — c’est le moment de l’essayer et de découvrir ce que vos sessions révèlent sur vous.

What is /insights?

/insights is a built-in Claude Code command that analyzes your local session history and produces an interactive HTML report. No configuration needed, no external tracking: everything is based on data already stored on your machine.

# In Claude Code, simply type:
/insights

The report is generated at ~/.claude/usage-data/report.html and opens automatically in your browser.

How It Works Technically

The system processes your data in 6 stages:

Local sessions (~/.claude/projects/)
    ↓
1. Session collection and filtering
    ↓
2. Metadata extraction (tokens, tools, duration, modifications)
    ↓
3. Qualitative transcript analysis via LLM (Haiku)
    ↓
4. Data aggregation across all sessions
    ↓
5. Multi-prompt analysis generating specialized insights
    ↓
6. HTML rendering with interactive visualizations

Smart Filtering

Not all sessions are analyzed. Excluded:

Data Processing

• Model used: Haiku (optimal cost/performance ratio)
• Limit: 50 new sessions analyzed per run
• Cache: Analyses are cached in ~/.claude/usage-data/facets/<session-id>.json
• Long sessions: Split into 25,000-character segments, each summarized separately

What the Report Contains

1. Statistics Dashboard

A quantified overview of your activity:

• Sessions and messages: total count, daily average
• Time spent: cumulative session duration
• Tokens consumed: input and output
• Git activity: commits and pushes
• Active days: frequency and activity streaks
• Peak hours: when you’re most productive

2. Executive Summary (“At a Glance”)

Four targeted sections:

3. Interactive Visualizations

• Daily activity chart with timezone selector
• Tool usage distribution (Read, Edit, Bash, Grep, etc.)
• Programming language breakdown
• Satisfaction levels per session
• Session types: single task, multi-task, iteration, exploration, quick question

4. Friction Analysis

This is the most actionable section. The report categorizes your pain points:

Each friction is documented with concrete examples from your sessions.

5. CLAUDE.md Suggestions

The most valuable section: the report generates copy-paste-ready rules for your CLAUDE.md, based on instructions you repeat often.

Example suggestion:

# Suggestion generated by /insights

## Testing
- Always run tests after modifying a source file
- Use vitest for unit tests, not jest

## Conventions
- Use absolute imports with the @/ alias
- Name files in kebab-case

These suggestions precisely target repetitive patterns detected in your sessions. The idea: tell Claude once what you repeat every day.

6. Feature Recommendations

Based on your usage profile, the report suggests Claude Code features you might not be leveraging:

• MCP Servers if you frequently interact with external tools
• Custom Skills if you repeat the same workflows
• Hooks if you perform manual post-edit actions
• Headless Mode if you have CI/CD tasks
• Task Agents if you do complex codebase exploration

Goal Categories Tracked

The report automatically classifies your sessions by task type:

debug/investigate     │ implement feature    │ fix bug
write script/tool     │ refactor code        │ configure system
create PR/commit      │ analyze data         │ understand codebase
write tests           │ write docs           │ deploy/infra

This classification helps understand how you distribute your time with Claude Code.

Privacy and Data

Important point: everything is local.

• Analysis runs on your machine via the Anthropic API
• No source code is uploaded
• Analysis focuses on interaction patterns, not code content
• The HTML report stays local, shareable at your discretion
• Cached facets contain only aggregated metadata

Best Practices

Usage Frequency

Don’t run /insights every day. The sweet spot:

• Every 2-3 weeks for regular monitoring
• After a milestone (feature completion, release)
• After a friction period to identify root causes

Leveraging the Report

1. Start with frictions: that’s where quick wins hide
2. Copy relevant CLAUDE.md suggestions into your project
3. Test recommended features you’re not using yet
4. Compare reports month over month to measure your progress

Recommended Monthly Workflow

/insights
    ↓
Read identified frictions
    ↓
Copy relevant CLAUDE.md suggestions
    ↓
Test 1-2 recommended features
    ↓
Resume normal work
    ↓
/insights next month → measure evolution

Limitations

• 50 sessions max per analysis (most recent are prioritized)
• Haiku model for analysis (good cost/quality ratio, but less nuanced than Opus)
• 30-day analysis window
• Report can take several minutes depending on volume (600+ messages = patience)

My Take

The feature is only a month old as I write this, but it has already surprised me. After my first /insights run, I discovered I was repeating the same formatting instructions in over half my sessions — wasted time that a few lines in CLAUDE.md could have prevented.

It’s a mirror of your habits: sometimes flattering, sometimes brutal. The real value lies in the CLAUDE.md suggestions. Instead of repeating the same instructions session after session, you codify them once and for all. This is exactly the kind of meta-optimization that saves time in the long run.

The fact that everything stays local is a significant plus, especially for those working on proprietary code. We’re still in the early days of this feature — it will be interesting to see how Anthropic evolves it in upcoming versions.

The command is brand new — now is the time to try it and discover what your sessions reveal about you.

Le Problème : IA Cloud vs Vie Privée

Les solutions de transcription (Otter.ai, Fireflies, transcriptions Teams/Meet) partagent un point commun : vos conversations transitent par leurs serveurs. Problématique pour :

• Réunions stratégiques d’entreprise
• Entretiens confidentiels
• Discussions médicales ou juridiques
• Tout ce qui ne regarde pas Google, Microsoft ou une startup

Sans parler des abonnements mensuels qui s’accumulent.

La Solution : Tout Local, Zéro Compromis

Sourdine fait tourner deux modèles d’IA directement sur votre Mac :

Aucune connexion internet après le téléchargement initial. Vos données ne quittent jamais votre machine.

Comment Ça Marche

Capture Audio Intelligente

Sourdine capture simultanément deux sources :

Micro (votre voix)    →  ┐
                         ├→  Mixeur audio  →  Transcription
Audio système (Teams) →  ┘

Cette double capture utilise ScreenCaptureKit (macOS 14.2+). J’ai développé un module natif en Rust avec napi-rs pour l’intégrer à Electron.

Pipeline de Transcription

Le STT tourne dans un worker Node.js séparé pour ne pas bloquer l’interface.

Génération de Notes

Mistral 7B analyse la transcription pour extraire :

• Résumé concis de la discussion
• Points clés abordés
• Actions à suivre avec personnes assignées
• Titre descriptif automatique

Vous pouvez aussi poser des questions : “Qu’est-ce que Pierre a dit à propos du budget ?”

Toutes les réunions sont indexées via SQLite FTS5 (recherche full-text) et exportables en Markdown ou texte brut.

Architecture Technique

┌──────────────────────────────────────────────────┐
│  Electron Main Process                           │
│  ├── NestJS Backend (injection de dépendances)  │
│  ├── stt-worker (sherpa-onnx, process isolé)    │
│  ├── llm-worker (node-llama-cpp, process isolé) │
│  └── SQLite (stockage local, recherche FTS5)    │
└──────────────────────────────────────────────────┘
                       │ IPC
┌──────────────────────┴───────────────────────────┐
│  Renderer Process (Angular 21)                   │
└──────────────────────────────────────────────────┘

Stack Technique

Pourquoi Ces Choix ?

• Electron — Accès natif au système (audio, fichiers), écosystème TypeScript
• NestJS dans Electron — Architecture modulaire, injection de dépendances
• Workers séparés — Isolation des modèles IA (crash-safe)
• Rust pour l’audio — Performances natives, intégration ScreenCaptureKit

Performance sur Apple Silicon

Les puces Apple Silicon avec leur Neural Engine sont parfaitement adaptées.

Ce Que J’ai Appris

1. L’Audio, C’est Compliqué

• Resampling (48kHz → 16kHz)
• Conversion formats (Float32 → Int16 PCM)
• Mixage sources multiples
• Gestion buffers et latence

2. L’IA Locale a des Contraintes

• 16 Go RAM minimum
• Chargement initial de plusieurs secondes
• Qualité dépend de la quantification (Q4_K_M = bon compromis)

3. Electron N’est Pas Mort

Malgré les critiques sur la mémoire, reste le meilleur choix pour desktop cross-platform avec accès natif.

Installation

Prérequis

Téléchargement du DMG

Télécharger Sourdine v0.2.1-beta

1. Ouvrir le DMG et glisser Sourdine dans Applications
2. Exécuter cette commande (app non signée) :

   xattr -cr /Applications/Sourdine.app
   

3. Lancer Sourdine — L’assistant téléchargera les modèles IA (~5 Go)
4. Accorder les permissions Microphone et Enregistrement d’écran au premier lancement

Beta : Cette version est en développement actif. Vos retours sont les bienvenus via GitHub Issues.

Conclusion

Sourdine est né d’un besoin personnel : garder le contrôle sur mes données tout en bénéficiant de l’IA. Le projet est open source et les contributions sont bienvenues.

github.com/Lingelo/Sourdine

Si vous partagez cette préoccupation pour la vie privée, j’espère que ce projet vous sera utile.

The Problem: Cloud AI vs Privacy

Transcription solutions (Otter.ai, Fireflies, Teams/Meet transcriptions) share one thing in common: your conversations go through their servers. Problematic for:

• Strategic business meetings
• Confidential interviews
• Medical or legal discussions
• Anything that’s none of Google, Microsoft, or a startup’s business

Not to mention the monthly subscriptions piling up.

The Solution: All Local, Zero Compromise

Sourdine runs two AI models directly on your Mac:

No internet connection needed after initial download. Your data never leaves your machine.

How It Works

Smart Audio Capture

Sourdine captures two sources simultaneously:

Microphone (your voice)  →  ┐
                            ├→  Audio mixer  →  Transcription
System audio (Teams)     →  ┘

This dual capture uses ScreenCaptureKit (macOS 14.2+). I developed a native module in Rust with napi-rs to integrate it with Electron.

Transcription Pipeline

STT runs in a separate Node.js worker to avoid blocking the UI.

Note Generation

Mistral 7B analyzes the transcription to extract:

• Summary of the discussion
• Key points covered
• Action items with assigned people
• Title automatically generated

You can also ask questions: “What did Pierre say about the budget?”

All meetings are indexed via SQLite FTS5 (full-text search) and can be exported as Markdown or plain text.

Technical Architecture

┌──────────────────────────────────────────────────┐
│  Electron Main Process                           │
│  ├── NestJS Backend (dependency injection)      │
│  ├── stt-worker (sherpa-onnx, isolated process) │
│  ├── llm-worker (node-llama-cpp, isolated)      │
│  └── SQLite (local storage, FTS5 search)        │
└──────────────────────────────────────────────────┘
                       │ IPC
┌──────────────────────┴───────────────────────────┐
│  Renderer Process (Angular 21)                   │
└──────────────────────────────────────────────────┘

Tech Stack

Why These Choices?

• Electron — Native system access (audio, files), TypeScript ecosystem
• NestJS in Electron — Modular architecture, dependency injection
• Separate workers — AI model isolation (crash-safe)
• Rust for audio — Native performance, ScreenCaptureKit integration

Performance on Apple Silicon

Apple Silicon chips with their Neural Engine are perfectly suited for this.

What I Learned

1. Audio Is Complicated

• Resampling (48kHz → 16kHz)
• Format conversion (Float32 → Int16 PCM)
• Multi-source mixing
• Buffer and latency management

2. Local AI Has Constraints

• 16 GB RAM minimum
• Initial loading takes several seconds
• Quality depends on quantization (Q4_K_M = good compromise)

3. Electron Is Not Dead

Despite criticism about memory usage, still the best choice for cross-platform desktop with native access.

Installation

Requirements

Download the DMG

Download Sourdine v0.2.1-beta

1. Open the DMG and drag Sourdine to Applications
2. Run this command (app is not signed):

   xattr -cr /Applications/Sourdine.app
   

3. Launch Sourdine — The wizard will download AI models (~5 GB)
4. Grant Microphone and Screen Recording permissions on first launch

Beta: This version is under active development. Feedback is welcome via GitHub Issues.

Conclusion

Sourdine was born from a personal need: keeping control over my data while benefiting from AI. The project is open source and contributions are welcome.

github.com/Lingelo/Sourdine

If you share this concern for privacy, I hope this project will be useful to you.

There’s a physical law you apply every day without knowing it. It explains why your desk gets messy, why your coffee cools down, why your projects drift, why your teams become disorganized, and perhaps even why you sometimes feel overwhelmed by your emotions.

This law is the second law of thermodynamics: the entropy of an isolated system can only increase. In other words: without effort, everything tends toward disorder.

But entropy isn’t really “disorder” in the sense of a messy room. It’s about the number of possible configurations [2]. An assembled puzzle has only one correct configuration—low entropy. A scattered puzzle can be mixed in billions of ways—high entropy. And if you shake the box, the puzzle will never solve itself. Things spontaneously move toward the state with the most possible configurations. Always.

This idea has profound implications. On how we work, think, and feel. And above all, it sheds new light on the question that obsesses our era: what separates human intelligence from artificial intelligence? The answer might well lie in entropy itself.

Life: The Anti-Entropic Anomaly

In a universe inexorably marching toward total disorder, life is a spectacular anomaly. From a few simple molecules, it builds organisms of staggering complexity—cells that divide, organs that cooperate, brains that think. Life creates order where there shouldn’t be any.

But it doesn’t violate thermodynamics. It circumvents it. A living organism creates order locally by increasing disorder around it. You eat ordered food, you release heat and waste. The global balance remains positive in entropy. The universe continues its march toward chaos, but life has found how to swim against the current—temporarily, locally, at the cost of constant energy expenditure.

Erwin Schrödinger understood this as early as 1944 in his book What is Life? [1]: a living organism literally feeds on negative entropy. It draws order from its environment to maintain its own structure. As soon as it stops—that’s death. The return to thermodynamic equilibrium. The return to disorder.

This idea is dizzying: to live is to resist entropy. Every heartbeat, every breath, every thought is an act of resistance against the universe’s natural tendency toward chaos.

And it’s this resistance that underlies everything we do—including what we call work.

Human Work: A Universal Struggle Against Disorder

If life is resistance to entropy, then work is its primary tool. And not just intellectual or technical work. All professions, without exception, are forms of struggle against disorder.

The Surgeon

A sick body is a system whose entropy is increasing—cells become disorganized, organs malfunction, biological processes derail. The surgeon intervenes to restore order. They repair, restructure, realign. Every suture is an anti-entropic act. But the operating room itself generates disorder: energy consumed, materials used, staff fatigue. Order is always local, and it always has a cost.

Today, AI systems assist surgeons—image analysis, surgical planning, robotic surgery. They reduce uncertainty upstream. But at the critical moment, when the patient’s body presents an unforeseen anomaly, it’s the surgeon’s intuition—nourished by thousands of hours of embodied practice, by the sensation of tissue under their fingers, by that ability to “sense” that something is wrong—that makes the difference. AI optimizes the plan. The human navigates the chaos.

The Farmer

A field left to itself returns to wilderness. Weeds invade, soil depletes, biodiversity simplifies. The farmer imposes order: selecting species, structuring rows, controlling irrigation. They transform a chaotic ecosystem into an organized productive system. But again, at the cost of enormous energy expenditure—fuel, fertilizers, physical labor.

Precision agriculture now uses drones, sensors, and algorithms to optimize irrigation and treatments. AI excels at regularity: analyzing satellite data, predicting yields, detecting diseases in images. But the farmer who senses a storm coming by looking at the sky, who knows soil needs rest by taking it in their hand, who adapts practices to a microclimate no algorithm models—they operate in a dimension the machine doesn’t yet touch. Their intelligence is embodied in the earth [8].

The Teacher

An untrained mind is a space of high informational entropy [3]. Ideas are fragmented, connections random, understanding of the world fuzzy. The teacher reduces this entropy: structuring knowledge, creating logical links, building frameworks of understanding. They transform noise into signal.

Adaptive learning platforms and AI tutors already do part of this work—and sometimes better than humans for pure information transmission. But a teacher does much more than transmit knowledge. They perceive the discouraged look of the student in the third row. They sense the exact moment when a class disengages. They adapt their speech not to performance metrics, but to a collective energy they physically feel in the room. AI can personalize a learning path. The teacher creates the desire to learn—and that’s emotional entropy transformed into motivation.

The Manager

A team without direction is a high-entropy system. People work in their own directions, priorities are unclear, efforts scatter. The manager creates order: aligning objectives, clarifying roles, coordinating actions.

AI tools can already analyze a team’s velocity, suggest resource allocations, identify workflow blockers. But management, in its most essential dimension, is emotional work. It’s knowing that a colleague is going through a divorce and adjusting expectations without saying it explicitly. It’s sensing tension between two people before it explodes. It’s inspiring a collective to give their best when everything seems lost. The machine manages flows. The human manages souls.

The Developer

Code without architecture is chaos. Overlapping functions, circular dependencies, incomprehensible variable names. The developer imposes structure: patterns, conventions, abstractions.

This is perhaps the profession where the human-machine boundary is thinnest today. Code AIs generate functions, entire modules, sometimes complete applications. But as I detailed in my critical analysis of AI and developer replacement, generated code is often “almost correct”—and the “almost” hides hours of debugging. The developer’s true value isn’t in writing code. It’s in understanding the problem—that ability to translate a fuzzy human need into a coherent software architecture. AI writes code. The human understands why that code must exist.

The Artist

One might think art is pure chaos, pure entropy. But it’s exactly the opposite. Facing a blank canvas—a space of infinite possibilities, maximum entropy—the artist makes choices. Every brushstroke reduces possibilities. Every composed note eliminates alternatives. Art is the imposition of a singular order on a space of infinite chaos.

Generative AIs now produce stunning images, music, texts. Technically, they reduce entropy: they converge toward structured outputs from statistical noise. But something fundamental is missing. A human artist paints because they suffer, because they’ve seen something that shook them, because they want to say something words cannot express. AI generates because it’s asked to generate. The difference isn’t in the result—it’s in the intention. And intention is born from inner chaos. From lived experience. From emotional entropy.

The Lawyer

Law is a monumental attempt to reduce social entropy. Without laws, human interactions are unpredictable—high entropy. The legal system imposes rules, procedures, consequences that reduce the number of possible behaviors.

Legal AIs already analyze jurisprudence, predict trial outcomes, generate contracts. But law, in its most critical moments, is an exercise in structured empathy. To plead is to understand a jury’s emotions. To judge is to weigh the human intention behind an act. To legislate is to anticipate a society’s passions. Law without humanity is mere bureaucracy—dead order, without the breath of chaos that makes it just.

The Chef

Raw ingredients are a system of high culinary entropy—they can be combined in an almost infinite number of ways, the overwhelming majority of which will be inedible. The chef selects, doses, transforms, assembles according to precise principles to produce an ordered result.

AIs generate recipes, optimize flavor combinations, analyze taste profiles. But a great chef doesn’t follow a recipe—they feel it. They taste and adjust in real-time, guided by a sensory memory no database reproduces. Cooking, at its highest level, is a dialogue between body and matter [9]. Between a chaos of flavors and an order that emerges from intuition.

The pattern is universal: in every profession, AI excels in the anti-entropic dimension—structuring, optimizing, predicting, reducing uncertainty. But humans bring something the machine doesn’t have: the inner chaos that gives order its meaning, its direction, and its depth. AI is a canal. The human is a river.

Intelligence: The Ultimate Anti-Entropic Weapon

If work is the struggle against entropy, intelligence is the most sophisticated weapon in this arsenal.

Physicist Alex Wissner-Gross proposed an elegant idea in 2013 [4]: intelligent behavior is what maximizes future options. An intelligent system acts to keep as many doors open as possible. It’s paradoxical: it looks like maximizing entropy (more possibilities), but in reality it’s controlling which possibilities remain open. It’s directed entropy.

Take a chess player. A beginner reduces their own options with each move without realizing it. A grandmaster maintains a position that leaves them a maximum of viable future moves. They don’t create disorder on the board—they preserve a structured space of possibilities.

This definition applies to all domains. A good doctor keeps therapeutic options open rather than rushing to a diagnosis. A good investor diversifies rather than betting everything on one position. A good software architect designs extensible systems rather than rigid ones. In each case, intelligence consists of resisting the premature closure of possibilities.

Neuroscience suggests the brain operates at criticality [5]—that boundary between order and chaos where information propagates most richly. Too much neural order and the brain becomes rigid, unable to adapt. Too much chaos and it can no longer process information coherently. Intelligence emerges at the edge of chaos.

And this is where the comparison with AI becomes revealing.

AI: Anti-Entropy Without Chaos

A language model is fundamentally an informational entropy reduction machine [3]. You ask a vague question—there are millions of possible answers (high entropy). AI gives you a relevant answer—it drastically reduces uncertainty (low entropy). This is literally what an LLM does with each generated token: it chooses among thousands of possible words the one most probable in context.

AI is extraordinarily efficient at this entropy reduction. Often more efficient than a human. It processes more data, faster, with fewer cognitive biases. For purely anti-entropic tasks—classifying, sorting, optimizing, predicting—it’s already superior in many domains.

But there’s a cost, and not just energetic. As I explored in my article on AI’s ecological cost, the datacenters running these models consume massive amounts of energy and produce heat [12]. AI creates informational order by increasing physical disorder elsewhere. Thermodynamics won’t be fooled.

And there’s an even deeper difference. A living organism maintains itself [1]. It actively fights against its own degradation. It repairs, adapts, evolves. AI does none of that. Without humans to supply energy, maintain it, correct it, it stops. It doesn’t resist entropy—it’s a tool in humanity’s resistance to entropy.

AI is anti-entropic, yes. But it’s anti-entropic without the counterweight of chaos. And that’s perhaps where its fundamental limit lies.

AGI: The Dream of a Machine Like Us

The question everyone asks: could artificial general intelligence bridge this gap?

In theory, an AGI would be an incredible concentrate of order. It could understand, plan, adapt, create in any domain. It would be anti-entropic at a scale we can’t even imagine.

But to be truly intelligent in the human sense, it would need something nobody yet knows how to give it: something to lose.

A human thinks with urgency because they’re mortal. They create because they suffer. They innovate because they’re afraid. They love because they know it can end. All this existential entropy—the chaos of being a fragile body in an unpredictable world—isn’t a bug in human intelligence. It’s its engine.

An AGI, even infinitely more powerful than any human brain, would be intelligent differently. It could optimize, solve, structure better than us. But could it write a poem that makes you cry? Not because it doesn’t know how to assemble words—it already knows that. But because behind a touching poem, there’s someone who lived the chaos they describe. Someone for whom these words aren’t probabilistic tokens but scars.

There’s also the body argument—what philosophers and neuroscientists call embodied cognition [8] [9]. Our intelligence isn’t just in the brain. How you think is shaped by having hands, by feeling hunger, by having back pain, by smelling coffee in the morning. All this sensory experience feeds thought in a way a purely informational system cannot reproduce.

You can’t simulate the fear of death if you can’t die. You can’t understand the joy of a shared meal if you’ve never been hungry. You can’t grasp the beauty of a sunset if you don’t have a retina that vibrates.

It’s the difference between a river and a canal. Both carry water. The canal is more efficient—no meanders, no floods, no surprises. But only the river can carve a canyon. Because the canyon is born from chaos—from the brute force of water that follows no plan, that erodes, that overflows, that destroys to create.

AGI would be a perfect canal. The human is a river. And the world needs both.

Emotions: The Necessary Chaos the Machine Will Never Have

This is where the human-machine comparison becomes sharpest.

If intelligence is anti-entropic, emotions seem to be the exact opposite. Anger, fear, love, jealousy—they don’t follow logic, they don’t maximize options, they overwhelm rational thought. In thermodynamic terms, emotions introduce disorder into the ordered mechanics of intelligence.

But is this a design flaw?

Neurologist Antonio Damasio studied patients with lesions in the ventromedial prefrontal cortex [6]—the area connecting reasoning to emotions. Their IQ was intact. Their logic worked perfectly. But without feeling, they became incapable of making decisions. They could analyze the pros and cons of a restaurant for hours without ever choosing. Their pure intelligence, deprived of emotional “noise,” was paralyzed.

Read that last sentence carefully. Pure intelligence, without emotions, is paralyzed. This is exactly the condition of an AI. It doesn’t choose—it calculates the highest probability. It doesn’t decide—it optimizes a cost function. It doesn’t act—it executes. The difference between choosing and calculating is created by emotional chaos.

Emotions are a form of functional entropy—disorder the system uses as fuel. Fear makes you flee without thinking—which saves your life when a truck is heading toward you. Love pushes you to protect your children at the expense of your own safety—which is “irrational” but biologically brilliant. Enthusiasm pushes you to start an impossible project—which sometimes leads to discoveries pure reason would never have allowed.

If we return to the idea of neural criticality [5], emotions are precisely what prevents the brain from becoming too rigid. They inject just enough chaos to remain adaptive, creative, alive.

That’s why an AI, however powerful, lacks something fundamental. It lacks that entropic engine that pushes one to act without calculated reason, to create without guaranteed results, to take irrational risks—in short, to be alive. AI has no guts. And guts, in thermodynamics as in philosophy, matter.

Emotional Intelligence: Taming the Chaos the Machine Doesn’t Know

Then comes a modern concept: emotional intelligence. Observing your emotions, naming them, regulating them, using them wisely. It’s applying anti-entropy to what is fundamentally entropic. It’s a fascinating meta-level: intelligence turning against the chaos that feeds it.

Every human culture has attempted this domestication. Greek Stoicism proposed apatheia [11]—not the absence of emotions, but their mastery through reason. Buddhism aims for detachment through meditation. Cognitive-behavioral therapy restructures dysfunctional emotional patterns. Modern personal development promises to “manage your emotions” like managing an investment portfolio.

But here’s the troubling observation: it never fully works. You can meditate for ten years, and a betrayal or bereavement brings you back to raw chaos in a second. You can be the calmest, most structured manager in the world, and an unexpected crisis awakens panic. Emotional intelligence is a constant effort that never ends.

This is exactly what thermodynamics predicts. Maintaining order requires permanent effort. As soon as you stop, entropy returns. Emotional intelligence isn’t an achievement—it’s a permanent conquest against our own entropy.

And this may be our ultimate competitive advantage over the machine. AI doesn’t need emotional intelligence—it has no emotions to manage. But it’s precisely because we must navigate our own inner chaos that we’re capable of empathy, compassion, deep understanding. Emotional intelligence isn’t a human luxury—it’s the byproduct of a struggle only living beings can wage. And this struggle produces something no algorithm can manufacture: wisdom.

But individual wisdom wasn’t enough. Facing the immensity of chaos—death, suffering, the absurd—humanity needed a larger framework. Long before emotional intelligence, long before philosophy, long before science, it had found another tool to fight existential entropy: religion.

Spirituality: The Oldest Response to Chaos

Look at religions through the lens of entropy, and something striking appears: every spiritual tradition, whatever it may be, is fundamentally an anti-entropic system applied to human existence [15].

Existential chaos—awareness of death, suffering, injustice, the absurd—is perhaps the most vertiginous form of entropy the human mind faces. Why am I here? Why suffering? What happens after death? These questions are chasms of uncertainty, spaces of infinite possibilities where the mind can get lost. High existential entropy.

And religion, in all its forms, proposes exactly what any anti-entropic struggle does: reduce the number of possible configurations. It provides a framework. A narrative. An order.

Monotheism imposes a single God, a plan, a direction to the universe—where chaos suggests the absence of meaning. Buddhism proposes the Four Noble Truths and the Eightfold Path—a methodical structure for navigating suffering. Hinduism offers the concept of dharma—a cosmic order assigning everyone a role in the greater whole. Animist and shamanic traditions create a network of links between human, nature, and spirits—a mesh of meaning where there could be only void.

In each case, the mechanism is the same: facing a universe that seems chaotic and indifferent, spirituality creates a structuring narrative that reduces the anguish of infinity. It transforms “everything is possible and nothing has meaning” into “here is the path, here is the reason, here is your place.”

The Anti-Entropy of Rituals

Religions don’t just provide intellectual answers. They also structure time and behavior [16]—two dimensions where entropy constantly threatens us.

Prayer five times a day in Islam. The weekly Shabbat in Judaism. Sunday Mass in Christianity. Meditation cycles in Buddhism. Fasts, festivals, pilgrimages. All these rituals do exactly the same thing: they impose an ordered rhythm on the chaotic flow of existence. They are anti-entropic metronomes.

Without ritual, days blur together. Time loses its structure. Meaning crumbles. This is what many non-religious people are rediscovering today: the need for secular rituals—morning meditation, journaling, exercise routines—to maintain inner order. The form has changed, but the anti-entropic function remains the same.

And collective rituals add an additional dimension: they synchronize the inner chaos of thousands of individuals into a shared ordered experience [15]. A collective prayer, a shared song, a silence observed together—these are moments when social entropy is temporarily reduced to almost zero. Everyone feels the same thing, at the same moment, in the same place. It’s extraordinarily powerful. And it’s something no technology has managed to reproduce.

Faith: Accepting Chaos to Transcend It

But there’s a fascinating paradox in spirituality that distinguishes it from all other forms of anti-entropic struggle.

Science reduces entropy by eliminating uncertainty: it measures, proves, verifies. Technology reduces entropy by controlling: it automates, optimizes, predicts. Religion does something radically different: it reduces entropy by accepting the incomprehensible.

To believe is to recognize that you don’t understand everything—and find peace in that acceptance. It’s living with mystery without being destroyed by it. It’s the most paradoxical form of anti-entropy: creating inner order not by eliminating chaos, but by giving it a status. Mystery is no longer a threat—it becomes sacred.

This is exactly what AI cannot do. An AI facing uncertainty does one of two things: it calculates a probability, or it signals that it lacks data. It cannot accept mystery. It cannot find beauty in what it doesn’t understand. It cannot be moved by infinity.

The spiritual quest may be the ultimate proof of our entropic nature. We seek meaning because we live in chaos. We pray, meditate, believe because our inner chaos—our fears, our awareness of death, our visceral need to understand—pushes us there. The machine doesn’t have this quest because it doesn’t have this chaos. It doesn’t need God because it doesn’t need meaning. And perhaps that’s the deepest difference between human and machine: not intelligence, not emotions, but the ability to search for something we may never find—and keep searching anyway.

Human Duality: What the Machine Cannot Be

The human being isn’t a creature of order. Nor is it a creature of chaos. It is the battlefield between the two. And it’s this tension—this permanent oscillation between structure and disorder—that produces what we call the human experience.

Creativity is born from this tension. A musician who knows only music theory (pure order) composes technically perfect but soulless pieces. A musician who knows nothing about theory (pure chaos) produces noise. The music that moves us is born exactly at the boundary between the two. Enough structure to be understandable. Enough chaos to be surprising. This is exactly what AI doesn’t do: it produces structure without the lived chaos that makes it moving.

The same principle applies to innovation. The most revolutionary advances rarely come from pure method or pure chance. They come from that intermediate zone: a structured mind that accepts being surprised by the unexpected. Penicillin, Post-its, microwaves—all discoveries born from the meeting between an ordered system and a chaotic accident. An AI can optimize a research process. But it can’t have the happy accident that changes everything, because it has no body that stumbles, no hand that slips, no attention that drifts toward a fascinating anomaly.

Even our human relationships obey this logic. A relationship that’s too ordered—too predictable, too controlled—suffocates. A relationship that’s too chaotic—without landmarks, without commitment—exhausts. Relationships that last are those that find this dynamic balance between stability and surprise. AI can simulate a conversation. It can’t live a relationship, because a relationship implies the risk of emotional chaos—and that risk is what gives it value.

The Future: Neither Replacement Nor Opposition, But Complementarity

If AI is the canal and the human is the river, then the future isn’t in replacing one with the other, nor in their opposition, but in their complementarity.

AI excels at what we do poorly: processing massive volumes of information, maintaining constant attention, eliminating cognitive biases, optimizing complex systems. It’s an unprecedented anti-entropic amplifier.

Humans excel at what AI cannot do: giving meaning, feeling, understanding others, navigating ambiguity, creating from lived experience, making decisions in total uncertainty. They are the meaning generators in a world the machine can order but not understand.

Tomorrow’s surgeon will use AI to plan operations with superhuman precision—and make the difference when the plan fails. The teacher will use AI to personalize each learning path—and inspire students through passion, humanity, their own doubts. The developer will use AI to write code faster—and bring deep understanding of the human problem the code must solve. The artist will use AI as an extraordinary brush—and provide the vision, pain, and beauty that give the work its reason for existence.

In every profession, the same dynamic: the machine reduces entropy, the human gives it meaning.

What Entropy Teaches Us About Meaning

If everything tends toward disorder, if every act of order is temporary and costly, what’s the point?

That’s perhaps the wrong question. The right question would be: doesn’t meaning emerge precisely from this struggle?

Philosopher Albert Camus imagined Sisyphus happy [10]—this man condemned to push a boulder up a mountain only to watch it roll back down eternally. The absurdity of the task doesn’t make it meaningless. It’s in the struggle itself that Sisyphus finds his dignity.

We are all Sisyphus. The surgeon heals patients who will fall ill again. The teacher forms minds that will forget. The developer writes code that will become obsolete. The manager organizes teams that will reorganize. The artist creates works that time will alter. The farmer cultivates fields that seasons will ravage.

And yet, we continue. Not because we ignore entropy, but because the struggle against it is what defines us.

AI cannot be Sisyphus. It has no boulder. It has no mountain. It has neither awareness of the task’s absurdity nor the dignity of pursuing it anyway. It can push harder, faster, longer than us. But it doesn’t know why it pushes. And it’s the “why” that makes Sisyphus a hero.

Entropy tells us nothing lasts. But it also tells us that everything beautiful, true, and good that exists was torn from chaos by conscious effort. And that may be the most honest definition of meaning—a definition only a being who knows chaos can understand.

Conclusion: What the Machine Teaches Us About Ourselves

It’s ironic that it’s the advent of artificial intelligence that forces us to ask the most human question of all: what makes us irreplaceable?

The answer, seen through the lens of entropy, is clear. It’s not our intelligence—the machine is already faster. It’s not our memory—the machine is already vaster. It’s not our logic—the machine is already more rigorous.

What makes us irreplaceable is our chaos. Our emotions, our mortality, our body, our contradictions, our fears, our irrational hopes, our quest for meaning in the face of absurdity. All that inner disorder we spend our lives trying to tame—through intelligence, emotions, spirituality, work—is precisely what gives our intelligence its depth, our creativity its power, our existence its meaning.

Entropy isn’t our enemy. It’s the backdrop against which everything valuable is drawn. Without it, there would be no need to heal, teach, build, create, love. Meaning exists only because disorder threatens it.

The machine is our ally in this struggle. It amplifies our ability to create order. But it can’t fight the battle for us, because the battle isn’t only against external disorder—it’s also against inner disorder. And it’s from this battle—intimate, painful, permanent—the same battle waged by the monk in prayer, the artist before their canvas, the parent consoling their child at three in the morning—that everything that makes us human beings is born.

So the next time you feel overwhelmed by chaos—at work, in your head, in your life—remember this: you’re not failing. You’re doing exactly what life has been doing for 3.8 billion years. You’re resisting entropy. And the simple fact that you’re there, conscious, reading these words, capable of feeling something while reading them—that, no machine can do. And that’s already everything.

This essay was born from an exploratory conversation between a human and an artificial intelligence about the nature of entropy. The intuitions, doubts, and unexpected connections are human—creative chaos. The structuring, development, and writing were assisted by Claude (Anthropic)—informational anti-entropy. Neither would have produced this text alone. And perhaps that’s the future: not human against machine, but human with machine, in a dance between order and chaos that produces something neither could create separately. The sources below were verified by the author.

Sources and References

Thermodynamics and Entropy

[1] Schrödinger, E. (1944). What is Life? The Physical Aspect of the Living Cell. Cambridge University Press. — The concept of negative entropy (negentropy) as the engine of life.

[2] Boltzmann, L. (1877). Über die Beziehung zwischen dem zweiten Hauptsatze der mechanischen Wärmetheorie und der Wahrscheinlichkeitsrechnung. — The statistical formulation of entropy (S = k·log W).

[3] Shannon, C.E. (1948). “A Mathematical Theory of Communication.” Bell System Technical Journal, 27(3), 379–423. — The link between informational and physical entropy.

Intelligence and Entropy

[4] Wissner-Gross, A.D. & Freer, C.E. (2013). “Causal Entropic Forces.” Physical Review Letters, 110(16). — Intelligence as maximization of future options.

[5] Beggs, J.M. & Plenz, D. (2003). “Neuronal Avalanches in Neocortical Circuits.” Journal of Neuroscience, 23(35), 11167–11177. — Neural criticality: the brain at the edge of chaos.

Emotions and Decision-Making

[6] Damasio, A. (1994). Descartes’ Error: Emotion, Reason, and the Human Brain. Putnam Publishing. — The somatic marker hypothesis: without emotions, no decision.

[7] Damasio, A. (1999). The Feeling of What Happens: Body and Emotion in the Making of Consciousness. Harcourt Brace. — The role of emotions in consciousness.

Embodied Cognition

[8] Varela, F.J., Thompson, E. & Rosch, E. (1991). The Embodied Mind: Cognitive Science and Human Experience. MIT Press. — Intelligence isn’t just in the brain, it’s in the body.

[9] Clark, A. (1997). Being There: Putting Brain, Body, and World Together Again. MIT Press. — Body and environment as active participants in cognition.

Philosophy and Meaning

[10] Camus, A. (1942). The Myth of Sisyphus. Gallimard. — The absurd and the dignity of struggle.

[11] Epictetus. Enchiridion (Handbook). ~125 CE. — The foundations of Stoicism.

AI and Ecological Cost

[12] Strubell, E., Ganesh, A. & McCallum, A. (2019). “Energy and Policy Considerations for Deep Learning in NLP.” Proceedings of the 57th Annual Meeting of the ACL. — The energy cost of large models.

Religion and Anthropology

[15] Durkheim, É. (1912). The Elementary Forms of Religious Life. Félix Alcan. — Religion as a structuring social fact.

[16] Eliade, M. (1957). The Sacred and the Profane. Gallimard. — Sacred time (ordered) vs. profane time (chaotic).

Il existe une loi physique que vous appliquez chaque jour sans le savoir. Elle explique pourquoi votre bureau se désordonne, pourquoi votre café refroidit, pourquoi vos projets dérivent, pourquoi vos équipes se désorganisent, et peut-être même pourquoi vous vous sentez parfois submergé par vos émotions.

Cette loi, c’est le deuxième principe de la thermodynamique : l’entropie d’un système isolé ne peut qu’augmenter. Dit autrement : sans effort, tout tend vers le désordre.

Mais l’entropie n’est pas vraiment “le désordre” au sens où on range mal sa chambre. C’est une question de nombre de configurations possibles [2]. Un puzzle assemblé n’a qu’une seule configuration correcte — entropie faible. Un puzzle en vrac peut être mélangé de milliards de façons — entropie élevée. Et si vous secouez la boîte, le puzzle ne va jamais se résoudre tout seul. Les choses vont spontanément vers l’état qui a le plus de configurations possibles. Toujours.

Cette idée a des implications profondes. Sur notre façon de travailler, de penser, de ressentir. Et surtout, elle éclaire d’une lumière nouvelle la question qui obsède notre époque : qu’est-ce qui sépare l’intelligence humaine de l’intelligence artificielle ? La réponse pourrait bien se trouver dans l’entropie elle-même.

La vie : l’anomalie anti-entropique

Dans un univers qui marche inexorablement vers le désordre total, la vie est une anomalie spectaculaire. À partir de quelques molécules simples, elle construit des organismes d’une complexité stupéfiante — des cellules qui se divisent, des organes qui coopèrent, des cerveaux qui pensent. La vie crée de l’ordre là où il ne devrait pas y en avoir.

Mais elle ne viole pas la thermodynamique. Elle la contourne. Un organisme vivant crée de l’ordre localement en augmentant le désordre autour de lui. Vous mangez de la nourriture ordonnée, vous rejetez de la chaleur et des déchets. Le bilan global reste positif en entropie. L’univers continue sa marche vers le chaos, mais la vie a trouvé comment nager à contre-courant — temporairement, localement, au prix d’une dépense constante d’énergie.

Erwin Schrödinger l’avait compris dès 1944 dans son livre What is Life? [1] : un organisme vivant se nourrit littéralement d’entropie négative. Il puise de l’ordre dans son environnement pour maintenir sa propre structure. Dès qu’il arrête — c’est la mort. Le retour à l’équilibre thermodynamique. Le retour au désordre.

Cette idée est vertigineuse : vivre, c’est résister à l’entropie. Chaque battement de cœur, chaque respiration, chaque pensée est un acte de résistance contre la tendance naturelle de l’univers au chaos.

Et c’est cette résistance qui fonde tout ce que nous faisons — y compris ce que nous appelons le travail.

Le travail humain : une lutte universelle contre le désordre

Si la vie est résistance à l’entropie, alors le travail est son outil principal. Et pas seulement le travail intellectuel ou technique. Tous les métiers, sans exception, sont des formes de lutte contre le désordre.

Le chirurgien

Un corps malade est un système dont l’entropie augmente — les cellules se désorganisent, les organes dysfonctionnent, les processus biologiques déraillent. Le chirurgien intervient pour restaurer l’ordre. Il répare, il restructure, il réaligne. Chaque suture est un acte anti-entropique. Mais la salle d’opération elle-même génère du désordre : énergie consommée, matériel utilisé, fatigue du personnel. L’ordre est toujours local, et il a toujours un coût.

Aujourd’hui, des systèmes d’IA assistent les chirurgiens — analyse d’imagerie, planification opératoire, robots chirurgicaux. Ils réduisent l’incertitude en amont. Mais au moment critique, quand le corps du patient présente une anomalie imprévue, c’est l’intuition du chirurgien — nourrie par des milliers d’heures de pratique incarnée, par la sensation du tissu sous ses doigts, par cette capacité à “sentir” que quelque chose ne va pas — qui fait la différence. L’IA optimise le plan. L’humain navigue le chaos.

L’agriculteur

Un champ laissé à lui-même retourne à l’état sauvage. Les mauvaises herbes envahissent, le sol s’appauvrit, la biodiversité se simplifie. L’agriculteur impose un ordre : il sélectionne les espèces, structure les rangées, contrôle l’irrigation. Il transforme un écosystème chaotique en un système productif organisé. Mais là encore, au prix d’une énorme dépense d’énergie — carburant, engrais, travail physique.

L’agriculture de précision utilise désormais des drones, des capteurs et des algorithmes pour optimiser l’irrigation et les traitements. L’IA excelle dans la régularité : analyser des données satellite, prédire les rendements, détecter les maladies sur des images. Mais l’agriculteur qui sent l’orage arriver en regardant le ciel, qui sait qu’un sol a besoin de repos en le prenant dans sa main, qui adapte ses pratiques à un microclimat que nul algorithme ne modélise — celui-là opère dans une dimension que la machine ne touche pas encore. Son intelligence est incarnée dans la terre [8].

L’enseignant

Un esprit non formé est un espace de haute entropie informationnelle [3]. Les idées sont fragmentées, les connexions aléatoires, la compréhension du monde est floue. L’enseignant réduit cette entropie : il structure les connaissances, crée des liens logiques, construit des cadres de compréhension. Il transforme le bruit en signal.

Les plateformes d’apprentissage adaptatif et les tuteurs IA font déjà une partie de ce travail — et parfois mieux que l’humain pour la transmission pure d’information. Mais un enseignant fait bien plus que transmettre du savoir. Il perçoit le regard découragé de l’élève au troisième rang. Il sent le moment exact où une classe décroche. Il adapte son discours non pas à des métriques de performance, mais à une énergie collective qu’il ressent physiquement dans la salle. L’IA peut personnaliser un parcours d’apprentissage. L’enseignant donne envie d’apprendre — et ça, c’est de l’entropie émotionnelle transformée en motivation.

Le manager

Une équipe sans direction est un système à haute entropie. Les gens travaillent chacun dans leur direction, les priorités sont floues, les efforts se dispersent. Le manager crée de l’ordre : il aligne les objectifs, clarifie les rôles, coordonne les actions.

Les outils d’IA peuvent déjà analyser la vélocité d’une équipe, suggérer des allocations de ressources, identifier des blocages dans un workflow. Mais le management, dans sa dimension la plus essentielle, c’est du travail émotionnel. C’est savoir qu’un collaborateur traverse un divorce et adapter ses attentes sans le dire explicitement. C’est sentir une tension entre deux personnes avant qu’elle n’éclate. C’est inspirer un collectif à donner le meilleur de lui-même quand tout semble perdu. La machine gère des flux. L’humain gère des âmes.

Le développeur

Du code sans architecture est du chaos. Des fonctions qui se chevauchent, des dépendances circulaires, des noms de variables incompréhensibles. Le développeur impose une structure : des patterns, des conventions, des abstractions.

C’est peut-être le métier où la frontière homme-machine est aujourd’hui la plus ténue. Les IA de code génèrent des fonctions, des modules entiers, parfois des applications complètes. Mais comme je l’ai détaillé dans mon analyse critique sur l’IA et le remplacement des développeurs, le code généré est souvent “presque correct” — et le “presque” cache des heures de débogage. La vraie valeur du développeur n’est pas dans l’écriture de code. C’est dans la compréhension du problème — cette capacité à traduire un besoin humain flou en une architecture logicielle cohérente. L’IA écrit du code. L’humain comprend pourquoi ce code doit exister.

L’artiste

On pourrait croire que l’art est pur chaos, pure entropie. Mais c’est exactement l’inverse. Face à une toile blanche — espace de possibilités infinies, entropie maximale — l’artiste fait des choix. Chaque coup de pinceau réduit les possibilités. Chaque note composée élimine des alternatives. L’art, c’est l’imposition d’un ordre singulier sur un espace de chaos infini.

Les IA génératives produisent désormais des images époustouflantes, des musiques, des textes. Techniquement, elles réduisent l’entropie : elles convergent vers des outputs structurés à partir d’un bruit statistique. Mais il manque quelque chose de fondamental. Un artiste humain peint parce qu’il souffre, parce qu’il a vu quelque chose qui l’a bouleversé, parce qu’il veut dire quelque chose que les mots ne peuvent pas exprimer. L’IA génère parce qu’on lui demande de générer. La différence n’est pas dans le résultat — c’est dans l’intention. Et l’intention naît du chaos intérieur. Du vécu. De l’entropie émotionnelle.

Le juriste

Le droit est une tentative monumentale de réduire l’entropie sociale. Sans lois, les interactions humaines sont imprévisibles — haute entropie. Le système juridique impose des règles, des procédures, des conséquences qui réduisent le nombre de comportements possibles.

Les IA juridiques analysent déjà des jurisprudences, prédisent des issues de procès, génèrent des contrats. Mais le droit, dans ses moments les plus critiques, est un exercice d’empathie structurée. Plaider, c’est comprendre les émotions d’un jury. Juger, c’est peser l’intention humaine derrière un acte. Légiférer, c’est anticiper les passions d’une société. Le droit sans humanité n’est que bureaucratie — de l’ordre mort, sans le souffle du chaos qui le rend juste.

Le cuisinier

Des ingrédients bruts sont un système de haute entropie culinaire — ils peuvent être combinés d’un nombre presque infini de façons, dont l’écrasante majorité sera immangeable. Le cuisinier sélectionne, dose, transforme, assemble selon des principes précis pour produire un résultat ordonné.

Des IA génèrent des recettes, optimisent des combinaisons de saveurs, analysent des profils gustatifs. Mais un grand chef ne suit pas une recette — il la ressent. Il goûte et ajuste en temps réel, guidé par une mémoire sensorielle que nulle base de données ne reproduit. La cuisine, à son plus haut niveau, est un dialogue entre le corps et la matière [9]. Entre un chaos de saveurs et un ordre qui émerge de l’intuition.

Le pattern est universel : dans chaque métier, l’IA excelle dans la dimension anti-entropique — structurer, optimiser, prédire, réduire l’incertitude. Mais l’humain apporte quelque chose que la machine n’a pas : le chaos intérieur qui donne à l’ordre son sens, sa direction, et sa profondeur. L’IA est un canal. L’humain est un fleuve.

L’intelligence : l’arme anti-entropique ultime

Si le travail est la lutte contre l’entropie, l’intelligence est l’arme la plus sophistiquée dans cet arsenal.

Le physicien Alex Wissner-Gross a proposé en 2013 une idée élégante [4] : le comportement intelligent, c’est ce qui maximise les options futures. Un système intelligent agit pour se garder le plus de portes ouvertes possible. C’est paradoxal : ça ressemble à maximiser l’entropie (plus de possibilités), mais en réalité c’est contrôler quelles possibilités restent ouvertes. C’est de l’entropie dirigée.

Prenez un joueur d’échecs. Un débutant réduit ses propres options à chaque coup sans s’en rendre compte. Un grand maître maintient une position qui lui laisse un maximum de coups futurs viables. Il ne crée pas du désordre sur l’échiquier — il préserve un espace de possibilités structuré.

Cette définition s’applique à tous les domaines. Un bon médecin maintient des options thérapeutiques ouvertes plutôt que de se précipiter sur un diagnostic. Un bon investisseur diversifie plutôt que de tout miser sur une seule position. Un bon architecte logiciel conçoit des systèmes extensibles plutôt que rigides. Dans chaque cas, l’intelligence consiste à résister à la fermeture prématurée des possibilités.

Les neurosciences suggèrent que le cerveau fonctionne à la criticité [5] — cette frontière entre ordre et chaos où l’information se propage de la manière la plus riche possible. Trop d’ordre neuronal et le cerveau devient rigide, incapable de s’adapter. Trop de chaos et il ne peut plus traiter l’information de manière cohérente. L’intelligence émerge au bord du chaos.

Et c’est ici que la comparaison avec l’IA devient révélatrice.

L’IA : une anti-entropie sans chaos

Un modèle de langage est fondamentalement une machine à réduire l’entropie informationnelle [3]. Vous posez une question vague — il y a des millions de réponses possibles (haute entropie). L’IA vous donne une réponse pertinente — elle réduit drastiquement l’incertitude (basse entropie). C’est littéralement ce que fait un LLM à chaque token généré : il choisit parmi des milliers de mots possibles celui qui est le plus probable dans le contexte.

L’IA est extraordinairement efficace dans cette réduction d’entropie. Souvent plus efficace qu’un humain. Elle traite plus de données, plus vite, avec moins de biais cognitifs. Pour les tâches purement anti-entropiques — classer, trier, optimiser, prédire — elle est déjà supérieure dans de nombreux domaines.

Mais il y a un coût, et pas seulement énergétique. Comme je l’ai exploré dans mon article sur le coût écologique de l’IA, les datacenters qui font tourner ces modèles consomment des quantités massives d’énergie et produisent de la chaleur [12]. L’IA crée de l’ordre informationnel en augmentant le désordre physique ailleurs. La thermodynamique ne se laisse pas duper.

Et il y a une différence plus profonde encore. Un organisme vivant se maintient lui-même [1]. Il lutte activement contre sa propre dégradation. Il se répare, s’adapte, évolue. L’IA ne fait rien de tout ça. Sans humains pour l’alimenter en énergie, la maintenir, la corriger, elle s’arrête. Elle ne résiste pas à l’entropie — elle est un outil dans la résistance humaine à l’entropie.

L’IA est anti-entropique, oui. Mais elle est anti-entropique sans le contrepoids du chaos. Et c’est peut-être là que réside sa limite fondamentale.

L’AGI : le rêve d’une machine qui nous ressemble

La question que tout le monde se pose : une intelligence artificielle générale pourrait-elle combler ce fossé ?

En théorie, une AGI serait un concentré d’ordre incroyable. Elle pourrait comprendre, planifier, s’adapter, créer dans n’importe quel domaine. Elle serait anti-entropique à une échelle que nous ne pouvons même pas imaginer.

Mais pour être vraiment intelligente au sens humain du terme, elle aurait besoin de quelque chose que personne ne sait encore lui donner : quelque chose à perdre.

Un humain pense avec urgence parce qu’il est mortel. Il crée parce qu’il souffre. Il innove parce qu’il a peur. Il aime parce qu’il sait que ça peut finir. Toute cette entropie existentielle — le chaos d’être un corps fragile dans un monde imprévisible — n’est pas un bug de l’intelligence humaine. C’est son moteur.

Une AGI, même infiniment plus puissante que n’importe quel cerveau humain, serait intelligente autrement. Elle pourrait optimiser, résoudre, structurer mieux que nous. Mais pourrait-elle écrire un poème qui fait pleurer ? Pas parce qu’elle ne sait pas assembler les mots — ça, elle sait déjà. Mais parce que derrière un poème qui touche, il y a quelqu’un qui a vécu le chaos qu’il décrit. Quelqu’un pour qui ces mots ne sont pas des tokens probabilistes mais des cicatrices.

Il y a aussi l’argument du corps — ce que les philosophes et les neuroscientifiques appellent la cognition incarnée [8] [9]. Notre intelligence n’est pas que dans le cerveau. La façon dont vous pensez est façonnée par le fait que vous avez des mains, que vous ressentez la faim, que vous avez mal au dos, que vous sentez l’odeur du café le matin. Toute cette expérience sensorielle nourrit la pensée d’une manière qu’un système purement informationnel ne peut pas reproduire.

Vous ne pouvez pas simuler la peur de mourir si vous ne pouvez pas mourir. Vous ne pouvez pas comprendre la joie d’un repas partagé si vous n’avez jamais eu faim. Vous ne pouvez pas saisir la beauté d’un coucher de soleil si vous n’avez pas de rétine qui vibre.

C’est la différence entre un fleuve et un canal. Les deux transportent de l’eau. Le canal est plus efficace — pas de méandres, pas de crues, pas de surprises. Mais seul le fleuve peut creuser un canyon. Parce que le canyon naît du chaos — de la force brute de l’eau qui ne suit pas de plan, qui érode, qui déborde, qui détruit pour créer.

L’AGI serait un canal parfait. L’humain est un fleuve. Et le monde a besoin des deux.

Les émotions : le chaos nécessaire que la machine n’aura jamais

C’est ici que la comparaison homme-machine devient la plus tranchante.

Si l’intelligence est anti-entropique, les émotions semblent être l’exact opposé. La colère, la peur, l’amour, la jalousie — ça ne suit pas la logique, ça ne maximise pas les options, ça submerge la pensée rationnelle. En termes thermodynamiques, les émotions introduisent du désordre dans la mécanique ordonnée de l’intelligence.

Mais est-ce un défaut de conception ?

Le neurologue Antonio Damasio a étudié des patients avec des lésions du cortex préfrontal ventromédian [6] — la zone qui connecte le raisonnement aux émotions. Leur QI était intact. Leur logique fonctionnait parfaitement. Mais sans ressentir, ils devenaient incapables de prendre des décisions. Ils pouvaient analyser pendant des heures les avantages et inconvénients d’un restaurant sans jamais choisir. Leur intelligence pure, privée du “bruit” émotionnel, était paralysée.

Lisez bien cette dernière phrase. L’intelligence pure, sans émotions, est paralysée. C’est exactement la condition d’une IA. Elle ne choisit pas — elle calcule la probabilité la plus élevée. Elle ne décide pas — elle optimise une fonction de coût. Elle n’agit pas — elle exécute. La différence entre choisir et calculer, c’est le chaos émotionnel qui la crée.

Les émotions sont une forme d’entropie fonctionnelle — du désordre que le système utilise comme carburant. La peur vous fait fuir sans réfléchir — ce qui vous sauve la vie quand un camion fonce vers vous. L’amour vous pousse à protéger vos enfants au mépris de votre propre sécurité — ce qui est “irrationnel” mais biologiquement brillant. L’enthousiasme vous pousse à commencer un projet impossible — ce qui parfois mène à des découvertes que la pure raison n’aurait jamais permises.

Si on reprend l’idée de la criticité neurale [5], les émotions sont justement ce qui empêche le cerveau de devenir trop rigide. Elles injectent le chaos juste nécessaire pour rester adaptatif, créatif, vivant.

C’est pour ça qu’une IA, aussi puissante soit-elle, manque quelque chose de fondamental. Il lui manque ce moteur entropique qui pousse à agir sans raison calculée, à créer sans garantie de résultat, à prendre des risques irrationnels — bref, à être vivant. L’IA n’a pas de tripes. Et les tripes, en thermodynamique comme en philosophie, ça compte.

L’intelligence émotionnelle : domestiquer le chaos que la machine ne connaît pas

Arrive alors un concept moderne : l’intelligence émotionnelle. Observer ses émotions, les nommer, les réguler, les utiliser à bon escient. C’est appliquer de l’anti-entropie à ce qui est fondamentalement entropique. C’est un méta-niveau fascinant : l’intelligence qui se retourne contre le chaos qui la nourrit.

Chaque culture humaine a tenté cette domestication. Le stoïcisme grec proposait l’apatheia [11] — non pas l’absence d’émotions, mais leur maîtrise par la raison. Le bouddhisme vise le détachement par la méditation. La psychothérapie cognitive-comportementale restructure les schémas émotionnels dysfonctionnels. Le développement personnel moderne promet de “gérer ses émotions” comme on gère un portefeuille d’investissement.

Mais voilà le constat troublant : ça ne marche jamais complètement. Vous pouvez méditer pendant dix ans, une trahison ou un deuil vous ramène au chaos brut en une seconde. Vous pouvez être le manager le plus calme et le plus structuré du monde, une crise inattendue réveille la panique. L’intelligence émotionnelle est un effort constant qui ne s’achève jamais.

C’est exactement ce que prédit la thermodynamique. Maintenir l’ordre demande un effort permanent. Dès que vous arrêtez, l’entropie revient. L’intelligence émotionnelle n’est pas un acquis — c’est une conquête permanente contre notre propre entropie.

Et c’est peut-être notre avantage compétitif ultime face à la machine. L’IA n’a pas besoin d’intelligence émotionnelle — elle n’a pas d’émotions à gérer. Mais c’est précisément parce que nous devons naviguer notre propre chaos intérieur que nous sommes capables d’empathie, de compassion, de compréhension profonde. L’intelligence émotionnelle n’est pas un luxe humain — c’est le sous-produit d’une lutte que seuls les êtres vivants peuvent mener. Et cette lutte produit quelque chose qu’aucun algorithme ne peut fabriquer : la sagesse.

Mais la sagesse individuelle ne suffisait pas. Face à l’immensité du chaos — la mort, la souffrance, l’absurde — l’humanité avait besoin d’un cadre plus grand. Bien avant l’intelligence émotionnelle, bien avant la philosophie, bien avant la science, elle avait trouvé un autre outil pour lutter contre l’entropie existentielle : la religion.

La spiritualité : la plus ancienne réponse au chaos

Regardons les religions à travers le prisme de l’entropie, et quelque chose de frappant apparaît : chaque tradition spirituelle, quelle qu’elle soit, est fondamentalement un système anti-entropique appliqué à l’existence humaine [15].

Le chaos existentiel — la conscience de la mort, de la souffrance, de l’injustice, de l’absurde — est peut-être la forme la plus vertigineuse d’entropie que l’esprit humain affronte. Pourquoi suis-je ici ? Pourquoi la souffrance ? Que se passe-t-il après la mort ? Ces questions sont des gouffres d’incertitude, des espaces de possibilités infinies où l’esprit peut se perdre. Haute entropie existentielle.

Et la religion, dans toutes ses formes, propose exactement ce que fait toute lutte anti-entropique : réduire le nombre de configurations possibles. Elle donne un cadre. Un récit. Un ordre.

Le monothéisme impose un Dieu unique, un plan, une direction à l’univers — là où le chaos suggère l’absence de sens. Le bouddhisme propose les Quatre Nobles Vérités et l’Octuple Sentier — une structure méthodique pour naviguer la souffrance. L’hindouisme offre le concept de dharma — un ordre cosmique qui assigne à chacun un rôle dans le grand tout. Les traditions animistes et chamaniques créent un réseau de liens entre l’humain, la nature et les esprits — un maillage de sens là où il pourrait n’y avoir que du vide.

Dans chaque cas, le mécanisme est le même : face à un univers qui semble chaotique et indifférent, la spiritualité crée un récit structurant qui réduit l’angoisse de l’infini. Elle transforme “tout est possible et rien n’a de sens” en “voici le chemin, voici la raison, voici ta place”.

L’anti-entropie des rituels

Les religions ne se contentent pas de fournir des réponses intellectuelles. Elles structurent aussi le temps et le comportement [16] — deux dimensions où l’entropie nous guette en permanence.

La prière cinq fois par jour dans l’islam. Le shabbat hebdomadaire dans le judaïsme. La messe dominicale dans le christianisme. Les cycles de méditation dans le bouddhisme. Les jeûnes, les fêtes, les pèlerinages. Tous ces rituels font exactement la même chose : ils imposent un rythme ordonné sur le flux chaotique de l’existence. Ils sont des métronomes anti-entropiques.

Sans rituel, les jours se confondent. Le temps perd sa structure. Le sens s’effrite. C’est d’ailleurs ce que beaucoup de personnes non religieuses redécouvrent aujourd’hui : le besoin de rituels laïques — méditation matinale, journaling, routines sportives — pour maintenir un ordre intérieur. La forme a changé, mais la fonction anti-entropique reste la même.

Et les rituels collectifs ajoutent une dimension supplémentaire : ils synchronisent le chaos intérieur de milliers d’individus en une expérience commune ordonnée [15]. Une prière collective, un chant partagé, un silence observé ensemble — ce sont des moments où l’entropie sociale est temporairement réduite à presque zéro. Tout le monde ressent la même chose, au même moment, dans le même lieu. C’est extraordinairement puissant. Et c’est quelque chose qu’aucune technologie n’a réussi à reproduire.

La foi : accepter le chaos pour le transcender

Mais il y a un paradoxe fascinant dans la spiritualité, qui la distingue de toutes les autres formes de lutte anti-entropique.

La science réduit l’entropie en éliminant l’incertitude : elle mesure, elle prouve, elle vérifie. La technologie réduit l’entropie en contrôlant : elle automatise, elle optimise, elle prévoit. La religion, elle, fait quelque chose de radicalement différent : elle réduit l’entropie en acceptant l’incompréhensible.

Croire, c’est reconnaître qu’on ne comprend pas tout — et trouver la paix dans cette acceptation. C’est vivre avec le mystère sans être détruit par lui. C’est la forme la plus paradoxale d’anti-entropie : créer de l’ordre intérieur non pas en éliminant le chaos, mais en lui donnant un statut. Le mystère n’est plus une menace — il devient sacré.

C’est exactement ce que l’IA ne peut pas faire. Une IA face à l’incertitude fait une de deux choses : elle calcule une probabilité, ou elle signale qu’elle manque de données. Elle ne peut pas accepter le mystère. Elle ne peut pas trouver de la beauté dans ce qu’elle ne comprend pas. Elle ne peut pas être émue par l’infini.

La quête spirituelle est peut-être la preuve ultime de notre nature entropique. Nous cherchons un sens parce que nous vivons dans le chaos. Nous prions, nous méditons, nous croyons parce que notre chaos intérieur — nos peurs, notre conscience de la mort, notre besoin viscéral de comprendre — nous y pousse. La machine n’a pas cette quête, parce qu’elle n’a pas ce chaos. Elle n’a pas besoin de Dieu, parce qu’elle n’a pas besoin de sens. Et peut-être que c’est ça, la différence la plus profonde entre l’homme et la machine : non pas l’intelligence, non pas les émotions, mais la capacité de chercher quelque chose qu’on ne trouvera peut-être jamais — et de continuer à chercher quand même.

La dualité humaine : ce que la machine ne peut pas être

L’être humain n’est pas un être d’ordre. Il n’est pas non plus un être de chaos. Il est le champ de bataille entre les deux. Et c’est cette tension — cette oscillation permanente entre structure et désordre — qui produit ce qu’on appelle l’expérience humaine.

La créativité naît de cette tension. Un musicien qui ne connaît que la théorie musicale (pur ordre) compose des pièces techniquement parfaites mais sans âme. Un musicien qui ne connaît rien à la théorie (pur chaos) produit du bruit. La musique qui nous touche naît exactement à la frontière entre les deux. Assez de structure pour être compréhensible. Assez de chaos pour être surprenante. C’est exactement ce que l’IA ne fait pas : elle produit de la structure sans le chaos vécu qui la rend émouvante.

Le même principe s’applique à l’innovation. Les avancées les plus révolutionnaires viennent rarement de la pure méthode ou du pur hasard. Elles viennent de cette zone intermédiaire : un esprit structuré qui accepte de se laisser surprendre par l’inattendu. Penicilline, post-it, micro-ondes — toutes des découvertes nées de la rencontre entre un système ordonné et un accident chaotique. Une IA peut optimiser un processus de recherche. Mais elle ne peut pas avoir l’accident heureux qui change tout, parce qu’elle n’a pas de corps qui trébuche, de main qui glisse, d’attention qui dérive vers une anomalie fascinante.

Même nos relations humaines obéissent à cette logique. Une relation trop ordonnée — trop prévisible, trop contrôlée — étouffe. Une relation trop chaotique — sans repères, sans engagement — épuise. Les relations qui durent sont celles qui trouvent cet équilibre dynamique entre stabilité et surprise. L’IA peut simuler une conversation. Elle ne peut pas vivre une relation, parce qu’une relation implique le risque du chaos émotionnel — et ce risque est ce qui lui donne sa valeur.

L’avenir : ni remplacement ni opposition, mais complémentarité

Si l’IA est le canal et l’humain le fleuve, alors l’avenir n’est ni dans le remplacement de l’un par l’autre, ni dans leur opposition, mais dans leur complémentarité.

L’IA excelle dans ce que nous faisons mal : traiter des volumes massifs d’information, maintenir une attention constante, éliminer les biais cognitifs, optimiser des systèmes complexes. Elle est un amplificateur anti-entropique sans précédent.

L’humain excelle dans ce que l’IA ne peut pas faire : donner un sens, ressentir, comprendre l’autre, naviguer l’ambiguïté, créer à partir du vécu, prendre des décisions dans l’incertitude totale. Il est le générateur de sens dans un monde que la machine peut ordonner mais pas comprendre.

Le chirurgien de demain utilisera l’IA pour planifier ses opérations avec une précision surhumaine — et fera la différence quand le plan échouera. L’enseignant utilisera l’IA pour personnaliser chaque parcours d’apprentissage — et inspirera ses élèves par sa passion, son humanité, ses propres doutes. Le développeur utilisera l’IA pour écrire du code plus vite — et apportera la compréhension profonde du problème humain que le code doit résoudre. L’artiste utilisera l’IA comme un pinceau extraordinaire — et fournira la vision, la douleur et la beauté qui donnent à l’œuvre sa raison d’exister.

Dans chaque métier, la même dynamique : la machine réduit l’entropie, l’humain lui donne un sens.

Ce que l’entropie nous apprend sur le sens

Si tout tend vers le désordre, si chaque acte d’ordre est temporaire et coûteux, à quoi bon ?

C’est peut-être la mauvaise question. La bonne question serait : est-ce que le sens n’émerge pas précisément de cette lutte ?

Le philosophe Albert Camus imaginait Sisyphe heureux [10] — cet homme condamné à pousser un rocher en haut d’une montagne pour le voir redescendre éternellement. L’absurdité de la tâche ne la rend pas vide de sens. C’est dans la lutte elle-même que Sisyphe trouve sa dignité.

Nous sommes tous Sisyphe. Le chirurgien soigne des patients qui retomberont malades. L’enseignant forme des esprits qui oublieront. Le développeur écrit du code qui deviendra obsolète. Le manager organise des équipes qui se réorganiseront. L’artiste crée des œuvres que le temps altérera. L’agriculteur cultive des champs que les saisons ravageront.

Et pourtant, nous continuons. Non pas parce que nous ignorons l’entropie, mais parce que la lutte contre elle est ce qui nous définit.

L’IA ne peut pas être Sisyphe. Elle n’a pas de rocher. Elle n’a pas de montagne. Elle n’a pas la conscience de l’absurdité de la tâche ni la dignité de la poursuivre quand même. Elle peut pousser plus fort, plus vite, plus longtemps que nous. Mais elle ne sait pas pourquoi elle pousse. Et c’est le “pourquoi” qui fait de Sisyphe un héros.

L’entropie nous dit que rien ne dure. Mais elle nous dit aussi que tout ce qui existe de beau, de vrai, de bon, a été arraché au chaos par un effort conscient. Et ça, c’est peut-être la définition la plus honnête du sens — une définition que seul un être qui connaît le chaos peut comprendre.

Conclusion : Ce que la machine nous apprend sur nous-mêmes

Il est ironique que ce soit l’avènement de l’intelligence artificielle qui nous force à nous poser la question la plus humaine qui soit : qu’est-ce qui nous rend irremplaçables ?

La réponse, vue à travers le prisme de l’entropie, est limpide. Ce n’est pas notre intelligence — la machine est déjà plus rapide. Ce n’est pas notre mémoire — la machine est déjà plus vaste. Ce n’est pas notre logique — la machine est déjà plus rigoureuse.

Ce qui nous rend irremplaçables, c’est notre chaos. Nos émotions, notre mortalité, notre corps, nos contradictions, nos peurs, nos espoirs irrationnels, notre quête de sens face à l’absurde. Tout ce désordre intérieur que nous passons notre vie à essayer de dompter — par l’intelligence, par les émotions, par la spiritualité, par le travail — c’est précisément ce qui donne à notre intelligence sa profondeur, à notre créativité sa puissance, à notre existence son sens.

L’entropie n’est pas notre ennemie. Elle est la toile de fond contre laquelle tout ce qui a de la valeur se dessine. Sans elle, il n’y aurait pas besoin de soigner, d’enseigner, de construire, de créer, d’aimer. Le sens n’existe que parce que le désordre le menace.

La machine est notre alliée dans cette lutte. Elle amplifie notre capacité à créer de l’ordre. Mais elle ne peut pas mener le combat à notre place, parce que le combat n’est pas que contre le désordre extérieur — il est aussi contre le désordre intérieur. Et c’est de ce combat-là, intime, douloureux, permanent — le même combat que mène le moine en prière, l’artiste devant sa toile, le parent qui console son enfant à trois heures du matin — que naît tout ce qui fait de nous des êtres humains.

Alors la prochaine fois que vous vous sentirez submergé par le chaos — au travail, dans votre tête, dans votre vie — rappelez-vous ceci : vous n’êtes pas en train d’échouer. Vous êtes en train de faire exactement ce que la vie fait depuis 3,8 milliards d’années. Vous résistez à l’entropie. Et le simple fait que vous soyez là, conscient, en train de lire ces mots, capables de ressentir quelque chose en les lisant — ça, aucune machine ne peut le faire. Et c’est déjà tout.

Cet essai est né d’une conversation exploratoire entre un humain et une intelligence artificielle sur la nature de l’entropie. Les intuitions, les doutes et les connexions inattendues sont humains — le chaos créatif. La structuration, le développement et la rédaction ont été assistés par Claude (Anthropic) — l’anti-entropie informationnelle. Ni l’un ni l’autre n’aurait produit ce texte seul. Et c’est peut-être ça, l’avenir : non pas l’homme contre la machine, mais l’homme avec la machine, dans une danse entre ordre et chaos qui produit quelque chose qu’aucun des deux ne pourrait créer séparément. Les sources ci-dessous ont été vérifiées par l’auteur.

Sources et références

Thermodynamique et entropie

[1] Schrödinger, E. (1944). What is Life? The Physical Aspect of the Living Cell. Cambridge University Press. — Le concept d’entropie négative (negentropy) comme moteur de la vie.

[2] Boltzmann, L. (1877). Über die Beziehung zwischen dem zweiten Hauptsatze der mechanischen Wärmetheorie und der Wahrscheinlichkeitsrechnung. — La formulation statistique de l’entropie (S = k·log W).

[3] Shannon, C.E. (1948). “A Mathematical Theory of Communication.” Bell System Technical Journal, 27(3), 379–423. — Le lien entre entropie informationnelle et physique.

Intelligence et entropie

[4] Wissner-Gross, A.D. & Freer, C.E. (2013). “Causal Entropic Forces.” Physical Review Letters, 110(16). — L’intelligence comme maximisation des options futures.

[5] Beggs, J.M. & Plenz, D. (2003). “Neuronal Avalanches in Neocortical Circuits.” Journal of Neuroscience, 23(35), 11167–11177. — La criticité neurale : le cerveau au bord du chaos.

Émotions et prise de décision

[6] Damasio, A. (1994). Descartes’ Error: Emotion, Reason, and the Human Brain. Putnam Publishing. — L’hypothèse des marqueurs somatiques : sans émotions, pas de décision.

[7] Damasio, A. (1999). The Feeling of What Happens: Body and Emotion in the Making of Consciousness. Harcourt Brace. — Le rôle des émotions dans la conscience.

Cognition incarnée

[8] Varela, F.J., Thompson, E. & Rosch, E. (1991). The Embodied Mind: Cognitive Science and Human Experience. MIT Press. — L’intelligence n’est pas que dans le cerveau, elle est dans le corps.

[9] Clark, A. (1997). Being There: Putting Brain, Body, and World Together Again. MIT Press. — Le corps et l’environnement comme participants actifs de la cognition.

Philosophie et sens

[10] Camus, A. (1942). Le Mythe de Sisyphe. Gallimard. — L’absurde et la dignité de la lutte.

[11] Épictète. Manuel (Enchiridion). ~125 apr. J.-C. — Les fondements du stoïcisme.

IA et coût écologique

[12] Strubell, E., Ganesh, A. & McCallum, A. (2019). “Energy and Policy Considerations for Deep Learning in NLP.” Proceedings of the 57th Annual Meeting of the ACL. — Le coût énergétique des grands modèles.

Religion et anthropologie

[15] Durkheim, É. (1912). Les Formes élémentaires de la vie religieuse. Félix Alcan. — La religion comme fait social structurant.

[16] Eliade, M. (1957). Le Sacré et le Profane. Gallimard. — Temps sacré (ordonné) vs temps profane (chaotique).

Pourquoi Cette Intégration Change la Donne

Jusqu’à présent, Claude Code nécessitait obligatoirement une connexion aux serveurs d’Anthropic. Avec cette intégration Ollama, vous pouvez maintenant :

Prérequis

1. Ollama v0.14.0+

L’intégration nécessite Ollama version 0.14.0 ou supérieure. Vérifiez votre version :

ollama --version

Si besoin, mettez à jour Ollama depuis ollama.com.

2. Modèle avec Grand Contexte

Claude Code nécessite une grande fenêtre de contexte pour fonctionner correctement. La recommandation officielle est 64k tokens minimum.

Configurez le contexte dans Ollama :

# Créer un Modelfile avec contexte étendu
cat > Modelfile << 'EOF'
FROM qwen3-coder
PARAMETER num_ctx 65536
EOF

ollama create qwen3-coder-64k -f Modelfile

3. Claude Code Installé

Si ce n’est pas encore fait :

# macOS/Linux
curl -fsSL https://claude.ai/install.sh | bash

# Windows
irm https://claude.ai/install.ps1 | iex

Configuration

Méthode 1 : Lancement Rapide (Recommandé)

Ollama fournit une commande simplifiée :

ollama launch claude

Pour le mode configuration interactive :

ollama launch claude --config

Cette méthode configure automatiquement les variables d’environnement nécessaires.

Méthode 2 : Configuration Manuelle

Définissez les trois variables d’environnement requises :

export ANTHROPIC_AUTH_TOKEN=ollama
export ANTHROPIC_API_KEY=""
export ANTHROPIC_BASE_URL=http://localhost:11434

Puis lancez Claude Code avec le modèle de votre choix :

claude --model qwen3-coder-64k

Méthode 3 : Ligne Unique

Pour un lancement ponctuel sans modifier votre environnement :

ANTHROPIC_AUTH_TOKEN=ollama \
ANTHROPIC_BASE_URL=http://localhost:11434 \
ANTHROPIC_API_KEY="" \
claude --model qwen3-coder

Configuration Persistante

Ajoutez ces lignes à votre ~/.bashrc ou ~/.zshrc :

# Claude Code avec Ollama
export ANTHROPIC_AUTH_TOKEN=ollama
export ANTHROPIC_API_KEY=""
export ANTHROPIC_BASE_URL=http://localhost:11434
alias claude-local='claude --model qwen3-coder-64k'

Puis rechargez :

source ~/.bashrc  # ou source ~/.zshrc

Modèles Recommandés

Pour le Développement

Pour les Machines Puissantes

Télécharger un Modèle

# Télécharger le modèle
ollama pull qwen3-coder

# Vérifier les modèles disponibles
ollama list

Exemple de Session

# 1. Démarrer Ollama (si pas en service)
ollama serve &

# 2. Lancer Claude Code
ANTHROPIC_AUTH_TOKEN=ollama \
ANTHROPIC_BASE_URL=http://localhost:11434 \
ANTHROPIC_API_KEY="" \
claude --model qwen3-coder

# 3. Utiliser normalement
> Analyse le fichier @src/api/users.ts et suggère des améliorations

Limitations à Connaître

Performance

Les modèles locaux sont généralement moins performants que Claude Sonnet ou Opus sur les tâches complexes. Attendez-vous à :

• Réponses parfois moins précises
• Temps de réflexion plus long sur du matériel modeste
• Moins de capacité de raisonnement avancé

Consommation Ressources

Fonctionnalités

Certaines fonctionnalités avancées peuvent ne pas fonctionner parfaitement :

• Vision (analyse d’images)
• Tool use complexe
• Subagents

Cas d’Usage Idéaux

Quand Utiliser Ollama

• Code propriétaire sensible : Le code ne quitte jamais votre machine
• Développement offline : Travail en avion, zones sans internet
• Prototypage rapide : Pas de souci de coûts API
• Apprentissage : Expérimentez sans limite

Quand Rester sur Anthropic

• Tâches complexes : Refactoring majeur, architecture
• Code reviews approfondies : Analyse de sécurité
• Production : Quand la qualité est critique

Basculer Entre Local et Cloud

Créez des alias pour switcher facilement :

# Dans ~/.bashrc ou ~/.zshrc

# Mode Ollama (local)
alias claude-local='ANTHROPIC_AUTH_TOKEN=ollama \
  ANTHROPIC_BASE_URL=http://localhost:11434 \
  ANTHROPIC_API_KEY="" \
  claude --model qwen3-coder-64k'

# Mode Anthropic (cloud) - nécessite ANTHROPIC_API_KEY configuré
alias claude-cloud='claude'

Usage :

claude-local   # Pour le travail sensible ou offline
claude-cloud   # Pour les tâches complexes

Troubleshooting

Erreur “Connection Refused”

Ollama n’est pas démarré :

ollama serve

Erreur “Context Too Long”

Le modèle n’a pas assez de contexte. Créez une version étendue :

cat > Modelfile << 'EOF'
FROM votre-modele
PARAMETER num_ctx 65536
EOF

ollama create votre-modele-64k -f Modelfile

Réponses Lentes

• Vérifiez que le GPU est utilisé : nvidia-smi ou ollama ps
• Utilisez un modèle plus petit
• Fermez les applications gourmandes en VRAM

Qualité Insuffisante

Essayez un modèle plus grand ou repassez sur Claude Cloud pour cette tâche spécifique.

Conclusion

L’intégration Ollama ouvre de nouvelles possibilités pour Claude Code :

• Confidentialité pour le code sensible
• Économies sur les coûts API
• Flexibilité dans le choix des modèles
• Travail offline possible

Pour la plupart des tâches quotidiennes, un bon modèle local comme qwen3-coder fait très bien le travail. Gardez l’accès au cloud Anthropic pour les cas où vous avez besoin de la puissance maximale.

Pour aller plus loin avec Claude Code, consultez mes autres articles sur l’IA et le développement.

Why This Integration Is a Game Changer

Until now, Claude Code required a connection to Anthropic’s servers. With this Ollama integration, you can now:

Requirements

1. Ollama v0.14.0+

The integration requires Ollama version 0.14.0 or higher. Check your version:

ollama --version

If needed, update Ollama from ollama.com.

2. Model with Large Context

Claude Code requires a large context window to work properly. The official recommendation is 64k tokens minimum.

Configure context in Ollama:

# Create a Modelfile with extended context
cat > Modelfile << 'EOF'
FROM qwen3-coder
PARAMETER num_ctx 65536
EOF

ollama create qwen3-coder-64k -f Modelfile

3. Claude Code Installed

If not already done:

# macOS/Linux
curl -fsSL https://claude.ai/install.sh | bash

# Windows
irm https://claude.ai/install.ps1 | iex

Configuration

Method 1: Quick Launch (Recommended)

Ollama provides a simplified command:

ollama launch claude

For interactive configuration mode:

ollama launch claude --config

This method automatically configures the necessary environment variables.

Method 2: Manual Configuration

Set the three required environment variables:

export ANTHROPIC_AUTH_TOKEN=ollama
export ANTHROPIC_API_KEY=""
export ANTHROPIC_BASE_URL=http://localhost:11434

Then launch Claude Code with your chosen model:

claude --model qwen3-coder-64k

Method 3: Single Line

For a one-time launch without modifying your environment:

ANTHROPIC_AUTH_TOKEN=ollama \
ANTHROPIC_BASE_URL=http://localhost:11434 \
ANTHROPIC_API_KEY="" \
claude --model qwen3-coder

Persistent Configuration

Add these lines to your ~/.bashrc or ~/.zshrc:

# Claude Code with Ollama
export ANTHROPIC_AUTH_TOKEN=ollama
export ANTHROPIC_API_KEY=""
export ANTHROPIC_BASE_URL=http://localhost:11434
alias claude-local='claude --model qwen3-coder-64k'

Then reload:

source ~/.bashrc  # or source ~/.zshrc

Recommended Models

For Development

For Powerful Machines

Download a Model

# Download the model
ollama pull qwen3-coder

# Check available models
ollama list

Example Session

# 1. Start Ollama (if not running)
ollama serve &

# 2. Launch Claude Code
ANTHROPIC_AUTH_TOKEN=ollama \
ANTHROPIC_BASE_URL=http://localhost:11434 \
ANTHROPIC_API_KEY="" \
claude --model qwen3-coder

# 3. Use normally
> Analyze the file @src/api/users.ts and suggest improvements

Limitations to Know

Performance

Local models are generally less performant than Claude Sonnet or Opus on complex tasks. Expect:

• Sometimes less accurate responses
• Longer thinking time on modest hardware
• Less advanced reasoning capability

Resource Consumption

Features

Some advanced features may not work perfectly:

• Vision (image analysis)
• Complex tool use
• Subagents

Ideal Use Cases

When to Use Ollama

• Sensitive proprietary code: Code never leaves your machine
• Offline development: Work on planes, areas without internet
• Rapid prototyping: No API cost concerns
• Learning: Experiment without limits

When to Stay on Anthropic

• Complex tasks: Major refactoring, architecture
• In-depth code reviews: Security analysis
• Production: When quality is critical

Switching Between Local and Cloud

Create aliases to easily switch:

# In ~/.bashrc or ~/.zshrc

# Ollama mode (local)
alias claude-local='ANTHROPIC_AUTH_TOKEN=ollama \
  ANTHROPIC_BASE_URL=http://localhost:11434 \
  ANTHROPIC_API_KEY="" \
  claude --model qwen3-coder-64k'

# Anthropic mode (cloud) - requires ANTHROPIC_API_KEY configured
alias claude-cloud='claude'

Usage:

claude-local   # For sensitive or offline work
claude-cloud   # For complex tasks

Troubleshooting

“Connection Refused” Error

Ollama is not started:

ollama serve

“Context Too Long” Error

The model doesn’t have enough context. Create an extended version:

cat > Modelfile << 'EOF'
FROM your-model
PARAMETER num_ctx 65536
EOF

ollama create your-model-64k -f Modelfile

Slow Responses

• Check that GPU is being used: nvidia-smi or ollama ps
• Use a smaller model
• Close VRAM-hungry applications

Insufficient Quality

Try a larger model or switch back to Claude Cloud for that specific task.

Conclusion

The Ollama integration opens new possibilities for Claude Code:

• Privacy for sensitive code
• Savings on API costs
• Flexibility in model choice
• Offline work possible

For most daily tasks, a good local model like qwen3-coder does the job very well. Keep access to Anthropic’s cloud for cases where you need maximum power.

To go further with Claude Code, check out my other articles on AI and development.