Glossaire

---

A

• Agent — Un LLM qui ne se contente pas de répondre : il agit en boucle, appelle des outils, lit le résultat et décide de l'étape suivante jusqu'à finir la tâche. C'est la différence entre un modèle qui te donne du code et un système qui édite tes fichiers et lance tes tests tout seul. (voir Module 5)
• AI Act — Le règlement européen qui encadre l'IA selon son niveau de risque. En clair : certains usages sont interdits, d'autres imposent transparence et traçabilité, et ça te concerne dès que tu mets de l'IA en production. (voir Module 8)
• Audit trail — La trace écrite de qui a fait quoi, et quand : quels prompts, quelles actions de l'agent, quelles décisions validées par un humain. Indispensable pour comprendre après coup ce qui s'est passé et prouver que tu gardais le contrôle. (voir Module 8)

C

• CLAUDE.md / AGENTS.md / GEMINI.md — Un fichier à la racine du projet où tu écris le contexte que l'agent doit toujours avoir sous les yeux : conventions, commandes, pièges à éviter. Chaque outil a le sien, mais l'idée est la même : ta mémoire de projet, versionnée avec le code. (voir Module 4)
• Context distraction — Quand le contexte est tellement rempli d'infos annexes que le modèle perd de vue la vraie tâche et part sur des détails. Trop de contexte nuit autant que pas assez. (voir Module 4)
• Context drift — Au fil d'une longue conversation, le contexte accumule des versions périmées et des allers-retours qui font dériver le modèle loin de ton intention de départ. (voir Modules 1 et 4)
• Context engineering — L'art de décider quoi mettre dans la fenêtre de contexte, dans quel ordre, et quand la nettoyer. C'est le prolongement du prompt engineering à l'échelle d'un projet entier. (voir Module 4)
• Context poisoning — Une info fausse ou malveillante entre dans le contexte et le modèle la reprend comme vraie pour la suite. Une erreur en amont contamine tout ce qui vient après. (voir Module 4)
• Context window / Fenêtre de contexte — La quantité de texte (en tokens) que le modèle peut lire d'un coup : ton prompt, les fichiers, l'historique, sa réponse. C'est sa mémoire de travail, elle est limitée, et tout ce qui déborde est oublié. (voir Module 1)
• ContextOps — Traiter la gestion du contexte comme une pratique d'équipe : conventions partagées, fichiers de contexte maintenus, révisés et améliorés comme du code. (voir Modules 4 et 7)

E

• Embedding — La transformation d'un texte en une liste de nombres qui capture son sens. Deux textes proches par le sens donnent des vecteurs proches, ce qui permet de chercher par similarité plutôt que par mots exacts. (transverse)
• Eval / Évaluation — Un jeu de tests pour vérifier qu'un prompt ou un agent donne toujours de bons résultats, surtout après un changement de modèle. Sans eval, tu ne sais pas si ta mise à jour a amélioré les choses ou les a cassées. (transverse)
• Explore-Plan-Code-Verify / EPCV — Une façon de travailler avec l'agent en quatre temps : il explore le code, propose un plan, écrit le code, puis vérifie. On valide le plan avant de le laisser coder, ce qui évite de partir dans le mur. (voir Module 3)

F

• Fan-out — Lancer plusieurs agents en parallèle sur des bouts indépendants d'une tâche, puis rassembler leurs résultats. Utile pour gagner du temps quand le travail se découpe bien. (voir Module 5)
• Few-shot — Donner au modèle quelques exemples d'entrée/sortie dans le prompt pour lui montrer le format ou le style attendu, au lieu de juste le décrire. Souvent plus efficace qu'une longue consigne. (voir Module 2)
• Framework R.C.T.C.F. — Une structure de prompt pour ne rien oublier : Rôle, Contexte, Tâche, Contraintes, Format. Un aide-mémoire pour écrire des demandes claires. (voir Module 2)

H

• Hallucination — Quand le modèle produit une réponse fausse mais présentée avec assurance : une fonction qui n'existe pas, une source inventée. C'est le comportement normal d'un système qui prédit du texte plausible, pas la vérité. (voir Module 1)
• Hook — Un script que tu branches sur un événement de l'agent, avant ou après une action, pour l'automatiser : formater le code, bloquer une commande, lancer les tests. Du déterministe posé autour d'un système non-déterministe. (voir Module 5)
• Human-in-the-loop — Garder un humain qui valide les décisions sensibles avant qu'elles ne s'appliquent. L'agent propose, tu disposes, surtout pour tout ce qui touche à la prod ou à la sécurité. (voir Modules 5 et 8)

K

• Knowledge cutoff — La date de fin des données d'entraînement d'un modèle. Il ne connaît rien de neuf après cette date, d'où ses erreurs sur les versions récentes de bibliothèques si tu ne lui donnes pas la doc à jour. (voir Module 1)

L

• Lost in the middle — Les modèles retiennent mieux le début et la fin d'un long contexte que le milieu. Une info importante noyée au centre d'un gros prompt a plus de chances d'être ignorée. (voir Modules 1 et 4)

M

• MCP / Model Context Protocol — Un standard qui permet de connecter un agent à des outils et des sources de données externes (base, API, fichiers) de façon uniforme. Une sorte de prise universelle entre le modèle et le reste de ton système. (voir Modules 5 et 6)
• Memory — Un mécanisme qui permet à l'agent de garder des infos entre les sessions, au lieu de repartir de zéro à chaque fois. À ne pas confondre avec la fenêtre de contexte, qui, elle, se vide. (voir Module 4)

N

• Non-déterminisme — Même prompt, réponses différentes d'une fois sur l'autre. C'est normal : le modèle tire le token suivant selon des probabilités, il ne rejoue pas un calcul figé. (voir Module 1)

O

• Over-trust — Faire trop confiance à la sortie du modèle et la valider sans vraiment la lire. Le vrai danger n'est pas que l'IA se trompe, c'est que tu ne le remarques pas. (voir Module 0)

P

• Pattern Writer/Reviewer — Faire produire le code par un agent, puis le faire relire par un autre au rôle bien séparé. Deux casquettes distinctes attrapent plus d'erreurs qu'un seul agent qui se relit lui-même. (voir Module 5)
• Plan mode — Un mode où l'agent analyse et propose un plan sans toucher à tes fichiers. Tu valides avant qu'il agisse, ce qui te laisse le contrôle sur les grosses tâches. (voir Module 5)
• Plugin / Marketplace — Un plugin ajoute des capacités à ton agent (commandes, skills, outils) ; le marketplace est l'endroit où on les trouve et où on les installe. De quoi étendre l'outil sans tout recoder. (voir Module 5)
• Prompt caching — Réutiliser la partie stable d'un prompt déjà traité au lieu de la refaire calculer à chaque appel. Ça réduit le coût et la latence quand tu renvoies souvent le même gros contexte. (voir Module 1)
• Prompt engineering — L'art d'écrire des instructions qui donnent des résultats fiables et reproductibles. Pas des formules magiques : de la clarté, du contexte et des exemples. (voir Module 2)
• Prompt injection (directe et indirecte) — Une attaque où un texte glisse des instructions pirates au modèle. Directe : l'utilisateur les tape lui-même. Indirecte : elles sont cachées dans un contenu que l'agent va lire (page web, fichier, ticket). (voir Module 8)

R

• RAG / Retrieval-Augmented Generation — Aller chercher des documents pertinents et les injecter dans le contexte avant que le modèle réponde. Il répond alors à partir de tes données à jour, pas seulement de sa mémoire d'entraînement. (transverse)
• Reasoning model / Extended thinking — Un modèle qui prend le temps de « réfléchir » en produisant des étapes intermédiaires avant de répondre. Meilleur sur les problèmes complexes, mais plus lent et plus cher. (voir Module 1)

S

• Skill — Un savoir-faire réutilisable que tu donnes à l'agent : des instructions packagées qu'il charge quand la tâche s'y prête. Tu factorises une bonne façon de faire une fois, il la rejoue partout. (voir Module 5)
• Slash command — Un raccourci tapé avec / pour déclencher une action ou un prompt prédéfini dans l'agent. Pratique pour tes routines répétées. (voir Module 5)
• Slopsquatting — Une attaque qui profite des hallucinations : le modèle invente un nom de package, un pirate crée ce package piégé, et ton agent l'installe. Vérifie toujours les dépendances qu'il te propose. (voir Module 8)
• Sorties structurées / Structured outputs — Forcer le modèle à répondre dans un format précis (du JSON conforme à un schéma) pour que ton code puisse l'exploiter directement. C'est ce qui transforme le modèle en vrai composant logiciel. (voir Module 1)
• Spec-Driven Development / SDD — Écrire d'abord une spec claire de ce que tu veux, puis laisser l'agent l'implémenter en s'y référant. La spec devient la source de vérité partagée entre toi et lui. (voir Module 3)
• Subagent — Un agent secondaire lancé par l'agent principal pour une sous-tâche, avec son propre contexte. Ça évite de polluer le contexte principal et permet de spécialiser le travail. (voir Module 5)

T

• Temperature — Un réglage qui contrôle le côté aléatoire des réponses. Basse : sortie stable et prévisible. Haute : plus de variété et de créativité, mais moins fiable. (voir Module 1)
• Token — L'unité de base que manipule un LLM : un bout de mot, un mot court, un symbole. Le modèle ne lit pas des lettres ni des mots, il prédit des tokens, et c'est en tokens que se comptent le coût et la limite de contexte. (voir Module 1)
• Tokenization / BPE — Le découpage d'un texte en tokens. Le BPE (Byte Pair Encoding) est l'algorithme courant pour ça : il fusionne les paires de caractères les plus fréquentes. C'est aussi pourquoi un modèle peut galérer à compter les lettres d'un mot. (voir Module 1)
• Tool use / Appel d'outils — La capacité du modèle à appeler des fonctions que tu lui exposes (lire un fichier, requêter une API) et à se servir du résultat. C'est ce qui fait passer d'un chatbot à un agent qui agit. (voir Module 1)
• top_p / top_k — Deux réglages qui limitent le choix du token suivant. top_k garde les k tokens les plus probables ; top_p garde les plus probables jusqu'à atteindre une probabilité cumulée p. Les deux servent à cadrer l'aléatoire, comme la temperature. (voir Module 1)

V

• Vibe coding — Coder en se laissant porter par l'IA, en acceptant ses propositions sans vraiment relire ni comprendre. Ça va vite pour un prototype, ça devient dangereux dès que le code compte. (voir Module 0)