10 000 apprenants qui se connectent à la même minute pour démarrer un examen chronométré : ce chiffre suffit à faire paniquer n’importe quel prestataire d’hébergement s’il ne l’a pas anticipé. Contrairement à un site e-commerce qui subit des pics diffus sur plusieurs jours, une plateforme d’examen encaisse une charge concentrée sur une fenêtre de quelques heures, à une date connue à l’avance.
C’est justement cette prévisibilité qui change la méthode. Il ne s’agit pas de sur-dimensionner un serveur à l’année « au cas où », mais de calculer précisément la charge attendue et de louer la puissance nécessaire pour la seule durée du créneau. Voici la démarche que nous suivons pour ce type de mission, sans jamais toucher au LMS lui-même : celui-ci reste la responsabilité de l’éditeur de la plateforme.
Calculer la charge réelle avant de réserver quoi que ce soit
Le premier réflexe erroné consiste à diviser le nombre d’apprenants par la durée de l’examen et à en déduire une charge moyenne. C’est une erreur : la connexion se concentre presque toujours sur les cinq premières minutes, au moment où la session s’ouvre. Sur un examen de deux heures avec 10 000 candidats, on observe généralement 60 à 70 % des connexions dans le premier quart d’heure.
Il faut donc raisonner en requêtes par seconde sur cette fenêtre critique, pas en moyenne sur la durée totale. Une authentification, un chargement de page d’examen et quelques requêtes AJAX de sauvegarde automatique représentent, sur nos mesures, entre 8 et 12 requêtes HTTP par candidat lors de la première minute de connexion.
- Nombre de candidats attendus dans le quart d’heure critique
- Poids moyen d’une page d’examen (idéalement sous 200 Ko hors médias)
- Fréquence des appels de sauvegarde automatique (souvent toutes les 30 à 60 secondes)
- Marge de sécurité pour les retardataires qui se connectent tous en même temps après un message de rappel
Provisionner à l’heure plutôt qu’à l’année
Une fois la charge chiffrée, la question devient : faut-il un VPS dédié loué toute l’année pour un usage de quatre heures ? Dans l’immense majorité des cas, non. Les offres cloud à la demande (instances facturées à l’heure) permettent de monter une machine dimensionnée pour le pic la veille de l’examen, et de la redescendre dès la clôture des sessions.
Concrètement, cela signifie remonter temporairement le nombre de workers PHP-FPM, augmenter la RAM allouée à MariaDB pour son buffer pool, et activer un cache de pages agressif en amont (reverse proxy ou CDN) pour absorber les requêtes qui ne nécessitent pas de session authentifiée.
Un exemple de configuration temporaire
; php-fpm pool dédié, actif seulement le jour J
pm = dynamic
pm.max_children = 180
pm.start_servers = 40
pm.min_spare_servers = 20
pm.max_spare_servers = 60
pm.max_requests = 500
Cette configuration est déployée par un script de provisioning quelques heures avant l’ouverture des sessions, puis remplacée par la configuration standard une fois l’examen terminé. L’objectif n’est pas de garder ces réglages en production toute l’année, ce qui gaspillerait de la mémoire sans bénéfice.
Tester la charge avant le jour réel
Aucun dimensionnement théorique ne remplace un test de charge réaliste. Nous utilisons des scénarios reproduisant le comportement exact des candidats : connexion, affichage de la première question, envoi périodique des réponses, jusqu’à la soumission finale. Ce test doit être mené sur l’infrastructure cible, avec les mêmes réglages que ceux prévus pour le jour J, faute de quoi les résultats ne veulent rien dire.
Un point souvent négligé : la base de données. Une charge d’écriture massive et simultanée (chaque sauvegarde automatique génère une requête UPDATE) sature plus vite les connexions MySQL que les requêtes de lecture. Le paramètre max_connections doit être révisé à la hausse, en cohérence avec la mémoire disponible.
Prévoir le scénario de repli
Même avec un calcul rigoureux, un dimensionnement peut être pris en défaut : un incident réseau chez un fournisseur tiers, une meilleure participation que prévu, ou un comportement inattendu du LMS sous charge. Un plan de repli documenté doit exister avant le jour J.
Sur ce type de mission, nous provisionnons systématiquement 30 % de capacité supplémentaire par rapport au calcul théorique, et nous gardons la main pour ajouter une instance en quelques minutes sans redémarrage complet du service.
Ce plan inclut une procédure de mise en file d’attente (salle d’attente virtuelle) si la charge dépasse malgré tout la capacité prévue, plutôt que de laisser le serveur s’effondrer et perdre des réponses d’examen en cours de saisie.
Notre verdict
Dimensionner un serveur pour un pic daté et prévisible n’a rien à voir avec le dimensionnement d’un site à trafic stable : c’est un exercice de calcul de charge suivi d’un provisionnement temporaire, testé avant le jour réel. Sur nos missions, cette approche revient environ trois fois moins cher qu’un VPS dédié loué à l’année pour un usage de quatre heures, tout en offrant une marge de sécurité supérieure. La rigueur du calcul de charge en amont fait toute la différence entre un examen qui se déroule sans accroc et un incident qui remet en cause la validité des résultats.
