Votre agent IA fonctionne parfaitement pendant les 10 premières étapes.
Puis, aux alentours de l'étape 15, il commence à faire n'importe quoi.
Mauvais appels d'outils. Oubli de vos instructions initiales. Résultats de mauvaise qualité.
La plupart des gens blâment le modèle.
Ce n'est presque jamais le modèle.
C'est ce que le modèle voit.
Organiser ce que le modèle voit s'appelle l'ingénierie du contexte.
C'est en train de devenir la compétence la plus importante pour quiconque construit des agents IA.
Voici le guide complet.
L'ingénierie des prompts est morte. L'ingénierie du contexte est ce qui compte maintenant.
Vous avez entendu parler de l'ingénierie des prompts.
Rédiger des instructions claires. Donner de bons exemples. Dire au modèle quel rôle jouer.
Cela fonctionne parfaitement pour un chatbot.
Cela cesse de fonctionner dès que vous construisez un agent.
Voici pourquoi.
Un chatbot répond à une question et s'arrête.
Un agent entreprend des actions — naviguer sur le web, appeler des API, écrire du code, exécuter des commandes — étape après étape après étape, parfois pendant des dizaines d'étapes.
Chaque étape produit un résultat qui est ajouté au contexte du modèle.
Et ce contexte est limité.
L'équipe d'ingénierie d'Anthropic le définit ainsi :
« Le contexte est l'ensemble des tokens inclus lorsque vous interrogez un LLM. L'ingénierie du contexte consiste à optimiser l'utilité de ces tokens pour atteindre systématiquement un résultat souhaité. »
En clair : assurez-vous que votre agent voit les bonnes informations, dans le bon format, au bon moment.
L'ingénierie des prompts est un sous-ensemble de l'ingénierie du contexte.
L'ingénierie du contexte est tout.
La fenêtre de contexte de votre agent est de la RAM. Et elle se remplit.
LangChain a la bonne analogie pour cela.
Considérez un LLM comme un nouveau type de système d'exploitation.
Le modèle est le CPU — il fait le raisonnement.
La fenêtre de contexte est la RAM — la mémoire de travail où tout ce que le modèle peut voir et sur quoi il peut raisonner actuellement réside.
Tout comme votre ordinateur ralentit lorsque la RAM se remplit, le raisonnement de votre agent se dégrade lorsque la fenêtre de contexte devient encombrée.
C'est ce qu'on appelle la pourriture du contexte.
Chroma a mené une étude évaluant 18 modèles de pointe — GPT-4.1, Claude 4, Gemini 2.5, Qwen3, et d'autres.
Les performances de chaque modèle se sont dégradées à mesure que la longueur des entrées augmentait.
Pas à la limite absolue. Bien avant.
Un modèle avec une fenêtre de 200 000 tokens peut montrer une dégradation significative à 50 000 tokens.
Le déclin est continu. Pas un précipice.
Pourquoi ? Les Transformers fonctionnent en faisant en sorte que chaque token fasse attention à tous les autres tokens — créant des relations au carré n. À mesure que le contexte grandit, la capacité du modèle à maintenir toutes ces relations s'amenuise.
Et puis il y a le problème « Perdu au Milieu ».
Les LLM montrent une courbe d'attention en forme de U.
→ Début du contexte : bien mémorisé
→ Fin du contexte : bien mémorisé
→ Milieu : largement ignoré
Les chercheurs ont mesuré une baisse de précision de plus de 30 points de pourcentage lorsque l'information pertinente passait du début du contexte au milieu.
Vos instructions originales — enterrées sous 50 000 tokens de résultats d'outils — disparaissent effectivement.
Les utilisateurs de Claude Code ont constaté que la qualité des résultats se dégrade à 40–60 % de la capacité du contexte. Bien avant toute limite absolue.
Ce qui entre réellement en compétition pour l'espace dans le contexte de votre agent
7 catégories. Toutes se disputent la même fenêtre limitée.
1. Prompt Système
L'identité de l'agent. Les règles de comportement. La logique de flux de contrôle. Les instructions pour différents types de tâches. Dans un agent, ce n'est pas juste « sois utile ». Cela peut définir toute l'architecture.
2. Définitions d'Outils
Chaque outil que l'agent pourrait appeler a besoin d'un schéma décrivant ce qu'il fait, quels paramètres il prend et quand l'utiliser.
3. Résultats des Appels d'Outils
Chaque appel d'outil ajoute son résultat au contexte. Une récupération de page web : 5 000 à 10 000 tokens. Une lecture de fichier : similaire. Cela s'accumule rapidement.
4. Connaissances Récupérées (RAG)
Documents extraits de bases de données vectorielles, résultats de recherche, réponses d'API — tout ce qui est récupéré pour éclairer les décisions de l'agent.
5. Historique de la Conversation
La transcription complète de tout ce qui s'est passé. Messages utilisateur, réponses de l'agent, raisonnements, décisions antérieures. Croît linéairement à chaque tour.
6. Mémoire
Mémoire à court terme de la session en cours. Mémoire à long terme des sessions précédentes — préférences utilisateur, résultats antérieurs, modèles appris.
7. État de l'Agent
Plan actuel, liste de tâches, marqueurs de progression, notes de brouillon. Les méta-informations qui suivent où l'agent en est dans une tâche en plusieurs étapes.
Tous les 7 en compétition pour la même fenêtre.
L'ingénierie du contexte consiste à décider ce qui gagne.
Les 4 Stratégies Fondamentales
LangChain a publié le cadre qui organise chaque technique d'ingénierie du contexte en 4 catégories.
Chaque technique que vous apprendrez s'inscrit dans l'une d'elles.
Écrire. Sélectionner. Compresser. Isoler.
Stratégie 1 — Écrire (Les agents oublient. Donnez-leur un moyen de se souvenir.)
Lorsque le contexte d'un agent se remplit et est compacté, il perd des informations.
Si l'agent n'a rien écrit avant que cela n'arrive — cette information est perdue à jamais.
Écrire signifie donner à l'agent des moyens de persister des informations en dehors de la fenêtre de contexte.
Trois formes :
Blocs-notes
Donnez à l'agent un outil qui lui permet de prendre des notes pendant une tâche. Résultats intermédiaires. Décisions prises. Informations dont il sait qu'il aura besoin plus tard.
Anthropic a construit un outil « pense » — un espace dédié pour que Claude travaille sur des problèmes.
Sur le benchmark tau-bench, cela a amélioré les performances jusqu'à 54 % sur certaines tâches.
Fichiers de Règles
Mémoire procédurale persistante.
Si vous avez utilisé Claude Code, vous avez vu CLAUDE.md.
Instructions chargées au début de chaque session — architecture du projet, conventions, comment exécuter les tests, à quoi faire attention.
L'agent le lit à chaque démarrage.
Il n'oublie jamais les fondamentaux.
Extraction de Mémoire
L'agent sauvegarde des faits, des préférences utilisateur et des modèles appris afin de pouvoir les récupérer entre les sessions.
Vit entièrement en dehors de la fenêtre de contexte.
Les informations dont l'agent aura besoin demain sont là, qui l'attendent quand demain arrivera.
Stratégie 2 — Sélectionner (Ne donnez pas tout à l'agent. Donnez-lui ce dont il a besoin maintenant.)
Un agent avec 40 outils, une grande base de connaissances et plusieurs sessions d'historique ne peut pas tout charger à la fois.
Quelque chose doit décider ce qui est pertinent pour cette étape.
RAG traditionnel : le système décide.
L'utilisateur demande → récupérer des documents → les fourrer dans le prompt → terminé.
Statique. Unique. Le modèle n'a pas son mot à dire.
RAG agentique : l'agent décide. Il cherche ce dont il a besoin, affine les requêtes, choisit les outils, détermine quand il a suffisamment d'informations.
La récupération comme un processus itératif, pas un pipeline unique.
Cela compte parce que ce qui est pertinent change à chaque étape — et seul l'agent sait ce dont il aura besoin ensuite.
Le problème de la sélection des outils est celui qui piège le plus de monde.
Si votre agent a 40 outils ou plus, cela représente potentiellement 10 000 tokens de définitions d'outils dans le contexte avant même que le travail ne commence.
La solution : RAG sur les descriptions d'outils.
Au lieu de déverser toutes les définitions d'outils à chaque appel, utilisez la recherche sémantique pour ne faire apparaître que les outils pertinents pour l'étape en cours.
Un article appelé RAG-MCP a testé cela.
Précision de sélection des outils : 14 % → 43 % (amélioration 3x). Utilisation de tokens : réduite de moitié environ.
Anthropic appelle cela une stratégie hybride : charger le contexte essentiel au préalable (comme CLAUDE.md), laisser l'agent faire une récupération juste-à-temps pour tout le reste.
Chargez les bases en amont. Récupérez le reste à la demande.
Stratégie 3 — Compresser (Le contexte s'accumule. Gardez le sens, coupez les tokens.)
Même avec une bonne sélection, le contexte s'accumule.
Chaque appel d'outil, document récupéré et décision reste dans la fenêtre.
Imaginez que votre agent a fait 20 appels d'outils.
Contexte : 80 000 tokens de résultats d'outils accumulés, d'historique de conversation, de traces de raisonnement.
La plupart de cela n'est plus pertinent. L'agent a déjà agi en conséquence.
Mais c'est toujours là, occupant de l'espace, dégradant l'attention, augmentant les coûts et la latence.
Vous pouvez compresser à 3 points.
Avant que l'information n'entre dans le contexte :
→ Découpez les grands documents en morceaux cohérents avant la récupération
→ Reclassez pour que seuls les morceaux les plus utiles entrent
→ Résumez les résultats d'outils à la volée avant qu'ils n'entrent dans le contexte principal
Pendant que l'agent travaille :
→ Résumé roulant de l'historique de la conversation — mis à jour en continu
→ Hybride populaire : gardez les 10 derniers messages verbatim + résumez tout ce qui est plus ancien
→ Découpage dur : supprimez les messages plus anciens une fois que le contexte atteint un seuil de taille
→ Auto-compaction de Claude Code : se déclenche à 95 % de capacité, résume automatiquement la trajectoire complète
Après que l'agent a agi sur quelque chose :
→ Effacement des résultats d'outil : une fois qu'un résultat d'outil a été utilisé il y a 15 étapes, supprimez-le
→ Remplacez par un résumé d'une ligne ou supprimez-le entièrement
→ L'agent n'a pas besoin du texte intégral d'une page web qu'il a récupérée il y a 20 étapes
Le but : réduire le nombre de tokens. Préserver ce qui compte vraiment.
Stratégie 4 — Isoler (La stratégie la plus puissante. Permet les systèmes multi-agents.)
Voici le problème plus profond des longues exécutions d'agents.
Ce n'est pas seulement l'espace. C'est la contamination.
Les recherches détaillées dans les fichiers de la phase de recherche sont encore dans le contexte lorsque l'agent passe à l'écriture de code.
Cet ancien contexte de recherche est maintenant du bruit. Il distrait le modèle pendant une phase où il doit se concentrer sur une implémentation propre.
Isoler signifie donner à différentes parties du travail leurs propres fenêtres de contexte séparées.
Sous-agents
Un agent parent délègue une sous-tâche ciblée — « cherche dans la base de code tous les fichiers liés à l'authentification » — à un sous-agent.
Le sous-agent travaille dans sa propre fenêtre de contexte vierge.
Lorsqu'il fait son rapport, il ne renvoie qu'un résumé condensé.
Toutes les opérations de recherche désordonnées restent isolées dans le contexte du sous-agent et ne polluent jamais le parent.
Isolation par schéma d'état (approche de LangGraph)
Concevez l'état de l'agent de sorte que différents champs stockent différents types de contexte.
Le LLM ne voit que les champs pertinents pour l'étape en cours.
Les résultats d'outils se trouvent dans un champ « coulisses » — invisibles pour le modèle jusqu'à ce qu'ils soient explicitement présentés.
Contrôle fin sur ce que l'agent voit à chaque étape sans avoir à créer des sous-agents séparés.
L'isolation est ce qui rend les workflows complexes en plusieurs étapes réellement fiables.
Différents travaux. Différentes fenêtres de contexte. Pas de contamination.
4 Façons dont les Agents Échouent (Nommez l'échec. Corrigez-le.)
Drew Breunig a identifié quatre modes d'échec distincts à mesure que le contexte de l'agent grandit.
Chaque agent défaillant que vous avez jamais vu tombe dans l'un de ces cas.
Échec 1 : Empoisonnement du Contexte
Une hallucination ou une erreur entre dans le contexte.
L'agent la référence encore et encore dans les étapes suivantes.
Une mauvaise donnée de l'étape 5 se répercute sur toutes les étapes suivantes.
Solution : Validez les résultats des outils avant qu'ils n'entrent dans le contexte. Après avoir récupéré d'une erreur, compressez l'historique des tentatives échouées. Ne laissez pas 10 étapes de débogage sans issue visibles alors que seule la résolution compte.
━━━
Échec 2 : Distraction par le Contexte
Le contexte devient si long que le modèle commence à trop s'appuyer sur l'historique récent.
Au lieu de synthétiser un nouveau plan, il ne fait que ressasser ce qu'il a récemment fait.
Il cesse de penser. Il commence à répéter.
Solution : Résumez et élaguez agressivement. Même lorsque vous disposez d'une grande fenêtre de contexte. Une grande fenêtre ne signifie pas qu'il faut la remplir.
━━━
Échec 3 : Confusion du Contexte
Un contenu superflu conduit le modèle à des décisions de mauvaise qualité.
Exemple classique : un modèle échoue sur un benchmark lorsqu'on lui donne 46 outils — même si le contexte était bien dans les limites — mais fonctionne correctement avec seulement 19 outils.
Les outils n'étaient pas trop nombreux pour que le contexte les contienne.
Ils étaient trop nombreux pour que le modèle puisse raisonner clairement.
Solution : Gestion dynamique des outils. Utilisez RAG-MCP pour ne faire apparaître que les outils pertinents pour l'étape en cours. Gardez l'ensemble d'outils adapté à la phase actuelle.
━━━
Échec 4 : Conflit de Contexte
Une nouvelle information contredit quelque chose déjà dans le contexte.
Le prompt système dit une chose. Un document récupéré dit quelque chose de différent.
L'agent ne peut pas concilier la contradiction. Produit un comportement incohérent.
Solution : Établissez un ordre d'autorité clair. Prompt système > faits récupérés > historique de la conversation. Validez les nouvelles informations par rapport au contexte existant avant de les injecter. Utilisez des balises XML et des en-têtes clairs pour que le modèle sache quelle source croire.
Comment Rédiger des Prompts Système pour Agents (Pas des Chatbots. Des Agents.)
Un prompt système de chatbot définit un ton.
« Vous êtes un assistant serviable. Soyez concis et amical. »
Un prompt système d'agent définit une architecture.
Il spécifie le flux de contrôle — comment aborder les types de tâches, quels outils utiliser quand, que faire en cas d'erreur, quelles garde-fous suivre.
C'est plus proche de la rédaction d'une description de poste pour un employé autonome que d'un prompt de personnalité.
Anthropic appelle cela écrire à la « bonne altitude ».
Trop prescriptif : « Si l'utilisateur mentionne la facturation ET mentionne un remboursement ET que le montant est supérieur à 100 $, appelez l'outil X. » Fragile. Casse à chaque cas limite que vous n'avez pas anticipé.
Trop vague : « Soyez utile et utilisez les outils appropriés. » Ne donne rien à l'agent. Il ne peut pas prendre de bonnes décisions autonomes sans signaux concrets.
Le point idéal : Suffisamment spécifique pour guider le comportement autonome. Suffisamment flexible pour que le modèle puisse appliquer son jugement dans des situations nouvelles. Des heuristiques solides. Pas de règles rigides.
Conseils pratiques :
→ Organisez avec des balises XML ou des en-têtes markdown — Contexte, Instructions, Guide des Outils
→ Commencez minimal et itérez sur les échecs — n'essayez pas d'anticiper tous les cas limites à l'avance
→ Minimal ne signifie pas court — un prompt système d'agent complexe peut faire des milliers de tokens et c'est bien tant que chaque token mérite sa place
→ Utilisez des exemples few-shot — montrez à l'agent à quoi ressemble un bon comportement plutôt que d'essayer de décrire chaque règle en mots
Le Cache KV : La raison $$$ de se soucier de l'ordre du contexte
La plupart des développeurs d'agents ne savent pas que cela existe.
Lorsque vous envoyez des tokens à un LLM, le modèle calcule des représentations clé-valeur pour chaque token.
Coûteux en calcul.
Donc les fournisseurs d'inférence mettent en cache ces représentations.
Si le début de votre contexte — le préfixe — reste le même entre les appels API, le fournisseur réutilise le calcul mis en cache et ne traite que les nouveaux tokens à la fin.
Rapide. Peu coûteux.
Mais si vous réorganisez ou modifiez la première partie de votre contexte entre les appels — vous invalidez le cache. Le fournisseur recalcule tout à partir de zéro.
La différence de coût sur Claude Sonnet :
→ Tokens d'entrée mis en cache : 0,30 $ par million
→ Tokens d'entrée non mis en cache : 3,00 $ par million
10x de différence.
Pour un agent effectuant 30 à 40 appels API par tâche, cela s'additionne rapidement.
Règles pratiques pour l'efficacité du cache KV :
→ Le contenu stable va en HAUT du contexte — prompt système, définitions d'outils, tout ce qui ne change pas entre les tours
→ Le contenu dynamique va en BAS — historique de la conversation, étape en cours, état de l'agent → N'ajoutez et ne supprimez pas dynamiquement des outils en cours de conversation — cela invalide le cache
→ Utilisez le masquage d'outils au lieu de la suppression d'outils — gardez toutes les définitions d'outils stables dans le préfixe (mis en cache), marquez simplement ceux qui ne sont pas pertinents comme indisponibles pour la phase en cours
Le Workflow Qui Livre 35 000 Lignes de Code en 7 Heures
Dex Horthy (PDG de HumanLayer) a présenté cela au AI Engineer Code Summit.
Son équipe l'aurait utilisé pour livrer environ 35 000 lignes de code dans une grande base de code Rust en une seule session de 7 heures.
La méthode : Compaction Intentionnelle Fréquente.
Structurez le travail de l'agent en phases. Chaque phase produit un artefact compacté. Chaque nouvelle phase commence avec une fenêtre de contexte fraîche contenant uniquement cet artefact.
Restez délibérément en dessous de 40–60 % de la fenêtre de contexte à tout moment.
Phase 1 — Recherche
Des sous-agents explorent la base de code. Lisent les fichiers. Tracent les flux de données. Cartographient l'architecture.
Tous les résultats de grep désordonnés et le contenu des fichiers restent dans les contextes des sous-agents. N'atteignent jamais le parent. (Isoler)
Sortie : un research.md compact — chemins de fichiers, signatures de fonctions, motifs, pièges. (Écrire)
Réinitialisation du contexte : la recherche brute utilisait 60–80 % de la fenêtre. L'artefact de recherche la compresse à 15–20 %. (Compresser)
Phase 2 — Planification
Nouvelle fenêtre de contexte. Contient uniquement : document de recherche + définition du problème.
L'agent produit un plan d'implémentation détaillé.
C'est le point de contrôle de révision humaine le plus important.
Attrapez les erreurs de logique ici, où les corriger est facile et gratuit. Plus tard, cela coûte des heures.
Phase 3 — Implémentation
Encore une nouvelle fenêtre de contexte. Contient uniquement : le plan.
L'agent le suit étape par étape.
Pour les tâches complexes : un progress.md suit ce qui a été complété et ce qui reste. (Écrire)
Le résultat : un agent propre et concentré à chaque phase. Pas de contamination. Pas de pourriture du contexte. Pas d'« étape 20 bâclée ».
Comment les meilleures plateformes gèrent cela différemment
Claude Code
Récupération hybride. CLAUDE.md est chargé au préalable. Des outils comme glob et grep gèrent la navigation juste-à-temps dans la base de code.
Auto-compaction à 95 % — préserve les décisions architecturales et les 5 fichiers les plus récemment consultés.
Peut générer des sous-agents pour des sous-tâches complexes, chacun avec son propre contexte vierge.
Philosophie : « faire la chose la plus simple qui fonctionne. » Laisser le modèle être intelligent sur ce dont il a besoin et lui donner des outils pour aller le chercher.
Manus
Ordre du contexte optimisé pour le cache KV : préfixe stable, suffixe dynamique. Masquage d'outils, pas suppression.
Pipeline de compression d'observation — chaque résultat d'outil est traité avant d'entrer dans le contexte de l'agent.
Liste de tâches persistante pour le suivi de l'état.
Système de fichiers comme mémoire de débordement pour le contexte évincé.
Conçu pour l'échelle. Servir des centaines de milliers d'utilisateurs où l'efficacité est un problème de coût opérationnel.
Agent ChatGPT
Approche axée sur le visuel. L'agent interagit avec un navigateur GUI.
Des captures d'écran sont ajoutées au contexte sous forme d'instantanés visuels. Le modèle raisonne sur ce qu'il voit.
Les tokens visuels sont chers, donc l'agent est sélectif quant au nombre de captures d'écran.
Utilise l'apprentissage par renforcement (RL) pour apprendre des stratégies optimales d'utilisation des outils à travers des milliers de machines virtuelles plutôt que de les programmer explicitement.
Google ADK
L'approche architecturale la plus rigoureuse.
Trois principes de conception :
- Séparer le stockage de la présentation — l'état durable n'est pas la même chose que ce qui apparaît dans chaque appel API
- Transformations explicites — des processeurs nommés et ordonnés qui transforment le contexte en étapes testables et composables
- Contextualiser par défaut — chaque appel de modèle ne voit que les informations minimales requises
La discipline d'ingénierie plutôt que l'artisanat du prompt.
Le pipeline universel du tour d'agent
Chaque plateforme sérieuse converge vers la même boucle en 5 étapes par tour d'agent :
→ Collecter — entrée utilisateur, historique de la conversation, résultats d'outils, documents récupérés, état de l'agent
→ Sélectionner — ce qui est pertinent pour cette étape dans le budget de tokens restant
→ Compresser — résumer, tronquer ou restructurer pour s'adapter au contexte → Organiser — contenu stable d'abord (cache), contenu dynamique ensuite
→ Assembler + appeler — contexte final → appel API → obtenir le résultat → boucler
C'est la boucle qui s'exécute à l'intérieur de chaque agent de production que vous avez jamais utilisé.
Comprendre cela est ce qui sépare ceux qui construisent des agents fiables de ceux qui se demandent pourquoi leur agent devient bâclé à l'étape 15.
Le résumé
La pourriture du contexte est réelle et commence bien avant votre limite de contexte.
Les 4 stratégies qui la corrigent :
→ Écrire — persister les informations en dehors du contexte pour que les agents n'oublient pas
→ Sélectionner — n'intégrer que ce qui est nécessaire pour cette étape
→ Compresser — couper les tokens, garder le sens, de manière proactive et non réactive
→ Isoler — contextes séparés pour des travaux séparés, pas de contamination
Les 4 modes d'échec à surveiller :
→ Empoisonnement — les mauvaises données se répercutent à chaque étape
→ Distraction — un long historique fait que les agents ressassent au lieu de penser
→ Confusion — trop d'outils dégrade la qualité des décisions
→ Conflit — les contradictions produisent un comportement incohérent
Le cache KV vaut 10x d'économies. Mettez le contenu stable en premier.
Le meilleur workflow : recherche → compacter → planifier → compacter → implémenter. Contexte frais à chaque phase.
L'ingénierie du contexte n'est pas optionnelle pour un travail sérieux sur les agents.
C'est le travail.
Si cela a été utile :
→ Repostez pour le partager avec tous les développeurs d'agents que vous connaissez
→ Suivez @sairahul1 pour plus de systèmes qui fonctionnent pendant que vous dormez
→ Mettez-le en favori — vous reviendrez au cadre des 4 stratégies
J'écris sur l'IA, la construction de produits et les systèmes qui fonctionnent réellement.
