# Qu’est-ce que l’ingénierie du contexte, et en quoi diffère-t-elle de l’ingénierie de prompts?

Date: 2025-07-09 · Author: Robert Scales · https://guidetoartificialintelligence.com/fr/apprendre/qu-est-ce-que-l-ingenierie-du-contexte/

**Answer:** L’ingénierie du contexte consiste à décider de tout ce qu’un modèle de langage voit avant de répondre, y compris les consignes, les documents récupérés, les définitions d’outils, la mémoire et l’historique de la conversation, et à l’assembler à neuf pour chaque requête. L’ingénierie de prompts, l’art de formuler la demande elle-même, est une partie de ce travail plus vaste.

Depuis quelques semaines, l’expression « ingénierie du contexte » (*context engineering*) se répand rapidement chez les gens qui conçoivent des produits avec l’IA. Le PDG de Shopify, Tobi Lutke, a dit la préférer à « ingénierie de prompts » (*prompt engineering*), parce qu’elle décrit mieux la véritable compétence : donner au modèle tout le contexte dont il a besoin pour avoir une chance raisonnable de réussir la tâche. Andrej Karpathy, un chercheur en IA bien connu, a abondé dans le même sens, et des billets de blogue de Harrison Chase, de LangChain, et d’autres ont depuis tenté de cerner l’idée.

Ce changement de vocabulaire reflète un changement dans ce que les gens construisent. Un **prompt** est le texte que vous envoyez à un modèle. Une **fenêtre de contexte** est tout ce que le modèle peut lire d’un coup, mesuré en jetons (des morceaux de mots). Quand vous clavardez avec ChatGPT, votre prompt est l’essentiel de ce que vous contrôlez. Quand vous créez un **agent**, un programme qui permet à un modèle d’utiliser des outils et de faire plusieurs étapes, le prompt n’est qu’une petite tranche d’un contexte que votre code assemble automatiquement, différemment chaque fois.

## La différence en un tableau

| | Ingénierie de prompts | Ingénierie du contexte |
|---|---|---|
| Question principale | Comment formuler cette demande? | Que doit voir le modèle pour faire cette tâche? |
| Unité de travail | Un morceau de texte | Un système qui rassemble et organise de nombreux morceaux |
| Moment | Quand vous écrivez le prompt | Chaque fois que le programme appelle le modèle |
| Correction typique | Des consignes plus claires, un exemple, un format | Ajouter la donnée ou l’outil manquant, retirer le bruit, résumer l’historique |

Harrison Chase décrit l’ingénierie de prompts comme un sous-ensemble du travail plus vaste. Des consignes claires comptent toujours, mais les autres morceaux comptent tout autant. Son test pratique mérite d’être retenu : quand un agent se trompe, demandez-vous s’il avait la bonne information et les bons outils. Sinon, la correction se trouve dans le contexte, pas dans la formulation. S’il avait tout et s’est quand même trompé, c’est le modèle ou les consignes qui posent problème.

Simon Willison, un développeur qui écrit beaucoup sur les modèles de langage, fait une remarque sur les mots eux-mêmes. Bien des gens entendent « ingénierie de prompts » comme un nom pompeux pour le fait de taper dans un robot conversationnel; l’expression n’a donc jamais rendu compte de l’effort en jeu. « Ingénierie du contexte » se prête moins aux malentendus.

## Un exemple concret : une requête, de nombreuses parties

Prenons un assistant pour une petite entreprise, construit sur un modèle qui a accès à des outils. Un client écrit : « Est-ce que je peux déplacer mon rendez-vous de jeudi à la semaine prochaine? » Voici ce qu’un système bien conçu pourrait placer dans le contexte avant que le modèle voie le message. Le nombre de jetons est donné à titre d’illustration.

| Partie | Ce qu’elle contient dans cet exemple | Jetons (environ) |
|---|---|---|
| Prompt système | Rôle, ton, règles de l’entreprise (« ne jamais réserver en dehors des heures d’ouverture ») | 400 |
| Définitions d’outils | `find_booking`, `list_free_slots`, `move_booking`, chacun avec ses entrées | 600 |
| Mémoire à long terme | Ce client préfère le matin et utilise les prénoms | 50 |
| Documents récupérés | La politique de report : préavis de 24 heures, sans frais | 150 |
| Historique de la conversation | Les trois derniers messages, ou un court résumé des plus anciens | 200 |
| Prompt de l’utilisateur | La question du client | 20 |
| Format de sortie | Le texte de la réponse plus une action structurée, s’il y a lieu | 80 |

Les mots du client lui-même représentent environ 20 jetons sur quelque 1 500. Le reste décide si la réponse est utile. Sans la politique, le modèle risque d’inventer des frais. Sans la mémoire, il risque de proposer des plages l’après-midi. Sans l’outil `list_free_slots`, il ne peut que deviner ce qui est libre.

Philipp Schmid, un ingénieur en IA qui écrit sur les agents, donne un exemple semblable dans son survol : un assistant qui répond à une demande de réunion rapide fait beaucoup mieux quand il peut aussi voir votre calendrier, vos courriels passés avec cette personne et un outil pour envoyer une invitation.

> **À essayer :** choisissez une tâche que vous confiez souvent à ChatGPT. Avant d’écrire le prompt, dressez dans un tableau la liste de ce qu’un collègue serviable aurait besoin de savoir : faits, documents, préférences, décisions antérieures. Collez les éléments pertinents dans la conversation avec votre demande, puis comparez la réponse avec celle que vous obtenez à partir de la demande seule.

## Des principes qui s’appliquent à l’usage quotidien

Même sans écrire de code, les habitudes se transposent. Donnez au modèle les faits qu’il ne peut pas connaître; il ne peut lire ni dans vos pensées ni dans vos fichiers. Préférez un court résumé pertinent à un long déversement, puisque le fouillis fait concurrence à ce qui compte. Le format compte aussi : une liste bien rangée des heures d’ouverture est plus facile à utiliser pour un modèle qu’une page Web collée telle quelle. Et quand une conversation s’est égarée, une nouvelle conversation qui commence par un résumé propre fonctionne souvent mieux qu’un long historique embrouillé.

## Que contient le contexte d’un agent, à part le prompt?

La plupart des descriptions énumèrent les mêmes briques. Le **prompt système** contient les consignes permanentes : rôle, règles, ton et parfois des exemples. Les **définitions d’outils** décrivent chaque fonction que l’agent peut appeler, avec son nom, son but et ses entrées, pour que le modèle sache ce qu’il peut faire et comment le demander. L’**information récupérée**, souvent appelée RAG (*retrieval-augmented generation*, génération augmentée par récupération), est du texte tiré de documents, de bases de données ou du Web pour cette requête.

Vient ensuite la mémoire. La **mémoire à court terme** est la conversation jusqu’ici, y compris les résultats des appels d’outils précédents, souvent condensée en résumé quand elle s’allonge. La **mémoire à long terme** est ce que le système conserve d’une session à l’autre, comme les préférences d’un utilisateur. Enfin, une **définition de la sortie** indique au modèle quelle forme sa réponse doit prendre, par exemple un objet JSON que le programme peut lire.

Le travail d’ingénierie consiste à choisir parmi ces éléments à chaque étape. Tout ce qu’on inclut coûte des jetons et de l’attention, et tout ce qui manque devient une supposition. Un bon agent charge ce dont l’étape suivante a besoin, laisse de côté ce qui ne sert pas et garde des consignes assez claires pour que le modèle sache quoi faire du reste.

## Sources

- The rise of "context engineering": https://blog.langchain.com/the-rise-of-context-engineering/
- The New Skill in AI is Not Prompting, It's Context Engineering: https://www.philschmid.de/context-engineering
- Context engineering: https://simonwillison.net/2025/Jun/27/context-engineering/