Comment fonctionnent réellement les LLMs

Un grand modèle de langage est un réseau de neurones entraîné à prédire le prochain token dans une séquence ; il convertit du texte en vecteurs numériques, utilise l’attention pour permettre à chaque token de rassembler le contexte des autres, et génère la sortie un token à la fois en échantillonnant depuis une distribution de probabilité sur son vocabulaire. Ce mécanisme unique — prédire un token, l’ajouter, prédire le suivant — constitue le moteur complet de ChatGPT, GitHub Copilot, Claude et Gemini. Tout le reste n’est qu’une question d’échelle, de procédure d’entraînement et d’ingénierie construite par-dessus.

Si vous utilisez ces outils quotidiennement sans jamais avoir regardé sous le capot, les comportements que vous avez remarqués — des réponses erronées formulées avec assurance, une conversation qui « oublie » comment elle a commencé, des sorties radicalement différentes à partir d’une invite légèrement reformulée, une incapacité à compter les lettres dans « strawberry » — ne sont pas des bizarreries aléatoires. Chacun découle directement des mécanismes internes. Cet article vous donne un modèle mental précis de ces mécanismes : les tokens et les embeddings, les couches d’attention et feed-forward du transformer, les trois phases d’entraînement, la façon dont la génération échantillonne réellement le texte, et une liste nommée des idées reçues que le mot « réellement » dans le titre est là pour corriger.

Ce qu’est réellement un LLM : la prédiction du prochain token

Dans son essence, un grand modèle de langage résout un problème étroit, encore et encore : étant donné une séquence de tokens, quel token vient ensuite ? Il formule cela comme un problème de classification sur l’ensemble de son vocabulaire — des dizaines de milliers de tokens possibles — et produit une probabilité pour chacun. Le modèle en sélectionne un, l’ajoute à la séquence, et recommence l’ensemble du processus. La génération de texte est cette boucle qui s’exécute jusqu’à une condition d’arrêt.

Cette reformulation est l’intuition fondamentale. « Écris une fonction qui applique un debounce à un callback » n’est pas une commande pour laquelle le modèle recherche une réponse. C’est une invite que le modèle continue, token par token, parce que les séquences ressemblant à cette invite étaient, dans ses données d’entraînement, suivies de séquences ressemblant à du code fonctionnel. Le modèle est un moteur de continuation pointé vers votre entrée.

L’architecture qui a permis à cela de fonctionner à grande échelle est le transformer, introduit dans l’article de 2017 Attention Is All You Need par Vaswani et al. Le « GPT » dans ChatGPT signifie Generative Pre-trained Transformer. Avant les transformers, les modèles traitaient le texte plus ou moins de gauche à droite et peinaient à connecter des mots éloignés dans une phrase ; l’attention a permis à un modèle de pondérer chaque token par rapport à tous les autres en parallèle, ce qui a débloqué à la fois la qualité et la vitesse d’entraînement.

Tokens et embeddings : comment le texte devient des nombres

Avant qu’un modèle puisse faire quoi que ce soit avec votre invite, il découpe le texte en tokens — des fragments de sous-mots, ni des mots entiers ni des lettres — et associe chaque token à un nombre. Un token peut être un mot entier (" the"), un fragment de mot ("ing"), un seul caractère, ou de la ponctuation. Cette étape de tokenisation est invisible dans l’interface de chat, mais elle explique toute une catégorie d’échecs.

Parce que le modèle lit des tokens de sous-mots plutôt que des lettres individuelles, lui demander de compter les lettres d’un mot va à l’encontre de la façon dont il représente le texte — c’est pourquoi les tâches de comptage de lettres et d’orthographe échouent plus souvent que la fluidité générale du modèle ne le suggérerait. Le modèle ne « voit » jamais les trois r dans « strawberry » ; il voit quelques identifiants entiers opaques représentant des fragments de tokens, les lettres ayant été absorbées dans ces fragments.

Vous pouvez observer ce phénomène avec le tokeniseur open source tiktoken d’OpenAI :

# pip install tiktoken
import tiktoken

enc = tiktoken.get_encoding("cl100k_base")
ids = enc.encode("strawberry")
print(ids)                       # a short list of integer token IDs
print([enc.decode([i]) for i in ids])  # the sub-word chunks, not letters

Exécutez-le et vous obtenez une poignée d’identifiants entiers, chacun se décodant en un fragment de plusieurs caractères — pas dix lettres séparées. Le modèle opère sur ces identifiants. Compter les caractères nécessiterait des informations que la tokenisation a éliminées, c’est pourquoi le modèle approxime et se trompe fréquemment.

Chaque identifiant de token est ensuite associé à un embedding : une longue liste de nombres (un vecteur) qui positionne le token dans un « espace de mots » à haute dimension. Dans cet espace, les mots similaires se regroupent — cat se trouve près de dog, kitten et pet — et la géométrie encode le sens. La démonstration classique vient de word2vec (Mikolov et al., 2013), qui a montré que l’arithmétique vectorielle capture des relations : approximativement, biggest − big + small ≈ smallest, et Paris − France + Italy ≈ Rome. Ces mêmes vecteurs héritent des biais humains présents dans le texte d’entraînement, c’est pourquoi doctor − man + woman peut dériver vers nurse. Les embeddings sont appris pendant l’entraînement, pas construits à la main.

À l’intérieur du transformer : couches d’attention et feed-forward

Un transformer est une pile de couches identiques, chacune effectuant deux tâches en séquence : une étape d’attention, où les tokens puisent du contexte auprès des autres tokens, et une étape feed-forward, où le modèle applique les connaissances stockées dans ses poids à chaque token individuellement. Un modèle de pointe empile des dizaines de ces couches, affinant la représentation de chaque token un peu plus à chaque niveau. Les premières couches gèrent la structure locale comme la grammaire et l’ambiguïté ; les couches ultérieures suivent le sens de plus haut niveau — qui a fait quoi à qui, et de quoi traite le passage.

L’attention fonctionne comme un service de mise en relation. Pour chaque token, le modèle produit un vecteur de requête (« que cherche-je ? ») et un vecteur de clé (« que puis-je offrir ? »). Il compare chaque requête à chaque clé, et lorsqu’elles correspondent, des informations circulent entre ces tokens. Dans la phrase « When John gave the book to Mary, she thanked him », l’attention est le mécanisme qui relie « she » à « Mary » et « him » à « John » afin que les couches ultérieures puissent l’utiliser. Une seule couche exécute de nombreuses opérations d’attention de ce type — appelées têtes — en parallèle, chacune apprenant à suivre un type de relation différent.

L’étape feed-forward est là où résident les faits appris. Après que l’attention a rassemblé le contexte pertinent, le réseau feed-forward traite chaque token individuellement, le transformant en fonction des patterns absorbés pendant l’entraînement. La division du travail est claire : l’attention récupère les informations depuis l’invite qui lui est présentée, tandis que les couches feed-forward fournissent les informations apprises depuis le corpus d’entraînement. Lorsque le modèle complète « The capital of Poland is » par « Warsaw », ce fait provient des poids feed-forward, et non de quoi que ce soit dans votre invite.

Pour l’algèbre linéaire et les équations exactes derrière l’attention, l’article original sur le transformer est la source primaire. Le modèle mental — faire correspondre, rassembler le contexte, puis appliquer les connaissances stockées, répété sur de nombreuses couches — est suffisant pour raisonner sur le comportement.

Comment les LLMs sont entraînés : pré-entraînement, fine-tuning et RLHF

L’entraînement se déroule en trois étapes : le pré-entraînement auto-supervisé, où le mot suivant dans un texte ordinaire constitue sa propre étiquette ; le fine-tuning par instructions sur des paires invite–réponse rédigées par des humains ; et l’apprentissage par renforcement à partir des retours humains (RLHF), qui aligne les sorties du modèle sur les préférences humaines. Chaque étape produit un type de modèle différent.

Le pré-entraînement est auto-supervisé : parce que le mot suivant correct est déjà présent dans le texte, le signal d’entraînement est gratuit et pratiquement illimité — chaque phrase sur internet est un exemple étiqueté. Le modèle commence avec des poids aléatoires, prédit très mal, et s’améliore sur des centaines de milliards d’exemples en ajustant ses poids pour réduire l’erreur de prédiction (la mathématique de cet ajustement est la rétropropagation, bien documentée par ailleurs). L’article sur les lois d’échelle de 2020 (Kaplan et al.) a constaté que la précision du modèle s’améliore selon une loi de puissance avec la taille du modèle, les données d’entraînement et la puissance de calcul — le résultat empirique qui a justifié la construction de modèles toujours plus grands.

Un modèle purement pré-entraîné n’est qu’un compléteur. Demandez-lui « What is your first name? » et il pourrait continuer avec « What is your last name? » parce que c’est une continuation plausible, non parce qu’il est peu coopératif. Le fine-tuning par instructions et le RLHF corrigent cela. Le pipeline pour transformer un modèle brut en assistant a été décrit dans l’article InstructGPT (Ouyang et al., 2022), le travail directement à l’origine de ChatGPT, qui a été lancé en préversion publique de recherche le 30 novembre 2022. La plupart des modèles de chat actuels sont entraînés avec une variante de ce pipeline, bien que les recettes exactes soient propriétaires.

Deux remarques sur les chiffres. Les données fréquemment citées pour GPT-3 — 175 milliards de paramètres, 96 couches, des embeddings de dimension 12 288, un vocabulaire de 50 257 tokens — proviennent de l’article GPT-3 de 2020 et sont utiles comme illustration concrète, pas comme spécification actuelle. Les laboratoires de pointe ne publient plus le nombre de paramètres de leurs derniers modèles : il n’existe aucun chiffre officiel de paramètres pour la série GPT-5 actuelle, Claude Opus/Sonnet/Haiku, ou les lignes Gemini 3.x. Considérez toute affirmation de « X mille milliards de paramètres » concernant un modèle actuel comme une rumeur.

Comment fonctionne la génération : échantillonnage, température et pourquoi la sortie est probabiliste

Lorsqu’un LLM génère du texte, il exécute la boucle de prédiction un token à la fois et échantillonne le prochain token depuis la distribution de probabilité qu’il calcule — il n’émet pas simplement « la réponse ». Voici la boucle en pseudocode :

tokens = tokenize(prompt)
while not done:
    logits = model.forward(tokens)        # one score per vocabulary token
    probs  = softmax(logits / temperature) # convert scores to probabilities
    next_token = sample(probs)             # pick one, weighted by probability
    tokens.append(next_token)
    if next_token == END_OF_TEXT:
        break
output = detokenize(tokens)

Le paramètre temperature contrôle la façon dont les scores deviennent des probabilités. Par défaut, un LLM est probabiliste, et non déterministe : une température supérieure à zéro signifie que la même invite peut produire des réponses différentes, car le modèle échantillonne depuis une distribution plutôt que de toujours sélectionner le token le plus probable. À une température de 0, le modèle devient glouton — il sélectionne toujours le token en tête — ce qui est approximativement déterministe et adapté au code ou à l’extraction. Des températures plus élevées aplatissent la distribution, rendant les tokens de faible probabilité plus susceptibles d’être choisis et la sortie plus variée. Le réglage temperature est documenté dans la référence de l’API OpenAI et la référence de l’API Messages d’Anthropic ; les deux l’exposent par requête.

C’est pourquoi relancer la même invite dans ChatGPT peut vous donner une réponse différente à chaque fois, et pourquoi « mettre la température à 0 » est le conseil standard lorsque vous avez besoin d’une sortie reproductible depuis une API.

Idées reçues courantes sur les LLMs

Plusieurs croyances intuitives sur le fonctionnement des LLMs sont erronées, et chaque croyance erronée amène les développeurs à mal utiliser les outils ou à mal interpréter leurs échecs. Le mot « réellement » dans le titre de cet article est là pour les corriger.

Ce n’est pas une recherche dans une base de données. Un LLM ne recherche pas des réponses dans une base de données — il ne dispose d’aucune table de faits stockés à récupérer ; il calcule une nouvelle distribution de probabilité sur l’ensemble de son vocabulaire à chaque étape, puis sélectionne un token et recommence. Présenter les paramètres comme « une base de connaissances » est trompeur : les poids encodent des régularités statistiques, pas des enregistrements indexés.

Il ne connaît pas sa réponse à l’avance. Le modèle ne connaît pas sa réponse avant de l’écrire : chaque token est choisi en fonction de tous les tokens qui le précèdent, donc le « raisonnement » que vous voyez est produit de gauche à droite, et non récupéré en bloc. C’est pourquoi un modèle peut commencer une phrase avec assurance et se retrouver dans une impasse — il n’y a pas de plan qui est lu, juste une continuation qui est calculée.

Pourquoi les LLMs se comportent comme ils le font

Une fois que vous comprenez le mécanisme, les comportements quotidiens de ces outils cessent d’être mystérieux. Chacun est une conséquence directe de la prédiction du prochain token sur des probabilités apprises.

L’hallucination. L’hallucination n’est pas un bug greffé sur le système — c’est le comportement par défaut d’un modèle optimisé pour produire du texte statistiquement plausible, qui est récompensé pour paraître juste plutôt que pour l’être réellement. Lorsque le modèle n’a pas de signal fort pour un fait, il produit quand même la continuation la plus plausible en apparence, avec un ton assuré, parce que le texte confiant domine ses données d’entraînement. Un nom de fonction inventé ou une citation inexistante est le modèle faisant exactement ce pour quoi il a été entraîné.

Les fenêtres de contexte. Une fenêtre de contexte est le nombre fixe de tokens que le modèle peut prendre en compte à la fois ; tout ce qui dépasse cette limite est simplement invisible pour le modèle, c’est pourquoi une longue conversation finit par « oublier » comment elle a commencé. En juin 2026, les modèles de pointe actuels convergent autour d’une fenêtre d’environ un million de tokens — Gemini 3.5 Flash gère 1 048 576 tokens en entrée, Claude Opus 4.8 propose une fenêtre de 1 million de tokens par défaut, et la série GPT-5 offre une fenêtre de 1 million de tokens via l’API. Grande, mais toujours fixe : une fois que votre conversation ou base de code la dépasse, les tokens les plus anciens tombent hors de ce que le modèle peut voir.

Sensibilité aux invites, chaîne de pensée et few-shot. La formulation exacte de votre invite modifie la distribution de probabilité, et donc la réponse, parce que la sortie est calculée token par token à partir des tokens précédents. Cette même propriété explique pourquoi les techniques de prompting fonctionnent. Le prompting few-shot (montrer des exemples résolus) amorce le contexte avec le pattern que vous souhaitez voir continué. Le prompting par chaîne de pensée (« think step by step ») fonctionne parce que le texte généré par le modèle lui-même devient une partie de l’entrée qu’il lit ensuite — les étapes intermédiaires agissent comme une mémoire de travail sur laquelle le modèle peut s’appuyer, au lieu de forcer la réponse finale en un seul saut.

Le grounding et le RAG. La génération augmentée par récupération (RAG) place les documents pertinents directement dans l’invite, afin que le modèle puisse extraire des faits par attention (l’invite qui lui est présentée) plutôt que depuis ses poids feed-forward avec perte d’information. C’est pourquoi un modèle disposant d’une recherche web ou de vos documents dans son contexte est plus précis sur les détails — vous avez déplacé la charge de « se souvenir depuis l’entraînement » vers « lire depuis l’invite », ce que l’architecture fait de manière bien plus fiable.

La question des « perroquets stochastiques »

La question de savoir si la prédiction du prochain token équivaut à une véritable compréhension ou à une imitation sophistiquée est ouverte et contestée. Le point de vue sceptique a été cristallisé dans l’article de 2021 On the Dangers of Stochastic Parrots (Bender, Gebru, et al.), qui soutenait qu’un modèle assemblant du texte d’entraînement selon la vraisemblance statistique, sans ancrage dans le sens, est davantage un perroquet qu’un esprit. Le point de vue opposé soutient que prédire suffisamment bien le texte exige un modèle compressé et utilisable du monde qu’il décrit. Les mécanismes présentés dans cet article sont établis ; cette interprétation ne l’est pas, et vous n’avez pas besoin de la résoudre pour bien utiliser ces outils.

Ce dont vous avez besoin, c’est du modèle mécanique : des tokens en entrée, des couches d’attention et feed-forward les affinant à travers de nombreuses couches de transformer, une distribution de probabilité en sortie, un token à la fois. Gardez cette image en tête et la prochaine fois que Copilot invente une méthode ou que ChatGPT se contredit trois tours après le début d’une conversation, vous saurez exactement quelle partie de la machine l’a produit — et, tout aussi utile, quel changement d’invite ou quelle étape de récupération le corrigera.

FAQ

Quelle est la différence entre un token et un mot dans un LLM ?

Un token est un fragment de sous-mot, pas un mot. Le tokeniseur découpe le texte en morceaux qui peuvent être un mot entier, un fragment de mot comme 'ing', un seul caractère, ou de la ponctuation, puis associe chacun à un identifiant entier. Un mot courant peut constituer un seul token, tandis qu'un mot plus rare se divise en plusieurs. Le modèle opère uniquement sur ces identifiants de tokens, jamais sur des mots ou des lettres bruts, ce qui explique pourquoi les tâches au niveau des caractères, comme le comptage de lettres, vont à l'encontre de la façon dont il représente le texte.

Augmenter la fenêtre de contexte améliore-t-il la précision d'un LLM ?

Pas directement. Une fenêtre de contexte plus grande permet seulement au modèle de prendre en compte plus de tokens à la fois ; cela ne le rend pas meilleur en raisonnement ou en rappel. La qualité peut toujours se dégrader lorsque des informations pertinentes se trouvent loin de l'endroit où elles sont nécessaires, et placer trop de texte non pertinent dans l'invite peut diluer le signal. L'avantage est que moins de tokens antérieurs tombent hors de la fenêtre, donc le modèle « oublie » moins d'une longue conversation ou d'un document.

Si je mets la température à 0, un LLM donnera-t-il toujours une sortie identique ?

Une température de 0 rend la génération gloutonne, sélectionnant toujours le token de plus haute probabilité, ce qui est approximativement déterministe pour un modèle et une invite donnés. En pratique, la reproductibilité exacte n'est pas toujours garantie entre les appels API en raison de facteurs tels que le non-déterminisme en virgule flottante sur le matériel parallèle, les changements de version du modèle, et le routage côté fournisseur. La température 0 est le bon réglage lorsque vous avez besoin d'une sortie cohérente pour du code ou de l'extraction, mais considérez-la comme quasi-déterministe plutôt que comme une garantie absolue.

Pourquoi la génération augmentée par récupération réduit-elle les hallucinations ?

Le RAG place les documents pertinents directement dans l'invite, afin que le modèle puisse extraire des faits par attention sur le texte qui lui est présenté, plutôt que depuis ses poids feed-forward avec perte d'information. L'architecture récupère les informations depuis l'invite de manière bien plus fiable qu'elle ne rappelle des patterns diffus appris pendant l'entraînement. Cela déplace la tâche de 'se souvenir de ce fait' vers 'lire ce fait', ce qui explique pourquoi un modèle disposant de vos documents ou de résultats web dans son contexte répond plus précisément aux détails, bien qu'il puisse toujours mal lire ou mal utiliser ce qui lui est fourni.