01 — Aller plus loin
Des techniques plus avancées
Découvrez les techniques avancées de prompting.
Zero shot, one shot et few shot
Un seul exemple suffit à transmettre un format. Il en faut plusieurs pour transmettre une règle dont l'IA n'a pas connaissance.
Le raisonnement guidé
Le détail intermédiaire donne une prise concrète pour repérer une erreur de raisonnement avant qu'elle n'atteigne la conclusion.
Les gabarits réutilisables
Seuls les éléments entre crochets changent d'une tâche à l'autre, le reste de la structure reste identique et déjà validé par l'équipe.
Le prompting par rôle
Le rôle attribué au modèle oriente directement les problèmes qu'il choisit de remonter en premier.
L'enchaînement de prompts
Chaque étape reste courte et vérifiable avant de passer à la suivante, ce qui limite les dérives d'une tâche qui aurait été traitée trop vite en un seul bloc.
L'affinage itératif
Chaque écart se corrige au moment où on le repère, sans avoir à tout réécrire.
Le méta-prompting
La liste des informations manquantes est souvent mise en avant.
Prompt système et prompt utilisateur
Un prompt système bien écrit évite de répéter les mêmes contraintes vingt fois par jour. Il rend aussi les résultats plus homogènes entre les membres de l'équipe.
La cohérence par recoupement
Si les deux formulations pointent vers la même hypothèse, la piste mérite d'être creusée en priorité. Si elles divergent, la prudence s'impose avant de conclure.
La page Exemples de prompting met en pratique ces techniques.
02 — Vérifier avant d'utiliser
Évaluer une réponse générée
Quatre critères à passer en revue avant de considérer un résultat généré comme fiable. Sur mobile, swipez la carte pour passer à la suivante.
La pertinence face à la demande
La réponse doit répondre exactement à ce qui a été demandé, ni plus ni moins. Un cas de test hors sujet ou une réponse qui traite un problème voisin plutôt que celui posé doit être écarté ou reformulé.
La couverture attendue
Une bonne réponse couvre les cas nominaux, mais aussi les cas limites et les cas d'erreur si la demande les évoquait. Une couverture qui s'arrête aux scénarios évidents signale souvent un prompt à préciser plutôt qu'un modèle défaillant.
L'exactitude technique
Un script, une donnée ou une règle métier générée doit être vérifiée par rapport à la documentation ou au comportement réel du système. Une réponse qui semble "juste" à la lecture peut contenir une hallucination difficile à repérer sans cette vérification.
Le respect du format demandé
Un tableau attendu qui revient sous forme de texte libre ? Une terminologie qui s'écarte de celle de l'équipe ? Cela montre que le prompt nécessiterait davantage de précision sur le format de sortie souhaité.
Comparer deux réponses obtenues à partir de deux formulations différentes de la même tâche aide aussi à apprendre ce qui fonctionne. Si la version affinée d'un prompt produit un résultat nettement meilleur, cette formulation mérite d'être conservée pour la prochaine fois.
03 — Mettre des chiffres dessus
Métriques pour évaluer les résultats de l'IA
Les quatre critères précédents se lisent à l'œil. Ces métriques mesurent le résultat obtenu sur une tâche de test précise.
| Métrique | Ce qu'elle mesure | Tâche de test | Ce que ça donne |
|---|---|---|---|
| Exactitude | L'exactitude globale du résultat généré, comparé à des cas de test écrits par des personnes expérimentées, à des exigences ou à une autre référence. On regarde ici si l'ensemble produit colle à cette référence. | Générer les cas de test du parcours de connexion à partir des exigences | Le parcours de connexion compte 12 exigences. Les cas générés en couvrent 10. Le verrouillage du compte après cinq tentatives et le mot de passe expiré ne sont traités par aucun cas. L'ensemble généré équivaut donc à 83% de la base de test. |
| Précision | La justesse du résultat généré par rapport à un objectif précis. On regarde ici ce que le modèle propose et qui ne sert à rien. | Générer des cas de test destinés à détecter les anomalies de calcul du panier | 12 cas sont générés, 9 déclenchent une anomalie réelle sur la version défectueuse. Les 3 autres passent au vert quoi qu'il arrive. La précision est de 75%. |
| Rappel | La capacité du modèle à retrouver tous les éléments pertinents d'un ensemble. On regarde ici ce qui manque. | Couvrir les partitions d'équivalence d'un champ « âge » compris entre 18 et 120 | Six partitions valides et invalides existent. Le modèle en couvre quatre et oublie la valeur vide ainsi que le format non numérique. Le rappel est de 4 sur 6. |
| Pertinence et adéquation contextuelle | Le fait que le résultat généré soit applicable et adapté au contexte du projet, base de test et vocabulaire métier compris. | Rédiger les cas d'acceptation d'une user story de remboursement | Le modèle propose des cas de remboursement partiel alors que la story ne couvre que le remboursement total. Il parle aussi de « commande annulée » là où le métier dit « commande rétractée ». |
| Diversité | La variété des entrées et des scénarios couverts, sans répétition d'un même cas sous plusieurs formulations. | Générer un jeu de tests exploratoires pour un formulaire de recherche | Sur 15 cas générés, 6 se contentent de changer le mot recherché. Les caractères accentués, la recherche vide et la saisie très longue ne sont jamais testés. |
| Taux de réussite des exécutions | La proportion de cas ou de scripts générés qui s'exécutent réellement, sans erreur de syntaxe ni problème de format. | Générer des scripts Playwright pour la suite de non-régression | Sur 10 scripts générés, 7 se lancent du premier coup. Deux échouent sur un sélecteur inventé, un sur un import manquant. Le taux est de 70%. |
| Efficience temporelle | Le temps gagné par rapport à la réalisation manuelle de la même tâche de test. | Produire le rapport de campagne à partir des résultats d'exécution | Le rapport rédigé à la main demande 50 minutes. Généré puis relu et corrigé, il en demande 20. Le gain n'est réel que si la relecture reste courte. |
Une métrique se mesure toujours sur une tâche de test donnée. La même consigne peut très bien obtenir un bon score en exactitude sur la génération de cas de test et un mauvais score en diversité. La comparaison ne vaut donc qu'entre deux résultats obtenus sur la même tâche.
Une IA générative peut rendre deux réponses différentes à une même demande. Un score relevé sur une seule exécution ne veut donc pas dire grand chose. Il faut relancer la tâche plusieurs fois et regarder la moyenne obtenue avant de conclure. Baisser la température réduit cette variation sans la supprimer. La mesure répétée reste donc nécessaire. Elle se fait par une revue manuelle, ou de façon automatisée en comparant le résultat à une référence préparée à l'avance.
04 — Capitaliser en équipe
Construire une bibliothèque de prompts
Un bon prompt mérite d'être conservé, partagé et évoluer avec le projet.
Écrire et faire relire un premier prompt
Une personne rédige un prompt pour une tâche récurrente de l'équipe, puis le fait tester par une ou deux autres personnes sur des cas réels avant de le considérer comme fiable.
Intégrer le prompt validé dans une bibliothèque commune
Le prompt validé rejoint un espace partagé accessible à toute l'équipe. On y ajoute une courte note qui précise pour quelle tâche il a été pensé et sur quel type de projet il a été testé.
Adapter le gabarit à la terminologie du projet
Un gabarit de prompt trouvé en ligne ou repris d'un autre projet doit être ajusté au vocabulaire métier et aux conventions déjà en place dans l'équipe.
Traiter le prompt comme un artefact de test
Un prompt utilisé en routine mérite le même traitement qu'un script de test, c'est-à-dire être versionné, daté, documenté et relu en revue de code. Un prompt qui fonctionne bien aujourd'hui peut devenir moins pertinent quand le projet évolue. Garder une trace des versions successives permet de comprendre pourquoi un ajustement a été fait et de revenir en arrière si besoin.
05 — Ce qui coince souvent
Pièges de formulation courants
Quatre formulations à éviter, avec une reformulation qui fonctionne mieux. Sur mobile, swipez la carte pour passer à la suivante.
Le prompt trop vague
Le prompt qui mélange plusieurs tâches
Le prompt sur contraint
Le prompt qui suppose un contexte manquant
Le prompt trop vague
Le prompt qui mélange plusieurs tâches
Le prompt sur contraint
Le prompt qui suppose un contexte manquant
A retenir
Ce qu'il faut retenir
Le prompt se travaille comme un cas de test
Une formulation vague donne un résultat vague. Préciser l'angle, le format et le contexte attendu change directement la qualité de la réponse obtenue.
Ce qui vaut pour tous les échanges remonte dans le prompt système
Rôle, ton, format et interdits se posent une fois pour toutes. Le prompt utilisateur ne porte alors que la demande du moment. Les résultats deviennent plus homogènes au sein de l'équipe.
Chaque réponse s'évalue avant d'être utilisée
La pertinence, la couverture, l'exactitude technique et le format respecté restent les critères à vérifier avant de considérer un résultat généré comme fiable.
Le meilleur prompt se construit en plusieurs essais
Peu de prompts sont parfaits du premier coup. Relire puis préciser au modèle ce qui manque.
Un bon prompt mérite d'être partagé
Une formulation qui fonctionne bien pour une tâche récurrente mérite de rejoindre une bibliothèque commune à l'équipe.
Mise en pratique
Testez votre compréhension
Une sélection de questions basées sur ce que vous venez de lire.
Quelle est la différence entre un prompt zero shot et un prompt few shot ?
Une équipe veut que ses cas de test générés suivent une convention de nommage que personne n'a jamais formalisée par écrit. Quelle approche a le plus de chances de fonctionner ?
Qu'est-ce que le méta-prompting ?
Une équipe configure un assistant partagé pour générer ses cas de test. Où faut-il placer la consigne « répondre au format tableau, avec la terminologie ISTQB » ?
Une personne ajoute « Tu es expert en sécurité applicative » devant sa demande, puis considère la couverture sécurité obtenue comme fiable. Quel est le problème ?
À quoi sert de demander à un modèle de détailler son raisonnement avant sa réponse finale ?
Pourquoi préférer une boucle de prompting itératif à un unique prompt très détaillé ?
Une personne demande la liste des cas de test d'un formulaire de paiement, puis, à partir de cette liste, demande le script du premier cas. De quelle technique s'agit-il ?
Quel est l'intérêt d'un gabarit de prompt réutilisable pour une équipe ?
Une réponse générée est bien structurée, au bon format, et couvre les cas demandés. Que reste-t-il à vérifier avant de l'utiliser ?
Douze cas de test sont générés pour détecter les anomalies de calcul du panier. Neuf déclenchent une anomalie réelle, les trois autres passent au vert quoi qu'il arrive. Quelle métrique ce constat mesure-t-il ?
Que risque un prompt qui mélange plusieurs tâches en une seule demande ?
Une personne écrit à un assistant « corrige ce bug », sans rien ajouter. Pourquoi cette demande est-elle difficile à exploiter ?
Pourquoi garder une trace des versions successives d'un prompt partagé en équipe ?
À savoir
La Minute QA est une aide à la compréhension, pas une formation professionnelle : certains points ne peuvent pas être couverts ici. Pensez à suivre une formation certifiante et à consulter le syllabus officiel ISTQB pour une préparation complète.
Pour aller plus loin