Fenêtre de contexte des LLM : comprendre les limites

Quand un assistant IA semble "oublier" une consigne donnée plus tôt ou ignore un passage de votre document, la cause est rarement un défaut de raisonnement. C'est presque toujours une question de fenêtre de contexte : la quantité de texte que le modèle peut réellement prendre en compte en une seule fois. Comprendre cette limite, c'est passer de prompts aléatoires à des résultats fiables, surtout quand vos cas d'usage B2B impliquent des documents longs ou des conversations qui s'étirent.

Ce qu'est vraiment une fenêtre de contexte

La fenêtre de contexte est l'espace de travail temporaire d'un modèle de langage. Elle se mesure en tokens, des fragments de texte plus petits qu'un mot. Tout ce qui doit être pris en compte pour produire une réponse y entre : vos instructions, les documents collés, l'historique de la conversation et la réponse en cours de génération.

Le point clé, souvent mal compris : cette fenêtre est partagée. Si vous remplissez l'essentiel de l'espace avec un long document, il reste moins de place pour la réponse. Et si le total dépasse la limite, quelque chose disparaît, généralement le contenu le plus ancien ou ce qui se trouve au-delà du plafond.

Pour bien situer ce mécanisme dans l'ensemble du fonctionnement des modèles, notre guide des grands modèles de langage pour débuter pose les bases.

Le token, l'unité qui compte

Un modèle ne lit pas des mots ni des caractères, mais des tokens. En ordre de grandeur, un token équivaut à peu près à trois quarts d'un mot en anglais, et un peu moins en français à cause des accents et des terminaisons. Quelques repères utiles :

Un paragraphe dense représente souvent quelques centaines de tokens.
Un document de plusieurs pages peut grimper à plusieurs milliers de tokens.
Le code, les tableaux et les listes consomment proportionnellement plus de tokens que de la prose, car la ponctuation et les sauts de ligne sont eux aussi tokenisés.

Cette unité a une double importance. D'abord, elle détermine si votre contenu tient dans la fenêtre. Ensuite, elle pilote directement la facture, puisque la plupart des fournisseurs facturent au token consommé. Pour transformer ce paramètre en levier budgétaire, voyez comment maîtriser le coût des tokens d'un LLM.

Pourquoi un grand contexte ne suffit pas

Les fenêtres de contexte se sont considérablement élargies ces dernières années. Il est tentant d'en conclure que le problème est résolu : il suffirait de tout envoyer au modèle. C'est une erreur de raisonnement.

Disposer d'une grande fenêtre signifie que le modèle peut accéder à beaucoup de texte. Cela ne signifie pas qu'il l'exploite de façon uniforme. Deux limites persistent :

L'attention n'est pas homogène. Le modèle ne pondère pas chaque passage de la même manière. Plus le contexte est long, plus le signal utile risque d'être dilué dans le bruit.
Le coût et la latence augmentent. Un contexte massif coûte plus cher à traiter et ralentit la réponse. Remplir la fenêtre "au cas où" est rarement une bonne stratégie.

Dans la plupart des cas, une sélection rigoureuse des informations pertinentes bat un volume brut envoyé sans tri.

Le piège du lost in the middle

C'est le phénomène le plus contre-intuitif, et celui qui piège le plus souvent les équipes en production. Les modèles ont tendance à mieux restituer les informations placées au début et à la fin du contexte qu'au milieu. Une consigne capitale ou une donnée critique enfouie au centre d'un long document peut être tout simplement négligée.

Imaginez que vous collez un cahier des charges de dix pages et que la contrainte essentielle figure à la page cinq, noyée entre deux sections secondaires. Le modèle peut produire une réponse cohérente en apparence, mais qui ignore précisément cette contrainte. Le texte était bien dans la fenêtre : il n'a simplement pas reçu assez d'attention.

Les parades concrètes :

Placez les instructions clés en tête de prompt, et rappelez-les en fin si le contexte est long.
Mettez les données critiques aux extrémités plutôt qu'au milieu.
Découpez un document volumineux et ne soumettez que les sections réellement utiles à la tâche.
Demandez explicitement au modèle de citer ou de reformuler la contrainte avant de produire sa réponse, pour vérifier qu'il l'a bien prise en compte.

L'historique de conversation, un budget qui se vide

Dans un échange long, chaque message accumulé occupe de l'espace dans la fenêtre. À mesure que la conversation s'étire, les premiers messages finissent par sortir du cadre. C'est ce qui donne l'impression que l'assistant "perd le fil" ou contredit une consigne donnée trente messages plus tôt.

Quelques pratiques pour garder le contrôle :

Pour une tâche précise, ouvrez une conversation neuve plutôt que d'empiler les sujets dans un fil interminable.
Résumez périodiquement les décisions importantes et réinjectez ce résumé, plus compact que l'historique complet.
Ne laissez pas des documents entiers traîner dans l'historique s'ils ne servent plus à l'étape en cours.

Cette gestion de la mémoire courte rejoint une question plus large, celle de la persistance d'information dans les systèmes IA : nous l'explorons dans notre article sur la mémoire des agents IA, court et long terme.

Cadrer vos prompts pour des réponses fiables

Une fois ces mécanismes compris, la méthode devient claire. L'objectif n'est pas de remplir la fenêtre, mais de la structurer. Une démarche qui se tient :

Définissez la tâche en premier. Le modèle doit savoir ce qu'on attend de lui avant de recevoir les données.
Sélectionnez le contexte utile. Mieux vaut trois sections pertinentes que quarante pages dont la majorité est hors sujet.
Hiérarchisez par position. Instructions et contraintes critiques aux extrémités, matière documentaire au centre.
Bornez la sortie. Demandez un format et une longueur précis pour réserver de l'espace à une réponse complète.
Vérifiez plutôt que de présumer. Sur les enjeux importants, faites confirmer au modèle qu'il a bien intégré les éléments décisifs.

Ce cadrage est exactement le travail qu'un agent IA bien conçu encapsule : un prompt système structuré, un contexte filtré et des garde-fous explicites, pour éviter à l'utilisateur d'avoir à y penser à chaque requête.

La prochaine étape concrète

Reprenez l'un de vos prompts récurrents, celui qui produit des résultats irréguliers. Repérez où sont placées vos consignes et estimez le volume de tokens que vous envoyez. Déplacez les instructions critiques en début de prompt, retirez tout document qui ne sert pas directement la tâche, et testez à nouveau. Dans la plupart des cas, ce simple réagencement améliore la fiabilité sans changer une ligne de votre demande. C'est le réflexe de base avant d'envisager des approches plus lourdes comme la récupération documentaire ou la mise en place d'agents spécialisés.

Questions fréquentes

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

La fenêtre de contexte est la quantité maximale de texte, mesurée en tokens, qu'un modèle de langage peut traiter en une seule fois. Elle inclut à la fois ce que vous envoyez (instructions, documents, historique) et ce que le modèle génère en réponse. Tout ce qui dépasse cette limite est ignoré ou tronqué, ce qui peut faire disparaître des informations importantes.

Un grand contexte garantit-il de meilleures réponses ?

Non. Une fenêtre de contexte plus large permet de fournir plus de matière, mais ne garantit pas que le modèle l'exploite uniformément. Les informations situées au milieu d'un long document sont souvent moins bien restituées que celles placées au début ou à la fin. La qualité dépend autant de la structure de votre prompt que de la taille brute de la fenêtre.

Qu'est-ce que le phénomène lost in the middle ?

C'est la tendance des modèles à mieux retenir les éléments situés en début et en fin de contexte qu'au milieu. Concrètement, si vous insérez une instruction cruciale au centre d'un long document, le modèle risque de la négliger. La parade consiste à placer les consignes clés et les données critiques aux extrémités du prompt.

Comment savoir combien de tokens consomme mon prompt ?

Un token correspond à peu près à trois quarts d'un mot en anglais, un peu moins en français. La plupart des fournisseurs proposent un compteur de tokens ou renvoient cette information dans leur réponse API. En pratique, surveiller le volume de tokens est utile autant pour rester dans la fenêtre que pour maîtriser le coût d'usage.