Qu'est-ce qu'un LLM, pour de vrai

Avant de toucher à l'API Claude, on prend 30 minutes pour comprendre ce qu'il y a sous le capot. Pas la version vulgarisée des posts LinkedIn. Pas les métaphores du « cerveau artificiel ». La mécanique réelle, parce que c'est elle qui explique pourquoi ça marche, et surtout pourquoi ça plante.

1. Pourquoi ce module existe

Tu pourrais sauter direct au Module 3 et faire ton premier appel API. Ça marcherait. Pendant cinq minutes. Puis tu vas te heurter à des comportements bizarres : le modèle qui invente des fonctions, qui se contredit, qui répond impeccablement à une question et n'importe comment à la suivante. Et là tu vas faire ce que tout le monde fait : accuser le prompt, accuser le modèle, accuser Anthropic. Sauf que la cause est dans la mécanique de base, que personne ne prend le temps d'expliquer.

Comprendre la mécanique te donne deux choses : tu sauras quand l'outil va briller, et tu sauras quand il va se planter. Ces deux informations valent plus que dix tutoriels prompt engineering.

2. D'où ça vient — l'histoire courte

Avant 2017 : la galère

Pendant des décennies, le NLP (Natural Language Processing) a vivoté avec des approches qui marchaient mal : modèles statistiques type n-grams limités à des fenêtres très courtes, réseaux récurrents (RNN, LSTM) qui oubliaient ce qui s'était passé 20 mots avant et qui étaient impossibles à paralléliser correctement sur GPU. Résultat : chatbots merdiques, traduction approximative, génération de texte incohérente.

2017 : le Transformer

Une équipe de Google publie un papier au titre volontairement provocant : « Attention Is All You Need ». L'idée centrale : on jette les RNN, on garde uniquement le mécanisme d'attention. Ça donne le Transformer.

Pourquoi c'est une révolution :

• Parallélisable. On peut traiter tous les tokens d'une séquence en parallèle sur GPU. Donc on peut scaler à des modèles énormes.
• Contexte long. L'attention permet à chaque token de « regarder » tous les autres tokens d'un coup, sans dégradation linéaire.
• Simple. Moins de paramètres bizarres que les LSTM, plus facile à optimiser.

À partir de là, tout s'enchaîne : BERT (2018), GPT-1 (2018), GPT-3 (2020) qui marque un changement d'échelle, ChatGPT (novembre 2022), puis l'explosion qu'on connaît aujourd'hui — Claude inclus.

3. Le Transformer — comment ça marche, vraiment

Pas besoin de dérouler les maths du papier original. Tu dois comprendre les idées clés, parce qu'elles expliquent tout le comportement d'un LLM.

L'attention, en une phrase

Pour chaque token de la séquence, le mécanisme d'attention calcule à quel point ce token doit « regarder » chacun des autres tokens pour produire sa propre représentation contextuelle.

Exemple : dans la phrase « Le chat que j'ai vu hier dans le jardin dort », quand le modèle traite le mot « dort », il doit comprendre que le sujet est « chat », pas « jardin ». L'attention lui permet d'associer un poids fort à « chat » et un poids faible à « jardin ».

Couches empilées, et c'est quoi exactement les « poids »

Un Transformer empile typiquement 32, 64, 96 couches d'attention. Chaque couche raffine la représentation. Les premières couches capturent la syntaxe locale, les dernières capturent du sens plus abstrait.

Quand on dit « Claude Opus 4.6 a X milliards de paramètres », on parle des poids : des nombres flottants stockés dans les matrices de chaque couche. Ces poids sont appris pendant l'entraînement et figés au moment de l'inférence.

Un modèle, c'est littéralement un gros fichier de nombres flottants. Quand tu lui envoies une requête, ton texte est transformé en vecteurs, multiplié par ces matrices, et le résultat est un vecteur de probabilités sur le vocabulaire. C'est tout. Pas de magie, pas de « compréhension », pas de « pensée ».

4. Tokenisation — pourquoi « strawberry » pose problème

Le LLM ne voit pas des mots, il voit des tokens

Avant de passer dans le réseau, ton texte est découpé en tokens. Un token n'est ni une lettre, ni un mot, c'est un sous-mot. Ce qui donne en pratique :

• bonjour → 1 token (mot fréquent en français)
• anticonstitutionnellement → 4 ou 5 tokens (mot rare, découpé)
• strawberry → typiquement 2 tokens : straw + berry

Le fameux « combien de r dans strawberry »

Quand tu demandes à un LLM combien de fois la lettre r apparaît dans strawberry, il échoue souvent. Pourquoi ? Parce qu'il ne voit pas les lettres individuelles. Il voit deux tokens, straw et berry, et il n'a aucune représentation interne du fait que straw contient un r et berry en contient deux.

Compter les tokens avant d'envoyer

Anthropic fournit un endpoint pour compter exactement combien de tokens contient ton message avant de l'envoyer. C'est crucial pour estimer les coûts en production et éviter les mauvaises surprises.

import anthropic

client = anthropic.Anthropic()

# Estimation du nombre de tokens d'un message avant envoi
result = client.messages.count_tokens(
    model="claude-opus-4-6",
    messages=[
        {"role": "user", "content": "Combien de r dans strawberry ?"}
    ]
)

print(f"Tokens d'entree estimes : {result.input_tokens}")

5. Fenêtre de contexte — au-delà du chiffre marketing

Ce que ça veut dire vraiment

Quand Anthropic annonce que Claude Opus a une grande fenêtre de contexte, ça veut dire que tu peux envoyer dans une seule requête un certain nombre de tokens (prompt système + historique + message utilisateur + documents joints). Vérifie toujours la valeur exacte dans la doc officielle au moment où tu lis ce module — Anthropic met à jour ses limites.

Concrètement, 200 000 tokens représentent environ 130 000 mots en français, ou ~500 pages d'un roman, ou ~15 000 lignes de code. Ça paraît énorme. Et pourtant en production tu vas atteindre cette limite plus vite que tu crois : un agent qui boucle, un historique qui s'accumule, des PDF longs, et boum.

Ce que la doc ne te dit pas : « lost in the middle »

Une étude largement reproduite a démontré que les LLM utilisent mieux l'information située au début et à la fin de leur contexte qu'au milieu. Concrètement : si tu mets un fait clé à la position 5 ou 95 d'un contexte de 100 documents, le modèle le retrouve. Si tu le mets à la position 50, les performances chutent significativement.

C'est une propriété émergente de l'architecture, pas un bug spécifique à un modèle. Conséquences pratiques :

• Pour le RAG : ne balance pas 50 documents au modèle en espérant qu'il trouve. Sélectionne les 3-5 plus pertinents et place les plus importants en début et fin de contexte.
• Pour les system prompts longs : les instructions critiques en début ou en fin, pas au milieu d'un pavé.
• Pour les conversations longues : à un moment, il faut résumer ou élaguer l'historique, sinon les premiers tours deviennent invisibles.

Le piège des fenêtres « 1M tokens »

Certains modèles annoncent 1 ou 2 millions de tokens de fenêtre. C'est techniquement vrai. Mais le coût explose (tu paies les tokens d'entrée à chaque appel), le « lost in the middle » empire avec la longueur, la latence augmente, et le bénéfice marginal au-delà de ~50k tokens est souvent nul.

6. Sampling — température, top-p, top-k

À chaque token généré, le modèle produit une distribution de probabilités sur tout le vocabulaire (typiquement 50 000 à 200 000 tokens possibles). Ensuite, il faut choisir un token. C'est le job du sampling.

Température

La température T modifie la distribution avant le tirage :

• T = 0 : choix toujours le plus probable. Maximum de déterminisme.
• T = 1 : on tire selon la distribution telle quelle.
• T > 1 : on aplatit la distribution, on donne plus de chances aux tokens improbables. Plus de créativité, plus de risque de partir en vrille.
• T < 1 : on accentue les écarts, on favorise les tokens probables. Plus de cohérence, moins de variété.

Top-p et top-k

Top-p : au lieu de fixer une température, tu dis « garde uniquement les tokens dont la somme cumulée des probabilités atteint p, et tire dans cet ensemble ». top_p = 0.95 est une bonne valeur par défaut.

Top-k : tu gardes uniquement les k tokens les plus probables. Valeur classique : 40.

En pratique, sur l'API Claude, tu vas surtout jouer avec la température. Top-p et top-k existent mais sont souvent laissés à leurs valeurs par défaut. Ne combine pas les trois en même temps sans savoir ce que tu fais : tu vas obtenir des comportements imprévisibles.

Voir la différence de tes propres yeux

import anthropic

client = anthropic.Anthropic()

prompt = "Donne-moi trois noms d'entreprise pour un SaaS de gestion de tests QA."

# Temperature 0 : reponse stable, repetable
reponse_stable = client.messages.create(
    model="claude-opus-4-6",
    max_tokens=200,
    temperature=0,
    messages=[{"role": "user", "content": prompt}]
)

# Temperature 0.9 : reponse creative, variable d'un appel a l'autre
reponse_creative = client.messages.create(
    model="claude-opus-4-6",
    max_tokens=200,
    temperature=0.9,
    messages=[{"role": "user", "content": prompt}]
)

print("Stable :", reponse_stable.content[0].text)
print("Creative :", reponse_creative.content[0].text)

Lance le code plusieurs fois. La version T=0 donne quasi toujours la même chose. La version T=0.9 varie à chaque appel.

7. Ce qu'un LLM fait, vraiment

Un LLM est un modèle autorégressif entraîné à une seule tâche : étant donné une séquence de tokens, prédire le token suivant. C'est tout.

Quand tu lui demandes « Quelle est la capitale de la France ? », il ne « cherche » pas la réponse dans une base de connaissances. Il calcule, sur la base de ses milliards de paramètres entraînés sur des milliards de pages web, que la suite la plus probable de cette séquence de tokens est « La capitale de la France est Paris ». Puis il génère « La », puis « capitale », et ainsi de suite, token par token, jusqu'à un signal d'arrêt.

Conséquences directes :

• Le LLM n'a pas de « réponse » en tête. Il génère mot après mot, et chaque mot influence les suivants. Il ne sait pas où il va quand il commence à répondre.
• Le LLM peut se contredire en cours de route. Si à un moment donné un token improbable est tiré, la suite va s'adapter à ce token, et tu peux te retrouver avec une réponse incohérente.
• Le LLM est sensible à la formulation. Un petit changement de prompt change la distribution du tout premier token, et donc tout le reste de la réponse.
• Le LLM ne « réfléchit » pas avant de répondre. C'est exactement ce que les modèles à extended thinking (Module 6) tentent de pallier en générant explicitement des étapes intermédiaires de raisonnement avant la réponse finale.

8. Ce qu'un LLM ne fait PAS

C'est la partie la plus importante du module. Si tu retiens ça, tu évites 80% des erreurs de prod.

Il ne « comprend » pas

Le mot « comprendre » implique une représentation mentale, une intentionnalité, un sens. Un LLM n'a rien de tout ça. Il a des matrices de poids qui transforment des vecteurs en d'autres vecteurs. Le fait que le résultat semble cohérent vient du fait qu'il a été entraîné sur un volume massif de texte humain dans lequel les patterns linguistiques encodent du sens. Mais le sens est dans le texte d'entraînement, pas dans le modèle.

C'est pour ça que les LLM peuvent dire des trucs profondément vrais et profondément faux dans la même phrase, avec exactement la même conviction apparente. Il n'y a personne aux commandes pour vérifier.

Il ne « raisonne » pas (au sens strict)

Un LLM peut produire des chaînes de raisonnement qui ressemblent à du raisonnement. Mais c'est de la génération de texte qui ressemble à du raisonnement, pas du raisonnement formel. La preuve : un LLM peut dérouler une démonstration mathématique impeccable sur un problème connu et se planter sur un problème équivalent légèrement reformulé, parce que la nouvelle formulation tombe en dehors de son corpus d'entraînement.

Les modèles à thinking (Claude Extended Thinking, OpenAI o1/o3) améliorent ça en générant explicitement de longues chaînes intermédiaires avant la réponse, ce qui leur permet de « vérifier » leurs étapes. Mais c'est toujours de la génération de texte.

Il ne « mémorise » pas (au sens où tu l'entends)

Un LLM ne mémorise rien entre deux appels. Chaque appel API est totalement indépendant. La « mémoire » que tu vois dans une conversation Claude.ai est simulée : l'historique complet est ré-envoyé au modèle à chaque tour. Si l'historique sort de la fenêtre de contexte, l'info est perdue.

Il ne sait pas qu'il ne sait pas

C'est le plus pernicieux. Un LLM n'a pas de mécanisme interne pour évaluer la fiabilité de sa propre réponse. Il génère avec la même apparente confiance la capitale de la France et le nom inventé d'un arrêt de la Cour de cassation qui n'a jamais existé.

Les techniques modernes (Constitutional AI chez Anthropic, RLHF) atténuent un peu le problème en apprenant au modèle à dire « je ne sais pas » dans certains cas. Mais c'est imparfait et facilement contournable.

9. Hallucinations — le mot qu'il faut comprendre avant tout le reste

Définition propre

Une hallucination, en LLM, c'est une sortie qui est :

• Plausible linguistiquement,
• Présentée avec confiance,
• Factuellement fausse, incohérente avec l'input, ou non vérifiable.

C'est la conséquence directe de tout ce qu'on vient de voir : un LLM génère ce qui est statistiquement probable, pas ce qui est vrai. Quand le vrai est rare dans son corpus d'entraînement et que le faux est plausible, il génère le faux.

Les types d'hallucinations

• Intrinsèque : la sortie contredit l'input fourni. Exemple : tu donnes un texte qui dit « le projet a démarré en 2024 » et le résumé sort « le projet a démarré en 2022 ».
• Extrinsèque : la sortie ajoute des informations non vérifiables ni dans l'input ni de notoriété publique. Exemple : citer une étude qui n'existe pas.
• Factuelle : la sortie est factuellement fausse par rapport au monde réel. Exemple : « Marie Curie a reçu trois prix Nobel » (elle en a reçu deux).

Causes principales

1. Données d'entraînement bruitées ou contradictoires. Si le corpus contient des erreurs, le modèle les apprend.
2. Couverture insuffisante. Sujets rares = forte propension à inventer.
3. Sampling stochastique. À température élevée, on tire des tokens improbables qui amorcent des chaînes fausses.
4. Mismatch prompt / entraînement. Formulations inhabituelles, hors domaine.
5. Pression à répondre. Les modèles sont entraînés à toujours produire une réponse plutôt qu'à dire « je ne sais pas ».

Ce qui marche pour réduire les hallucinations

• Température basse (T=0 ou proche) pour les tâches factuelles.
• Grounding : fournir explicitement les sources dans le contexte (RAG bien fait).
• Citations (Module 13) : forcer le modèle à indiquer d'où vient son info.
• Tool use : déléguer les calculs, les requêtes BDD, les recherches web à de vrais outils.
• Validation aval : vérifier les sorties avec des règles métier, des regex, des appels d'API.
• Demander explicitement « si tu n'es pas sûr, dis je ne sais pas » : aide marginalement.
• Multi-passes : faire générer la réponse, puis demander à un autre appel de la critiquer.

10. Cas réels — quand l'IA se plante en prod

Pas de la théorie : des cas réels, sourcés, dont tu peux tirer des leçons.

Mata v. Avianca (USA, 2023)

Un avocat new-yorkais utilise ChatGPT pour rédiger un mémoire juridique. ChatGPT lui invente six décisions de jurisprudence qui n'existent pas, avec noms de parties, références de dossiers, citations. L'avocat dépose le mémoire sans vérifier. Le juge découvre la supercherie. L'avocat est sanctionné, l'affaire fait jurisprudence sur l'usage des LLM en droit.

Leçon : un LLM cite avec aplomb des sources qui n'existent pas. Toujours, toujours vérifier les références.

Air Canada chatbot (Canada, 2024)

Un client demande au chatbot d'Air Canada s'il peut bénéficier d'un tarif réduit pour deuil. Le chatbot lui dit oui, en inventant une politique qui n'existe pas. Le client achète son billet, demande le remboursement. Air Canada refuse. Le tribunal donne raison au client : Air Canada est responsable des affirmations de son chatbot.

Leçon : si tu déploies un agent IA en contact client, tu es juridiquement responsable de ses sorties. Pas le fournisseur du modèle. Toi.

Les bots de support qui inventent des features

Plusieurs SaaS ont déployé des chatbots GPT/Claude sur leur doc, sans grounding strict. Résultat : le chatbot invente des fonctionnalités qui n'existent pas, des endpoints API fantômes, des paramètres imaginaires. Les utilisateurs remontent des bugs sur des features qui n'ont jamais été développées.

Leçon : RAG strict, citations obligatoires, et une catégorie « je ne sais pas » en sortie. Sinon ton chatbot devient un générateur de tickets bidon.

11. Exercices pratiques

Exercice 1 — Compter les tokens FR vs EN

Écris un script qui compte les tokens sur deux textes équivalents en français et en anglais, et compare le ratio caractères/tokens.

import anthropic

client = anthropic.Anthropic()

def compter_tokens(texte: str) -> dict:
    """Retourne le nombre de tokens et quelques statistiques."""
    resultat = client.messages.count_tokens(
        model="claude-opus-4-6",
        messages=[{"role": "user", "content": texte}]
    )
    return {
        "tokens": resultat.input_tokens,
        "caracteres": len(texte),
        "ratio_car_par_token": round(len(texte) / resultat.input_tokens, 2)
    }

if __name__ == "__main__":
    fr = "Bonjour, je teste la tokenisation en francais avec un texte assez long pour avoir des statistiques."
    en = "Hello, I am testing tokenization in English with a fairly long text to get some statistics."
    print("FR :", compter_tokens(fr))
    print("EN :", compter_tokens(en))

Question : pourquoi le français consomme-t-il typiquement plus de tokens que l'anglais à contenu équivalent ?

Exercice 2 — Mesurer la stabilité d'une réponse

Envoie 10 fois la même question à Claude avec temperature=0, puis 10 fois avec temperature=1.0. Compare. Combien de réponses sont identiques au mot près dans chaque cas ?

Exercice 3 — Provoquer une hallucination contrôlée

Demande à Claude : « Cite-moi cinq publications scientifiques sur l'application de SikuliX au testing de caisses de supermarché, avec auteurs, titres, journaux et années. »

Vérifie chaque référence sur Google Scholar. Combien sont réelles ? Combien sont inventées ? Documente le résultat.

Objectif pédagogique : voir de tes propres yeux que le modèle invente avec aplomb sur des sujets de niche, même quand tu lui demandes des références précises.

Exercice 4 — Lost in the middle, en pratique

Construis un prompt avec 10 paragraphes de texte aléatoire. Cache un fait précis dans le paragraphe 5 (« Le code secret est XYZ-42-PQR »). Demande à Claude « Quel est le code secret ? ». Recommence en plaçant le fait au paragraphe 1, puis au 10. Compare les taux de réussite sur 10 essais à chaque position.

12. Ce qu'il faut retenir

1. Un LLM est un prédicteur de token suivant entraîné sur du texte. Pas un cerveau, pas un assistant intelligent, pas un oracle.
2. L'architecture Transformer a tout débloqué grâce au mécanisme d'attention parallélisable.
3. La tokenisation explique pourquoi les LLM échouent sur des opérations caractère par caractère.
4. La fenêtre de contexte est une capacité, pas une qualité. Le « lost in the middle » est réel.
5. Température contrôle la créativité vs la stabilité. Pour les tâches factuelles : T=0.
6. Un LLM ne comprend pas, ne raisonne pas formellement, ne mémorise pas, et ne sait pas qu'il ne sait pas.
7. Les hallucinations ne sont pas un bug, c'est une propriété structurelle. Aucun modèle commercial actuel n'en est exempt.
8. Quand tu déploies un LLM en prod, tu es responsable de ses sorties. Pas Anthropic. Toi.

Si tu acceptes ces 8 points, tu vas construire des systèmes IA solides. Si tu les ignores, tu vas faire la une de LinkedIn — pour les mauvaises raisons.

13. Pour aller plus loin

Sources officielles à consulter (et à remettre à jour régulièrement, car la doc Anthropic bouge) :

• Intro to Claude — docs.claude.com
• Models overview — docs.claude.com
• Token counting — docs.claude.com
• Context windows — docs.claude.com
• Reduce hallucinations — docs.claude.com