Configuration, État, Stockage, Prompt : Ingénierie du contexte dans LangGraph

Les développeurs qui utilisent LangChain ou LangGraph se heurtent tôt ou tard à des termes tels que Config, State, Store et Context Engineering. Il est facile de penser que « context » ne désigne que la dernière chaîne de prompt. Cette supposition s’effondre dès que les applications se développent.

La qualité d’un produit basé sur l’IA dépend moins uniquement de la marque du modèle que de la manière dont les informations sont sélectionnées, stockées et présentées au modèle. LangChain et LangGraph fournissent le vocabulaire et les mécanismes nécessaires à cette tâche — et ces concepts s’adaptent parfaitement à l’ingénierie logicielle classique.

Quel est réellement le contexte d’un LLM

On entend souvent parler de « context » et on imagine une seule phrase de l’utilisateur, comme par exemple « Expliquez les React Hooks ». Les applications réelles ont également besoin de l’historique des conversations, des préférences, des documents récupérés, des résultats des outils, des métadonnées d’authentification et des paramètres de fonctionnement. Tous ces éléments ensemble forment le contexte qui permet d’obtenir des réponses précises.

                    LLM
                     ▲
                     │
        ┌────────────┴────────────┐
        │                         │
   User Message             Additional Context
                                │
         ┌──────────────┬──────────────┬──────────────┐
         │              │              │
   Conversation     User Info     Retrieved Docs
      History

L’instruction n’est qu’une couche de cette pile.

Pourquoi la gestion est importante

Une question de support comme « Où se trouve la dernière commande ? » nécessite l’identité de l’utilisateur, les échanges précédents, les commandes récentes, les politiques en vigueur ainsi que des informations sur l’expédition. Intégrer tout cela dans une seule instruction massive à chaque fois génère des chaînes de texte énormes, coûteuses et difficiles à déboguer. L’ingénierie de contexte est la discipline qui consiste à déterminer ce que le modèle voit, d’où proviennent ces informations, quand elles sont disponibles et pendant combien de temps elles restent actives — y compris les secrets que le modèle ne doit en aucun cas voir.

Quatre types de contexte

1. Config (contexte d’exécution immuable)

Le config correspond aux métadonnées de la demande qui ne changent pas pendant le fonctionnement de l’agent : identifiant de l’utilisateur, abonné, forfait, région linguistique, fuseau horaire, indicateurs de fonctionnalité, authentification. Transmettez-le via l’objet configurable réservé par LangChain :

await agent.invoke(
  {
    messages: [
      {
        role: "user",
        content: "Show my recent orders."
      }
    ]
  },
  {
    configurable: {
      userId: "123",
      tenantId: "companyA",
      plan: "premium"
    }
  }
);

Les outils peuvent le lire en toute sécurité :

const getOrders = tool(async (_, config) => {
    const userId = config.configurable.userId;

    return database.orders.find({
        userId
    });
});

L’utilisateur ne sait jamais entrer d’ID ; l’outil le récupère à partir de la configuration en temps de exécution.

2. État (mémoire de travail)

L’état correspond à la RAM pendant l’exécution : messages, résultats de l’outil, documents récupérés, notes intermédiaires, résumés. Contrairement à la configuration, l’état évolue au fur et à mesure que les nœuds s’exécutent.

User asks question

↓Search tool runs↓Results added to State↓Model reasons↓Final answer generated

Les nœuds du graphe lisent et écrivent dans l’état, ce qui permet une collaboration sans besoin de variables globales.

3. Stockage (mémoire à long terme)

L’état disparaît lorsque l’exécution se termine. Le stockage, quant à lui, persiste entre les conversations : préférences, profils, interactions antérieures, pile de bibliothèques préférée, ton d’écriture. Exemple : un utilisateur mentionne qu’il crée des applications React ; une semaine plus tard, une question sur la gestion de l’état peut orienter les réponses vers des solutions compatibles avec React sans avoir à le demander à nouveau.

4. Contexte de la demande

Finalement, les éléments Config, State et Store se résument dans l’instruction finale du modèle : le dernier texte de l’utilisateur, l’historique édité, les documents récupérés, les résultats des outils, ainsi que les préférences mémorisées. N’oubliez pas : l’instruction est le produit de la gestion du contexte, et non l’intégralité de ce dernier.

Pourquoi ne pas mettre tout dans l’instruction ?

Les fenêtres de contexte sont limitées. Des tokens supplémentaires augmentent les coûts et la latence. Les jetons d’authentification et les clés API ne doivent en aucun cas être visibles par le modèle. Séparer la configuration en temps de exécution du texte destiné au modèle constitue donc une mesure de sécurité et d’économie, et non une simple question de rigueur.

Correspondance avec l’ingénierie logicielle

Config ressemble aux paramètres définis au niveau de la requête. State correspond à la mémoire de travail par requête. Store évoque une base de données ou un service de profils. L’assemblage des prompts rappelle la génération d’une vue à partir de multiples sources de données. Penser de cette manière aide les ingénieurs backend à adopter LangGraph sans le considérer comme une magie artificielle étrangère.

Habitudes pratiques

• Gardez Config petit et structuré.
• Rédigez des réducteurs/nœuds State faciles à tester.
• Considérez les écritures dans Store comme des événements produits intentionnellement, et non comme des effets secondaires accidentels.
• Journalisez quels niveaux ont contribué à chaque prompt afin de faciliter le débogage.
• Préférez la récupération d’informations et les recherches dans Store au copier-coller de toute l’historique.

Les équipes qui gèrent explicitement ces niveaux développent des assistants qui restent moins coûteux, plus sûrs et plus faciles à expliquer en cas de problème à 2 heures du matin.

Modèles récurrents dans les applications LangGraph

De nombreux graphes commencent par un nœud routeur qui examine les paramètres Config (locataire, région linguistique) et State (dernière intention de l’utilisateur) avant de choisir une branche. Les nœuds de récupération écrivent des documents dans State ; les nœuds de génération lisent State et ne touchent jamais aux secrets d’authentification bruts provenant de Config, sauf via des enveloppes d’outil. Les nœuds mémoire décident si une préférence vaut la peine d’être enregistrée dans Store après que l’étape ait réussi.

Incoming Request

Le fonctionnement de checkpointing (lorsqu’il est activé) permet de conserver State entre les étapes, afin que les agents à long terme puissent reprendre leur travail. Cela diffère de Store : les checkpoints assurent la durabilité au niveau d’une exécution spécifique, tandis que Store constitue la mémoire du produit entre différentes sessions.

↓Middleware↓Load Memory↓Update State↓Generate Prompt↓Call LLM

Lorsque vous déboguez une mauvaise réponse, demandez quel niveau a échoué. Identifiant utilisateur incorrect ? Config. Résultat d’outil perdu ? State. Préférence oubliée ? Store. Tokens trop volumineux ? Assemblage des prompts. Cette taxinomie transforme les rapports vagues du type « le modèle a halluciné » en tickets exploitables.

User
↓Agent.invoke()↓Config
(User ID, Tenant ID)↓Middleware↓State
(Chat History)↓Retriever
(Knowledge Base)↓Store
(Long-Term Memory)↓Prompt↓LLM↓Final Response

L’ingénierie de contexte concerne donc moins la création de prompts ingénieux que plutôt un flux de données discipliné — c’est la même compétence qui permet de maintenir en bon état les backends web ordinaires. LangChain et LangGraph se contentent de nommer ces conteneurs afin que les fonctionnalités d’IA cessent de mettre tout le contenu dans une seule chaîne de caractères.

Anti-modèles à éviter

En insérant l’intégralité du journal de conversation dans chaque prompt « au cas où », on gaspille de l’argent et on dilue l’attention nécessaire. Intégrer des clés API dans les prompts système « par commodité » crée un risque de fuite de données. Utiliser Store comme boîte à ordures pour des outils temporaires pollue les sessions futures. Permettre à chaque nœud de modifier la Config en cours d’exécution détruit la garantie d’immuabilité sur laquelle reposent ces outils.

Préférez des schémas explicites pour l’État, des chemins d’écriture audités pour le Stockage, ainsi que des modèles de prompts qui n’acceptent que les champs nécessaires. Mesurez l’utilisation des tokens par couche. Examinez les traces hebdomadairement jusqu’à ce que l’équipe puisse prédire quel nœud ajoute quels tokens.

Avec de telles habitudes, Config, State, Store et Prompt Context cessent d’être des termes à la mode pour devenir le système d’exploitation de l’agent — une infrastructure discrète qui permet au modèle de paraître plus intelligent qu’il ne le serait seul.