Prompt engineering ou context engineering : ce que l'IA doit savoir de votre travail

On demande souvent : « Quel est le bon prompt ? »

La question est utile, mais elle arrive trop tard si l'IA ne connaît ni votre situation, ni vos ressources, ni vos règles, ni la qualité attendue. Une demande bien formulée ne remplace pas le contexte de travail.

Le prompt engineering concerne la manière de formuler une instruction. Le context engineering concerne ce que l'IA doit pouvoir connaître, au bon moment, pour contribuer à une tâche réelle sans inventer le cadre à votre place.

Un prompt est une demande. Le contexte est l'environnement de cette demande.

Prenons une instruction simple : « Prépare une formation sur l'IA pour mon équipe. »

Elle donne une action, mais elle laisse presque tout le reste dans le flou. Quelle équipe ? Quel niveau de départ ? Quels outils sont autorisés ? Quel temps est disponible ? Quels enjeux métier ? Quelles données sont sensibles ? Quel résultat pédagogique faut-il obtenir ? Quelles ressources sont déjà validées ?

L'IA peut combler ces manques avec des hypothèses plausibles. C'est précisément le problème : une réponse plausible n'est pas nécessairement adaptée.

Le context engineering consiste à préparer les éléments qui permettront à l'IA de ne pas avoir à deviner l'essentiel.

Les quatre couches d'un contexte utile

Un bon contexte n'est pas une accumulation de documents. C'est une sélection organisée.

1. Le contexte stable Ce sont les informations qui changent peu : mission de l'organisation, règles de confidentialité, ton éditorial, politiques internes, rôles des personnes, sources de référence, critères de qualité.

2. Le contexte de situation Il concerne la tâche du moment : public visé, objectif, échéance, contraintes, étape d'un projet, décisions déjà prises, risques particuliers.

3. Les ressources de preuve Ce sont les documents, données, modèles, exemples validés et sources que l'IA peut mobiliser. Elles doivent être identifiées, à jour et proportionnées à la question.

4. Le contexte d'exécution Il précise où en est le travail : ce qui a déjà été tenté, ce qui reste à décider, les actions suivantes, la personne responsable et le format attendu.

Cette architecture évite deux erreurs opposées : donner à l'IA si peu d'informations qu'elle improvise, ou lui transmettre un dossier entier sans savoir ce qui est pertinent.

Un exemple de situation de travail

Imaginons qu'une responsable formation veuille concevoir un module sur l'usage responsable de l'IA.

Un simple prompt demanderait : « Crée un module de deux heures sur l'IA responsable. »

Un contexte de travail utile préciserait par exemple :

• -le public et son niveau d'expérience ;
• -les situations métier qui serviront de cas ;
• -les outils effectivement disponibles ;
• -les règles internes sur les données ;
• -les ressources que l'équipe considère comme fiables ;
• -les objectifs pédagogiques ;
• -les critères de réussite ;
• -les éléments que l'IA ne doit pas inventer.

Le résultat ne devient pas automatiquement juste. En revanche, il devient plus facile à discuter, à vérifier et à adapter. L'IA n'est plus invitée à remplacer le cadrage du travail. Elle est invitée à travailler à partir d'un cadrage explicite.

Le context engineering n'est pas une mémoire magique

Mettre des documents à disposition d'un assistant ne signifie pas qu'il les comprend tous de la même manière, qu'ils sont à jour, ni qu'ils seront pertinents dans chaque réponse. Une bibliothèque de prompts n'est pas une base de connaissances. Un dossier partagé n'est pas, en lui-même, un contexte exploitable.

Le contexte doit être gouverné : qui en est propriétaire ? quand a-t-il été mis à jour ? quelles sources font foi ? lesquelles ne doivent pas être utilisées ? quelles informations sont confidentielles ? que se passe-t-il lorsqu'une règle change ?

Le context engineering est donc aussi un travail d'organisation. Il oblige à rendre les savoirs de travail plus explicites avant de vouloir les automatiser.

CADREZ® : une méthode de cadrage, pas une formule magique

CADREZ® peut servir de repère pour préparer ce contexte.

• -C comme Collaborateur : quel rôle précis confie-t-on à l'IA ?
• -A comme Action : qu'attend-on d'elle à cette étape ?
• -D comme Description : quelle est la situation humaine et professionnelle ?
• -R comme Ressources : quelles sources, données, contraintes et références sont autorisées ?
• -E comme Exigences : à quoi reconnaîtra-t-on une réponse utile ?
• -Z comme Zéro oubli : qu'est-ce qui manque encore pour éviter une réponse fondée sur des suppositions ?

L'intérêt de cette approche n'est pas d'allonger les prompts. Il est de rendre visibles les éléments qui déterminent la qualité du travail. CADREZ® est un cadre méthodologique à tester et ajuster dans chaque situation. Ce n'est pas une garantie automatique de fiabilité ou de compréhension.

Cinq gestes pour passer du prompt au contexte

• -Cartographier la tâche : objectif, public, contraintes, enjeux et décision attendue.
• -Choisir les bonnes ressources : peu de documents, mais identifiés, datés et pertinents.
• -Écrire les règles de qualité : format, niveau de preuve, ton, limites, éléments interdits.
• -Prévoir la vérification : qui relit, avec quels critères, sur quels points de vigilance ?
• -Conserver une trace : ce qui a été fourni, modifié, écarté et retenu.

Ces cinq gestes sont utiles avec un chatbot, un assistant métier ou un agent plus autonome. Plus le système peut agir, plus cette architecture doit être explicite.

La question à poser à votre organisation

Votre IA manque-t-elle vraiment de bons prompts ? Ou manque-t-elle surtout d'un contexte fiable, partagé et maintenu par les personnes qui connaissent le travail réel ?

Dans la plupart des organisations, la deuxième réponse est la plus importante. C'est là que se joue la différence entre une démonstration convaincante et un usage réellement utile.