IA dans le test logiciel

01 — Comprendre l'IA

Qu'est-ce que l'intelligence artificielle ?

Avant de parler de test, quelques notions de base.

Intelligence artificielle

Le terme générique

Un ensemble de techniques informatiques qui permettent à un programme d'effectuer des tâches associées à l'intelligence humaine. Cela peut-être reconnaître une image, comprendre une phrase ou prédire une valeur. Ce n'est pas une seule technologie, mais un champ qui regroupe plusieurs approches.

Apprentissage automatique (Machine Learning)

La branche la plus utilisée en entreprise

Plutôt que de programmer des règles explicites ("si X alors Y"), on entraîne un modèle sur des exemples pour qu'il apprenne lui-même à repérer des régularités. Cette branche sert par exemple à prédire quels tests ont le plus de risque d'échouer, à partir de l'historique des exécutions passées.

Réseaux de neurones & deep learning

Une famille de modèles d'apprentissage automatique

Des modèles composés de plusieurs couches de calculs interconnectés, inspirés (de loin) du fonctionnement des neurones biologiques. Le deep learning (apprentissage profond) désigne l'usage de réseaux à très nombreuses couches, capables d'apprendre des représentations complexes à partir de grandes quantités de données brutes (texte, image, son).

IA générative & modèles de langage (LLM)

Ce qu'on utilise le plus aujourd'hui via un chat

Un LLM est un réseau de neurones entraîné sur d'immenses volumes de texte pour prédire, mot après mot, la suite la plus probable d'un texte. C'est ce mécanisme de prédiction qui, à grande échelle, permet de générer des cas de test, du code ou des résumés à partir d'une consigne (prompt).

IA générative vs apprentissage automatique classique

Deux usages issus de la même famille

Les deux relèvent de l'apprentissage automatique. Ce qui les sépare, c'est ce qu'on demande au modèle de produire. L'IA générative (grands modèles de langage) produit du texte, du code ou des cas de test à partir d'un prompt. L'apprentissage automatique classique repose sur des modèles entraînés pour une tâche précise, comme prédire quels tests ont le plus de risque d'échouer. Les deux coexistent dans les outils de test actuels.

Exemple :

IA générative : "Génère les cas de test pour ce formulaire de paiement"Apprentissage automatique classique : "Ce test a 82 % de risque d'échouer aujourd'hui"

L'IA générative produit un contenu nouveau à partir d'une consigne. Le modèle classique calcule une prédiction ciblée à partir de données historiques. Deux usages différents, souvent combinés dans un même outil de test.

Trois familles de modèles de langage

Tous les LLM ne servent pas à la même chose

Un LLM de fondation est le modèle brut sorti de l'entraînement. Il complète du texte. Il ne cherche pas vraiment à obéir à une consigne, ce qui le rend peu pratique à utiliser directement. Un LLM adapté aux instructions a reçu un entraînement supplémentaire pour suivre une demande formulée en langage naturel. C'est celui que l'on trouve dans presque tous les outils grand public. Un LLM de raisonnement va plus loin. Il produit une réflexion intermédiaire avant sa réponse finale, ce qui aide sur les tâches à plusieurs étapes de logique.

Ce que ça change en test :

Adapté aux instructions : reformuler un rapport, générer des cas de test à partir de règles clairesRaisonnement : démêler une chaîne de dépendances entre cas de test, analyser une contradiction entre exigences

Un modèle de raisonnement est plus lent et plus coûteux. Le réserver aux tâches qui le méritent est un bon réflexe pour le budget et pour la consommation d'énergie.

Les modèles multimodaux

Quand l'entrée n'est plus seulement du texte

Un modèle multimodal accepte plusieurs types d'entrées. Le plus souvent du texte et des images. On peut donc lui fournir une maquette d'écran, une capture d'une anomalie ou un extrait de tableau de bord et lui poser une question dessus.

Exemple en test :

"Voici la maquette de l'écran d'inscription. Liste les critères d'acceptation que cet écran suppose, et les champs dont le comportement n'est pas déductible de la seule maquette.""Voici la maquette attendue et une capture de la recette. Signale tous les écarts visibles entre les deux."

La vigilance reste la même que sur le texte. Le modèle décrit ce qu'il croit voir. Il peut affirmer la présence d'un champ absent de l'image, avec autant d'assurance que le reste.

IA symbolique

L'approche historique, à base de règles

Avant l'apprentissage automatique, l'IA reposait surtout sur des règles écrites à la main par des expert•es. C'était un peu comme un arbre de décision géant. Cette approche reste utilisée aujourd'hui pour des systèmes où chaque décision doit pouvoir s'expliquer précisément, par exemple certains moteurs de règles métier. Elle est plus rigide qu'un modèle statistique mais son comportement est entièrement prévisible, ce qu'un LLM ne peut pas garantir.

02 — Comment un modèle apprend

Comment un modèle apprend

Des documents en entrée, un modèle statistique en sortie.

Des données en très grand nombre

Un modèle de langage s'entraîne sur des milliards de pages de texte, de code et de documents. Plus le corpus est large et varié, plus le modèle repère de régularités statistiques du langage.

Exemple : le corpus d'entraînement mélange des sources très variées

LivresSites webCode sourceWikipédiaForums

Des paramètres ajustés statistiquement

L'entraînement ajuste des milliards de paramètres numériques (poids) pour que le modèle minimise ses erreurs de prédiction sur les exemples fournis. Rien n'est écrit à la main, tout est appris par calcul.

Exemple : à chaque exemple d'entraînement, les poids se corrigent un peu

Avant : "Le chat mange la …" → "voiture" (33%)Après des milliards d'exemples : "croquette" (91%)

À chaque erreur de prédiction sur un exemple d'entraînement, un algorithme (la rétropropagation) ajuste légèrement les poids du modèle pour le rapprocher de la bonne réponse. Répété des milliards de fois, cet ajustement fait émerger des prédictions de plus en plus fiables.

IMPORTANT

Une prédiction, pas un raisonnement

Le modèle calcule le mot ou le tokenUnité de texte, mot, sous-mot ou caractère, que le modèle traite comme brique de base le plus probable à écrire ensuite. Il n'a ni compréhension du monde ni vérification factuelle intégrée, ce qui explique qu'il peut halluciner.

Exemple : "La capitale de la France est"

LacapitaledelaFranceestParis

Le modèle découpe la phrase en tokens (en orange), puis calcule statistiquement le token suivant le plus probable. Paris (en vert) arrive en tête, non pas parce que le modèle "sait" que c'est la capitale, mais parce que cette suite de mots est la plus fréquente dans les textes utilisés pour l'entraîner.

Ces tokens comptent doublement. Ils déterminent d'abord ce que le modèle peut traiter en une fois. Tout l'échange doit tenir dans sa fenêtre contextuelleQuantité maximale de texte, mesurée en tokens, qu'un modèle peut prendre en compte en une seule fois, la consigne, le contexte fourni et la réponse se partageant cette place. Ils déterminent ensuite le coût. La facturation des outils professionnels se fait au token envoyé et au token généré.

Un savoir figé après l'entraînement et RAG

Sauf réentraînement ou recherche externe ajoutée par l'outil, le modèle ne connaît pas les évènements postérieurs à la date de sa dernière mise à jour de connaissances.

Exemple : une question posée à un modèle dont les connaissances s'arrêtent en 2024

"Qui a gagné le match d'hier soir ?"Sans outil de recherche : réponse impossible ou inventéeAvec recherche web activée : réponse à jour

Le modèle seul ne suffit pas ici. Il ne fait que rejouer ce qu'il a appris jusqu'à sa date de coupure. Il faut donc une source externe, ajoutée par l'outil. La technique qui consiste à retrouver une information puis à l'ajouter au prompt avant de répondre s'appelle le RAG. La recherche web n'en est que le cas le plus visible. En test logiciel, la source est le plus souvent la documentation du projet et elle est indexée pour que le modèle réponde à partir des exigences réelles. La page Infrastructure de test basée LLM détaille cette mécanique.

03 — L'IA et le test

Sous quelle forme l'IA arrive dans le test ?

Selon l'outil utilisé et le niveau d'autonomie qu'on lui laisse, la place du testeur ou de la testeuse change.

Test assisté par l'IA vs test autonome

Qui garde la main ?

Dans la très grande majorité des usages actuels, l'IA assiste les équipes. Elle propose, suggère, priorise, mais une validation humaine reste nécessaire. Le test entièrement autonome, sans supervision, reste rare et risqué en dehors de cas très encadrés. Par exemple, une suite de smoke tests automatisés qui s'exécute à chaque déploiement en intégration continue, sur un périmètre limité et déjà validé.

Pourquoi ce sujet compte pour un•e testeur•se

L'enjeu pour le métier

Ces outils se diffusent vite dans les équipes de développement et de QA. Il faut que le•la testeur•se comprenne ce qu me'ils font bien, ce qu'ils font mal, et où ils demandent de la vigilance. Cela permet de les utiliser efficacement sans leur déléguer un jugement qu'ils n'ont pas.

Chatbot, outil intégré ou agent

Trois façons différentes de faire appel à l'IA

Un chatbot IA répond aux questions posées dans une conversation. C'est l'usage le plus simple et le plus accessible, y compris pour des profils non techniques. Un outil de test doté de fonctions d'IA intègre directement un modèle de langage dans ses fonctionnalités habituelles, sans passer par une conversation. Un agent va plus loin encore. Il peut exécuter lui-même une suite d'actions pour accomplir une tâche. Cette exécution peut nécessiter, ou non, une supervision humaine plus ou moins fréquente.

04 — Bien formuler sa demande

La structure d'un bon prompt

Un LLM répond à ce qu'on lui donne. Bien formuler sa demande change directement la qualité du résultat.

Exemple sur un formulaire de connexion :

01

Rôle

Demander au modèle d'adopter un point de vue précis comme celui d'un•e testeur•se, d'un•e test manager ou d'un•e ingénieur•e en automatisation. Le ton et les priorités de la réponse changent selon le rôle demandé.

Rôle : agis comme un•e testeur•se d'acceptation spécialisé•e en e-commerce, avec une solide expérience du test fonctionnel.

02

Contexte

Donner les informations de fond nécessaires. Par exemple, l'objet testé, la fonctionnalité concernée, les contraintes du projet. Sans ce contexte, le modèle complète avec des hypothèses génériques.

Contexte : formulaire de connexion d'un site marchand, accessible sur web et mobile, utilisé par des client•es déjà inscrit•es.

03

Instructions

Formuler la tâche demandée de façon claire et directe. Une consigne vague produira presque toujours une réponse vague voire erronée.

Instructions : génère des cas de test fonctionnels couvrant les scénarios nominaux de connexion, les cas limites et les cas d'erreur.

04

Données d'entrée

Fournir la matière sur laquelle travailler. Par exemple, une user story, des critères d'acceptation, une capture d'écran ou un extrait de code. Plus ces données sont précises, plus la réponse l'est aussi.

Données d'entrée : champ email et mot de passe obligatoires, mot de passe de 8 caractères minimum avec au moins une majuscule et un chiffre, compte verrouillé après 5 tentatives échouées.

05

Contraintes

Préciser les limites à respecter. Par exemple, un format imposé, un nombre de cas maximum ou une terminologie propre à l'équipe.

Contraintes : inclure au moins un cas limite et un cas lié à la sécurité, ne pas dépasser dix cas de test, utiliser la terminologie ISTQB.

06

Format de sortie

Indiquer la structure attendue de la réponse. Par exemple, un tableau, une liste numérotée ou un script dans un langage donné.

Format de sortie : tableau avec les colonnes identifiant, donnée testée, étape à réaliser et résultat attendu

Chaque composant guide un peu plus la réponse du modèle. Retirer les contraintes ou le format de sortie donnerait un résultat plus générique, avec moins de chances de correspondre exactement à ce qui est attendu.

04 — Bien formuler sa demande

La structure d'un bon prompt

Un LLM répond à ce qu'on lui donne. Bien formuler sa demande change directement la qualité du résultat.

01

Rôle

Demander au modèle d'adopter un point de vue précis comme celui d'un•e testeur•se, d'un•e test manager ou d'un•e ingénieur•e en automatisation. Le ton et les priorités de la réponse changent selon le rôle demandé.

02

Contexte

Donner les informations de fond nécessaires. Par exemple, l'objet testé, la fonctionnalité concernée, les contraintes du projet. Sans ce contexte, le modèle complète avec des hypothèses génériques.

03

Instructions

Formuler la tâche demandée de façon claire et directe. Une consigne vague produira presque toujours une réponse vague voire erronée.

04

Données d'entrée

Fournir la matière sur laquelle travailler. Par exemple, une user story, des critères d'acceptation, une capture d'écran ou un extrait de code. Plus ces données sont précises, plus la réponse l'est aussi.

05

Contraintes

Préciser les limites à respecter. Par exemple, un format imposé, un nombre de cas maximum ou une terminologie propre à l'équipe.

06

Format de sortie

Indiquer la structure attendue de la réponse. Par exemple, un tableau, une liste numérotée ou un script dans un langage donné.

01

Rôle

02

Contexte

03

Instructions

04

Données d'entrée

05

Contraintes

06

Format de sortie

Exemple sur un formulaire de connexion :

Rôle : agis comme un•e testeur•se d'acceptation spécialisé•e en e-commerce, avec une solide expérience du test fonctionnel.Contexte : formulaire de connexion d'un site marchand, accessible sur web et mobile, utilisé par des client•es déjà inscrit•es.Instructions : génère des cas de test fonctionnels couvrant les scénarios nominaux de connexion, les cas limites et les cas d'erreur.Données d'entrée : champ email et mot de passe obligatoires, mot de passe de 8 caractères minimum avec au moins une majuscule et un chiffre, compte verrouillé après 5 tentatives échouées.Contraintes : inclure au moins un cas limite et un cas lié à la sécurité, ne pas dépasser dix cas de test, utiliser la terminologie ISTQB.Format de sortie : tableau avec les colonnes identifiant, donnée testée, étape à réaliser et résultat attendu

Chaque composant guide un peu plus la réponse du modèle. Retirer les contraintes ou le format de sortie donnerait un résultat plus générique, avec moins de chances de correspondre exactement à ce qui est attendu.

Cette structure en six composants pose les bases. La page Ingénierie du prompting va plus loin.

05 — Cas d'usage

Les cas d'usage concrets

Plusieurs usages sont aujourd'hui répandus de l'IA dans les activités de test. Sur mobile, swipez la carte pour passer à la suivante.

01

Analyse des exigences

Avant même de concevoir des tests, un modèle de langage peut relire une spécification ou une user story. Il parvient à repérer les ambiguïtés, les informations manquantes ou les incohérences avec d'autres exigences du projet. Cette relecture précoce évite de découvrir le problème plus tard.

02

Génération assistée de cas de test

À partir d'une user story, d'une spécification ou d'une capture d'écran, un outil d'IA générative propose des cas de test (nominaux, limites, erreurs). Cela accélère la conception, mais chaque cas doit être relu et validé par un humain avant d'être considéré comme fiable.

03

Priorisation intelligente des tests

En croisant l'historique des défauts, les zones de code modifiées et la criticité métier, l'IA aide à prioriser quels tests exécuter en premier. Particulièrement utile en intégration continue où le temps d'exécution est limité.

04

Tests auto-réparants (self-healing)

Quand un sélecteur d'interface change (un bouton renommé, un id modifié), certains outils d'automatisation détectent l'élément équivalent et réparent le script automatiquement plutôt que de faire échouer le test. Ici il faut faire attention que le modèle n'introduit pas des erreurs.

05

Détection d'anomalies visuelles

Des outils de comparaison visuelle basés sur l'IA repèrent des régressions d'interface (décalage, couleur, superposition) que des assertions fonctionnelles classiques ne détecteraient pas.

06

Analyse de logs et de risques

L'IA peut analyser de grands volumes de logs de production ou de résultats d'exécution pour repérer des anomalies récurrentes et orienter l'analyse de risques vers les zones les plus fragiles.

07

Génération de données de test synthétiques

Plutôt que d'utiliser de vraies données de production (souvent sensibles), un modèle peut générer des jeux de données réalistes et variés, en respectant les règles métier fournies en entrée. Pratique pour couvrir davantage de cas sans exposer d'informations confidentielles.

08

Assistance à la rédaction de rapports

L'IA peut aider à la rédaction de rapports de bug, reformuler une description technique en langage clair pour un•e client•e, ou synthétiser une session d'exploration. Ce sont des tâches rédactionnelles où l'IA générative fait gagner du temps.

01

Analyse des exigences

Avant même de concevoir des tests, un modèle de langage peut relire une spécification ou une user story. Il parvient à repérer les ambiguïtés, les informations manquantes ou les incohérences avec d'autres exigences du projet. Cette relecture précoce évite de découvrir le problème plus tard.

02

Génération assistée de cas de test

À partir d'une user story, d'une spécification ou d'une capture d'écran, un outil d'IA générative propose des cas de test (nominaux, limites, erreurs). Cela accélère la conception, mais chaque cas doit être relu et validé par un humain avant d'être considéré comme fiable.

03

Priorisation intelligente des tests

En croisant l'historique des défauts, les zones de code modifiées et la criticité métier, l'IA aide à prioriser quels tests exécuter en premier. Particulièrement utile en intégration continue où le temps d'exécution est limité.

04

Tests auto-réparants (self-healing)

Quand un sélecteur d'interface change (un bouton renommé, un id modifié), certains outils d'automatisation détectent l'élément équivalent et réparent le script automatiquement plutôt que de faire échouer le test. Ici il faut faire attention que le modèle n'introduit pas des erreurs.

05

Détection d'anomalies visuelles

Des outils de comparaison visuelle basés sur l'IA repèrent des régressions d'interface (décalage, couleur, superposition) que des assertions fonctionnelles classiques ne détecteraient pas.

06

Analyse de logs et de risques

L'IA peut analyser de grands volumes de logs de production ou de résultats d'exécution pour repérer des anomalies récurrentes et orienter l'analyse de risques vers les zones les plus fragiles.

07

Génération de données de test synthétiques

Plutôt que d'utiliser de vraies données de production (souvent sensibles), un modèle peut générer des jeux de données réalistes et variés, en respectant les règles métier fournies en entrée. Pratique pour couvrir davantage de cas sans exposer d'informations confidentielles.

08

Assistance à la rédaction de rapports

L'IA peut aider à la rédaction de rapports de bug, reformuler une description technique en langage clair pour un•e client•e, ou synthétiser une session d'exploration. Ce sont des tâches rédactionnelles où l'IA générative fait gagner du temps.

06 — Intégration au processus

Comment l'IA s'intègre dans le processus de test

L'IA s'insère étape par étape dans le processus fondamental de test.

01

Analyse & conception

L'IA aide à identifier des scénarios de test à partir des exigences, y compris des cas limites auxquels on ne pense pas toujours spontanément.

Exemple de prompt : "Agis comme testeur•se d'acceptation. Voici les critères d'acceptation de cette fonctionnalité de paiement en ligne. Propose des scénarios de test, en incluant au moins deux cas limites."

02

Implémentation

Génération de scripts d'automatisation, de jeux de données de test réalistes, ou des modèles de cas de test à compléter.

Exemple de prompt : "Voici un cas de test rédigé en langage naturel et un exemple de script déjà existant dans ce projet. Génère le script correspondant à ce cas de test, dans le même style."

03

Exécution

L'IA aide à décider dans quel ordre lancer les tests, en s'appuyant sur les modifications récentes et sur l'historique des défauts pour faire remonter en premier ceux qui présentent le plus de risque.

Exemple de prompt : "Voici la liste des tests modifiés depuis le dernier déploiement et l'historique des défauts du mois dernier. Propose un ordre d'exécution en commençant par les tests les plus à risque."

04

Analyse des résultats

Tri automatique des échecs de test (faux positifs liés à l'environnement vs vrais défauts), regroupement des anomalies similaires.

Exemple de prompt : "Voici les logs de ces 12 tests en échec. Regroupe-les par cause probable et indique lesquels ressemblent à un problème d'environnement plutôt qu'à un vrai défaut."

05

Reporting

Synthèse automatique des campagnes de test avec mise en évidence des zones à risque pour aider à la décision go / no-go.

Exemple de prompt : "Résume cette campagne de test en dix lignes pour un•e chef•fe de projet non technique, en mettant en avant les zones encore risquées avant la mise en production."

07 — Limites

Limites et points de vigilance

L'IA est loin d'être infaillible. Voici quatre points de vigilance à garder en tête avant de lui confier une tâche. Sur mobile, swipez la carte pour passer à la suivante.

Hallucinations et faux positifs

Un outil génératif peut proposer des cas de test qui semblent pertinents mais ne correspondent pas réellement au comportement attendu du système. Rien dans le ton de la réponse ne signale l'erreur, toute suggestion doit donc être vérifiée.

Biais de couverture

L'IA a tendance à générer des cas nominaux et des variations évidentes. Elle repère moins bien les combinaisons rares ou les scénarios métier complexes qu'un•e testeur•se expérimenté•e identifierait par analyse de risques.

Comportement non déterministe

Poser exactement la même question deux fois à un modèle peut donner deux réponses différentes, même formulées de façon identique. C'est déroutant pour un•e testeur•se habitué•e à la reproductibilité.

Confidentialité des données

Envoyer des spécifications, du code ou des données de production à un outil d'IA externe pose des questions de confidentialité qui doivent être validées avant tout usage en entreprise.

Ces quatre exemples ne sont qu'un aperçu. La page Risques et limites de l'IA détaille plus. Notamment avec des exemples d'hallucinations et des méthodes pour vérifier une suggestion.

08 — Le facteur humain

Le rôle du•de la testeur•se ne disparaît pas

L'IA transforme les tâches du quotidien. L'utilisateur•rice garde le jugement sur la qualité. Sur mobile, swipez la carte pour passer à la suivante.

Le jugement métier reste humain

Une IA ne connaît pas les enjeux de l'entreprise, les contraintes réglementaires ou les priorités d'un projet aussi finement qu'une équipe qui le vit au quotidien. Prioriser selon les risques reste une décision humaine, informée par l'IA.

Le scepticisme professionnel s'applique aussi à l'IA

Le même esprit critique qui pousse un•e testeur•se à douter d'une fonctionnalité "qui fonctionne" doit s'appliquer à une suggestion de l'IA. On ne prend pas pour argent comptant ce qui est dit.

De nouvelles compétences à développer

Savoir formuler une bonne consigne (prompt), relire un cas de test généré, ou évaluer la pertinence d'une priorisation automatique devient une compétence à part entière du métier de testeur•se.

La page Adopter l'IA dans son équipe QA prend l'angle organisationnel, avec le déploiement progressif de ces outils.

A retenir

Ce qu'il faut retenir

01

L'IA est un outil et l'utilisateur•trice doit analyser.

L'IA accélère des tâches comme la génération de cas de test, la priorisation ou la détection d'anomalies. Cependant, la validation et le jugement métier restent humains.

02

Chaque suggestion se vérifie

Un cas de test généré par l'IA n'est fiable qu'après relecture, car les hallucinations et le biais de couverture restent des risques réels.

03

L'IA s'intègre à chaque étape du processus

De la conception jusqu'au reporting, elle épaule le processus fondamental de test déjà connu.

04

Le sens critique du•de la testeur•se reste central

La curiosité, le scepticisme professionnel et la connaissance du contexte métier restent les compétences qui font la différence face à l'IA.

Mise en pratique

Testez votre compréhension

Une sélection de questions basées sur ce que vous venez de lire.

Question 1 / 12

Quelle est la différence entre un LLM adapté aux instructions et un LLM de raisonnement ?

Un•e testeur•se fournit à un modèle multimodal la maquette d'un écran et lui demande d'en déduire des critères d'acceptation. Quelle vigilance reste nécessaire ?

Pourquoi le nombre de tokens d'un échange compte-t-il pour une équipe de test ?

Que peut faire un outil d'IA générative à partir d'une user story ?

Une refonte graphique renomme l'identifiant d'un bouton. Le script d'automatisation continue de passer au vert sans qu'une personne intervienne. De quelle fonction s'agit-il ?

Une équipe génère vingt cas de test pour un formulaire de recherche. Les vingt portent sur des mots recherchés valides et de longueur ordinaire. Quel phénomène est à l'œuvre ?

Pourquoi faut-il rester vigilant face aux suggestions d'un outil d'IA appliqué au test ?

Quel type de défaut d'interface l'IA de comparaison visuelle est-elle particulièrement adaptée à détecter ?

Un•e testeur•se colle les logs de douze tests en échec et demande un regroupement par cause probable. À quelle étape du processus de test cet usage se rattache-t-il ?

Une équipe demande à un chatbot si la dernière version d'une bibliothèque de test corrige une anomalie connue. La réponse est détaillée et pourtant fausse. Quelle est l'explication la plus probable ?

Quelles compétences restent centrales pour un•e testeur•se, même avec l'IA en support ?

Parmi ces éléments, lequel ne fait pas partie de la structure d'un prompt bien construit ?

Pour aller plus loin