Pourquoi les “AI harness” deviennent plus importants que les modèles eux-mêmes

Depuis quelques mois, un nouveau terme revient partout dans l’écosystème IA : le “harness”. Derrière ce mot un peu technique se cache pourtant une idée centrale dans l’évolution des agents IA modernes. Et parmi les projets qui cristallisent cette tendance, il y a Pi.

Pi se présente comme un “minimal terminal coding harness”. Dit autrement : une couche logicielle légère qui transforme un modèle de langage en véritable agent opérationnel.

Le point important, c’est que Pi ne cherche pas à être un simple chatbot. Son rôle est d’orchestrer le travail du modèle : accès aux fichiers, exécution de commandes, gestion du contexte, historique, extensions, workflows, mémoire, outils externes, etc.

Et aujourd’hui, c’est précisément cette couche d’orchestration qui devient stratégique.

Qu’est-ce qu’un harness IA exactement ?

Un modèle comme GPT-5, Claude ou Gemini sait générer du texte. Mais seul, il ne “fait” presque rien.

Le harness est la structure qui entoure le modèle pour lui permettre d’agir :

• lire et modifier des fichiers ;
• lancer des commandes shell ;
• gérer des sessions ;
• mémoriser un contexte ;
• appeler des outils ;
• changer de modèle dynamiquement ;
• appliquer des règles de sécurité ;
• orchestrer plusieurs étapes de travail.

Sur Reddit et dans les communautés open source, beaucoup résument le harness comme “le système qui transforme un LLM en agent”.

En pratique, le modèle devient le moteur, mais le harness devient le systèm d’exploitation.

Pourquoi Pi attire autant l’attention ?

Pi adopte une approche radicalement minimaliste. Là où beaucoup d’outils IA deviennent des “IDE géants”, Pi veut rester petit au cœur et extensible autour.

Le projet fournit seulement quelques primitives essentielles :

• read
• write
• edit
• bash

Puis tout le reste est construit via des extensions TypeScript, des templates, des skills ou des packages.

Cette philosophie est importante car elle inverse la logique habituelle :

au lieu d’imposer un workflow au développeur, Pi laisse le développeur construire son propre workflow.

C’est une différence majeure avec des solutions plus fermées comme OpenAI Codex, Anthropic Claude Code ou certains IDE IA très intégrés.

Pourquoi le harness compte parfois plus que le modèle ?

C’est probablement le point le plus sous-estimé aujourd’hui.

Beaucoup pensent encore que toute la valeur vient du LLM. En réalité, deux équipes utilisant exactement le même modèle peuvent obtenir des résultats radicalement différents selon le harness utilisé.

Pourquoi ?

Parce qu’une énorme partie de la performance agentique dépend de :

• la gestion du contexte ;
• les outils disponibles ;
• la mémoire ;
• la capacité à découper les tâches ;
• la sécurité ;
• le routage entre modèles ;
• les prompts système ;
• les boucles de validation ;
• les workflows d’exécution.

Pi insiste justement sur cette idée de “context engineering”.

Aujourd’hui, un bon harness peut parfois compenser un modèle plus faible.

À l’inverse, un excellent modèle mal orchestré produit souvent des agents incohérents, coûteux ou instables. Cela ramène à la discussion de l’importance du contexte, et cela a toujours été depuis le début, rien de nouveau. Même quand vous promptez l’IA sur le web, vous définissez un bon contexte pour que la réponse soit la plus précise, et le prompt engineering des début s’appuyait sur la maitrise du prompt (une abondante littérature sur les différentes technique de prompting existe, à mon avis inutile de s’embarasser des dizaines et des dizaines de technique c’est du marketing)

Quels autres harness existent ?

Pi n’est pas seul.

On voit émerger plusieurs familles de harness IA :

OpenCode, OpenHands, Continue.dev,Cline,Cursor,OpenClaw

Chaque projet fait des choix différents :
minimalisme, autonomie, sandboxing, multi-agents, mémoire persistante, IDE intégré ou CLI terminal.

Le marché semble d’ailleurs évoluer vers une commoditisation des modèles eux-mêmes. Les différences entre GPT, Claude, Gemini ou Qwen se réduisent progressivement sur certaines tâches.

Le véritable avantage compétitif se déplace donc vers :

• le harness ;
• les workflows ;
• les outils ;
• l’intégration ;
• l’expérience développeur.

Autrement dit : le futur des agents IA ne se jouera pas uniquement sur “quel modèle utiliser”, mais surtout sur “comment le piloter”.

Je vous avais parlé de Ollama, par le passé, mais Ollama utilise un moteur d’inférence qui est llama.cpp, le vrai; Ollama n’est qu’une interface visuelle construite par dessus llama.cpp .

Et pour des questions d eperformance, je vous conseille de le prendre plutôt que d’utiliser Ollama qui est plutôt pour un public larger. Entant que codeur, il faut utilise llama.cpp.

Installation de llama.cpp

Allez d’abord le télécharger, en ce qui me concerne je suis sous Windows, donc je vais utiliser WSL. Il faut le savoir en matière d’intelligence artificielle il vaut mieux utiliser Linux.

Il existe plein de sites qui permettent de le télécharger, la source officielle de llama.cpp, mais aussi ce site qui explique bien comment il faut faire pour installer llama.cpp.

Installer llama.cpp n’est que la première partie du travail, il faudra après son installation télécharger les modèles LLM opensource.

Il y a 2 options pour installer llama.cpp sous Windows, la première option nécessite d’avoir Visual Studio (et non VS Code), la seconde pour moi est plus simple , est d’installer sous WSL ce qui nous ramène à un système Linux (souvenez vous en matière d’IA Linux est bien mieux).

On part sur l’option 2 avec WSL, si vous ne l’avez pas encore installé :

wsl --install

Puis:
sudo apt update
sudo apt install git build-essential cmake

puis clonez le projet llamacpp:
git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp

cmake -B build
cmake --build build

puis attendez un moment (le processus de compilation est assez lent)
Voilà vous êtes prêt maintenant !

Les modèles LLM GGUF

Ce sont des modèles faits pour tourner en local, Hugging Face en héberges milliers de tous type : textuel, image, vidéo.

Vous devez avoir une carte graphique au minimum de 8GB de VRAM, ce qui vous permet d’avoir des modèles génératifs qui tiennent un peu la route. Moi j’ai une carte de 16 GB, donc je peux avoir des modèles un peu plus grand. Mais alors il faut s’attarder sur la notion de paramètre dans les modèles LLM. Plus le nombre de paramètres est grand plus le modèle est performant normalement.

Les modèles LLM non GGUF, les modèles d’origine qui tournent dans les info cloud sont au format .safetensors, .bin ou .pth. Il faut beaucoup de VRAM (volatil RAM la RAM des cartes graphique à la différence de la RAM du CPU)pour les faire tourner. La configuration est plus complexe avec des ichier config/tokenizer, setup CUDA pénible parfois.

Le format GGUF résout tous ces problèmes ça tombe bien pour nous c’est plus facile à mettre en oeuvre. Un modèle LLM de 500B (500 milliards de paramètre en 8 bits) nécessite 550 giga de RAM. Nous on va faire tourner des modèle 8 bits plus petits, à 8B, 12B, en 8 bits, donc ma carte 5060 à 16GB de VRAM suffit.

Pour savoir combien de Giga de VRAM il faut pour faire tourner un modèle 8bit, 1 milliard (1B B comme billions milliard en anglais) de paramètre nécessite 1 giga de VRAM. Il existe des modèle dégradé en 4 bits, dit des modèle quantizé, en passant de 8 bits à 4 bits, on divise par deux la taille des modèle, donc ma carte de 16 GB de VRAM peut faire tourner un modèle 32B en 4 bits.

Les modèles quantizés sont moins performant mais pas de moitié, en passant de 8 bits à 4 bit, on dégrade de 30% les performances d’inférence.

GGUF met dans un seul fichier les poids du modèle, le tokenizer, les metadatas, et paramètres d’inférence dans un seul fichier, c’est plus facile à mettre en oeuvre. Voir cet article plus en détail sur ces propriétés dans le GGUF.

Télécharger un modèle LLM

Si vous avez suivi l’installation dans WSL, votre installation de llama.cpp doit se trouver dans le répertoire suivant :

/mnt/c/Users/<user>/llama.cpp/build/bin/

et dans ce répertoire vous avez llama-cli, et llama-server

Il est conseillé d'installer huggingface-hub

pip install huggingface-hub

et ensuite on télécharge un fichier GGUF (le LLM), avec 16 GB un des meilleur modèle est celui de Mistral 7B, c'est un peu décevant mais si on télécharge un modèle plus grand que la VRAM (16GB), ça plante :$

Mais avant on vérifie que python et pip sont bien  ceux de WSL

which python3
which pip3

si l'une des commande retourne */pyenv-win/* dans le chemin, c'est qu'on n'est pas 100% Linux, dans mon cas c'était pip qui était pas Linux, mais Python était bien Linux

on doit faire cette commande pour installer pip :
python3 -m pip install huggingface-hub --break-system-packages

si la lligne ci-dessus ne marche pas il faut installer pip

sudo apt install python3-pip

puis refaire :
python3 -m pip install huggingface-hub --break-system-packages

Téléchargement du modèle Mistral

Vérifiez que le répertoire ~/models existe sinon faite
mkdir -p ~/models


wget https://huggingface.co/bartowski/Mistral-7B-Instruct-v0.3-GGUF/resolve/main/Mistral-7B-Instruct-v0.3-Q8_0.gguf \
  -O ~/models/mistral-7b-q8.gguf

Ensuite une fois installé lancez :

~/llama.cpp/build/bin/llama-server \
  -m ~/models/mistral-7b-q8.gguf \
  -c 4096 \
  --port 8080

Et dans un autre terminal faites :
curl http://localhost:8080/health

vous devriez avoir en réponse :
{"status":"ok"}

Comment fait on pour avoir une interface friendly?

Il va falloir installer par exemple OpenWebUI, mais je trouve que c’est plus facile d’installer OpenWebUI dans un Docker aussi, je suppose que vous avez installé Docker Desktop:

docker run -d \
  --name open-webui \
  --add-host=host.docker.internal:host-gateway \
  -e OPENAI_API_BASE_URL=http://host.docker.internal:8080/v1 \
  -e OPENAI_API_KEY=fake \
  -p 3000:8080 \
  ghcr.io/open-webui/open-webui:main

Ensuite on ouvre le navigateur au http://localhost:3000  (il faut avoir lancé llama-server.

une fosi le docker en place
docker logs open-webui
pour le monitorer, quand on voit Uvicorn running, on ouvre sur l'hôte http://localhost:3000

Les poids d’un modèle

C’est le cerveau appris du LLM.

Pendant l’entraînement, le modèle apprend des milliards de paramètres numériques (des matrices de nombres flottants).

vecteur stockant les nombre
[0.2381, -1.442, 0.882]

Un modèle 7B contient 7 milliards de ces paramètres, un modèle 70B contient 70 milliards de ces paramètres ….

Ces poids servent dans les couches du transformer :

embedding
attention
feed forward layers
output layers

Lorsqu’on écrit dans le prompt un texte comme « Bonjour comment vas tu? » ce que fait llama.cpp :

• transforme le texte en tokens
• fait passer ces tokens dans les couches du réseau de neurones
• applique les poids à chaque étape
• prédit le token suivant

Les poids sont stockés sous forme de tensors dans GGUF

blk.0.attn_q.weight
blk.0.attn_k.weight
blk.0.ffn_up.weight

./llama-cli -m model.gguf

la commande ci-dessus li les tensors en mémoire RAM/VRAM

Tokenizer

Le LLM ne comprend pas le texte brut, mais les token, docn il faut tokenizer les textes.

"Bonjour tout le monde" peut devenir
[5321, 884, 921]

Le tokenizer définit

• le vocabulaire
• le mapping texte-> id
• le mapping id -> texte

./llama-cli -m model.gguf -p "hello"

llama.cpp tokenize "hello"
envoit les ids au modèle
reçoit des ids du model
reconvertit en texte

Metadatas

Une metadata est une données sur la données, dans notre cas, c’est la carte d’identité du modèle

architecture
nombre de couches
taille contexte
type de modèle
version tokenizer
quantization utilisée

Exemple:
architecture = llama
context_length = 8192
embedding_length = 4096
block_count = 32

La commande
./llama-cli -m model.gguf
sort ces données à l'écran

Paramètres d’inférence

Ce ne sont PAS les poids entraînés. Ce sont les réglages au moment où tu fais générer du texte.

./llama-cli \
  -m model.gguf \
  --temp 0.7 \
  --top-k 40 \
  --top-p 0.9

Température

Controle l’aléatoire, plus c’est élevé (proche de 1) plus c’est créatif

top-k

Le modèle garde uniquement les K tokens les plus probables.

top-k = 40   choisit parmi les 40 meilleurs candidats

top-p

Il garde les tokens jusqu’à atteindre X% de probabilité cumulée.

contexte size

C’est la fenêtre de contexte, la mémoire du LLM.

En résumé :

• poids = connaissances du modèle
• tokenizer = traduction texte ↔ tokens
• metadata = mode d’emploi du modèle
• paramètres d’inférence = réglages runtime dans llama.cpp

Comment sont les modèle avant quantization?

Le standard d’origine est sur 16 bits FP16. La majorité des modèles open source sont entrainés et distribués en

• FP16 16-bit floatingpoint
• parfois en BF16 (bfloat 16) surtout en entrainement

Ainsi en ordre de grandeur, un modèle LLM 7B en FP16 nécessite 14 Go (7B x 16 bits ou 2 bytes), un modèle 70B nécessite en FP16 nécessite 140 Go, 70 Go en 8 bits, et 35 Go en 4bits, cette dernière quantization est intéressante, car elle met à notre portée des modèle 70B pour du matériel comme la RTX 3090 (24 GB de VRAM), il faut 2 carte graphique et ça fera 48 GB de VRAM.

Modèle dense VS modèle sparse (mixture of Experts)

Dans le contexte des LLM locaux avec llama.cpp, la différence est surtout : combien de paramètres sont réellement utilisés à chaque token généré.

Les modèles denses

Ce sont les modèles classiques, Mistral, Llama, Qwen, à chaque prompt chaque token passe par toutes les couches et tous les paramètres concernés. Sur un modèle à 7B de paramètres, presque les 7 milliards de paramètre sont sollicités théoriquement (hors optimisation).

Les mixture of experts (MoE)

Le modèle contient plusieurs experts, tous ne sont pas activés en même temps, cela dépend du prompt un routeur choisit quels experts utiliser selon le token. Exemple le modèle Mistral AI Mixtral 8x7B. Théoriquement ce modèle a 56B paramètres, seul12 à 14B sont actifs par token.

Le MoE est intéressant en local car le coput d’inférence est plus bas qu’un modèle dense équivalent. Ainsi le coput d’un 56B est en fait celui d’un 12 ou 14B/

Mais attention vous devez charger tous els poids en VRAM. Qu’est ce qu’on y gagne alors? On y gagne en vitesse de calcul relative, intelligence et capacité, mais la taille on n’y gagne pas.

Je suppose que vous avez installé Obsidian

Démarrez Obsidian, commencez par créer un coffre (vault en anglais), liez le coffre à un répertoire. Pour ma part je choisis VeilleIA.

Ouvrez pour ce tutoriel le dossier VeilleIA pour voir les fichier sui sont automatiquement créés

Ensuite depuis le terminal de VScode ou directement dans un terminal à l’endroit où se trouve le répertoire VeilleIA.

Initialisation du wiki augmenté à Claude

Copie de la méthode détaillé pour faire de Obsidian votre second cerveau. Andrej Karpathya écrit un texte très populaire où il se sert de Obsidian et des ses fichier markdown comme mémoire de LLM (claude ici en particuliers). Le problème majeur des LLM est qu’ils n’ont pas de mémoire, il faut leur rappeler souvent le contexte. Disposer d’un ensemble de fichier LLM en guise de mémoire est très intéressant, pour avoir un bon assistant IA.

Son texte se trouve ici. Nous allons copier ce texte où il décrit sa méthode et le donner à manger à Claude. Cliquez sur raw en haut à droite pour avoir le bon texte.

# LLM Wiki

A pattern for building personal knowledge bases using LLMs.

This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.

## The core idea

Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.

The idea here is different. Instead of just retrieving from raw documents at query time, the LLM **incrementally builds and maintains a persistent wiki** — a structured, interlinked collection of markdown files that sits between you and the raw sources. When you add a new source, the LLM doesn't just index it for later retrieval. It reads it, extracts the key information, and integrates it into the existing wiki — updating entity pages, revising topic summaries, noting where new data contradicts old claims, strengthening or challenging the evolving synthesis. The knowledge is compiled once and then *kept current*, not re-derived on every query.

This is the key difference: **the wiki is a persistent, compounding artifact.** The cross-references are already there. The contradictions have already been flagged. The synthesis already reflects everything you've read. The wiki keeps getting richer with every source you add and every question you ask.

You never (or rarely) write the wiki yourself — the LLM writes and maintains all of it. You're in charge of sourcing, exploration, and asking the right questions. The LLM does all the grunt work — the summarizing, cross-referencing, filing, and bookkeeping that makes a knowledge base actually useful over time. In practice, I have the LLM agent open on one side and Obsidian open on the other. The LLM makes edits based on our conversation, and I browse the results in real time — following links, checking the graph view, reading the updated pages. Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.

This can apply to a lot of different contexts. A few examples:

- **Personal**: tracking your own goals, health, psychology, self-improvement — filing journal entries, articles, podcast notes, and building up a structured picture of yourself over time.
- **Research**: going deep on a topic over weeks or months — reading papers, articles, reports, and incrementally building a comprehensive wiki with an evolving thesis.
- **Reading a book**: filing each chapter as you go, building out pages for characters, themes, plot threads, and how they connect. By the end you have a rich companion wiki. Think of fan wikis like [Tolkien Gateway](https://tolkiengateway.net/wiki/Main_Page) — thousands of interlinked pages covering characters, places, events, languages, built by a community of volunteers over years. You could build something like that personally as you read, with the LLM doing all the cross-referencing and maintenance.
- **Business/team**: an internal wiki maintained by LLMs, fed by Slack threads, meeting transcripts, project documents, customer calls. Possibly with humans in the loop reviewing updates. The wiki stays current because the LLM does the maintenance that no one on the team wants to do.
- **Competitive analysis, due diligence, trip planning, course notes, hobby deep-dives** — anything where you're accumulating knowledge over time and want it organized rather than scattered.

## Architecture

There are three layers:

**Raw sources** — your curated collection of source documents. Articles, papers, images, data files. These are immutable — the LLM reads from them but never modifies them. This is your source of truth.

**The wiki** — a directory of LLM-generated markdown files. Summaries, entity pages, concept pages, comparisons, an overview, a synthesis. The LLM owns this layer entirely. It creates pages, updates them when new sources arrive, maintains cross-references, and keeps everything consistent. You read it; the LLM writes it.

**The schema** — a document (e.g. CLAUDE.md for Claude Code or AGENTS.md for Codex) that tells the LLM how the wiki is structured, what the conventions are, and what workflows to follow when ingesting sources, answering questions, or maintaining the wiki. This is the key configuration file — it's what makes the LLM a disciplined wiki maintainer rather than a generic chatbot. You and the LLM co-evolve this over time as you figure out what works for your domain.

## Operations

**Ingest.** You drop a new source into the raw collection and tell the LLM to process it. An example flow: the LLM reads the source, discusses key takeaways with you, writes a summary page in the wiki, updates the index, updates relevant entity and concept pages across the wiki, and appends an entry to the log. A single source might touch 10-15 wiki pages. Personally I prefer to ingest sources one at a time and stay involved — I read the summaries, check the updates, and guide the LLM on what to emphasize. But you could also batch-ingest many sources at once with less supervision. It's up to you to develop the workflow that fits your style and document it in the schema for future sessions.

**Query.** You ask questions against the wiki. The LLM searches for relevant pages, reads them, and synthesizes an answer with citations. Answers can take different forms depending on the question — a markdown page, a comparison table, a slide deck (Marp), a chart (matplotlib), a canvas. The important insight: **good answers can be filed back into the wiki as new pages.** A comparison you asked for, an analysis, a connection you discovered — these are valuable and shouldn't disappear into chat history. This way your explorations compound in the knowledge base just like ingested sources do.

**Lint.** Periodically, ask the LLM to health-check the wiki. Look for: contradictions between pages, stale claims that newer sources have superseded, orphan pages with no inbound links, important concepts mentioned but lacking their own page, missing cross-references, data gaps that could be filled with a web search. The LLM is good at suggesting new questions to investigate and new sources to look for. This keeps the wiki healthy as it grows.

## Indexing and logging

Two special files help the LLM (and you) navigate the wiki as it grows. They serve different purposes:

**index.md** is content-oriented. It's a catalog of everything in the wiki — each page listed with a link, a one-line summary, and optionally metadata like date or source count. Organized by category (entities, concepts, sources, etc.). The LLM updates it on every ingest. When answering a query, the LLM reads the index first to find relevant pages, then drills into them. This works surprisingly well at moderate scale (~100 sources, ~hundreds of pages) and avoids the need for embedding-based RAG infrastructure.

**log.md** is chronological. It's an append-only record of what happened and when — ingests, queries, lint passes. A useful tip: if each entry starts with a consistent prefix (e.g. `## [2026-04-02] ingest | Article Title`), the log becomes parseable with simple unix tools — `grep "^## \[" log.md | tail -5` gives you the last 5 entries. The log gives you a timeline of the wiki's evolution and helps the LLM understand what's been done recently.

## Optional: CLI tools

At some point you may want to build small tools that help the LLM operate on the wiki more efficiently. A search engine over the wiki pages is the most obvious one — at small scale the index file is enough, but as the wiki grows you want proper search. [qmd](https://github.com/tobi/qmd) is a good option: it's a local search engine for markdown files with hybrid BM25/vector search and LLM re-ranking, all on-device. It has both a CLI (so the LLM can shell out to it) and an MCP server (so the LLM can use it as a native tool). You could also build something simpler yourself — the LLM can help you vibe-code a naive search script as the need arises.

## Tips and tricks

- **Obsidian Web Clipper** is a browser extension that converts web articles to markdown. Very useful for quickly getting sources into your raw collection.
- **Download images locally.** In Obsidian Settings → Files and links, set "Attachment folder path" to a fixed directory (e.g. `raw/assets/`). Then in Settings → Hotkeys, search for "Download" to find "Download attachments for current file" and bind it to a hotkey (e.g. Ctrl+Shift+D). After clipping an article, hit the hotkey and all images get downloaded to local disk. This is optional but useful — it lets the LLM view and reference images directly instead of relying on URLs that may break. Note that LLMs can't natively read markdown with inline images in one pass — the workaround is to have the LLM read the text first, then view some or all of the referenced images separately to gain additional context. It's a bit clunky but works well enough.
- **Obsidian's graph view** is the best way to see the shape of your wiki — what's connected to what, which pages are hubs, which are orphans.
- **Marp** is a markdown-based slide deck format. Obsidian has a plugin for it. Useful for generating presentations directly from wiki content.
- **Dataview** is an Obsidian plugin that runs queries over page frontmatter. If your LLM adds YAML frontmatter to wiki pages (tags, dates, source counts), Dataview can generate dynamic tables and lists.
- The wiki is just a git repo of markdown files. You get version history, branching, and collaboration for free.

## Why this works

The tedious part of maintaining a knowledge base is not the reading or the thinking — it's the bookkeeping. Updating cross-references, keeping summaries current, noting when new data contradicts old claims, maintaining consistency across dozens of pages. Humans abandon wikis because the maintenance burden grows faster than the value. LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass. The wiki stays maintained because the cost of maintenance is near zero.

The human's job is to curate sources, direct the analysis, ask good questions, and think about what it all means. The LLM's job is everything else.

The idea is related in spirit to Vannevar Bush's Memex (1945) — a personal, curated knowledge store with associative trails between documents. Bush's vision was closer to this than to what the web became: private, actively curated, with the connections between documents as valuable as the documents themselves. The part he couldn't solve was who does the maintenance. The LLM handles that.


## Note

This document is intentionally abstract. It describes the idea, not a specific implementation. The exact directory structure, the schema conventions, the page formats, the tooling — all of that will depend on your domain, your preferences, and your LLM of choice. Everything mentioned above is optional and modular — pick what's useful, ignore what isn't. For example: your sources might be text-only, so you don't need image handling at all. Your wiki might be small enough that the index file is all you need, no search engine required. You might not care about slide decks and just want markdown pages. You might want a completely different set of output formats. The right way to use this is to share it with your LLM agent and work together to instantiate a version that fits your needs. The document's only job is to communicate the pattern. Your LLM can figure out the rest.

Pour chatGPT, afin de donner du contexte à une question, on upload un fichier pdf par exemple, et on demande à chatGPT une question ce dernier saura regarder le pdf pour augmenter son texte, on appelle cela un RAG.

On va procéder différemment ici, car l’approche de Karpathy est de fabriquer un wiki qui s’augmente et se modifie, ce n’est pas seulement une accumulation de fichier, si un fichier n’a qu’une petite part d’information qui peut compléter le wiki (quelque chose de nouveau), seul le texte nouveau sera injecté dans le wiki, il sera analysé, pour voir en quoi il apporte de la valeur (complément, contradiction etc)

Coller le texte de Karpathy et ajouter à côté ce prompt :

You are a LLM Wiki agent. Implement this exact idea file as my complete second brain. create the CLAUDE.md schema file with full rules, set up index.md and log.md, define folder conventions, and show me the first ingest example.

Installer l’extension Obsidian Web Clipper pour convertir une page web en markdown

Imaginez que vous tombiez sur une page web, qui rentre dans le cadre de votre veille IA, comment ajouter le contenu de cette page à votre wiki? le meilleur format pour travailler en IA générative, c’est

Pour convertir en markdown une page, cliquez sur l’icône de l’extension, vous pouvez renommer le fichier à la volée tout en haut de la popup qui apparait, et tout en bas vous désignez le répertoire où va être enregistré le fichier markdown.

Les IA aiment travailler avec le markdown, qui est une alternative au markup (HTML), beaucoup plus dépouillé, mais porteur de valeur sémantique.

Vous allez importer dans le répertoire raw, qui est l’antichambre de vos entités sémantiques du wiki.

Une fois en possession de fichier dans raw, il est temps d’aller dans un terminal ouvert à l’emplacement de votre wiki et d’invoquer Claude Code.

Ajout de commande Claude

Créez un répertoire invisible .claude, puis un sous répertoire commands, et dedans créez 4 fichiers markdown : ingest, query,save,lint.

Mettez dans chaque commande le markdown correspondant.

query

---
description: Ask a question answered from the wiki
argument-hint: <question>
---

Run the QUERY workflow from CLAUDE.md for: $ARGUMENTS

Steps:
1. Read `index.md` to find relevant pages.
2. Read those pages and follow `[[wikilinks]]` as needed.
3. Synthesize an answer with `[[page]]` citations.
4. If the answer is substantive, offer to file it as `wiki/syntheses/<slug>.md`.
5. Append an entry to `log.md`.

save

---
description: File the last response as a synthesis page
argument-hint: [optional-slug]
---

File the previous assistant response into `wiki/syntheses/<slug>.md`.

Slug: $ARGUMENTS (if empty, derive a concise kebab-case slug from the content).

Steps:
1. Write the synthesis page with proper frontmatter (`type: synthesis`, `created`, `updated`, `tags`, `sources`).
2. Preserve `[[wikilinks]]` and add a `## References` section.
3. Update `index.md` to list the new synthesis.
4. Append an entry to `log.md`.

ingest

---
description: Ingest a source from raw/ into the wiki
argument-hint: <path-to-source-in-raw>
---

Run the INGEST workflow from CLAUDE.md on: $ARGUMENTS

Steps:
1. Read the source at $ARGUMENTS (fetch if URL).
2. Discuss 2-5 key takeaways with the user.
3. Create `wiki/sources/YYYY-MM-DD-slug.md` with summary, key claims, entities, concepts, quotes.
4. Create/update entity and concept pages for each mentioned; flag contradictions with `> [!warning]`.
5. Update `index.md`.
6. Append an entry to `log.md`.
7. Report created/updated pages, contradictions, and open questions.

lint

---
description: Lint the wiki for contradictions, orphans, and gaps
argument-hint:
---

Run the LINT workflow from CLAUDE.md.

Report on:
- Contradictions across pages
- Stale claims
- Orphan pages (no inbound links)
- Concepts mentioned without their own page
- Missing cross-references
- Data gaps worth researching

Suggest next sources to ingest.

$ARGUMENTS

C’est ingest que nous allons utiliser en premier. Dans Claude Code tapez /ingest, et il va aller regarder dans le répertoire raw digérer le fichier markdown et les répartir dans les différents répertoire du wiki. Quand c’est fait vous pouvez invoquer la vue graphique en noeud et relations dans Obsidian.

Une fois que c’est fait, vous pouvez requêter le wiki en tapant /query, et posez votre question.

Pourquoi ça marche?

Les IA sont entrainées sur des larges banques de données, mais leurs connaissance se limitent à ces données. Comme c’est une machine statistique, si vous posez une question sur un sujet dont ils n’on t pas eu connaissance, ils vont halluciner, c’est à dire inventer des choses.

Afin d’éviter cela, on leur demande de puiser des données dans des jeux de données complémentaires qui n’ont pas servi à leur entrainement, c’est le RAG (Retrieval Augmented Generation). En gros on va faire une première requête dans la source de connaissance supplémentaire (votre wiki) et envoyer le résultat de cette requête au LLM avec votre question et c’est le LLM qui va finaliser la réponse. Ceci permet de diminuer les hallucinations.

Particularité de la mise en place d’Obsidian avec la méthode de Andrej Karpathy

Ce que nous venons de faire c’est simplement constituer une base de connaissance sur un thème particulier, pas forcément pour du RAG, mais de procurer une mémoire pour vous ! imaginez que vous empiliez des livres de connaissances, mais que vous aimeriez avoir un assistant qui vous livre l’information à votre question, c’est exactement ce que va faire le LLM Claude Code. Avec ce système, chaque fois que vous découvrez une page d’informations nouvelles, vous le donnez à digérer à Claude qui va dispatcher l’information dans le wiki. Avec comme bonus qu’il n’y aura pas de répétition de cette information, et qu’il y a une vérification de si cette nouvelle information risque de contredire l’ancienne. Votre wiki est maintenu par l’IA. Vous n’avez qu’à alimenter en markdown le wiki, très facilement avec l’extension Obsidian Web Clipper.

Avoir un wiki évolutif, sur lequel on peut requêter pour avoir l’information très rapidement, une information curatée, c’est précisément pour cette raison qu’on appelle ce système un second cerveau.

Claude Code : Guide d’installation et prise en main rapide

L’assistant IA qui travaille directement dans votre terminal, au cœur de votre code.

---

Qu’est-ce que Claude Code ?

Claude Code est l’outil en ligne de commande d’Anthropic qui transforme votre terminal en assistant de développement intelligent. Contrairement à un simple chatbot, Claude Code lit votre codebase, comprend le contexte de votre projet, écrit du code, exécute des commandes, modifie des fichiers et itère — tout cela sous votre contrôle. Que vous soyez développeur expérimenté ou que vous débutiez, il s’intègre à votre workflow sans friction.

---

Prérequis

Avant d’installer Claude Code, vérifiez deux points :

• Un compte Claude.ai avec un abonnement Pro ou Max — Claude Code n’est pas disponible sur le plan gratuit.
• macOS 13 ou supérieur — pour les utilisateurs Mac. Linux est également supporté.

C’est tout. L’installeur natif se charge du reste.

---

Installation sur Mac

Méthode 1 — Installeur natif (recommandée)

Ouvrez votre Terminal (Cmd + Espace, tapez Terminal, appuyez sur Entrée) et collez cette commande :

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

L’installeur télécharge et configure automatiquement Claude Code. Quand il affiche « Claude Code successfully installed! », c’est bon.

Ensuite, mettez à jour votre PATH pour que la commande claude soit reconnue par votre terminal :

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc && source ~/.zshrc

Vérifiez l’installation :

claude --version

Méthode 2 — Via Homebrew

Si vous utilisez Homebrew, une seule commande suffit :

brew install --cask claude-code

Méthode 3 — Via npm

Si Node.js (version 18 ou supérieure) est déjà installé sur votre machine :

npm install -g @anthropic-ai/claude-code

La méthode npm est la méthode historique, mais maintenant il y a un installateur binaire (voir ci-dessus)

---

Première connexion

Au premier lancement, Claude Code demande le thème graphique que vous voulez, deamnde votre méthode de login, si vous avez un compte PRO et c’est le plus souvent, c’est la première méthode, sinon vous avez d’autre méthode qui consomment l’API, (mais cette dernière va vous revenir plus cher, car le coût est calculé au nombre de token), et Claude ouvre automatiquement votre navigateur pour vous authentifier :

claude

Connectez-vous à votre compte Claude.ai et cliquez sur Authenticate. La session est ensuite sauvegardée localement — vous n’aurez plus à vous reconnecter à chaque fois.

Pour que Claude code fonctionne sur votre dossier projet, allez sur votre répertoire de projet et tapez Claude, il vous demandera systématiquement de valider que vous faites confiance à ce projet.

Prise en main : les fonctionnalités essentielles

1. Travailler dans un projet

Claude Code est conçu pour fonctionner au sein de votre projet. Naviguez dans votre dossier de travail avant de le lancer :

cd mon-projet

claude

Dès lors, Claude voit tous vos fichiers et comprend le contexte de votre codebase. Vous pouvez lui demander d’expliquer la structure du projet, de décrire une fonction, ou de repérer des incohérences.

---

2. Demander des modifications de code

Décrivez ce que vous voulez en langage naturel. Claude génère les changements et les présente sous forme de diff avant de les appliquer :

> Ajoute une fonction de validation d’email dans utils.py

> Refactorise cette classe pour utiliser des dataclasses Python

> Corrige le bug dans la fonction parse_date — elle ne gère pas les années bissextiles

Claude attend votre approbation avant chaque modification. Vous restez maître des changements. Vous allez être bluffé par sa capacité à écrire du code qui fonctionne, et en 20 minutes vous pouvez abattre l’équivalent d’une semaine de travail voire plus, cet effet multiplicateur est d’autant plus grand que vous vous attaquez à des technologies dont vous n’êtes pas familier ou jamais vu. Plus de crainte de rester bloqué, et plus de syndrome de l’imposteur !

---

3. Exécuter des commandes et des tests

Claude Code peut lancer des commandes shell directement :

> Lance les tests unitaires et explique les erreurs

> Installe les dépendances manquantes du projet

> Génère le build de production

Il interprète les résultats, identifie les erreurs et propose des corrections en boucle.

---

4. Le mode Plan (Shift + Tab)

Avant de se lancer dans une tâche complexe, Claude peut vous présenter un plan d’action détaillé. Appuyez sur Shift + Tab pour activer ce mode. Vous visualisez chaque étape prévue et pouvez affiner les instructions avant exécution — idéal pour les refactorisations importantes ou l’ajout de nouvelles fonctionnalités.

---

5. Reprendre une session précédente

Chaque conversation avec Claude Code est sauvegardée. Pour reprendre là où vous en étiez :

claude –continue   # reprend la dernière session

claude –resume     # choisit une session parmi l’historique

---

6. Commandes utiles à connaître

Une fois dans Claude Code, quelques raccourcis à garder en tête :

Commande	Action
/help	Affiche la liste des commandes disponibles
/model	Change le modèle Claude utilisé
/rename	Renomme la session en cours
/exit	Quitte Claude Code
Échap	Interrompt Claude si une action est en cours

---

Extension VS Code

Si vous travaillez principalement dans VS Code, une extension Claude Code est disponible directement dans le marketplace. Elle affiche les suggestions et diffs dans un panneau latéral, avec un accès rapide depuis l’éditeur sans quitter votre environnement habituel. Mais personnellement l’outil CLI rest mon favori à 99%

Bonnes pratiques pour démarrer

Initialisez Git dans vos projets. Claude Code fonctionne bien mieux avec un historique de versions — vous pouvez rollback immédiatement si un changement ne convient pas.

Commencez par des tâches simples. Demandez-lui d’expliquer un fichier, de générer des tests unitaires, ou d’ajouter de la documentation. Cela permet de comprendre comment il interprète votre codebase avant de lui confier des modifications importantes.

Lisez les diffs avant d’approuver. Claude est efficace, mais c’est vous qui validez. Prenez l’habitude de relire chaque changement proposé.

---

Conclusion

Claude Code change la manière dont on interagit avec son code. Ce n’est pas un autocomplete amélioré — c’est un agent qui lit, comprend, modifie et teste votre projet de façon autonome, tout en restant sous votre supervision. L’installation prend moins de deux minutes. La prise en main, quelques heures. Et rapidement, il devient difficile de s’en passer.

---

Pour aller plus loin : docs officielles Claude Code