Vous convoquez une réunion stratégique. La salle fait vingt places. Vous regardez votre liste d’invités — marketing, finance, produit, juridique, terrain, direction — et vous comprenez qu’il va falloir arbitrer. Certains dossiers entreront dans la salle, d’autres resteront dehors. Et chaque participant supplémentaire alourdira la délibération.
La fenêtre de contexte, en trois phrases
La fenêtre de contexte, c’est la quantité maximale de texte qu’une IA peut lire et garder en tête en une seule fois.
C’est la mémoire de travail du modèle pour une requête donnée. Elle inclut votre prompt, les documents joints, l’historique de la conversation et la réponse générée. Tout cela partage le même espace fini.
La fenêtre de contexte est le nombre maximal de positions que le mécanisme d’attention d’un Transformer peut traiter simultanément, borné par des contraintes de mémoire et de calcul généralement quadratiques en la longueur de la séquence.
L’analogie-maîtresse : la table de conférence
Imaginez que vous organisez une réunion décisive. Vous disposez d’une salle avec une table de conférence à capacité fixée — disons vingt chaises. Chaque personne que vous invitez occupe une place. Chacune apporte une information, un dossier, un point de vue.
Autour de cette table, tous les participants s’entendent et se voient. Quand l’un prend la parole, les autres intègrent ce qu’il dit pour formuler leur propre contribution. Le directeur juridique répond à la directrice financière ; le marketing réagit au juridique ; la direction générale synthétise l’ensemble. La valeur de la réunion ne vient pas de la somme des présences, mais du maillage de leurs interactions.
Un modèle de langage fonctionne sur ce principe. Chaque token présent dans sa fenêtre de contexte est un « participant » à la réunion. Le mécanisme d’attention permet à chaque token d’écouter tous les autres et d’ajuster sa contribution en fonction. Votre prompt, vos documents, l’historique de la conversation : tout est à la table en même temps.
Mais la salle a une capacité finie. Si vous tentez d’y faire entrer plus de monde que de chaises, deux scénarios se produisent. Soit la porte est fermée aux retardataires — votre document est tronqué, et ce qui dépasse disparait. Soit vous faites sortir les premiers entrés pour faire de la place aux derniers — c’est le mécanisme de fenêtre glissante des longues conversations. Dans les deux cas, ce qui sort de la salle cesse d’exister pour le modèle.
Dernière subtilité : plus la salle est grande, plus la réunion coûte cher. Pas linéairement — quadratiquement. Doubler le nombre de chaises ne double pas le coût : il le quadruple, parce que le nombre d’interactions possibles entre participants croît avec le carré de leur effectif. Une réunion à cinquante personnes n’est pas « dix fois » une réunion à cinq, elle en est cent fois plus coordonnée. C’est la raison mathématique pour laquelle agrandir une fenêtre de contexte coûte plus cher qu’on ne l’imagine.
Dans une vraie réunion, un participant qui sort garde un souvenir partiel de ce qu’il a entendu et pourra revenir avec. Un token qui sort de la fenêtre de contexte, lui, disparaît totalement du point de vue du modèle : aucune trace, aucun résidu. Autre différence — et elle compte : tous les participants humains écoutent avec la même attention quel que soit leur emplacement à la table. Les LLM, eux, ont tendance à mieux retenir ce qui est en début et en fin de fenêtre qu’au milieu. C’est le phénomène bien documenté du « lost in the middle ».
Les rouages, traduits
Six notions techniques, chacune avec son équivalent dans la salle de réunion et sa traduction simple.
| Terme technique | Dans l’analogie | En réalité |
|---|---|---|
| Fenêtre de contexte | La capacité totale de la salle de réunion | Le nombre maximal de tokens que le modèle traite en une seule requête |
| Tokens d’entrée | Les participants que vous convoquez | Votre prompt, vos documents, l’historique |
| Tokens de sortie | Les intervenants qui rejoignent la table | La réponse générée par le modèle, token par token |
| Attention | Les interactions croisées entre participants | Le calcul qui pondère l’influence de chaque token sur chaque autre |
| Troncation | Les invités refusés à la porte faute de place | Ce qui dépasse la fenêtre est coupé, invisible pour le modèle |
| Coût quadratique | Le coût de coordination qui explose avec la taille de la salle | Doubler la fenêtre multiplie le calcul par quatre, pas par deux |
Ce que ça change pour vous
Cinq conséquences pratiques pour un manager qui choisit ou utilise un LLM.
- Le choix du modèle dépend d’abord de la taille de vos documents. Les fenêtres des modèles grand public s’échelonnent aujourd’hui de quelques dizaines de milliers à plus d’un million de tokens. Un rapport annuel de 80 pages tient dans 128 000 tokens ; un corpus de 50 rapports, non.
- Les conversations longues finissent par « oublier » leur début. Au-delà d’un certain seuil, les premiers échanges glissent hors de la fenêtre. L’IA ne vous contredit pas : elle ne voit simplement plus ce que vous lui aviez dit il y a trois heures.
- Une grande fenêtre ne vaut pas toujours mieux qu’une bonne base documentaire. Charger cinquante rapports dans la fenêtre d’un modèle coûte cher et dégrade la qualité (effet lost in the middle). Pour beaucoup d’usages, une architecture RAG qui ne récupère que les passages pertinents donne de meilleurs résultats à budget égal.
- Le coût ne s’additionne pas, il se multiplie. Passer d’une requête à 20 000 tokens à une requête à 200 000 tokens ne coûte pas dix fois plus cher à traiter : l’attention croît en carré. C’est pour cette raison que les fournisseurs facturent plus cher les très longs contextes.
- Le « milieu » de vos documents est le moins bien traité. Si vous demandez à un LLM d’analyser un long document, placez les instructions critiques au début ou à la fin. Tout ce qui est au milieu risque d’être sous-pondéré par le modèle.
FAQ débutants
Les deux articles qui ont posé les fondations
① Vaswani et al. (2017) — l’invention de la salle de réunion ✅
Contexte. 2017, chez Google Brain. Les modèles de traduction automatique fonctionnent en série — ils lisent les mots un par un, et peinent à relier un mot de début de phrase à un mot de fin. Les auteurs cherchent une architecture plus parallèle.
Idée centrale. Remplacer le traitement séquentiel par un mécanisme où chaque token « regarde » tous les autres en même temps. C’est le mécanisme d’attention, et l’architecture s’appelle le Transformer.
Pourquoi ça a changé le domaine. C’est le papier fondateur de toute la génération actuelle d’IA générative. GPT, Claude, Gemini, Llama, Mistral : toutes sont des variantes du Transformer. La notion même de « fenêtre de contexte » émerge ici, comme conséquence directe du design de l’attention.
Référence APA : Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., Kaiser, Ł., & Polosukhin, I. (2017). Attention Is All You Need. Advances in Neural Information Processing Systems, 30, 5998–6008. arxiv.org/abs/1706.03762
② Beltagy, Peters & Cohan (2020) — comment agrandir la salle ✅
Contexte. 2020, à l’Allen Institute for AI. Les premiers Transformers plafonnent à 512 tokens. Traiter un document juridique, un rapport médical ou une thèse est inenvisageable : tout est coupé au bout de quelques pages.
Idée centrale. Ne pas obliger chaque token à écouter tous les autres. Chaque token n’écoute que ses voisins immédiats (attention locale), sauf quelques tokens globaux qui gardent une vue d’ensemble. Le calcul devient linéaire au lieu de quadratique. Le modèle s’appelle Longformer.
Pourquoi ça a changé le domaine. C’est l’un des premiers papiers qui ouvre réellement la voie aux fenêtres longues. La plupart des techniques développées ensuite pour atteindre 100 000, 200 000, voire un million de tokens descendent conceptuellement de cette idée : relâcher la contrainte que tous les participants parlent à tous les autres.
Référence APA : Beltagy, I., Peters, M. E., & Cohan, A. (2020). Longformer: The Long-Document Transformer. arXiv preprint arXiv:2004.05150. arxiv.org/abs/2004.05150
Trois prompts pour explorer par vous-même
Prompt 1 — Explorer
Quelle est ta fenêtre de contexte maximale en tokens ? Et combien de mots français cela représente-t-il approximativement ? Explique-moi ce qui se passe concrètement si je dépasse cette limite.
🎯 Objectif : connaître la capacité réelle du modèle utilisé · 📚 Ce qu’on apprend : calibrer ses attentes au bon ordre de grandeur.
Prompt 2 — Tester sa compréhension
Je vais coller un long texte. Au milieu, je vais cacher une phrase très spécifique : « Le code secret est BRIOCHE-42 ». À la fin, je te poserai une question sans lien. Dis-moi ensuite si tu as vu le code caché, et à quelle position approximative il se trouvait.
🎯 Objectif : expérimenter l’effet « lost in the middle » · 📚 Ce qu’on apprend : la qualité d’attention n’est pas uniforme dans la fenêtre.
Prompt 3 — Cas pratique management
Mon équipe veut interroger une bibliothèque de 200 rapports internes (environ 2 millions de mots au total). Explique-moi quand privilégier un modèle à très grande fenêtre (1M tokens) et quand opter pour une architecture RAG, avec les coûts et limites de chaque option.
🎯 Objectif : arbitrer entre deux architectures possibles · 📚 Ce qu’on apprend : grande fenêtre n’est pas toujours la bonne réponse.
Note méthodologique. Cet article a été rédigé avec l’assistance de Claude (Anthropic) selon un gabarit pédagogique en quatre passes : (1) identification et vérification des articles fondateurs, (2) rédaction autour d’une analogie filée — la table de conférence, (3) relecture et contrôle des références, (4) rendu HTML responsive pour lisibilité sur mobile. Les deux références bibliographiques ont été vérifiées via arXiv et les actes NeurIPS 2017.
Laisser un commentaire