Passer au contenu principal
RM
Retour au blog

1 million de tokens de contexte. Qu'est-ce que ça permet concrètement et quelles sont les limites ?

Radnoumane Mossabely8 min read
GPT-4.1 million tokens
GPT-4.1
OpenAI
Context Window
LLM
0 vues

TL;DR

  • GPT-4.1 supporte 1 million de tokens en contexte, soit environ 750 000 mots ou 3 000 pages.
  • Ca permet de charger des codebases entieres, des livres complets, des heures de logs.
  • Le probleme "lost in the middle" persiste : le modele est moins fiable sur les informations au milieu du contexte.
  • Le cout est lineaire : 1M tokens en input, c'est cher. RAG reste souvent plus economique.
  • Gemini 1.5 Pro avait ouvert la voie. GPT-4.1 confirme que le million est le nouveau standard.

On est passes de 4K a 1M en deux ans

Pour comprendre a quel point ca va vite, un rappel chronologique. GPT-3.5 a son lancement : 4 096 tokens. Soit environ 3 000 mots. A peine un article de blog. Tu ne pouvais meme pas lui donner un fichier de code complet sans le tronquer.

GPT-4 (mars 2023) : 8K tokens en standard, 32K en version etendue. Un progres, mais toujours insuffisant pour des cas d'usage serieux. Claude 2 a pousse a 100K, ce qui etait deja impressionnant. Puis Gemini 1.5 Pro a debarque avec 1 million de tokens en fevrier 2024, et tout le monde a compris que la course a la fenetre de contexte etait lancee.

GPT-4.1, sorti en avril 2025, aligne OpenAI sur ce nouveau standard. 1 million de tokens. C'est pas juste un chiffre marketing. C'est un changement qualitatif dans ce qu'on peut demander a un LLM.

Ce que tu peux faire avec 1 million de tokens

Mettons des chiffres concrets. 1 million de tokens, ca represente approximativement :

ContenuEquivalent
Code source~60 000 lignes (une codebase moyenne)
Texte~750 000 mots (10 romans)
Documentation~3 000 pages
Logs~24h de logs applicatifs
Conversations~500 echanges detailles

Ca ouvre des cas d'usage qui etaient impossibles avant :

Analyse de codebase complete. Tu peux charger un projet entier -- tous les fichiers source, les configs, les tests -- et demander au modele de trouver un bug, de comprendre l'architecture, ou de proposer un refactoring. Pas besoin de decouper et de perdre le contexte inter-fichiers.

Review de documents longs. Un contrat de 200 pages, un rapport d'audit, une these. Le modele peut les lire en entier et repondre a des questions qui necessitent de croiser des informations dispersees dans le document.

Debug de logs. Tu balances 24h de logs applicatifs et tu demandes "qu'est-ce qui s'est passe a 3h du matin ?". Le modele peut corréler des evenements separes de milliers de lignes.

Traduction de livres entiers. Charger un livre complet permet de maintenir la coherence terminologique sur 300 pages, ce qui etait impossible avec une fenetre de 32K.

Le probleme "lost in the middle"

Avoir 1 million de tokens ne veut pas dire que le modele utilise ces 1 million de tokens aussi bien. C'est le probleme le plus sous-estime des grandes fenetres de contexte.

Des recherches publiees depuis 2023 montrent un pattern recurrent : les LLM sont tres bons pour exploiter les informations au debut et a la fin du contexte, mais nettement moins fiables sur ce qui se trouve au milieu. C'est le phenomene "lost in the middle".

Concretement, si tu charges 60 000 lignes de code et que le bug se trouve dans un fichier qui tombe au milieu du contexte, le modele a plus de chances de le rater que si ce fichier etait au debut ou a la fin.

Le probleme lost in the middle : l'attention du modele n'est pas uniforme sur le contexte

GPT-4.1 a fait des progres sur ce point par rapport a ses predecesseurs. OpenAI a specifiquement travaille sur l'amelioration du suivi d'instructions dans les longs contextes. Mais le probleme n'a pas disparu. Sur des taches de type "aiguille dans une botte de foin" (retrouver une information specifique dans un contexte enorme), les performances se degradent encore quand l'information cible est au milieu.

Le cout : la ou ca fait mal

Le contexte n'est pas gratuit. Et a 1 million de tokens, la facture monte vite.

Voici un ordre de grandeur pour GPT-4.1 (avril 2025) :

Volume d'inputCout approximatif
10K tokens~$0.02
100K tokens~$0.20
500K tokens~$1.00
1M tokens~$2.00

Et c'est juste l'input. Ajoute l'output, et une seule requete avec un contexte complet peut couter plusieurs dollars. Si ton application fait des dizaines de requetes par utilisateur, ca explose.

Compare ca avec un systeme RAG bien configure : tu stockes tes documents dans une base vectorielle, tu recuperes seulement les 5-10 chunks les plus pertinents (quelques milliers de tokens), et tu envoies ca au modele. Le cout par requete tombe a quelques centimes.

GPT-4.1 vs Gemini 1.5 Pro : le match

Gemini 1.5 Pro de Google a ete le premier a atteindre le million de tokens en production. Un an plus tard, GPT-4.1 s'aligne. La comparaison est inevitable.

CritereGPT-4.1Gemini 1.5 Pro
Contexte max1M tokens1M tokens (2M en preview)
MultimodalTexte, images, audioTexte, images, audio, video
"Needle in haystack"Tres bon debut/fin, correct milieuExcellent sur l'ensemble
Cout (1M input)~$2.00~$1.25
LatenceElevee sur contextes longsOptimise pour longs contextes
Suivi d'instructionsExcellentBon
CodeTres fortFort

Google a un avantage structurel sur les longs contextes. Leur architecture a ete optimisee pour ca des le depart, avec des techniques comme l'attention par fenetre glissante. GPT-4.1 est arrive plus tard sur ce terrain mais compense par une meilleure qualite de suivi d'instructions et de generation de code.

Quand utiliser 1M de contexte vs RAG

C'est la question strategique. Tu as un gros corpus de donnees a exploiter. Tu choisis quoi ?

Le contexte long est meilleur quand :

  • Tu as besoin que le modele comprenne les relations entre toutes les parties du document (architecture de code, structure narrative d'un livre).
  • Le corpus tient dans 1M tokens et ne change pas souvent.
  • Tu as besoin de reponses qui synthetisent l'ensemble du document, pas juste un passage.
  • Tu es pret a payer le cout associe.

Le RAG est meilleur quand :

  • Ton corpus est plus grand que 1M tokens (base de connaissances d'entreprise, documentation de milliers de pages).
  • Les donnees changent frequemment et doivent etre mises a jour sans re-traiter tout le contexte.
  • Tu as besoin de reponses factuelles basees sur des passages precis.
  • Le cout par requete doit rester bas.
  • Tu as besoin de citations exactes avec la source.

La combinaison est souvent optimale. Tu utilises le RAG pour filtrer les documents pertinents, puis tu charges ces documents dans un contexte long pour une analyse approfondie. C'est du RAG + long context, et c'est probablement l'approche qui va dominer.

Ce que ca change pour les developpeurs

Le million de tokens n'est pas juste un benchmark. Ca change la facon dont on construit des applications IA.

Les agents deviennent plus autonomes. Un agent de code avec 1M de contexte peut charger tout un projet et travailler dessus sans avoir besoin de systemes de recherche complexes. Claude Code, Cursor, Codex -- tous ces outils beneficient directement de cette capacite.

Le pre-traitement diminue. Avant, tu passais du temps a decouper tes documents, a construire des pipelines d'embedding, a optimiser ton chunking. Avec 1M de contexte, pour beaucoup de cas d'usage, tu peux juste... tout charger. C'est moins elegant, mais ca marche.

L'architecture des applications change. Le pattern "embedding + vector DB + retrieval + generation" reste pertinent pour les gros corpus, mais pour des corpus moyens (une documentation produit, un repo de code), le pattern "tout dans le contexte" devient viable.

Les limites qu'il ne faut pas oublier

Le million de tokens n'est pas une solution magique. Quelques rappels :

  • La latence augmente. Plus le contexte est long, plus le temps de reponse augmente. Une requete avec 1M tokens prend significativement plus de temps qu'avec 10K.
  • La qualite n'est pas uniforme. Lost in the middle. On l'a dit, mais ca merite d'etre repete.
  • Le cout est lineaire. Pas de magie economique. Plus de tokens = plus cher.
  • La memoire de travail a ses limites. Le modele peut lire 1M tokens, mais sa capacite a raisonner sur toutes ces informations simultanement reste contrainte. Il ne "comprend" pas 3 000 pages comme un humain comprendrait un resume de 10 pages.

Le million de tokens est un outil puissant. Comme tout outil puissant, il faut savoir quand l'utiliser et quand s'en passer.

Ressources

Partager: