Tokens et fenêtre de contexte : ce qu'un LLM lit pour répondre

Un LLM, pour large language model ou grand modèle de langage, ne lit pas une demande comme un humain lit une page. Il reçoit une suite d'unités appelées tokens, les traite dans une fenêtre de contexte, puis produit une réponse. Cette mécanique explique beaucoup de comportements qui paraissent étranges : une IA peut ignorer une consigne noyée dans un long échange, ralentir quand on lui donne trop de matière ou répondre à côté si le contexte utile n'est pas là.

En langage simple, la fenêtre de contexte est le dossier posé sur la table du modèle au moment où il répond. Tout ce qui n'est pas dans ce dossier est invisible pour cette requête. Tout ce qui y entre prend de la place, coûte des tokens et peut aider ou distraire.

Qu'est-ce qu'un modèle de langage ?

Un modèle est le moteur qui transforme une entrée en sortie. Dans le cas d'un LLM, l'entrée peut être une question, un brief, un extrait de document, un historique de conversation ou des résultats d'outils. La sortie peut être une réponse, un résumé, une classification, un plan d'action ou un texte structuré.

Le modèle ne consulte pas automatiquement vos fichiers, votre CRM ou votre site. Il ne voit que ce que le système lui fournit : le prompt, les messages précédents retenus, les documents récupérés, les outils disponibles et parfois une mémoire. Cette distinction est importante pour les usages en entreprise. Si une réponse doit s'appuyer sur des procédures internes, ces procédures doivent entrer dans le contexte ou être retrouvées par un système comme le RAG.

Qu'est-ce qu'un token ?

Un token est une petite unité de texte manipulée par le modèle. Ce n'est pas exactement un mot. Un mot court peut tenir en un token. Un mot long, un nom propre, un morceau de code ou une ponctuation peuvent être découpés autrement. Google explique dans sa documentation Gemini que les tokens servent à compter ce qu'un modèle reçoit et génère, et que la fenêtre de contexte limite l'ensemble entrée plus sortie selon le modèle utilisé : Understand and count tokens.

Pour un dirigeant ou une équipe métier, il faut retenir trois effets.

Plus vous envoyez de texte, plus vous consommez de tokens d'entrée.
Plus vous demandez une réponse longue ou un raisonnement coûteux, plus vous consommez de tokens de sortie.
Le modèle a une limite : il ne peut pas tout garder indéfiniment dans la même requête.

Les tokens sont donc à la fois une unité technique, une unité de coût et une contrainte de design.

Qu'est-ce que la fenêtre de contexte ?

La fenêtre de contexte, ou context window, désigne la quantité maximale d'information qu'un modèle peut considérer pour générer sa prochaine réponse. Elle inclut généralement les instructions système, le prompt utilisateur, l'historique retenu, les documents injectés, les définitions d'outils et la place nécessaire à la réponse.

La documentation Claude précise que la taille de cette fenêtre dépend du modèle et que les tokens d'entrée et de sortie comptent dans cette limite : Context windows. La documentation Gemini donne la même logique : le contexte est l'information transmise au modèle, puis le modèle génère sa réponse depuis ce contexte : Long context.

Une grande fenêtre de contexte est utile pour analyser un contrat, un dossier client ou un long historique. Elle ne remplace pas le tri. Donner plus de matière peut améliorer la réponse si cette matière est pertinente. Donner tout le dossier peut aussi introduire du bruit, des contradictions et des consignes périmées.

Prompt, contexte et output : les trois zones à distinguer

Le prompt est l'instruction donnée au modèle. On peut le traduire par consigne ou brief. Il dit ce qu'il faut faire, pour qui, avec quelles limites et dans quel format.

Le contexte est la matière disponible pour exécuter cette consigne : documents, messages, données retrouvées, règles métier, historique utile. Le prompt dirige. Le contexte alimente.

L'output, ou sortie, est ce que le modèle produit : texte, tableau, e-mail, résumé, prochaine action ou JSON, un format de données structuré. Dans l'API (application programming interface, interface de programmation applicative) OpenAI, les guides de génération de texte et de prompting distinguent aussi les instructions, les entrées et les formats de sortie attendus : Text generation et Prompt engineering.

Quand un usage IA échoue, le problème vient souvent d'un mélange entre ces trois zones. On demande un format précis, mais on ne fournit pas l'information. On donne beaucoup d'information, mais aucune priorité. On exige une réponse courte, mais on laisse dix règles contradictoires dans l'historique.

Reasoning et reasoning effort : pourquoi certaines réponses coûtent plus cher

Le reasoning, ou raisonnement, désigne le travail intermédiaire du modèle pour résoudre une tâche. Certains modèles permettent de régler un reasoning effort, c'est-à-dire un niveau d'effort de raisonnement. Dans la documentation OpenAI, ce réglage guide le modèle sur la quantité de travail à consacrer à la tâche ; un effort plus faible favorise la vitesse et l'usage réduit de tokens, tandis qu'un effort plus élevé peut améliorer les tâches complexes : Reasoning models.

Ce réglage ne rend pas un mauvais brief fiable. Il aide surtout quand la tâche demande plusieurs étapes : comparer des options, vérifier des contraintes, résoudre un problème technique, planifier une exécution ou arbitrer un cas ambigu.

Sur une tâche simple, demander plus de raisonnement peut seulement augmenter la latence et le coût. Pour trier un e-mail ou extraire une date, un effort faible suffit souvent. Pour analyser un dossier client contradictoire, il peut être justifié de laisser plus de place au raisonnement.

Le context rot : quand trop de contexte dégrade la réponse

Le context rot, ou dégradation du contexte, décrit un phénomène simple : plus le contexte grossit, plus il peut devenir difficile pour le modèle de garder le bon signal. Anthropic l'explique dans son article sur le context engineering : le contexte est une ressource finie, et ajouter des tokens inutiles peut disperser l'attention du modèle : Effective context engineering for AI agents.

Dans une conversation longue, le context rot peut apparaître de plusieurs façons.

Une ancienne consigne contredit la nouvelle.
Un détail secondaire devient plus visible que l'objectif.
Le modèle reprend une hypothèse périmée.
Les documents injectés contiennent trop de passages faibles.
La réponse ralentit sans gagner en qualité.

La solution n'est pas toujours de changer de modèle. Souvent, il faut réduire le dossier : garder les sources utiles, retirer l'historique mort, résumer les décisions validées et replacer l'objectif actuel au-dessus du bruit.

Exemple concret : une demande commerciale

Imaginez une entreprise qui veut utiliser une IA pour répondre à une demande entrante.

Le mauvais contexte ressemble à ceci : tout l'historique du site, les anciennes offres, trois versions de tarifs, des notes internes, un long échange commercial et une consigne vague : « réponds au prospect ».

Le bon contexte est plus court :

demande du prospect ;
offre actuelle ;
règles de qualification ;
contraintes de ton ;
informations manquantes à demander ;
format attendu pour le brouillon ;
règle de validation humaine avant envoi.

Le modèle a moins de matière, mais une matière plus utile. Il peut produire un brouillon clair, lister les inconnues et éviter de promettre ce que l'entreprise ne contrôle pas. Pour un agent IA plus autonome, cette logique rejoint les limites décrites dans Agent IA en entreprise.

Mini-expérience : voir ce qui entre dans le contexte

Voici une expérience simple à reproduire dans n'importe quel assistant IA.

Copiez ce prompt :

Tu vas répondre uniquement à partir du bloc CONTEXTE.
Si l'information n'est pas dans le bloc, réponds : "Information absente du contexte."

CONTEXTE
- Offre A : réponse sous 24 h.
- Offre B : réponse sous 4 h.

QUESTION
Quelle offre garantit une réponse sous 4 h ?

Le modèle doit répondre : Offre B.

Maintenant, remplacez le contexte par ceci :

Tu vas répondre uniquement à partir du bloc CONTEXTE.
Si l'information n'est pas dans le bloc, réponds : "Information absente du contexte."

CONTEXTE
- Offre A : réponse sous 24 h.
- Offre B : réponse prioritaire.

QUESTION
Quelle offre garantit une réponse sous 4 h ?

La bonne réponse est : information absente du contexte. Si le modèle invente « Offre B », le problème n'est pas la question. Le problème est la discipline demandée au modèle et le contrôle de la sortie.

Dernière variante : ajoutez vingt lignes inutiles entre les deux offres et la question, puis répétez le test dans une conversation neuve. Ce petit essai ne constitue pas un benchmark : il montre simplement quelle matière vous envoyez au modèle et pourquoi un contexte encombré devient plus difficile à auditer. Le contexte n'est pas un placard infini, mais un espace de travail à tenir propre.

Comment réduire coût et latence

Le coût et la latence suivent des règles assez directes.

Envoyer moins de texte inutile réduit les tokens d'entrée.
Demander une sortie plus courte réduit les tokens de sortie.
Choisir un effort de raisonnement adapté évite de payer un raisonnement lourd pour une tâche simple.
Utiliser un RAG évite d'injecter toute une base documentaire quand seuls quelques passages sont nécessaires.
Découper un processus en étapes peut être plus fiable qu'un prompt gigantesque.

Pour une PME, la bonne question n'est pas « quel modèle a la plus grande fenêtre ? ». C'est plutôt : « quelle information minimale doit être visible pour prendre la bonne prochaine action ? ». Cette logique rejoint la méthode de cadrage dans Automatisation IA en PME.

FAQ

Un token est-il un mot ?

Non. Un token peut être un mot, un morceau de mot, un signe ou un morceau de code. Le découpage dépend du modèle et du tokenizer, ou outil de découpage en tokens.

Une grande fenêtre de contexte rend-elle le RAG inutile ?

Non. Une grande fenêtre aide pour des dossiers longs. Le RAG reste utile pour retrouver les bons passages, citer les sources et éviter d'envoyer toute la base à chaque requête.

Pourquoi l'IA oublie-t-elle une consigne ?

Elle peut ne plus être dans le contexte, être contredite par une autre consigne ou être noyée dans un historique trop long. Le prompt doit clarifier la priorité.

Faut-il toujours demander plus de raisonnement ?

Non. L'effort de raisonnement doit suivre la difficulté. Une extraction simple n'a pas besoin du même effort qu'un arbitrage complexe.

Sources de référence

Par Anthony Dalin

Publié le 16 août 2026

Une question précise ? Posez-la au chat →