Root Cause Analysis : l’arme secrète des équipes QA

Pourquoi le RCA change la vie d’une équipe QA

Tu connais sûrement cette situation :

On corrige un bug, on vérifie que ça marche, on ferme le ticket, et hop, on passe au suivant. Mission accomplie, non ? Pas vraiment. Parce qu'on oublie LA question essentielle : pourquoi ce bug a-t-il existé en premier lieu ?

Puis il revient.

On le corrige à nouveau.

Il revient encore.

Et là, un motif classique apparaît :

“C’est encore un bug côté dev…”

C’est humain. C’est simple. Et… c’est presque toujours faux.

C'est là qu'intervient le Root Cause Analysis (RCA), cette méthode qui transforme les QA Engineers d'exécutants en véritables gardiens de la qualité. Le RCA, c'est votre billet pour passer du statut de "testeur qui trouve des bugs" à celui de "professionnel qui élimine les causes des bugs". Et croyez-moi, la différence est énorme.

La cause profonde d’un bug dépasse rarement la simple ligne de code. Elle touche souvent un process, une incompréhension, un outil, une donnée, une mauvaise hypothèse, un comportement utilisateur non anticipé, voire une décision produit ambiguë.

Le RCA, c’est le passage du QA pompier au QA architecte, celui qui ne se contente pas de détecter, mais qui permet au système de ne plus reproduire ses erreurs.

Et dans cet article, je vais te montrer pourquoi c’est l’un des leviers les plus puissants pour faire monter la maturité d’une équipe produit.

Le problème n°1 : des anomalies mal structurées = analyse impossible

On parle souvent de RCA comme d’un exercice analytique, mais en réalité, le combat commence bien avant. La majorité des équipes n’ont pas un problème de bugs. Elles ont un problème…d’information.

Pour 80 % des équipes que j’accompagne, le vrai blocage est là :

👉 les anomalies dans Jira sont insuffisamment structurées.

Il faut donc commencer par structurer vos tickets d'anomalies correctement. Un ticket mal documenté, c'est comme essayer de résoudre une enquête sans indices. Impossible.

Les champs essentiels dans Jira

Voici comment transformer vos tickets Jira en machines à RCA :

Catégorie de la cause racine

Créez un champ personnalisé avec des valeurs comme :

• Logique métier incorrecte
• Gestion d'erreur manquante
• Problème de performance
• Interface utilisateur/UX
• Intégration/API
• Configuration/environnement
• Problème de données
• Architecture/design

“Sans données fiables, toute analyse de causes profondes est vouée à n’être qu’une opinion.”

Pourquoi catégoriser les anomalies est une arme stratégique (pas une case Jira en plus)

La catégorisation est souvent perçue comme une corvée.

“Encore une colonne à remplir dans Jira…”

Mais en réalité :catégoriser, c’est voir les patterns.

Sans catégorisation, tu corriges des symptômes. Avec catégorisation, tu identifies les maladies.

Voici ce qu’on voit apparaître dès qu’on classifie correctement :

1. Bugs de compréhension

User story ambiguë, critère d’acceptation flou, mauvaise interprétation du PO.

C’est probablement la catégorie la plus sous-estimée… et la plus coûteuse.

2. Bugs récurrents sur un même module

Souvent le signe :

• d’un design fragile
• d’un module trop couplé
• d’une dette technique structurelle

3. Problèmes liés au device / OS

Typiquement :

• Android 14 casse une fonctionnalité
• iOS fonctionne mais Android non
• Comportement différent sur tablette

Sans catégorisation device/OS → impossible de le voir.

4. Erreurs environnement / données

Très fréquent :

• jeux de tests non réalistes
• données obsolètes
• environnement instable

5. Problèmes liée à l’automatisation

Flakys, scripts cassés, CI instable.

Ce que tu obtiens grâce à la catégorisation

Une vision systémique. Tu ne corriges plus un bug.Tu identifies une zone à risque, et tu peux agir à la source.

Comment structurer les anomalies pour préparer un RCA efficace

La clé d’un RCA réussi, ce n’est pas le talent analytique du QA.

C’est la qualité des données.

Les champs indispensables dans un ticket Jira

Voici le contenu que j’impose (gentiment) dans mes accompagnements QA :

• Title clair, actionnable et précis
• Steps to reproduce complets
• Expected vs Actual behavior
• Environnement (staging / production / device / OS / version)
• Module / Feature (dossier Jira cohérent)
• Type d’anomalie : compréhension, logique, données, UI, performance, etc.
• Impact (business + utilisateur)
• Screenshot / video obligatoire
• Root cause level 1 (provisoire) : ce qu’on pense avant l’analyse réelle et identifié la réelle root cause. Soit on met à postériori ce champs à jour soit on en crée un autre.
• Label device : web, iOS, Android, tablette
• Label criticité (basé sur une règle partagée)

Les grandes familles de causes racines : comprendre avant de corriger

Pour t’aider à structurer ton analyse, voici une grille basée sur ton podcast + mes audits QA.

1. Compréhension / Communication

• Story ambiguë
• Critèred d’acceptation incomplet
• Pas de 3 Amigos
• Mauvaise transmission PO - Dev- QA

2. Process / Méthodes

“Pas de revue de code. Pas de revue de test. Sprint review bâclée.”

Cette catégorie explose dans les équipes en mode “livrer vite”.

3. Environnement / Données

• Jeux de tests non réalistes
• Données corrompues
• Différences prod / staging
• Environnement instable

4. Outils / Automatisation

• Tests flakys
• CI/CD non fiable
• Scripts non maintenus

5. Compétences / Formation

• Dev peu familiarisé avec le domaine métier
• QA junior sans guidelines
• Onboarding insuffisant
• Turnover

6. Produit / Architecture

• Modules fortement couplés
• Design non scalable
• Comportement non défini dans les cas limites

7. Device / OS / Navigateur

• Fragmentation mobile
• Compatibilité WebView
• Différences de moteurs de rendu

Attention : une anomalie a souvent plusieurs causes. C’est même la norme en RCA.

Les grandes méthodes de Root Cause Analysis en QA

Tu n’as pas besoin de 10 outils.

Tu as besoin d’un état d’esprit et de 2–3 méthodes ultra efficaces.

On va couvrir les principales.

La méthode des 5 Pourquoi

C’est la méthode la plus simple… et l’une des plus puissantes.

Principe :

On pose “pourquoi ?” jusqu’à atteindre la cause systémique. Généralement entre 5 et 7 niveaux.

Exemple QA :

1. Pourquoi le test échoue ?

→ Le code ne gère pas le cas X.

2. Pourquoi le code ne gère pas ce cas ?

→ Ce cas n’était pas dans la story.

3. Pourquoi il n’était pas dans la story ?

→ Mauvaise compréhension des règles métier.

4. Pourquoi la compréhension était mauvaise ?

→ Aucun atelier de clarification (3 Amigos).

5. Pourquoi il n’y a pas eu d’atelier ?

→ Le PO pensait que c’était simple.

👉 Cause profonde : un manque dans le process de refinement, pas un bug dev.La cause profonde n’est pas dans le code. Elle est dans l’input du process.

Le diagramme d’Ishikawa (arête de poisson / cause-effet)

Outil idéal pour les problèmes complexes ou multifactoriels.

Catégories typiques en QA :

• Code
• Environnements
• Données
• Outils
• Process
• Humain

On met le problème en tête, les catégories en arêtes, et on brainstorme en équipe.

Exemple :

“Crash au login en production” →

on identifie une combinaison de causes : données corrompues + absence de test de charge + dépendance API externe + absence de retry.

C’est un excellent outil collectif, beaucoup utilisé dans les retours d’incidents.

Pareto 80/20

20 % des causes génèrent 80 % des bugs.

Si 3 modules concentrent 70 % des anomalies…

ce n’est pas une coïncidence.

C’est une alarme qualité.

Analyse multi-causes

Très souvent, le RCA fait émerger :

• une spécification floue
• un manque de compétence
• une absence de revue
• une donnée invalide

La force du RCA : détecter la combinaison invisible à l’œil nu.

Comment organiser un RCA dans une équipe produit / QA

Quand déclencher un RCA ?

✔ Bug récurrent

✔ Incident de production

✔ Régression majeure

✔ Anomalie coûteuse

✔ Problème “invisible” qui cache autre chose

✔ Bug qui impacte la roadmap

Qui doit être présent ?

• QA (facilitateur)
• Dev (contexte technique)
• PM / PO (vision métier)
• UX (si impact design)
• Support client (impact réel)

Déroulé d’un atelier RCA (30 minutes)

1. Présentation factuelle du bug
2. Vérification des données
3. Application d’une méthode (5 Pourquoi ou Ishikawa)
4. Identification des causes profondes
5. Définition des actions correctives
6. Définition des actions préventives
7. Publication dans un espace partagé (Confluence)

Les pièges à éviter

• Chercher un coupable (“c’est le dev”)
• Se précipiter à la solution
• En rester aux symptômes
• Ne pas structurer le ticket
• Faire un RCA sans données
• Ne pas suivre les actions décidées

Comment le RCA transforme la culture qualité

Un bug = plusieurs améliorations

Un simple bug peut améliorer :

• une règle métier
• un test automatisé
• un monitoring
• une documentation
• un workflow
• une dépendance API
• un design UX

“Un RCA bien mené améliore à la fois la cause directe et les conditions qui l’ont rendue possible.”

Le QA devient “architecte de la qualité”

Tu n’es plus celui qui pointe les erreurs.

Tu deviens celui qui aide l’équipe à comprendre.

Le QA qui maîtrise le RCA :

• éclaire les angles morts
• détecte les patterns
• anticipe les régressions
• améliore les process
• augmente la vélocité de l’équipe

Un gain mesurable sur la vélocité et les coûts

Le RCA :

• réduit les bugs récurrents
• diminue le temps de retest
• améliore la prédictibilité
• évite les faux correctifs
• réduit drastiquement les incidents en prod
• évite les rushs QA de fin de sprint

C’est un investissement qui rapporte énormément.

Le RCA n’est pas un outil, c’est une posture

La force du RCA ne réside pas dans un tableau, un diagramme ou une méthode. L’analyse des causes racines, ce n’est pas une perte de temps. C’est, de loin, la meilleure manière de réduire durablement les anomalies, et la plus belle opportunité pour faire monter ton équipe en maturité

La force du RCA, c’est qu’il :

• permet de comprendre avant d’agir
• supprime les blâmes
• fait grandir l’équipe
• réduit la dette qualité
• prévient les incidents
• améliore la productivité
• transforme le rôle du QA

Elle transforme :

• un bug → en apprentissage
• un testeur → en architecte
• une équipe → en système qui apprend
• un rituel → en choix stratégique

a prochaine fois qu’un test échoue, pose-toi une seule question :

“Est-ce que je veux juste corriger ce bug, ou comprendre pourquoi il existe ?”

FAQ – Root Cause Analysis

À quelle fréquence doit-on faire un RCA ?

À chaque incident majeur ou bug récurrent. Pas pour les anomalies mineures isolées.

Qui doit animer le RCA ?

Souvent la QA, car c’est le rôle le plus neutre, mais n’importe quel facilitateur formé peut le faire.

Un RCA doit durer combien de temps ?

Entre 15 et 45 minutes. Un RCA qui dure 2 heures est un postmortem, pas un RCA.

Quelle est la différence entre RCA et postmortem ?

Le postmortem est un document complet d’après-incident.

Le RCA est l’analyse des causes profondes.

Faut-il faire un RCA sur tous les bugs ?

Non. Seulement sur les bugs récurrents, critiques ou révélateurs de failles systémiques.

Comment éviter que le RCA devienne un procès ?

Focalisation sur les faits, pas sur les personnes.

Suppression du vocabulaire accusatoire.

Données > opinions.

Peut-on combiner plusieurs méthodes ?

Oui. Souvent : 5 Pourquoi → Ishikawa pour affiner.

Comment savoir si un RCA est “bon” ?

S’il aboutit à :

• une cause systémique,
• des actions correctives,
• des actions préventives.

Faut-il toujours des preuves avant de conclure ?

Oui. Pas de RCA sans données factuelles (logs, vidéo, steps, analytics…).

Que faire si les causes profondes sont organisationnelles ?

Les traiter comme n’importe quel bug : créer une action, un owner, un suivi.

Références

• Medium - Stop blaming developers. Perform Root Cause Analysis like a professional QA engineer
• OpenIT - Qualité logicielle et mise en œuvre du RCA
• CQO-at-work - Analyse des causes racines

Plus d’articles comme celui-ci