Intermédiaire 20 min

L'art du Prompt Engineering

Comment structurer vos prompts pour obtenir des résultats prévisibles et exploitables, au lieu de parler au LLM comme à un humain.

Le prompt engineering souffre d’un problème d’image. On a souvent l’impression qu’il s’agit de trouver la “phrase magique” pour débloquer l’IA. En réalité, en tant que développeur, vous devez voir un LLM pour ce qu’il est, un moteur probabiliste. Il ne réfléchit pas, il calcule la suite la plus probable de votre texte.

Votre objectif est de réduire l’entropie (l’incertitude) de sa réponse.

Soyez explicite sur le contexte et le format

Un prompt flou donne un résultat générique. Donnez-lui un rôle, un contexte précis, et imposez un format de sortie.

La mauvaise approche

Écris une fonction pour parser des logs.

L’approche ingénieur

Tu es un développeur Python senior. Écris une fonction qui parse ce format de log nginx. Contraintes, utilise les expressions régulières, gère les erreurs si la ligne est mal formée, et documente la fonction avec des docstrings. Ne renvoie QUE le code, pas d’explications avant ou après.

Le Few-Shot Prompting

La manière la plus efficace d’expliquer un format complexe à un modèle n’est pas de le décrire, mais de le montrer. C’est le concept du few-shot.

Plutôt que d’écrire un long paragraphe d’instructions, donnez des exemples d’entrées et de sorties attendues.

Extrais le sentiment de ces commentaires utilisateurs.

Commentaire : "L'application plante à chaque fois que je clique sur valider."
Sentiment : Négatif

Commentaire : "L'interface est super fluide, beau boulot."
Sentiment : Positif

Commentaire : "Je ne trouve pas le bouton pour exporter en PDF."
Sentiment :

Le modèle va naturellement compléter la suite avec “Neutre” ou “Négatif” sans que vous ayez eu besoin de définir ce qu’est un sentiment.

Chain of Thought (La chaîne de pensée)

C’est une technique redoutable pour les problèmes logiques. Si vous demandez directement la réponse à un problème complexe, le LLM risque de se tromper car il essaie de générer la solution finale d’un coup.

Forcez-le à décomposer son calcul. Le simple fait d’écrire les étapes intermédiaires l’aide à générer les bons tokens suivants.

Résous ce problème de logique.
Règle stricte : Tu dois d'abord écrire ton raisonnement étape par étape avant de donner la réponse finale.

Un serveur peut traiter 100 requêtes par seconde. Nous recevons un pic de 5000 requêtes. Nous avons un load balancer et 3 serveurs actifs. Combien de temps faudra-t-il pour vider la file d'attente ?

Forcer une sortie structurée (JSON)

C’est le nerf de la guerre quand on intègre un LLM dans du code. Vous voulez récupérer des données parsables, pas du texte libre.

Demandez explicitement le format JSON et donnez la structure de clés attendue. Avec les modèles récents (Llama 3, Mistral), la fiabilité est excellente.

Analyse ce texte et retourne les informations extraites.
Tu dois répondre STRICTEMENT au format JSON valide. Aucun texte avant, aucun texte après.
Structure attendue :
{
  "ip_source": "",
  "code_erreur": 0,
  "criticite": "haute|moyenne|basse"
}

Texte à analyser : "192.168.1.42 a renvoyé une erreur 502 à 14h32, l'API est tombée."

Si le modèle s’obstine à rajouter du texte, de nombreux outils (comme les grammaires GBNF dans llama.cpp ou l’option response_format d’Ollama) permettent désormais de forcer la sortie au niveau du moteur d’inférence lui-même.