Comprendre les LLMs

---

1. Ce qu'est réellement un LLM

Un Large Language Model (LLM) est un système entraîné à prédire le token le plus probable en fonction de tous les tokens précédents. Tout part de là, et ça suffit à expliquer le meilleur comme le pire de son comportement.

Sous le capot, il n'y a ni compréhension au sens humain, ni raisonnement causal natif, ni mémoire qui persiste d'une session à l'autre. Ce qui produit des réponses bluffantes, c'est la compression de patterns statistiques sur des centaines de milliards de tokens de code, de texte et de doc. Quand Claude résout un problème algorithmique, il rejoue des structures vues des millions de fois dans des contextes proches.

Implication pour le dev : à modèle égal, la qualité de la réponse dépend surtout de ce que tu lui donnes en entrée. Et ça, c'est toi qui le contrôles.

---

2. L'analogie fondamentale (d'après Andrej Karpathy)

Karpathy décrit le LLM comme un nouveau type de système d'exploitation : le modèle joue le rôle du CPU, le context window celui de la RAM. On pousse l'analogie d'un cran : dans ce système, c'est toi qui tiens le rôle de l'OS : tu décides ce qui entre en mémoire et ce qui en sort.

Conséquence directe : tout comme un OS performant gère finement ce qu'il charge en RAM, un dev performant gère finement ce qu'il injecte dans le contexte.

---

3. Le context window

Le context window contient tout : ton historique de conversation, les fichiers lus, les outputs de commandes, les instructions système.

Tailles courantes (à jour : juillet 2026)

Compare les deux colonnes de droite : 1M tokens chez Claude 5 et 1M tokens chez Gemini 3 Pro ne contiennent pas le même texte. Un token n'est pas une unité universelle, c'est une convention propre à chaque tokenizer (voir §6).

Le problème : Lost in the Middle

Plus grand ≠ meilleur. Les recherches montrent que les modèles ont tendance à mieux traiter les informations au début et à la fin du contexte. Les informations au milieu d'une longue session sont partiellement "perdues".

Conséquence pratique :

• Place tes instructions critiques en début de contexte (CLAUDE.md / AGENTS.md / GEMINI.md, system prompt)
• Et dans ton prompt final (fin du contexte)
• Évite de noyer tes contraintes au milieu de milliers de lignes

Context Drift

Au fil d'une longue session, des informations obsolètes et contradictoires s'accumulent. La qualité se dégrade progressivement et silencieusement.

L'allure typique de la dégradation (à prendre comme un ordre de grandeur, pas comme une loi gravée) :

• 0–40 % du context plein : zone optimale, réponses fiables
• 40–70 % : premiers ratés, des détails commencent à se perdre
• 70 %+ : zone dangereuse, les contradictions internes grimpent

---

4. Les hallucinations : pourquoi et comment les éviter

Une hallucination, c'est quand le modèle génère du contenu faux avec assurance. Ce n'est pas un bug : c'est un comportement émergent d'un système de prédiction statistique.

Les 4 causes principales

Cause 1 : Contexte insuffisant Le modèle n'a pas assez d'info → il comble les trous avec des patterns plausibles.

Fix : fournis un contexte précis et pertinent.

Cause 2 : Demande ambiguë La requête admet plusieurs interprétations → le modèle choisit la plus probable selon son entraînement, pas selon ton intention.

Fix : sois précis sur le "quoi", le "pourquoi" et les contraintes.

Cause 3 : Knowledge cutoff Le modèle ne connaît pas les APIs récentes, tes librairies internes, tes versions spécifiques.

Fix : injecte la documentation ou les signatures des interfaces directement dans le prompt.

Cause 4 : Contexte pollué (Context Poisoning) Une erreur dans une réponse précédente se propage aux réponses suivantes.

Fix : vérifie les résumés d'analyse de l'IA, redémarre une session propre si besoin.

Le réflexe minimal avant d'accepter une réponse

Trois questions, dans cet ordre, à chaque fois que tu récupères du code généré :

1. Comprends-tu chaque ligne ? Sinon, demande à l'IA d'expliquer avant d'aller plus loin.
2. Les tests passent-ils ? Sinon, corrige. Pas de « ça devrait marcher ».
3. As-tu vérifié ce qu'il a inventé ? Les noms de packages, les signatures d'API, les options de config : c'est là que se logent les hallucinations.

C'est le filtre de base, celui qui s'applique à chaque réponse. La checklist complète avant merge en production, elle, est au Module 9 §9 : elle ajoute la revue sécurité, les conventions du projet et la revue humaine.

---

5. Comparatif des modèles principaux

Note importante : aucun modèle n'est universellement supérieur, et le classement change à chaque release. Le bon réflexe n'est pas de retenir un gagnant, c'est de tester deux modèles sur ta tâche réelle et de garder celui qui te coûte le moins d'allers-retours.

---

6. Tokenization — pourquoi ça compte

Les LLMs ne lisent pas des caractères, mais des tokens : des fragments de mots produits par un tokenizer (BPE pour la plupart). Conséquences pratiques que tout senior doit avoir en tête.

Coût et précision

Un token ≈ 4 caractères en anglais, ≈ 3 en français, beaucoup moins en code à cause de la ponctuation. Estimations utiles :

Pièges concrets

• react-query-async et reactqueryasync se tokenizent différemment. Le modèle voit deux choses distinctes. Soigner les noms qu'on cite à l'IA limite la confusion.
• Les très longs identifiants (USER_PROFILE_DETAILS_REPOSITORY_IMPL) coûtent plusieurs tokens et n'aident pas le modèle à raisonner. Préférer des noms courts dans les prompts si possible.
• Le français coûte 20–30 % de tokens en plus que l'anglais. Sur des prompts longs et techniques, basculer en EN peut améliorer à la fois le coût et la qualité.
• Le tokenizer change entre générations d'un même provider. Un même texte ne donne pas le même nombre de tokens sur deux générations de modèles, et l'écart peut être large. Conséquence : un compteur de tokens, une estimation de coût ou un « ça rentre dans la fenêtre » calibrés sur l'ancienne génération deviennent faux du jour au lendemain. Recompte après chaque montée de version au lieu de reprendre tes repères.

Outils utiles

• Le tokenizer playground d'Anthropic / OpenAI / Google pour mesurer un prompt avant de l'envoyer.
• En agent (Claude Code, Cursor), regarder l'usage par session pour repérer ce qui coûte cher.

---

7. Reasoning models et extended thinking

Depuis 2024, une classe de modèles est entraînée à réfléchir avant de répondre : ils émettent un long enchaînement de raisonnement (souvent caché) puis produisent la réponse finale. En 2026 c'est devenu la norme, et le curseur a bougé une deuxième fois : on ne décide plus si le modèle réfléchit, on décide combien d'effort il a le droit de dépenser, et c'est lui qui répartit.

Régler le curseur

Chez Claude, effort prend cinq valeurs de low à max, avec high par défaut (dans l'API comme dans Claude Code).

Deux pièges que le nom ne laisse pas deviner. L'effort agit sur tous les tokens de la réponse, pas seulement sur la réflexion : à low, le modèle appelle aussi moins d'outils et explique moins ce qu'il fait. Et changer d'effort en cours de conversation invalide le prompt caching (§8), parce que ça modifie le prompt rendu. Sur une session longue, choisis un niveau au départ et n'y touche plus.

---

8. Prompt caching — le levier économique #1

Sur Anthropic et désormais d'autres providers, tu peux marquer une portion du prompt comme cacheable. Si le cache est encore chaud (TTL 5 min par défaut chez Anthropic, option 1 h), un cache read est facturé ~10 × moins cher qu'un token normal et généré beaucoup plus vite. À nuancer : la première écriture du cache coûte un peu plus cher (~1,25 ×) : le gain n'apparaît qu'à partir du deuxième appel sur le même préfixe.

C'est la fonctionnalité qui change l'économie d'un agent en production. Pour un fichier de contexte (CLAUDE.md / AGENTS.md / GEMINI.md) de 5 000 tokens lu à chaque tour de conversation, c'est la différence entre $30 et $3 par session.

Ce qu'on met en cache

• System prompt long
• Documentation (CLAUDE.md, conventions)
• Schemas, types, interfaces
• Quelques shots d'exemples

Ce qu'on ne met pas en cache

• Le message utilisateur courant
• Le résultat des outils (souvent différent à chaque appel)

Anthropic API — exemple minimal

const response = await anthropic.messages.create({
  model: 'claude-sonnet-5',
  system: [
    {
      type: 'text',
      text: longSystemPrompt,
      cache_control: { type: 'ephemeral' },
    },
  ],
  messages: [{ role: 'user', content: userMessage }],
})

Bonnes pratiques

• Place les blocs les plus stables en premier dans le prompt (cache hit = préfixe identique).
• Mesure cache_creation_input_tokens vs cache_read_input_tokens dans la réponse : c'est ton ratio de cache hit.
• Régénère le cache toutes les 5 min en faisant un petit appel keep-alive si ton trafic est sporadique.

---

9. Paramètres d'inférence — temperature, top_p, top_k

Trois leviers, trois usages distincts. Un senior qui pilote des agents en production doit savoir les utiliser.

---

10. Le non-déterminisme

Le même prompt peut produire des réponses différentes à chaque exécution. C'est intentionnel (paramètre temperature).

Implications pratiques :

• Ne régénère pas sans changer ton prompt si la première réponse était mauvaise
• Pour des tâches critiques, descends temperature à 0, mais sache que même à 0, la sortie n'est pas garantie identique (routage interne, batching). L'API Anthropic n'expose pas de paramètre seed ; certaines API comme OpenAI le proposent, sans garantie stricte non plus
• Pour l'exploration créative, le non-déterminisme est un avantage

---

11. Au-delà du texte : appeler des outils et rendre du JSON

On a dit qu'un LLM prédit du texte. C'est vrai, mais pour un dev il manque une pièce au tableau : aujourd'hui, ce texte peut aussi être une demande d'action ou une donnée structurée. C'est ce qui fait passer le modèle de « machine à écrire » à brique qu'on branche dans une vraie application.

Tool use (appel d'outils)

Tu décris au modèle des outils qu'il peut utiliser : lire un fichier, lancer une requête SQL, appeler une API. Le modèle ne les exécute pas lui-même : quand il en a besoin, il répond « appelle get_ticket avec l'argument PROJ-1234 », ton code exécute l'appel et lui renvoie le résultat. Il continue avec cette info en main.

C'est le mécanisme derrière tout le reste du guide :

• Un agent (Claude Code, Cursor), c'est un LLM plus une boucle d'outils : lire, écrire, lancer des commandes.
• Le MCP (Module 7), c'est une façon standard de brancher tes outils à lui.
• Et c'est le vrai remède aux hallucinations : le modèle va chercher l'info au lieu de la deviner.

Sorties structurées

Tu peux aussi forcer le modèle à répondre selon un schéma précis (souvent du JSON validé). Au lieu d'un paragraphe qu'il faut parser à la main, tu récupères directement un objet exploitable :

// Au lieu d'une réponse en prose à re-parser, on impose la forme
const schema = {
  type: 'object',
  properties: {
    severity: { type: 'string', enum: ['low', 'medium', 'high'] },
    file: { type: 'string' },
    fix: { type: 'string' },
  },
  required: ['severity', 'file', 'fix'],
}
// La réponse est garantie conforme à ce schéma → directement utilisable en code

Pourquoi ça compte pour toi : dès que tu veux brancher un LLM dans un pipeline (revue de PR automatique, tri de tickets, extraction de données), tu ne veux pas d'un texte à interpréter, tu veux une donnée fiable. Les sorties structurées, c'est ce qui rend un LLM utilisable comme un composant logiciel, pas juste comme un chat.