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.

C'est tout. Il n'y a pas de compréhension au sens humain, pas de raisonnement causal natif, pas de mémoire persistante entre sessions.

Ce qui produit des réponses brillantes, c'est la compression de patterns statistiques sur des centaines de milliards de tokens de code, de texte, de documentation. Quand Claude résout un problème algorithmique, il active des patterns vus des millions de fois dans des contextes similaires.

Implication pour le dev : la qualité de la réponse dépend à 80% de la qualité de ce que tu fournis en entrée — pas du modèle.

---

2. L'analogie fondamentale (Andrej Karpathy)

"LLM as the CPU, context window as RAM, you as the OS"

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 actuelles (2026)

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 :

• 0–40 % du context plein — zone optimale, réponses fiables
• 40–70 % — première dégradation, les détails commencent à se perdre
• 70 %+ — zone dangereuse, les contradictions internes augmentent

---

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.

Protocole de validation anti-hallucination

Avant tout merge, trois questions, dans cet ordre :

1. Comprends-tu chaque ligne ? — Sinon, demande à l'IA d'expliquer avant d'aller plus loin.
2. Les tests unitaires passent-ils ? — Sinon, corrige. Pas de "ça devrait marcher".
3. Une revue humaine a-t-elle eu lieu ? — Code review par un pair, comme pour tout code produit à la main.

Si les trois sont à oui, le merge est autorisé. Sinon, on n'avance pas.

---

5. Comparatif des modèles principaux

Note importante : aucun modèle n'est universellement supérieur. Le meilleur outil dépend de la tâche. Un dev expert jongle entre plusieurs selon le besoin.

---

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é.

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-2025, une nouvelle 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.

Quand l'activer

• Problème algorithmique non trivial (concurrence, perf, complexité)
• Debug d'un bug qui résiste depuis une heure
• Décision d'architecture avec tradeoffs croisés
• Revue de code sécurité approfondie

Quand l'éviter

• Tâches simples ou répétitives (le thinking coûte plus de tokens et plus de latence)
• Génération de boilerplate
• Refactoring mécanique

---

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 (5 min sur Anthropic), les tokens cache hit sont facturés 10 × moins cher et générés beaucoup plus vite.

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-4-6',
  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, mets temperature: 0 et garde un seed si l'API le supporte
• Pour l'exploration créative, le non-déterminisme est un avantage