Context engineering (ingénierie de contexte)

Comment ça marche

Un modèle ne sait rien de votre situation. Tout ce qu’il sait au moment de répondre, c’est ce qui est dans son contexte : votre demande, les documents que vous avez fournis, les consignes permanentes, la conversation jusqu’ici, et pour un agent, ce que ses outils lui ont renvoyé. Le context engineering, c’est l’art de composer cet ensemble.

Les questions à se poser sont concrètes. Qu’est-ce que le modèle doit absolument savoir pour cette tâche ? Sous quelle forme : le document entier, un extrait, un résumé ? Dans quel ordre : les consignes avant ou après les données ? Qu’est-ce qui doit rester d’une demande à l’autre, et qu’est-ce qui doit être oublié ? Pour un agent, qu’est-ce qu’on garde des résultats d’outils, et qu’est-ce qu’on résume ? Bien répondu, le modèle fait le reste.

Un exemple concret

1. Contexte pauvre : « Réponds à cette réclamation » et l’e-mail du client. Le modèle écrit une réponse polie, générique, qui ne sait rien du dossier. Inutilisable.
2. Contexte trop riche : l’e-mail, les 40 pages de conditions générales, l’historique complet du client, la charte de communication de l’entreprise. Le modèle cite une clause inapplicable et oublie que le client a déjà été remboursé une fois.
3. Contexte composé : l’e-mail ; les trois derniers échanges avec ce client ; la clause de garantie qui s’applique, extraite ; deux exemples de réponses à des réclamations similaires, validées par l’équipe ; et la consigne : ton, longueur, ce qu’on peut proposer et ce qu’on ne peut pas.

Le troisième contexte tient en deux pages. Il a été assemblé par une règle simple, réutilisée à chaque réclamation : l’e-mail, l’historique court, la clause, deux exemples, la consigne.

Ce que ça change pour une équipe

• La qualité dépend d’une méthode, pas d’un talent. Une règle d’assemblage du contexte, écrite une fois, donne des résultats réguliers à toute l’équipe.
• Les exemples valent mieux que les explications. Deux réponses validées montrent le ton et le format mieux que dix lignes de consignes.
• Les documents s’organisent pour l’IA. Des extraits prêts à l’emploi, des fiches courtes, des références datées : la documentation devient une réserve de contextes.
• Les agents deviennent fiables. Un agent dont le contexte est conçu, avec ce qu’il garde et ce qu’il résume, se perd beaucoup moins qu’un agent qui accumule tout.

Les limites et les erreurs fréquentes

• Coller tout le dossier. Le réflexe de sécurité qui noie le modèle. Extraire ce qui sert.
• Oublier l’ordre. Les consignes perdues au milieu d’un long document sont moins bien suivies. Les consignes en tête, les données ensuite, la question à la fin.
• Laisser le contexte dériver. Dans une longue conversation ou une session d’agent, le contexte accumule des éléments périmés. Résumer, trier, repartir.
• Confondre contexte et vérité. Un modèle qui a un document sous les yeux peut encore mal le lire. Le contexte réduit les erreurs ; la vérification reste.