Context engineering : pourquoi le prompt engineering ne suffit plus
Les premières vagues de l’IA générative ont popularisé le « prompt engineering », l’art de formuler des instructions afin d’obtenir la réponse souhaitée d’un modèle. Au fil de 2023‑2025, des communautés ont partagé des recettes : écrire des prompts longs, utiliser des listes, assigner des rôles (« tu es un comptable »), etc. Cependant, cette technique présente des limites : les résultats sont fragiles, sensibles à de légères modifications, et ne prennent pas en compte la mémoire ni le contexte prolongé des échanges. Pour déployer des applications robustes, les entreprises se tournent désormais vers le « context engineering ».
Limites du prompt engineering
Un prompt isolé agit comme un message dans le vide. Les grands modèles de langage (LLM) sont non‑déterministes : la même requête peut produire des réponses différentes selon l’état interne du modèle ou le tirage aléatoire. De plus, un changement de formulation peut conduire à une dérive. Les tests montrent qu’une phrase ou une consigne légèrement différente peut conduire à un résultat opposé. Les prompts ne disposent pas de mémoire : après avoir répondu, le modèle oublie le contexte antérieur, à moins qu’il soit répété dans le prompt. Cela limite les applications longues ou complexes.
Par ailleurs, un simple prompt ne permet pas d’intégrer des données métier à jour (textes juridiques, bases de données internes). La réponse se base uniquement sur la connaissance générale du modèle, qui peut être obsolète ou inadéquate.
Le concept de context engineering
Le context engineering consiste à fournir au modèle un environnement structuré, enrichi de connaissances pertinentes et de métadonnées, permettant des interactions cohérentes et fiables. Selon MarketLiftUp, cette approche établit un cadre de raisonnement où le modèle peut s’appuyer sur une continuité, une mémoire et des règles spécifiques au domaine. Contrairement aux simples prompts, le contexte inclut la conversation antérieure, des données externes et des paramètres qui guident le comportement du modèle.
Une des principales technologies associées est le Retrieval‑Augmented Generation (RAG). Cette méthode combine un LLM avec une base de connaissances externe : lorsqu’un utilisateur pose une question, un moteur de recherche interne va récupérer des documents pertinents et les injecter dans le contexte avant de générer une réponse. Ainsi, le modèle répond en s’appuyant sur des informations actualisées et vérifiables.
Types de contexte à gérer
Le contexte n’est pas un bloc monolithique. MarketLiftUp identifie plusieurs types :
| Type de contexte | Description | Exemple |
|---|---|---|
| Persistant | Informations stables sur l’utilisateur (identité, préférences), le domaine ou la tâche | Identifiants de l’entreprise, règles de conformité interne, historique des interactions passées |
| Actuel (up‑to‑date) | Données en temps réel provenant de bases, API ou documents récents | Taux de change, disponibilité des stocks, textes de loi mis à jour |
| Adaptatif | Informations ajustées en fonction de la conversation en cours | Résumé des échanges, clarifications apportées, intention de l’utilisateur |
La gestion du contexte est contrainte par la fenêtre de contexte du modèle, c’est‑à‑dire la longueur maximale du texte d’entrée. Pour des modèles comme GPT‑4, cette fenêtre peut dépasser 30 000 tokens, mais elle reste limitée. Il faut donc choisir quelles informations sont pertinentes et les adapter (résumer, hiérarchiser) pour maximiser la pertinence.
Différences entre prompt engineering et context engineering
| Aspect | Prompt engineering | Context engineering |
|---|---|---|
| Nature | Instructions formulées pour guider la réponse | Environnement structuré incluant mémoire, données et métadonnées |
| Robustesse | Sensible aux variations et aléatoire | Plus fiable grâce à la continuité et aux sources externes |
| Gestion de la connaissance | S’appuie uniquement sur la connaissance interne du modèle | Intègre des données actualisées via RAG ou des bases internes |
| Adaptabilité | Nécessite des ajustements manuels pour chaque tâche | Peut être paramétré et automatisé (context builders) |
| Cas d’usage | Expérimentation, requêtes simples, tests rapides | Applications professionnelles, assistants spécialisés, chatbots métiers |
Mettre en œuvre le context engineering
Pour déployer une solution basée sur le context engineering, plusieurs composantes entrent en jeu :
- Construction d’une base de connaissances : agrégation de documents internes (politiques, FAQ), de données clients et de sources publiques fiables. Il est important d’indexer ces documents et de les structurer (titres, sections, métadonnées) pour faciliter la récupération.
- Moteur de recherche interne : un modèle de recherche sémantique ou un moteur vectoriel identifie les passages les plus pertinents pour une question donnée. Ces passages sont convertis en vecteurs et comparés à la requête.
- Sélection et injection du contexte : selon la longueur du contexte disponible, sélectionner les documents les plus pertinents et les injecter dans la fenêtre de contexte. Ajouter des en‑têtes ou des tags pour aider le modèle à distinguer les sources.
- Prompt orchestration : structurer le prompt en combinant l’historique de la conversation, les informations de l’utilisateur et les documents récupérés. Utiliser des balises ou des marqueurs pour séparer les parties.
- Boucle d’apprentissage : analyser les réponses générées et recueillir les commentaires des utilisateurs pour améliorer la base de connaissances, le moteur de recherche et la gestion du contexte.
Avantages et exemples
Le passage du prompt engineering au context engineering offre plusieurs bénéfices :
- Fiabilité accrue : en s’appuyant sur des documents vérifiés, les réponses sont plus exactes et les hallucinations sont réduites.
- Personnalisation : le modèle tient compte de l’identité et des préférences de l’utilisateur grâce au contexte persistant.
- Scalabilité : le système peut être déployé dans différentes équipes avec des contextes distincts (juridique, RH, marketing).
- Conformité : l’utilisation de bases internes et la traçabilité des sources facilitent le respect des réglementations (par ex. RGPD).
Des entreprises du secteur juridique utilisent déjà cette approche : la start‑up Harvey intègre des bases de données de jurisprudence pour fournir des conseils précis aux avocats, tandis que des hôpitaux combinent des modèles avec des dossiers médicaux pour proposer des plans de soins actualisés. Ces vertical LLMs (voir article suivant) reposent souvent sur une architecture contextuelle pour garantir la pertinence et la sécurité.
Conclusion
Le prompt engineering constitue une étape utile pour expérimenter les LLMs, mais il atteint ses limites dès que l’on s’attaque à des tâches professionnelles, complexes ou sensibles. En fournissant au modèle un environnement riche et structuré, le context engineering permet de s’affranchir de la fragilité des prompts et d’intégrer des données actualisées grâce à des approches comme le RAG. Pour les entreprises, c’est une condition indispensable pour développer des assistants intelligents fiables, capables de raisonner sur des contextes longs et d’apporter une véritable valeur ajoutée.
