Prompt engineering : différences avec context et intent ?

Le prompt engineering façonne la réponse immédiate d’un modèle ; context et intent engineering structurent les données et les objectifs autour du modèle. Je montre comment ces trois couches s’articulent, leurs techniques, limites et quand les combiner pour fiabiliser vos systèmes IA.

Qu’est-ce que le prompt engineering ?

Le prompt engineering consiste à construire l’instruction envoyée au modèle pour obtenir la sortie souhaitée.

Définition : Le prompt engineering regroupe les techniques pour formuler des instructions (prompts) claires, structurées et adaptées à un modèle de langage de grande taille (LLM, pour Large Language Model) afin d’obtenir des réponses précises, fiables et exploitables.

Sensibilité au phrasé : Les LLM prédisent des tokens en fonction du contexte et sont très sensibles au choix des mots, à l’ordre des informations et au format demandé. Des variations mineures peuvent produire des réponses radicalement différentes, surtout sur des tâches ambigües ou multi-étapes.

Techniques communes :

• Zero-shot : Demander directement une tâche sans exemple, utile quand le modèle connaît bien la tâche.
• Few-shot (2–5 exemples) : Fournir quelques exemples annotés dans le prompt pour montrer le format attendu et réduire l’ambiguïté.
• Chain-of-thought (CoT) : Demander au modèle d’exposer son raisonnement étape par étape pour améliorer les performances sur des tâches complexes (Wei et al., 2022).
• System prompts : Instructions système persistantes qui orientent le comportement global du modèle (voir OpenAI docs).
• ReAct : Combinaison d’actions et de raisonnement pour interagir avec des outils ou bases de connaissances (Yao et al., 2022).

Exemples concrets et mini-prompts :

Résumé d’email — Mauvais prompt :

Résume cet email.

Résumé d’email — Version améliorée (rôle, format, contraintes) :

Tu es un assistant professionnel. Résume l'email en 3 phrases maximum, points clés en bullet points, élimine le bruit et conserve les actions à faire.

Génération d’objet d’email — Mauvais prompt :

Propose un objet.

Génération d’objet d’email — Version améliorée :

Agis comme un responsable communication. Propose 5 objets courts (50 caractères max), orientés conversion, et indique le ton (formel/informatif).

Sources principales : Wei et al., 2022 (Chain-of-Thought); Yao et al., 2022 (ReAct); OpenAI Documentation (system prompts).

Qu’est-ce que le context engineering ?

Le context engineering consiste à fournir au modèle les données externes et la gestion mémoire nécessaires pour répondre correctement.

Principes. La fenêtre de contexte (ou context window) désigne la quantité de texte qu’un LLM peut traiter en une fois, typiquement 8k à 32k tokens pour GPT-4 selon la version. La technique de chunking consiste à découper des documents en segments gérables pour respecter cette limite. La mise à jour de la mémoire couvre l’ajout, la suppression et l’archivage d’éléments contextuels afin de garder la réponse pertinente et fraîche.

• RAG (Retrieval-Augmented Generation). Méthode décrite par Lewis et al., 2020, qui combine récupération d’informations et génération.
• Embeddings. Représentations vectorielles des textes permettant la recherche sémantique; expliqués comme des points dans un espace multidimensionnel.
• Vector DB. Bases de données optimisées pour les vecteurs (exemples : FAISS, Pinecone) utilisées pour l’indexation et la recherche par similarité.
• Mise en cache et versioning. Stockage des résultats fréquentés et contrôle de la version des documents pour éviter les réponses basées sur des sources obsolètes.

Exemple pratique — Pipeline RAG. Indexation des documents → calcul des embeddings → stockage dans une index vectoriel → recherche par similarité au runtime → construction du prompt final avec extraits pertinents → génération par le LLM.

# Pseudo-code RAG (simplifié)
docs = ingest(source_files)
vectors = embed(docs)                    # embeddings
index.upsert(vectors)                    # vector DB (FAISS/Pinecone)
query_vec = embed(user_query)
hits = index.search(query_vec, k=5)      # retrieval
context = assemble(hits)                 # selected chunks
prompt = template.format(context, user_query)
response = LLM.generate(prompt)

Limites et risques. Contexte limité par la taille de fenêtre, coût et latence augmentés par la recherche et l’envoi d’un contexte long, risques d’obsolescence des données et d’injection de prompt via documents malveillants.

• Bonnes pratiques opérationnelles. Chunking adapté (taille ~500–1000 tokens selon usage), stratégies de freshness (re-indexation régulière), contrôle de source, user-scoped context pour éviter les fuites entre utilisateurs, et tests adversariaux pour détecter l’injection de prompt.

Qu’est-ce que l’intent engineering ?

L’intent engineering définit et formalise l’objectif métier et le mapping entre intentions utilisateur et workflows automatisés.

Définition claire. L’Intent Engineering formalise l’objectif métier derrière une interaction utilisateur et traduit cette intention en une suite d’actions automatisées exécutables par un système.

Différences avec prompt et context. Le prompt correspond à l’entrée textuelle fournie au modèle (ce que l’utilisateur dit). Le context regroupe les données complémentaires disponibles (profil utilisateur, historique, documents). L’intent représente l’objectif ou l’action souhaitée (ce que l’on veut atteindre).

Exemple de transformation d’une demande libre en séquence d’actions. Pour une requête générique, on peut décomposer en quatre étapes : rechercher (collecte d’information), planifier (définition des étapes et priorités), exécuter (actions automatisées), vérifier (contrôles et confirmations).

Méthodes pour modéliser les intents. Voici des approches courantes et complémentaires.

• Taxonomies : Classification hiérarchique des intentions métier pour normaliser les libellés.
• NLU classifier : NLU signifie Natural Language Understanding (compréhension du langage naturel), et désigne des modèles entraînés pour détecter l’intent.
• Ontologies : Modèles sémantiques reliant concepts métier, entités et relations pour une compréhension riche.
• Règles + ML : Combinaison de règles déterministes et d’apprentissage automatique pour robustesse et évolutivité.

Design d’un intent-to-action mapping. Cartographier chaque intent vers une séquence d’actions précises, définir préconditions (données requises), fallbacks (scénarios erreurs) et métriques de succès. Je recommande d’industrialiser ces mappings dans un registre versionné.

Exemple concret — Personnalisation d’email. Intentes à détecter : information (demande d’info), rendez-vous (prise de RDV), réclamation (insatisfaction). Workflow type : récupérer le profil via RAG (Retrieval-Augmented Generation : technique qui combine récupération de documents et génération), remplir un template personnalisé, envoyer l’email et enregistrer le suivi.

Tableau synthétique.

Monitoring et boucles de rétroaction. Mesurer en continu la précision des détections et les métriques opérationnelles, analyser erreurs et faux positifs, et réentraîner ou ajuster règles. L’amélioration des intents est un cycle itératif indispensable pour maintenir la fiabilité du workflow.

// Exemple pseudocode d'un mapping intent -> actions
if intent == "Rendez-vous":
  profile = retrieveProfile(userId) // RAG ou base utilisateur
  slots = extractSlots(prompt) // date, créneau
  if slots.valid:
    book = scheduler.reserve(profile, slots)
    sendConfirmation(book)
  else:
    askClarification()

Quand et comment combiner les trois couches ?

Combiner intent, context et prompt en pipeline donne une exécution fiable : intent détectée → context récupéré → prompt conçu pour exécution. Cette approche sépare la compréhension (intent), la mémoire/données (context) et la génération (prompt), ce qui facilite la robustesse et la traçabilité.

Scénarios d’application.

• Tâches simples : Un prompt seul suffit pour des réponses directes ou créatives sans dépendance à des données externes.
• Tâches nécessitant des données à jour : Combiner prompt + context via Retrieval ou API pour injecter des faits récents (ex. prix, disponibilité).
• Workflows autonomes : Utiliser intent + context + prompt pour orchestrer des actions multi-étapes (ex. réservation, workflows RH).

Patterns d’architecture.

• Orchestrator/Agent : Composant central qui séquence detectIntent(), retrieveContext(), renderPrompt() et exécute appels API.
• Agent loop ReAct : Agent qui alterne réflexion (Reasoning) et action (Action) pour itérer sur des sous-tâches.
• RAG + Prompt Templates : Retrieval-Augmented Generation (RAG) récupère documents, puis un template assemble contexte + instruction.
• State Machine pour intents : Machine à états pour suivre le statut d’une intention multi-étapes (ex. réservation en attente de confirmation).

Exemples d’implémentation.

• FAQ dynamique (RAG + prompt template) : Indexer docs produit, récupérer top-k chunks pertinents, injecter dans template avec instructions de synthèse et citations.
• Agent de réservation : Classifier intent via NLU (Natural Language Understanding), récupérer profil utilisateur et calendriers, orchestrer prompt pour confirmer créneaux puis appeler API de réservation.

Snippets pseudocode.

// Template prompt avec placeholders de contexte
Template = "Vous êtes un assistant. Contrainte : Répondre en français.\nContexteUtilisateur: {{user_profile}}\nContexteDocs: {{retrieved_docs}}\nInstruction: {{task_instruction}}\nRésultat attendu : Résumer en 3 points."

// Process pipeline
intent = detectIntent(user_input)               // NLU classifier
context = retrieveContext(intent, user_id)      // DB, vector search, APIs
prompt = renderPrompt(Template, context, intent) // Remplacer placeholders
response = callLLM(prompt)                       // Appel modèle
result = postProcess(response, intent)           // Extraction, actions, logs

Indicateurs à surveiller.

Checklist de déploiement.

• Tests end-to-end avec jeux d’exemples représentatifs.
• Few-shot examples pour stabiliser le comportement du prompt.
• Monitoring : logs, traces, alertes sur latence/coût/précision.
• Plan de rollback et feature flags pour désactiver l’agent en cas de régression.
• Processus de ré-entraînement ou de réindexation périodique pour limiter le drift.

Prêt à combiner prompt, context et intent pour fiabiliser vos IA ?

Les trois couches sont complémentaires : le prompt façonne la réponse immédiate, le contexte fournit les données nécessaires et l’intent structure l’objectif et le workflow. Pour des systèmes robustes, il faut orchestrer intent detection, retrieval de contexte fiable et prompts bien formatés, mesurer la performance (précision, latence, coût) et mettre en place des boucles de rétroaction. En appliquant ces principes, vous réduisez les erreurs, gagnez en cohérence métier et augmentez la valeur opérationnelle de vos projets IA.

FAQ

• Qu’est-ce qui différencie prompt engineering du context engineering ?
  Le prompt engineering porte sur la formulation envoyée au modèle ; le context engineering porte sur les données externes (documents, base utilisateur, mémoire) nécessaires pour répondre correctement. Le premier guide le comportement, le second fournit l’information.
• Quand faut-il ajouter une couche intent engineering ?
  Lorsque vous devez traduire des demandes utilisateurs en workflows ou actions automatisées (multi-étapes), ou garantir que l’IA respecte des objectifs métier définis. L’intent engineering formalise ces objectifs et oriente l’orchestrateur.
• Quels outils pour le context engineering ?
  Classiquement : embeddings + vector DB (FAISS, Milvus, Pinecone), frameworks RAG (LangChain, Haystack), et pipelines d’ingestion. L’important est la qualité des embeddings et la stratégie de chunking.
• Quelles métriques suivre pour juger la fiabilité du système ?
  Précision de détection d’intent, taux de réponses utiles, latence, coût par requête, taux d’erreur/échouement, drift des données. Complétez par évaluations humaines régulières.
• Quels sont les risques courants et comment s’en protéger ?
  Risques : manque d’information (données absentes), injection de prompt (source non fiable), hallucinations. Mitigations : contrôle des sources, validation post-LLM, tests adversariaux, monitoring et rollback.

A propos de l’auteur

Franck Scandolera — expert & formateur en Tracking avancé server-side, Analytics Engineering, Automatisation No/Low Code (n8n), intégration de l’IA en entreprise et SEO/GEO. Responsable de l’agence webAnalyste et de l’organisme de formation Formations Analytics. Références clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Française de Football, Texdecor. Disponible pour aider les entreprises => contactez moi.

Franck Scandolera

⭐ Analytics engineer, Data Analyst et Automatisation IA ⭐

• Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

• Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
• Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
• Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.