Historiquement, nous parlions de « Prompt Engineering » (l’art de rédiger des instructions pour l’IA). Cependant, avec des modèles de plus en plus puissants et des fenêtres de contexte immenses, le défi a changé. Si vous souhaitez itérer pour un workflow du quotidien, ou construire un pipeline automatisé d’ingestion de données (pour exemple), vous avez besoin de rendre votre modèle déterministe. Chaque erreur, infime soit elle, multipliée par le nombre de requête peut représenter une perte de temps et d’argent énorme.
Qu’est-ce que le Context Engineering ?
Le Context Engineering est la discipline qui consiste à sélectionner systématiquement les informations qu’un modèle de langage reçoit afin de maximiser ses performances, tout en minimisant les coûts et les erreurs.
La différence entre le Prompt Engineering et le Context Engineering est la suivante :
-
Le Prompt Engineering se concentre sur la rédaction manuelle de textes et d’instructions astucieuses (ex. : « Tu es un expert en… »). C’est une approche statique qui montre ses limites, car elle ne permet pas de monitorer les résultats en temps réel sans que le LLM ne finisse par se tromper ou divaguer. Cela fonctionne une fois, dix fois, mais sans que l’on sache si un meilleur résultat aurait été possible avec plus de rigueur et un suivi chiffré.
-
Le Context Engineering, quant à lui, se concentre sur la gestion programmatique du système global : récupération de documents (RAG), formatage des données, gestion de la mémoire et définition des outils. C’est une approche disciplinée et dynamique qui garantit la pertinence du message pour un cas d’usage spécifique.
En résumé, on pourrait qualifier le Prompt Engineering de « coup de chance » qui, lorsqu’il se répète, relève de la croyance, là où le Context Engineering transforme l’essai en une véritable science.
Pourquoi le contexte est la base de tout bon prompt ?
Le « contexte » est l’ensemble complet de tokens (mots et/ou caractères) auxquels le modèle a accès pour générer une réponse (instructions système, historique de conversation, documents récupérés, archives, etc.).
Obtenez votre devis gratuit
En moins de 5 minutes, configurez votre projet et recevez un devis détaillé.
-
Le manque d’informations : Si vous donnez trop peu de contexte, le modèle ne saura pas comment agir, d’autant plus si vous vous écartez de sa base de connaissances initiale.
-
L’excès d’informations : À l’inverse, si vous en donnez trop, vous risquez le « Context Rot » (le pourrissement de votre contexte). La performance du modèle se dégrade car il peine à traiter l’information pertinente, les coûts explosent et le temps de réponse (temps d’inférence) devient trop long pour votre usage.
Comment pratiquer l’ingénieurie de context ?
Pour fournir la bonne information au bon moment, le LLM a besoin d’être alimenté par la « bonne » donnée. Nous avons identifié plusieurs leviers sur lesquels vous pouvez jouer, notamment dans le cadre de l’agentique :
-
L’édition et résumé du contexte :
Comme nous l’avons vu, le Context Rot est à éviter, et l’effet Lost in the Middle nous oblige à augmenter la densité d’information. Ici, il s’agit de supprimer sélectivement l’historique non pertinent ou de condenser les informations (par exemple, un long rapport financier résumé en quelques lignes, débarrassé des tournures verbeuses destinées à l’humain). De cette manière, vous augmentez la pertinence tout en réduisant le nombre de tokens ingérés par votre modèle. En anglais, on parle de « Context Editing & Summarization ».
-
Déchargement de la mémoire :
Au lieu de tout stocker dans la fenêtre de contexte, vous pouvez utiliser un fichier externe ou un « scratchpad » (brouillon) où l’agent pourra écrire et lire des informations qui persisteront malgré l’érosion de la fenêtre de contexte. L’agent peut ainsi mettre à jour ses avancées sur un sujet ou laisser des « footprints » (empreintes) pour le prochain agent qui reprendra la tâche.
-
Le Retrieval Augmented Generation (RAG) :
Ici, nous nourrissons le LLM automatiquement. La requête de l’utilisateur est comparée à une base de données vectorielle pour extraire les segments les plus pertinents. Ensuite, via un prompt préconçu, le LLM reçoit ces informations et instructions pour formuler sa réponse. Il existe plusieurs niveaux de complexité :
-
RAG classique : Pour les demandes simples (« Quel est le CA de 2024 ? »).
-
RAG agentique : Pour les demandes nécessitant plusieurs étapes de recherche (« Compare le CA 2025 vs 2024 »).
-
GraphRAG : Où la base de données est un graphe de connaissances structurant les relations entre les données.
-
-
Séléction des bons outils :
Si votre agent a accès à des dizaines d’outils, vous pouvez implémenter un RAG spécifique pour qu’il ne reçoive qu’une liste restreinte et pertinente d’outils adaptés à la tâche en cours.
-
Le flux de contrôle :
Divisez les tâches complexes en sous-tâches ou étapes (chaînes). Chaque étape ne reçoit alors que le contexte strictement nécessaire à sa réalisation spécifique.
DSPy : certainement le prochain workflow largement intégré pour l’ingénieurie de contexte
Si l’on devait concevoir un framework d’IA à partir de zéro en prenant l’ingénierie de contexte au sérieux, on aboutirait inévitablement à DSPy. Plus qu’une simple bibliothèque, DSPy (Declarative, Self-improving Python) représente un changement de philosophie radical : il transforme l’art flou du « prompting » en une véritable discipline d’ingénierie logicielle.
Besoin d'un expert web ?
Site web, SEO, stratégie digitale - Parlons de votre projet.
De l’incantation à la programmation déclarative
Une architecture modulaire et agnostique
Predict à ChainOfThought ou ReAct) sans avoir à réécrire tout votre code. De plus, cette abstraction rend votre système portable : un programme écrit pour GPT-4 peut être basculé sur un modèle Claude ou un modèle open-source local en changeant une seule ligne de configuration, sans casser votre ingénierie de contexte.