Modèle de maturité : Votre GPS vers la Quality Assistance

Article 7/7 - Série complète sur la Quality Assistance

C’est le dernier article de cette série.

Après avoir exploré ce que signifie la Quality Assistance, puis observé comment Atlassian, Netflix, OpenClassrooms et ManoMano l’ont incarnée, il reste une question essentielle :

👉 Comment savoir où vous vous situez dans cette transformation ?

Car la Quality Assistance n’est pas un “outil”, ni une “organisation”, ni même une “méthode”.

C’est une évolution progressive. Un déplacement.

D’un modèle centré sur la détection des défauts… vers un système où les équipes construisent ensemble la qualité.

La maturité d’une organisation QA ne se mesure plus seulement par son taux d’automatisation ou le volume de bugs.

Elle se mesure par la capacité à partager la responsabilité, à anticiper les risques, et à prendre des décisions éclairées grâce aux données produits, delivery et production.

Ce dernier article est donc celui de la mise en perspective.

Celui qui vous permet de localiser votre situation actuelle, d'identifier le prochain niveau à atteindre, et de construire une roadmap réaliste et pragmatique.

Bienvenue dans le modèle de maturité de la Quality Assistance.

Pourquoi un modèle de maturité est indispensable

Si chaque entreprise doit trouver son propre chemin, il existe toutefois des paliers universels dans la transformation QA.

Les entreprises n’évoluent pas du jour au lendemain vers une culture “Quality at Speed”.

Elles progressent par phases successives, chacune marquée par un changement de posture :

• du contrôle → à la collaboration
• de l’exécution → à l’accompagnement
• de la détection → à la prévention
• du “QA fait la qualité” → au “tout le monde contribue à la qualité”

Ce modèle — inspiré par Dan Buckland constitue aujourd’hui la référence la plus adaptée aux organisations agiles modernes. Ce modèle est utilisé par ClearScore, OpenClassrooms, et des dizaines d'organisations pour guider leur transformation.

Parce qu’il ne s’intéresse pas seulement aux processus, mais surtout à :

• la culture
• la répartition de la responsabilité
• la maturité technique
• et la capacité des équipes à apprendre ensemble.

C’est ce qui fait toute sa valeur.

Un mot sur les modèles historiques… et leurs limites

Avant d’aller plus loin, il faut dire une vérité simple :

Les modèles comme TMMi, TMAP, ou les grilles ISTQB n’ont pas été pensés pour les organisations modernes.

Ils ont été conçus initialement pour :

• des cycles en V,
• des processus très séquentiels,
• des équipes séparées,
• des validations manuelles,
• des responsabilités centralisées.

Leur vision est essentiellement :

• documentaire,
• prescriptive,
• orientée conformité et audit.

Dans un monde agile, produit, CI/CD, cloud-native, micro-services, ces modèles donnent encore une grille de lecture… mais ils ne capturent pas la dimension culturelle, ni la responsabilisation collective, ni le rôle stratégique du QA en tant que coach.

C’est exactement pour cette raison que des organisations comme Atlassian, ClearScore, Netflix ou ManoMano se sont tournées vers des modèles adaptés à l’agilité.

Et c’est là qu’intervient le modèle de Dan Buckland, à l’origine ce de modèle de maturité de la Quality Assistance disponible aujourd’hui.

Le modèle de maturité Dan Buckland : une évolution en 4 phases

Voici les quatre phases fondatrices du modèle avec une progression qui décrit comment une organisation évolue d’un QA traditionnel vers une approche Quality Assistance mature.

Phase 0 — La QA traditionnelle : le contrôle avant tout

C’est la phase dans laquelle se trouvent… 70 % des entreprises aujourd’hui.

Focus : détecter les défauts

La mission première du QA est de tester et de valider.

Rôle QA : exécuteur

Le QA :

• exécute les tests manuels,
• remonte des bugs,
• valide les correctifs,
• donne le “GO / NO GO”.

Fonctionnement

Le cycle se résume souvent à :

DEV → QA → CORRECTIONS → QA → RELEASE

Conséquences

• Feedback tardif
• Frictions entre équipes (“ils ne testent pas”, “ils bloquent la release”)
• Dépendances structurelles
• Accumulation de dettes
• Effet tunnel total

Cette phase ne date pas d’hier, et elle fonctionne parfois à petite échelle.

Mais elle ne supporte pas la cadence des organisations modernes.

Phase 1 — L’éveil de la Quality Assistance : le Shift-Left

C’est souvent la phase la plus difficile… car elle demande de changer la posture.

Focus : introduire la qualité plus tôt

On découvre qu’en impliquant les QA en amont, on gagne du temps.

Rôle QA : facilitateur

Le QA commence à orienter, clarifier, anticiper.

Il participe aux 3 Amigos, à la préparation des US, aux kickoffs.

Pratiques clés

• Introduction des QA Kickoffs
• Example Mapping
• BDD / Gherkin
• Définition de Done incluant la qualité
• Premiers tests automatisés
• Pair testing occasionnel

Résultats

• Moins de surprises en fin de sprint
• Moins de bugs tardifs
• Croissance du “quality mindset”

Mais la responsabilité qualité reste encore partagée timidement.

Phase 2 — La responsabilité partagée : la Quality Ownership

C’est la phase où les organisations commencent réellement à ressentir l’effet “Quality Assistance”.

Focus : faire de la qualité une responsabilité collective

La bascule culturelle se produit ici : le QA ne teste plus pour les autres, il enables les autres à tester.

Rôle QA : coach, enabler

Le QA :

• accompagne les devs
• développe des outils
• pilote l’amélioration continue
• forme sur les techniques de test
• facilite les rituels qualité (reviews, blitz, exploratoire)

Pratiques clés

• Automatisation mature (unit, integration, API, contract, E2E)
• Coverage piloté par les risques
• CI/CD robuste
• Blitz testing
• Exploratory testing régulière
• Ateliers qualité systématiques
• Développeurs = premiers responsables des tests

Résultats

• Le QA n’est plus un goulot d’étranglement
• Réduction massive du cycle-time
• Amélioration du Defect Escape Rate
• Meilleure collaboration Dev/QA/Product

ClearScore décrit très bien cette phase dans son article :

“Quality Assistance is a model where the entire team takes responsibility for quality. The QA is no longer a gatekeeper.”

Retour terrain : la Phase 1 est le premier grand pas. Les résultats sont visibles rapidement (3-6 mois), ce qui crée le momentum pour la suite.

Phase 3 — L’intégration stratégique : la qualité comme système vivant

Le niveau le plus élevé, atteint par peu d’organisations : Atlassian, Netflix, ManoMano, certaines équipes OpenClassrooms.

Retour terrain : la Phase 2 est l'objectif de la majorité des organisations. C'est le sweet spot entre efficacité et réalisme. Beaucoup s'arrêtent là, et c'est parfait.

Focus : piloter la qualité à l’échelle

La qualité n’est plus un sujet de delivery, mais un sujet stratégique.

Rôle QA : coach transversal et stratège

Les QA deviennent :

• mentors,
• facilitateurs,
• analystes,
• experts en observabilité,
• gardiens des SLO/SLA,
• animateurs de communautés de pratique.

Pratiques clés

• Pilotage qualité data-driven
• Observabilité avancée
• Testing in production (canary, A/B)
• Chaos Engineering (Netflix style)
• Culture de la résilience
• SLO / SLI / SLA applicatifs
• Post-mortems d’apprentissage
• Gouvernance légère mais solide

Résultats

• Incidents maîtrisés
• Feedback loops ultra-rapides
• Capacités d’apprentissage organisationnelles
• Alignement produit / tech / QA
• Impact business mesurable

Comme l’écrit Ministry of Testing :

“Quality Assistance accelerates delivery by enabling teams, not by adding more validation.”

Retour terrain : la Phase 3 est l'aboutissement. Peu d'organisations y sont (Netflix, certaines équipes Atlassian). Ce n'est pas obligatoire pour tout le monde, mais c'est la destination si vous visez l'excellence absolue.

Les transformations humaines derrière le modèle

Ce modèle n’est pas qu’un ensemble de pratiques.

C’est surtout une transformation humaine et culturelle.

Voici ce qui évolue réellement d’une phase à l’autre :

1. La posture du QA

De : exécutant → facilitateur → coach → stratège.

2. La responsabilité

De : QA seule → QA + Dev → Squad → Organisation entière.

3. La synchronisation produit / tech

Du “PO écrit → Dev code → QA teste”

au “nous construisons ensemble la qualité”.

4. La vision de la qualité

De : conformité → prévention → résilience → valeur.

5. La définition même de “tester”

• Phase 0 : exécuter des scripts
• Phase 1 : clarifier les exigences
• Phase 2 : concevoir la stratégie de test
• Phase 3 : piloter un système vivant de fiabilité

C’est cette transformation, et non le tooling, qui crée la valeur.

Comment diagnostiquer votre niveau de maturité ?

Voici une synthèse directement dérivée de ton document Quality Assistance Acculturation — adaptée pour être utilisable comme grille d’autodiagnostic.

Si vous cochez majoritairement :

• Phase 0 → urgence stratégique
• Phase 1 → potentiel énorme
• Phase 2 → transformation en cours
• Phase 3 → excellence maintenable

Construire une roadmap d’évolution pragmatique

Une transformation QA n’est jamais un big bang.

Elle se construit sur 12 à 36 mois, par petites étapes orchestrées.

Voici une exemple de roadmap possible (à adapter en fonction de votre contexte) :

Étape 1 — Redéfinir le rôle QA (mois 1–3)

• Passer du “QA = test” au “QA = enablement”.
• Clarifier le périmètre : tests → coaching.
• Cartographier les responsabilités.
• Former les QA au rôle de facilitateur( notemment sur les softs skills)
• Mettre en place les premiers kickoffs.

Étape 2 — Former les développeurs (mois 3–6)

• Pair testing
• Exploratory testing guidé
• Introduction à l’analyse des risques
• Définition de charte qualité par squad

Étape 3 — Créer une culture de collaboration (mois 6–9)

• QA Kickoffs systématiques
• Reviews qualité sur chaque ticket
• Testing notes
• Blitz testing
• 3 Amigos généralisés
• DoR et DoD incluant des critères qualité

Étape 4 — Mettre en place une infrastructure de qualité (mois 9–12)

• CI/CD robuste
• Tests automatisés à chaque niveau
• Environnements de test stables
• Monitoring et alerting
• Dashboards qualité

Étape 5 — Passer au pilotage stratégique

• SLO / SLI / SLA
• Chaos Engineering
• Quality Gates dans la plateforme
• Pilotage qualité par la donnée
• Communauté de pratique QA/Dev/Product
• Alignement direction produit + direction tech

Les 3 erreurs fatales à éviter

Erreur 1 : Vouloir sauter des phases

Exemple réel : Une organisation en Phase 0 (devs ne testent pas) veut implémenter du Chaos Engineering (Phase 3) parce que "Netflix le fait".

Résultat : Chaos dans le chaos. Bugs en production. Panique. Retour en arrière.

La leçon : Respectez les étapes. Chaque phase prépare la suivante.

Erreur 2 : Copier un modèle sans l’adapter

Exemple réel : "On va faire comme Atlassian" → Copie des 6 stages sans comprendre le contexte.

Résultat : Pratiques plaquées, résistance, échec.

La leçon : Inspirez-vous, n'imitez pas. Adaptez à VOTRE contexte.

Erreur 3 : Manquer de patience

Exemple réel : Organisation abandonne après 6 mois sans résultats visibles (alors qu'elle est en Phase 0 → Phase 1, qui prend 12 mois).

Résultat : Transformation avortée, retour à l'ancien modèle, équipes démoralisées.

La leçon : Chaque phase prend du temps et depend de chaque contexte. Tenez le cap.

Le vrai message : la Quality Assistance est un voyage

Il faut le dire franchement : très peu d’entreprises sont réellement en Phase 3.

Et ce n’est pas grave.

La Quality Assistance n’est pas un idéal à atteindre.

C’est :

• une philosophie
• une démarche
• un continuum d’apprentissage
• une manière plus moderne, plus efficace et plus humaine de travailler.

Ce modèle vous permet simplement de répondre à une question clé :

Quel est le prochain pas à franchir pour améliorer votre logiciel, votre delivery, et votre collaboration ?

Ce n’est pas une fin.

C’est le début d’un cycle.

Et si vous avez suivi cette série d’articles depuis le début, vous savez maintenant que la qualité n’est pas un rôle.

C’est un système vivant.

Et qu’il faut des femmes et des hommes capables de le faire respirer.

FAQ — Modèle de maturité & transformation QA

Q1. Est-ce que toutes les organisations doivent viser la phase 3 ?

Non. Le bon niveau de maturité dépend du contexte : taille, secteur, criticité du produit, structure technique. L’important est d’avancer.

Q2. Peut-on être à plusieurs phases à la fois ?

Oui. Une organisation peut être en phase 2 en mobile et en phase 0 en backend. C’est normal — et même attendu.

Q3. Comment savoir si on est prêt pour la phase 2 ?

Quand les développeurs sont capables d’écrire des tests fiables, et que les QA passent plus de temps à accompagner qu’à exécuter.

Q4. Le rôle du QA disparaît-il à terme ?

Non. Il évolue. Le QA devient un coach, un expert, un stratège, un facilitateur. Son impact augmente - il ne diminue pas.

Q5. Quels sont les signaux qu’une organisation a atteint la phase 3 ?

• Peu de bugs en production
• Développeurs autonomes sur le test
• Forte observabilité
• Post-mortems systématiques
• Leadership aligné
• QA = expert transverse, pas exécuteur

Références

1. Dan Buckland — Taking a phased approach to adopting Quality Assistance (ClearScore, Medium)
2. Ministry of Testing — Better Software, Faster: A Tester’s Report on the Quality Assistance Model

Plus d’articles comme celui-ci