Polarys
Prompt engineering : les bases/Quand la réponse ne convient pas

Quand la réponse ne convient pas

Diagnostiquer une demande qui échoue

Reformuler au hasard ne mène nulle part

Face à une réponse décevante, le réflexe est de réécrire la demande en entier, différemment. Parfois ça marche, et l'on ne sait pas pourquoi, donc on ne peut pas le refaire.

Une demande qui échoue échoue pour l'une de quatre raisons, et chacune a une correction distincte. Les distinguer prend trente secondes et remplace une demi-heure de tâtonnements.

Les quatre causes

La tâche est ambiguë. Le modèle a répondu à une question voisine de la vôtre. Signe caractéristique : la réponse est correcte mais hors sujet. Correction : dire ce que vous voulez obtenir, et à quoi cela servira.

Le format n'est pas dit. Vous vouliez un tableau, vous recevez trois paragraphes. Signe : le fond est bon, la forme est inutilisable. Correction : décrire la forme attendue, colonne par colonne s'il le faut, et donner un exemple d'une ligne.

Le contexte manque. Le modèle a inventé pour combler. Signe : des détails plausibles que vous n'avez jamais fournis. Correction : fournir la matière, et interdire d'inventer le reste.

La tâche est trop grosse. La réponse est superficielle, ou elle traite bien le début et bâcle la fin. Signe : la qualité décroît au fil de la réponse. Correction : découper, ce que traite la leçon suivante.

Le test qui isole la cause

Ne changez qu'une chose à la fois, et gardez la version précédente. C'est la même discipline que le dépannage : deux modifications simultanées vous privent de savoir laquelle a agi.

En pratique : gardez la demande dans un fichier, numérotez vos essais, notez en une ligne ce qui a changé et si c'était mieux. Trois essais suffisent presque toujours, à condition qu'ils soient différents et non trois reformulations du même flou.

Ce qu'il ne sert à rien de faire

Insister. Redemander la même chose en majuscules ou en ajoutant « c'est important » ne change presque rien, sauf sur le ton de la réponse.

Empiler les consignes. Une demande de trente contraintes produit une réponse qui en respecte quelques-unes, sans que vous puissiez prévoir lesquelles. Au-delà de cinq ou six consignes fortes, découpez.

Changer d'outil. C'est le dernier réflexe utile, pas le premier. Si la demande est ambiguë, elle l'est pour tous les modèles.

Un cas concret

Demande : « Fais-moi un point sur la sécurité de notre parc informatique. » Réponse : trois pages de généralités justes et sans valeur.

Diagnostic : tâche ambiguë et contexte absent, pas un problème de modèle.

Demande corrigée : « Voici la liste de nos postes, leurs versions de système et la date du dernier correctif appliqué. Repère les machines qui ne reçoivent plus de mises à jour de sécurité, classe-les par urgence, et n'ajoute aucune recommandation générale. »

Même outil, même journée, résultat exploitable.

À retenir

Quatre causes, quatre corrections : ambiguïté, format, contexte, taille. Un changement à la fois, trois essais notés. Insister ne corrige rien, découper corrige beaucoup.

Quiz de validation

Quiz - 3 questions

1. La réponse est juste mais totalement hors sujet. Quelle cause suspecter d'abord ?

2. La réponse contient des détails précis que vous n'avez jamais fournis. Que signale ce symptôme ?

3. Pourquoi ne changer qu'une chose à la fois entre deux essais ?

Suis ta progression

Crée un compte gratuit pour suivre ta progression et accéder à toutes les leçons.