OpenClassrooms : d’une QA dédiée à une responsabilité commune

Article 5/7 - 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 Quality Assistance a été progressive et réfléchie.

Face à une forte croissance et à des cycles de livraison qui ralentissaient malgré des QA dédiées dans chaque squad, nous avons choisi de transformer notre approche : passer d’une QA dédié à une approche plus globale, où la qualité devenait une responsabilité collective de chaque équipe produit.

Après plusieurs années de cette transformation, un contexte économique tendu et des réorganisations ont amené l’entreprise à aller encore plus loin : réduire le nombre de QA dédiés par squad et créer quelques rôles QA globaux pour soutenir l’organisation dans son ensemble.

Plutôt qu’une régression, cette décision était une opportunité : elle permettait d’ancrer une culture où les équipes produit sont pleinement responsables de la qualité, donnant naissance à une forme mature de NoQA - la qualité sans gardiens du temple.

Portrait : OpenClassrooms, l’entreprise qui a transformé sa qualité

Les chiffres qui comptent :

• Secteur : EdTech (formations en ligne diplômantes)
• Contexte : Scale-up en forte croissance
• Organisation : Squads produit avec pratiques Agile
• Transformation Quality Assistance : Juin 2020 (proactive)
• Réorganisations majeures : Mai 2023 (3 ans après)

Leur situation unique :

• Organisation DÉJÀ mature en qualité
• Clean architecture en place
• Tests unitaires omniprésents
• Développeurs qui testent déjà de manière poussée
• % de bugs toujours en dessous du marché
• QE déjà intégrés dans les squads

Leur défi réel :

• Mettre en place la Quality Assistance en même temps que scaler.
• Faire accepter le changement : redéfinir les rôles, les activités, ...
• Améliorer la vélocité tout en conservant la qualité

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 AVAIT :

• ✅ Une organisation déjà mature en qualité
• ✅ Des QA intégrés dans les squads depuis longtemps
• ✅ De l'automatisation déjà présente
• ✅ Une culture qualité forte (ADN de l'entreprise)
• ✅ Le luxe d'expérimenter
• ✅ Une conviction (le modèle QA ne scale pas)
• ✅ Un leadership engagé (Vincent Dauce)
• ✅ Une référence inspirante (Alan Page et Modern Testing)
• Une organisation évolutive
• Les développeurs testaient beaucoup (avant 2016)
• Les développeurs ont délégué à la QA
• La mise en place de la Quality Assistance (2020-2023), les développeurs ont de nouveau testé
• Puis en noQA (après 2023) ils ont repris l'intégralité des tests.

Retour terrain : C'est rare. La plupart des transformations que j'accompagne partent d'une QA traditionnelle problématique. OpenClassrooms est parti d'une base déjà excellente pour aller vers l'excellence scalable.

Le point de départ : Une organisation déja mature

La qualité, ADN d'OpenClassrooms

Bien avant la transformation Quality Assistance, OpenClassrooms avait :

Architecture solide :

• Clean architecture déjà implémentée
• Séparation claire des responsabilités
• Code maintenable et testable

Tests omniprésents :

• Tonnes de tests unitaires
• Couverture de test élevée
• Automatisation déjà en place
• Développeurs qui testent de manière poussée

Culture qualité :

• Qualité dans l'ADN de l'entreprise (pas juste la tech)
• Qualité des cours éducatifs = priorité #1
• Cette culture se reflétait dans le code

QE déjà intégrés :

• 1 Quality Engineer par squad (8 QE au total)
• Présents dès le product discovery
• Impliqués dans toutes les phases
• Pas isolés dans une tour d'ivoire

Métriques saines :

• Entre 5-15% de bugs corrigés vs tasks toujours en dessous du marché
• Qualité déjà au rendez-vous

Alors, quel était le problème ?

Le problème n'était PAS la qualité. C'était la VÉLOCITÉ face au scaling.

Le pattern observé :

Quand une organisation scale :

1. Les équipes grossissent
2. On spécialise les rôles (QE font les tests, devs codent)
3. La coordination augmente
4. La communication se complexifie
5. La vélocité diminue inexorablement

Ce qui se passait chez OpenClassrooms :

• Les QE faisaient les tests (validaient, exécutaient)
• Les développeurs codaient mais déléguaient une partie du test
• À mesure que l'organisation grandissait, cette spécialisation créait de la friction
• Les handoffs ralentissaient le flow

Les symptômes observés dans les rétrospectives :

"Nous avons obtenu deux fois plus de feedbacks sur l'organisation de la qualité, ses difficultés et son inclusion avec la roadmap."

Pas des feedbacks sur la QUALITÉ du produit (qui était bonne), mais sur l'ORGANISATION de la qualité qui devenait un frein au scaling.

Retour terrain : C'est le problème des organisations matures. Vous avez réussi la qualité, mais en créant des spécialisations qui ne scalent pas. Le défi n'est plus "comment faire de la qualité" mais "comment maintenir qualité ET vélocité en grandissant".

La décision stratégique : Quality Assistance (Juin 2020)

L'inspiration : Modern Testing de Alan PAge

Vincent Dauce s'inspire de la vision Alan Page du Modern Testing complétée par le modèle de maturité de Dan Buckland.

La mission de l’équipe de Quality Engineering :

"Accelerate the achievement of shippable quality that makes education accessible."

Les 3 objectifs clés :

1. Maintenir la vélocité malgré la croissance

• Éliminer les frictions de coordination
• Réduire les handoffs
• Fluidifier le delivery

2. Redonner l'ownership aux développeurs

• Les devs TESTENT (pas juste codent)
• Les QE COACHENT (pas juste testent)
• Qualité = responsabilité de l'équipe produit

3. Préparer l'organisation au scaling

• Modèle qui scale naturellement
• Pas besoin d'embaucher 10 QE pour 50 devs
• Investissement dans l'upskilling, pas dans les testeurs

Le changement fondamental de posture

Avant (déjà bien, mais pas scalable) :

• QE font les tests
• Devs développent et testent partiellement
• Coordination QE ↔ Dev sur les tests
• Flow : Dev code → QE teste → Prod

Après (Quality Assistance) :

• Devs testent TOUT
• QE coachent, forment, outillent
• Pas de handoff sur le test
• Flow : Dev code + teste → Prod (QE en support)

La nuance importante : Ce n'est pas "les devs ne testaient pas" → "maintenant ils testent" C'est "les devs testaient déjà" → "maintenant ils testent TOUT et en ownership complet"

Retour terrain : Cette nuance est cruciale. OpenClassrooms n'a pas formé des devs qui ne testaient pas. Ils ont donné l'ownership complet à des devs qui testaient déjà bien.

La transformation 1 (2020-2023) : Quality Assistance en action

Phase 1 : Communication et Acculturation (Été 2020)

Action 1 : Renommer pour marquer la rupture

Avant :

• QA Team
• QA Manager
• QA Engineers = testeurs

Après :

• Quality Engineering Team
• Quality Director (Vincent Dauce)
• Quality Engineers = coaches

Action 2 : Kickoff officiel

Vincent organise une communication transverse :

• Présentation de la nouvelle vision
• Explication du "pourquoi" (préparer le scaling)
• Clarification des nouveaux rôles
• Engagement de tous les stakeholders

Action 3 : Acculturation intensive

Diffusion massive de contenu :

• Vidéo Alan Page "Adventures in Modern Testing"
• Articles et références Modern Testing
• Sessions dans les squads
• Communication continue

Retour terrain : Vincent a sur-communiqué (dans le bon sens). Sur-communiquer en transformation = sous-estimer rarement.

Phase 2 : Évolution des rôles QE (2020-2023)

Le changement de mission des Quality Engineers :

AVANT (pré-2020) :

• Intégrés dans les squads ✓
• Présents dès le product discovery ✓
• Mais : exécutaient les tests eux-mêmes

APRÈS (2020-2023) :

• Toujours intégrés dans les squads ✓
• Toujours dès le product discovery ✓
• Mais : coachent les devs, avec l’ambition de ne plus être dans l’exécution. Dans la réalité, Ils avaient encore 3 activités :
• testing
• checking
• coaching

Les nouvelles activités des QE :

• Coaching des développeurs sur les techniques de test
• Facilitation des sessions de test (Blitz Testing)
• Création de Testing Notes collaboratives
• Pairing avec les devs pour montrer les techniques
• Support sur demande, pas validation systématique
• Architecture pour la testabilité
• Collaboration avec les Product Manager, Product Designer, UX, Writer, Solution Manager

Ce qui change pour les développeurs :

• Ownership complet du test de leurs features
• Formation continue par les QE
• Autonomie progressive
• Responsabilité end-to-end

Phase 3 : Les pratiques mises en place

Pratique 1 : Blitz Testing

• Sessions time-boxées (1h)
• Toute l'équipe teste ensemble
• Facilité par les QE

Pratique 2 : Testing Notes Collaboratives

• Documentation de la stratégie de test
• Co-créées Dev + QE
• Base de connaissance vivante

Pratique 3 : Pairing Dev/QE

• QE montre les techniques
• Dev applique progressivement en autonomie
• Montée en compétence continue

Pratique 4 : Exploratory Testing Distribué

• Développeurs font du test exploratoire
• QE forme aux techniques
• Culture du test mature distribuée

Retour terrain : Ces pratiques ne sont pas révolutionnaires prises individuellement. C'est leur combinaison + le changement d'ownership qui fait la différence.

Phase 4 : Changement de métriques

Anciennes métriques (abandonnées) :

• ❌ Nombre de tickets testés par QE
• ❌ Couverture de test (métrique locale)

Nouvelles métriques (adoptées) :

• ✅ Cycle-time : De "ready" à "en production". Ce métrique a existé à plusieurs
• ✅ Perception de la valeur QE
• ✅ Autonomie des squads

Les résultats de la transformation 1 (2020-2021)

Les succès mesurables

Métrique clé : Cycle-Time

• De 6 jours et 3h en 2019 à moins de 2 jours en 2024 et 2025
• Impact direct sur la vélocité
• Maintien de la qualité (pas de dégradation)

Métrique 2 : Perception QE

Différentes survey sont effectuées pour recueillir chaque année certains indicateurs comme:

• La compréhension de la transformation,
• La valeur apportée par la QE,
• La satisfaction de la qualité apportée...
• Et l'autonomie des squads (ie à quel point les équipes sont dépendants des QE)

Métrique 3 : Autonomie

• Squads capables de délivrer en autonomie
• Moins de dépendance aux QE pour validation
• Ownership fort

Les succès qualitatifs

Succès 1 : Préparation au scaling

• Le modèle scale naturellement
• Pas besoin d'embaucher proportionnellement plus de QE
• Organisation prête pour la croissance

Succès 2 : Culture qualité renforcée

• Qualité = affaire de tous (pas juste des QE)
• Réflexe qualité dès la conception
• Tests pensés dès le design

Succès 3 : Vélocité maintenue

• Malgré la croissance, pas de ralentissement
• Coordination fluide
• Delivery régulier

Le plus important : Organisation résiliente

Cette transformation a préparé OpenClassrooms à ce qui allait venir 3 ans plus tard...

2023 : La Résilience à l'épreuve

Mai 2023 : Les Réorganisations Arrivent

3 ans après la mise en place de la Quality Assistance, OpenClassrooms fait face à des réorganisations majeures.

Le contexte :

• Ajustements organisationnels importants
• Réduction d'équipe
• Équipe QE passe de 8 à 2 personnes

Ce qui aurait pu se passer (sans Quality Assistance) :

• Effondrement de la qualité
• Goulot d'étranglement sur 2 personnes
• Ralentissement dramatique du delivery
• Difficulté à scaler

Ce qui s'est réellement passé : L'organisation a tenu.

Pourquoi ? Parce qu'elle était préparée.

Les squads étaient déjà autonomes. Les développeurs testaient déjà en ownership. La Quality Assistance mise en place 3 ans avant a permis de traverser cette tempête.

Retour terrain : OpenClassrooms a trouvé une organisation résiliente qui a démontré que le modèle adopté, basé sur l’ownership et l’autonomie des équipes, fonctionne même dans un contexte de changements organisationnels majeurs.

La transformation 2 (2023-2024) : Monter d'un niveau

Le nouveau défi

Avec seulement 2 Quality Engineers, le modèle "1 QE par squad" n'était plus viable.

La question : Comment continuer à apporter de la valeur avec 2 QE pour toute l'organisation ?

La réponse : Monter d'un niveau. Passer de la qualité squad-level à la qualité globale.

La redéfinition des rôles (2ème fois)

Rappel : Il y a eu 2 redéfinitions de rôles

Redéfinition 1 (2020) : QE testeurs → QE coaches (niveau squad)

Redéfinition 2 (2023-2024) : QE coaches squad → QE stratégiques globaux

Un nouveau rôle émerge (2023-2024) :

Quality Ops Engineer 🛠️

Mission : Construire les outillages qualité pour toute l'organisation

Activités :

• Test strategy globale
• Frameworks de test utilisables par tous
• CI/CD qualité
• Environnements de test
• Documentation et formation sur les outils
• Quality tooling transverse
• 80 % de leur temps est consacré à la création et à la maintenance d'outils de qualité pour les produits, la conception, l'ingénierie, l'infrastructure et les données.
• 20 % de leur temps est consacré à la maintenance des tests automatisés de bout en bout.

Retour terrain : Ce passage de squad-level à organization-level est une évolution naturelle quand on a peu de QE. Plutôt que de se disperser, on se concentre sur l'effet multiplicateur maximal.

Les leçons d'OpenClassrooms

Leçon 1 : L'anticipation crée la résilience

Sans Quality Assistance (2020) :

• Réorganisations 2023 = catastrophe
• Dépendance aux 8 QE
• Effondrement avec passage à 2 QE

Avec Quality Assistance (2020) :

• Réorganisations 2023 = géré sereinement
• Squads autonomes
• 2 QE suffisent (niveau stratégique)

Retour terrain : C'est le ROI invisible de l'anticipation. On ne le voit pas immédiatement, mais quand la tempête arrive, c'est ce qui fait la différence entre couler et naviguer.

Leçon 2 : Partir d'une base mature ne dispense pas de transformer

OpenClassrooms AVAIT déjà :

• Clean architecture ✓
• Tests unitaires ✓
• Devs qui testent ✓
• QE intégrés ✓

Et pourtant, la transformation était nécessaire. Pourquoi ?

Parce que "mature" ≠ "scalable".

Vous pouvez avoir une excellente qualité à 50 personnes et vous effondrer à 200 personnes si votre modèle ne scale pas.

Leçon 3 : Il y a deux transformations, pas une

Transformation 1 (2020) : Ownership

• QE arrêtent de faire les tests progressivement
• Devs prennent l'ownership complet
• Niveau : Squad

Transformation 2 (2023) : Scalabilité extrême

• QE montent d'un niveau (organisation)
• Stratégie, metrics, tooling
• Niveau : Global

Beaucoup d'organisations s'arrêtent à la transformation 1. OpenClassrooms a dû faire la transformation 2 par nécessité... et c'est devenu un atout.

Leçon 4 : La qualité était dans l'ADN, pas juste dans la tech

Insight de Vincent :

"La qualité a toujours été dans le cœur d'OpenClassrooms. Nous avons des profils qualité directement affectés à la qualité des cours dans les équipes de contenus."

La qualité des cours = priorité #1. Cette culture qualité s'est naturellement reflétée dans la tech.

Enseignement : Quand la qualité est une valeur d'entreprise (pas juste tech), les transformations qualité sont plus faciles. Elles s'appuient sur une culture déjà présente.

Les défis rencontrés

Défi 1 : Former des développeurs déjà bons

Le paradoxe : Les développeurs OpenClassrooms testaient déjà bien. Le défi n'était pas de leur apprendre à tester, mais de leur donner l'ownership COMPLET et la confiance pour valider sans QE.

Les symptômes :

• "Est-ce que c'est suffisant ?"
• "Tu peux valider que mes tests sont OK ?"
• Besoin de réassurance

Comment ça été surmonté :

• ✅ Coaching intensif sur la confiance, pas juste la technique
• ✅ Célébration des succès autonomes
• ✅ Feedback constructif sans jugement
• ✅ Testing Notes comme filet de sécurité
• ✅ Améliorer et étendre les tests automatiques des tests unitaires aux tests bout en bout

Défi 2 : Redéfinir le rôle des QE (2 fois)

Difficulté 1 (2020) : Passer de testeur à coach

• Certains QE aimaient tester
• Changement d'identité professionnelle
• Nouvelles compétences (soft skills)

Difficulté 2 (2023) : Passer du coaching squad à un rôle stratégique global

• Moins de proximité avec les équipes
• Changement de niveau d'intervention
• Moins "dans l'action", plus "dans la stratégie"

Comment c'est été géré :

• ✅ Communication transparente
• ✅ Accompagnement individuel
• ✅ Co-construction de la nouvelle vision
• ✅ Acceptation que certains partent

Défi 3 : Maintenir la culture pendant la croissance

Le problème : Pendant la transformation (2020-2023), l'organisation a grandi. Nouveaux arrivants sans contexte du "monde d'avant" d’OpenClassrooms. Bien évidemment,  Les nouveaux arrivants connaissaient aussi et surtout des QA traditionnelles et risquaient d’appliquer ces pratiques au lieu de s’aligner sur le modèle Quality Assistance.

Les complications :

• Onboarding sur un modèle en transformation
• Dilution potentielle de la culture
• Alignement difficile

Comment c'est été géré :

• ✅ Documentation extensive
• ✅ Onboarding qualité systématique
• ✅ Communication continue (pas juste au début)
• ✅ Ambassadeurs dans chaque squad

Retour terrain : La croissance pendant une transformation est un défi universel. OpenClassrooms l'a bien géré grâce à la communication continue.

Défi 4 : Le sentiment d'indispensabilité (2021)

Citation Vincent :

"Nous avons même un peu peur d'être indispensables."

Le paradoxe :

• 90% des squads disent "QE indispensables"
• C'est positif (reconnaissance de la valeur)
• C'est aussi inquiétant (dépendance pas encore éliminée)

Le travail continu : Augmenter encore l'autonomie pour que les squads se sentent capables SANS les QE.

Ce que VOUS pouvez en retenir

Pour les organisations déjà matures en qualité

Si vous êtes comme OpenClassrooms (déjà bons) :

✅ Le défi n'est pas "comment faire de la qualité" Vous savez déjà faire.

✅ Le défi est "comment scaler sans perdre vélocité" C'est là que la Quality Assistance intervient.

✅ Agissez dès maintenant pour adapter vos pratiques avant que la croissance ne complique le delivery.

Les 3 signaux qu'il est temps de transformer :

1. La coordination devient lourde malgré la bonne qualité
2. Les handoffs ralentissent le flow
3. Vous anticipez une croissance rapide et savez que le modèle actuel pourrait limiter l’efficacité

Pour toutes les organisations

Les 3 principes transférables d'OpenClassrooms :

Principe 1 :Transformer de manière proactive plutôt que de réagir aux crises  et Choisir un modèle qui facilite la résilience future

• Analysez où vous serez dans 2-3 ans
• Identifiez les futurs goulots
• Agissez maintenant, pas quand c'est urgent

Principe 2 : Partir d'une base mature facilite tout

• Investissez d'abord dans la maturité technique de base
• Clean architecture, tests, automatisation
• PUIS transformez l'organisation

Principe 3 : Préparez-vous à transformer plusieurs fois

• Une transformation n’est jamais unique : adaptez-vous au contexte et restez flexibles
• Le contexte évolue, l'organisation doit évoluer
• Flexibilité > rigidité

Transformer pour tenir et évoluer

Chez OpenClassrooms, la transformation Quality Assistance a été un choix pour résoudre un vrai problème de vélocité et préparer l’organisation à grandir efficacement. Trois points clés ressortent de cette expérience :

La maturité technique ne suffit pas

Même avec des tests, une architecture propre et des équipes déjà responsables, un modèle organisationnel inadapté peut freiner la croissance. La Quality Assistance a permis d’allier qualité et vélocité tout en préparant les équipes à davantage d’autonomie.

Un modèle scalable = résilience

Lorsque les réorganisations de 2023 ont réduit l’équipe QE, le modèle mis en place a permis aux squads de continuer à délivrer efficacement. Ce n’était pas une question d’anticiper une catastrophe, mais d’avoir construit un fonctionnement où chaque équipe produit est responsable de la qualité, et où les QE soutiennent plutôt qu’ils n’exécutent.

Les transformations sont continues

Le passage de QE “squad-level” à QE “stratégique global” montre que l’évolution ne s’arrête jamais. Le contexte change, les équipes changent, et le modèle doit évoluer avec elles. La vraie compétence est d’adapter son organisation de manière pragmatique au fil du temps.

Message clé : vous n’avez pas besoin d’attendre une crise pour transformer vos pratiques. En choisissant un modèle réfléchi, en testant son efficacité et en donnant l’ownership aux équipes, vous pouvez évoluer sereinement et préparer votre organisation à grandir durablement.

❓ 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