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 :

1. 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.”

3. 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.

3.1. Les champs indispensables dans un ticket Jira

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

• Title clair, actionnable et précis
• Steps to reproduce complets
• Expected vs Actual behavior
• Environment (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
• Label device : web, iOS, Android, tablette
• Label criticité (basé sur une règle partagée)

3.2. Une taxonomie simple pour catégoriser les bugs

Inspirée de CQO-at-work et des bonnes pratiques qualité :

Familles de causes potentielles :

1. Compréhension : mauvaise interprétation d’une user story
2. Process / communication : manque de clarification, non-respect d’une étape
3. Données : dataset invalide, mock incohérent
4. Code / logique : erreur algorithmique, gestion des edge cases
5. Interface / UX : incohérence UI, problème d’accessibilité
6. Tests : cas manquants, automatisation absente
7. CI/CD / environnements
8. Humain : erreur non systémique
9. Dépendance externe : API, intégration tierce

3.3. Exemple concret d’un template Jira optimisé RCA

Title : [Module] Cas non traité : panier vide après refresh sur Android
Environment : Staging / Android 14 / Pixel 5
Steps to reproduce :
Expected :
Actual :
Device :
Impact :
Severity :
Type d’anomalie :
Root cause (préliminaire) :
Screenshot / Vidéo :

Avec une structure comme ça, 70 % du RCA est déjà gagné.

4. 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.

4.1. 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.

Comme le souligne Niarsdet :

“Les développeurs sont souvent la dernière étape visible, pas l’origine du problème.”

4.2. Le diagramme d’Ishikawa (arête de poisson)

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.

4.3. Le “causal tree” (arbre des causes)

Pour les incidents critiques, notamment en production.

On part de l’événement déclencheur puis on déploie les ramifications :

• Contexte
• Causes directes
• Causes contributives
• Causes profondes

C’est souvent utilisé en SRE, mais parfaitement applicable à la QA.

4.4. Le RCA collaboratif (“Circle of Investigation”)

Technique simple :

1. 5 minutes → chaque personne note les causes probables
2. 10 minutes → mise en commun
3. 10 minutes → consolidation dans Ishikawa
4. 10 minutes → choix des actions correctives
5. 5 minutes → actions préventives

Résultat :

On élimine la culture du blâme.

Tout le monde apprend.

Et la QA devient un agent de facilitation.

4.5. Le RCA “par les données”

Les meilleures équipes que j’ai vues font systématiquement appel à :

• logs
• analytics
• monitoring
• traces techniques
• heatmaps
• replay utilisateur

Pourquoi ?

Parce que les données objectivent, elles réduisent les débats et les biais.

Comme le rappelle OpenIT :

“Une analyse n’a de valeur que si elle s’appuie sur des faits mesurables.”

5. Comment organiser un RCA dans une équipe produit / QA

5.1. 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

5.2. Qui doit être présent ?

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

5.3. 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)

5.4. 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

6. Comment le RCA transforme la culture qualité

6.1. 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

C’est l’effet systémique que décrit CQO-at-work :

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

6.2. 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

6.3. 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.

7. Exemple complet de RCA appliqué à un bug réel

1. Contexte

Une application e-commerce voit le panier se vider aléatoirement.

2. Ticket Jira (bien structuré)

• Device : Android
• OS : 14
• Module : Checkout
• Criticité : élevée
• Étapes de reproduction : OK
• Comportement attendu vs réel : OK
• Vidéo jointe : OK

3. Observation

Le bug apparaît après un refresh.

4. 5 Pourquoi

1. Pourquoi le panier se vide ?

→ La session est réinitialisée.

2. Pourquoi la session est réinitialisée ?

→ Le token d’auth expire après 5 min.

3. Pourquoi expire-t-il aussi vite ?

→ Paramètre de sécurité par défaut non modifié.

4. Pourquoi ce paramètre n’a pas été modifié ?

→ Aucun owner identifié pour la config mobile.

5. Pourquoi aucun owner ?

→ Le process d’onboarding du projet ne prévoit pas l’attribution des responsabilités config.

👉 Cause profonde : manque de RACI sur la configuration mobile.

5. Ishikawa (abrégé)

• Process : manque de RACI
• Outils : pas de monitoring de refresh
• Données : token default
• UX : pas de message utilisateur
• Code : pas de gestion du cas refresh

6. Actions correctives

• Étendre la durée d’expiration à 30 min
• Ajouter un mécanisme de sauvegarde panier
• Journaliser les expirations

7. Actions préventives

• Nouveau RACI sur config mobile
• Checkliste onboarding dev + QA
• Tests automatiques sur refresh panier

8. Résultat après 2 sprints

✔ 0 occurrence

✔ Réduction des tickets support

✔ Meilleure stabilité Checkout

8. Comment mesurer la qualité et l’impact du RCA

Indicateurs concrets :

• Nombre de bugs récurrents
• Taux de tickets ayant une cause profonde identifiée
• Taux de régressions par sprint
• MTTR (Mean Time To Recovery)
• Nombre d’actions préventives implémentées
• Diminution des retests
• Satisfaction utilisateur (NPS / reviews)

9. Les meilleures pratiques pour ancrer le RCA dans une équipe

• Rendre obligatoire la catégorie “Root cause” dans Jira
• Faire un RCA pour chaque incident majeur
• Documenter les RCA dans un espace partagé
• Tenir un “RCA Friday” (30 minutes par semaine)
• Faire participer les devs ET les PM
• Former l’équipe aux 5 Pourquoi dès l’onboarding
• Mettre en place un champion RCA (QA senior)

10. Conclusion : Le RCA n’est pas un outil, c’est une culture

La force du RCA ne réside pas dans un tableau, un diagramme ou une méthode.

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

Si tu veux faire progresser ton équipe produit, commence par un RCA simple cette semaine.

Tu verras : c’est un petit changement qui produit un impact énorme.

FAQ – Root Cause Analysis (12 questions essentielles)

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

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

2. 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.

3. Un RCA doit durer combien de temps ?

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

4. 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.

5. 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.

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

Focalisation sur les faits, pas sur les personnes.

Suppression du vocabulaire accusatoire.

Données > opinions.

7. Peut-on combiner plusieurs méthodes ?

Oui. Souvent : 5 Pourquoi → Ishikawa pour affiner.

8. Comment savoir si un RCA est “bon” ?

S’il aboutit à :

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

9. Faut-il toujours des preuves avant de conclure ?

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

10. Que faire si les causes profondes sont organisationnelles ?

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

11. Peut-on utiliser le RCA en Discovery ?

Oui. Pour analyser les problèmes utilisateurs ou les irritants dès l’amont.

12. Comment mesurer l’impact long terme ?

Baisse des régressions, augmentation de la vélocité, stabilité en production.

Références

• Niarsdet — 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