Un prompt IA fiable pour le test logiciel précise sept éléments : le rôle attendu, le contexte du système, la tâche exacte, les entrées autorisées, les contraintes, le format de sortie et les critères de qualité. Cette structure réduit les interprétations silencieuses et rend le résultat plus facile à contrôler. Elle ne garantit pas une réponse juste : les exigences sources, la couverture et les résultats générés doivent toujours être vérifiés.
Qu’est-ce qu’un prompt de test logiciel ?
Un prompt de test logiciel désigne l’ensemble des instructions, données et contraintes fournies à un modèle d’IA pour réaliser une tâche QA délimitée. Il peut servir à extraire les règles d’une user story, proposer des conditions de test, transformer des critères en Gherkin, classer des anomalies ou préparer un compte rendu.
Un bon prompt n’est pas nécessairement long. Il contient ce qui permet au modèle de distinguer :
- les faits qu’il peut utiliser ;
- les opérations qu’il doit effectuer ;
- les décisions qu’il n’a pas le droit de prendre ;
- la forme du livrable ;
- les vérifications qui permettront de l’accepter ou de le rejeter.
Le programme ISTQB CT-GenAI v1.1 inclut le prompt engineering, l’évaluation des sorties et les risques de l’IA générative. La structure proposée ici est un gabarit opérationnel inspiré de ces préoccupations ; elle ne constitue pas une reproduction du syllabus ni une norme.
Les 7 éléments d’un prompt IA robuste pour la QA
1. Rôle : qui doit agir et avec quelle responsabilité ?
Le rôle oriente le niveau de vocabulaire et le type de contrôle attendu. « Agis comme un test analyst » est toutefois trop vague s’il n’est pas accompagné d’une responsabilité concrète.
Préférez :
Tu assistes un test analyst chargé d’identifier les conditions de test d’un parcours de remboursement. Tu proposes un brouillon ; tu ne décides aucune règle métier absente des sources.
Le rôle ne confère ni expérience réelle ni autorité. Il cadre le comportement textuel du modèle.
2. Contexte : pour quel produit, risque et public ?
Le contexte explique pourquoi la tâche existe. Indiquez le type de système, l’étape du cycle, le public du livrable et les risques qui influencent la couverture.
Exemple :
L’application permet à un client français de demander un remboursement après annulation. Le livrable sera relu par le Product Owner et utilisé pour préparer une recette fonctionnelle. Aucun paiement réel ne sera exécuté.
Un contexte utile évite les détails décoratifs. Il doit aider à interpréter les entrées ou les critères de qualité.
3. Instruction : quelle tâche précise faut-il accomplir ?
Utilisez un verbe observable : extraire, comparer, classer, transformer, générer ou critiquer. Une instruction ne doit idéalement porter que sur une étape vérifiable.
Exemple :
Extrais les règles explicites, les termes ambigus, les contradictions et les dépendances. Ne rédige pas encore de critères d’acceptation.
« Analyse ce document » ne définit ni l’opération, ni le résultat attendu, ni la limite de la tâche.
4. Entrées : quelles sources font autorité ?
Nommez chaque entrée et son rôle :
STORY: besoin utilisateur, potentiellement incomplet ;CRITERES_VALIDES: règles approuvées qui peuvent déterminer un résultat attendu ;GLOSSAIRE: définition des termes métier ;MAQUETTE: représentation visuelle, informative sauf mention contraire ;CONVENTIONS_QA: règles de nommage et de format.
Lorsque deux sources ont des niveaux d’autorité différents, dites laquelle prévaut ou demandez de signaler le conflit. Sans cette règle, le modèle peut fusionner deux formulations incompatibles.
5. Contraintes : que ne faut-il pas faire ?
Les contraintes les plus utiles portent sur les erreurs coûteuses :
- ne pas inventer de règle, de donnée ou de dépendance ;
- ne pas utiliser de connaissance externe non fournie ;
- marquer « indéterminé » si la source ne permet pas de conclure ;
- ne pas reproduire de donnée personnelle ;
- ne pas appeler « validé » un contenu encore en revue ;
- ne pas produire de code lorsque la tâche porte sur l’analyse.
Une liste interminable de prohibitions peut devenir difficile à suivre. Conservez les limites qui modifient réellement l’acceptation de la sortie.
6. Format : comment restituer le résultat ?
Le format doit rendre la revue rapide. Un tableau peut imposer des colonnes telles que type, élément, source, impact test, question et statut.
Pour une intégration automatisée, un schéma JSON strict peut être préférable. Pour une revue métier, un tableau Markdown lisible est souvent plus efficace. Ne demandez un format structuré que si le consommateur — humain ou système — en a besoin.
7. Critères : comment juger la qualité ?
Les critères transforment une préférence vague en contrôle observable. Par exemple :
- chaque fait comporte une référence à la source ;
- aucune hypothèse n’apparaît dans la colonne « règle » ;
- chaque ambiguïté conduit à une question répondable ;
- les doublons sont fusionnés avec justification ;
- la sortie respecte exactement les colonnes attendues ;
- les critères de test sont formulés en résultats observables.
Un modèle peut aussi effectuer une vérification finale, mais cette auto-vérification ne remplace pas la revue du testeur.
Modèle de prompt QA prêt à adapter
Le gabarit suivant est volontairement générique. Les libellés entre crochets doivent être remplacés ; les sources doivent être placées dans des blocs clairement délimités.
RÔLE
Tu assistes [rôle QA] pour [responsabilité]. Tu produis un brouillon soumis à validation humaine.
CONTEXTE
Système : [produit et parcours]
Phase : [analyse / conception / implémentation / reporting]
Public du livrable : [testeur / Product Owner / développeur]
Risque prioritaire : [risque]
TÂCHE
[Un verbe précis + un résultat délimité]
ENTRÉES AUTORISÉES
<SOURCE_1 id="S1" autorite="validée">
[contenu]
</SOURCE_1>
<SOURCE_2 id="S2" autorite="informative">
[contenu]
</SOURCE_2>
CONTRAINTES
- Utilise uniquement les sources fournies.
- N’invente aucune règle manquante.
- Distingue fait, ambiguïté, contradiction et hypothèse.
- Indique « indéterminé » quand les sources ne permettent pas de conclure.
- Ne produis pas [livrable hors périmètre].
FORMAT DE SORTIE
[tableau, JSON, Gherkin ou autre schéma exact]
CRITÈRES D’ACCEPTATION DE LA SORTIE
- Chaque affirmation cite S1 ou S2 et, si possible, le passage concerné.
- Aucune règle ne provient d’une source informative seule.
- Chaque question est liée à un impact de test.
- Termine par la liste des contrôles humains restant à effectuer.
Prompt système et prompt utilisateur : quelle différence ?
Un prompt système — ou une instruction de niveau équivalent selon l’outil — fixe des règles durables, tandis qu’un prompt utilisateur porte la tâche et les données du moment. Les noms et la hiérarchie exacte varient selon les plateformes ; il faut vérifier leur documentation.
Dans l’API OpenAI, par exemple, les messages developer ou system ont une priorité supérieure aux messages user, comme l’indique la référence officielle des entrées de la Responses API. Cette règle d’un fournisseur ne doit pas être extrapolée sans vérification à tous les outils.
| Niveau | Contenu recommandé | Fréquence de changement | Exemple QA |
|---|---|---|---|
| Système ou développeur | rôle durable, politique, limites, format général | faible | ne jamais transformer une hypothèse en règle validée |
| Utilisateur | tâche courante, sources, critères spécifiques | élevée | analyser la story RBT-42 et produire le tableau demandé |
| Référence externe | exigences, glossaire, exemples, captures | selon le projet | critères d’acceptation approuvés |
Une instruction utilisateur ne doit pas pouvoir contourner une politique durable. À l’inverse, le prompt système ne doit pas contenir toutes les données changeantes du projet : cela complique la maintenance et la traçabilité.
Tokens et fenêtre de contexte : ce que le testeur doit comprendre
Un token désigne une unité de texte traitée par un modèle ; un token ne correspond pas toujours à un mot complet. La segmentation dépend du modèle et de son encodeur.
La fenêtre de contexte désigne la quantité maximale d’informations que le modèle peut prendre en compte pour produire une réponse, selon les règles du fournisseur et du modèle. Elle peut inclure les instructions, les messages précédents, les documents, les images représentées et la sortie à générer.
Les limites, le comptage et la tarification évoluent selon l’outil. Il faut donc mesurer avec le compteur ou la documentation du modèle utilisé au moment de la mise en œuvre, et dater toute valeur publiée.
Ajouter plus de contenu n’améliore pas automatiquement la qualité. Une spécification complète peut contenir du bruit, des versions obsolètes et des contradictions. Préparez plutôt un contexte utile :
- supprimer les doublons et versions périmées ;
- conserver les identifiants et la provenance ;
- placer les règles décisives près de la tâche ;
- séparer les sources validées des documents informatifs ;
- tester si le modèle retrouve effectivement les passages nécessaires ;
- consigner la version exacte des entrées utilisées.
Méthode pratique pour construire et tester un prompt QA
Étape 1 — Définir une seule sortie utile
Objectif : éviter une chaîne opaque.
Action : choisir un livrable intermédiaire, par exemple un inventaire d’ambiguïtés.
Résultat attendu : une sortie dont la qualité peut être jugée sans exécuter une autre tâche.
Erreur à éviter : demander en une fois analyse, critères, cas, données et scripts.
Étape 2 — Préparer les sources et leur autorité
Objectif : empêcher la fusion silencieuse de documents incompatibles.
Action : donner un identifiant, une version et un statut à chaque entrée.
Résultat attendu : chaque affirmation peut être reliée à sa provenance.
Erreur à éviter : joindre une maquette et une règle métier sans préciser laquelle fait foi.
Étape 3 — Écrire les contraintes et les critères ensemble
Objectif : rendre chaque risque contrôlable.
Action : convertir « n’invente rien » en contrôles : source requise, statut « indéterminé », liste des hypothèses séparée.
Résultat attendu : une grille de revue utilisable par un testeur.
Erreur à éviter : accumuler des interdictions non mesurables.
Étape 4 — Créer un petit jeu d’évaluation
Objectif : tester le prompt sur plusieurs formes de difficulté.
Action : sélectionner des stories complètes, ambiguës, contradictoires et comportant une dépendance externe ; préparer les éléments attendus.
Résultat attendu : des résultats comparables après chaque modification.
Erreur à éviter : optimiser le prompt sur un seul exemple.
Étape 5 — Versionner et rejouer les contrôles
Objectif : détecter les régressions.
Action : conserver le prompt, le modèle, les paramètres, les entrées, la date et le résultat de la revue.
Résultat attendu : une décision documentée de conserver, corriger ou abandonner la nouvelle version.
Erreur à éviter : conclure qu’un prompt est stable après une démonstration réussie.
Exemple hypothétique 1 — Extraire les ambiguïtés d’un remboursement
La story contient « remboursement rapide », une règle partielle sur les cartes bancaires et une dépendance au prestataire de paiement. Le prompt demande uniquement :
- les faits avec référence de ligne ;
- les termes non mesurables ;
- les contradictions ;
- les dépendances ;
- les questions classées par impact sur la conception des tests.
La contrainte « ne rédige aucun résultat attendu pour une règle absente » empêche de transformer « rapide » en délai arbitraire. La sortie est acceptée si toutes les règles citées existent dans la story et si chaque inconnue importante produit une question. Les critères d’acceptation ne sont rédigés qu’après réponse du métier.
Exemple hypothétique 2 — Classer des anomalies sans réinterpréter leur gravité
Une équipe possède 80 titres et descriptions d’anomalies déjà anonymisés. Le prompt doit les classer par composant à partir d’une liste fermée, repérer les doublons possibles et expliquer les rapprochements par des termes présents dans les descriptions.
Le modèle n’est pas autorisé à modifier la sévérité, car celle-ci dépend de règles projet non fournies. Les sorties possibles pour le composant sont limitées à la taxonomie ou À_REVOIR. Le testeur contrôle les cas À_REVOIR, un échantillon de chaque catégorie et tous les doublons suggérés avant d’importer le classement dans l’outil de suivi.
Erreurs fréquentes dans un prompt de test logiciel
Confondre rôle et preuve d’expertise
« Tu es un expert ISTQB » peut améliorer le style sans garantir l’application correcte d’une technique. Exigez les étapes, la trace vers les règles et les critères permettant de vérifier le travail.
Fournir les sources sans les délimiter
Le modèle peut confondre une instruction et le texte d’un document. Utilisez des blocs identifiés, précisez leur autorité et demandez une citation vers l’identifiant correspondant.
Demander une sortie exhaustive
« Liste tous les cas » n’a pas de critère de fin défendable. Définissez plutôt le modèle de couverture, les risques, les techniques et la justification des exclusions.
Ajouter du contexte non contrôlé
Une longue conversation peut contenir des décisions périmées. Reconstituez un paquet de contexte versionné pour la tâche critique au lieu de supposer que tout l’historique est correct.
Évaluer seulement la forme
Un tableau propre peut être factuellement faux. Contrôlez d’abord la fidélité aux sources, puis la couverture, l’utilisabilité et le format.
Conclusion
Un prompt QA efficace transforme une demande vague en contrat de travail vérifiable : qui agit, sur quelles sources, pour quelle tâche, avec quelles limites et selon quels critères. Prenez un livrable existant, appliquez le gabarit en sept éléments, puis rejouez-le sur plusieurs stories avant de l’utiliser en production. Pour adapter cette structure à votre processus, vous pouvez faire examiner votre cas d’usage de test.