Écrire un bon prompt : méthode et exemples

Un prompt est la demande que tu adresses à un modèle d'IA générative : la consigne, le contexte et les données qu'il doit traiter. Le prompt engineering, ou ingénierie de prompt, est la méthode qui consiste à écrire puis améliorer cette demande pour obtenir une réponse juste, au bon format, sans dix allers-retours. Ce chapitre te donne une structure en six éléments, des prompts complets pour le SLAM et le SISR, et les erreurs à éviter.

Les six éléments d'un bon prompt

Un modèle ne connaît ni ton entreprise, ni tes versions, ni ce que tu as déjà essayé. Tout ce qu'il ne lit pas dans le prompt, il le devine, et il devine la situation la plus courante, pas la tienne.

Ajoute un critère de réussite quand c'est possible : « Le script doit pouvoir être relancé sans créer de doublons. » Il guide le modèle et te donne de quoi tester la réponse.

Un prompt SISR, avant et après

Avant :

Fais-moi un script pour créer des utilisateurs dans l'AD.

L'assistant va inventer un format de fichier, une OU, peut-être écrire un mot de passe en clair dans le script, et ne gérera pas les comptes qui existent déjà.

Après :

Contexte : je suis technicien au service informatique d'une PME. Domaine Active Directory
ad.sorbier.example, contrôleur de domaine sous Windows Server 2025, PowerShell 5.1 avec le
module ActiveDirectory.

Tâche : écris un script PowerShell qui crée les comptes des nouveaux arrivants à partir d'un
fichier CSV.

Données : le fichier arrivees.csv, séparateur point-virgule, encodé en UTF-8 :
Prenom;Nom;Service;Fonction
Paul;Martin;Comptabilite;Comptable

Contraintes :
- login = initiale du prénom + nom, en minuscules, sans accents ni espaces ;
- compte créé dans OU=<Service>,OU=Utilisateurs,OU=Sorbier,DC=ad,DC=sorbier,DC=example ;
- si le login existe déjà, ne rien créer et afficher un avertissement ;
- mot de passe initial aléatoire de 16 caractères, à changer à la première connexion,
  jamais écrit en clair dans le script ;
- le script doit accepter -WhatIf pour un essai à blanc.

Format : le script complet et commenté, puis une explication de chaque bloc en une phrase,
puis la liste des droits AD nécessaires pour l'exécuter.

La réponse sera plus longue à lire, mais elle correspondra à ton domaine, à ton fichier et à tes règles. Compare-la au script du cours Windows Server : c'est un bon exercice de relecture.

Un prompt SLAM, avant et après

Avant :

Donne-moi la requête SQL pour avoir les tickets ouverts par service.

L'assistant va inventer des noms de tables et de colonnes. La requête aura l'air juste et échouera sur ta base.

Après :

Contexte : base MySQL 8.4 de gestion de parc. Schéma utile :
service (id_service, code, libelle, etage)
employe (id_employe, nom, prenom, email, telephone, date_embauche, #id_service, #id_responsable)
ticket (id_ticket, titre, date_ouverture, date_cloture, priorite, statut, #id_demandeur, #id_poste)
ticket.id_demandeur référence employe.id_employe. statut vaut 'ouvert', 'en_cours' ou 'resolu'.

Tâche : écris la requête qui donne, pour chaque service, le nombre de tickets non résolus
de ses employés, y compris les services qui n'en ont aucun.

Contraintes : utilise uniquement les tables et colonnes ci-dessus. Pas de sous-requête.

Format : la requête seule, puis une phrase pour chaque jointure, puis le piège à éviter
avec COUNT.

Le schéma fourni empêche l'invention de colonnes, et « y compris les services qui n'en ont aucun » oriente vers une jointure externe. Tu reconnais la base parc du cours SQL : vérifie la requête proposée en l'exécutant.

Le prompt système d'une application

Quand tu intègres un modèle dans une application (chapitre 7), tu écris un prompt système : des consignes envoyées avant chaque conversation, que l'utilisateur ne voit pas. Il fixe le rôle, le périmètre, le ton et le format.

Tu es l'assistant du support informatique de Sorbier Logistique. Tu aides les salariés,
qui ne sont pas informaticiens, à résoudre les problèmes courants de leur poste de travail.

Règles :
- Réponds en français, en cinq étapes au plus, avec des phrases courtes.
- Ne donne que des manipulations sans risque pour un utilisateur : redémarrer, vérifier
  un câble, vider la file d'impression. Jamais de commande d'administration.
- Si le problème demande un technicien, ou si tu n'es pas sûr, dis-le et propose
  d'ouvrir un ticket.
- Ne demande jamais de mot de passe et n'en accepte aucun.
- Si la question ne concerne pas l'informatique du poste de travail, réponds que tu ne
  peux pas aider sur ce sujet.

Donner des exemples : le few-shot

Sans exemple, on parle de prompt zero-shot : le modèle comprend la tâche à partir de la consigne seule. Avec quelques exemples, on parle de few-shot : le modèle imite leur forme. C'est la méthode la plus fiable pour obtenir un format strict, comme une classification que ton code va lire.

Classe chaque demande d'assistance. Réponds uniquement par un objet JSON avec deux clés :
"categorie" (poste, imprimante, reseau, compte, logiciel) et "priorite" (basse, normale,
haute, critique).

Demande : Je n'arrive plus à me connecter à ma session depuis ce matin.
Réponse : {"categorie": "compte", "priorite": "haute"}

Demande : L'imprimante du 1er étage imprime des pages blanches.
Réponse : {"categorie": "imprimante", "priorite": "normale"}

Demande : Plus personne n'a Internet à l'entrepôt de Mâcon.
Réponse : {"categorie": "reseau", "priorite": "critique"}

Demande : Mon écran clignote quand je déplace une fenêtre.
Réponse :

Choisis des exemples variés, qui couvrent les cas limites, et vérifie que ton code accepte une réponse mal formée : un modèle peut ajouter une phrase avant le JSON. Les API proposent aussi des sorties structurées qui forcent le respect d'un schéma JSON ; avec Ollama, c'est le champ format.

Structurer un long prompt

Quand tu fournis un long document, sépare clairement les données des consignes, par exemple avec des balises :

<procedure>
(le texte de la procédure de sauvegarde, 3 pages)
</procedure>

<journal>
(les 40 dernières lignes du journal de la sauvegarde de cette nuit)
</journal>

Compare le journal à la procédure. Liste les étapes de la procédure qui n'apparaissent pas
dans le journal, avec pour chacune la ligne de la procédure concernée.

Mets les documents d'abord et la question à la fin, comme dans cet exemple : les modèles traitent mieux une longue entrée quand la demande arrive après les données. Les balises ont un second intérêt : elles aident le modèle à traiter le contenu d'un document comme des données, pas comme des consignes. C'est une protection partielle contre l'injection de prompt, pas une garantie.

Faire réfléchir, faire poser des questions

Trois formules changent souvent la qualité de la réponse :

• « Avant de répondre, pose-moi les questions qui te manquent. » Le modèle liste ce qu'il aurait deviné : la version, le nombre d'utilisateurs, la contrainte de budget.
• « Propose deux solutions et compare-les sur la sécurité, la complexité et le coût. » Tu évites de prendre la première idée pour la seule.
• « Liste les hypothèses que tu fais. » Les erreurs se cachent souvent dans une hypothèse fausse : « je suppose que le serveur est sous Debian ».

Avec un modèle de raisonnement (chapitre 3), inutile d'écrire « réfléchis étape par étape » : il le fait déjà. Décris plutôt précisément le problème et le résultat attendu.

Itérer

La première réponse est un brouillon. Quand elle ne convient pas, demande-toi quel élément manquait au prompt plutôt que de répéter « non, refais » :

Au bout d'une dizaine d'échanges qui patinent, repars d'une conversation neuve avec un prompt complet : l'historique encombré gêne plus qu'il n'aide. Garde les prompts qui fonctionnent dans un fichier prompts.md de ton dépôt : ce sont des outils, comme des scripts.

Les erreurs classiques

• Plusieurs tâches dans un seul prompt : le modèle en traite une bien et bâcle les autres.
• Des contraintes contradictoires : « explique en détail, en trois lignes ».
• Des données sensibles : un mot de passe, un fichier de clients, une configuration réelle (chapitre 12).
• Une prémisse fausse dans la question (chapitre 3).
• « Fais comme un expert » sans dire ce qu'un expert ferait ici : un rôle seul n'apporte presque rien, le contexte et les contraintes font le travail.

Exercices

Contexte : application web en PHP 8.4, connexion à MySQL 8.4 avec PDO. Les mots de passe
sont enregistrés avec password_hash() dans la colonne mdp_hash (VARCHAR(255)) de la table
utilisateur.

Problème : avec un identifiant et un mot de passe justes, la page affiche « Identifiants
incorrects ». Aucun message d'erreur PHP.

Données : voici le code du traitement du formulaire (login.php) :
(le code)

Tâche : trouve la cause la plus probable et propose la correction.

Contraintes : garde la requête préparée ; n'affiche jamais si c'est l'identifiant ou le
mot de passe qui est faux.

Format : la cause en une phrase, la ou les lignes corrigées, puis comment vérifier la
correction.

Classe l'objet de chaque courriel envoyé au support informatique en "demande",
"incident" ou "autre". Réponds uniquement par un de ces trois mots, en minuscules,
sans ponctuation.

Objet : Création d'un compte pour le stagiaire de lundi
Type : demande

Objet : Le VPN coupe toutes les dix minutes
Type : incident

Objet : Pot de départ de Nadia vendredi
Type : autre

Objet : {objet du courriel à classer}
Type :