Ingénierie de prompt

Une consigne, quatre éléments

Une consigne utile tient en quatre parties : le rôle attendu, la tâche précise, le contexte disponible, le format de sortie. Le rôle cadre le ton et le niveau de détail ; la tâche énonce le verbe et l'objet ; le contexte apporte les documents ou les contraintes ; le format fixe la structure attendue. Beaucoup d'échecs viennent d'un de ces éléments laissé implicite, que le modèle comble à sa manière. Un bloc manquant se repère en relisant la consigne à froid, avant même de la tester.

Les exemples complètent utilement la description. Deux ou trois cas représentatifs, avec l'entrée et la sortie attendue, valent souvent mieux qu'un paragraphe d'explications. Les contraintes négatives, ce qu'il ne faut pas faire, se formulent aussi explicitement : ne pas inventer de référence, ne pas dépasser telle longueur, signaler l'absence d'information. Une consigne sans interdit laisse au modèle la latitude de combler les vides. Un exemple mal choisi, hors du domaine visé, oriente vers un style qui ne convient pas.

Ce qui distingue une consigne solide

Une bonne consigne se reconnaît à ce qu'elle est testable. Si deux personnes lisent la sortie et ne jugent pas de la même façon, le critère manque. Il faut donc définir ce qu'est une réponse correcte, sur des cas réels, et conserver ces cas pour comparer les versions. L'écriture d'une consigne est un cycle court : rédiger, essayer, observer les erreurs, corriger la formulation, recommencer. Le cycle se mène sur un échantillon stable, sinon la comparaison mesure le hasard autant que l'amélioration.

La stabilité compte autant que la performance ponctuelle. Une consigne qui fonctionne sur un exemple et échoue sur le voisin n'est pas prête. Les formulations trop longues ou trop nombreuses finissent par se contredire, et le modèle en retient une partie arbitraire. Mieux vaut une consigne courte, structurée, avec un exemple, qu'un texte dense où chaque phrase ajoute une exception. Dix lignes avec quatre exemples se corrigent plus facilement que deux pages que personne ne relit. Un exemple suffit souvent, à condition qu'il soit juste et proche du cas réel.

Les limites de l'exercice

Les résultats ne sont pas transférables tels quels. Un modèle réagit différemment d'un autre à la même consigne, et une mise à jour peut modifier le comportement sans prévenir. Une bibliothèque de consignes doit donc être versionnée, associée à un modèle et à une date, avec les cas de test correspondants. Traiter une consigne comme un réglage figé, valable partout et toujours, conduit à des régressions silencieuses. On note la date et la version du modèle comme on le ferait d'une dépendance logicielle.

L'ingénierie de prompt ne compense ni un corpus médiocre, ni une architecture inadaptée, ni l'absence de contrôle. Fournir de bons documents, vérifier les sorties, limiter les actions possibles reste plus déterminant qu'une formule habile. Elle demeure utile, souvent indispensable, mais elle agit à la marge d'un dispositif : c'est le dispositif qui décide du résultat en production. Un dispositif solide combine documents à jour, contrôle des sorties et permissions limitées ; la consigne vient régler les derniers détails.