Context engineering : le guide pour mieux utiliser l'IA

Publié le 9 juillet 2026 — Mis à jour le 21 juillet 2026

Vous pouvez écrire un prompt précis et obtenir malgré tout une réponse médiocre. La cause n'est pas toujours votre demande. Elle se trouve souvent dans les informations qui l'entourent : une ancienne instruction, un document trop long, un exemple contradictoire ou un historique devenu confus.

Le context engineering, ou ingénierie de contexte, consiste à sélectionner, structurer et maintenir toutes les informations fournies à un modèle d'IA afin qu'il puisse accomplir une tâche correctement. Cela inclut votre prompt, mais aussi les instructions système, l'historique, les fichiers, les exemples, les outils disponibles et les résultats de ces outils.

En clair : le prompt définit ce que vous demandez. Le contexte détermine ce que l'IA peut comprendre et utiliser pour vous répondre.

En bref — 7 règles pour construire un meilleur contexte

1. Définissez le cadre de travail : objectif, contraintes et format attendu.
2. Placez les instructions importantes en premier : séparez-les clairement des données à analyser.
3. Ne fournissez que les informations utiles : la capacité maximale n'est pas une cible à atteindre.
4. Ajoutez des exemples représentatifs : montrez le résultat attendu au lieu de seulement le décrire.
5. Nettoyez l'historique : repartez dans une nouvelle conversation quand la tâche change.
6. Séparez les projets : un contexte métier, des sources et des règles propres à chaque usage.
7. Vérifiez le contexte avant d'accuser le modèle : cherchez les informations manquantes, obsolètes ou contradictoires.

Sommaire

1. Qu'est-ce que le context engineering ?
2. Context engineering et prompt engineering : quelle différence ?
3. Ce que le modèle voit vraiment
4. Pourquoi plus de contexte peut dégrader la réponse
5. Les 7 leviers du context engineering
6. Exemple concret : analyser un contrat
7. Checklist avant d'envoyer votre demande
8. Questions fréquentes

Qu'est-ce que le context engineering ?

Le context engineering est la pratique qui consiste à fournir à une IA le plus petit ensemble d'informations pertinentes pour produire le résultat attendu. Son objectif n'est pas de remplir la fenêtre de contexte, mais d'y placer les bonnes instructions, données, exemples et ressources, au bon moment et dans une structure claire.

Anthropic présente le context engineering comme la suite naturelle du prompt engineering. À mesure que les usages deviennent plus longs et plus complexes, il ne suffit plus de rédiger une bonne instruction. Il faut aussi gérer l'état complet transmis au modèle au fil des échanges.

Pour une conversation simple, cette discipline peut se résumer à choisir les bons extraits d'un document. Pour un agent IA, elle couvre également sa mémoire, ses outils, les résultats de ses actions et les règles qui déterminent les informations accessibles à chaque étape.

Context engineering et prompt engineering : quelle différence ?

Le prompt engineering améliore la formulation d'une demande. Le context engineering organise l'ensemble des informations disponibles au moment où le modèle génère sa réponse.

Élément	Prompt engineering	Context engineering
Question principale	Comment formuler la demande ?	Quelles informations le modèle doit-il recevoir ?
Périmètre	Prompt utilisateur et instructions	Prompt, historique, fichiers, exemples, mémoire et outils
Moment	Principalement avant la réponse	Avant et pendant toute la tâche
Risque courant	Demande vague ou ambiguë	Contexte incomplet, encombré ou contradictoire
Exemple	« Résume ce contrat en 10 points »	Fournir les clauses utiles, le rôle du lecteur et les critères de risque

Les deux pratiques sont complémentaires. Un bon contexte ne sauve pas une demande incompréhensible, et un excellent prompt ne compense pas des données absentes ou contradictoires.

Ce que le modèle voit vraiment

Une application d'IA assemble plusieurs éléments dans une fenêtre de contexte avant de demander au modèle de produire une réponse. Selon l'outil utilisé, cette fenêtre peut contenir :

1. des instructions définies par l'application ou le projet ;
2. vos messages précédents et les réponses du modèle ;
3. des fichiers, extraits de documents ou résultats de recherche ;
4. des exemples de réponses attendues ;
5. la description des outils que l'IA peut utiliser ;
6. votre demande actuelle.

Le modèle génère sa réponse à partir de cet ensemble. Il ne distingue pas toujours spontanément une règle encore valable d'une consigne abandonnée trois échanges plus tôt. Il ne sait pas non plus qu'un document est obsolète si rien ne le signale.

La fenêtre de contexte fixe donc une capacité maximale, pas une garantie de compréhension uniforme. Un modèle capable d'accepter un très long document n'exploitera pas nécessairement chaque passage avec la même fiabilité.

Pourquoi plus de contexte peut dégrader la réponse

Ajouter des informations peut aider l'IA, mais chaque élément inutile lui donne aussi une nouvelle occasion de se tromper de priorité.

Les travaux de Chroma sur le context rot montrent que les performances peuvent varier à mesure que la longueur du contexte augmente, y compris sur des tâches relativement simples. L'étude ne conclut pas que tout contexte long est mauvais. Elle montre qu'une grande capacité en tokens ne garantit pas une utilisation constante de toutes les informations. Consultez l'étude complète de Chroma.

Le phénomène dit lost in the middle illustre un autre risque. Une étude publiée dans Transactions of the Association for Computational Linguistics a observé que plusieurs modèles exploitaient mieux une information placée au début ou à la fin d'un long contexte qu'au milieu. Les auteurs concluent que fournir davantage de documents crée un compromis entre information disponible et difficulté de traitement. Consultez l'étude « Lost in the Middle ».

Ces résultats évoluent avec les modèles. Google Research rapporte par exemple que Gemini 2.5 Flash retrouve correctement des faits simples même près de la limite de sa fenêtre de contexte. Cette amélioration ne supprime toutefois pas les problèmes de pertinence, de contradictions ou de raisonnement sur plusieurs sources. Consultez l'évaluation de Google Research.

La bonne règle n'est donc pas « faites toujours court ». C'est : maximisez le signal utile et réduisez le bruit.

Les 7 leviers du context engineering

1. Définir un cadre de travail stable

Les instructions persistantes servent à définir les règles qui restent vraies pendant toute la tâche : rôle, objectif, public, contraintes et forme de la réponse.

Une instruction utile ne se contente pas d'attribuer un personnage à l'IA. Elle décrit surtout le travail à accomplir et les critères d'un bon résultat.

Instruction trop vague :

Tu es un expert juridique. Résume les contrats.

Instruction exploitable :

Analyse les contrats commerciaux du point de vue du client.

Pour chaque document :
1. résume l'objet du contrat en 100 mots maximum ;
2. identifie les obligations du client ;
3. signale les clauses de responsabilité, de pénalité et de résiliation ;
4. distingue les faits du document de tes recommandations ;
5. indique « information absente » lorsqu'un élément manque.

Le lecteur est un dirigeant non-juriste. Utilise un français clair.

Cette seconde version transforme une posture générale en procédure vérifiable.

2. Placer les instructions avant les données

Présentez d'abord la tâche et le format attendu, puis séparez clairement les documents à traiter. OpenAI recommande également de structurer clairement les instructions et d'utiliser des délimiteurs pour distinguer les consignes du contenu source. Consultez le guide de prompt engineering d'OpenAI.

Objectif : extraire les trois principaux risques contractuels.

Format : un tableau avec les colonnes Clause, Risque et Action recommandée.

Contrat à analyser :
"""
[extrait du contrat]
"""

Pour un long dossier, rappelez la question après les pièces si l'interface le permet. Vous réduisez ainsi le risque que la demande se perde parmi les données.

3. Réduire le volume, augmenter la densité

Ne confondez pas exhaustivité et pertinence. Pour analyser les conditions de résiliation d'un rapport de 80 pages, commencez par les sections qui traitent de la durée, du préavis, des pénalités et des obligations postérieures à la fin du contrat.

Si vous ignorez les passages utiles, procédez en deux étapes :

1. demandez à l'IA d'identifier les sections pertinentes ;
2. ouvrez une nouvelle analyse avec ces sections et vos critères précis.

Vous évitez ainsi de mélanger la phase de recherche avec la phase de décision.

4. Montrer un exemple du résultat attendu

Un exemple aide le modèle à reproduire une structure, un niveau de détail ou un ton. Cette méthode, appelée few-shot prompting, fonctionne mieux quand l'exemple ressemble réellement à la tâche finale.

Exemple de sortie attendue :

Clause : Résiliation anticipée
Risque : Élevé
Motif : Le fournisseur peut résilier avec un préavis de 7 jours, sans motif.
Action : Demander un préavis de 30 jours et limiter la résiliation aux manquements non corrigés.

Analyse maintenant l'extrait suivant selon le même format :
[extrait]

Évitez les exemples moyens ou contradictoires. Le modèle peut reproduire leurs défauts aussi fidèlement que leurs qualités.

5. Nettoyer l'historique de conversation

Un long fil accumule des brouillons, des corrections et des hypothèses devenues fausses. Quand vous changez d'objectif, ouvrez une nouvelle conversation et transmettez uniquement l'état validé.

Situation	Approche recommandée
Vous améliorez le même article	Gardez le fil : les versions précédentes peuvent aider
Vous passez d'un article à une analyse financière	Ouvrez une nouvelle conversation
Vous traitez plusieurs documents indépendants	Utilisez un fil par document
Le modèle répète une ancienne erreur	Repartez avec un résumé corrigé
Le fil contient plusieurs consignes incompatibles	Créez un contexte propre et hiérarchisé

Avant de repartir, demandez éventuellement un résumé des décisions prises. Relisez-le, corrigez-le, puis utilisez cette version comme point de départ.

6. Séparer les projets et les sources

Chaque domaine métier a son vocabulaire, ses documents de référence et ses règles. Un projet de support client ne devrait pas partager les mêmes instructions qu'un projet juridique ou éditorial.

Pour chaque projet, définissez :

• l'objectif et les tâches autorisées ;
• les sources de référence ;
• le ton et le format des livrables ;
• les informations interdites ou sensibles ;
• les situations qui exigent une validation humaine.

Cette séparation améliore la cohérence et réduit le risque qu'une règle prévue pour un usage influence une autre tâche.

7. Auditer le contexte avant de changer de modèle

Quand une réponse est mauvaise, changer immédiatement de modèle ne révèle pas la cause. Vérifiez d'abord le contexte :

• L'information nécessaire est-elle présente ?
• La source est-elle fiable et à jour ?
• Deux instructions se contredisent-elles ?
• Le résultat attendu est-il défini ?
• Un ancien échange détourne-t-il la réponse ?
• Le document contient-il beaucoup de passages sans rapport avec la question ?

Une fois le contexte nettoyé, comparez plusieurs modèles avec exactement la même demande. Vous saurez alors si l'écart vient du modèle plutôt que des données fournies.

Exemple concret : analyser un contrat

Voici deux façons de demander la même analyse.

Sans context engineering

[PDF de 45 pages]

Analyse ce contrat.

La demande ne précise ni le point de vue, ni les risques recherchés, ni le niveau de détail. Le modèle doit deviner ce qui compte.

Avec context engineering

Rôle : tu assistes le responsable des achats de l'entreprise cliente.

Objectif : préparer une première revue avant validation par un juriste.

Critères : identifie les risques liés à la responsabilité, aux pénalités,
au renouvellement et à la résiliation. N'invente aucune clause absente.

Format :
1. résumé en 5 points ;
2. tableau des risques avec niveau Faible, Moyen ou Élevé ;
3. questions à transmettre au juriste.

Source :
"""
[clauses 4, 7, 9 et 12 du contrat]
"""

La différence ne tient pas à une formule magique. Le second contexte précise le lecteur, l'objectif, les critères, le format et les sources pertinentes. Il réduit les décisions que le modèle doit improviser.

Pour un document juridique, l'IA reste un outil de préparation. Une décision contractuelle importante doit être validée par un professionnel qualifié.

Checklist avant d'envoyer votre demande

Utilisez cette checklist pour vérifier votre contexte en moins d'une minute :

• L'objectif tient en une phrase.
• Le lecteur ou l'utilisateur final est identifié.
• Les critères de réussite sont explicites.
• Le format de sortie est défini.
• Les sources utiles sont présentes et datées.
• Les documents inutiles ont été retirés.
• Les instructions et les données sont clairement séparées.
• Aucun ancien message ne contredit la demande actuelle.
• Un exemple est fourni si le style ou la structure compte.
• Les limites et besoins de validation humaine sont indiqués.

Questions fréquentes

Quelle est la différence entre context engineering et prompt engineering ?

Le prompt engineering consiste à mieux formuler une instruction. Le context engineering organise tout ce que le modèle reçoit : instruction, historique, fichiers, exemples, mémoire et outils. Le prompt est donc une composante du contexte, pas son équivalent.

Une grande fenêtre de contexte donne-t-elle de meilleures réponses ?

Pas automatiquement. Une grande fenêtre permet de transmettre davantage de texte, mais la qualité dépend de la pertinence, de la structure et de la cohérence de ce texte. Un contexte plus long peut aider s'il contient des preuves utiles. Il peut aussi dégrader la réponse s'il ajoute du bruit ou des contradictions.

Quand faut-il ouvrir une nouvelle conversation avec une IA ?

Ouvrez une nouvelle conversation lorsque vous changez de sujet, de document ou d'objectif, ou quand l'historique contient trop de corrections. Conservez le même fil lorsque vous poursuivez exactement la même tâche et que les échanges précédents restent utiles.

Comment éviter le context rot ?

Réduisez les informations non pertinentes, placez les consignes importantes au début, séparez clairement les sources et résumez les décisions validées. Pour les tâches longues, créez régulièrement un contexte propre à partir d'un résumé relu plutôt que d'accumuler tous les échanges.

Le context engineering est-il utile sans compétences techniques ?

Oui. Choisir les bons extraits, ouvrir un nouveau fil au bon moment, fournir un exemple et organiser ses projets sont déjà des pratiques de context engineering. Les développeurs appliquent les mêmes principes à plus grande échelle avec des bases documentaires, des outils et des agents IA.

À retenir

Le context engineering ne consiste pas à donner le plus d'informations possible à une IA. Il consiste à lui donner les informations les plus utiles, dans une structure qu'elle peut exploiter.

Commencez par trois actions simples : définissez le résultat attendu, retirez ce qui ne sert pas la tâche et ouvrez une nouvelle conversation lorsque l'objectif change. Vous obtiendrez souvent un gain plus net qu'en ajoutant une nouvelle couche d'instructions à un fil déjà confus.

Pour approfondir le sujet :

• Comment rédiger de bons prompts : les 10 techniques de base ;
• Hallucinations IA : pourquoi l'IA invente et comment l'éviter : comment vérifier les sources et les réponses ;
• ChatGPT vs Claude vs Gemini : quel modèle choisir en 2026 ? : comparez les modèles selon votre tâche.

Sur Haloon, vous pouvez organiser vos conversations par projet, conserver des instructions adaptées à chaque usage et utiliser Reprompt pour comparer plusieurs modèles avec le même contexte. Vous gardez ainsi vos sources, votre historique et vos essais dans un seul espace de travail privé.