Le guide de la context window IA pour les développeurs : pourquoi vos prompts échouent

Vous êtes dans une super session de debug depuis 40 minutes. L'IA comprend votre schéma, se souvient de vos conventions de nommage, et vous fait des suggestions solides. Puis, vers le message 25, quelque chose change. Le modèle commence à halluciner des noms de fonctions. Il oublie la contrainte que vous avez mentionnée plus tôt. Les réponses semblent génériques.

Vous n'avez pas changé de modèle. Vous n'avez rien fait de mal. Que s'est-il passé ?

Vous avez atteint la limite de la context window. Et vous ne le saviez même pas.

---

Qu'est-ce qu'une context window ?

Une context window est la quantité totale de texte — mesurée en tokens — qu'un LLM peut "voir" à un instant donné. Tout ce qui se trouve dans la fenêtre est disponible pour le raisonnement du modèle. Tout ce qui en sort est complètement invisible, comme si ça n'avait jamais existé.

Pensez à ça comme la RAM pour l'attention du modèle. La context window contient toute votre conversation : votre system prompt, chaque message envoyé, chaque réponse du modèle, et tous les documents que vous avez collés.

Quand la conversation dépasse la context window, le contenu le plus ancien est supprimé. Le modèle ne vous avertit pas. Il ne dit pas "j'ai oublié ce que vous m'aviez dit plus tôt." Il cesse simplement de savoir des choses qu'il savait.

Les maths des tokens que tout développeur devrait connaître

Modèle	Context window	Équivalent caractères approximatif
GPT-4o	128K tokens	~512 000 caractères
Claude 3.5 Sonnet	200K tokens	~800 000 caractères
Claude 3 Opus	200K tokens	~800 000 caractères
Gemini 1.5 Pro	1M tokens	~4 000 000 caractères

Un token correspond à environ 4 caractères ou ¾ d'un mot en français. Un fichier source typique représente 500 à 2 000 tokens. Une longue conversation avec beaucoup de code représente 10 000 à 50 000 tokens.

---

Pourquoi la dégradation du contexte arrive avant la limite stricte

Voici la partie contre-intuitive : vous n'avez pas besoin d'atteindre la limite stricte pour que le contexte se dégrade. Même bien à l'intérieur de la fenêtre, les modèles montrent une décroissance de l'attention — ils pondèrent les tokens récents plus fortement que les anciens.

Si vous expliquez votre architecture au début d'une longue conversation, puis posez une question 15 000 tokens plus tard, le modèle peut partiellement ou complètement ignorer cette explication initiale. Non pas parce qu'elle a été supprimée — elle est toujours dans la fenêtre — mais parce que les mécanismes d'attention priorisent naturellement la récence.

C'est pourquoi le phénomène "lost in the middle" est bien documenté dans la recherche sur les LLM : l'information enfouie au milieu d'un long contexte est systématiquement sous-pondérée.

Ce que ça signifie en pratique

• Placez vos contraintes les plus importantes à la fin de votre bloc de contexte, pas au début
• Répétez les contraintes critiques dans vos messages de suivi ("pour rappel, on utilise l'App Router, pas le Pages Router")
• Utilisez des blocs de contexte courts et denses plutôt que de longues explications discursives

---

Comment structurer votre contexte pour une précision maximale

L'objectif est de condenser le maximum de signal en minimum de tokens, et de placer les informations les plus importantes là où le modèle les pondèrera le plus fiablement.

Le format de contexte ATLAS

C'est la structure recommandée chez ATLAS et qu'utilisent des milliers de développeurs au quotidien :

## Stack
Next.js 14 (App Router) · TypeScript 5.3 · Tailwind 3.4 · Supabase · tRPC v11 · Zod · Vitest

## Architecture
- Monorepo (Turborepo) : apps/web, apps/api, packages/types, packages/ui
- Auth : Supabase Auth + RLS, stratégie cookie de session
- API : routers tRPC dans apps/api/src/routers/, types partagés via packages/types

## Conventions
- Composants fonctionnels uniquement · Server Components par défaut · fichiers kebab-case · composants PascalCase
- Pas de barrel files · tests collocalisés dans __tests__/ · préférer zod.parse() à la validation manuelle

## Session en cours
[Ce sur quoi vous travaillez en ce moment]

Notez ce que ce format fait :

• La ligne Stack utilise des séparateurs · pour densifier l'info (moins de tokens que des bullet points)
• La section Architecture contient uniquement des faits structurels — pas d'adjectifs, pas d'explication
• Les Conventions sont des règles, formulées de manière impérative
• La Session en cours est en fin, pour recevoir le poids d'attention maximal

Ce format utilise typiquement 150 à 250 tokens — assez peu cher pour être inclus dans chaque message si nécessaire.

---

Le problème de "reset de contexte" dans les longues sessions

Il existe un second problème de contexte distinct de la limite de fenêtre : les frontières de session.

Chaque nouvelle conversation avec ChatGPT ou Claude commence avec zéro contexte. Pas un contexte dégradé — zéro. Votre session précédente, aussi productive soit-elle, est complètement perdue. Toutes les décisions prises, les contraintes établies, le code reviewé ensemble — disparus.

C'est le problème qu'ATLAS a été conçu pour résoudre. Plutôt que de réétablir le contexte depuis zéro à chaque nouvelle session, ATLAS maintient un store de contexte persistant pour chacun de vos projets. Quand vous démarrez une nouvelle conversation, ATLAS injecte automatiquement votre contexte projet actuel.

Le résultat : chaque nouvelle session semble être la continuation de la précédente, pas un démarrage à froid.

---

Techniques pratiques pour gérer le contexte dans les longues sessions

1. L'astuce du checkpoint résumé

Toutes les 20 à 30 messages dans une longue session, demandez au modèle de résumer ce qui a été décidé :

"Résume les décisions clés prises dans cette session sous forme d'un bloc de contexte compact que je peux coller dans une nouvelle conversation."

Collez ce résumé au début de votre prochaine session. Ça étend effectivement votre contexte de travail sur plusieurs conversations.

2. Le préfixe "IMPORTANT :"

Pour les contraintes que le modèle continue d'oublier, préfixez-les explicitement :

"IMPORTANT : On utilise l'App Router, PAS le Pages Router. Chaque chemin de fichier que vous suggérez doit être dans app/, pas dans pages/."

L'emphase n'est pas de la superstition — la recherche montre que les LLM pondèrent de manière fiable le contenu avec des marqueurs d'importance explicites.

3. Le code comme contexte, pas la description

Plutôt que de décrire votre modèle de données en prose, collez les types TypeScript réels :

// Collez ça, pas une description
type User = {
  id: string;
  email: string;
  role: "admin" | "member" | "viewer";
  orgId: string;
};

Les types sont denses, non ambigus, et utilisent moins de tokens que les descriptions en langage naturel.

4. Élaguer avant d'étendre

Avant de coller un gros fichier pour analyse, supprimez les sections non pertinentes. Le modèle n'a pas besoin de votre package.json entier — il a besoin de l'objet dependencies. Plus vous êtes chirurgical, plus les réponses sont fiables.

---

Quand démarrer une nouvelle session vs continuer l'ancienne

Une règle empirique utile : démarrez une nouvelle session quand :

• Vous passez à un sous-problème ou une feature différente
• Le modèle a commencé à halluciner ou à oublier des contraintes
• La conversation a dépassé ~15 000 tokens
• Vous voulez aborder le problème sous un angle différent

Continuez la même session quand :

• Vous itérez sur le même bout de code
• Le modèle a établi un contexte utile (votre schéma, la forme de votre API) qui a pris du temps à mettre en place
• Vous êtes en flow et les réponses sont précises

---

Résumé

• Les context windows sont de la RAM limitée en tokens — quand elles sont pleines, le contenu le plus ancien disparaît silencieusement
• La dégradation de l'attention arrive avant la limite stricte : l'info au "milieu" est sous-pondérée
• Structurez votre contexte de manière dense, impérative, avec les informations prioritaires en dernier
• Chaque nouvelle session repart de zéro — utilisez ATLAS pour persister le contexte automatiquement entre sessions
• Utilisez les checkpoints résumés, les préfixes IMPORTANT :, et le code comme contexte pour les longues sessions