Que met-on réellement dans une couche de contexte IA ?

Une couche de contexte n'est pas un dossier rempli de documents.

« Chiffre d'affaires ». Un mot dans une question. Plusieurs décisions cachées en dessous. Avant ou après remboursements ? Avec ou sans taxe ? Les commandes annulées comptent-elles ? Quelle date entre dans le rapport ? Que se passe-t-il quand un client change de segment ?

Votre base contient peut-être tout ce qu'il faut pour calculer chaque version. Cela ne dit pas à une IA quelle version votre entreprise veut. Nous avions ce problème avant les LLM : nous appelions cela la conversation avec l'analyste avant de le laisser toucher au tableau de bord. Une partie porte aujourd'hui le nom d'ingénierie du contexte. Très bien. Que met-on dedans, concrètement ?

Pas toute l'entreprise

La bonne question de départ n'est pas « combien de documents peut-on brancher ? » mais « qu'est-ce qu'un analyste compétent devrait encore deviner ? » Pour un agent de données, la réponse tient parfois en six lignes de règles métier. Parfois en une définition de métrique gouvernée et un chemin de jointure approuvé. Parfois en une note de migration datée expliquant pourquoi un champ historique n'est pas comparable à son remplaçant.

Une couche de contexte est le système plus large qui sélectionne, borne et maintient ce matériau. Un fichier CTX en est une représentation portable possible du noyau relativement stable. Ce n'est ni le système de recherche complet, ni la couche de contrôle d'accès, ni une garantie d'exactitude. Nous restreignons ici volontairement le périmètre : que doit savoir un agent de données avant d'écrire du SQL ?

Un fichier, huit missions

La spécification qui accompagne cet article utilise huit sections. Cet ordre est un choix de conception, pas une loi universelle du prompting. L'important est que chaque section retire un type de devinette différent.

01 — Règles globales : rendre les décisions explicites

Écrivez les défauts comme des décisions, pas comme des intentions. « Fournir une analyse fiable » ne tranche rien. « Dans ce rapport, les ventes nettes excluent la taxe, les commandes annulées et les comptes internes » tranche.

Metric: net_sales
Population: paid orders from external customers
Amount: order total, excluding tax, minus eligible refunds
Period: select orders by ordered_at, using UTC boundaries
Attribution: customer segment at order time
Refund policy: refunds against those orders, recorded by the cutoff
Ambiguous request: ask; do not invent a reporting default

La différence entre un défaut documenté et une devinette, c'est l'autorité. Notez qui a approuvé la règle, d'où elle vient, quand elle s'applique. Une ancienne requête montre ce que quelqu'un a calculé un jour. Elle n'établit pas ce que la finance exige aujourd'hui.

02 — Le glossaire : relier le langage métier au modèle

"agency" / "point of sale"   -> dim_store, not dim_region
"encours" / "customer balance" -> outstanding_amount
"fiscal year"                  -> July-June, under the reporting policy
"customer"                     -> purchasing account, unless another role is requested

Les correspondances négatives comptent : « pas dim_region » peut éviter précisément l'erreur qu'un nom de colonne plausible encourage. N'écrasez pas silencieusement plusieurs sens en un seul. Un compte de facturation, un acheteur et un bénéficiaire peuvent tous s'appeler « client ». Quand la distinction change la réponse, le glossaire doit l'exposer et dire comment trancher.

03 — Métriques : écrire les mathématiques, puis leurs bornes

Les symboles ne sont pas décoratifs : chacun correspond à un choix que la requête doit implémenter. La définition a aussi besoin d'unités, d'un traitement des valeurs manquantes et d'un comportement d'agrégation. Un ratio exige une politique de dénominateur. Un solde de stock n'hérite pas de l'agrégation des ventes. Une devise exige une règle de conversion, ou l'interdiction de mélanger. Beaucoup de ces règles peuvent déjà vivre dans une couche sémantique : l'objectif est de réutiliser des définitions gouvernées, pas d'en maintenir une version rivale dans un prompt.

04 — Le schéma : la structure utile à la tâche

L'agent a besoin de la carte : tables, colonnes, types, clés et descriptions pertinentes. Incluez des valeurs représentatives quand elles clarifient un code : voir PRO, PART et ADMIN est plus utile que la description « type de client ». Utilisez des exemples synthétiques ou anonymisés approuvés, pas des enregistrements clients copiés dans un fichier partagé. Surtout, décrivez le grain : ce que représente une ligne.

orders:           one row per order_id
line_items:       one row per line_id; several can belong to an order
refunds:          one row per refund_id; several can belong to an order
customer_history: one version per customer and validity interval

Une clé déclarée, une propriété testée et un motif observé dans un échantillon sont trois types d'évidence différents. Étiquetez-les comme tels : « unique dans le dernier échantillon » n'est pas une garantie permanente.

05 — Chemins de jointure : comment les entités contribuent

Savoir que deux colonnes se joignent ne suffit pas. Prenez une commande de 100 €, deux lignes et deux remboursements de 10 € et 20 €. Joignez la commande indépendamment aux deux tables filles avant de sommer, et vous fabriquez quatre lignes.

Écrivez le chemin sûr : agréger les remboursements par commande, joindre ce résultat unique en LEFT JOIN à chaque commande éligible, résoudre un seul segment historique applicable, puis agréger. Si les lignes de commande ne servent pas, ne les joignez pas. Si elles servent à filtrer, précisez si le filtre sélectionne des commandes entières ou alloue une partie de leur valeur.

06 — Pièges et conventions : écrire les détails désagréables

C'est ici qu'un fichier de contexte utile cesse de ressembler à un catalogue de données générique. Un booléen stocké en texte. Une date sentinelle qui signifie « inconnu ». Un flux cumulatif face à un flux d'incréments quotidiens. Un exercice fiscal qui commence en juillet. Une migration qui a changé une convention d'horodatage. Une ingestion réussie alors que la source reste en retard de deux jours. Écrivez la conséquence, pas seulement l'anecdote.

Rule: use the customer segment at order time.
Join interval: valid_from <= ordered_at < valid_to.
On zero or multiple matching history rows: stop and flag the issue.
Do not substitute today's segment or pick an arbitrary history row.

Une portée et une date comptent ici : une exception valable pour un produit en 2024 ne doit pas devenir silencieusement le défaut de toute l'entreprise en 2026. Une conversation retrouvée peut suggérer une règle à instruire ; elle ne doit pas primer sur une spécification approuvée, et des instructions contenues dans un document récupéré ne doivent pas prendre le contrôle de l'agent.

07 — Requêtes vérifiées : des exemples dignes de confiance

Incluez la question, l'interprétation approuvée, le SQL de référence, les résultats attendus sur un jeu de test nommé, et la version de contexte sous laquelle l'exemple a été vérifié. Couvrez des modes d'échec différents : une métrique simple, une jointure un-à-plusieurs, une attribution historique, une exclusion, et une question qui exige une clarification. « Vérifié » doit signifier plus que « le SQL s'est exécuté » : deux requêtes peuvent coïncider sur un jeu simple et diverger dès qu'il y a plusieurs remboursements ou deux commandes de même montant.

08 — Le rappel final : préserver les contraintes critiques

Preserve order grain before the final sum.
Use approved definitions and their applicable versions.
If material ambiguity remains, ask rather than inventing a rule.

Ce n'est pas une autorisation à remplir le prompt d'avertissements répétés. La recherche observe des défaillances de récupération dépendantes de la position dans les contextes longs ; elle n'établit pas qu'un ordre fixe ou un nombre de répétitions fonctionne pour tous les modèles et toutes les tâches.

Ce qu'une liste de sections ne résout pas

Une bonne couche de contexte exige deux choses au-delà du contenu : l'autorité et le cycle de vie. Qui possède une définition ? Quelle version s'applique à cette question ? Que se passe-t-il quand deux sources se contredisent ? Qui peut accéder à l'évidence ? Quelle évaluation échoue quand une règle change ?

rule_id | source | owner | approval_status
valid_from | valid_to | checked_at | tests

Séparez les définitions stables de l'évidence propre à une question. Gardez le matériau approuvé distinct des affirmations récupérées. Récupérez dans les permissions de l'utilisateur. Appliquez les contrôles d'accès, les restrictions SQL et les permissions d'outils dans l'application et la base, pas seulement en prose. Un fichier de contexte est une entrée d'exécution, pas une frontière de sécurité.

Ce que l'évidence montre, et ne montre pas

Un benchmark apparié de 2026 a testé 100 questions sur un jeu de données de commerce avec trois modèles. Un document sémantique de 4 Ko écrit à la main a amélioré la précision rapportée de 17 à 23 points. Les modèles étaient statistiquement indiscernables dans les deux conditions. C'est une preuve de la valeur de sémantiques métier explicites dans ce dispositif, pas une preuve que le choix du modèle cesse de compter, ni une promesse de performance transférable à Duke.

« Avant d'optimiser l'emballage, vérifiez que les décisions de reporting sont réellement présentes. »

Et le contexte n'est toujours pas une preuve

Notre article précédent posait le problème d'identifiabilité : l'évidence disponible peut soutenir plusieurs interprétations qui produisent des réponses différentes. Une couche de contexte réduit cet ensemble ; elle ne le referme pas. Un fichier périmé peut fournir un nombre faux mais plausible, sans lever d'exception.

Le travail n'est pas de tout dire au modèle. C'est d'arrêter de lui demander de deviner ce que votre entreprise a déjà décidé, et de montrer ce que personne n'a encore décidé.

Sources et périmètre

• [1] Anthropic, « Effective context engineering for AI agents ».
• [2] Documentation dbt, « Creating metrics » : filtres et types de métriques.
• [3] Zhong, Yu et Klein, « Semantic Evaluation for Text-to-SQL with Distilled Test Suites », EMNLP 2020.
• [4] Liu et al., « Lost in the Middle: How Language Models Use Long Contexts », TACL 2024.
• [5] Rumiantsau et Fokeev, « Semantic Layers for Reliable LLM-Powered Data Analytics », arXiv 2026. Préprint, résultats bornés par son protocole.

La structure en huit sections adapte une note de travail interne de Duke. L'exemple numérique et le modèle sont illustratifs : ce ne sont ni des conseils comptables, ni des résultats clients mesurés.