Contexte et Contraintes

Le contexte : donner au modèle ce qu’il ne sait pas

Les modèles Mistral disposent de connaissances générales étendues, mais ils ignorent tout de votre situation spécifique : votre entreprise, votre projet, votre audience, vos contraintes métier. Le contexte que vous fournissez dans votre prompt comble cet écart, et c’est lui qui fait toute la différence entre un outil généraliste et un assistant spécialisé. Sans contexte, le modèle produit des réponses génériques — justes en moyenne, inutilisables en particulier. Avec le bon contexte, il produit des réponses sur mesure.

Trois types de contexte à fournir

Le premier est le contexte situationnel : la situation dans laquelle s’inscrit votre demande. Un directeur marketing qui écrit simplement « propose-moi un plan marketing » obtiendra un plan de manuel scolaire. S’il précise sa situation, tout change :

Contexte : Je suis directeur marketing d'une PME de 50 salariés
spécialisée dans la vente de mobilier de bureau en B2B.
Nous lançons une nouvelle gamme éco-responsable en septembre 2026.
Notre budget marketing annuel est de 80 000 euros.

Chaque phrase de ce contexte élimine des dizaines de réponses hors sujet : exit les stratégies B2C, exit les budgets à sept chiffres, exit les recommandations sans lien avec le lancement.

Le deuxième est le contexte documentaire : les données que le modèle doit analyser ou utiliser. Le modèle ne connaît pas vos chiffres internes — il faut les lui donner, idéalement délimités par des balises pour les séparer des instructions :

Voici les résultats trimestriels à analyser :

<données>
T1 2026 : CA 1.2M€, marge 23%, 145 nouveaux clients
T2 2026 : CA 1.5M€, marge 21%, 178 nouveaux clients
T3 2026 : CA 1.1M€, marge 19%, 112 nouveaux clients
</données>

Identifiez les tendances et proposez 3 actions correctives pour le T4.

Le troisième est le contexte d’audience : à qui s’adresse le contenu généré. Un même sujet ne s’explique pas de la même façon à un débutant et à un expert. Précisez par exemple : « Le texte s’adresse à des développeurs Python confirmés (5+ ans d’expérience) qui découvrent les API de modèles de langage pour la première fois. Pas besoin d’expliquer les bases de Python, mais détaillez les concepts LLM. » Le modèle calibrera alors son niveau de détail exactement là où votre lecteur en a besoin.

Définir le format attendu

Le format de sortie est l’une des contraintes les plus puissantes. Sans indication, le modèle choisira un format par défaut — souvent un texte en prose — que vous devrez retravailler. En précisant le format, vous obtenez exactement ce dont vous avez besoin, prêt à l’emploi.

Pour une liste, dites-le : « Listez les avantages sous forme de bullet points (5 maximum). » Pour un tableau : « Présentez les résultats dans un tableau Markdown avec les colonnes Fonctionnalité | Disponibilité | Priorité. » Pour une intégration logicielle, le JSON structuré est roi, et il mérite d’être spécifié champ par champ :

Retournez la réponse au format JSON suivant :
{
  "resume": "string (max 100 mots)",
  "mots_cles": ["string"],
  "sentiment": "positif | neutre | négatif",
  "score_confiance": "number (0-1)"
}

Le même principe vaut pour le code : « Écrivez la fonction en Python 3.11+. Ajoutez des docstrings Google-style et des type hints. Incluez 2 exemples d’utilisation en commentaires à la fin. » Plus le format est décrit précisément, moins vous aurez de reprises à faire.

Contraindre la longueur

Les modèles Mistral ont tendance à être exhaustifs si vous ne fixez pas de limites. Vous pouvez contraindre la longueur par nombre de mots (« Répondez en 150 mots maximum »), par structure (« Répondez en exactement 3 paragraphes de 2-3 phrases chacun ») ou par éléments (« Donnez exactement 5 recommandations, chacune en une phrase »).

Une mise en garde s’impose toutefois : les modèles de langage comptent mal les mots et les caractères. Demander « exactement 150 mots » produira un texte d’environ 150 mots, rarement pile. Si la longueur compte vraiment pour vous, préférez les contraintes structurelles — nombre de paragraphes, de points, de sections —, que le modèle respecte beaucoup plus fidèlement que les comptages précis.

Contraindre le ton et le registre

Le ton de la réponse influence directement son utilité : un texte au ton inadapté est un texte à réécrire. Soyez explicite, quitte à empiler les précisions : « Ton : professionnel mais accessible. Évitez le jargon technique sauf quand il est incontournable (dans ce cas, définissez-le). Utilisez le vouvoiement. Pas d’émojis ni de langage familier. »

Une astuce de formateur : les directives de ton les plus efficaces passent souvent par une comparaison avec une situation professionnelle connue. « Répondez comme un consultant senior qui présente à un comité de direction », « Adoptez un ton pédagogique, comme un professeur qui explique à des étudiants de master » ou « Soyez direct et concis, comme un rapport d’audit interne » : chacune de ces phrases condense en une image tout un ensemble de choix de vocabulaire, de longueur et de posture que le modèle sait décoder.

Contraindre le périmètre

Délimiter le périmètre, c’est dire au modèle où s’arrêter. Prenons un exemple de consignes :

Consignes de périmètre :
- Concentrez-vous UNIQUEMENT sur le marché français
- Ne mentionnez PAS les réglementations américaines ou britanniques
- Ignorez les aspects fiscaux (un autre expert s'en charge)
- Si une information vous manque, indiquez-le explicitement
  plutôt que d'inventer

La dernière consigne mérite qu’on s’y arrête : elle est votre meilleure défense contre les hallucinations. Un modèle à qui l’on demande une réponse complète a tendance à combler les trous avec du plausible ; en l’autorisant explicitement à admettre ses limites, vous transformez une invention silencieuse en signalement visible, que vous pouvez ensuite traiter.

Combiner contexte et contraintes

En pratique, un prompt professionnel combine naturellement tout ce qui précède : le contexte et les règles permanentes dans le system prompt, les données et le format attendu dans le message user. Voici un exemple complet d’analyse RH :

messages = [
    {
        "role": "system",
        "content": """Vous êtes un analyste RH senior dans une entreprise tech française.
Règles :
- Français formel, vouvoiement
- Basez-vous uniquement sur les données fournies
- Si une donnée manque, signalez-le avec [DONNÉE MANQUANTE]
- Format : sections avec titres, bullet points, pas de prose"""
    },
    {
        "role": "user",
        "content": """Analysez les données d'absentéisme ci-dessous et proposez un plan d'action.

Données T1 2026 :
- Taux d'absentéisme global : 7.2% (+1.8 pts vs T1 2025)
- Département le plus touché : Support client (12.1%)
- Motif principal : arrêts maladie courte durée (< 5 jours)
- Ancienneté moyenne des absents : 2.3 ans

Format attendu :
1. Diagnostic (3 points max)
2. Causes probables (3 hypothèses)
3. Plan d'action (5 mesures concrètes avec calendrier)"""
    }
]

Observez comment chaque élément vu dans cette leçon y trouve sa place : le rôle et le registre dans le system, les données délimitées dans le user, le format numéroté en fin de message, et le garde-fou anti-invention ([DONNÉE MANQUANTE]) posé une fois pour toutes.

Points clés à retenir

• Le contexte transforme une réponse générique en réponse personnalisée
• Fournissez le contexte situationnel, documentaire et d’audience selon les besoins
• Définissez toujours le format de sortie attendu (JSON, liste, tableau, etc.)
• Contraignez la longueur par la structure plutôt que par le comptage de mots
• Délimitez le périmètre et autorisez le modèle à signaler les informations manquantes