Contexte long : ce que ça change vraiment de charger 200 pages dans un modèle

La fenêtre de contexte IA est devenue un argument commercial de premier plan. Les annonces se suivent, les chiffres grossissent, et une idée simple s'installe : puisqu'on peut charger deux cents pages d'un coup, la recherche documentaire serait devenue inutile. Il suffirait de tout donner au modèle et de poser sa question.

C'est vrai dans certains cas. C'est faux dans beaucoup d'autres, et la frontière n'est pas là où l'intuition la place. Une grande fenêtre de contexte garantit qu'un texte entre dans le modèle. Elle ne garantit pas qu'il soit exploité de façon uniforme, ni que la réponse soit fiable, ni que l'opération soit économiquement raisonnable à l'échelle d'un usage quotidien.

Cet article explique ce que mesure réellement le chiffre annoncé, pourquoi la qualité de l'attention décroche avant la limite technique, ce que coûte un prompt très long en exploitation, et comment arbitrer entre « tout charger » et une approche par recherche documentaire.

Fenêtre de contexte IA : ce que mesure vraiment le chiffre annoncé

La fenêtre de contexte est le nombre maximal de tokens qu'un modèle peut traiter en une seule fois, entrée et sortie confondues. Le token est l'unité de découpage du texte : ni un mot, ni un caractère, mais un fragment fréquent. En anglais, un token représente en moyenne un peu moins d'un mot. En français, le découpage est moins favorable : comptez plutôt un token pour trois à quatre caractères, ce qui donne environ 1,3 à 1,5 token par mot.

Traduisons en volumes concrets, avec l'hypothèse d'une page de 400 mots :

Premier enseignement : deux cents pages tiennent largement dans les fenêtres modernes. Deux mille pages, non, et c'est déjà le volume documentaire d'un service juridique ou d'un support technique de taille moyenne. La question du « tout charger » se pose donc pour un dossier, pas pour un corpus.

Second enseignement, plus mécanique : le contexte est sans mémoire d'un appel à l'autre. Chaque requête renvoie l'intégralité du contenu. Si vous chargez 120 000 tokens pour poser une question, puis une deuxième, puis une troisième, vous avez transmis 360 000 tokens. Cette propriété gouverne tout le calcul économique de la section suivante.

Pourquoi l'attention ne suit pas la taille annoncée

C'est le point que les fiches produit passent sous silence. Un modèle peut accepter un contexte long sans pour autant en exploiter uniformément le contenu.

Deux résultats de recherche cadrent le phénomène. Le premier, publié en 2023 sous le titre « Lost in the Middle », montre que la performance d'un modèle sur une tâche de recherche d'information dans un long contexte suit une courbe en U : les éléments placés au début et à la fin du contexte sont bien exploités, ceux situés au milieu le sont nettement moins. L'écart n'est pas marginal, et il persiste sur des modèles conçus pour le contexte long.

Le second, le banc d'essai RULER publié en 2024, va plus loin. Il constate que malgré une précision quasi parfaite sur le test classique de l'aiguille dans une botte de foin, presque tous les modèles évalués chutent nettement à mesure que le contexte s'allonge. Sa conclusion la plus citée : seule la moitié environ des modèles annonçant une prise en charge de 32 000 tokens maintenaient à cette longueur une performance satisfaisante sur des tâches plus exigeantes que la simple récupération d'une phrase insérée.

La raison est intuitive. Retrouver une phrase distinctive plantée dans un texte long est facile : elle détonne. Les tâches réelles ressemblent rarement à cela. Elles demandent de croiser trois passages éloignés, de compter des occurrences, de suivre une chaîne de renvois, ou de repérer une absence. Ce sont ces tâches qui se dégradent.

Conséquence pratique immédiate : plus votre question exige d'agrégation ou de recoupement, moins vous pouvez compter sur un chargement massif. Et une question du type « ce document mentionne-t-il une clause de réversibilité ? » est particulièrement piégeuse, car une absence ne produit aucun signal saillant.

Ce que coûte vraiment un prompt de 120 000 tokens

Le raisonnement économique se fait sur des hypothèses, puisque les tarifs varient selon les fournisseurs et les gammes de modèles. Prenons une hypothèse de travail simple et volontairement ronde : 3 euros par million de tokens d'entrée.

Le rapport est de un à vingt. Sur un mois d'exploitation, l'écart passe de quelques dizaines d'euros à plus de deux mille. Ce n'est pas un détail de facture : c'est ce qui décide de la viabilité d'un assistant interne.

Deux nuances importantes tempèrent ce calcul. D'abord, la mise en cache des préfixes de prompt, proposée par la plupart des fournisseurs, réduit fortement le coût de la portion identique répétée d'un appel à l'autre. Si vos deux cents pages ne changent pas et que le cache est bien utilisé, la facture réelle descend sensiblement. Ensuite, une approche par recherche documentaire a un coût propre : vectorisation initiale, stockage, maintenance de l'index. Ce coût est fixe et modeste, mais il n'est pas nul, comme nous l'avons vu à propos des embeddings et de la vectorisation.

La latence mérite autant d'attention que le prix. Un utilisateur qui attend huit secondes avant le premier mot d'une réponse abandonne l'outil, même si la réponse finit par être excellente. Sur un assistant conversationnel interne, la latence est souvent le facteur d'adoption numéro un.

Quand « tout charger » est le bon choix

Le contexte long n'est pas un piège, c'est un outil avec un domaine d'emploi. Il est supérieur dans quatre situations.

• Le document est unique, cohérent et consulté ponctuellement. Un appel d'offres de 150 pages à analyser une fois, un rapport annuel, un cahier des charges. Monter une chaîne de recherche documentaire pour trois requêtes n'a aucun sens.
• La question porte sur la structure globale. Résumer, comparer deux versions, produire un plan, repérer les contradictions d'ensemble : ces tâches supposent de voir le document entier, et une recherche par extraits les sabote par construction.
• Le découpage ferait perdre le sens. Un code source, un contrat dont les définitions conditionnent toutes les clauses, un procès-verbal où l'ordre des interventions compte.
• Le corpus est petit et stable. En dessous de quelques dizaines de milliers de tokens, une chaîne de recherche documentaire ajoute de la complexité pour un gain nul.

Quand la recherche documentaire reste supérieure

À l'inverse, quatre situations disqualifient le chargement massif.

• Le corpus dépasse la fenêtre. Cas le plus simple : au-delà de quelques milliers de pages, la question ne se pose plus.
• Les requêtes sont nombreuses et répétitives. Un assistant interrogé cent fois par jour par vingt personnes ne peut pas recharger le corpus à chaque fois, pour des raisons de coût et de latence.
• Les documents changent souvent. Une base de connaissances mise à jour chaque semaine se maintient plus simplement dans un index que dans des prompts figés.
• La traçabilité est exigée. Une chaîne de type recherche augmentée sur les documents d'entreprise sait dire de quel passage vient la réponse. Un contexte massif produit une réponse dont on ne sait pas d'où elle sort, ce qui est rédhibitoire dès qu'un contrôle est prévu.

Un point souvent oublié : le contexte long dégrade aussi la gouvernance. Charger un corpus entier revient à donner à chaque utilisateur l'accès à tout son contenu, puisque le modèle peut restituer n'importe quel passage. Une architecture par recherche permet de filtrer les documents accessibles selon les droits de la personne qui pose la question. Sur des données de ressources humaines ou de rémunération, cette différence n'est pas négociable.

Une règle de décision en quatre questions

Voici la grille que nous utilisons pour trancher, dans l'ordre.

1. Le corpus tient-il dans la fenêtre ? Si non, la question est réglée : recherche documentaire.
2. Combien de requêtes par jour sur le même corpus ? Au-delà d'une vingtaine, le calcul économique bascule presque toujours vers la recherche, sauf mise en cache très efficace.
3. La question est-elle globale ou ponctuelle ? Globale (résumé, comparaison, cohérence d'ensemble) : contexte long. Ponctuelle (où est-il écrit que...) : recherche.
4. Faut-il citer la source et filtrer les droits ? Si oui : recherche, sans hésiter.

Une approche mixte est souvent la meilleure et elle est sous-employée. On sélectionne d'abord les cinq à dix documents pertinents par une recherche, puis on les charge entiers dans le contexte plutôt qu'en fragments. On évite ainsi le découpage qui perd le sens, tout en restant à 30 000 ou 40 000 tokens au lieu de 500 000. C'est le compromis qui donne les meilleurs résultats sur les corpus de taille intermédiaire.

Deux réflexes de mise en œuvre valent d'être retenus, quelle que soit l'approche. Placez les instructions importantes à la fin du prompt plutôt qu'au début quand le contexte est long, puisque la fin est mieux exploitée que le milieu. Et testez la dégradation chez vous : prenez dix questions dont vous connaissez la réponse, faites-les tourner sur un contexte court puis sur le contexte complet, et comparez. Un quart d'heure de test vaut mieux qu'une longueur annoncée sur une fiche produit. Cela suppose de comprendre ce qui se passe sous le capot, sujet que nous avons abordé dans notre explication du fonctionnement d'un modèle de langage.

Ce qu'il faut retenir

Une grande fenêtre de contexte IA est une commodité, pas une architecture. Elle supprime une contrainte technique réelle et simplifie beaucoup de traitements ponctuels sur des documents longs. Elle ne supprime ni la dégradation de l'attention au milieu du contexte, ni le coût par requête, ni le besoin de citer ses sources, ni la question des droits d'accès.

La bonne question n'est pas « quelle est la plus grande fenêtre disponible » mais « combien de fois par jour vais-je poser une question sur ce corpus, et devrai-je justifier la réponse ». Répondez à ces deux points et le choix entre contexte long et recherche documentaire se fait tout seul, sur des chiffres plutôt que sur une impression.