Prompt

Ce que contient une consigne utile

Un prompt se lit comme une instruction de travail. Il indique qui parle au modèle, ce qu'il doit produire, sur quels éléments s'appuyer et sous quelle forme rendre la réponse. Une consigne qui omet le format attendu produit un texte correct mais inutilisable dans un tableau ; une consigne qui omet le public visé produit un ton inadapté. Les quatre éléments, rôle, tâche, contexte et format, couvrent l'essentiel des besoins courants en entreprise, du compte rendu de réunion à la réponse à un appel d'offres.

Le contexte peut prendre plusieurs formes : un extrait de document collé dans la consigne, un historique de conversation, ou des exemples de réponses attendues. Plus la tâche est spécifique, plus ces éléments pèsent sur le résultat. Une consigne longue n'est pas meilleure par principe : elle doit rester lisible et ne pas mélanger plusieurs demandes. Un prompt qui traite à la fois la synthèse, la traduction et la mise en forme obtient souvent une réponse approximative sur les trois.

Pourquoi le résultat varie

Un modèle ne rejoue pas exactement le même calcul à chaque appel. Le mécanisme de génération introduit une part d'aléatoire, réglable, qui fait varier la formulation et parfois la conclusion. À cela s'ajoutent les évolutions du modèle lui-même : un prompt éprouvé sur une version peut se comporter autrement après une mise à jour du fournisseur, sans que rien n'ait changé dans votre code. La reproductibilité se construit, elle ne va pas de soi, et elle se mesure en rejouant plusieurs fois la même consigne sur les mêmes entrées.

La variabilité tient aussi à la formulation. Deux consignes équivalentes en apparence produisent des sorties différentes, parce que certaines tournures orientent le modèle vers un registre ou une structure. C'est pourquoi il faut tester, conserver les versions qui fonctionnent et noter ce qui a été modifié. Un prompt est un artefact technique : il mérite le même suivi qu'un fragment de code, avec un historique et des cas de non-régression.

Erreurs fréquentes

La première erreur est de demander une réponse fiable sur un sujet que le modèle ne peut pas connaître, comme un tarif interne ou une donnée récente, sans lui fournir la source. La deuxième est d'accumuler les consignes négatives, qui se neutralisent souvent. La troisième est de ne pas prévoir de cas de sortie : que doit répondre le modèle lorsqu'il ne sait pas ? Sans cette clause, il produit une réponse plausible plutôt qu'un refus explicite.

La quatrième est de croire qu'un prompt résoudra un problème de données. Si les documents de référence sont contradictoires ou périmés, la meilleure consigne du monde restera ambiguë. La cinquième est d'oublier la sécurité : un texte saisi par un utilisateur peut contenir des instructions hostiles qui détournent le modèle de sa tâche. Traiter les entrées comme non fiables, et séparer les instructions système du contenu utilisateur, fait partie du travail de cadrage, au même titre que la définition du format de sortie attendu.