Imaginez que vous engagez un consultant brillant. Il a deux doctorats, parle sept langues, et résout des problèmes dont vous ignoriez même l’existence. Vous l’installez dans une salle et lui dites : “j’ai besoin que vous refactorisiez l’authentification du projet”.

Le consultant vous regarde, acquiesce, et demande : “Quel projet ?”

Vous ne lui avez pas donné accès au code. Vous ne lui avez pas expliqué l’architecture. Il ne sait pas si vous utilisez des tokens JWT ou des cookies de session. Il ne connaît ni le langage que vous utilisez, ni le nombre de microservices, ni pourquoi la dernière tentative de migration s’est soldée par un désastre.

Ce consultant, c’est votre LLM. Et vous venez de commettre l’erreur que font 90% des gens qui travaillent avec des agents IA : vous préoccuper du cerveau au lieu de vous préoccuper de ce que le cerveau voit.

Le prompt engineering est mort. Vive le context engineering.

Depuis des mois, je vois la même conversation dans chaque forum, chaque fil Twitter, chaque réunion d’équipe : “GPT-5 ou Claude Opus ?”, “quel modèle est le meilleur pour le code ?”, “lequel raisonne le mieux ?”.

Et la réponse, à chaque fois que je fais les comptes, est la même : peu importe. Enfin, pas exactement. Mais la différence entre un modèle top et un autre modèle top est marginale comparée à la différence entre lui donner un bon contexte ou lui donner n’importe quoi.

Un modèle moyen avec un contexte parfait bat un modèle top avec un contexte défaillant. Toujours. Sans exception.

Cela porte un nom : context engineering. Et non, ce n’est pas la même chose que le prompt engineering.

Le prompt engineering consiste à écrire un bon prompt. C’est choisir les bons mots, structurer la demande, ajouter des exemples. C’est important, mais ce n’est qu’une pièce du puzzle.

Le context engineering consiste à concevoir tout ce que le modèle voit : quelle information entre, dans quel ordre, ce qui est écarté quand ça ne rentre pas, ce qui est compressé, ce qui est préservé coûte que coûte. C’est de l’architecture de l’information pour les LLM.

Autrement dit : le prompt engineering consiste à rédiger une bonne question. Le context engineering consiste à décider quels livres l’étudiant a sur son pupitre avant de commencer l’examen.

Les quatre phases de la mémoire : un cycle de vie invisible

OpenAI a publié récemment deux articles Cookbook qui décortiquent le fonctionnement de la gestion de contexte dans les agents avec mémoire à long terme. Ce n’est pas du RAG. Ce n’est pas une base de données vectorielle. C’est un système d’états qui fonctionne comme un carnet de terrain avec des règles strictes.

Le pattern est local-first et state-based : un objet d’état structuré qui voyage avec l’agent et se met à jour à chaque phase.

flowchart TD
    A["1. INJECTION\n(début de session)"] --> B["2. DISTILLATION\n(pendant la conversation)"]
    B --> C["3. CONSOLIDATION\n(post-session)"]
    C --> D["4. TRIMMING\n(préservation)"]
    D -->|"Nouvelle session"| A

    A1["Rend l'état en YAML\n+ mémoires globales (max 6)\n+ règles de précédence"] -.-> A
    B1["save_memory_note()\nValide la durabilité\nExige l'actionnabilité\nRejette PII et spéculation"] -.-> B
    C1["Job asynchrone\nFusionne session → global\nDéduplication avec LLM\nFiltre les notes éphémères"] -.-> C
    D1["TrimmingSession : dernières N\nRéinjecte les notes coupées\ndans le system prompt"] -.-> D

    style A fill:#2d3748,stroke:#4a9eed,color:#fff
    style B fill:#2d3748,stroke:#ed9a4a,color:#fff
    style C fill:#2d3748,stroke:#9a4eed,color:#fff
    style D fill:#2d3748,stroke:#4aed5c,color:#fff

Phase 1 : Injection — le pupitre de l’examen

Quand une session démarre, l’agent monte son contexte initial. Ce n’est pas aléatoire. C’est une structure concrète :

  • YAML frontmatter avec l’état de l’utilisateur (préférences, configuration).
  • Liste de mémoires globales : maximum 6, ordonnées par récence. Pourquoi 6 ? Parce que plus de 6 se font concurrence pour l’attention du modèle et commencent à se diluer. Moins, c’est plus.
  • Bloc <memory_policy> avec des règles de précédence explicites.

Les règles de précédence sont cruciales : Input actuel > Mémoire de session > Mémoire globale > Récence dans le même scope. Si l’utilisateur vous dit “maintenant j’utilise Vim” mais que votre mémoire globale dit “utilise VS Code”, c’est ce qu’il vient de dire qui gagne. Cela semble évident, mais sans règles explicites, le modèle s’accroche parfois à ce qu’il “se souvient” plutôt qu’à ce que vous êtes en train de lui dire.

Phase 2 : Distillation — capturer sans contaminer

Pendant la conversation, l’agent peut capturer des mémoires en temps réel avec un outil du type save_memory_note(). Mais tout ne passe pas. L’outil a des guardrails stricts :

  • Valide la durabilité : “l’utilisateur veut une pizza ce soir” n’est pas une mémoire durable. C’est rejeté.
  • Exige l’actionnabilité : la mémoire doit servir à quelque chose dans les sessions futures.
  • Rejette les PII : noms complets, adresses, numéros de carte. Dehors.
  • Rejette la spéculation : “je pense que l’utilisateur préfère Python” n’est pas un fait. C’est une supposition.
  • Requiert la confirmation de l’utilisateur : avant de sauvegarder, demande.

Ce filtre est brutal, et pour cause. Une mémoire contaminée empoisonne toutes les sessions futures. C’est comme si votre carnet de terrain avait une note fausse : chaque fois que vous le consultez, vous prenez des décisions basées sur une information incorrecte.

Phase 3 : Consolidation — le nettoyage nocturne

Après chaque session, un job asynchrone récupère les notes de session et les fusionne avec la mémoire globale. Ce n’est pas un append. C’est une consolidation intelligente :

  • Déduplication assistée par LLM : si deux notes disent la même chose avec des mots différents, elles fusionnent.
  • Filtrage des notes éphémères : tout ce qui contient “cette fois”, “aujourd’hui”, “maintenant” est écarté.
  • Résolution des conflits par récence : si une note nouvelle contredit une ancienne, c’est la nouvelle qui gagne.

Pensez à cela comme à la personne qui range votre bureau à la fin de la journée. Elle ne jette pas tout — elle garde l’important, consolide les post-its qui disent la même chose, et jette ceux qui ne s’appliquent plus.

Phase 4 : Trimming — couper sans perdre

Quand l’historique devient trop volumineux, il faut élaguer. TrimmingSession ne conserve que les dernières N interventions. Mais — et c’est important — les notes de mémoire qui vivaient dans les tours coupés ne se perdent pas. Elles sont réinjectées dans le system prompt du tour suivant.

C’est comme arracher les vieilles feuilles d’un carnet mais recopier les notes importantes sur la première page avant de les jeter.

Trimming vs Summarization : deux philosophies, un dilemme

Pour gérer la mémoire à court terme (l’historique de conversation dans une session), il existe deux techniques fondamentales. Chacune avec ses avantages et ses pièges.

flowchart LR
    subgraph Trimming["Trimming (Last-N Turns)"]
        direction TB
        T1["Historique complet\n(40 tours)"]
        T2["Couper tours 1-30"]
        T3["Conserver tours 31-40\n(intacts, sans altération)"]
        T1 --> T2 --> T3
    end

    subgraph Summarization["Summarization (Compression)"]
        direction TB
        S1["Historique complet\n(40 tours)"]
        S2["LLM résume tours 1-30\nen ~400 tokens"]
        S3["Injecter résumé synthétique\n+ tours 31-40"]
        S1 --> S2 --> S3
    end

    style Trimming fill:#1a2332,stroke:#4a9eed,color:#fff
    style Summarization fill:#2a1a32,stroke:#9a4eed,color:#fff

Trimming : la guillotine déterministe

Scanne l’historique vers l’arrière, conserve les dernières N interventions complètes, et tout ce qui précède disparaît.

Avantage : fidélité totale du contexte récent. Ce qui reste n’a été ni altéré, ni résumé, ni interprété. Ce sont les messages originaux, tels quels.

Inconvénient : amnésie brutale. Le tour N-1 existe avec tous les détails. Le tour N-2 n’existe pas du tout. Il n’y a pas de dégradation graduelle — il y a une coupure binaire entre “je me souviens de tout” et “je ne me souviens de rien”.

C’est comme la mémoire d’un poisson rouge avec un disque dur externe : les 10 dernières secondes sont parfaites, tout ce qui précède n’existe simplement pas.

Summarization : la compression avec risque

Quand l’historique dépasse un seuil, un LLM compresse l’ancien et l’injecte comme une paire synthétique user/assistant au début de la conversation. Le prompt de résumé a des principes stricts :

  • Préserver les milestones (décisions prises, accords).
  • Maintenir l’ordre temporel.
  • Détecter les contradictions et les marquer.
  • Faits incertains marqués comme “UNVERIFIED”.
  • Maximum 400 tokens par résumé.

Avantage : vous conservez l’essence de toute la conversation. Pas d’amnésie brutale. Le modèle “sait” qu’il y a 30 tours vous avez décidé d’utiliser PostgreSQL au lieu de MongoDB, même s’il n’a plus les messages originaux.

Inconvénient : compounding errors. Si un fait erroné entre dans le résumé, il empoisonne tout le comportement futur. Et comme le résumé est généré par un LLM, il n’est pas immunisé contre les hallucinations. Un modèle qui résume mal génère un résumé incorrect que le tour suivant traite comme vérité absolue.

C’est culotté : vous utilisez un LLM pour résumer l’historique d’un autre LLM, et si le premier se trompe, le second hérite de l’erreur sans le savoir.

Pour distinguer le réel du synthétique, chaque enregistrement porte des métadonnées d’observabilité : {"synthetic": bool, "kind": "...", "summary_for_turns": "..."}. Ainsi vous pouvez au moins auditer quelle partie du contexte est originale et quelle partie est un résumé.

Vous le faites déjà (sans le savoir)

Si vous utilisez Claude Code, vous avez déjà un système de context engineering qui fonctionne. Seulement vous ne l’avez pas conçu — c’est Anthropic qui l’a fait. Mais si vous regardez attentivement, les pièces s’imbriquent :

Votre CLAUDE.md global + CLAUDE.md par projet + fichiers SKILL.md = injection manuelle. Vous décidez quel contexte voit le modèle au démarrage de chaque session. C’est vous qui choisissez quels “livres vont sur le pupitre”.

Le répertoire ~/.claude/projects/*/memory/ où Claude Code sauvegarde les notes entre sessions = implémentation directe du pattern injection + distillation. Le modèle capture des faits pendant la session et les récupère lors de la suivante.

La compression automatique de contexte que Claude Code fait quand la conversation s’allonge = trimming + summarization. Vous ne le voyez pas parce que c’est transparent, mais chaque fois que votre session dépasse un certain seuil, une partie de la conversation est compressée.

Les skills (/blog, /commit, etc.) = injection de contexte spécialisé à la demande. Au lieu de charger tout le contexte possible au début, vous ne chargez que celui dont vous avez besoin quand vous en avez besoin.

Et voici ce qui me semble le plus intéressant : la qualité de vos CLAUDE.md détermine la qualité de votre agent bien plus que le modèle que vous utilisez. Un CLAUDE.md bien structuré — avec des conventions claires, des chemins corrects, des décisions d’architecture documentées — transforme n’importe quel modèle décent en assistant utile. Un CLAUDE.md vide ou désordonné transforme le meilleur modèle du monde en consultant brillant enfermé dans une pièce sans lumière.

Prompt debt : la dette technique invisible

Connaissez-vous le concept de technical debt ? Du code qui fonctionne mais qui accumule des problèmes futurs. Des raccourcis que vous payez plus tard.

Le context engineering a sa propre dette : prompt debt. Ce sont tous ces fichiers de configuration, instructions, mémoires et notes qui s’accumulent et que personne ne maintient.

Un CLAUDE.md avec des instructions contradictoires. Des mémoires globales qui ne s’appliquent plus. Des skills avec des chemins qui ont changé il y a trois mois. Des règles de précédence implicites que personne n’a documentées.

Chaque élément de contexte obsolète est du bruit. Et le bruit concurrence le signal pour l’attention du modèle. Plus de bruit → de moins bons résultats. Pas parce que le modèle est moins bon, mais parce que vous lui donnez des déchets mélangés à de l’information utile en espérant qu’il sache les distinguer.

L’hygiène de votre couche de context engineering est aussi importante que l’hygiène de votre code. Peut-être plus, parce qu’un bug dans le code échoue bruyamment. Un bug dans le contexte échoue silencieusement — le modèle prend simplement de moins bonnes décisions sans que personne s’en aperçoive.

L’actionnable : ce que vous pouvez faire aujourd’hui

Toute cette théorie c’est bien beau, mais qu’en faites-vous un mardi matin ?

1. Auditez votre CLAUDE.md (ou équivalent). A-t-il des instructions contradictoires ? Des chemins qui n’existent plus ? Des règles qui ne s’appliquent plus ? Nettoyez. Chaque ligne qui traîne est du bruit.

2. Ordonnez votre contexte par stabilité. Ce qui ne change jamais va en premier (conventions, stack). Ce qui change souvent va à la fin (tâche actuelle). Cela maximise les cache hits et réduit les coûts. Ce n’est pas cosmétique — c’est économique.

3. Établissez des règles de précédence explicites. Si l’utilisateur dit une chose et la mémoire dit autre chose, qui gagne ? Si vous ne le définissez pas, le modèle décide à votre place. Et vous prenez des risques.

4. Filtrez agressivement. Tout ne mérite pas d’être retenu. Une décision d’architecture, oui. Que l’utilisateur préfère les tabs aux espaces, peut-être. Qu’il pleuvait quand la session a commencé, non.

5. Distinguez contexte réel et synthétique. Si vous utilisez la summarization, marquez les résumés comme tels. Quand quelque chose échoue, vous devez savoir si le modèle travaillait avec des données réelles ou avec un résumé potentiellement incorrect.

6. Traitez la maintenance du contexte comme de la dette technique. Mettez-la dans le backlog. Révisez-la périodiquement. Ce n’est pas glamour, mais c’est ce qui sépare un agent qui fonctionne d’un agent qui hallucine.

La compétence que personne ne met sur son CV

Le context engineering est la compétence invisible. Elle ne figure pas dans les offres d’emploi. Elle n’a pas de certification. Il n’y a pas de cours de 40 heures sur Udemy avec un diplôme à la fin.

Mais c’est ce qui sépare les gens qui “utilisent ChatGPT” des gens qui construisent des agents qui fonctionnent. C’est la différence entre poser une question à un LLM et concevoir un système où le LLM a tout ce qu’il faut pour vous donner la bonne réponse.

La prochaine fois que votre agent fait quelque chose de stupide, avant d’accuser le modèle, regardez quel contexte vous lui donniez. Il y a de fortes chances que le problème ne soit pas le cerveau — mais ce que le cerveau était en train de voir.

Et ça, contrairement au modèle, c’est vous qui le contrôlez.

Sources : Les deux articles d’OpenAI Cookbook sur Context Engineering for Long-Term Personalization et Short-Term Memory Management with Sessions. Si le fonctionnement de la boucle interne d’un coding agent vous intéresse, lisez Votre AI coding agent est une boucle while avec des délires de grandeur. Et si vous voulez comprendre pourquoi l’ordre du prompt affecte le coût, Pourquoi 99% de ce que vous envoyez à Claude est déjà en cache.

Cet article a été rédigé en espagnol et traduit avec l’aide de l’IA.