Je tiens tout d’abord à remercier chaleureusement Marc Hage Chahine pour le temps qu’il m’a accordé afin que je lui présente QAlityOS, ainsi que pour l’opportunité de m’exprimer sur la Taverne du Testeur. C’est un véritable honneur.
Je suis consultant QA, actuellement en mission dans un grand groupe audiovisuel français. Sur mon temps libre, j’ai voulu créer l’outil qui me manquait au quotidien : un couteau suisse pour le QA qui travaille avec Jira et Xray.
Une situation que vous connaissez sûrement
Vendredi soir. La release est prête. Le plan de test est monté, les exécutions sont créées, les cas de tests sont liés, la campagne est calée pour une mise en production lundi ou mardi.
Lundi matin, on vous demande en urgence d’ajouter deux ou trois tickets au périmètre. Un autre saute. Et une User Story a finalement évolué, avec du code revu dans la foulée, donc des cas de tests à reprendre.
Le lendemain, on vous annonce un gel de MEP pour la période des congés de Noël.
J’ai vécu cette scène plus d’une fois. Le problème n’était jamais vraiment le changement lui-même, qui fait partie du métier, mais le temps qu’il fallait ensuite pour le répercuter partout. Refaire la campagne, retrouver les tests impactés, remettre à jour la documentation.
Le constat de départ
Comme beaucoup d’entre nous, je passe une bonne partie de mes journées dans Jira, Xray et Confluence. Et un constat revenait sans cesse : une part importante de ce temps est consacrée à produire, mettre à jour ou rechercher de l’information, plutôt qu’à réellement tester. Écrire des cas de tests, maintenir leur cohérence quand les User Stories évoluent, préparer des campagnes, rédiger les PV de recette, produire les release notes, analyser la couverture… Autant de tâches indispensables, mais souvent répétitives.
Quand l’IA générative est arrivée, je me suis demandé si elle pouvait devenir un véritable assistant du QA, et pas seulement un générateur de texte. C’est de cette question qu’est né QAlityOS.
D’abord comprendre : mesurer la maturité QA d’un projet
Avant même de vouloir automatiser quoi que ce soit, j’ai voulu comprendre. Pourquoi certains projets rendent-ils ces lundis matin si douloureux ? Pourquoi un projet semble-t-il difficile à maintenir ? Pourquoi certaines équipes accumulent-elles plus de dette qualité que d’autres ? Ce sont des choses que l’on ressent souvent intuitivement, mais que l’on ne mesure presque jamais.
Le module d’audit est le premier que j’ai construit, et il est resté la porte d’entrée de l’outil. En dix à quinze minutes, l’application analyse un projet Jira et en tire un diagnostic structuré autour de quatre axes : la couverture de test, la qualité et la testabilité du backlog, l’activité d’exécution, et l’hygiène du processus. Chaque axe est situé sur une échelle de maturité, du plus fragile au plus solide.
Pour y parvenir, l’outil combine deux approches. D’un côté, des mesures factuelles calculées sur l’ensemble des tickets : ancienneté, temps de traitement, taux de réouverture des bugs, couverture des critères d’acceptation, régularité du flux. De l’autre, une lecture assistée par l’IA qui analyse la clarté des descriptions, repère les schémas problématiques récurrents et met en perspective les points forts comme les zones de risque.
Le résultat n’est pas une note. C’est un rapport qui situe le niveau de maturité QA du projet, mais surtout qui met en évidence des recommandations concrètes, classées par priorité et rattachées à de vrais tickets. Dans sa version la plus complète, il va jusqu’à analyser les pratiques d’équipe, sur des données anonymisées, ainsi que la gouvernance documentaire dans Confluence. L’objectif n’est pas de distribuer un score, mais d’aider l’équipe à savoir où porter ses efforts en premier.
[VISUEL : capture d’un rapport d’audit — bandeau de maturité, les quatre axes, et un extrait de recommandations.]
Un copilote, pas un remplaçant
Une fois le diagnostic posé, il faut agir. C’est là que la génération intervient.
Dès le départ, je ne voulais pas d’un outil qui remplace le métier de QA. Je pense au contraire que la décision doit toujours rester humaine.
L’idée est simple : l’IA propose, le QA garde le contrôle. Rien n’existe dans Jira, Xray ou Confluence sans avoir été relu, modifié, validé ou rejeté par le testeur. Il ne s’agit pas d’automatiser le métier, mais de récupérer du temps sur les tâches répétitives pour le consacrer à ce qui fait la vraie valeur d’un QA : comprendre le produit, challenger le besoin, explorer et analyser les risques.
Générer directement dans son environnement de travail
Je ne voulais pas d’un outil de plus où l’on copie-colle du contenu entre deux applications. QAlityOS s’intègre donc directement à Jira, Xray et Confluence, et peut assister la rédaction de la plupart des artefacts du quotidien : cas de tests manuels, User Stories, rapports d’anomalies, plans et PV de recette, rapports de mise en production, release notes, documentation Confluence.
Pour la génération de cas de tests, il est possible d’ajouter une maquette ou une capture d’écran afin de donner du contexte à l’IA. C’est un axe que je souhaite nettement renforcer dans les prochaines versions, avec une meilleure exploitation du visuel pour produire des scénarios plus pertinents.
Industrialiser certaines activités QA
Au fil du développement, une autre idée s’est imposée : aider les équipes à préparer et à maintenir leur patrimoine de tests, et pas uniquement à produire du contenu à la volée.
Côté préparation, QAlityOS peut construire automatiquement, à partir des informations présentes dans Jira, un plan de tests, ses exécutions et les liens avec les cas de tests concernés. Une fois la préparation validée, l’ensemble se publie en un clic dans Jira et Xray. On revient à la scène du début : quand le périmètre bouge lundi matin, reconstruire la campagne ne coûte plus une demi-journée.
Côté maintien, deux fonctionnalités s’attaquent à un problème que je trouve trop peu outillé, la dette documentaire.
La première détecte les User Stories qui ont évolué dans Jira et identifie les cas de tests potentiellement impactés. Elle propose alors les ajouts, les modifications ou les suppressions à effectuer, toujours avec validation humaine avant toute mise à jour. Cette possibilité de proposer une suppression compte autant que le reste : un patrimoine de tests qui ne fait que grossir finit par coûter plus qu’il ne rapporte, et savoir retirer un test devenu obsolète fait partie de son entretien.
La seconde repère les User Stories qui ne sont couvertes par aucun cas de test. Il suffit de sélectionner celles qui nous intéressent pour générer les scénarios correspondants.
Ces deux fonctionnalités partagent le même parcours, résumé ci-dessous : l’outil détecte, l’IA propose, le QA valide, et ce n’est qu’ensuite que quoi que ce soit est publié.
VISUEL : schéma du parcours de synchronisation — US modifiée / US non couverte → détection → proposition IA → validation humaine → publication Jira & Xray.
Tenter de chiffrer le coût de la dette qualité
Le module d’audit m’a donné le diagnostic. Restait une question : combien coûte réellement ce qu’il révèle ?
C’est l’objet du dernier module, encore en développement, la Roadmap QA. Il se nourrit en partie de l’audit et intervient donc après lui. L’idée est d’aller au-delà du constat, en proposant une estimation chiffrée, en euros, de la dette qualité d’un projet, selon des critères ajustables au contexte de chaque entreprise.
Je préfère être clair : c’est encore un axe de recherche. Aucune estimation de ce type ne sera jamais exacte, et ce n’est pas le but. Ce que je cherche, c’est un ordre de grandeur qui permette d’arbitrer, et qui rende discutable devant un management ce qui reste trop souvent un ressenti de QA. C’est probablement le sujet qui m’enthousiasme le plus aujourd’hui.
Et les données ?
C’est une question légitime, alors autant y répondre directement.
Aujourd’hui, QAlityOS s’appuie sur Claude pour la génération. Les données Jira nécessaires au fonctionnement sont enregistrées dans votre workspace, hébergé sur des serveurs situés en Europe. Quant aux données transmises au modèle pour être traitées, elles passent par l’API commerciale d’Anthropic, dont les conditions prévoient qu’elles ne servent pas à entraîner les modèles. C’est un choix d’architecture que j’assume : garder les données au sein de l’Union européenne, et ne travailler qu’avec des fournisseurs d’IA dont les conditions commerciales protègent vos contenus, me paraît la moindre des choses vis-à-vis d’équipes qui manipulent parfois des informations sensibles.
Ce socle va s’élargir. L’un de mes prochains chantiers est de permettre aux entreprises qui le souhaitent d’utiliser leurs propres accès aux modèles d’IA, avec leurs propres clés. L’objectif est double : leur laisser la maîtrise de leur relation avec le fournisseur d’IA, et ouvrir le choix du modèle. Je veux à terme que QAlityOS ne soit pas lié à un seul moteur, mais puisse s’appuyer sur plusieurs, avec une attention particulière pour les modèles open source et open weight.
Je réfléchis par ailleurs à une mémoire projet et une mémoire applicative, sur données anonymisées, afin que l’outil apprenne des usages réels et des sensibilités de chacun. C’est un chantier que je veux mener avec beaucoup de précautions, et de préférence en discutant avec ceux que le sujet inquiète plutôt qu’en avançant seul.
Ce que l’outil ne sait pas encore faire
QAlityOS est une première version, et il me semble plus utile d’en nommer les limites que de les passer sous silence.
L’IA peut se tromper. Elle produit parfois des cas de tests trop génériques, ou passe à côté d’un cas limite évident pour qui connaît le produit. C’est bien pour cette raison que la validation humaine n’est pas une option de confort, mais le cœur du fonctionnement. Quant à l’estimation de la dette, je l’ai dit, elle est encore exploratoire.
La prise en compte des maquettes, elle aussi, reste basique : un seul visuel, exploité de façon encore un peu sommaire, même si les résultats sont déjà encourageants. C’est le prochain gros chantier. Je veux pouvoir en fournir plusieurs à l’IA, et je regarde ce que donneraient d’autres formats, la vidéo notamment, pour capter un parcours plutôt qu’un écran figé. C’est un sujet sur lequel j’aimerais beaucoup avoir des retours : qu’attendriez-vous concrètement d’une IA qui « voit » vos maquettes ?
Cela ne me dérange pas d’exposer ces limites. En revanche, prétendre l’inverse me dérangerait beaucoup.
Une parenthèse sur la façon dont tout cela a été construit
Quand j’ai commencé, ni Codex ni Claude Code n’existaient. Je développais avec les chats web de ChatGPT et de Claude, en recollant à la main les bons morceaux de code dans le contexte à chaque échange, en espérant ne rien oublier d’important. C’était un exercice d’équilibriste permanent.
Les outils ont beaucoup changé depuis, et coder comme déboguer sont devenus nettement plus confortables. Je le mentionne parce que cela me semble parlant : en un peu plus d’un an, la manière même de construire un outil s’est transformée. C’est aussi ce qui rend cette période aussi intéressante à vivre pour ceux qui, comme nous, travaillent sur la qualité de ce qui est produit.
Une première version, construite avec la communauté QA
Le projet est loin d’être terminé, et c’est ce qui rend l’aventure passionnante. Je fais aujourd’hui tester l’application par des professionnels du test, afin de confronter mes idées au terrain. Chaque échange me pousse à remettre en question certaines fonctionnalités, à en améliorer d’autres, ou à en imaginer de nouvelles.
Le couteau suisse du départ s’est révélé plus vaste que prévu, et il continuera sûrement de s’élargir. Mais mon ambition n’est pas de construire mon outil idéal : c’est de construire un outil qui rende réellement service à la communauté QA. Les retours de personnes comme Marc, et de tous les bêta-testeurs qui acceptent de donner un peu de leur temps, sont donc particulièrement précieux.
Si le sujet vous parle et que vous avez envie de mettre les mains dedans, ou simplement de me dire que je me trompe quelque part, je serai ravi d’échanger. C’est comme ça que ce projet avancera.
A propos de l’auteur:
Après plus de 8 ans dans l’IT, dont plus de 6 ans consacrés à la qualité logicielle, j’exerce aujourd’hui comme consultant QA. Certifié ISTQB Foundation et PSPO I, j’interviens sur l’ensemble du cycle de test, de la définition de la stratégie jusqu’à la validation des livraisons.
Passionné par l’évolution du métier et les possibilités offertes par l’IA, j’ai créé QAlityOS, un copilote connecté à Jira, Xray et Confluence. Son objectif : aider les équipes à auditer leurs projets, analyser les risques, améliorer la couverture des exigences et produire leurs livrables QA, tout en conservant la validation humaine au cœur du processus.
Contact : nicolas@qalityos.io
