Le client est une plateforme d’enseignement en ligne proposant des cours interactifs, des devoirs, des espaces personnels pour les élèves et leurs parents ainsi que le paiement en ligne. L’activité est fortement saisonnière : septembre accueille le plus grand nombre de nouveaux élèves, et une panne de la plateforme durant les premières semaines de l’année scolaire peut faire perdre définitivement des clients. Il n’y avait pas d’équipe QA interne : les développeurs testaient entre deux tâches. La régression avant chaque mise en production prenait trois jours et manquait malgré tout des parcours essentiels, comme le paiement, la réservation d’un cours ou l’accès à la classe virtuelle. Le client nous a contactés après un nouvel incident : un défaut de paiement avait fait perdre une partie des demandes recueillies pendant l’été.
Mettre en place un processus d’assurance qualité de zéro :
une stratégie de test priorisée selon les risques métier, l’automatisation des parcours clés, l’intégration des contrôles dans la CI et des tests de charge avant le pic de septembre. Contrainte : poursuivre le développement sans interruption ; les mises en production restaient hebdomadaires et septembre n’attendait pas.
Nous n’avons pas commencé par les tests automatisés, mais par l’analyse des risques : quels parcours cassent le plus souvent et où le coût d’un défaut est-il le plus élevé ? L’automatisation a suivi cette liste de priorités.
- Nous avons audité la qualité : analyse des bugs des six derniers mois, entretiens avec les équipes et cartographie des parcours les plus sensibles – paiement, réservation d’un cours, accès à la classe et notifications aux parents.
- Nous avons rédigé une stratégie de test : niveaux de test, responsabilités, définition of done des fonctionnalités et règles de signalement des bugs, communes aux trois équipes de développement.
- Nous avons automatisé le parcours critique : scénarios end-to-end avec Playwright pour la plateforme web, tests API pour le backend et suite smoke avant chaque mise en production.
- Nous avons intégré des barrières QA dans la CI : impossible de publier sans suite smoke validée ; la régression complète se lance chaque nuit et les résultats sont visibles par toutes les équipes dans GitLab.
- Nous avons effectué des tests de charge avec k6 : simulation du trafic de pointe de septembre, détection des goulots d’étranglement et résolution avec l’équipe backend avant la saison.
- Nous avons transmis le processus au client : documentation, procédures et formation de l’ingénieur QA aux tests automatisés et au pipeline.
La décision essentielle a été de prioriser les risques métier plutôt que de viser une couverture impressionnante. Nous n’avons volontairement pas recherché une automatisation à 100 % : la couverture de 75 % des scénarios critiques a apporté l’essentiel du bénéfice, car elle protégeait précisément les parcours qui font gagner ou perdre des clients à la plateforme. Les autres parcours restent couverts par des tests exploratoires manuels avant les mises en production importantes.
Le principal effet économique est la détection plus précoce des défauts : un bug détecté par un test automatisé dans la CI coûte plusieurs fois moins cher qu’un défaut signalé par le parent d’un élève en production. La plateforme a abordé la saison avec une marge de sécurité, et les équipes ont pu publier plus souvent sans craindre « l’effet du vendredi ». Autre avantage : la confiance de l’entreprise ; l’équipe commerciale peut désormais promettre honnêtement aux écoles partenaires une plateforme stable pendant le pic des inscriptions.
| Indicateur | Résultat |
|---|---|
| Bugs critiques en production | 5–7 par mois → 1–2 par trimestre |
| Régression avant mise en production | 3 jours manuels → 4 heures avec des tests automatisés |
| Pic de charge de septembre | Incidents chaque année → 0 incident, sans dégradation |
| Moment de détection des défauts | Le plus souvent en production → Les tests automatisés les détectent avant la mise en production |
Les indicateurs ont été repris des documents sources de l’étude de cas. La période est indiquée lorsqu’elle est précisée dans la source.
- bugs critiques par trimestre (auparavant 5–7 par mois)
- 1–2
- régression avec tests automatisés (auparavant 3 jours manuellement)
- 4 h
- des scénarios clés couverts par des tests automatisés
- 75%
- incidents pendant le pic de septembre
- 0
Échelle indicative : 3 jours sont convertis en 72 heures. Pour la longueur des barres, la plage mensuelle de bugs est multipliée par trois pour obtenir une valeur trimestrielle ; les bornes supérieures sont comparées.
- 01Commit
- 02Suite smokepas de validation, pas de mise en production
- 03Mise en productionchaque semaine
- 04Chaque nuitrégression complète
Les prochaines étapes que nous recommandons à la plateforme :
- La régression visuelle, pour vérifier automatiquement la mise en page des cours, des e-mails et des espaces personnels.
- Une fabrique de données de test pour générer des élèves, groupes et paiements réalistes à chaque exécution.
- La QA en production : feature flags et mises en production canari pour activer progressivement les nouvelles fonctionnalités.
Nous avons cessé d’avoir peur des mises en production. Avant, chaque vendredi pouvait se terminer par l’analyse des réclamations ; maintenant, la mise en production est une procédure courante de quinze minutes.
— CTO de l’école en ligne