La plus grosse erreur que font les équipes lors des tests de charge se produit avant même qu’un seul script ne soit écrit : elles choisissent la mauvaise taille de test. Un test de charge trop petit vous donne une confiance trompeuse. Tout apparaît en vert dans vos tableaux de bord, mais lorsque le trafic augmente en production, des fissures apparaissent. Un test de charge trop grand est tout aussi mauvais. Vous perdez du temps, de l’argent et de l’infrastructure en testant un scénario qui n’arrive jamais, et vous finissez par courir après des goulets d’étranglement fantômes.
Il existe de nombreux récits édifiants. Par exemple, une grande entreprise a lancé un nouveau produit lors du Black Friday après n’avoir testé que 500 utilisateurs simultanés parce que cela « semblait sûr ». Quelques minutes après le lancement de la promotion, le trafic a grimpé à 2 500 utilisateurs et la chaîne de paiement s’est effondrée. À l’autre extrémité du spectre, une université a insisté pour tester son nouveau portail avec 1 000 utilisateurs, alors que le pic historique de trafic n’avait jamais dépassé 5 000. Le résultat : des factures cloud gonflées et un mois perdu à courir après des goulets d’étranglement qui ne se seraient jamais déclenchés en réalité.
Le dimensionnement est l’endroit où l’art et la science des tests de charge se rencontrent. Vous avez besoin d’un chiffre suffisamment grand pour être significatif, mais assez ancré pour refléter la réalité. Le problème est que la plupart des équipes n’ont pas de chiffre clair de « utilisateurs simultanés » dans leurs documents de projet. Beaucoup choisissent par défaut un nombre rond comme 500, 1 000 ou 10 000 simplement parce que cela a l’air autoritaire sur une diapositive, et ce n’est pas suffisant.
Dans cet article, nous allons passer en revue trois façons éprouvées de dimensionner vos tests de charge : 1) piloté par les exigences, 2) basé sur les transactions, et 3) basé sur les analyses. Chacune offre un cadre pour transformer des données désordonnées ou incomplètes en une taille de test défendable — une taille qui correspond au trafic de production plutôt qu’à des suppositions.
Méthode 1 : Dimensionnement piloté par les exigences
Quand vous avez de la chance, vos exigences contiennent déjà la réponse — il suffit de lire entre les lignes.
Certains scénarios le rendent évident. Si votre entreprise planifie une assemblée générale diffusée en direct où la présence est obligatoire, la simultanéité équivaut au nombre de participants. S’il y a 1 000 employés, vous devriez tester pour 1 100 utilisateurs simultanés (le nombre d’employés plus une marge de sécurité de 10 %). C’est à peu près aussi simple que cela.
D’autres événements sont plus délicats mais restent prévisibles. Prenez un système d’inscription aux cours d’une université. La plupart de l’année, le trafic est stable et modéré. Mais le jour des inscriptions, le système est mis à rude épreuve. Les étudiants se précipitent pour obtenir des places dans les cours populaires, et le trafic dépasse largement la ligne de base. Si vous savez qu’il y a 10 000 étudiants et que l’expérience vous dit que 90 % d’entre eux accéderont au système pendant les inscriptions, cela fait 9 000 utilisateurs simultanés. Ajoutez des comportements comme des étudiants demandant à des amis ou à la famille de se connecter depuis plusieurs appareils, et la simultanéité réelle peut dépasser 100 % de la population étudiante. Un test prudent pourrait dimensionner le trafic à 200 % des utilisateurs étudiants.
Cela se retrouve aussi dans d’autres secteurs. Considérez un portail fiscal gouvernemental en avril. Le système peut avoir une utilisation légère tout au long de l’année, mais le jour de la déclaration, la simultanéité augmente fortement. Ou regardez une plateforme de billetterie de concerts. Pour la plupart des événements, le trafic est réparti. Mais quand les billets d’un artiste majeur sont mis en vente à 10 h précises, tous les fans appuient sur « actualiser » en même temps (sans parler des bots qui tentent d’acheter des billets, ce qui est une problématique distincte à prendre en compte). Ce sont des moments pilotés par les exigences, et votre test de charge doit être dimensionné en conséquence.
Pièges : Les exigences sous-estiment souvent. Les parties prenantes peuvent minorer la participation pour rester conservatrices sur le budget, ou elles peuvent ne pas prendre en compte les « lurkers » qui se connectent tôt pour sécuriser une place, ou les bots. Remettez toujours le chiffre en question, modélisez le comportement de pic et ajoutez des marges.
Règle générale : Le dimensionnement piloté par les exigences fonctionne mieux lorsque l’événement est limité dans le temps et prévisible, avec des comptes de participants clairs. Dans ces cas, les exigences vous donnent la base la plus défendable.
Méthode 2 : Dimensionnement basé sur les transactions
Quand les exigences ne vous donnent pas de chiffre, vos transactions métier le feront. Au lieu de penser en termes d’utilisateurs abstraits, pensez en termes d’actions : commandes, inscriptions, paiements, téléchargements, enchères.
Les calculs fonctionnent ainsi :
- Identifiez le volume de transactions au pic. Supposons que votre plateforme e-commerce traite 1 000 commandes un jour typique, mais pendant les fêtes, le volume augmente de 50 % pour atteindre 1 500 commandes.
- Trouvez la fenêtre active. Si la plupart des commandes ont lieu entre 10 h et 22 h, c’est une fenêtre de 12 heures, soit ~125 commandes par heure.
- Ajustez pour une distribution inégale. Le trafic est rarement uniforme. Si les heures de pointe sont 25 % plus élevées, cela fait ~160 commandes durant l’heure la plus chargée.
- Traduisez en simultanéité. Si un client met cinq minutes à finaliser une commande, alors 160 commandes/heure équivalent à 2,67 commandes/minute. Multipliez par la durée de cinq minutes et vous obtenez ~14 utilisateurs simultanés qui passent réellement des commandes.
- Ajoutez le trafic de navigation. Les acheteurs ne sont pas toute l’histoire. Si vos analyses montrent 10 navigateurs pour un acheteur, cela représente 140 utilisateurs simultanés supplémentaires.
- Ajoutez une marge. Avec une marge de sécurité de 25 %, vous êtes maintenant à ~190 utilisateurs. Vous pourriez même vouloir ajouter 50 % ou 100 % de marge (ou plus selon la variabilité).
Voilà la taille de votre test dans cet exemple : 190 utilisateurs simultanés reproduisant les schémas de transaction les plus chargés et significatifs que votre système rencontrera.
Cette méthode fonctionne bien car elle relie la charge directement aux résultats métier. Vous ne testez pas seulement « 190 utilisateurs », vous validez la capacité à traiter « 160 commandes pic/heure plus la navigation ». C’est un chiffre que les parties prenantes comprennent et apprécient.
Deuxième exemple : Les plateformes d’enchères. Supposons que vous constatiez une moyenne de 10 000 enchères par jour, dont 40 % se concentrent dans les deux dernières heures des enchères phares. Cela fait 4 000 enchères sur deux heures, soit ~2 000/heure. Si chaque enchère prend en moyenne 30 secondes, cela représente ~16 utilisateurs simultanés en train d’enchérir. Mais si votre ratio navigation/enchères est de 30:1 (commun sur les sites d’enchères), il vous faudra simuler près de 500 utilisateurs pour refléter la charge réelle. Cette taille de test vous indique si votre système peut gérer non seulement le pic d’enchères, mais aussi l’afflux de navigateurs qui regardent et actualisent les annonces.
La saisonnalité compte aussi. Le commerce de détail n’est pas le seul secteur à connaître des pics. Les plateformes de voyage voient des pics de demande pendant les vacances. Les portails fiscaux sont saturés en avril. L’onboarding SaaS explose lorsque de nouveaux contrats sont signés. Le dimensionnement basé sur les transactions s’adapte à tout cela en liant la simultanéité à des événements spécifiques au métier.
Règle générale : Utilisez le dimensionnement basé sur les transactions lorsque les exigences sont vagues mais que les métriques métier sont claires. C’est précis, compréhensible pour les parties prenantes et directement lié aux résultats.
Méthode 3 : Dimensionnement basé sur les analyses
Lorsque les exigences sont vagues et que vous n’avez pas de données de transactions, les outils d’analytique peuvent combler la lacune. Google Analytics, Adobe Analytics ou des plateformes similaires vous fournissent des données de trafic qui peuvent être traduites en simultanéité avec un peu de calcul.
Voici comment :
- Commencez par le trafic de pointe. Supposons que votre site ait reçu 50 000 visiteurs lors de sa journée la plus chargée.
- Convertissez en trafic horaire. Divisez par 24 heures = ~2 100 visiteurs/heure.
- Ajustez pour les pics. Le trafic n’est pas plat. Ajoutez 50 % pour tenir compte d’une distribution inégale → ~3 150 visiteurs/heure.
- Utilisez la durée moyenne de session. Si les utilisateurs passent en moyenne deux minutes sur le site, alors 3 150 / 60 × 2 = ~105 utilisateurs simultanés.
- Ajoutez une marge. Avec une marge de 25 %, vous êtes à ~130 utilisateurs simultanés.
Voilà votre taille de test : 130 utilisateurs reflétant le trafic le plus intense enregistré par vos analyses.
Exemple : Une entreprise SaaS avec 500 000 utilisateurs actifs mensuels. Si les utilisateurs actifs quotidiens représentent ~10 % de ce nombre (50 000), et que 20 % se connectent pendant les heures de pointe, vous avez 10 000 utilisateurs dans votre fenêtre la plus chargée. Si la durée moyenne de session est de 15 minutes, cela se traduit par ~2 500 utilisateurs simultanés à tester.
Précautions sur la précision : Les analyses sont meilleures que les logs, mais elles ne sont pas parfaites. Considérez :
- Les bloqueurs de pubs peuvent masquer certaines visites.
- Les bannières de consentement aux cookies peuvent provoquer des sous-comptages si les utilisateurs refusent le suivi.
- Le trafic de bots peut gonfler les chiffres s’il n’est pas filtré.
Malgré ces problèmes, les analyses constituent une solution de repli solide. Elles reflètent des sessions utilisateurs réelles, normalisées entre appareils et emplacements, et peuvent être segmentées par géographie ou type d’appareil si votre plateforme a un trafic régional ou fortement mobile.
Règle générale : Utilisez le dimensionnement basé sur les analyses lorsque les métriques métier ne sont pas disponibles, mais que vous disposez de données de trafic cohérentes. C’est la façon la plus pratique d’ancrer vos tests dans la réalité.
Cas spécial : Applications entièrement nouvelles
Et si vous démarrez avec une application toute neuve ? Vous n’avez pas de exigences définissant la simultanéité, pas d’historique de transactions ni de données analytiques, ce qui pose un problème entièrement différent.
L’erreur courante est de choisir un nombre rond comme « 2 000 utilisateurs simultanés » parce que cela semble sûr. Mais ce chiffre est sans signification s’il n’est pas lié au comportement attendu.
Une meilleure approche consiste à projeter le trafic en termes de transactions ou de sessions. Si vous attendez 200 téléchargements par heure, dimensionnez votre test pour valider cela. Si vous attendez 10 000 inscriptions le jour du lancement, convertissez cela en trafic horaire et en durée de session. Même des estimations approximatives cadrées ainsi vous donnent des résultats interprétables en termes métier — tout cela se modélise et se calcule.
Exemple : Supposons que votre équipe marketing projette 5 000 inscriptions durant la semaine de lancement, concentrées par un gros communiqué de presse. Si vous supposez que 60 % tombent le premier jour, cela fait 3 000 inscriptions. Réparties de façon inégale, avec 40 % dans les trois premières heures, cela fait ~1 200 inscriptions. Si la création de compte prend trois minutes, vous regardez ~60 inscriptions simultanées. Ajoutez la navigation et le trafic de réessai, et vous pourriez raisonnablement tester 200–300 utilisateurs simultanés. Ce chiffre repose sur des hypothèses, mais elles sont au moins explicites, et vous pouvez les affiner lorsque des données réelles arrivent.
Méfiez-vous des suppositions parce que les managers veulent présenter quelque chose d’un certain ordre. Les parties prenantes ou les managers peuvent pousser pour des chiffres ronds énormes (« Testons 50 000 utilisateurs pour montrer aux investisseurs que nous sommes prêts à monter en charge »). Résistez à cela. Des tests surdimensionnés ne créent pas de confiance — ils génèrent du bruit et du gaspillage. Basez votre dimensionnement sur les transactions projetées, même si ce ne sont que des estimations.
Tableau récapitulatif : choisir la bonne méthode
| Méthode | Quand l’utiliser | Forces | Risques / limites |
| Piloté par les exigences | Événements prévisibles et limités dans le temps | Clair, défendable, facile à calculer | Sous-estimation par les parties prenantes, conflits |
| Basé sur les transactions | Applications existantes avec données métier claires | Lie directement aux résultats, ratios précis | Requiert de bonnes métriques, effets saisonniers |
| Basé sur les analyses | Sites avec historique de trafic cohérent | Facile à calculer, basé sur des sessions réelles | Bloqueurs de pubs, bots, précision inégale |
| Nouvelles applications | Pas d’historique ni de données disponibles | Force des hypothèses explicites, orienté vers l’avenir | Risque de conjectures |
Réflexions finales sur le bon dimensionnement des tests de charge
Le but d’un test de charge n’est pas d’atteindre un nombre — c’est de répondre à une question. Votre système peut-il gérer les comportements et événements spécifiques qui comptent pour votre activité ?
- Si les exigences vous donnent des nombres directs, utilisez-les.
- Sinon, les transactions fournissent l’ancrage le plus précis et orienté métier.
- Si ceux-ci ne sont pas disponibles, les analyses offrent une solution de repli fiable.
- Pour les systèmes tout neufs, les projections valent mieux que des chiffres arbitraires.
Et peu importe la méthode choisie, ajoutez toujours une marge. Le trafic réel est en rafales, imprévisible et rarement aligné sur des moyennes parfaites.
LoadView aide à rendre chacune de ces stratégies de dimensionnement pratiques. Avec LoadView, vous pouvez modéliser non seulement des nombres d’utilisateurs, mais des schémas réalistes — pics de trafic lors des inscriptions, mélange de navigation et de commande, ou distribution globale correspondant à vos analyses. Cela signifie que votre test n’est pas qu’un chiffre, c’est une répétition générale pour la réalité de production.
Le dimensionnement est la première décision dans tout test de charge. Faites-le bien, et tous les résultats que vous obtiendrez par la suite auront du sens. Faites-le mal, et aucun script ni rapport ne vous sauvera. Avec les trois méthodes décrites ici, vous pouvez dimensionner vos tests en toute confiance et vous assurer que vos résultats de performance correspondent réellement au trafic et à l’activité de votre site ou application.