Cette semaine, nous vous présentons un profil brillant qui publie régulièrement sur l’IA et le testing. Daura Rady a un background fintech et une expertise métier et technique rare. Elle porte aujourd’hui plusieurs casquettes : QA Automation Engineer, crowdtester, créatrice de contenu IA et testing. Dans cette interview, vous découvrirez des clés que vous pourrez vous aussi actionner dans votre quotidien de QA pour progresser. Bonne lecture !
Présentation
Comment es-tu arrivée dans le métier du test ? Où en es-tu aujourd’hui ?
Je suis arrivée à la QA par la finance, pas par l’informatique. Et c’est ce détour qui a façonné ma conviction la plus forte : tester, ce n’est pas vérifier qu’un produit fonctionne, c’est gérer un risque.
La finance m’a appris le poids du risque, l’automatisation m’a appris à choisir les bons risques à couvrir, le crowdtesting m’a appris que le terrain réel casse toujours les certitudes de laboratoire, et l’IA m’apprend aujourd’hui à superviser des systèmes capables de tester à ma place. C’est ce fil rouge qui relie tout ce qui suit.
Mission et vision du métier
Si tu devais résumer ton rôle en une seule mission, ce serait laquelle ?
Ma mission, c’est de traduire la complexité technique en confiance business. Quand un produit sort en production sans incident, quand un utilisateur fintech termine son parcours sans friction, quand une équipe livre sereinement parce qu’elle sait que les risques majeurs sont couverts, c’est là que je vois l’impact réel de mon travail.
Derrière cette phrase, deux enjeux me guident : protéger le business et protéger l’image de marque. Un incident en prod dans la fintech, ce n’est pas un ticket Jira qui clignote en rouge. C’est un client qui part, une amende ACPR, une obligation DSP2 qui te tombe dessus.
Et mon rôle va plus loin que l’exécution. Je veux vulgariser les bonnes pratiques de QA et d’automatisation, parce que trop d’équipes confondent encore automatiser et couvrir. Tu peux avoir 500 tests verts et zéro confiance dans ta prod. À long terme, j’ai envie de transmettre, de former, et de construire mes propres outils pour rendre le testing plus intelligent.
Une bonne QA ne se mesure ni au nombre de scripts qu’elle écrit, ni au nombre de bugs qu’elle détecte, mais au nombre de bugs qu’elle empêche d’exister.
Où se situent, pour toi, les frontières du rôle de QA ?
Pour moi, la QA couvre toute la chaîne, de l’écriture du besoin jusqu’au monitoring de production, et même au-delà.
Le shift left, c’est intervenir au refinement : challenger la User Story, proposer des critères d’acceptance testables, repérer les zones floues avant que la première ligne de code soit écrite. Une ambiguïté non levée à ce stade, c’est un bug garanti en prod.
Le shift right, c’est ne pas s’arrêter au go-live : lire les dashboards de monitoring, surveiller les alertes, aller chercher le feedback utilisateur là où il vit vraiment, sur l’App Store, dans les avis Google, sur les forums. Les utilisateurs réels voient ce que nos tests ne voient pas.
Entre les deux : le design technique, les revues de testabilité, l’automatisation, la CI/CD, la collaboration permanente avec les devs et les PO. La QA n’est pas une étape de fin de chaîne, c’est une fonction transversale.
Et je vais plus loin que la transversalité. Je ne vois pas la QA comme une simple fonction de contrôle au service du PO ou du PM. Je la vois aussi comme une fonction de construction du produit. Quand je challenge une User Story au refinement, que je débusque une incohérence métier, que je propose un parcours alternatif ou que je défends l’utilisateur réel face à une logique trop théorique, je ne me contente pas de valider, je participe à façonner le produit. Mon passage par la finance et l’accompagnement de startups SaaS sur leur vision produit me font lire une fonctionnalité avec les yeux d’un product builder : est-ce que ça crée de la valeur, est-ce cohérent, est-ce que ça sert vraiment l’utilisateur, avant même de me demander si c’est testable. Le PO porte le quoi et la valeur métier, le dev porte le comment, et la QA garde le pourquoi : pourquoi cette feature existe, et pour qui elle ne doit jamais casser.
La QA n’est pas la police du code. C’est le garde-fou du business, du besoin jusqu’au feedback utilisateur.
L’IA dans sa pratique quotidienne
Peux-tu nous raconter ton cheminement, de la découverte des modèles à la maîtrise que tu as aujourd’hui ?
Mon rapport à l’IA n’a pas commencé avec le buzz récent sur les agents. Il a commencé bien plus tôt, dans un contexte qui n’a rien à voir avec le testing : la finance.
Dès 2021, dans mes fonctions en investissement, j’utilisais déjà les modèles d’OpenAI (GPT-3, alors en bêta, bien avant le lancement grand public de ChatGPT fin 2022) comme copilote de réflexion. Rédiger des emails, structurer des analyses, dégrossir une note d’investissement de cinquante pages : l’IA me faisait gagner un temps considérable sur la production pure, pour que je puisse concentrer mon énergie là où elle compte vraiment, l’analyse, le raisonnement, la négociation. C’est là que j’ai compris une chose que je garde encore aujourd’hui : l’IA n’est pas là pour penser à ta place, elle est là pour te libérer du temps de cerveau.
J’ai gardé ce réflexe en basculant vers la QA. Fin 2024, début 2025, je développais un générateur de cas de test à partir de User Stories, en branchant directement les API d’OpenAI. L’idée était simple : prendre une US brute, la structurer avec un prompt, et en sortir des scénarios Gherkin avec les cas nominaux, les cas négatifs et les edge cases. Le projet est resté privé sur mon repo Git, puis une mission a pris le dessus et je l’ai mis en pause. Mais il m’a laissé une conviction : l’IA n’a d’intérêt en QA que si elle résout un vrai problème de terrain. De cette conviction est né mon laboratoire personnel : un espace d’expérimentation où je propulse la gestion des tests au niveau supérieur grâce à l’apprentissage automatique (Machine Learning) et au traitement du langage naturel (Natural Language Processing). Depuis, l’écosystème a mûri.
Concrètement, j’utilise le traitement du langage naturel pour que mes outils de test « lisent » et comprennent les rapports de bugs ou les scénarios écrits en français par les humains. En parallèle, j’exploite l’apprentissage automatique pour analyser l’historique de l’application et prédire précisément là où le code risque de casser.
Avec le Model Context Protocol, un agent peut piloter un navigateur via l’accessibility tree plutôt que via des screenshots : c’est déterministe, auditable, exploitable pour le testing. J’ai publié plusieurs carrousels pour expliquer cette architecture à la communauté, notamment la différence entre Playwright MCP et l’approche CLI classique.
Ce qui m’intéresse, ce n’est pas l’IA gadget, c’est l’IA qui résout des problèmes concrets :
- générer des scénarios depuis des US, pour gagner du temps en design de tests ;
- self-healing des locators, pour réduire la maintenance des suites ;
- analyse des traces d’échec en CI, pour diagnostiquer la flakiness plus vite ;
- évaluation des sorties de LLM, avec des outils comme Promptfoo, parce que tester un système non déterministe demande une autre discipline que tester du code classique.
J’utilise aussi l’IA comme outil de montée en compétence. Quand je veux démystifier un concept, je me le fais expliquer à trois niveaux : comme à un enfant, en contexte terrain, puis en vision expert. Cette méthode m’a fait progresser vite sur le MCP, les patterns avancés de Playwright et les architectures de tests distribués.
Je me positionne sur ce que la communauté appelle l’AI Supervisor. Une senior QA en 2026 n’écrit plus uniquement des scripts : elle calibre des agents, relit leurs traces pour vérifier que leur logique colle à l’intention métier, et encode la connaissance produit dans des prompts et des skills.
En 2026, le job n’est plus d’écrire des scripts. C’est de calibrer l’agent, de lire ses traces, et de garantir que sa logique reflète le risque métier réel.
Les grandes leçons de l’automatisation
Quelles sont les plus grandes leçons que tu as apprises en automatisation ?
Leçon numéro un, celle que j’aimerais graver au-dessus du bureau de chaque QA junior : la stratégie d’automatisation passe avant l’outil.
Beaucoup d’équipes sautent sur Playwright, écrivent 200 tests E2E en trois mois, et héritent d’une suite lente, flaky, ingérable. Le problème vient rarement de l’outil, il vient de l’absence de stratégie. Trois préalables avant d’automatiser sérieusement :
- un environnement stable, parce que si ton env de test tombe un jour sur trois, tes tests ne mesurent plus la qualité du produit, ils mesurent la météo de ton infra ;
- une couverture unitaire existante, sinon toute la pyramide bascule vers le E2E, lent et fragile ;
- un risk-based testing assumé, parce qu’on ne peut pas tout automatiser et qu’il faut couvrir d’abord les parcours qui portent le chiffre d’affaires, la conformité, les données sensibles.
Leçon numéro deux : la flakiness n’est pas une fatalité, c’est un symptôme. Un test instable révèle presque toujours autre chose : un wait mal posé, un DOM dynamique mal géré, une API lente, ou une couche de cache qui sert des assets périmés (un classique que j’ai détaillé dans un carrousel, parce que peu de gens y pensent). La vraie réponse à la flakiness n’est jamais le retry aveugle, c’est le déterminisme : attendre une réponse réseau précise avec waitForResponse, poller un état avec expect.poll, plutôt que de poser un waitForTimeout au hasard.
Leçon numéro trois : les tests API offrent le meilleur retour sur investissement. Rapides, déterministes, indépendants du rendu. Et l’API est souvent le vrai contrat, même derrière une UI. Sur un exercice où je devais tester les GitHub Issues, j’ai découvert que toute l’interface communique exclusivement en GraphQL. Plutôt que de me battre avec le DOM, j’ai testé en attaquant directement la couche GraphQL et en gardant l’UI pour les parcours critiques : approche hybride, tests bien plus rapides et bien plus stables. Avant d’empiler du E2E, je regarde toujours ce que je peux sécuriser au niveau API.
Tester en environnement financier
Qu’est-ce que ça change concrètement dans ta manière de tester ?
Ça change tout. Et soyons clairs : le plus difficile, ce n’est pas la technique de test. C’est la priorisation et l’analyse de risque. Parce qu’en environnement financier, le plus difficile n’est pas la technique de test. C’est la priorisation. Entre les parcours d’authentification, les données personnelles, les opérations financières, les règles de conformité et les multiples profils utilisateurs, tout semble important. La vraie compétence consiste à comprendre le métier suffisamment bien pour identifier les risques qui méritent le plus d’attention.
Le piège est exactement là. Quand tout paraît critique, deux réflexes mortels apparaissent : soit tu essaies de tout tester, et tu te noies dans une suite lente et impossible à maintenir, soit tu te paralyses. La compétence qui sépare une QA junior d’une senior dans ce contexte, c’est de trancher : distinguer ce qui semble critique de ce qui l’est vraiment. Je m’appuie sur une lecture impact x probabilité, mais le plus dur n’est pas la matrice, c’est la discipline et la compréhension métier qu’il faut pour assumer de dire « voilà ce qu’on couvre en premier, et voilà pourquoi », et pour le défendre devant un PO ou un métier qui te jure que tout est prioritaire.
Au-delà de la priorisation, deux réflexes que la finance m’a ancrés :
- Les combinaisons métier sont infinies, il faut échantillonner intelligemment. Sur un produit d’épargne salariale, ou sur une plateforme de gestion de crédit, il y a des millions de combinaisons. Je travaille par personas calibrés sur la base client réelle : quels profils représentent 80 % du volume ? Ce sont eux que je couvre d’abord.
- La conformité n’est pas une option. RGPD, DSP2, KYC, AML, piste d’audit : ce sont des exigences testables, pas des annexes juridiques qu’on lit à la fin.
Un exemple qui résume bien tout ça : sur une application d’analyse d’appels d’offres, je devais vérifier la cohérence entre les montants affichés dans un dashboard et ceux générés dans un export Excel. Les règles métier évoluaient régulièrement, donc l’enjeu n’était pas d’automatiser aveuglément chaque formule. L’objectif était plutôt de sécuriser un contrat stable : à règle donnée, les montants visibles à l’écran devaient rester cohérents avec ceux de l’export.
J’ai donc commencé par des contrôles manuels pour comprendre les cas sensibles, puis j’ai identifié les vérifications automatisables : cohérence écran/export, totaux, arrondis et cas à fort impact métier. L’automatisation ne remplaçait pas l’analyse métier, elle sécurisait les régressions sur les règles déjà validées.
Mon métier, c’est de tester des systèmes où les bugs coûtent de l’argent réel. Un test qui passe n’est pas une garantie. Un test pensé pour couvrir le bon risque, c’est une assurance.
Le crowdtesting, un accélérateur de compétences
Comment le crowdtesting vient enrichir ta manière de tester ?
Le crowdtesting, c’est l’une des meilleures écoles terrain pour un testeur. Ça ne tient pas sur un CV classique, mais ça transforme la pratique.
En mission, on travaille souvent dans un cadre stable : même application, mêmes environnements, mêmes interlocuteurs, pendant des mois. En crowdtesting, c’est l’inverse, et c’est là toute sa force : un effet d’accélération. Tu enchaînes une multitude de projets sur un temps très court. En quelques semaines, j’ai pu tester plus de types de produits, de devices et de parcours utilisateurs que sur une année de mission classique. Chaque session est un mini-laboratoire : nouveau produit, nouvelles règles, nouveaux bugs à comprendre en quelques minutes. Ce que ça m’apporte :
- une exposition multi-domaine (UX, accessibilité, paiement, IoT, embarqué) et l’habitude d’aller droit au risque dès la première minute ;
- du device testing réel, parfois sur du matériel envoyé physiquement chez moi, ce qu’on n’a jamais en mission classique ;
- une rigueur de bug report non négociable, parce qu’un rapport flou ou non reproductible est rejeté, point ;
- une veille produit permanente, en testant des produits concurrents ou des marchés différents, ce qui construit une base de référence sur les patterns UX et les erreurs classiques de parcours.
Cette exposition construit quelque chose qu’aucune formation ne donne : une bibliothèque mentale de patterns. À force de voir des dizaines de produits, tu reconnais instantanément les zones qui cassent, les erreurs de parcours récurrentes, les angles morts d’accessibilité. Et tu apprends à te brancher sur un produit inconnu en quelques minutes, puis à aller droit au risque. C’est exactement la compétence d’une senior : changer de contexte vite et repérer le danger tout de suite.
Le crowdtesting m’a surtout appris une chose : un bug mal expliqué est presque aussi inutile qu’un bug non trouvé.
J’y ai gagné en rigueur, en vitesse d’analyse, et surtout en clarté : savoir reproduire, isoler, prioriser et documenter un problème pour qu’un développeur puisse agir vite.
Le crowdtesting n’était pas un complément à mes missions. C’était un véritable laboratoire d’apprentissage.
Une anomalie marquante
Est-ce qu’il y a une anomalie qui t’a particulièrement marquée ?
Le bug qui m’a le plus appris n’est pas le plus spectaculaire. C’est celui qui m’a forcée à comprendre qu’un test ne mesure pas toujours ce qu’on croit.
Sur un pipeline Jenkins, une suite passait systématiquement en local et échouait de façon intermittente en CI. Réflexe de tout le monde : relancer, puis blâmer les tests. Moi, j’ai ouvert les logs.
Deux problèmes combinés. L’agent Jenkins était sous-dimensionné en CPU et mettait trois fois plus de temps à rendre les pages que ma machine de dev. Et un proxy VPN bloquait silencieusement le chargement d’assets CSS externes. Résultat : l’application s’affichait sans styles, et les sélecteurs Playwright ne trouvaient plus les éléments dans un DOM partiellement rendu.
Ce cas m’a appris qu’un test qui échoue en CI n’est pas automatiquement un test flaky. Il peut révéler un écart réel entre l’environnement local et l’environnement d’exécution : ressources plus lentes, dépendances réseau, configuration différente ou rendu incomplet.
Depuis, je ne classe jamais un échec comme “instable” sans analyser les logs, les traces et les différences d’environnement.
La leçon colle exactement à ma vision du métier : un test qui échoue en CI n’est pas forcément un mauvais test, c’est parfois le meilleur signal que tu aies sur l’état réel de ton environnement. Le travail d’une QA, c’est de savoir faire la différence.
Ce qui lui plaît dans la QA
Qu’est-ce qui te plaît le plus dans le métier de QA aujourd’hui ?
Ce qui me plaît, c’est le croisement entre technique, stratégie et impact métier.
J’ai un background finance, pas informatique. En basculant vers la QA, j’ai dû apprendre à coder, comprendre les architectures, lire des logs, automatiser, construire des frameworks, tester des API, maîtriser les pipelines. Personne ne me l’a offert. Alors quand je construis aujourd’hui un framework Playwright avec fixtures typées, page objects, API helpers, gestion du storage state et pipeline multi-environnement, je sais d’où je viens, et ça donne du sens.
Ensuite, la variété. Dans une même semaine, je peux écrire un test Playwright TypeScript, débugger un pipeline Jenkins, challenger une User Story au refinement, documenter un risque métier, et finir par un carrousel LinkedIn pour vulgariser un concept. Je ne retrouve ce spectre dans aucun autre métier tech.
Enfin, l’impact business direct. Quand je détecte un bug sur un parcours de souscription critique avant la prod, je n’ai pas juste fait mon job : j’ai évité une perte de revenu, une plainte client, un ticket régulateur. Voir l’impact de son travail en euros et en image de marque, c’est rare dans la tech.
Le préjugé qu’elle veut combattre
Quel préjugé souhaiterais-tu combattre dans la QA ?
Celui qui dit que la QA, c’est la fin de la chaîne. L’étape qui vient après le dev, juste pour valider. C’est faux, et c’est coûteux.
Une bonne QA intervient dès le besoin et ne s’arrête pas au go-live, je l’ai dit plus haut. Le chiffre qui devrait clore le débat : corriger un bug en production coûte de dix à cent fois plus cher que de l’éviter au refinement¹. Pourtant, la plupart des équipes traitent encore la QA comme une validation finale, pas comme une fonction de prévention.
L’autre préjugé, c’est que la QA serait moins technique que le dev. Concevoir un framework scalable, avec interception réseau, parallélisation, gestion d’authentification et pipeline multi-environnement, c’est coder au même niveau qu’un développeur. La différence n’est pas le niveau technique, c’est l’intention : le dev construit le comportement attendu, la QA cherche à prouver où ce comportement casse.
La QA moderne n’est pas une fonction de validation. C’est une discipline d’ingénierie et de gestion du risque.
Conseil à quelqu’un qui débute
Que conseillerais-tu à une personne qui débute dans la QA ?
Je vais être directe, parce que c’est ce qui m’aurait aidée au début.
Un : commence par la pensée critique, pas par l’automatisation. Apprends à challenger une User Story, à poser les bonnes questions, à raisonner en cas négatifs et edge cases. Automatiser sans comprendre ce qu’on teste, c’est produire du bruit, pas de la valeur.
Deux : le crowdtesting est une école accélérée. Des plateformes comme Tester Work, uTest, Testio ou Tryber t’apprennent à écrire un vrai bug report, à tester sur de vrais devices, et tu es payée pour apprendre.
Trois : choisis une stack et maîtrise-la. En 2026, l’écosystème qui paie et qui dure, c’est Playwright en TypeScript, plus du testing API, plus une bonne base CI/CD. N’essaie pas d’apprendre Cypress, Selenium, Appium et Postman en même temps. Maîtrise une stack à fond, puis élargis.
Quatre : expose-toi. LinkedIn, carrousels, blog, communauté. Pas pour la vanité, pour la crédibilité. Produire du contenu m’a obligée à structurer ma pensée, vérifier mes sources, challenger mes propres convictions. Et ça ouvre des portes en entretien.
Cinq : utilise l’IA comme accélérateur d’apprentissage, pas comme béquille. Fais-lui expliquer un concept à trois niveaux, puis confronte toujours ses réponses à la documentation officielle et au terrain.
La QA, ça s’apprend en questionnant, en cassant, et en comprenant pourquoi ça casse. Pas en récitant des définitions.
_________________________________
¹Finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design phase.” Source : Boehm, B., & Basili, V. R. (2001). Software Defect Reduction Top 10 List. IEEE Computer, 34(1), 135-137.
_________________________________
Merci à Daura pour cette passionnante interview. Nous vous invitons chaleureusement à la suivre sur LinkedIn pour découvrir ses contenus sur l’IA et le test logiciel.
