Anti-Patterns à Éviter

Les erreurs qui sabotent vos prompts

Maîtriser le prompting, c’est aussi savoir ce qu’il ne faut pas faire. Certaines habitudes, parfaitement naturelles en communication humaine, produisent des résultats médiocres avec les modèles Mistral — précisément parce qu’elles reposent sur une compréhension implicite que le modèle n’a pas. Cette leçon recense les sept anti-patterns les plus fréquents, avec pour chacun la version fautive, la version corrigée et la logique de la correction. Vous reconnaîtrez probablement quelques-unes de vos propres habitudes au passage.

Anti-pattern 1 : le langage subjectif

Entre collègues, « fais-moi un texte pas trop long » fonctionne, parce que vous partagez un contexte : le collègue sait pour quel usage, pour quel lecteur, dans quelles habitudes de la maison. Le modèle, lui, ne perçoit pas les mots subjectifs comme vous. Des termes comme « court », « long », « beaucoup », « intéressant » ou « pas trop » sont ambigus et produisent des résultats imprévisibles d’une exécution à l’autre.

Mauvais :

Écrivez un texte pas trop long sur l'IA.
Incluez beaucoup d'exemples intéressants.

Bon :

Écrivez un texte de 200 à 300 mots sur l'IA générative.
Incluez 3 exemples concrets d'application en entreprise
(marketing, RH, service client).

La règle de correction est mécanique : remplacez chaque terme subjectif par une mesure objective. « Pas trop long » devient « 200-300 mots », « beaucoup d’exemples » devient « 3 exemples », et « intéressants » devient une description précise du type d’exemples attendus.

Anti-pattern 2 : les instructions contradictoires

Quand votre prompt contient des consignes incompatibles — « soyez exhaustif et couvrez tous les aspects » suivi de « répondez en maximum 3 phrases » —, le modèle doit choisir laquelle suivre, et ce choix est imprévisible. Un jour vous aurez trois phrases superficielles, le lendemain un pavé exhaustif. La correction consiste à réconcilier les deux exigences en une consigne unique et cohérente : « Couvrez les 3 aspects principaux du sujet. Pour chaque aspect, donnez une phrase de synthèse (max 25 mots). » L’exhaustivité est devenue un périmètre défini, la brièveté une contrainte par élément — plus aucun conflit.

Si vos règles sont réellement complexes, avec des comportements différents selon les cas, ne les entassez pas : structurez-les en arbre de décision, où chaque branche est explicite :

Si le client est un particulier :
  → Utilisez un ton accessible, évitez le jargon technique
  → Proposez l'offre Starter en premier

Si le client est une entreprise :
  → Utilisez un ton professionnel et technique
  → Proposez l'offre Enterprise en premier

Si vous ne savez pas :
  → Demandez poliment si c'est pour un usage personnel ou professionnel

Anti-pattern 3 : demander au modèle de compter

Les modèles de langage sont mauvais en comptage. Ils ne comptent pas réellement les mots, les caractères ou les phrases — ils estiment, parce qu’ils manipulent des tokens et non des unités de texte. Demander « exactement 150 mots » ou « vérifiez que chaque phrase fait moins de 20 mots » revient à exiger d’un peintre qu’il mesure au micron : ce n’est pas son instrument.

Mauvais :

Écrivez un texte de exactement 150 mots.
Vérifiez que chaque phrase fait moins de 20 mots.

Bon :

Écrivez un texte court (environ 150 mots, 2-3 paragraphes).
Utilisez des phrases concises et directes.

Et si le comptage est réellement critique pour votre application — une limite de caractères imposée par une interface, par exemple —, effectuez-le côté code après avoir reçu la réponse du modèle, pas dans le prompt. Votre langage de programmation compte parfaitement ; le modèle, non.

Anti-pattern 4 : la génération excessive de tokens

Chaque token généré a un coût, financier et en latence. Demander au modèle de produire des informations que vous n’utiliserez pas est du gaspillage pur : vous payez plus cher pour attendre plus longtemps un texte que vous ne lirez pas. Le cas typique est l’analyse de code où l’on demande « expliquez chaque ligne en détail », plus « l’historique du langage » et « les alternatives possibles », alors que seuls les bugs vous intéressent.

Bon :

Analysez ce code et identifiez :
1. Les bugs potentiels (avec la ligne concernée)
2. Une correction proposée pour chaque bug
Rien d'autre.

Le « rien d’autre » final est une consigne étonnamment puissante : elle dit explicitement au modèle de ne pas ajouter les compléments, avertissements et élargissements qu’il produit spontanément. Votre réponse arrive plus vite, coûte moins cher et va droit au but.

Anti-pattern 5 : les échelles numériques

Demander au modèle de noter sur une échelle de 1 à 5 ou de 1 à 10 semble rigoureux — c’est en réalité le contraire. Le modèle n’a pas de calibration interne fiable pour ces échelles : le même texte pourra recevoir 6/10 aujourd’hui et 8/10 demain, sans qu’aucun critère n’explique l’écart. La solution consiste à remplacer les chiffres par des échelles verbales avec des critères explicites :

Évaluez la qualité de ce texte selon ces niveaux :
- Insuffisant : erreurs factuelles, structure incohérente
- Acceptable : correct mais manque de profondeur ou de clarté
- Bon : bien structuré, clair, avec des exemples pertinents
- Excellent : publication-ready, original, apporte une valeur ajoutée claire

Choisissez un niveau et justifiez en 2 phrases.

Chaque niveau étant défini par des critères observables, l’évaluation devient reproductible et justifiée — vous savez pourquoi un texte est « Acceptable » plutôt que « Bon », et le modèle applique les mêmes critères à chaque appel.

Anti-pattern 6 : les instructions vagues

« Améliorez ce texte » est l’exemple parfait de la consigne qui semble claire et ne l’est pas du tout. Améliorer quoi ? L’orthographe ? Le style ? La structure ? Le modèle choisira pour vous, et il risque de réécrire des passages que vous vouliez conserver tels quels. La version professionnelle délimite à la fois ce qu’il faut corriger et ce qu’il faut laisser intact :

Améliorez ce texte en corrigeant :
1. Les fautes d'orthographe et de grammaire
2. Les phrases de plus de 30 mots (simplifiez-les)
3. Les répétitions de mots dans un rayon de 3 phrases

Ne modifiez PAS :
- Le sens des phrases
- Les termes techniques (même s'il existe des synonymes)
- La structure des paragraphes

Le bloc « Ne modifiez PAS » est aussi important que le premier : sans lui, un modèle zélé remplacera vos termes techniques par des synonymes approximatifs.

Anti-pattern 7 : ignorer le pré-remplissage

Le dernier anti-pattern est une occasion manquée plutôt qu’une erreur active : beaucoup d’utilisateurs ignorent la possibilité de pré-remplir la réponse via le rôle assistant, vue dans la leçon sur les rôles. C’est pourtant un levier puissant pour forcer un format. Avec un simple message user demandant du JSON, le modèle peut ajouter une phrase d’introduction, des backticks, un commentaire final — autant d’éléments qui casseront votre parsing. En terminant vos messages par un début de réponse assistant, le format devient quasi garanti :

Sans pré-remplissage (format imprévisible) :

messages = [
    {"role": "user", "content": "Listez 3 avantages du télétravail en JSON."}
]

Avec pré-remplissage (format garanti) :

messages = [
    {"role": "user", "content": "Listez 3 avantages du télétravail en JSON."},
    {"role": "assistant", "content": "{\"avantages\": ["}
]

Le modèle se trouve déjà « en train d’écrire » l’objet JSON : il ne peut que le compléter.

Points clés à retenir

• Remplacez le langage subjectif et les instructions vagues par des consignes mesurables et délimitées
• Évitez les instructions contradictoires — structurez les cas complexes en arbre de décision
• Ne demandez jamais au modèle de compter : les comptages critiques se font côté code
• Limitez la génération aux informations réellement utilisées, avec des échelles verbales plutôt que numériques
• Exploitez le pré-remplissage assistant pour garantir le format de sortie