Prompt Engineering : Techniques et structure (multi-outils)

Les techniques ci-dessous fonctionnent, à des degrés divers, sur la plupart des LLM actuels (Claude, ChatGPT, et autres). Les spécificités de syntaxe (balises XML, formats JSON) sont notées quand elles ne sont pas universelles.

Structure de base d’un bon prompt

1. Rôle/contexte     - qui doit répondre, dans quel cadre
2. Tâche             - ce qui est demandé, précisément
3. Contraintes       - ce qui est exclu, le format attendu
4. Exemple(s)        - optionnel, mais stabilise fortement le résultat

Exemple complet

Tu es un administrateur système Linux expérimenté.

Tâche : explique pourquoi la commande suivante échoue.
systemctl restart nginx renvoie "Job for nginx.service failed"

Contraintes :
- Réponse en français, 5 phrases maximum
- Donne la commande de diagnostic à lancer en premier
- Ne suppose pas une distribution spécifique sauf si précisé

Techniques

Few-shot (exemples avant la tâche)

Convertis ces titres en slugs URL.
"Guide Docker Compose" -> "guide-docker-compose"
"Sécuriser SSH en 5 étapes" -> "securiser-ssh-en-5-etapes"
"Qu'est-ce qu'un VLAN ?" ->

Un ou deux exemples avant la vraie demande réduisent fortement l’ambiguïté sur le format attendu, en particulier pour des tâches de transformation/formatage.

Chain-of-thought (raisonnement explicite)

Résous ce problème étape par étape, en montrant ton raisonnement
avant la réponse finale : si un service consomme 2Go de RAM et
que le serveur a 8Go au total avec 3Go déjà utilisés par d'autres
process, combien reste-t-il de marge après le démarrage du service ?

Utile pour des tâches à plusieurs étapes logiques (calculs, diagnostics multi-causes) – demander le raisonnement AVANT la réponse réduit les erreurs de saut de logique.

Décomposition de tâche complexe

Plutôt qu’un seul prompt massif (« audite ce code, corrige les bugs, ajoute des tests, documente »), séparer en étapes vérifiables individuellement :

1. "Liste les problèmes dans ce code, sans les corriger."
2. (après revue humaine) "Corrige les problèmes 1, 3 et 4 de la liste."
3. "Écris des tests pour la fonction corrigée."

Chaque étape reste vérifiable indépendamment – un prompt unique qui enchaîne tout rend difficile de savoir où une erreur a été introduite.

Négatif explicite (ce qu’il ne faut PAS faire)

N'utilise pas de bibliothèque externe. Reste en bash pur (pas
de Python, pas de Perl). Ne propose pas d'alternative si la
contrainte semble limitante - travaille dans le cadre donné.

Les modèles suivent mieux une contrainte négative explicite qu’une contrainte implicite déduite du contexte.

Demander l’auto-critique

Relis ta réponse. Y a-t-il une hypothèse non vérifiée ou un
raccourci que tu as pris sans le signaler ?

Pièges courants

Prompt trop vague. « Améliore ce script » donne un résultat générique. « Améliore la gestion d’erreur de ce script : chaque commande qui peut échouer doit logger l’erreur et sortir avec un code non-zéro » donne un résultat exploitable.

Mélanger plusieurs demandes indépendantes dans un seul prompt. Le modèle peut en oublier une ou mal prioriser. Une demande par prompt, ou une liste numérotée explicite si plusieurs sont nécessaires.

Ne pas donner le contexte technique précis. Version de langage/framework, contraintes d’environnement, outils disponibles – l’absence de ces détails produit une réponse générique qu’il faut ensuite adapter à la main.

Faire confiance à une réponse qui « a l’air correcte » sans vérifier. Un modèle peut produire du code syntaxiquement valide qui ne fait pas exactement ce qui est demandé, ou une explication plausible mais factuellement fausse. La vérification reste de la responsabilité de qui utilise la réponse.

Répéter tout le contexte à chaque message dans une longue conversation. La plupart des outils gardent l’historique – reformuler tout à chaque tour dilue le signal plus qu’il n’aide.

Comparaison rapide des approches selon l’outil

Les principes de structuration (contexte, tâche, contraintes, exemples) restent valables sur les deux ; les détails de syntaxe API changent.