Architecture 3-Tier du contexte : Hot, Warm et Cold Memory

Le paradoxe du prompt vide : quand 80 % du travail se fait avant d'écrire

Une étude portant sur 283 sessions de travail avec des agents IA révèle un chiffre qui devrait faire réfléchir tout architecte logiciel : l'infrastructure contextuelle représente désormais 24,2 % de la documentation totale produite dans un projet impliquant des LLMs. Et pourtant, la plupart des équipes continuent de passer l'essentiel de leur énergie à peaufiner leurs prompts.

Patrick Debois, l'inventeur du DevOps, formule ce paradoxe avec une image saisissante : « Chaque session est un nouvel employé — un employé qui repart de zéro, sans mémoire musculaire ni conversations de couloir. » Un LLM, aussi puissant soit-il, ne se souvient de rien entre deux sessions. Il ignore vos conventions d'équipe, vos décisions architecturales passées, les raisons pour lesquelles vous avez choisi telle bibliothèque plutôt qu'une autre. À chaque nouvelle conversation, vous recrutez un expert brillant mais amnésique.

C'est de ce constat qu'émerge une discipline nouvelle, encore en cours de structuration, mais dont les premiers travaux — notamment ceux de Vasilopoulos, Debois, Shipper et Klaassen publiés entre 2025 et 2026 — dessinent des contours précis : le Context Engineering.

Du Prompt Engineering au Context Engineering : un changement de paradigme

Le Prompt Engineering tel qu'il s'est pratiqué ces dernières années est une discipline artisanale. On optimise une interaction isolée, on ajuste le ton, on reformule une instruction pour obtenir une réponse légèrement meilleure. C'est utile. Mais c'est fondamentalement limité.

Sa principale faiblesse ? Il traite chaque session comme un événement autonome. La mémoire est éphémère, le retour sur investissement est linéaire — vous recommencez le même travail à chaque fois — et l'approche ne passe pas à l'échelle.

Le Context Engineering renverse cette logique. Plutôt que d'optimiser une interaction, il optimise l'environnement global dans lequel l'agent opère. La mémoire devient persistante, traversant les sessions. L'approche est industrielle : le contexte est versionné, distribué, maintenu comme une dépendance logicielle. Et le retour sur investissement est composé — chaque effort de documentation profite aux cycles futurs, de façon exponentielle.

Pour reprendre une analogie familière aux développeurs : le Prompt Engineering, c'est écrire un bon commentaire dans le code. Le Context Engineering, c'est construire une documentation vivante, testée, versionnée, qui s'améliore à chaque sprint.

L'architecture 3-Tier du contexte : Hot, Warm et Cold Memory

Le modèle le plus structurant proposé par Vasilopoulos est ce qu'on appelle l'architecture 3-Tier de la mémoire contextuelle. À l'image d'une architecture de données classique, elle distingue trois niveaux selon la fréquence d'accès, la nature de l'information et le coût de chargement.

Tier 1 — Hot Memory : la constitution de l'agent

La Hot Memory est le socle permanent. Elle est toujours chargée, quelle que soit la tâche en cours. On y trouve les conventions fondamentales, les principes directeurs, la « culture d'entreprise » de l'agent : ton, style de réponse, règles de nommage, interdictions absolues, identité du projet.

Concrètement, pour un agent assistant au développement back-end chez un de nos clients, la Hot Memory pourrait contenir : le langage de programmation principal, les conventions de nommage choisies par l'équipe, les principes d'architecture retenus (hexagonale, CQRS…), et quelques règles absolues comme « ne jamais exposer de données personnelles dans les logs ».

Ce tier est court, dense en directives, et rarissimement modifié. C'est la constitution : on ne la réécrit pas à chaque sprint.

Tier 2 — Warm Memory : les experts à la demande

La Warm Memory regroupe des agents ou modules spécialisés, invoqués à la demande selon le contexte de la tâche. Contrairement à la Hot Memory, elle est majoritairement factuelle — environ 50 % de faits, peu de directives — et modulaire.

Imaginez un agent « expert sécurité » que l'on active uniquement lors d'une revue de code sensible, ou un agent « domaine métier assurance » que l'on charge quand la conversation porte sur les règles de calcul de primes. Ces experts ne sont pas là en permanence — cela alourdirait inutilement le contexte — mais ils peuvent être invoqués précisément quand le besoin s'en fait sentir.

Cette modularité est clé : elle permet de composer des contextes riches sans dépasser les fenêtres de tokens disponibles, et surtout sans noyer l'agent dans des informations non pertinentes pour la tâche en cours.

Tier 3 — Cold Memory : la base de connaissance de référence

La Cold Memory est le savoir massif : spécifications techniques, documentation API, référentiels métier, historiques de décisions architecturales. Elle n'est jamais chargée par défaut, mais tirée au besoin — typiquement via des mécanismes de RAG (Retrieval-Augmented Generation) ou de recherche vectorielle.

C'est la bibliothèque. On n'en mémorise pas tout le contenu, mais on sait qu'elle existe et comment y accéder. Un agent bien architecturé sait quand aller chercher dans cette base plutôt que de répondre de mémoire — et surtout, il sait ne pas inventer ce qu'il n'y trouve pas.

La distinction entre ces trois tiers n'est pas qu'académique. Elle conditionne directement les performances de l'agent, son coût d'utilisation (les tokens chargés en Hot Memory ont un coût à chaque appel) et sa maintenabilité dans le temps.

Le CDLC : quand le DevOps rencontre l'ingénierie du contexte

Une des contributions les plus opérationnelles de ces travaux est la notion de Context Development Lifecycle (CDLC) — une approche qui applique au contexte les principes éprouvés du DevOps.

Le cycle comprend quatre phases :

• Générer : rendre l'implicite explicite. C'est l'étape la plus difficile culturellement. Il s'agit de formaliser tout ce que l'équipe sait mais n'a jamais écrit — les décisions tacites, les conventions orales, les « on fait toujours comme ça ».
• Évaluer : appliquer au contexte les principes du TDD. Un échec de l'agent n'est pas un défaut du modèle — c'est une spécification non écrite. Si vous devez expliquer deux fois la même chose à votre agent, c'est un bug de documentation.
• Distribuer : packager le contexte comme une dépendance logicielle, avec versioning sémantique (à la manière de npm ou Maven). Les équipes peuvent ainsi aligner leurs agents sur une version précise du contexte, et les montées de version sont gérées de manière contrôlée.
• Observer : mettre en place une boucle de feedback. Les hésitations de l'agent en production — les reformulations, les demandes de précision, les erreurs récurrentes — sont autant de signaux qui indiquent des lacunes dans la spécification.

Ce dernier point mérite qu'on s'y attarde. En production, un agent qui hésite ou qui produit des réponses inconsistantes ne souffre pas nécessairement d'une limitation du modèle de base. Il souffre d'un contexte insuffisant. Les symptômes de l'agent sont les tests d'intégration de votre documentation.

Le contexte pourrit — et c'est dangereux

Comme le code, le contexte vieillit mal s'il n'est pas maintenu. Une spécification périmée est pire que l'absence de spécification : elle induit activement l'agent en erreur, avec une confiance apparente qui rend la détection de l'erreur encore plus difficile.

Chez SFEIR, nous accompagnons des équipes qui découvrent ce problème de la manière la plus douloureuse : un agent qui, pendant des semaines, a appliqué une convention obsolète parce que personne n'avait mis à jour le fichier de contexte après un changement d'architecture. Le modèle fonctionnait parfaitement — c'est la documentation qui était fausse.

La gouvernance du contexte inclut également une dimension sécurité souvent sous-estimée : le contexte représente une surface d'attaque potentielle. Il contient des informations sensibles sur les systèmes, les conventions, parfois des éléments métier confidentiels. Il nécessite des mécanismes d'audit et de contrôle d'accès au même titre que le code source.

Compound Engineering : la boucle qui change tout

Si le Context Engineering définit l'architecture, le Compound Engineering — tel que formalisé par Shipper et Klaassen — en est la pratique quotidienne. Et c'est là que réside le véritable levier de productivité.

L'ingénierie traditionnelle souffre d'un problème bien connu : la complexité croissante. Chaque nouvelle fonctionnalité s'appuie sur des fondations de plus en plus chargées de dette technique. La centième feature est mécaniquement plus difficile à implémenter que la première. C'est la loi de la gravité du logiciel.

Le Compound Engineering propose une inversion de ce gradient. Chaque feature rend la suivante plus facile, parce que chaque cycle enrichit le contexte disponible pour les cycles futurs. La boucle est vertueuse par construction.

La répartition du temps selon le modèle Compound

Shipper et Klaassen proposent une répartition du temps en quatre phases qui rompt avec les intuitions habituelles :

• Plan (Planifier) : enseigner au système ce qu'il doit faire. Produire du contexte structuré, consommable par l'agent. C'est là que se concentre un effort initial important.
• Work (Exécuter) : l'exécution proprement dite représente paradoxalement une part minoritaire du temps total — environ 10 % dans les équipes qui maîtrisent le modèle.
• Assess (Évaluer) : la validation est longue, environ 40 % du temps. Vérifier la qualité, tester les cas limites, identifier les lacunes du contexte révélées par l'exécution.
• Compound (Capitaliser) : l'étape « magique ». Chaque bug, chaque insight, chaque décision de la session est documenté et versé dans le contexte pour les cycles futurs. C'est cette étape qui transforme la documentation d'une corvée en carburant productif.

Ce modèle a une vertu supplémentaire, souvent négligée : il aligne les incitations. Dans les organisations traditionnelles, documenter est un effort altruiste — on le fait pour ses collègues, pas pour soi. Avec le Compound Engineering, documenter aide directement l'auteur lors de sa prochaine session. La base de contexte enrichie bénéficie immédiatement à celui qui l'a enrichie.

Le Context Flywheel de Debois

Patrick Debois nomme ce phénomène le Context Flywheel : une boucle vertueuse où l'output d'une session enrichit l'input de la suivante. Plus le volant tourne, plus il accumule d'élan. Les premières itérations sont coûteuses à lancer — c'est l'investissement initial. Mais passé un seuil, le système s'auto-alimente.

En pratique, les équipes qui ont intégré cette approche rapportent une accélération significative à mesure que leur base de contexte mûrit. Les estimations avancées dans les travaux de référence évoquent un multiplicateur de vélocité pouvant atteindre ×5 pour un développeur bien outillé par rapport à un développeur travaillant sans infrastructure contextuelle. Un chiffre à prendre avec prudence — il dépend fortement du domaine, de la maturité de la base de contexte et du type de tâches — mais qui illustre l'ordre de grandeur des gains possibles.

Et le coût de maintenance ? Environ 1 à 2 heures par semaine pour maintenir un système qui continue à s'améliorer de lui-même. C'est le prix d'un investissement qui se rembourse à chaque cycle.

Convergence des trois visions : architecture, méthodologie et pratique

Ce qui rend ce corpus de travaux particulièrement solide, c'est que trois approches distinctes convergent vers les mêmes conclusions.

Vasilopoulos apporte la dimension architecturale : un contexte bien structuré en 3 tiers accélère toutes les features adjacentes. L'architecture n'est pas une fin en soi — c'est un accélérateur systémique.

Debois apporte la dimension méthodologique, avec sa vision DevOps du cycle de vie du contexte. Son insight central : traiter le contexte comme du code — avec les mêmes exigences de qualité, de versioning et de testing — transforme une pratique artisanale en discipline industrielle.

Shipper et Klaassen apportent la dimension pratique avec le Compound Engineering. Leur contribution est de rendre tangible, au niveau du flux de travail quotidien d'un développeur, ce que signifie concrètement « investir dans le contexte ».

La synthèse de ces trois visions peut se résumer ainsi : le contexte est un actif, pas une dépense. Il s'amortit, il génère des intérêts composés, il peut être transmis, audité, mis à jour. L'ingénieur de demain ne sera pas uniquement celui qui écrit le meilleur code, mais celui qui structure le meilleur contexte.

Comment SFEIR accompagne ses clients sur ces enjeux

Chez SFEIR, nous avons intégré ces principes dans nos pratiques d'accompagnement sur les projets d'IA agentique et de développement assisté. Nous observons régulièrement les mêmes patterns chez nos clients : des équipes qui déploient des agents puissants mais qui peinent à les maintenir dans le temps, parce qu'elles n'ont pas structuré leur infrastructure contextuelle.

Notre approche s'articule autour de plusieurs axes concrets :

• Audit contextuel : identifier ce qui est implicite dans les équipes et qui devrait être formalisé en Hot Memory. C'est souvent là que se cache l'essentiel de la valeur — dans les conventions orales, les décisions de design jamais documentées, les règles métier que tout le monde « sait ».
• Architecture de la mémoire : aider les équipes à distinguer ce qui relève de la Hot, Warm ou Cold Memory, et à construire les mécanismes de chargement dynamique du contexte selon la tâche en cours.
• Mise en place du CDLC : outiller les équipes pour versionner, tester et distribuer leur contexte comme une dépendance logicielle à part entière, avec les pipelines CI/CD correspondants.
• Formation au Compound Engineering : accompagner le changement culturel qui consiste à reclassifier la documentation d'une corvée à un investissement à retour immédiat.

La question que posent souvent nos clients n'est pas « notre LLM est-il assez bon ? » — les modèles disponibles aujourd'hui sont remarquables. La vraie question est : avons-nous construit l'infrastructure qui leur permet d'être vraiment utiles dans notre contexte spécifique ?

Ce que vous pouvez faire dès maintenant

Le Context Engineering peut sembler intimidant vu de loin, mais son adoption peut être progressive. Voici quelques premiers pas concrets :

• Commencez par votre Hot Memory. Réservez une heure en équipe pour lister les dix conventions les plus importantes de votre projet. Formalisez-les dans un fichier dédié, versionné avec votre code. C'est votre première constitution.
• Traitez le prochain échec de votre agent comme un bug de documentation. Quand l'agent produit une réponse incorrecte ou inadaptée, demandez-vous : quelle information manquait dans le contexte ? Écrivez-la. Vous venez de faire du TDD contextuel.
• Instaurez l'étape Compound. À la fin de chaque session de travail significative avec un agent, prenez cinq minutes pour capitaliser : qu'avez-vous corrigé ? Quelle décision avez-vous prise ? Où le contexte était-il incomplet ? Ces cinq minutes sont votre investissement compound.
• Versionez votre contexte. Même un simple dossier context/ dans votre repository, avec des fichiers Markdown bien nommés et des commits clairs, est infiniment plus maintenable que des prompts copiés-collés dans des fichiers texte épars.

Ces pratiques ne requièrent pas d'outillage sophistiqué pour démarrer. Elles requièrent surtout un changement de regard : voir le contexte non plus comme un paramètre technique secondaire, mais comme le principal levier de qualité et de vélocité de vos systèmes IA.

L'ère du prompt engineering touchait à ses limites naturelles. L'ère du context engineering commence à peine. Les équipes qui investissent maintenant dans cette infrastructure seront celles qui tireront le plus de valeur des agents IA dans les années qui viennent — non pas parce qu'elles auront accès à de meilleurs modèles, mais parce qu'elles sauront les nourrir.