Je maintiens un assistant IA intégré à un site WordPress, et je passe donc ma vie à écrire, casser et réécrire des prompts. Voici ce qui marche vraiment, loin des threads LinkedIn.
Un bon prompt est une spec, pas une incantation
Le réflexe du débutant, c'est d'écrire « fais-moi un article sur X ». Le résultat est générique, évidemment. Ce qui change tout : traiter le prompt comme un cahier des charges. Rôle, contexte, contraintes, format de sortie, exemples de ce qui est interdit. Quand j'ai découpé mon prompt système en sections numérotées avec des règles de refus explicites, les réponses hors sujet ont quasiment disparu.
J'ai rassemblé tout ça dans un guide complet du prompt engineering en français : structure d'un prompt, few-shot, gestion du contexte, et les pièges classiques (prompts trop longs, consignes contradictoires, injection).
Tester en local avant de payer une API
Autre leçon : itérer sur un prompt coûte cher quand chaque test part sur une API payante. La solution que j'utilise au quotidien, c'est de prototyper en local avec Ollama. Les petits modèles open source (4 à 8 milliards de paramètres) suffisent largement pour valider une structure de prompt, et ensuite seulement je passe au gros modèle pour la production. Si vous voulez la marche à suivre, notre guide d'Ollama en français couvre l'installation, les modèles utiles et les réglages qui comptent.
Trois règles qui tiennent la route
- Une consigne = une phrase. Si une règle tient en trois phrases, le modèle en suivra la moitié.
- Donnez un exemple de sortie attendue. Ça vaut dix paragraphes d'explications.
- Écrivez les cas de refus. Un assistant qui sait quand dire « je ne sais pas » vaut mieux qu'un assistant qui invente.
Le prompt engineering n'est pas de la magie, c'est de la rédaction technique. Et comme toute rédaction, ça s'apprend en écrivant.
Publié aussi sur wpadminlab.com
