Quand la fenêtre de contexte cesse d’être un argument

La fenêtre de contexte est la quantité maximale de texte, mesurée en jetons, qu’un modèle de langage peut prendre en compte en une seule requête, consigne, documents fournis et réponse compris.

Elle fixe ce que le modèle « voit » au moment de répondre. Tout ce qui dépasse doit être sélectionné en amont, généralement par une chaîne de récupération documentaire. C’est pourquoi la taille de fenêtre a longtemps été une contrainte d’architecture : avec quelques milliers de jetons, comme le rappelait la fenêtre de 8 000 jetons de GPT-4, il fallait choisir avec soin les passages à envoyer.

Les fenêtres sont ensuite passées à cent mille jetons, puis à un million, comme l’a montré Gemini 1.5 et son million de jetons. La question n’est plus de savoir si un document tient dans la fenêtre, mais ce qu’on gagne à l’y mettre.

Lorsque plusieurs modèles offrent une fenêtre suffisante pour la tâche, sa taille annoncée devient un critère moins discriminant que la qualité obtenue, le coût et l’exploitation.

Google avait annoncé Gemini 1.5 et des possibilités de contexte long en février 2024. OpenAI présente GPT-4.1 dans l’API le 14 avril 2025 avec une fenêtre allant jusqu’à un million de jetons. Cela ne signifie pas que tous les fournisseurs proposent exactement les mêmes capacités.

Je pose une question plus utile : le contexte nécessaire à cette tâche tient-il dans les variantes envisagées ? Si oui, comparer seulement leurs plafonds dit peu sur le résultat.

Il faut aussi distinguer capacité annoncée et exploitation de l’information. Les travaux RULER, publiés en 2024, évaluent le comportement réel sur plusieurs tâches de contexte long. Ils montrent pourquoi une longueur nominale ne suffit pas à juger un service documentaire.

Le comportement sur votre jeu de tests, le coût par réponse à qualité constante, et la stabilité du format de sortie décident aujourd’hui d’un choix de modèle. Une annonce peut donner des indications ; elle ne fournit pas la mesure sur votre système.

Le premier ne peut venir que de vous. Aucun classement public ne prédit le comportement sur un corpus donné, dans une langue donnée, pour une tâche donnée. C’est le raisonnement de lire une annonce de benchmark.

Le deuxième se mesure et se compare, à condition que la couche d’abstraction comptabilise le coût par appel au même endroit pour tous les fournisseurs.

Le troisième est le plus négligé et le plus déterminant en production : un modèle qui respecte scrupuleusement un format de sortie demandé vaut mieux qu’un modèle plus capable qui s’en écarte, parce que cette fois-là casse une chaîne automatisée. Les mécanismes qui garantissent ce format sont décrits dans les sorties structurées.

Au-delà de la fenêtre, il faut comparer les versions disponibles, les conditions de traitement, les tarifs et la disponibilité, en examinant leur effet sur le service attendu.

• La politique de dépréciation : combien de préavis avant qu’une version soit retirée. Voir le jour où le modèle a changé sans prévenir.
• La localisation du traitement, qui décide de ce qu’on a le droit de lui envoyer.
• La stabilité tarifaire, et notamment le rapport entre jetons d’entrée et de sortie selon votre profil d’usage.
• La disponibilité mesurée, pas annoncée : 99 % de disponibilité sur une année de 365 jours correspondent arithmétiquement à 3,65 jours d’indisponibilité. Un contrat peut toutefois mesurer un autre périmètre, avec des exclusions.

Une fenêtre suffisante permet de comparer l’envoi direct et la récupération documentaire, mais le choix dépend aussi de la confidentialité, des versions, de la qualité et de la charge.

Je ne fixe pas un seuil universel de pages ou de requêtes. Les documents n’ont pas la même densité, les utilisateurs n’ont pas les mêmes droits et les traitements n’exigent pas tous la même information.

L’envoi direct peut simplifier un premier système sur un corpus limité. La récupération peut réduire le contexte, sélectionner les sources pertinentes et appliquer des filtres. Les deux doivent être testés sur les mêmes questions et avec les mêmes contraintes.

Le coût des entrées et des sorties reste visible, comme le rappelle une grande fenêtre reste une facture. La possibilité de tout envoyer n’en démontre ni l’utilité ni l’autorisation.

Cette comparaison évite le surdimensionnement initial décrit dans sortir du prototype.

À capacités équivalentes, le fournisseur qui se comporte de la même façon d’un mois sur l’autre vaut mieux que celui qui progresse par à-coups. C’est un critère d’exploitation, jamais mis en avant commercialement.

Un système en production est réglé : le prompt a été ajusté, les seuils fixés, les cas limites traités. Une amélioration du modèle qui change le style des réponses ou la façon de refuser oblige à tout revérifier.

Les équipes qui exploitent depuis longtemps le savent et arbitrent en conséquence. Elles préfèrent un fournisseur qui annonce ses changements, propose des versions figées, et laisse un préavis suffisant.

L’historique de versions apporte une première information. Il faut le compléter par les conditions de maintien et par une recette du comportement sur vos demandes.

Avant de signer, demandez comment les versions sont maintenues et retirées, quel préavis est prévu et quels moyens permettent de tester un remplacement avant sa mise en service.

« Combien de temps une version reste-t-elle disponible après l’annonce de son remplacement ? » La réponse à cette question détermine votre charge d’exploitation bien plus sûrement que n’importe quelle caractéristique technique.

Comparer deux fournisseurs en pratique demande une intégration limitée sur la même tâche, avec les mêmes cas et les mêmes critères de qualité, de coût et d’exploitation.

1. Isoler l’appel au modèle derrière une couche d’abstraction, pour que le changement de fournisseur se réduise à un paramètre. Le principe est décrit dans la couche qui rend le modèle remplaçable.
2. Rejouer le même jeu de tests sur les deux, avec les mêmes consignes et les mêmes documents.
3. Mesurer le coût par réponse correcte, pas le prix par jeton : un modèle moins cher qui échoue plus souvent coûte davantage en relecture.
4. Compter les écarts de format sur plusieurs centaines d’appels, pas sur une démonstration.
5. Lire les conditions : préavis de dépréciation, versions figées, localisation, engagement de disponibilité.
6. Noter l’effort d’intégration : qualité de la documentation, clarté des erreurs, réactivité du support.

Je préfère une intégration bornée qui révèle les contraintes réelles à une comparaison de fiches sans essai. Sa durée dépend des interfaces et des accès disponibles.

Les erreurs les plus fréquentes dans le choix d’un modèle consistent à décider sur une caractéristique d’annonce, à sur-dimensionner l’architecture dès le départ et à ignorer le coût d’exploitation des changements de version.

• Choisir la plus grande fenêtre par principe. Une fenêtre qu’on remplit coûte à chaque requête ; une fenêtre qu’on ne remplit pas n’apporte rien.
• Construire une chaîne de récupération complexe avant d’avoir mesuré. Sur un petit corpus, l’envoi direct suffit et se remplace plus tard.
• Comparer des prix par jeton sans profil d’usage. Le rapport entre entrée et sortie change complètement le classement.
• Oublier l’arbitrage avec l’ajustement du modèle. Le choix entre récupération et entraînement complémentaire se fait aussi sur le coût, comme le montre RAG ou fine-tuning.
• Signer sans lire la politique de versions. C’est elle qui détermine la charge de revérification des années suivantes.

Ces points sont examinés lors d’un audit IA d’un système existant ou d’un appel d’offres en préparation.

Lectures complémentaires : {"type":"markdown","title":"Une capacité devenue standard","content":"**Quand tous les fournisseurs proposent une très grande fenêtre de contexte, cette caractéristique cesse de départager quoi que ce soit.** C’est le sort habituel des arguments techniques : ils différencient dix-huit mois puis deviennent un prérequis.\n\nPendant deux ans, la taille de fenêtre a structuré les comparaisons. Elle apparaissait en tête des annonces, dans les tableaux comparatifs, dans les appels d’offres. Elle disparaît de ce rôle aussi vite qu’elle y était entrée.\n\nCe qui reste alors est plus intéressant, parce que ce sont les critères qui comptaient déjà : le comportement sur vos cas, le coût par réponse, la stabilité du fournisseur, et le respect des formats de sortie."},{"alt":"Quatre fournisseurs offrant une capacité équivalente","src":"/images/schemas/fenetre-cesse-d-etre-un-argument.webp","type":"image","caption":"Une capacité partagée par tous cesse d’être un critère de choix."},{"type":"markdown","title":"Les critères qui reprennent leur place","content":"**Le comportement sur votre jeu de tests, le coût par réponse à qualité constante, et la stabilité du format de sortie décident aujourd’hui d’un choix de modèle.** Aucun des trois ne figure dans une annonce.\n\nLe premier ne peut venir que de vous. Aucun classement public ne prédit le comportement sur un corpus donné, dans une langue donnée, pour une tâche donnée. C’est le raisonnement de [lire une annonce de benchmark.