Le prompt
ne suffit
plus.

Pendant longtemps, on a beaucoup parlé de prompt engineering. L'idée était simple : mieux écrire la demande pour obtenir une meilleure réponse. C'était déjà utile, et ça l'est encore. Mais dès qu'on veut construire une vraie application IA, ce n'est plus suffisant.

Aujourd'hui, la question n'est plus seulement : "quel prompt écrire ?". La vraie question devient : quel contexte faut-il donner au modèle pour qu'il comprenne le besoin, utilise les bonnes informations, appelle les bons outils et produise une réponse fiable ?

C'est exactement là que le context engineering devient important. On ne parle plus seulement d'une phrase bien formulée. On parle d'une architecture complète autour du modèle.

Le context engineering, expliqué simplement

Le context engineering, c'est l'art de préparer intelligemment tout ce que le modèle va voir avant de répondre. Il faut imaginer le contexte comme le bureau de travail du modèle : les consignes, les documents ouverts, les outils disponibles, les informations importantes, l'historique utile et les règles à respecter.

Un modèle puissant avec un mauvais contexte peut répondre à côté. Un modèle moins puissant avec un contexte propre peut parfois produire une réponse beaucoup plus utile. C'est une idée importante, parce qu'elle remet l'architecture au centre.

De plus, le context engineering devient encore plus stratégique avec les agents. Un agent ne fait pas que répondre. Il peut chercher, lire, écrire, appeler une API, modifier un fichier ou décider d'une étape suivante. Dans ce cas, le contexte ne sert plus seulement à améliorer la réponse. Il sert à contrôler l'action.

Prompt engineering vs context engineering

Le prompt engineering répond surtout à une question : comment formuler la demande ?

Le context engineering répond à une question plus large : comment construire l'environnement qui permet au modèle de bien travailler ?

La différence est fondamentale. Un prompt peut dire : "Tu es un expert en architecture IA, explique-moi le RAG". C'est utile. Mais un système de context engineering peut ajouter la documentation du projet, les choix techniques déjà faits, les erreurs rencontrées, les contraintes de sécurité, les données disponibles, le niveau de l'utilisateur, le format attendu et les outils que l'agent peut utiliser.

C'est là que l'on passe d'une conversation à une application. Le prompt devient une brique, mais le contexte devient le moteur de fiabilité.

Les briques du contexte

Pour vulgariser, on peut découper le contexte en plusieurs briques.

• Le system prompt : le rôle, les règles, les limites et le comportement attendu.
• La demande utilisateur : ce que la personne veut vraiment obtenir, avec ses contraintes.
• Les données récupérées : documents, chunks RAG, bases de connaissances, résultats de recherche.
• La mémoire : ce qui doit être conservé entre deux échanges, sans tout réinjecter inutilement.
• Les outils : ce que l'agent peut appeler, lire, modifier ou déclencher.
• L'état de la tâche : ce qui est déjà fait, ce qui reste à faire, ce qui est bloqué.
• Le format de sortie : tableau, JSON, article, plan d'action, synthèse courte ou livrable complet.

Quand ces briques sont mal assemblées, le modèle peut être très bon et produire quand même une réponse faible. Quand elles sont bien organisées, la qualité monte immédiatement.

Trois exemples concrets

1. Un assistant de code

Un mauvais prompt dirait simplement : "corrige ce bug". C'est trop pauvre. Un bon contexte donne aussi le fichier concerné, les conventions du projet, les tests existants, l'erreur exacte, les contraintes de sécurité et la commande de vérification.

La différence est énorme. Dans le premier cas, le modèle devine. Dans le second, il travaille comme un développeur qui a ouvert le bon dossier, lu les bonnes règles et compris ce qu'il doit prouver avant de livrer.

2. Un assistant support client

Un prompt peut dire : "réponds poliment au client". Mais un vrai système doit injecter le statut du client, son historique, la politique commerciale, les tickets précédents, le produit concerné, le niveau de priorité et les actions autorisées.

Là encore, le contexte fait toute la différence. Sans contexte, l'IA donne une réponse générique. Avec contexte, elle peut produire une réponse utile, cohérente avec la politique de l'entreprise et adaptée à la situation réelle.

3. Un agent de veille IA

Pour un blog comme celui-ci, on pourrait demander : "écris un article sur une nouveauté IA". Mais le vrai contexte devrait contenir la thèse éditoriale, le niveau du lecteur, les sources à vérifier, le format de l'article, les angles à éviter, les articles déjà publiés et les notions à vulgariser.

C'est exactement ce qui permet de passer d'un texte correct à un article cohérent avec une ligne éditoriale.

La méthode simple pour commencer

Il n'est pas nécessaire de construire une architecture complexe dès le départ. La bonne approche est progressive.

D'abord, clarifier le rôle et le résultat attendu. Ensuite, ajouter les documents vraiment utiles. Puis intégrer la mémoire, seulement quand elle apporte de la valeur. Ensuite, brancher les outils, mais avec des permissions strictes. Enfin, mesurer la qualité avec des exemples de test.

Le point important, c'est de ne pas ajouter du contexte pour remplir la fenêtre. Trop de contexte peut dégrader la réponse. Le bon contexte n'est pas le plus long. C'est le plus pertinent.

Ce qu'il faut retenir

Le prompt engineering reste utile. Il permet de mieux formuler, mieux cadrer, mieux guider. Mais il devient insuffisant dès que l'IA doit travailler dans un environnement réel.

Le context engineering est le passage à l'échelle. C'est ce qui permet de construire des systèmes IA plus fiables, plus cohérents, plus maintenables et beaucoup plus proches des usages concrets.