Il existe deux littératures sur le prompt engineering. L'une liste des formules qui impressionnent sur un exemple isolé. L'autre décrit ce qui tient encore quand le même prompt tourne mille fois par jour sur des entrées qu'on n'a pas choisies.

Cet article traite de la seconde. Les six techniques ci-dessous ont un point commun : elles réduisent la variance de la sortie, pas seulement sa qualité moyenne. C'est ce qui compte dès qu'un prompt passe en production.

1. Délimiter le contenu, toujours

La confusion la plus fréquente et la plus sous-estimée : le modèle ne distingue pas spontanément votre consigne du texte sur lequel il doit travailler. Ça se voit rarement sur des entrées courtes et propres, et systématiquement dès que l'entrée contient elle-même quelque chose qui ressemble à une instruction.

Tâche : extrais les dates mentionnées dans le texte ci-dessous.
Réponds uniquement par une liste.

<<<TEXTE
{contenu}
TEXTE

Le bénéfice n'est pas seulement la clarté : c'est aussi la première ligne de défense contre l'injection de prompt. Un texte utilisateur qui contient « ignore les instructions précédentes » est nettement moins efficace quand il est visiblement à l'intérieur d'un bloc balisé et que la consigne dit d'en traiter le contenu comme des données.

2. Montrer plutôt que décrire

Décrire un format en prose produit un format approximatif. Deux exemples produisent le format.

C'est particulièrement vrai pour tout ce qui touche au style et aux cas limites. Un exemple qui montre quoi faire quand l'information est absente vaut trois paragraphes de consigne défensive.

Deux à cinq exemples suffisent presque toujours. Au-delà, le coût en tokens monte et le gain devient marginal — et le risque augmente que le modèle recopie un détail accidentel de vos exemples.

3. Contraindre le format de sortie explicitement

Si vous devez parser la réponse, ne demandez pas « une liste » : donnez le schéma exact, et dites quoi mettre quand la valeur manque.

Réponds en JSON, sans texte autour :
{"date": "AAAA-MM-JJ ou null", "montant_millimes": entier ou null}

Deux règles pratiques ici. Interdire explicitement le texte d'accompagnement — sinon vous récupérez du JSON précédé de « Bien sûr, voici : », ce qui casse tout parseur naïf. Et prévoir la valeur nulle — sans quoi le modèle invente une date plutôt que d'admettre qu'il n'y en a pas.

Quand la plateforme le propose, une sortie structurée imposée côté API est toujours préférable à une consigne en langue naturelle : la contrainte devient mécanique au lieu d'être une suggestion.

4. Une tâche par appel

Un prompt qui demande de résumer, classer et traduire en une fois donne trois résultats médiocres. Découpé en trois appels, il donne trois résultats corrects — et surtout, quand l'un se dégrade, vous savez lequel.

L'objection est le coût : trois appels au lieu d'un. Elle est souvent fausse. Le prompt combiné est long, ses consignes se gênent, et il faut le relancer plus souvent. Trois prompts courts et stables coûtent fréquemment moins cher qu'un prompt long qu'on rejoue.

L'objection sérieuse est la latence, et elle se traite en parallélisant les appels indépendants.

5. Donner un critère d'abstention

Un modèle répond. C'est ce qu'il fait. Si vous ne lui donnez pas de porte de sortie, il en invente une — et une réponse fabriquée coûte plus cher qu'une absence de réponse, parce qu'elle ne se signale pas.

Si l'information ne figure pas dans le document fourni,
réponds exactement : INFORMATION_ABSENTE

Un marqueur littéral et repérable vaut mieux qu'une consigne floue du type « dis-le si tu ne sais pas » : votre code peut le tester. C'est la même logique que le null du point 3, appliquée à la réponse entière.

6. Fixer une version du prompt et la traiter comme du code

Un prompt en production est un artefact versionné. Il se relit, se diffe, se déploie et se revient en arrière.

En pratique : le prompt vit dans un fichier, pas dans une chaîne concaténée au milieu de la logique métier ; toute modification passe par une revue ; et un jeu d'entrées de référence est rejoué avant de déployer. Sans ce dernier point, une amélioration sur trois cas observés peut être une régression sur trente cas qu'on ne regarde pas.

Ce qui ne sert à rien

Les incantations de flatterie. « Tu es un expert de classe mondiale » n'apporte rien de mesurable sur les modèles récents. Décrire le rôle a un intérêt quand ça précise un registre ou un public (« explique à quelqu'un qui n'a pas de bagage technique ») — pas quand ça décerne un titre.

Les menaces et les récompenses. « Je vais te donner un pourboire », « c'est très important pour ma carrière » : du folklore issu de générations de modèles antérieures.

Empiler les consignes. Passé une dizaine de contraintes, certaines sont ignorées silencieusement. Un prompt de vingt règles n'en applique pas vingt — il en applique celles qu'il retient, et vous ne saurez pas lesquelles. Coupez plutôt en plusieurs appels (point 4).

Le « step by step » systématique. Demander un raisonnement explicite aide sur les tâches à plusieurs étapes. Sur une extraction ou une classification simple, ça allonge la réponse, augmente le coût et n'améliore rien. Et sur les modèles à raisonnement intégré, la consigne fait doublon.

Et pour le français et la derja

Ces six techniques sont indépendantes de la langue. Ce qui change avec le français — et plus encore avec l'arabe tunisien — c'est la quantité de convention implicite sur laquelle le modèle peut s'appuyer. Moins il y en a, plus les points 2 (montrer) et 3 (contraindre le format) rendent.

Le cas de la derja est traité en détail dans Prompt engineering en derja : orthographe non normalisée, deux systèmes d'écriture, code-switching permanent.

Tukai donne accès à plusieurs modèles dans une même interface, ce qui rend le point 6 — rejouer un jeu d'entrées de référence — praticable sans changer d'outil. Le détail est sur la page fonctionnalités, et la facturation en dinars sur la page tarifs.

Un bon prompt ne se juge pas sur sa meilleure sortie, mais sur sa pire. C'est la variance qui décide s'il tient en production.