Dans une analyse publiée sur Search Engine Land, Tania Brown décrit ce phénomène sous le nom de context rot, ou dégradation du contexte. Growth Marketing Manager chez Victorious, elle travaille depuis plus de dix ans dans le SEO, la stratégie de contenu et le PPC. Son expertise porte aussi sur l’ingénierie de contenu et les systèmes de production à grande échelle.
Le prompt ne représente qu’une partie du contexte
Le contexte désigne l’ensemble des informations lues par le modèle pendant une tâche. Il comprend le prompt, les fichiers joints, la mémoire, les instructions du projet, les skills et sous-agents de Claude, les réponses des outils et les résultats transmis par les étapes précédentes.
Les informations récupérées par un système RAG et les anciens messages d’une longue conversation rejoignent aussi cet ensemble. Le contexte s’étend donc au-delà du seul prompt.
Un contexte métier plus précis peut modifier les priorités proposées, même lorsque la mission reste comparable. Anthropic définit l’ingénierie de contexte comme la sélection et l’entretien des informations transmises au modèle pendant l’inférence. Le contexte constitue une ressource limitée à gérer, et non un espace à remplir.
Six problèmes peuvent altérer les résultats
Tania Brown distingue six formes de dégradation susceptibles de modifier progressivement les réponses.
| Forme | Effet observé |
|---|---|
| Surcharge | Le volume d’informations rend la réponse plus vague et certaines consignes sont ignorées. |
| Options concurrentes | Plusieurs outils ou modèles valides produisent des résultats différents selon l’exécution. |
| Divergence | Des copies d’un même document évoluent séparément et transmettent des règles incompatibles. |
| Obsolescence | Le workflow reprend d’anciens services, formats, liens ou documents de référence. |
| Contradiction | Deux instructions s’opposent sans indiquer laquelle doit prévaloir. |
| Contamination | Une erreur non vérifiée passe d’une étape à l’autre et devient une information de référence. |
Les symptômes orientent le contrôle. Une réponse devenue plus vague conduit d’abord à examiner le volume de données fourni. Des variations entre plusieurs exécutions peuvent venir de modèles, d’outils ou de fichiers concurrents.
À l’inverse, une erreur répétée à l’identique renvoie plutôt vers une information périmée, une contradiction stable ou une donnée incorrecte transmise par une étape précédente.
Auditer ce que le modèle a réellement lu
Tania Brown conseille d’examiner un workflow fréquent après une nouvelle exécution. Dans Claude Chat et Cowork, les étapes consacrées aux fichiers, aux skills et aux outils peuvent être ouvertes pour consulter les éléments chargés. Dans Claude Code, les commandes /context et /memory donnent accès au contexte actif et aux fichiers de mémoire.
La liste obtenue doit ensuite être comparée aux seules informations nécessaires à la tâche. Le contrôle porte sur les skills, les instructions qui encadrent les réponses de Claude, les connaissances du projet, les dossiers connectés, la mémoire, les anciens échanges et les outils appelés.
Les corrections consistent à séparer extraction et production, désigner un seul outil ou modèle de document et conserver une version de référence pour chaque fichier. Les documents doivent être datés, tandis que les copies et consignes devenues inutiles sont retirées.
Dans une automatisation SEO confiée à Claude, le résultat d’une étape peut alimenter toutes les suivantes. Tania Brown recommande donc de vérifier avant l’étape suivante. Pour les affirmations factuelles, cette vérification s’effectue dans une nouvelle fenêtre de contexte qui contient seulement les informations à contrôler et leurs sources.
L’autrice propose enfin une révision trimestrielle des skills, des connaissances de projet, des dossiers connectés et de la mémoire. Les documents consacrés au fonctionnement des plateformes sont contrôlés chaque mois. Après chaque correction, le workflow est relancé avant toute autre modification afin d’identifier son effet sur le résultat.
