Les modèles d'IA peuvent désormais lire l'intégralité de votre code source. Voici ce que cela change concrètement.

La fenêtre de contexte est devenue le champ de bataille technique déterminant du cycle actuel de l'IA. En dix-huit mois, le plafond pratique des modèles basés sur Transformer est passé de 128 000 tokens à plus d'un million – et avec Gemini 2.5 Pro, à 2 millions. Ce nombre est généralement présenté comme une spécification produit. Il mérite un examen plus approfondi.

Un token représente environ les trois quarts d'un mot. Un million de tokens, c'est environ 750 000 mots – l'équivalent de dix romans moyens, d'un document juridique de 2 000 pages, ou de la majeure partie du code source d'une entreprise de logiciels de taille moyenne. Lorsqu'un modèle peut contenir tout cela simultanément dans son contexte de travail, les types de questions que vous pouvez lui poser changent fondamentalement.

Du fragment au système

Le cas d'usage original des assistants de code était l'autocomplétion : tapez le nom d'une fonction, obtenez quelques lignes de continuation plausible. Cela fonctionne toujours bien. Mais le changement intéressant se produit lorsque le modèle a accès à l'ensemble du système – chaque fichier, chaque import, chaque contrat d'interface (Interface Contract).

Claude Opus 4.8 d'Anthropic prend en charge 1 million de tokens avec une forte précision de récupération sur l'ensemble de la fenêtre – un problème qui a entaché les tentatives précédentes de contexte long. Gemini 2.5 Pro de Google atteint 2 millions de tokens. GPT-4.1 d'OpenAI se situe à 1 million. La course ne porte plus sur la capacité à lire un document volumineux – mais sur la capacité du modèle à agir de manière cohérente sur ce qu'il a lu.

Pour le développement logiciel, cela signifie quelque chose de concret : un modèle qui a lu votre module d'authentification, votre schéma de base de données, votre couche API et votre suite de tests simultanément travaille à partir de la même image complète qu'un ingénieur senior a en tête. Quand il suggère une refactorisation (Refactor), il peut voir le rayon d'impact. Quand il trouve un bogue, il peut le tracer à travers trois couches d'abstraction.

Ce qui s'améliore réellement

Les gains les plus fiables du contexte long concernent des tâches intrinsèquement globales : analyse des dépendances, audits de sécurité, revue d'architecture, refactorisation entre fichiers. Ce sont des tâches où l'analyse fragmentaire a toujours été le goulot d'étranglement, et non la capacité de raisonnement du modèle.

Les tâches de récupération s'améliorent également qualitativement. Les approches antérieures d'analyse de grands documents reposaient sur le RAG – découpage des documents, Embedding, récupération des morceaux pertinents au moment de la requête. Le RAG est une solution de contournement pour un contexte limité et introduit des failles : le récupérateur peut ne pas renvoyer le bon morceau, l'Embedding peut manquer des relations sémantiques, le modèle ne voit jamais deux éléments de preuve qui auraient rendu la connexion évidente. Le contexte de document complet élimine ces failles pour les documents qui tiennent dans la fenêtre.

Les flux de travail d'analyse juridique et financière sont déjà en cours de reconstruction autour de cette capacité. Un modèle lisant un contrat d'acquisition complet – avec tous les calendriers et annexes – peut répondre à des questions de références croisées qui auraient exigé qu'un avocat corrèle manuellement les clauses. Le modèle ne remplace pas l'avocat, mais il élimine l'étape de récupération qui consommait la majeure partie du temps facturable.

Le problème de la dilution de l'attention (Attention Dilution)

Les gains ne sont pas uniformes. Plusieurs évaluations indépendantes ont documenté un mode de défaillance constant dans les modèles à contexte long : les performances se dégradent lorsque l'information pertinente est enfouie au milieu de la fenêtre de contexte. Ce phénomène a un nom dans la littérature de recherche : le problème "perdu au milieu" (Lost in the Middle).

Google et Anthropic ont tous deux réalisé des investissements architecturaux explicites pour y remédier – Gemini 2.5 utilise des encodages positionnels appris (Learned Positional Encodings) conçus pour la récupération à longue portée, tandis qu'Anthropic rapporte une amélioration de l'uniformité de récupération dans la série Claude 4.x. Mais aucune des deux sociétés n'a publié d'évaluations complètes de type "aiguille dans une botte de foin" (Needle-in-a-Haystack) à 1 million de tokens pour vérification publique indépendante.

Il y a aussi la question du coût. La mise à l'échelle du budget de tokens signifie qu'un appel d'un million de tokens est nettement plus coûteux qu'un appel de 100 000 tokens. En pratique, les tokens de prompt mis en cache (Cached Prompt Tokens) réduisent cela – la mise en cache de prompts d'Anthropic réduit les coûts de contexte de 90 % pour les appels répétés, rendant la fenêtre d'un million de tokens exploitable pour les applications qui réutilisent de grands contextes sur plusieurs requêtes.

Là où ce n'est pas encore suffisant

La vidéo reste la frontière. Une vidéo d'une heure à 24 images par seconde contient 86 400 images. La compréhension vidéo native opère sur une entrée sous-échantillonnée – Gemini 1.5 Pro gère une image par seconde avec un traitement audio séparé. Pour l'analyse de surveillance ou la révision de vidéos longues, cette compression perd trop d'informations.

La deuxième limitation est la mémoire active. Une fenêtre de contexte est stationnaire – c'est ce que le modèle a chargé au début de la conversation. Pour les applications qui doivent suivre un état évolutif sur plusieurs sessions, les fenêtres de contexte sont complétées, mais pas remplacées, par des systèmes de mémoire externe : bases de données, magasins de vecteurs, architectures augmentées par mémoire.

Ce que cela signifie pour les développeurs maintenant

Trois choses méritent d'être faites différemment maintenant que les fenêtres de contexte d'un million de tokens sont prêtes pour la production :

Arrêtez de sur-découper vos pipelines RAG. Pour les documents de moins de 500 pages, le contexte de document complet surpassera les approches augmentées par récupération sur les tâches de précision. Construisez le pipeline RAG pour passer à l'échelle sur de nombreux documents, pas pour compenser la taille du document.

Utilisez la fenêtre de contexte pour la revue de code au niveau système avant d'ouvrir un PR. Alimenter une branche de fonctionnalité complète – tous les fichiers modifiés, le diff, les fichiers de test pertinents – vers un seul appel de modèle avec une invite de revue structurée capture les problèmes entre fichiers que la revue par fichier individuel manque par conception.

Reconsidérez les hypothèses sur ce qui nécessite du Fine-tuning. De nombreuses tâches pour lesquelles les gens faisaient du Fine-tuning – résumé de documents, correspondance de style, extraction d'entités de corpus spécifiques à un domaine – peuvent désormais être traitées en contexte avec des exemples et un accès complet au document. Le Fine-tuning reste gagnant pour l'inférence sensible à la latence et les distributions d'entraînement étroites, mais ce n'est plus le premier recours.

La fenêtre de contexte continue de s'étendre. Les questions qui valent la peine d'être posées ne concernent plus le plafond – elles concernent ce que vous construisez lorsque ce plafond n'est plus la contrainte.