L'architecture de contexte : pourquoi un agent sait quoi faire — ou ne sait pas

Le même modèle, deux résultats opposés

Prenez deux entreprises. Même secteur, même taille, même modèle de langage déployé. L'une obtient un agent qui traite 80% des demandes clients sans intervention humaine. L'autre accumule les erreurs, les réponses hors sujet, les escalades inutiles.

La différence ne se situe pas dans le choix du modèle. Elle se situe dans ce qu'on lui donne à comprendre avant qu'il agisse.

Un agent IA ne "sait" rien par lui-même. Il reconstruit une compréhension à chaque sollicitation, à partir des informations qu'on lui transmet. Cette transmission, c'est ce qu'on appelle l'architecture de contexte. Et c'est elle qui détermine si votre agent prend la bonne décision — ou passe complètement à côté.

Les quatre couches du contexte

Pour qu'un agent agisse de manière pertinente, il doit disposer de quatre types d'informations, chacune jouant un rôle distinct :

• Les instructions système : le cadre permanent qui définit le rôle de l'agent, ses limites, son ton, ses règles de fonctionnement. C'est la constitution de l'agent — ce qui ne change pas d'une requête à l'autre.
• La mémoire court terme : l'historique de la conversation en cours. Sans elle, l'agent oublie ce qu'il vient de dire ou de faire. Chaque échange repart de zéro.
• Le Cortex d'entreprise : les connaissances métier, les procédures, les données de référence. C'est ce qui permet à l'agent de répondre selon votre réalité, pas selon une moyenne statistique du web.
• L'état courant du processus : où en est-on dans le workflow ? Quelle étape vient d'être franchie ? Quelles actions restent à accomplir ? Sans cette information, l'agent ne peut pas s'inscrire dans une séquence cohérente.

Chaque couche manquante ou mal configurée crée un angle mort. Et les angles morts produisent des erreurs.

Pourquoi la plupart des déploiements échouent sur le contexte

Le réflexe naturel consiste à se concentrer sur le modèle. On compare les benchmarks, on teste les capacités de raisonnement, on évalue les temps de réponse. Tout cela compte, mais c'est secondaire.

Ce qui fait échouer un déploiement, c'est rarement le modèle. C'est l'absence de structure autour de lui.

Quelques situations classiques :

• Instructions système trop vagues : l'agent improvise, interprète, dévie. Il n'a pas de cadre clair pour arbitrer entre deux options.
• Pas de mémoire de conversation : le client doit répéter trois fois son problème. L'agent pose des questions auxquelles il a déjà eu la réponse.
• Cortex absent ou obsolète : l'agent répond avec des informations génériques, parfois fausses dans votre contexte. Il ne connaît pas vos produits, vos tarifs, vos exceptions.
• État du processus non transmis : l'agent propose une action déjà effectuée, ou saute une étape obligatoire. Il ne sait pas où il en est.

Ces problèmes ne se résolvent pas en changeant de modèle. Ils se résolvent en structurant ce que le modèle reçoit.

Un exemple concret : le traitement d'une réclamation

Un distributeur industriel déploie un agent pour traiter les réclamations clients. Le modèle utilisé est performant, les premiers tests en environnement contrôlé sont concluants.

En production, les problèmes apparaissent rapidement. L'agent propose des remboursements sur des produits hors garantie. Il demande des informations que le client a déjà fournies. Il escalade des cas simples et traite seul des cas complexes.

L'analyse révèle quatre failles de contexte :

• Les règles de garantie ne sont pas dans le Cortex — l'agent applique une logique générique.
• L'historique client n'est pas injecté — chaque échange repart de zéro.
• Les instructions système ne précisent pas les seuils d'escalade.
• L'état du dossier (ouvert, en attente de pièces, validé) n'est pas transmis.

Une fois ces éléments structurés et injectés correctement, le taux de traitement automatique passe de 30% à 75%. Le modèle n'a pas changé. L'architecture de contexte, si.

Structurer le contexte : une discipline, pas une option

On ne peut pas automatiser le chaos. Un agent performant suppose une organisation requêtable — des données accessibles, des processus formalisés, des règles explicites.

Structurer le contexte implique plusieurs chantiers :

• Documenter les instructions système : pas un prompt bricolé, mais un document de référence qui évolue avec l'usage.
• Concevoir la mémoire : définir ce qui doit être retenu, sur quelle durée, avec quelle granularité.
• Construire le Cortex : identifier les sources de vérité, les maintenir à jour, les rendre interrogeables.
• Modéliser les processus : savoir à chaque instant où en est l'agent dans le workflow, et lui transmettre cette information.

Ce travail n'est pas technique au sens où il ne concerne pas que l'IT. Il engage les métiers, les opérations, la direction. C'est un travail d'organisation avant d'être un travail d'intégration.

Ce que cela change pour vos décisions

Quand vous évaluez un projet d'agent IA, la question n'est pas seulement "quel modèle choisir ?". C'est aussi :

• Quelles instructions système allons-nous définir ?
• Comment la mémoire de conversation sera-t-elle gérée ?
• Quelles données métier devront être accessibles, et sous quelle forme ?
• Comment l'état des processus sera-t-il transmis à l'agent ?

Si ces questions n'ont pas de réponse claire avant le déploiement, le projet sera fragile. Pas parce que la technologie est immature — mais parce que le contexte n'aura pas été pensé.

La qualité d'un agent se joue dans ce qu'on lui donne à comprendre. Le reste, c'est de l'exécution.