Le context engineering est la discipline qui consiste à décider quelles informations sont transmises à un modèle de langage, sous quelle forme et à quel moment. Là où le prompt engineering se concentre sur la formulation d'une instruction unique, le context engineering gouverne l'ensemble de l'environnement informationnel dans lequel le modèle raisonne.
Pourquoi cette distinction est importante
Un modèle de langage ne peut pas récupérer des informations qui ne lui ont pas été fournies. Ses résultats sont limités par ce qui se trouve dans sa fenêtre de contexte au moment de l'inférence. Si cette fenêtre contient des données incorrectes, des données obsolètes ou trop de bruit, la réponse du modèle en souffre, quelle que soit la qualité de la formulation du prompt.
Le context engineering traite cette fenêtre comme une ressource gérée. La question n'est pas seulement « que dois-je demander ? » mais « que doit savoir le modèle, et comment cette connaissance doit-elle être organisée ? »
Ce que recouvre concrètement le context engineering
En pratique, il englobe plusieurs décisions liées entre elles :
- Sélection. Quels documents, enregistrements, sorties d'outils ou traces mémoire sont pertinents pour cette requête ? Les pipelines de récupération, notamment RAG, constituent un mécanisme pour répondre à cette question au moment de l'exécution.
- Structure. Comment l'information doit-elle être ordonnée et mise en forme ? Les modèles traitent différemment le contenu selon sa position et sa présentation. Placer des contraintes critiques à la fin d'un contexte long est une source d'erreur connue.
- Compression. Les fenêtres de contexte sont finies et les coûts d'inférence augmentent avec le nombre de tokens. La résumisation, la stratégie de découpage et le filtrage influent tous sur la quantité d'informations utiles qui peuvent y tenir.
- Fraîcheur. Un contexte statique devient obsolète. Les systèmes qui injectent des données en temps réel, l'état de l'utilisateur ou des résultats d'outils récents nécessitent une logique pour gérer ce qui doit être actualisé et à quel moment.
- Séparation des rôles. Dans les systèmes multi-tours ou agentiques, il est important de distinguer les instructions système, les entrées utilisateur, les réponses des outils et les sorties précédentes du modèle, afin que celui-ci interprète correctement chaque élément.
Relation avec le prompt engineering
Le prompt engineering reste pertinent : la formulation d'une instruction détermine encore ce que le modèle fait avec les informations qu'il reçoit. Mais le prompt engineering couvre peut-être 10 à 20 pour cent des leviers disponibles. Le context engineering couvre le reste. Les deux ne sont pas en concurrence ; le context engineering est le cadre plus large dans lequel le prompt engineering opère.
Là où il apparaît dans les systèmes en production
Les décisions de context engineering sont intégrées dans la plupart des applications assistées par l'IA qui ne sont pas triviales :
- Un agent de codage qui récupère les fichiers pertinents, les résultats de tests et les journaux d'erreurs avant de demander à un modèle de proposer un correctif fait du context engineering.
- Un assistant destiné aux clients qui récupère l'historique du compte et les documents de politique avant de générer une réponse fait du context engineering.
- Un pipeline de traitement documentaire qui décide quelles sections d'un contrat transmettre à un modèle, et dans quel ordre, fait du context engineering.
Dans les systèmes agentiques, où les modèles exécutent des séquences d'actions et où le contexte s'enrichit à chaque étape, le problème d'ingénierie devient plus complexe. Les décisions sur ce qu'il faut conserver, résumer ou supprimer influent directement sur la cohérence de l'agent tout au long d'une tâche longue.
Défaillances courantes
Un context engineering insuffisant tend à produire l'un des quelques problèmes reconnaissables suivants : le modèle ignore une contrainte parce qu'elle était noyée dans du matériel non pertinent ; il hallucine un fait qui était récupérable mais qui ne l'a pas été ; il contredit des instructions antérieures parce que la fenêtre de contexte n'était pas gérée d'un tour à l'autre ; ou il fonctionne bien en test et mal en production parce que le contexte de test était plus propre que les données réelles.
Ces défaillances sont souvent attribuées à tort au modèle lui-même. Dans bien des cas, le modèle se comporte de manière cohérente avec ce qui lui a été fourni.
Ce que nous évaluons
Le jugement en matière d'ingénierie du contexte est évalué directement lors de notre sélection technique. Dans l'évaluation AI-native, les candidats sont notés sur l'ingénierie des prompts et du contexte en tant que critère explicite : s'ils configurent le prompt et le contexte de la tâche de façon à ce que l'outil produise un résultat exploitable en une ou deux passes. Nous examinons également le développement piloté par les spécifications et la vérification des sorties d'IA, qui dépendent tous deux de la même compétence sous-jacente : décider quelles informations le modèle nécessite et à quel moment. La grille d'évaluation complète et la structure des sessions sont décrites sur comment nous sélectionnons.
Réponses courtes
Le context engineering est-il la même chose que RAG ?
Non. RAG est une technique permettant de remplir le contexte au moment de l'exécution en récupérant des documents pertinents. Le context engineering est la discipline plus large qui consiste à décider ce qui entre dans la fenêtre de contexte, sous quelle forme et dans quel ordre. RAG est un outil au sein de cette pratique.
Faut-il comprendre le context engineering pour utiliser des outils d'IA pour le codage ?
Pour un usage basique, non. Pour des systèmes en production où la fiabilité est importante, oui. Les ingénieurs qui comprennent le context engineering prennent de meilleures décisions sur les informations à exposer à un modèle et sur les raisons pour lesquelles les sorties échouent lorsqu'elles le font.
En quoi le context engineering diffère-t-il du fine-tuning ?
Le fine-tuning modifie les poids du modèle pour y intégrer des connaissances ou des comportements. Le context engineering fournit des informations au moment de l'inférence sans modifier le modèle. Les deux sont complémentaires, mais le context engineering est moins coûteux à itérer et ne nécessite pas de réentraînement.
