OpenClassrooms : d’une QA dédiée à une responsabilité commune
Article 5/8 - Série complète sur la Quality Assistance
Et si la fin de la QA était en fait le début de la qualité ?
Chez OpenClassrooms, la transformation n’a pas été choisie.
Elle a été subie, puis assumée.
Contexte économique tendu, réorganisation, recentrage produit…
Et au milieu de tout ça, une décision radicale : supprimer le rôle de QA dédié.
Mais au lieu d’y voir une régression, OpenClassrooms y a vu une opportunité :
celle de rendre les équipes totalement responsables de leur qualité.
Ce cinquième article de la série sur la Quality Assistance te plonge dans ce cas fascinant :
celui d’une entreprise qui a transformé la contrainte en levier,
et qui incarne aujourd’hui une forme mature de NoQA — la qualité sans gardiens du temple.
Portrait : OpenClassrooms, l’entreprise qui a transformé sa qalité
Les chiffres qui comptent :
- Secteur : EdTech (formations en ligne diplômantes)
- Contexte : Startup en croissance avec contraintes budgétaires
- Organisation : Squads produit avec pratiques Agile/Scrum
- Transformation : 2020-2021 (accélérée par la nécessité)
Leur défi unique :
- Scaler rapidement avec budget limité
- Transformer une QA traditionnelle... vite
- Maintenir la qualité pendant la transformation
- Faire accepter le changement dans l'urgence
Et si votre plus grande contrainte - manque de budget, manque de temps, manque de ressources - devenait votre meilleur levier de transformation ?
Le contexte qui change tout :
OpenClassrooms n'avait PAS :
- ❌ Le budget Netflix pour une infrastructure cloud extrême
- ❌ Le temps Atlassian pour une transformation en 6 stages sur le long terme
- ❌ Le luxe d'expérimenter tranquillement
OpenClassrooms AVAIT :
- ✅ Une urgence (difficultés financières)
- ✅ Une conviction (le modèle QA ne scale pas)
- ✅ Un leadership engagé (Vincent Dauce)
- ✅ Une référence inspirante (Dan Buckland et Modern Testing)
Retour terrain : C'est exactement le profil de 70% des organisations que j'accompagne. Budget limité, temps compté, pression pour livrer. OpenClassrooms prouve qu'on peut réussir dans ces conditions.
Le point de départ : Une QA traditionnelle classique
Avant la transformation, OpenClassrooms avait une structure QA que vous reconnaîtrez probablement.
L'organisation initiale
Structure :
- Équipe QA dédiée et séparée du développement
- QA Manager pilotant l'équipe
- Process waterfall déguisé en agile
- QA intervenant en fin de cycle
Le workflow typique :
Les symptômes classiques (vous les connaissez)
Symptôme 1 : Le goulot d'étranglement
- Stories qui s'empilent en attente de test
- QA débordée, dev en attente
- "C'est la QA qui bloque" devient un refrain
Symptôme 2 : La responsabilité déplacée
- Qualité = "le job de la QA"
- Développeurs qui "balancent par-dessus le mur"
- Product Managers qui ne pensent pas qualité
Symptôme 3 : La détection tardive
- Bugs découverts en fin de cycle
- Coût de correction explosif
- Rework constant
Symptôme 4 : Les métriques locales
- "Nombre de tickets testés"
- "Nombre de bugs trouvés"
- Aucune vue sur la valeur business
Retour terrain : Cette description vous semble familière ? C'est normal. C'est exactement le même schéma que j'observe dans 90% des organisations avant transformation. Vous n'êtes pas seuls.
Les limites atteintes
En juillet 2020, le constat est sans appel :
- 40 à 95% des tâches QA contiennent des causes racines en amont
- Cycle-time beaucoup trop long
- Satisfaction équipes au plus bas sur le sujet qualité
- Budget qui ne permet plus de maintenir ce modèle
Le moment de vérité : Continuer comme avant n'est plus une option.
La décision radicale : Passer au "No QA"
Le déclencheur : La nécessité, mère de l'innovation
Le contexte financier : Les difficultés financières d'OpenClassrooms ont accélérée la transformation. Pas le temps de tergiverser, pas le budget pour maintenir une grosse équipe QA.
La décision :
"Nous n'aurons plus de Quality Assurance. Nous passons à la Quality Assistance, et vite."
Retour terrain : Transformation par nécessité vs transformation par choix. J'ai observé les deux. La nécessité donne une clarté et une urgence qui, paradoxalement, facilitent l'adoption. Pas de place pour le "on verra plus tard".
L'inspiration : le modèle de Dan Buckland
OpenClassrooms s'est inspiré du modèle de maturité de Dan Buckland (que nous explorerons en détail dans l'article 7).
Les principes clés adoptés :
Principe 1 : Quality at Speed
- Vitesse ET qualité, pas l'un ou l'autre
- Éliminer les goulots d'étranglement
- Fluidifier le delivery
Principe 2 : Shift-Left
- Qualité dès la conception
- Tests en amont, pas en aval
- Prévention > Détection
Principe 3 : Responsabilité partagée
- Qualité = affaire de tous
- Pas de "je développe, tu testes"
- Collaboration transverse
Principe 4 : Quality Engineering, pas Assurance
- Focus sur l'architecture testable
- Outillage et coaching
- Assistance, pas contrôle
La vision cible
Mission redéfinie :
"Accelerate the achievement of shippable quality that makes education accessible."
Deux mots clés :
- "Accelerate" = On ne ralentit pas, on accélère
- "Shippable quality" = Qualité livrable, pas qualité parfaite
L'organisation cible :
- Équipes produit autonomes sur la qualité
- Quality Engineers en support/coaching
- Architecture favorisant la testabilité
- Outillage pour l'autonomie
Faut-il attendre la crise pour oser transformer ? Ou peut-on créer l'urgence artificiellement pour accélérer ?
La transformation en pratique : de la théorie à la réalité
Phase 1 : Le changement de posture (Mois 1-3)
Action 1 : Renommer l'équipe et les rôles
Avant :
- QA Team
- QA Manager
- QA Engineers
Après :
- Quality Engineering Team
- Head of Quality (Vincent Dauce)
- Quality Engineers (nouvelle définition)
Pourquoi c'est important : Les mots comptent. "QA" est trop associé à "Quality Assurance" (contrôle). Le changement de nom marque la rupture.
Action 2 : Clarifier la mission
Vincent organise un kickoff officiel transverse :
- Présentation de la nouvelle vision à toute l'organisation
- Explication du "pourquoi" du changement
- Clarification des nouveaux rôles et responsabilités
Action 3 : Acculturation intensive
L'équipe diffuse massivement du contenu :
- Vidéo d'Alan Page sur "Adventures in Modern Testing"
- Articles et références sur la Quality Assistance
- Sessions de sensibilisation dans les squads
- Communication continue sur les canaux internes
Retour terrain : La communication en transformation est TOUT. Sous-communiquer = échec garanti. OpenClassrooms a sur-communiqué, et c'est ce qui a permis l'adhésion.
Phase 2 : La redéfinition des rôles (Mois 3-6)
Les 2 nouveaux rôles émergents :
Rôle 1 : Quality Ops Engineer
Mission : Construire les outils qualité pour rendre les équipes autonomes
Activités :
- Développer les frameworks de test
- Créer les environnements de test
- Automatiser les pipelines CI/CD qualité
- Maintenir l'infrastructure de test
- Documentation et formation sur les outils
Profil : Dev avec sensibilité qualité, expertise tooling
Rôle 2 : Senior Quality Engineer
Mission : Support produit/tech haut niveau, coaching stratégique
Activités :
- Coaching des équipes sur les pratiques qualité
- Analyse des risques produit
- Support sur les problématiques complexes
- Définition des stratégies de test
- Monitoring de la qualité globale
Profil : QA senior avec vision transverse, excellentes soft skills
Les équipes produit deviennent autonomes :
- ✅ Les développeurs testent leur propre code
- ✅ Les PO pensent qualité dès la découverte produit
- ✅ Les designers intègrent la testabilité dans leurs maquettes
- ✅ Les DevOps supportent les environnements de test
Phase 3 : Les pratiques mises en place (Mois 6-12)
Pratique 1 : Blitz Testing
Inspirée d'Atlassian, adaptée au contexte OpenClassrooms :
- Sessions de 1h time-boxées
- Toute l'équipe teste ensemble
- Focus sur les features critiques
Pratique 2 : Exploratory Testing Distribué
Les développeurs font du test exploratoire :
- Formation par les Quality Engineers
- Pairing avec QE sur les premiers tests
- Autonomie progressive
Pratique 3 : Testing Notes Collaboratives
Documentation de la stratégie de test :
- Co-créées lors des refinements
- Maintenues par l'équipe
- Base de connaissance qualité
Pratique 4 : Architecture Support
Conception pour la testabilité :
- APIs testables by design
- Feature flags pour tests progressifs
- Environnements de test stables
Pratique 5 : Quality Advisors Intégrés
Les Quality Engineers rejoignent les squads :
- Présence aux rituels (planning, daily, retro)
- Coaching en temps réel
- Support sur demande, pas validation systématique
Retour terrain : Ces pratiques ne sont pas tombées du ciel. Elles ont été implémentées progressivement, ajustées, améliorées. La transformation a été itérative, pas big-bang.
Phase 4 : Le changement de métriques (An 2)
Anciennes métriques (abandonnées) :
- ❌ Nombre de tickets testés par QA
- ❌ Nombre de bugs trouvés
- ❌ Couverture de test (métrique locale)
Nouvelles métriques (adoptées) :
- ✅ Cycle-time : De "done dev" à "en production"
- ✅ Lead-time : De "idée" à "en production"
- ✅ Perception de la valeur QE : Sondage régulier
- ✅ Bugs en production : Tendance sur 6 mois
- ✅ Autonomie des équipes : Self-assessment
Le changement de focus :
- Avant : Optimisation locale (la QA)
- Après : Optimisation globale (le delivery)
Les défis rencontrés
Défi 1 : L'adoption par les équipes
Le problème : Les développeurs ne savaient pas tester. Pas par manque de capacité, mais par manque de formation et d'habitude.
Les symptômes :
- "Je ne sais pas par où commencer"
- "Combien de temps dois-je passer à tester ?"
- "Est-ce que c'est suffisant ?"
Comment ils l'ont surmonté :
- ✅ Formation intensive (ateliers, pairing)
- ✅ Testing Notes comme guide
- ✅ Quality Engineers disponibles pour coaching
- ✅ Bienveillance sur les erreurs initiales
- ✅ Célébration des premiers succès
Retour terrain : C'est LE défi majeur de toute transformation Quality Assistance. Les développeurs ne résistent pas par mauvaise volonté, mais par manque de compétence initiale. La formation est non-négociable.
Défi 2 : La redéfinition des rôles QA
Le problème : Certains QA ne voulaient pas devenir "coaches". Ils aimaient tester, pas former.
Les conséquences :
- Perte de certains talents (départs)
- Période de deuil pour l'ancienne identité
- Reconstruction d'une nouvelle identité professionnelle
Comment ils l'ont géré :
- ✅ Communication transparente dès le début
- ✅ Accompagnement individuel (coaching)
- ✅ Possibilité de pivoter vers Quality Ops (dev)
- ✅ Acceptation que certains partent
- ✅ Recrutement de profils alignés avec la nouvelle vision
Citation Vincent Dauce :
"Les problématiques principales concernent les rôles et responsabilités de chacun. En Quality Assurance, le modèle était clair mais inefficace. En Quality Assistance, il faut mettre en place un effort collectif qui requiert une clarification."
Retour terrain : J'ai vu des transformations échouer parce que le management n'a pas osé accepter que certains QA partent. Vous ne pouvez pas forcer quelqu'un à changer de métier. Mieux vaut accompagner ceux qui veulent, et laisser partir ceux qui ne veulent pas.
Défi 3 : Le timing (transformation accélérée)
Le problème : La contrainte financière a forcé une transformation rapide. Moins de temps pour accompagner, former, ajuster.
Les tensions :
- Pression pour livrer vs temps pour former
- Besoin de stabilité vs changement radical
- Court terme (survie) vs long terme (vision)
Le témoignage honnête de Vincent :
"C'était fonctionnel, mais c'était par nécessité. J'aurais préféré avoir plus de temps pour le shift-right et le chaos engineering. On a fait les choix qu'on pouvait faire."
Les compromis assumés :
- ⚠️ Focus sur shift-left, shift-right reporté
- ⚠️ Chaos engineering en attente (pas le temps/budget)
- ⚠️ Monitoring production moins poussé qu'idéalement
- ⚠️ Certaines pratiques avancées non implémentées
Retour terrain : Transformation idéale vs transformation réelle. OpenClassrooms a fait la transformation POSSIBLE, pas la transformation PARFAITE. Et c'est OK. Mieux vaut 80% implémenté et qui fonctionne que 100% rêvé et jamais fait.
Défi 4 : La croissance simultanée
Le problème : Pendant la transformation, l'organisation grandissait. Nouvelles personnes arrivant sans connaître "le monde d'avant".
Les complications :
- Onboarding sur un modèle en cours de transformation
- Alignement difficile (certains n'ont pas vécu le pourquoi)
- Risque de dilution de la vision
Comment ils l'ont géré :
- ✅ Documentation extensive de la vision et pratiques
- ✅ Onboarding qualité systématique
- ✅ Communication continue (pas juste au début)
- ✅ Ambassadeurs dans chaque squad
Les résultats obtenus : Mesurer l'impact
Les succès mesurables (1 an après)
Métrique 1 : Cycle-Time
- Amélioration de 34% du cycle-time
- De "done dev" à "disponible en production"
- Impact direct sur la vélocité de livraison
Métrique 2 : Perception de la QA
- 60% des équipes : "Indispensables"
- 30% des équipes : "Très utiles"
- 10% des équipes : "Utiles"
- Total : 90% perçoivent de la valeur
Métrique 3 : Disparition des plaintes
- Zéro mention de "bottleneck QA" dans les rétros
- Avant : sujet #1 de frustration
- Après : n'apparaît plus
Métrique 4 : Tests créés par non-QA
- Augmentation significative des tests utiles créés par les développeurs, PO, designers
- Démocratisation de la qualité
Retour terrain : Ces métriques sont parlantes. Amélioration mesurable ET perçue. C'est la combinaison qui prouve le succès.
Les succès qualitatifs
Succès 1 : Équipes autonomes
- Les squads gèrent leur qualité de bout en bout
- Pas de dépendance à une validation externe
- Ownership fort
Succès 2 : Culture qualité émergente
- Qualité devient un réflexe, pas une contrainte
- Discussions qualité dès la découverte produit
- Tests pensés dès le design
Succès 3 : Scalabilité atteinte
- Le modèle scale avec la croissance
- Pas besoin d'embaucher 10 QA pour 50 devs
- Investissement dans l'outillage plutôt que dans les testeurs
Succès 4 : Coûts optimisés
- Équipe Quality Engineering réduite
- Budget réalloué sur l'infrastructure et l'outillage
- ROI positif
Les compromis assumés
Compromis 1 : Shift-Right limité
"J'aurais préféré avoir plus de focus sur le monitoring en production et le shift-right, mais on a dû prioriser le shift-left."
Compromis 2 : Chaos Engineering en attente
- Pas le budget/temps pour implémenter
- Reporté à une phase ultérieure
- Focus sur la résilience de base d'abord
Compromis 3 : Maturité encore en progression Vincent dit : "Nous avons même un peu peur d'être indispensables."
- L'autonomie n'est pas encore totale
- Les équipes s'appuient encore beaucoup sur les QE
- Travail continu pour augmenter l'autonomie
Retour terrain : J'apprécie cette honnêteté. Un modèle "fonctionnel" n'est pas un modèle "parfait". OpenClassrooms a fait les bons choix pour leur contexte. C'est ça, l'intelligence.
Les principes clés
OpenClassrooms s'est inspiré du modèle de maturité de Dan Buckland. Voici les principes qu'ils ont appliqués.
Principe 1 : Quality at Speed
Le concept : Vitesse ET qualité sont synergiques, pas antagonistes.
Application chez OpenClassrooms :
- Élimination des goulots (QA bottleneck)
- Automatisation pour accélérer
- Qualité dès le début pour éviter le rework
Citation :
"Accelerate the achievement of shippable quality."
Principe 2 : Architecture pour la Testabilité
Le concept : Concevoir des systèmes faciles à tester dès le design.
Application chez OpenClassrooms :
- Quality Ops Engineer construit l'infra testable
- APIs conçues pour être testées facilement
- Feature flags pour tester progressivement
- Environnements de test stables et reproductibles
Principe 3 : Quality Advisors, pas Assurance
Le concept : Conseiller et accompagner, pas contrôler et valider.
Application chez OpenClassrooms :
- Quality Engineers en posture de coaching
- "Comment tu comptes tester ?" au lieu de "Je vais tester"
- Support sur demande, pas validation obligatoire
- Pairing pour montrer, pas pour faire à la place
Principe 4 : Shift-Left (et Shift-Right dans l'Idéal)
Le concept : Qualité dès la conception (shift-left) et monitoring en production (shift-right).
Application chez OpenClassrooms :
- ✅ Shift-left bien implémenté (tests dès le début)
- ⚠️ Shift-right en cours de développement (monitoring production)
- 🎯 Objectif futur : Équilibrer les deux
Le témoignage honnête :
"J'aurais préféré avoir plus de temps pour le shift-right et le chaos engineering."
Retour terrain : Le pragmatisme, c'est faire les bons choix dans les bonnes priorités. OpenClassrooms a priorisé shift-left (impact immédiat) avant shift-right (impact long terme). C'était le bon choix pour leur contexte.
Ce que VOUS pouvez en retenir
Pour les organisations avec contraintes budgétaires
Si vous manquez de budget, inspirez-vous d'OpenClassrooms :
✅ Stratégie 1 : Quality Ops Engineer
- Recrutez/formez 1 personne sur l'outillage qualité
- Focus sur les frameworks, infra, CI/CD
- ROI rapide (démultiplie la capacité des équipes)
✅ Stratégie 2 : Quality Advisors Transverses
- Transformez vos QA en advisors
- 1 QA advisor pour 2-3 équipes produit
- Coaching, pas testing
✅ Stratégie 3 : Autonomisation Progressive
- Commencez par 1-2 équipes pilotes volontaires
- Formez intensivement
- Étendez au fur et à mesure
Pour les organisations qui veulent transformer
Si vous avez le choix du timing, inspirez-vous quand même d'OpenClassrooms :
✅ Avantage 1 : Transformation rapide
- 12-18 mois vs 3-4 ans (Atlassian)
- Résultats en 1 an
- Momentum préservé
✅ Avantage 2 : Pragmatisme
- Focus sur l'essentiel
- Pas de perfectionnisme paralysant
- Itération continue
✅ Avantage 3 : Modèle éprouvé
- Cas concret français/européen
- Contexte similaire au vôtre
- Leçons apprises documentées
3 Quick Wins OpenClassrooms Applicables Dès Demain
Quick Win #1 : Créer un Rôle Quality Ops 🛠️
Difficulté : ⭐⭐ Moyenne
Impact : ⭐⭐⭐⭐ Élevé
Temps : 1 mois
Action concrète :
- Identifiez 1 personne (QA ou Dev) avec sensibilité outillage
- Redéfinissez son rôle : construire les outils qualité pour tous
- Premières missions :
- Framework de test automatisé
- CI/CD qualité
- Environnements de test stables
- Formez les équipes sur les outils créés
Résultat attendu : Autonomisation des équipes via l'outillage
Quick Win #2 : Transformer 1 QA en Quality Advisor (Pilote) 👨🏫
Difficulté : ⭐⭐⭐ Moyenne-Élevée
Impact : ⭐⭐⭐⭐⭐ Très élevé
Temps : 3 mois
Action concrète :
- Choisissez 1 QA senior volontaire
- Redéfinissez son rôle : coach, pas testeur
- Assignez-le à 1-2 équipes (pas plus au début)
- Nouvelles activités :
- Coaching sur les pratiques de test
- Pairing avec les développeurs
- Création de Testing Notes
- Support sur demande (pas validation systématique)
- Mesurez l'impact après 3 mois
Résultat attendu : Équipes plus autonomes, QA plus impactant
Quick Win #3 : Autonomiser 1 Équipe Produit (Expérimentation) 🚀
Difficulté : ⭐⭐⭐ Moyenne-Élevée
Impact : ⭐⭐⭐⭐ Élevé
Temps : 6 mois
Action concrète :
- Choisissez 1 équipe produit volontaire et mature
- Expérimentez le modèle "Quality Assistance" complet :
- Les développeurs testent leurs stories
- QA en coaching, pas en validation
- Testing Notes collaboratives
- Blitz testing réguliers
- Formez l'équipe intensivement (2-3 ateliers)
- Mesurez cycle-time, satisfaction, bugs en prod
- Partagez les résultats à l'organisation
Résultat attendu : Preuve de concept, ambassadeurs internes
Retour terrain : Ces 3 quick wins sont exactement ce qu'OpenClassrooms a fait. Commencez petit, prouvez que ça marche, scalez.
La meilleure QA, c’est celle qu’on ne voit plus
Chez OpenClassrooms, la disparition du rôle de QA n’a pas supprimé la qualité.
Elle l’a rendue visible partout.
Chacun en est responsable, chacun la défend, chacun la construit.
C’est ça, la vraie Quality Assistance :
l’art de rendre les équipes autonomes dans la qualité,
sans jamais perdre le sens du collectif.
❓ FAQ
Est-ce que “No QA” veut dire qu’il n’y a plus de tests ?
Non. Les tests sont toujours là, mais distribués. Les devs les conçoivent, les exécutent et les maintiennent.
Comment éviter que la qualité se dégrade ?
En créant des standards, en outillant les équipes et en animant la culture du feedback.
Quel est le rôle du Quality Ops ?
Fournir les outils, dashboards et frameworks qui rendent la qualité accessible à tous.
Et si mes équipes ne sont pas prêtes ?
Commence petit : une squad pilote, un produit limité, et un accompagnement fort.
Comment mesurer la qualité sans QA ?
Suivre les métriques d’ingénierie (MTTR, change failure rate) et de produit (erreurs, support, satisfaction).
Comment gérer la charge pour les devs ?
Automatiser les tâches répétitives et encourager le pair testing.
Et le rôle du QA coach ?
Diffuser la culture, aider à structurer les stratégies de test et accompagner la montée en maturité.
🔗 Références
- QE Unit — Il n’y a plus de Quality Assurance chez ManoMano & OpenClassrooms
- Medium OpenClassrooms — Working as Quality Engineer at OpenClassrooms
Cet article est le 5ème d'une série de 7 publications sur la Quality Assistance. Dans le prochain épisode : ManoMano : Une culture décentralisée de la Qualité.
Plus d’articles comme celui-ci
