27.1 Analyse du marché existant

🆕 Section prospective

Cette page ne décrit pas notre application : elle décrit ce que font les outils du marché, pour calibrer nos propres propositions. Elle sert de référence à toutes les fiches A1 – A12.

Solutions retenues et raison du choix

Solution	Pourquoi elle est pertinente pour nous
TestRail (Gurock/Idera)	La plus proche de notre cas : outil de gestion de recette autonome (pas un greffon Jira), organisé en référentiel de cas + exécutions groupées par jalon de release, avec un module de rapports intégré. C'est notre comparable direct.
Xray (Jira)	Référence sur la séparation référentiel / périmètre exécuté (Test Repository vs Test Plan / Test Execution) — exactement le point de rigidité identifié dans notre v1 — et sur la génération de cas de test assistée par IA.
Zephyr Scale (SmartBear)	Référence sur l'archivage réversible des cas de test et sur le rattachement d'un cycle de test à une version/release, c'est-à-dire nos deux autres demandes (masquage de flux, montées de version).

qTest (Tricentis), PractiTest et Qase ont été ajoutés au second temps de l'étude (inventaire exhaustif) pour leurs apports spécifiques : traçabilité exigence → défaut et gouvernance à grande échelle pour qTest, matrice de traçabilité et IA (SmartFox) pour PractiTest, IA (AIDEN) pour Qase. Voir Inventaire des fonctionnalités.

Synthèse comparative

Axe	TestRail	Xray (Jira)	Zephyr Scale (Jira)
Dashboards / reporting	Espace Reports dédié : rapports générables immédiatement, sur appel API, ou selon une planification récurrente, avec envoi par e-mail aux destinataires (qui reçoivent un lien — l'accès reste contrôlé). Rapports type Activity Summary (Cases) (cas créés/modifiés sur une période), Runs (Summary), User (Test Execution) Workload. Plus de 70 rapports prédéfinis. Tableaux de bord inter-projets réservés à la licence Enterprise.	Suivi de la couverture des exigences par graphiques interactifs ; rapports et tableaux de bord sur le statut, la couverture et les versions, pour décider d'une mise en production.	Gadgets natifs du dashboard Jira (Test execution results by coverage, by test cycle), plus de 30 rapports prédéfinis, filtrage par epic / story / version, export multi-formats.
Référentiel de tests ↔ campagnes / cycles	Référentiel unique par projet (sections/sous-sections = dossiers). Un test run groupe des cas sélectionnés pour exécution ; un milestone groupe des runs pour une release. La sélection est une opération d'exécution, pas une refonte du référentiel.	Séparation explicite : le Test Repository organise les tests en dossiers sans se préoccuper de l'exécution ; les Test Sets / Test Plans / Test Executions définissent le périmètre exécuté. Un même test peut appartenir à plusieurs Test Sets.	Cas de test rangés en dossiers/sous-dossiers ; les test cycles regroupent un sous-ensemble de cas pour un objectif donné, assignables à des testeurs et à un environnement. Structure pensée pour la réutilisation (régression, releases parallèles).
Non-régression / montées de version	Milestone = release ; les runs de régression sont créés par sélection dans le référentiel. Baselines = branches du référentiel (copie du master) pour maintenir plusieurs versions en parallèle. La fermeture d'un run l'archive et fige les données du cas au moment de l'exécution (les modifications ultérieures ne se propagent pas).	Test Plan par version/sprint : on identifie les tests à rejouer, on planifie les exécutions, on consolide les résultats. Les tests de régression sont regroupés logiquement (dossier / Test Set) et réutilisés de plan en plan.	Test cycle associé à une version/release Jira (ou à un sprint) ; archivage des cycles par version, l'affichage des versions archivées étant désactivé par défaut.
Gestion utilisateurs & droits	Système de rôles et permissions configurable, restreignant l'accès par projet pour des utilisateurs ou des groupes.	Rôles et permissions hérités de Jira (schémas de permission projet).	Permissions par projet paramétrables par type d'objet (Settings ▸ Test Management ▸ Permissions ▸ Test Cases : ex. droit de suppression).
IA (génération de cas de test)	Génération de cas de test ou de scénarios BDD à partir d'exigences en texte : on choisit une section et un modèle, on saisit l'exigence, l'IA propose titres + descriptions que l'utilisateur édite, réoriente ou exclut avant génération complète (human-in-the-loop, TestRail 9.5). TestRail 10.2 étend l'IA à la génération de code d'automatisation.	AI Test Case Generation : sélection d'une ou plusieurs exigences / preconditions / issues → prévisualisation de titres et descriptions suggérés → revue, édition ou rejet avant création des tests (manuels ou Cucumber). Positionné explicitement comme assistant, pas comme automate.	HaloAI : lecture de la story Jira liée → génération de cas de test brouillons avec étapes, jeu de données et résultats attendus ; résumé d'exécutions en échec en description de défaut ; détection des tests instables / à risque.
Masquage / archivage	Cas « supprimés » placés dans un état retiré des runs et plans mais conservé en base, masquable/affichable par bascule dans l'UI, restaurable pendant 7 / 14 / 30 jours (paramétré par l'administrateur). Statut Archived pour les runs et plans en fin de vie.	Organisation par dossiers ; cycle de vie du test porté par le workflow Jira de l'issue.	Archivage réversible : retire le cas de la bibliothèque active sans le supprimer, réintégrable à tout moment. Versionnage des cas de test avec historique d'audit.

Ce qu'on en retient pour la v2

1. Aucun des trois n'oblige à figer le périmètre d'une campagne à sa création. Le référentiel est stable, le périmètre exécuté est une sélection — c'est structurellement l'inverse de notre snapshot v1 « tout ou rien » (§8).
2. Le figeage existe, mais à la clôture, pas à l'ouverture. TestRail fige les données d'un run quand on le ferme ; notre v1 fige à l'activation. La même garantie d'historique est obtenue sans interdire d'ajuster le périmètre en cours de campagne.
3. L'archivage réversible est la norme ; la suppression est l'exception (Zephyr Scale, TestRail avec rétention). Notre v1 n'a que la suppression en cascade.
4. L'IA du marché est cadrée et supervisée : entrée = une exigence textuelle sélectionnée, sortie = brouillon revu par un humain avant écriture. Aucun éditeur ne revendique l'ingestion autonome d'un dossier de conception complet. Ce constat calibre A5.
5. Le reporting planifié et diffusé est un standard (TestRail), pas un luxe — mais il suppose un canal d'envoi, qui n'existe ni en v1 ni en v2 (§16).
6. L'IA est le différenciateur 2026 du marché, et il est inégalement couvert : Qase (AIDEN), PractiTest (SmartFox) et qTest (Copilot) la facturent au crédit ; Zephyr Scale en a peu, et celle de TestRail reste limitée. Autrement dit, A5 n'est pas du rattrapage — c'est un axe de différenciation, à condition de livrer la revue humaine et la traçabilité de provenance.

Sources

Consultées les 19 et 20/07/2026.

TestRail — Projects and their types · Test suites · General configurations for reports · Activity Summary (Cases) report · User (Test Execution) Workload · Managing user permissions and roles · Moving, copying, deleting and restoring test cases · Import test cases from CSV or Excel · Migration: CSV & Excel · Quick Start: Generate Test Cases with AI · AI & Innovation · Platform

Xray — Test Repository · Test Sets vs Test Plans · Importing Manual Tests using Test Case Importer · Importing Tests with (CSV) · AI Test Case Generation (documentation) · Smarter Test Design: AI Test Case Generation (blog)

Zephyr / SmartBear — Work with Test Cases (archivage) · Archived and released versions · Zephyr (HaloAI) · Atlassian — Jira and Zephyr Scale

Comparatifs multi-outils (qTest, PractiTest, Qase) — Best Test Management Tools in 2026 · Test Management Tools Comparison 2026 · PractiTest — 20 Best Test Management Tools (2026) · PractiTest — TestRail vs Xray · qasphere — 10 Best Test Management Tools 2026