AI Plan
AI Build
AI Run
AI ChangeSolutionDiagnostic Data & IA
Évaluez votre maturité et construisez une roadmap priorisée.
Découvrir le diagnostic Retour à l’Académie IA
Académie IA · context engineering
Qu’est-ce que le context engineering ?
Le context engineering consiste à sélectionner, structurer et maintenir toutes les informations dont un système d’IA a besoin pour accomplir une tâche. Il dépasse le prompt : données, mémoire, outils, état du workflow, permissions et résultats intermédiaires font partie du contexte.
Définition 30 sec
L’ingénierie du contexte, ou context engineering, conçoit l’environnement informationnel transmis à un modèle au bon moment. Elle orchestre instructions, connaissances, exemples, historique, outils et état d’exécution afin de rendre les réponses et actions d’un assistant ou d’un agent plus pertinentes et fiables.
L’abréviation informelle « context eng » est parfois utilisée, mais « context engineering » reste la formulation de référence.
Comprendre
Un LLM ne connaît ni les règles internes d’une entreprise ni la situation opérationnelle courante. Sa performance dépend donc fortement des informations accessibles lors de la requête. Le prompt engineering améliore les instructions ; le context engineering traite l’ensemble du système qui construit et actualise ce contexte.
Le context engineering marque le passage d’un prompt monolithique à une architecture dynamique. Le contexte peut provenir d’un RAG, d’une mémoire, d’applications métier, de métadonnées, d’outils ou d’un état persistant. L’enjeu n’est pas d’en fournir le maximum, mais de sélectionner ce qui est pertinent, autorisé et suffisamment récent.
Un contexte volumineux ou contradictoire peut dégrader le résultat et augmenter les coûts. Sa provenance, sa priorité, sa durée de vie et son niveau de confiance doivent être explicites. L’ingénierie du contexte devient ainsi une discipline de conception et de maintenance, pas une optimisation ponctuelle de consigne.
La contrainte de fenêtre ne suffit pas à définir un bon contexte. Il faut arbitrer fraîcheur, précision, autorité et utilité pour la tâche. Une règle officielle récente doit par exemple primer sur une note ancienne même si celle-ci semble sémantiquement proche.
Le contexte inclut aussi ce que le modèle ne doit pas voir. Les permissions doivent être appliquées avant la récupération, et non confiées au modèle sous forme d’instruction. La réduction du contexte protège donc à la fois la performance, les coûts et la confidentialité.
Comment ça fonctionne ?
Le système identifie d’abord les informations nécessaires à la tâche : objectif, identité de l’utilisateur, règles, données actuelles et résultats précédents. Il collecte ensuite ces éléments dans les sources autorisées.
Une couche d’orchestration filtre, hiérarchise et formate le contexte en fonction de la requête et de la limite disponible. Elle peut résumer un historique, retrouver des documents, appeler un outil ou maintenir un état entre plusieurs étapes.
Après exécution, les résultats utiles sont conservés selon des règles de mémoire et de confidentialité. Des évaluations vérifient non seulement la réponse, mais aussi si le système a mobilisé les bonnes informations, au bon moment et avec les bons droits.
Exemple concret
Un copilote d’approvisionnement doit proposer une action sur une rupture. Le prompt seul ne suffit pas. Le système rassemble la prévision de demande, le stock actuel, les délais fournisseurs, les règles de marge, les contraintes logistiques et les permissions de l’utilisateur. Il ne transmet que les éléments utiles au cas traité.
La qualité de la réponse dépend ici de la construction du contexte opérationnel, bien davantage que d’une formulation brillante mais isolée.
Pourquoi c’est important pour les entreprises ?
Le context engineering transforme des connaissances dispersées en capacité d’action pour l’IA. Il est essentiel lorsque les copilotes et agents doivent travailler dans des processus réels plutôt que répondre à des questions génériques.
Il oblige l’entreprise à clarifier ses sources fiables, ses règles, ses droits d’accès et la propriété de ses connaissances. Il rend aussi visibles des problèmes existants : documentation obsolète, données contradictoires, exceptions non formalisées ou responsabilités floues.
À l’échelle, il faut traiter le contexte comme une infrastructure gouvernée : composants réutilisables, versionnement, observabilité, sécurité et mesure. Le prompt reste utile, mais il devient une brique parmi d’autres.
Cette discipline fait émerger un besoin de collaboration. Les métiers définissent les règles et exceptions, les équipes Data organisent les sources, l’IT sécurise les accès et les équipes IA conçoivent l’orchestration. Aucun acteur ne possède seul le contexte opérationnel complet.
La mesure doit isoler les causes : mauvaise source, information périmée, sélection insuffisante, instruction ambiguë ou limite du modèle. Sans cette observabilité, les équipes modifient le prompt au hasard et accumulent des correctifs fragiles.