Le TDD du contexte : comment maintenir un contexte d'agent vivant face à la pourriture

Le sprint avait démarré normalement. Un agent de codage chargé de générer les flux d'authentification d'une application critique avait produit, en quelques heures, des centaines de lignes de code parfaitement structurées. Problème : la spec d'authentification avait été modifiée trois semaines plus tôt dans un fichier de contexte que personne n'avait mis à jour. L'agent avait travaillé dur — et juste — sur une réalité qui n'existait plus. Trois jours pour dérouler, comprendre, corriger.

Ce scénario n'est pas exceptionnel. Il est la forme la plus courante de dette de contexte dans les équipes qui adoptent les agents de codage sans appliquer aux specs la même discipline qu'au code. Et contrairement à la dette technique classique, il est invisible jusqu'au moment où il explose — précisément parce que l'agent génère du code cohérent avec ce qu'on lui a donné, même quand ce qu'on lui a donné est faux.

Cet article est un playbook. Il s'appuie sur le TDD du contexte — un concept formalisé par Patrick Debois dans le Context Development Lifecycle — et sur les pratiques qui permettent de maintenir un contexte vivant plutôt que d'accumuler de la pourriture silencieuse.

Le paradoxe : plus le contexte grossit, plus il ment

La pensée naïve sur le contexte est quantitative : plus il est large, mieux l'agent comprend. C'est faux — et la matière empirique est convergente sur ce point.

Patrick Debois, inventeur du terme DevOps et fondateur de Tessl, pose le problème avec précision dans son article fondateur sur le CDLC : « Le contexte pourrit. Comme le code, le contexte entre en conflit et devient obsolète. Une spec périmée est pire que pas de spec : elle induit l'agent en erreur activement. » Cette formule mérite d'être lue deux fois. L'absence de spec laisse l'agent improviser — c'est prévisible et visible. La spec périmée, elle, lui donne confiance dans une réalité qui n'existe plus — c'est indétectable jusqu'au dommage.

La recherche en contexte agentique identifie deux pathologies complémentaires. Le brevity bias : les systèmes compriment excessivement le contexte, perdant des nuances critiques. Le context collapse : la qualité du contexte se dégrade au fil des itérations d'adaptation, créant un cercle vicieux de performance déclinante — ce que les chercheurs de Stanford, SambaNova Systems et UC Berkeley ont documenté dans leur framework ACE (Agentic Context Engineering, arXiv 2025-10-07). Les deux pathologies coexistent souvent : un contexte à la fois trop comprimé et trop contradictoire.

La dégradation n'est pas abstraite. Dans Claude Code avec une fenêtre d'un million de tokens, la pourriture de contexte — cette dégradation de performance liée à la dilution de l'attention sur trop de tokens — commence à apparaître vers 300 000 à 400 000 tokens selon la complexité de la tâche (Thariq, ingénieur Anthropic, 2026-04-14). L'intuition que « plus de contexte résout tout » a une limite physique.

La conclusion contre-intuitive est que les fenêtres de contexte infinies ne résolvent pas le problème de gouvernance. Elles le déplacent : le défi passe de la curation (choisir ce qu'on inclut) à la gouvernance (détecter les conflits, déprécier l'obsolète, maintenir la cohérence). C'est un problème plus difficile, pas moins.

Le TDD du contexte : un concept nommé, pas une métaphore

La bonne nouvelle, c'est que les ingénieurs ont déjà résolu ce problème — pour le code. Le Test-Driven Development impose une discipline simple : avant d'écrire le code, écrire le test qui définit ce que le code doit faire. L'échec du test n'est pas un signal de mauvais code ; c'est un signal de spec incomplète.

Le TDD du contexte applique la même logique. Voici la formulation de Patrick Debois, telle qu'elle apparaît dans la matière first-party du deck Context Engineering (2026-03) : « Un échec d'évaluation n'est pas un défaut de l'agent, c'est une spécification non écrite. Si vous devez expliquer deux fois la même chose, c'est un bug de documentation. »

Cette reformulation est radicale dans ses implications pratiques. Dans la plupart des équipes, quand un agent produit un résultat inattendu, le premier réflexe est de réécrire le prompt — d'expliquer à nouveau, différemment. C'est efficace à court terme et toxique à long terme : on n'a pas corrigé la spec, on a juste ajouté du contexte contradictoire. La prochaine session repartira du même état dégradé.

L'évaluation comme test unitaire de la spec

Une évaluation (eval) dans le contexte agentique fonctionne exactement comme un test unitaire : elle définit un scénario, un input, un output attendu, et mesure l'écart. Mais contrairement aux tests de code déterministes, les LLMs produisent des outputs probabilistes. La qualité de la spec ne se mesure pas sur un run unique — elle se mesure statistiquement sur plusieurs exécutions.

Debois formule l'obligation clairement : « You wouldn't ship code without tests. Why would you ship context without evaluations? » (https://tessl.io/blog/context-development-lifecycle-better-context-for-ai-coding-agents/, 2026-02-19). Un contexte sans evals est un contexte non testé — on fait confiance à l'intuition, pas à la mesure.

Les evals ont un deuxième avantage pratique : elles permettent de naviguer entre modèles de façon factuelle. Quand l'équipe envisage de passer d'un modèle à un autre, les evals fournissent une base de comparaison objective plutôt qu'une séquence de « ça semble mieux sur ce cas ».

La règle des « deux explications »

Le signal le plus simple pour détecter un bug de documentation : si vous ou un collègue avez dû expliquer à l'agent la même contrainte deux fois dans deux sessions différentes, cette contrainte n'est pas dans la spec — elle est dans votre tête. Chaque reformulation manuelle révèle une lacune de documentation, pas un oubli du modèle.

Appliquer cette règle systématiquement change la relation à l'échec. Quand l'agent dérape, la première question n'est plus « quel était le bug du modèle ? » mais « quelle spec manquait ? ». C'est un changement d'attribution qui transforme l'échec en feedback.

Le CDLC : Générer, Évaluer, Distribuer, Observer

Patrick Debois, qui a cofondé le mouvement DevOps en 2009, a publié en février 2026 le Context Development Lifecycle (CDLC) — un cycle de vie en quatre phases qui traite le contexte des agents de codage comme un artefact d'ingénierie à part entière, et non comme un fichier markdown oublié dans un dépôt. L'analogie avec DevOps est assumée et explicite : en 2009, l'enjeu était d'intégrer le développement et les opérations. En 2026, l'enjeu est d'intégrer le développement et l'ingénierie du contexte.

Générer — rendre l'implicite explicite. La plupart des équipes ne fournissent à l'agent que le premier des trois niveaux de contexte : technique (standards, patterns architecturaux). Les deux autres niveaux — projet (priorités, scope, contraintes de timing) et business (conformité, attentes client, règles métier) — restent tacites. Ils se manifestent plus tard dans les sessions comme des specs « manquantes », précisément parce qu'ils n'ont jamais été formalisés.

Évaluer — appliquer le TDD au contexte. Définir le comportement attendu avant de déployer le contexte. Mesurer statistiquement (le non-déterminisme des LLMs rend les snapshots individuels non représentatifs). Traiter chaque échec comme une spécification à compléter.

Distribuer — traiter le contexte comme une dépendance logicielle. Versioning, sémantique, packaging — les mêmes pratiques qui gouvernent npm ou maven s'appliquent au contexte. L'insight clé, et c'est une rupture par rapport à la documentation classique : pour la première fois, partager sa connaissance sous forme de contexte bénéficie directement à l'auteur, pas seulement à l'équipe. Un meilleur contexte collectif améliore les interactions de chacun avec les agents. L'incitation est structurellement alignée.

Observer — fermer la boucle. En production, les agents signalent les lacunes de spec par leurs hésitations, leurs questions répétées, leurs improvisations face au silence du contexte. Ces signaux ne sont pas des bruits à filtrer — ce sont des données à capturer. Chaque hésitation est une alerte de maintenance du contexte.

Les signaux faibles : l'agent hésite, la spec manque

Dans la pratique, comment reconnaître qu'un contexte a besoin d'être mis à jour avant qu'un sprint parte en vrille ? Quatre signaux opérationnels émergent de la veille.

Premier signal : les hésitations répétées. Quand un agent demande régulièrement des clarifications sur le même sujet ou produit des outputs inconsistants d'une session à l'autre sur les mêmes inputs, il ne souffre pas d'un défaut de modèle. Il navigue dans un contexte ambigu ou contradictoire. La spec est incomplète sur ce point.

Deuxième signal : les reformulations forcées. Si vous vous retrouvez à réexpliquer une contrainte que vous avez déjà énoncée, la règle des « deux explications » s'applique : c'est un bug de doc. Le signal est particulièrement fort quand différents membres de l'équipe formulent la même contrainte différemment — signe que le contexte organisationnel n'est pas codifié.

Troisième signal : les résultats inattendus récurrents. Des outputs qui « semblent incorrects » mais dont il est difficile de dire pourquoi indiquent souvent un décalage entre le comportement attendu (dans la tête de l'équipe) et le contexte réel (ce qui est effectivement dans la spec). L'eval manquante rend ce décalage invisible.

Quatrième signal : la mauvaise compaction. Dans les sessions longues, la compaction du contexte — le résumé automatique pour faire de la place — survient quand le modèle est à son point de moindre intelligence (context rot). Si la compaction produit des résumés qui perdent des contraintes critiques, c'est que ces contraintes ne sont pas assez saillantes dans le contexte — elles ne sont pas structurées comme telles, mais noyées dans la prose.

La phase Observer du CDLC fournit le cadre institutionnel pour capturer ces signaux : chaque hésitation, question ou improvisation inattendue de l'agent en production alimente le cycle suivant. Sans cette phase, les signaux se perdent dans le quotidien des sprints.

Le Context Flywheel de Debois (2026-02-26) ajoute une dimension stratégique à cette vigilance : les modèles se commoditisent, les outils convergent. Ce qui crée un avantage durable pour une équipe, c'est le contexte raffiné itération après itération — les cas limites catalogués, les besoins utilisateurs cartographiés, le raisonnement domaine encodé. Un concurrent peut acheter le même modèle ; il ne peut pas reproduire deux ans de cycle CDLC.

Playbook : cinq gestes pour un contexte vivant

La maintenance d'un contexte n'est pas un projet de refonte — c'est un régime de pratique continue. Debois estime le coût à 1 à 2 heures par semaine pour un système qui s'améliore seul, avec à la clé une vélocité ×5 par rapport à un développeur sans contexte structuré (matière DG, Context Engineering deck 2026-03, slide 15). Ce ratio est le retour sur investissement de la rigueur contextuelle.

Geste 1 — Écrire les evals avant la spec. Comme le TDD impose d'écrire le test avant le code, le TDD du contexte impose de définir le comportement attendu avant de rédiger la spec. Qu'est-ce que l'agent doit faire dans ce scénario ? Comment la réussite est-elle mesurable ? Ces questions, posées avant la rédaction, révèlent les zones d'ambiguïté à clarifier — plutôt que de les découvrir en production.

Geste 2 — Versionner le contexte comme une dépendance. Un contexte non versionné est un contexte qui dérive sans qu'on s'en aperçoive. Appliquons à la spec le même soin qu'à une dépendance npm : semantic versioning, changelog, politique de dépréciation. Quand une règle métier change, le contexte doit être mis à jour avec la même formalité qu'une mise à jour de bibliothèque.

Geste 3 — Assigner un propriétaire. Sans ownership explicite, le contexte pourrit — comme la documentation, l'infrastructure et la sécurité avant lui. L'industrie a déjà appris cette leçon trois fois. La résolution est la même : désigner une équipe ou un rôle responsable de la maintenance, de l'enablement (rendre la contribution facile via des outils CLI et des evals en CI) et de la gouvernance (seuil de qualité, détection de conflits, dépréciation).

Geste 4 — Traiter chaque reformulation comme un bug de doc. Instituer la règle des « deux explications » comme une norme d'équipe. Chaque fois qu'un collègue réexplique une contrainte à un agent, c'est une tâche de maintenance : ouvrir un ticket, mettre à jour la spec, exécuter les evals. La reformulation orale ne compte pas — seule la spec mise à jour est une correction réelle.

Geste 5 — Capturer les hésitations de l'agent comme des métriques. Instrumenter les sessions pour loguer les questions posées par les agents, les clarifications demandées, les itérations sur le même output. Ces données alimentent la phase Observer du CDLC et permettent de prioriser la maintenance du contexte sur les zones les plus sollicitées.

La boucle compound (Shipper & Klaassen, référencée dans la matière DG, slide 13-14) illustre l'effet de ces gestes dans le temps : le travail d'exécution représente 10 % du cycle, la validation 40 %, et le stockage des leçons pour les cycles futurs est « l'étape magique ». Chaque bug documenté, chaque insight codifié, rend l'itération suivante plus rapide. La complexité décroît — contrairement à l'ingénierie traditionnelle où chaque feature rend la suivante plus difficile.

Le contexte est un actif, pas un fichier markdown oublié

Chez SFEIR, le Context Engineering est défini comme « l'art de nourrir les agents IA » — une pratique d'ingénierie industrielle, pas une tâche auxiliaire de documentation. La distinction est importante. Un fichier markdown oublié dans un dépôt est une dépense — il coûte à écrire et dérive ensuite. Un contexte versionné, testé, distribué et observé est un actif : il s'améliore avec chaque itération et produit un retour composé sur la vélocité de l'équipe.

C'est la thèse centrale de Patrick Debois dans le CDLC, et c'est aussi celle qui structure notre approche du Context Engineering : « Le contexte est un actif, pas une dépense. L'ingénieur de demain ne sera pas celui qui écrit le meilleur code, mais celui qui structure le meilleur contexte. » (matière DG, Context Engineering deck 2026-03, slide 17).

Le TDD du contexte est le mécanisme qui rend cette thèse opérationnelle. Sans évaluations, la spec est une opinion. Avec des évaluations, c'est une mesure — et une mesure peut être maintenue, comparée, améliorée. Elle peut servir de critère de dépréciation (« cette règle échoue 40 % du temps dans ce scénario — elle est contradictoire avec la règle ajoutée en février »). Elle peut servir d'arbitre entre modèles (« sur notre corpus d'evals, le modèle B performe mieux sur les cas de conformité »). Elle peut servir de base de discussion entre l'équipe et les parties prenantes.

Cette rigueur s'inscrit dans la progression naturelle que SFEIR observe chez ses clients : du prompt engineering (interaction isolée, mémoire éphémère, ROI linéaire) au context engineering (environnement global, mémoire persistante cross-sessions, ROI composé), jusqu'au Harness Engineering — où le harnais de l'agent intègre à la fois les guides feedforward (ce que l'agent doit faire) et les sensors feedback (ce que l'agent a effectivement produit, capturé comme matière pour la prochaine spec). L'évaluation est le sensor fondamental de ce harnais.

La spec périmée de vendredi, la vélocité de lundi

Le sprint du début de cet article s'est terminé par trois jours perdus. Mais l'équipe en a tiré une procédure : tout changement de règle métier déclenche maintenant une mise à jour obligatoire du contexte, avec un run d'evals avant le merge. Ce n'est pas lourd — c'est le coût qu'ils auraient dû payer en amont plutôt qu'en aval.

La dette de contexte fonctionne comme la dette technique : elle s'accumule silencieusement, par des specs légèrement périmées, des règles jamais documentées, des reformulations orales qui ne trouvent jamais le chemin de la spec. Puis elle se paie en une seule fois, lors d'un sprint raté ou d'un incident en production que l'agent a aggravé en suivant consciencieusement des instructions erronées.

Le TDD du contexte n'est pas une surcharge de process. C'est le changement de posture qui transforme les évaluations d'un overhead en boussole — et qui fait de chaque hésitation de l'agent non plus un symptôme à ignorer, mais un signal à capturer.

« Le contexte est un actif, pas une dépense. » La question n'est pas si vous devez maintenir votre contexte — c'est comment vous allez l'organiser pour que cette maintenance coûte 1 à 2 heures par semaine plutôt que trois jours de sprint.

Points clés

Un échec d'évaluation n'est pas un défaut de l'agent. C'est une spécification non écrite. Chaque fois que l'agent dérape, la première question à poser est : « quelle spec manquait ? », pas « quel était le bug du modèle ? »

La règle des deux explications est un outil de détection. Si vous avez dû reformuler la même contrainte à deux reprises dans deux sessions différentes, c'est un bug de documentation — pas un oubli du modèle. La correction est dans la spec, pas dans le prompt.

Le CDLC de Debois fournit le cadre opérationnel. Quatre phases : Générer (rendre l'implicite explicite), Évaluer (TDD du contexte), Distribuer (versioning, packaging, incitation alignée), Observer (les hésitations de l'agent = métriques de maintenance). Chaque phase a un output tangible.

Assigner un propriétaire est non-négociable. Sans ownership explicite, le contexte pourrit — comme la documentation, l'infra et la sécurité avant lui. La maintenance coûte 1-2 heures par semaine ; ne pas la faire coûte des sprints.

Le fossé compétitif est dans le contexte, pas dans le modèle. Les modèles se commoditisent. Un contexte raffiné itération après itération — cas limites catalogués, raisonnement domaine encodé — est ce que les concurrents ne peuvent pas répliquer.

Pour aller plus loin : Context Engineering — le guide complet · CDLC : le contexte comme dépendance logicielle · Compound Engineering : la boucle cumulative · Sécuriser le contexte de vos agents IA · Le coût réel du token budget

Sources

1. SFEIR — Context Engineering, matière first-party, mars 2026.
2. Patrick Debois (Tessl), Context Development Lifecycle — tessl.io, 19 février 2026.
3. Patrick Debois (Tessl), The Context Flywheel — tessl.io, 26 février 2026.
4. Stanford, SambaNova Systems & UC Berkeley, Agentic Context Engineering (ACE) — arxiv.org, 7 octobre 2025.
5. Thariq (Anthropic), gestion de session et contexte 1M dans Claude Code — x.com, 14 avril 2026.