1 million de tokens sur Claude Opus 4.7 : la fenêtre de contexte enfin exploitable ?

Opus 4.7 est sorti hier jeudi 16 avril 2026. L’une des promesses qu’Anthropic met en avant concerne la rétention de contexte sur la fenêtre de 1 million de tokens. Sur le papier, cette fenêtre existait déjà avec 4.6. En pratique, peu d’utilisateurs l’utilisaient vraiment parce que la qualité se dégradait bien avant le plafond. Qu’est-ce qui change vraiment avec 4.7 ?

Le décalage entre la capacité théorique et l’usage réel

Sur Opus 4.6, la fenêtre de 1M de tokens était un argument marketing impressionnant. En réalité, au-delà de 350k-400k tokens, les utilisateurs remontaient des problèmes : le modèle commençait à oublier des détails du début de la session, à reposer des questions déjà traitées, à produire des sorties incohérentes avec le contexte plus ancien.

Cette dégradation venait de la nature probabiliste du long context. Plus le contexte est long, plus l’attention du modèle se dilue. Au-delà d’un certain seuil, l’information ancienne perd du poids relatif dans les décisions du modèle, même si elle est toujours techniquement présente dans le context window.

Conséquence : la plupart des workflows production restaient dans les 100k-200k tokens, avec des mécanismes de résumé et de chunking pour contourner la dégradation.

Ce que 4.7 change

Selon les premiers retours et mes propres tests depuis hier soir, Opus 4.7 tient mieux la distance sur les contextes longs. Le point de dégradation se déplace d’environ 400k à 700k tokens. C’est un gain significatif.

Ça ne veut pas dire que la fenêtre 1M est maintenant utilisable à plein dans tous les cas. Il reste une dégradation entre 700k et 1M. Mais pour la majorité des workflows production, rester en dessous de 700k tokens devient réaliste, ce qui ouvre des cas d’usage qui étaient fermés avec 4.6.

Les cas d’usage qui deviennent vraiment possibles

Audit de codebase complet. Sur une app de taille moyenne (50 à 100 fichiers, 200k à 400k tokens), tu peux maintenant charger l’ensemble dans une seule session et demander une analyse globale. Cohérence architecturale, duplications, anti-patterns, dépendances circulaires. Avec 4.6, il fallait chunker et perdre le lien inter-fichiers.

Production de clusters topiques. Pour la production de contenu SEO, tu peux maintenant écrire 10 à 15 articles liés (silo topique) dans une seule session, avec cohérence inter-articles maintenue. Le brief initial reste actif même au 15e article.

Sessions de debug complexes. Un debug qui s’étale sur plusieurs heures, avec accumulation de logs, de stack traces, d’hypothèses testées, reste cohérent de bout en bout. Tu ne redécouvres plus à mi-parcours que le modèle a oublié une hypothèse éliminée 20 minutes plus tôt.

Ingestion de documentation volumineuse. Tu peux charger la doc complète d’un framework (50k à 100k tokens) et poser des questions ciblées sans avoir à refaire des embeddings ou du RAG. Utile quand tu apprends une nouvelle techno en profondeur.

Les limites qui persistent

Il faut nuancer l’enthousiasme. Plusieurs problèmes structurels restent.

Le coût de chaque nouveau tour augmente avec le contexte. Sur une session à 500k tokens de contexte, chaque nouveau prompt consomme ces 500k tokens en entrée avant de produire sa sortie. La facture grimpe exponentiellement sur une longue session.

Le phénomène du “lost in the middle”. Même sur 4.7, les informations situées au milieu du contexte (pas au début, pas à la fin) peuvent perdre en saillance. Si tu mets une information critique au milieu d’un contexte de 500k tokens, elle peut être moins bien mobilisée qu’une info en ouverture ou en clôture.

La rétention précise vs l’impression générale. Le modèle tient mieux le fil général de la session, mais la rétention précise (citation mot pour mot, valeur numérique exacte vue 200k tokens plus tôt) reste sujette à erreur. Pour ces cas, il faut toujours reposer l’info ou extraire via un appel dédié.

Comment utiliser la fenêtre étendue efficacement

Quelques patterns qui marchent dans mon expérience.

Structure le contexte en couches. Pose le brief global et les règles immuables en ouverture. Les informations détaillées par sujet arrivent ensuite. Cette structure aide le modèle à garder une hiérarchie claire.

Répète les contraintes critiques régulièrement. Tous les 100k tokens environ, rappelle brièvement les contraintes clés. Ça coûte peu de tokens et maintient la saillance.

Utilise des ancres explicites. Numérote tes sections, tes décisions, tes hypothèses. Quand tu réfères à l’une d’elles plus tard, utilise le numéro. Le modèle tient mieux le lien.

Résume périodiquement. Sur une session très longue, demander un résumé intermédiaire (qui devient un nouveau point de départ) aide à consolider le contexte utile et à laisser de côté le bruit.

Pour les intégrations API et les agents autonomes

Les agents autonomes profitent particulièrement de la fenêtre étendue. Un agent qui traite plusieurs centaines d’items hétérogènes en une session garde la mémoire de ce qu’il a déjà fait et peut éviter les doublons ou les incohérences.

Point de vigilance : sur un agent qui tourne 24/7, la fenêtre se remplit vite. Prévois un mécanisme de rotation : compacter périodiquement le contexte en un résumé dense et repartir avec un contexte frais. La commande de “new session” en début de chaque plage de 500k tokens reste une bonne pratique.

Le coût caché des sessions très longues

Soyons clairs : une session de 700k tokens de contexte qui fait 20 tours consomme énormément. En tarif API standard, on parle de plusieurs euros par tour sur les derniers échanges de la session. Sur un usage intensif en production, ça se voit.

Pour rentabiliser la fenêtre étendue, utilise-la quand elle apporte un gain net : cohérence inter-éléments, compréhension globale impossible en chunks, réduction du nombre d’aller-retours nécessaires. Pour les cas où un chunking reste praticable, le chunking coûte moins cher.

FAQ

Peut-on tester sa limite effective de rétention ? Oui, par un test empirique. Injecte une information précise (un numéro, un code, un nom propre) en début de contexte. Fais grossir le contexte par des tours successifs. À intervalles réguliers, demande au modèle de ressortir l’information. Tu verras le point de dégradation sur ton workflow spécifique.

La fenêtre 1M est-elle disponible sur tous les plans ? Oui, c’est une caractéristique du modèle, pas du plan. La différence entre plans concerne plutôt le volume d’appels et le tarif.

Faut-il reprompter à chaque session ou peut-on persister ? Le context window est par session. Il ne persiste pas automatiquement d’une session à l’autre. Pour persister, il faut soit sauvegarder et rerouter le contexte à l’ouverture, soit utiliser des mécanismes de mémoire côté application (RAG, base vectorielle, etc.).

---

Je pilote Linkuma, plateforme de netlinking low cost avec 40 000 sites au catalogue et 15 000 clients accompagnés. On exploite les sessions longues pour la production de contenu à grande échelle. Retours terrain sur linkuma.com, promos hebdomadaires sur deals.linkuma.com.