20 000 apprenants inscrits dès le jour de l’ouverture d’un nouvel abonnement de formation, avec une campagne de communication qui pousse fortement à la connexion le premier lundi matin : ce chiffre, communiqué par le client trois semaines avant le lancement, a immédiatement posé une question de dimensionnement bien plus qu’une question fonctionnelle sur la plateforme LMS déjà développée et testée. Vingt mille comptes ne se connectent jamais tous en même temps, mais un pic concentré sur la première heure d’ouverture représente un profil de charge très différent d’un usage quotidien étalé.
Cette checklist reprend les vérifications que nous effectuons systématiquement avant tout lancement à fort trafic prévisible, dans l’ordre où nous les traitons, des plus structurantes aux plus fines.
1. Estimer le pic réel, pas la moyenne
- Demander au client une estimation du pourcentage d’apprenants susceptibles de se connecter dans la première heure d’ouverture, à partir de son historique de campagnes précédentes si disponible.
- Sur ce projet, cette estimation donnait environ 30 % des inscrits dans la première heure, soit six mille connexions concentrées sur une fenêtre de soixante minutes, avec un pic probable sur les quinze premières minutes suivant l’envoi de l’email de lancement.
- Convertir ce chiffre en requêtes par seconde estimées, en tenant compte du nombre de requêtes HTTP générées par un parcours de connexion complet (authentification, chargement du tableau de bord, premier module de cours).
2. Identifier le goulot d’étranglement le plus probable
Sur ce type de plateforme LMS construite sur WordPress avec LearnDash, la base de données est systématiquement le premier point de tension observé lors des tests de charge précédents menés sur des projets comparables, avant même le serveur web. Les requêtes de vérification de progression de cours, exécutées à chaque chargement de page pour chaque apprenant connecté, génèrent un volume de requêtes SQL bien supérieur à ce que suggère le nombre de pages vues.
Vérifications base de données
- Confirmer la présence d’un cache d’objets persistant (Redis) configuré et actif, pas seulement installé mais non connecté.
- Vérifier les index sur les tables de progression de cours les plus sollicitées, via
EXPLAINsur les requêtes les plus fréquentes identifiées par le plugin de requêtes lentes. - Confirmer le nombre de connexions simultanées maximum autorisées côté serveur MySQL, comparé au nombre de workers PHP-FPM susceptibles de solliciter la base en même temps.
3. Dimensionner les workers PHP-FPM
; php-fpm pool avant ajustement
pm.max_children = 20
pm.start_servers = 5
; apres ajustement pour le pic estime
pm.max_children = 80
pm.start_servers = 20
pm.max_spare_servers = 40
Ce dimensionnement seul ne suffit pas : il doit être accompagné d’une vérification de la mémoire disponible sur le serveur, chaque worker PHP-FPM supplémentaire consommant une part de mémoire qui, multipliée par quatre-vingts, peut dépasser la capacité du serveur si elle n’a pas été vérifiée au préalable.
4. Réaliser un test de charge réaliste, pas théorique
Un test de charge qui simule uniquement des requêtes GET sur la page d’accueil ne représente pas la réalité d’un lancement de cette nature. Le scénario de test reproduisait le parcours complet : connexion, chargement du tableau de bord personnel, accès au premier module de cours, marquage de progression, sur six mille sessions simulées réparties sur une fenêtre de quinze minutes, avec un outil de test de charge dédié.
Ce test a révélé un point non anticipé : le plugin de certification générait un PDF de bienvenue à la première connexion de chaque apprenant, une opération coûteuse en CPU qui, multipliée par six mille connexions simultanées, saturait les workers PHP-FPM bien avant que la base de données n’atteigne elle-même sa limite.
5. Prévoir un plan de dégradation progressive
- Report de la génération du PDF de bienvenue vers une tâche différée, exécutée par le cron dans la minute suivant la première connexion plutôt que de façon synchrone.
- Mise en place d’une page d’attente légère en cas de saturation extrême, plutôt qu’une erreur serveur brute renvoyée à l’apprenant.
- Alerte automatique envoyée à l’équipe technique dès que le taux d’utilisation des workers PHP-FPM dépasse 80 % pendant plus de deux minutes consécutives.
Un test de charge qui ne reproduit pas le parcours réel de l’utilisateur ne mesure rien d’exploitable ; il rassure sans rien garantir.
Ce qu’il faut retenir
Le dimensionnement d’une plateforme e-learning pour un lancement à fort trafic ne se limite jamais au nombre d’inscrits total : c’est la concentration du pic de connexion, croisée avec les opérations les plus coûteuses déclenchées à la première connexion, qui détermine le véritable risque. Un test de charge reproduisant fidèlement ce scénario révèle presque toujours un goulot d’étranglement différent de celui qu’on imaginait au départ.
