Prompting efficace et cas d'usage professionnels

Un prompt vague produit une réponse générique. Un prompt efficace combine en général cinq éléments : le rôle ou la posture attendue de l'assistant (par exemple relecteur juridique, professeur de mathématiques), le contexte pertinent (à qui s'adresse la réponse, dans quel cadre), la tâche précise à accomplir, le format de sortie souhaité (liste, tableau, email de trois paragraphes) et les contraintes à respecter (longueur, ton, éléments à éviter). Formuler ces cinq points avant d'envoyer une demande réduit fortement le nombre d'allers-retours nécessaires pour obtenir un résultat exploitable. Un moyen simple de vérifier qu'un prompt est complet consiste à se demander si une personne extérieure au projet, disposant du même prompt mais sans connaître le contexte, produirait le résultat attendu ; si la réponse est non, un des cinq éléments manque probablement.

Dans l'API comme dans un GPT personnalisé, une distinction existe entre le prompt système, qui définit le comportement général et durable de l'assistant pour toute la conversation (son rôle, ses limites, son ton), et les messages utilisateur, qui portent la demande ponctuelle. Dans ChatGPT grand public, les instructions personnalisées jouent un rôle proche du prompt système : elles s'appliquent à toutes les conversations sans avoir à les répéter à chaque message. Bien séparer ce qui relève d'une consigne permanente de ce qui relève d'une demande ponctuelle évite d'avoir à réexpliquer le contexte à chaque échange. Dans une application construite sur l'API, il est possible d'envoyer plusieurs messages système successifs ou de les combiner avec des messages développeur pour hiérarchiser des consignes, par exemple des règles de conformité imposées par l'entreprise qui priment sur les préférences exprimées par l'utilisateur final.

Fournir un ou plusieurs exemples de la sortie attendue dans le prompt, une technique appelée few-shot prompting, améliore nettement la constance du format et du style produits par le modèle, en particulier pour des tâches répétitives comme la catégorisation d'emails, la rédaction de fiches produit ou l'extraction d'informations structurées. À l'inverse, un prompt sans exemple (zero-shot) reste souvent suffisant pour des tâches simples et courantes, où ajouter des exemples n'apporte qu'un gain marginal pour un coût de rédaction plus élevé. Le choix des exemples compte autant que leur nombre : des exemples trop proches les uns des autres risquent de biaiser le modèle vers un seul type de cas, alors que des exemples variés, couvrant les situations limites qu'on souhaite voir bien traitées, donnent une meilleure généralisation sur des entrées nouvelles.

Demander explicitement au modèle de raisonner étape par étape avant de donner sa réponse finale, une approche connue sous le nom de chain of thought, améliore la fiabilité sur les problèmes qui demandent plusieurs étapes de logique, de calcul ou de comparaison. Sur une tâche complexe, il est souvent plus efficace de la décomposer soi-même en sous-tâches successives (d'abord extraire les données, puis les analyser, puis rédiger la synthèse) plutôt que de tout demander en un seul prompt monolithique. Les modèles de raisonnement de la série o appliquent une version plus poussée de ce principe de façon automatique, en interne, avant même de commencer à répondre. Sur une tâche de vérification de calcul financier par exemple, demander explicitement au modèle de détailler chaque étape intermédiaire avant de donner le résultat final permet de repérer plus facilement une erreur de raisonnement, alors qu'une réponse directe sans étapes intermédiaires ne laisse rien à vérifier en cas d'erreur.

En rédaction, un prompt précisant l'audience, le ton et la longueur transforme un brouillon générique en texte quasi publiable, qu'il s'agisse d'un compte rendu de réunion, d'une fiche de poste ou d'un email de relance client. En analyse, coupler un prompt bien cadré avec Data Analysis permet d'explorer un jeu de données sans compétence de programmation. En code, décrire précisément le comportement attendu, le langage et les contraintes de performance donne de meilleurs résultats que de demander une implémentation en une phrase. En support client, un prompt qui fixe des garde-fous clairs (ton, sujets autorisés, cas où transférer à un humain) réduit le risque de réponses inappropriées face à des demandes inattendues des utilisateurs. Dans tous ces cas, la qualité du résultat dépend davantage de la clarté du cadrage donné au modèle que de la sophistication du prompt : une consigne courte mais précise sur l'audience, le format et les limites à respecter surpasse souvent un prompt long mais vague sur ce qui est réellement attendu.