Workflow de test agentique intégrant une couche RAG

Introduction

Lorsqu’on découvre le RAG (Retrieval-Augmented Generation), on le représente souvent de façon très technique :

Documents → découpage → embeddings → base vectorielle → recherche → LLM → réponse

Cette représentation est correcte. Mais elle est incomplète dès que l’on quitte le cadre d’un simple chatbot documentaire pour s’intéresser à une utilisation opérationnelle de l’IA générative dans les tests logiciels.

Dans une véritable infrastructure de test basée sur LLM, le RAG ne constitue pas seulement une « couche technique » ajoutée à un modèle de langage.
Il devient un mécanisme d’alimentation contextuelle d’un workflow de test plus large, reliant les connaissances de l’organisation, le LLM, les outils de test, les API, les contrôles humains et les mécanismes d’observabilité.

C’est cette évolution, du RAG naïf (Naive RAG) au RAG avancé (Advanced RAG), puis au RAG Modulaire (Modular RAG) et son intégration dans des workflows de test orchestrés, qui permettent de comprendre sa véritable place dans une infrastructure de test assistée par IA.

PARTIE I : Les fondements et les limites du modèle classique

1. Le besoin de contexte : la limite initiale des LLM

Un LLM possède des connaissances acquises lors de son entraînement.
Mais il ne connaît pas nécessairement :

• la dernière version de nos exigences ;
• les règles métier propres à notre produit ;
• les User Stories du sprint courant ;
• nos cas de test existants ;
• l’historique des défauts relevés, corrigés ou non ;
• notre architecture applicative ;
• les résultats de la dernière campagne de régression ;
• les conventions internes utilisées par l’équipe de test.

Un testeur peut donc demander au chatbot :

« Génère les cas de test vérifiant la fonctionnalité de remboursement partiel. »

Le LLM sera parfaitement capable de produire une réponse plausible.

Mais « plausible » ne signifie pas « conforme à notre application ».

Il peut par exemple proposer un cas de test avec comme objectif :

« Vérifier qu’un remboursement partiel peut être demandé avant l’expédition de la commande. »

Alors que la règle métier interne indique précisément le contraire.

Le problème n’est donc pas nécessairement la capacité de raisonnement ou de génération du LLM.

Le problème est l’absence du bon contexte au bon moment.

C’est précisément ce que cherche à résoudre le RAG.

Le syllabus ISTQB CT-GenAI décrit le RAG comme une technologie associant recherche d’information et modèle de langage afin d’intégrer au processus de génération des informations supplémentaires, pertinentes pour la requête.
Dans un contexte de test, cela permet notamment d’aligner l’analyse ou la conception des tests sur les dernières spécifications, exigences et données disponibles.

2. Le RAG naïf : principes de fonctionnement

La première forme de RAG est parfois appelée Naive RAG, ou RAG de base.

Son fonctionnement peut être résumé en quatre grandes opérations.

2.1. Découpage et Vectorisation

– Découpage – Chunking

Les documents sont divisés en fragments suffisamment petits pour pouvoir être retrouvés et injectés dans la fenêtre de contexte du modèle.

Par exemple, une spécification de 200 pages peut être découpée en fragments de quelques centaines de tokens.

Le syllabus CT-GenAI évoque à titre d’exemple des fragments de 256 à 512 tokens.

À noter : Lors du découpage, la fin d’un fragment est recopiée comme début du suivant. Ce chevauchement (overlap) assure la continuité sémantique entre les fragments consécutifs, facilitant la recherche et préservant le contexte.
Par exemple :
Chunk 1 : « Tout paiement supérieur à 500 € nécessite une validation… »
Chunk 2 : « nécessite une validation par un responsable. »

– Vectorisation – Embedding

Chaque fragment est transformé en une représentation numérique appelée embedding.

Deux fragments ayant une signification proche (par exemple deux fragments parlant de « réinitialisation du mot de passe » et de « récupération des identifiants »), tendront à occuper des positions proches dans l’espace vectoriel, même s’ils n’utilisent pas exactement les mêmes termes.

2.2. Stockage et indexation vectorielle
Les vecteurs obtenus sont stockés dans une base de données vectorielle, généralement avec le fragment de texte correspondant et éventuellement quelques métadonnées.

On obtient schématiquement :

Fragment de texte → Embedding → Base vectorielle

Par exemple :

Fragment (chunk) : REQ-245 : « Tout paiement supérieur à 500 € nécessite… »
→ Vectorisation (Embedding) : [0.027, -0.184, 0.731, …]
→ Stockage (embedding + chunk + métadonnées) dans la base vectorielle et son index vectoriel.

La base vectorielle ne sert donc pas seulement à conserver les embeddings : elle fournit également les mécanismes permettant de rechercher efficacement les vecteurs les plus proches.

2.3. Recherche de similarité

– Vectorisation de la requête
Lorsque l’utilisateur pose une question, celle-ci est à son tour transformée en embedding.

Par exemple, « Quels tests prévoir pour les paiements importants ? » devient également un vecteur.

– Recherche de similarité

La recherche de similarité s’effectue alors dans la base vectorielle, qui compare le vecteur de la requête aux vecteurs des fragments indexés.

Le système sélectionne les fragments les plus proches, souvent selon une mesure telle que la similarité cosinus.

(La similarité cosinus mesure à quel point deux vecteurs d’embeddings « pointent dans la même direction ». Plus le cosinus est proche de 1, plus les deux vecteurs sont considérés comme sémantiquement proches.)

NB : Une base vectorielle et un système d’embeddings constituent une implémentation très courante du RAG, mais ne sont pas une obligation intrinsèque du RAG : la récupération peut également utiliser des mécanismes lexicaux, structurés ou d’autres systèmes de recherche.

Schématiquement :

Question utilisateur → Embedding de la requête → Recherche dans l’index vectoriel → Top-k fragments les plus proches

Par exemple, si la requête utilisateur est : « Quels tests prévoir pour les paiements supérieurs à 500 € ? » et que son embedding simplifié est : [0.030, -0.170, 0.720], la base vectorielle pourrait retrouver des embeddings proches comme :

La recherche remonterait donc en priorité REQ-812, REQ-245 et REQ-391, car leurs vecteurs ont une orientation très proche de celui de la requête.

Attention : Cette représentation de vecteurs à 3 dimensions est une illustration simplifiée à titre pédagogique !
Un véritable embedding comporte généralement des centaines ou milliers de dimensions.

2.4. Récupération et génération augmentée

– Récupération (Retrieval)
Les fragments correspondant aux meilleurs résultats sont récupérés avec leur contenu textuel.

Par exemple :

• règle métier concernant les paiements > 500 € ;
• exigence relative à 3D Secure ;
• contrainte concernant certaines cartes bancaires.

– Génération augmentée

Ces fragments sont ajoutés au prompt ou au contexte fourni au LLM.

Le modèle produit alors sa réponse à partir de deux sources :

Prompt (système + utilisateur) + contexte récupéré → LLM → Réponse

On obtient donc un pipeline complet de RAG naïf que l’on peut  représenter sous la forme de deux flux distincts :

Phase 1 – Ingestion, réalisée en amont

Documents → Chunking → Embeddings → Base vectorielle / Index

Phase 2 – Interrogation, réalisée à chaque requête

Question → Embedding → Recherche dans l’index vectoriel → Fragments récupérés → Prompt enrichi → LLM → Réponse

3. Les limites de l’approche naïve

Imaginons qu’un testeur recherche « Quelles règles dois-je prendre en compte pour tester la validation d’un paiement supérieur à 500 € ? »

Une recherche vectorielle simple peut récupérer dix fragments ressemblant sémantiquement à la question.

Mais plusieurs difficultés apparaissent.

• Le fragment le plus proche mathématiquement n’est pas nécessairement le plus utile fonctionnellement.
• Un ancien document peut être plus proche sémantiquement qu’une spécification mise à jour hier.
• Une exigence contenant précisément le mot « 500 € » peut être importante même si sa représentation vectorielle est moins proche.
• Plusieurs fragments presque identiques peuvent saturer les résultats de recherche.
• Une règle générale peut être récupérée alors qu’une règle spécifique au pays, au type de paiement ou à la version de l’application devrait avoir priorité.
• Enfin, la manière dont l’utilisateur formule sa question peut être très différente du vocabulaire employé dans les documents.

Une solution pour pallier ces difficultés peut être alors de passer du RAG naïf au RAG avancé.

PARTIE II : L’évolution vers un système intelligent

4. Le RAG Avancé (Advanced RAG) : optimiser la recherche de contexte

Le principe du RAG avancé reste identique : fournir au modèle les informations les plus pertinentes possibles.

Ce qui change est la sophistication de la chaîne de récupération.

Divers mécanismes sont alors mis en œuvre :

4.1 Recherche hybride

Une recherche hybride combine généralement recherche lexicale et recherche sémantique

La recherche lexicale, par exemple avec BM25, est particulièrement efficace lorsqu’un terme exact est important :

• ERR_PAYMENT_037
• 3D Secure
• REQ-PAY-124
• nom d’une API ;
• numéro d’une version ;
• référence précise d’une exigence.

La recherche vectorielle est au contraire efficace lorsque l’utilisateur et le document expriment une même idée avec des formulations différentes.

Pour un testeur, ces deux formes de recherche sont complémentaires.

4.2 Reclassement (Reranking)

La première recherche peut volontairement récupérer un nombre assez important de candidats.

Un second modèle, souvent appelé reranker, réévalue ensuite leur pertinence par rapport à la question exacte.

On pourrait ainsi récupérer initialement 30 fragments, puis n’en retenir que 5 particulièrement pertinents avant de construire le contexte du LLM.

L’objectif n’est plus seulement de retrouver de l’information, mais de sélectionner le meilleur contexte possible.

4.3 Enrichissement et filtrage par métadonnées

Chaque fragment peut être accompagné de métadonnées :

• produit ;
• version ;
• sprint ;
• auteur ;
• date de validation ;
• statut du document ;
• type d’artefact ;
• composant applicatif ;
• niveau de criticité ;
• environnement ;
• pays concerné, etc.

Une requête portant sur la version 4.7 de l’application peut ainsi exclure automatiquement les exigences obsolètes de la version 3.2.

Pour le test logiciel, cette capacité est particulièrement importante : la pertinence d’une information dépend souvent autant de son statut et de sa version que de son contenu textuel.

4.4  Réécriture de la requête

La question posée par le testeur n’est pas nécessairement la meilleure requête de recherche.

Un système avancé peut transformer :

« Pourquoi le paiement plante-t-il pour certains clients ? »

en plusieurs requêtes plus exploitables :

• Quelles sont les exigences relatives aux échecs de paiement ?
• Quels sont les défauts historiques associés au module Payment ?
• Quels codes d’erreur sont présents dans les logs ?
• Quelles sont les règles 3D Secure ?
• Quelles sont les contraintes relatives aux cartes et devises ?

Le système ne modifie donc pas seulement la réponse. Il optimise également la manière de rechercher les informations qui permettront de produire cette réponse.

5. Du RAG à l’orchestration agentique

C’est ici qu’une distinction devient essentielle.

Un système RAG, aussi sophistiqué soit-il, reste essentiellement chargé d’une mission :

Retrouver le contexte pertinent et le mettre à disposition du processus de génération.

Il ne faut donc pas confondre :

RAG (= retrouver et fournir le bon contexte) avec Agent/orchestrateur (décider quelles opérations effectuer et piloter leur enchaînement)

Cette différence est particulièrement importante dans les tests logiciels.

Le syllabus CT-GenAI distingue lui-même ces deux mécanismes. Le RAG apporte les informations contextuelles nécessaires tandis que les agents basés sur LLM peuvent invoquer des outils, interagir avec des systèmes externes et enchaîner des tâches.

Supposons maintenant que l’objectif soit :

« Analyse les échecs de la dernière campagne de régression et crée les rapports de défauts nécessaires. »

Le système doit potentiellement :

1. récupérer les résultats de la campagne ;
2. lire les logs d’exécution ;
3. identifier les cas de test ayant échoué ;
4. retrouver les exigences associées ;
5. récupérer les défauts similaires déjà connus ;
6. déterminer si l’échec semble nouveau ;
7. proposer une sévérité ;
8. générer un rapport ;
9. demander éventuellement une validation humaine ;
10. appeler l’API Jira ou Azure DevOps ;
11. créer le rapport de défaut ;
12. journaliser l’ensemble de l’opération.

Le RAG intervient à plusieurs étapes, par exemple pour retrouver :

• l’exigence associée au test ;
• la dernière règle métier applicable ;
• les défauts historiques similaires ;
• la documentation technique pertinente.

Mais le RAG ne constitue pas à lui seul l’intégralité de ce workflow.

L’orchestrateur ou l’agent LLM pilote la séquence.

Le RAG lui fournit le contexte dont il a besoin pour raisonner et agir.

Les API lui permettent d’interagir avec les outils.

Les outils de test exécutent les opérations déterministes.

La validation humaine (HITL, Human In The Loop) sécurise certaines décisions.

Enfin, l’observabilité et le LLMOps assurent traçabilité, suivi et analyse du système.

Le CT-GenAI décrit précisément cette évolution vers des assistants intégrés au workflow de test et capables d’intervenir sur l’analyse, la conception, l’implémentation, l’exécution et le reporting des tests, avec des degrés variables d’autonomie.

6. Les trois niveaux de maturité du RAG

On peut représenter l’évolution de façon progressive.

Ce dernier niveau, vu comme un objectif, permet d’éviter une confusion fréquente :

Tout système agentique utilisant une base vectorielle n’est pas simplement « un gros RAG ».

Et tout RAG avancé ou modulaire n’est pas nécessairement agentique.

La sophistication peut se situer dans la récupération de connaissances, dans l’orchestration des actions, ou dans les deux.

PARTIE III : Application pratique et valeur ajoutée

7. L’architecture d’un workflow de test augmenté

Le schéma d’une infrastructure complète peut être lu de haut en bas.

8. Cas pratique : De la User Story à la création du défaut

Prenons une User Story concernant un paiement nécessitant 3D Secure au-delà d’un certain montant.

Dans un RAG naïf, le système retrouve quelques fragments ressemblant à la User Story et les fournit au LLM, qui génère des cas de test.

Dans un RAG avancé, le système peut :

• reformuler la requête ;
• rechercher simultanément par similarité et par mots-clés ;
• filtrer les documents pour ne conserver que la version courante ;
• récupérer exigences, règles de sécurité et défauts historiques ;
• reclasser les fragments ;
• transmettre au LLM uniquement les informations les plus pertinentes.

Dans un workflow agentique intégrant le RAG, le système peut suivre le workflow suivant :

User Story
→ récupération des exigences → génération des conditions de test
→ validation humaine
→ création des cas de test
→ injection dans l’ALM
→ déclenchement de l’automatisation → analyse des résultats
→ nouvelle récupération documentaire
→ qualification des échecs
→ validation (automatique + humaine)
→ création des rapports de défauts
→ validation humaine
→ reporting

Le changement de perspective est considérable.

Le RAG n’est plus simplement visible comme : « une base vectorielle devant ChatGPT » mais comme : « le mécanisme qui fournit les connaissances contextuelles nécessaires aux différentes étapes d’un workflow de test assisté par IA ».

9. Le véritable impact pour le métier du test

L’intérêt majeur du RAG ne réside donc pas dans l’utilisation d’embeddings ou d’une base vectorielle en tant que tels.

Ces éléments ne sont que des moyens techniques.

Sa véritable valeur est de créer un pont entre deux mondes :

le raisonnement génératif du LLM et la réalité documentaire, technique et métier du système testé.

Pour un testeur, cette distinction est fondamentale.

Le but n’est pas que le LLM produise davantage.

Le but est qu’il produise à partir des bonnes exigences, de la bonne version, des bonnes règles métier, des bons résultats de test et du bon historique projet.

Le syllabus CT-GenAI souligne précisément que, dans les tests logiciels, le RAG permet à l’infrastructure basée sur LLM d’accéder aux sources de données de l’entreprise afin d’aligner les tâches de test sur les informations les plus récentes.

10. Conclusion : Vers une infrastructure de test augmentée

Présenter le RAG uniquement comme la succession :

Chunking → Embeddings → Vector Store → Retrieval → Generation

est utile pour comprendre son fonctionnement interne.

Mais cette représentation ne montre qu’une partie du problème.

Dans une infrastructure de test mature, le RAG s’insère dans une chaîne beaucoup plus vaste :

Connaissances → RAG → LLM/Agent → Outils → Validation → Exécution → Résultats → Observabilité

Le passage du RAG naïf au RAG avancé améliore progressivement la qualité de la récupération : recherche hybride, métadonnées, réécriture des requêtes, reranking…

Le passage du RAG avancé au workflow agentique (Modular RAG) change, lui, la nature du système : le contexte récupéré n’est plus seulement utilisé pour répondre à une question, mais peut alimenter une succession d’activités de test reliées entre elles.

C’est probablement là que se situe l’évolution la plus importante.

Le RAG n’est pas le workflow de test.

Mais dans un système de test assisté par IA suffisamment élaboré, il peut devenir la couche de connaissance qui irrigue tout le workflow.

Et c’est à ce moment-là que l’on cesse de parler simplement d’un « LLM auquel on a ajouté une base vectorielle » pour commencer à parler d’une véritable infrastructure de test basée sur LLM.

Bibliographie

L’article « Retrieval-Augmented Generation for Large Language Models: A Survey » de Y.Gao et als. (janv. 2024) est considéré comme une référence incontournable et l’un des meilleurs points de départ pour comprendre la structuration de la RAG (génération augmentée par récupération).
Le domaine de l’IA évoluant rapidement, il ne couvre cependant pas en profondeur les tendances les plus récentes de 2025-2026 comme le Graph RAG ou les approches multi-agents autonomes (Agentic RAG) évoquées dans cet article.

Avertissement

Cet article, après rédaction, a été revu avec l’assistance de ChatGPT (OpenAI, modèle GPT-5.6 Sol) et Gemini (Google), notamment pour la reformulation et/ou la vérification de certains éléments. La responsabilité éditoriale finale reste celle de l’auteur.