| |
Imagine que tu engages un consultant brillant. Il possède deux doctorats, parle sept langues et résout des problèmes dont tu n’avais même pas conscience. Tu t’assois avec lui dans une salle et tu lui dis : “J’ai besoin que tu refactorises l’authentification du projet.”
Le consultant te regarde, acquiesce, et demande : “Quel projet ?”
Tu ne lui as pas donné accès au code. Tu ne lui as pas expliqué l’architecture. Il ne sait pas si tu utilises des tokens JWT ou des cookies de session. Il ne sait pas quel langage vous utilisez, ni combien de microservices sont en jeu, ni pourquoi la dernière tentative de migration s’est soldée par un échec.
Ce consultant, c’est ton LLM. Et tu viens de commettre la même erreur que 90% des gens qui travaillent avec des agents d’IA : te concentrer sur le cerveau plutôt que sur ce que le cerveau voit.
Le prompt engineering est dépassé. Vive le context engineering.
Cela fait des mois que j’assiste à la même discussion sur tous les forums, dans chaque thread Twitter, et dans toutes les réunions d’équipe : “GPT-5 ou Claude Opus ?”, “Quel modèle est le meilleur pour coder ?”, “Lequel raisonne le mieux ?”
Et la réponse, après avoir fait les calculs, est toujours la même : ça n’a pas d’importance. Bon, pas exactement aucune importance. Mais la différence entre deux modèles haut de gamme est marginale par rapport à la différence entre leur fournir un bon contexte ou du contenu incohérent.
Un modèle moyen avec un contexte parfait surpassera un modèle haut de gamme avec un contexte médiocre. Toujours. Sans exception.
Ce concept porte un nom : context engineering. Et non, ce n’est pas la même chose que le prompt engineering.
Le prompt engineering, c’est rédiger un bon prompt. Choisir les bons mots, structurer la demande, ajouter des exemples. C’est important, mais ça reste une pièce parmi d’autres.
Le context engineering, c’est concevoir tout ce que le modèle voit : quelles informations entrent, dans quel ordre, ce qui est rejeté quand l’espace est limité, ce qui est compressé, ce qui reste impérativement intact. C’est l’architecture de l’information appliquée aux LLMs.
En termes simples : le prompt engineering revient à poser une bonne question. Le context engineering, c’est choisir quels livres l’élève a sur son bureau avant qu’il ne commence l’examen.
Les quatre phases de la mémoire : un cycle de vie invisible
OpenAI a récemment publié deux articles dans son Cookbook qui déconstruisent la gestion du contexte par les agents dotés d’une 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 modèle repose sur une logique local-first et state-based : un objet d’état structuré accompagne l’agent et est mis à jour à chaque étape.
flowchart TD
A["1. INJECTION\n(début de session)"] --> B["2. DISTILLATION\n(pendant la conversation)"]
B --> C["3. CONSOLIDATION\n(après la session)"]
C --> D["4. TRIMMING\n(préservation)"]
D -->|"Nouvelle session"| A
A1["Rendre l'état sous forme YAML\n+ mémoires globales (max 6)\n+ règles de priorité"] -.-> A
B1["save_memory_note()\nValider la durabilité\nExiger une action possible\nRejeter les DPI et les spéculations"] -.-> B
C1["Tâche asynchrone\nFusionner session → global\nDéduplication avec LLM\nFiltrer notes temporaires"] -.-> C
D1["TrimmingSession: derniers N\nRéinjecter notes coupées\ndans le prompt système"] -.-> 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 d’examen
Lorsqu’une session démarre, l’agent met en place son contexte initial. Ce n’est pas aléatoire. C’est une structure précise :
- YAML frontmatter contenant l’état de l’utilisateur (préférences, configuration).
- Liste des mémoires globales : maximum 6, ordonnées par récence. Pourquoi 6 ? Parce que dépasser ce nombre fait compétition entre les éléments et dilue leur pertinence. Moins, c’est mieux.
- Bloc
<memory_policy>avec des règles explicites de priorité.
Ces règles de priorité sont essentielles : Input actuel > Mémoire de session > Mémoire globale > Récence dans un même scope. Si l’utilisateur dit “j’utilise Vim maintenant” mais que la mémoire globale mentionne “utilise VS Code”, c’est ce qu’il vient de dire qui prévaut. Cela semble évident, mais sans règle explicite, le modèle peut parfois s’accrocher à ce qu’il “se souvient” plutôt qu’à ce qu’on lui dit au moment présent.
Phase 2 : Distillation — capturer sans contaminer
Pendant la conversation, l’agent peut capturer des mémoires en temps réel via un outil tel que save_memory_note(). Mais tout n’est pas valable. Cet outil est doté de garde-fous stricts :
- Valider la durabilité : “l’utilisateur veut une pizza ce soir” n’est pas une mémoire durable. Cela est rejeté.
- Exiger une action possible : la mémoire doit être utile pour des sessions futures.
- Rejeter les données personnelles (DPI) : noms complets, adresses, numéros de carte. Exclus.
- Rejeter les spéculations : “je pense que l’utilisateur préfère Python” n’est pas un fait établi. C’est une hypothèse.
- Demander la confirmation de l’utilisateur : avant de sauvegarder, il faut vérifier.
Ce filtre est implacable, et pour de bonnes raisons. Une mémoire contaminée empoisonne toutes les sessions futures. Si ton carnet de notes contient une fausse information, chaque fois que tu le consultes, tu prends des décisions basées sur des données erronées.
Phase 3 : Consolidation — le nettoyage nocturne
Après chaque session, une tâche asynchrone rassemble les notes de session et les fusionne avec les mémoires globales. Ce n’est pas une simple addition. C’est une consolidation intelligente :
- Déduplication assistée par LLM : si deux notes expriment la même chose avec des mots différents, elles sont fusionnées.
- Filtrage des notes temporaires : tout ce qui contient “ce moment”, “aujourd’hui”, “juste maintenant” est rejeté.
- Résolution des conflits par récence : si une nouvelle note contredit une ancienne, elles sont fusionnées en priorisant la plus récente.
C’est comme la personne qui nettoie ton bureau à la fin de la journée. Elle ne jette pas tout — elle sauvegarde l’essentiel, fusionne les post-its similaires, et se débarrasse de ceux qui ne sont plus utiles.
Phase 4 : Trimming — couper sans perdre
Lorsque l’historique devient trop volumineux, il faut le réduire. TrimmingSession conserve uniquement les dernières N interventions. Mais — sois attentif — les notes mémorisées provenant des tours supprimés ne sont pas perdues. Elles sont réinjectées dans le prompt système du prochain tour.
C’est comme arracher les vieilles pages d’un cahier tout en transférant les annotations 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 d’une conversation dans une session), deux techniques majeures existent. Chacune avec ses avantages et ses pièges.
flowchart LR
subgraph Trimming["Trimming (Derniers N tours)"]
direction TB
T1["Historique complet\n(40 tours)"]
T2["Couper les tours 1-30"]
T3["Conserver les tours 31-40\n(intacts, non modifiés)"]
T1 --> T2 --> T3
end
subgraph Summarization["Summarization (Compression)"]
direction TB
S1["Historique complet\n(40 tours)"]
S2["LLM résume les tours 1-30\nen ~400 tokens"]
S3["Injecter un 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
Parcourt l’historique en arrière, conserve les derniers N tours complets, et tout le reste disparaît.
Avantage : fidélité totale au récent contexte. Ce qui reste n’a pas été altéré, résumé ou interprété. Ce sont les messages originaux tels quels.
Inconvénient : amnésie abrupte. Le tour N-1 existe avec tous les détails ; tout ce qui précède est effacé. Pas de dégradation progressive — un seul coupure nette entre “je me souviens de tout” et “je ne me souviens de rien”.
Comme la mémoire d’un poisson rouge avec un disque externe : les derniers secondes sont intactes, tout ce qui précède n’existe pas.
Summarization : la compression risquée
Dès que l’historique dépasse un seuil, un modèle compresse le plus ancien et ‘injecté’ à la session actuelle