Glossaire

Les termes techniques du domaine sont massivement anglais : ce glossaire conserve le mot d’usage en anglais et en donne une définition en français. À consulter quand un terme du handbook reste opaque. Pour la mécanique d’inférence (token, embeddings, transformer…), voir Annexe — Comment un LLM fait son inférence ?. Les mécanismes propres à Claude Code renvoient à sa documentation officielle.

Accept Edits

Mode qui approuve automatiquement les modifications de fichiers pour la durée de la session ; les commandes shell, elles, continuent de demander une validation. → Doc Claude Code — Permission modes

API

Application Programming Interface. Interface par laquelle deux programmes se parlent. Pour un agent, c’est aussi bien l’endpoint HTTP du modèle — auquel on envoie le contexte et qui facture les tokens — que les fonctions exposées par un outil ou un service. Un « appel d’API » est une requête envoyée à ce point d’entrée.

CLAUDE.md

Fichier markdown placé à la racine d’un projet (ou dans une hiérarchie de dossiers) que l’agent charge au début de chaque session : standards de code, décisions d’architecture, conventions. C’est le contrat permanent du contexte. → Doc Claude Code — Memory

Compaction

Résumé automatique de l’historique de conversation quand il devient trop long : le système condense les anciens tours pour libérer de la place dans la fenêtre, au prix d’une perte de détail. Dans Claude Code, déclenchée par /compact (ou /clear pour repartir de zéro). → Doc Claude Code — Commands

Context engineering

Discipline qui consiste à curer ce que le modèle voit — choisir, structurer et doser le contexte pour obtenir un meilleur résultat. Plus large que le prompt engineering : on gère tout ce qui occupe la fenêtre, pas seulement l’instruction.

Context window

Fenêtre de contexte. Quantité maximale de tokens qu’un modèle peut traiter en un seul appel, entrée et sortie comprises. Ressource finie et coûteuse : tout ce que l’agent « sait » à un instant donné doit y tenir. Au-delà d’environ 70 % de remplissage, la qualité décroche. → Doc Claude Code — Context window

Embeddings

Représentation d’un token sous forme de vecteur de nombres, qui situe son sens dans un espace à plusieurs centaines de dimensions. C’est ce qui permet au modèle de manipuler du sens plutôt que des suites de caractères. → Annexe inférence.

Extended thinking

Aussi appelé reasoning tokens. Tokens que le modèle génère pour « réfléchir » avant de produire sa réponse finale. Ils comptent dans le budget de sortie — donc facturés — même lorsqu’ils restent cachés à l’utilisateur. Propres aux modèles à raisonnement.

Front-matter

Bloc d’en-tête en YAML placé au tout début d’un fichier markdown (entre deux ---) qui porte ses métadonnées : par exemple description, when_to_use, status. Point d’attention : le front-matter d’un skill reste chargé en permanence dans le contexte, même quand le corps du skill n’est lu qu’à l’invocation. → Doc Claude Code — Skills

Guardrails

Garde-fous. Contraintes et conventions qu’on impose à l’agent pour borner son comportement. On distingue la guidance (orientations souples), les rules (règles fermes, souvent dans .claude/rules) et les guardrails proprement dits. Chargés quand ils deviennent pertinents, pas en permanence.

Harness / Harness engineering

Harnais. Tout ce que l’on met en place autour du modèle pour le cadrer : le contexte, les instructions et les outils qui lui fournissent du feedback. Le harness engineering est la discipline qui consiste à concevoir ce harnais — l’évolution du context engineering, élargie aux boucles de feedback fournies à l’agent. C’est le sujet même de ce handbook, structuré en Arrange · Instruct · Assert.

Hooks

Points d’ancrage déterministes du cycle de vie de l’agent où l’on branche une action automatique : par exemple PreToolUse (avant qu’un outil s’exécute), PostToolUse / PostEdit (après). Ils permettent à l’agent — et non au LLM, non déterministe — d’intervenir de façon garantie. → Doc Claude Code — Hooks

Ingénierie agentique

Agentic engineering. L’activité consistant à intégrer un agent comme acteur du cycle de vie logiciel et à le cadrer : construire son contexte, décider des choix d’architecture et des « ilities », et vérifier qu’il produit ce qui est attendu. Elle ne remplace pas l’ingénierie logicielle classique, elle s’y ajoute. → Principes fondamentaux.

LLM

Large Language Model, grand modèle de langage. Dans ce handbook, on le traite comme une fonction pure : pour une entrée donnée (contexte + instruction) il produit une sortie, sans mémoire entre deux appels (stateless). → Modèles mentaux — un LLM est une fonction pure.

MCP

Model Context Protocol. Protocole standard qui permet à un agent de se connecter à des sources externes — APIs, bases de données, services — via des « serveurs MCP ». Une porte d’entrée standardisée pour donner au modèle accès à de la matière qu’il n’a pas nativement. → Doc Claude Code — MCP

Permissions

Règles qui déterminent les actions que l’agent peut effectuer sans demander. Par défaut, il demande pour tout. En mode « accept edits », seules les modifications de fichiers se font sans validation ; tout autre usage d’outil requiert l’accord de l’utilisateur (sauf autorisation préalable accordée via /permissions). → Doc Claude Code — Permissions

Plan Mode

Mode lecture seule : l’agent explore la codebase et propose un plan, mais ne modifie aucun fichier et n’exécute aucune commande. → Doc Claude Code — Permission modes

Progressive disclosure

Stratégie consistant à ne révéler le contexte qu’au fur et à mesure des besoins de l’agent, là où il se trouve dans la codebase, plutôt que tout charger d’avance. Économise la fenêtre et garde l’attention focalisée. (On rencontre parfois le terme lazy loading pour le même principe.)

Session

Une exécution de claude dans un répertoire, du lancement à la sortie. Chaque session a son propre historique de conversation ; la mémoire du projet (le CLAUDE.md), elle, persiste d’une session à l’autre. → Doc Claude Code — Sessions

Skill

Prompt réutilisable qui code une tâche précise et récurrente ; c’est le LLM qui décide de le charger quand il le juge pertinent mais un humain peut également invoquer un skill avec la syntaxe /skill-name. Seul son front-matter reste visible en permanence dans le contexte; son corps ne se charge qu’à l’invocation. → Doc Claude Code — Skills

Slash command

Commande déclenchée à la main par l’humain en tapant /nom. À la différence d’un skill (chargé par le LLM), elle est invoquée explicitement. Dans Claude Code, les commandes personnalisées ont fusionné avec les skills. → Doc Claude Code — Commands

Sub-agent

Sous-agent. Agent scopé, lancé par un orchestrateur avec son propre contexte, son propre toolset et sa propre mission ; il vit à part du contexte de l’orchestrateur, et seul son résultat remonte. → Doc Claude Code — Subagents

System prompt

Socle d’instructions déposé par l’éditeur du modèle tout en tête du contexte : identité de l’agent, règles permanentes, format de réponse. L’utilisateur ne le modifie pas, mais il occupe déjà de la place dans la fenêtre.

Token

Unité atomique que lit un LLM : un fragment de texte (~3 à 4 caractères). Le tokenizer est le composant qui découpe le texte brut en tokens à partir d’un vocabulaire figé. Coût, taille et latence se comptent tous en tokens. → Annexe inférence.

Tools

Outils. Capacités que l’agent peut actionner pour agir ou obtenir du feedback : lire et écrire un fichier, lancer bash, grep, exécuter des tests… C’est ce qui distingue un agent d’un simple LLM.

Transformer

Cœur de calcul du modèle. Le transformer enrichit l’embedding de chaque token avec le contexte des autres (mécanisme d’attention) ; l’unembedding reprojette le résultat dans l’espace du vocabulaire pour prédire le token suivant. → Annexe inférence.

Vibe coding

Faire produire du code par un agent IA en interagissant avec lui en se fiant à l’intuition, sans garde-fou ni vérification, et surtout sans lire et vérifier que le code produit par l’agent est correct pour l’humain (suivant des critères variables par humain, on est d’accord). Acceptable pour un prototype jetable, à proscrire pour du code de production : c’est précisément ce que le « focusing » de l’agent cherche à éviter.