Comment générer des modèles de trafic réalistes pour les applications d’entreprise

La plupart des tests de charge d’entreprise commencent avec un nombre choisi lors d’une réunion. Cinq mille utilisateurs virtuels. Dix mille. Le test réussit, le rapport est archivé, et l’application plante toujours le premier lundi du trimestre.

Les nombres ronds sont faciles à convenir et ne vous disent presque rien. Le trafic réel arrive par rafales, se répartit inégalement entre les fonctionnalités, et modifie sa composition au moment précis où le volume atteint son pic. Un test qui envoie un flux plat de requêtes identiques exerce un chemin de code différent de celui de la production, avec un comportement de cache, des plans de requête, et une contention de verrouillage sans rapport avec le système en direct.

Voici comment construire un modèle de trafic à partir des données que vous collectez déjà, et comment le lancer pour que les résultats aient du sens.

Table des matières

1. Pourquoi le trafic d’entreprise est difficile à simuler
2. Où les données de trafic existent déjà
3. Comment construire un modèle de trafic à partir des données de production
4. Où les modèles de trafic échouent
5. À quoi ressemblent les formes de trafic réelles en entreprise
6. Comment exécuter le modèle dans LoadView
7. Comment vérifier le modèle par rapport à la production
8. En résumé
9. Questions fréquentes

Pourquoi le trafic d’entreprise est difficile à simuler

Trois choses déconcertent les équipes qui passent directement d’un nombre de personnel à un test en cours.

La concurrence et le taux d’arrivée ne sont pas le même chiffre. Quand un intervenant dit « nous devons gérer 5 000 utilisateurs », demandez lequel des deux il entend. Cinq mille personnes connectées simultanément est un test complètement différent de cinq mille sessions démarrant chaque heure. Se tromper dans le sens généreux vous fera passer des semaines à ajuster une charge qui n’arrivera jamais. Se tromper dans l’autre sens ne vous dit rien. Le test d’utilisateurs concurrents ne prend sens que lorsque vous savez lequel des deux chiffres vous ciblez. C’est la différence entre un modèle basé sur le taux d’arrivée, qui reflète comment les utilisateurs arrivent réellement, et un modèle basé sur la concurrence, qui maintient une population fixe dans le système. Le trafic public est presque toujours le premier. Les systèmes avec une base utilisateur limitée — postes de centre d’appels, sièges sous licence, portails d’agents — se comportent vraiment comme le second.

Le trafic a une forme, et c’est cette forme qui cause les dommages. Les pools de connexions, les groupes de mise à l’échelle automatique et les serveurs d’application chauffés JIT répondent tous au taux de changement, pas seulement au plafond. Un système qui gère confortablement 2 000 utilisateurs concurrents peut échouer en atteignant 2 000 s’il y arrive en quatre-vingt-dix secondes.

Le mélange des transactions évolue avec le volume. À volume moyen, un site e-commerce voit surtout du navigation. Lors d’une vente flash, les appels de paiement et de gestion des stocks prennent une part beaucoup plus grande sur le même nombre de requêtes. Le nombre total paraît identique sur un tableau de bord. La charge sur la base de données ne l’est pas.

Un nombre plat d’utilisateurs virtuels et une courbe d’arrivée façonnée peuvent produire le même débit moyen tout en sollicitant des parties totalement différentes de la pile.

Où les données de trafic existent déjà

Vous n’avez pas besoin d’une nouvelle instrumentation. La plupart de ces données sont déjà écrites quelque part sur disque. Le travail consiste à les assembler en sessions et à filtrer le trafic des bots avant de compter quoi que ce soit.

Les applications internes d’entreprise n’ont généralement aucune balise d’analyse. Les journaux d’authentification et les journaux des serveurs d’application comblent cette lacune — les événements de connexion fournissent le taux d’arrivée, et le temps entre la première et la dernière requête par session donne la durée.

Comment construire un modèle de trafic à partir des données de production

Quatre sorties définissent le modèle : taux d’arrivée, mélange des transactions, distribution des temps de réflexion, et répartition géographique.

Étape 1 : Choisissez la fenêtre exacte que vous modélisez

Pas “le pic de trafic”. Une heure précise, à une date précise, extraite de vos journaux. Prenez l’heure à plus fort débit des douze derniers mois, puis choisissez une deuxième fenêtre couvrant votre pire événement commercial — clôture de fin de mois, inscription ouverte, Black Friday, rapport trimestriel. Modélisez les deux. Ils n’ont presque jamais la même forme.

Étape 2 : Comptez les sessions, pas les requêtes

Les requêtes par seconde sont les chiffres les plus faciles à extraire mais aussi les moins stables. Déployez une version frontale qui regroupe trois appels API en un seul et votre nombre de requêtes baisse d’un tiers sans changement de la demande. Les sessions par heure reflètent ce que les utilisateurs font réellement. L’écart est le plus grand sur les applications monopages, où un clic peut générer une douzaine d’appels API en arrière-plan.

Extrayez les sessions par heure pour votre fenêtre, ainsi que la durée moyenne et au 90e percentile des sessions. Gardez les deux chiffres — la queue compte à l’étape trois.

Étape 3 : Convertissez les sessions en concurrence

La loi de Little relie le taux d’arrivée à la concurrence :

Sessions concurrentes = sessions par heure × (minutes moyennes par session ÷ 60)

18 000 sessions/heure × (6 minutes ÷ 60) = 1 800 sessions concurrentes

Lancer 18 000 utilisateurs virtuels simultanés contre cette application, c’est tester quelque chose dix fois plus grand que votre pic réel. Vous échouerez à un test que vous auriez réussi, puis passerez un sprint à traquer un goulet d’étranglement que la production n’atteindra jamais.

La loi de Little prend la moyenne, donc considérez P90 comme une vérification de dimensionnement distincte plutôt qu’une seconde lecture de la formule. Avec un P90 à 22 minutes contre une moyenne de 6 minutes, vous obtenez environ 6 600 — la concurrence si chaque session dure aussi longtemps que le dixième le plus lent. Volontairement pessimiste, c’est le chiffre utile pour la planification de capacité lorsque des sessions longues retiennent des ressources rares comme des threads de rapports ou des connexions à la base.

Étape 4 : Répartissez le trafic en transactions métier

Regroupez les points de terminaison en transactions métier plutôt qu’en URL : recherche, consultation détaillée, ajout au panier, soumission de réclamation, export de rapport, paie. Enregistrez ensuite deux mixages — la part de chaque transaction sur la totalité de la fenêtre, et sa part durant la minute la plus chargée.

Si ces deux mixages diffèrent de plus de quelques points de pourcentage sur une transaction, construisez-les tous deux dans le test et exécutez-les comme scénarios séparés. Un test basé uniquement sur le mix horaire sous-évaluera la charge de la transaction qui connaît le plus de pics au pic.

Étape 5 : Extrait les temps de réflexion des vraies sessions

Ne devinez pas le temps de réflexion et n’utilisez pas de constante. Une pause fixe de cinq secondes synchronise tous les utilisateurs virtuels en colonne, frappant l’application en cadence, générant un débit en pics qu’aucune population réelle ne produit.

Extrayez le délai entre chargements de pages consécutifs dans de vraies sessions à partir des données RUM ou APM et reproduisez-le comme une distribution. Les utilisateurs d’entreprise sont généralement bimodaux : courts écarts en naviguant dans un flux qu’ils connaissent par cœur, longs en lisant un document ou prenant un appel téléphonique.

Étape 6 : Adaptez la montée en charge à la courbe réelle

Tracez le nombre de sessions par minute sur votre fenêtre et façonnez la montée du test pour qu’elle corresponde. Trois formes couvrent la plupart des applications d’entreprise :

• Presque verticale. Lancements de produits, ventes de billets, ouverture de marché. Le pic de concurrence arrive en moins de deux minutes.
• Escalier. Applications internes qui s’activent à 9 h dans chaque fuseau horaire, un palier par région.
• Onde carrée. Trafic batch et intégration. Allumé à plein volume, éteint à plein volume, sans montée.

Étape 7 : Placez la charge là où sont vos utilisateurs

Utilisez la répartition géographique des analyses ou journaux CDN et générez la charge depuis ces mêmes régions. Cela ne concerne pas uniquement la mesure de la latence pour les utilisateurs distants. La latence influe sur la concurrence : une session tenue ouverte par un aller-retour de 280 ms dure plus longtemps que la même session sur une connexion de 20 ms, donc des taux d’arrivée identiques produisent une concurrence plus élevée. Tester tout depuis une seule région cache cela entièrement.

Où les modèles de trafic échouent

Un jeu de données par utilisateur virtuel. Même login, même ID produit, même numéro de compte pour dix mille utilisateurs, et votre taux de hit de cache monte à presque 100 %. La production ne se comporte pas ainsi. Paramétrez avec un jeu de données suffisamment large pour correspondre à la cardinalité réelle — un pool de comptes, une liste d’SKU, des IDs de commande uniques par exécution — puis comparez le taux de hit du cache du test à celui de la production avant de faire confiance à un résultat.

Rien d’autre ne tourne pendant le pic. Les pics d’entreprise coïncident avec des travaux programmés : ETL nocturnes, reconstruction d’index, génération de rapports, fenêtres de sauvegarde, synchronisation de réplication. Si le travail de rapprochement s’exécute à 2 h du matin et que votre pic batch est aussi à 2 h, un environnement de test propre sans charge de fond mesure un système que vous n’opérez pas.

Tests protocolaires uniquement sur des applications lourdes en navigateur. Un test au niveau HTTP rejoue les requêtes capturées lors de l’enregistrement. Il n’exécutera pas de JavaScript, ne déclenchera pas les appels chargés paresseusement, n’exécutera pas les balises tierces, ni ne rendra quoi que ce soit. Pour une application monopage ou un portail interne lourd, cela exclut la plupart du travail effectué par le client — et tout ce qui détermine l’affichage utilisateur. Le test de charge d’application web dans de vrais navigateurs est la seule manière de mesurer le rendu côté client sous charge.

Le chemin heureux uniquement. Le trafic réel comprend des paniers abandonnés, des boucles de retour, des connexions échouées, des jetons expirés, et des double-clics impatients. Les connexions échouées valent un scénario à part : elles touchent le fournisseur d’identité, contournent généralement le cache, et déclenchent souvent une logique de verrouillage qui ajoute des écritures.

À quoi ressemblent les formes de trafic réelles en entreprise

Trois modèles qui reviennent sans cesse, et ce que chacun exige du modèle.

Vente flash ou lancement de produit dans le commerce de détail

L’arrivée est quasi verticale et le mélange se concentre sur trois transactions : détails produit, ajout au panier, paiement. Si la page produit est cacheable, le taux de hit CDN s’améliore car tout le monde demande le même article populaire, ce qui rend un test naïf facile. La pression retombe sur les appels non cacheables — vérifications de stock, écritures de panier, autorisations de paiement — tous frappant simultanément l’origine avec contention au niveau des lignes pour un seul SKU. Modélisez le mélange à la minute de pic, pas à l’heure.

Clôture de fin de mois dans un ERP interne

Le volume de sessions est banal. La durée de session ne l’est pas. Les exports de rapports et les traitements batch durent plusieurs minutes, donc la concurrence monte bien que le taux d’arrivée semble plat — la loi de Little qui joue contre vous. Cela s’ajoute aussi au batch de clôture comptable, donc la charge de fond fait partie du test. Séparez les utilisateurs de rapport longue durée et ceux du traitement en leur propre classe transactionnelle avec leur propre durée au lieu de les fusionner dans une moyenne unique.

Période d’inscription ouverte dans l’assurance

Semaines de charge élevée avec un pic marqué les deux derniers jours. Les sessions sont longues car les gens lisent les documents de plan, et elles comportent beaucoup d’authentification et de téléchargements. La partie de plusieurs semaines est un test d’endurance, où les fuites de mémoire, l’épuisement du pool de connexions, et le volume des journaux comptent plus que la concurrence maximale. Le pic des derniers jours nécessite son propre modèle.

Comment exécuter le modèle dans LoadView

Une fois le modèle créé, la configuration du test en découle. LoadView propose trois courbes de charge, et votre modèle vous indique laquelle choisir :

Enregistrez le flux de session avec EveryStep Web Recorder pour que le script reproduise le parcours utilisateur dans un vrai navigateur, sur les navigateurs desktop et mobiles que vos analyses indiquent. Fixez la répartition régionale avec le réseau d’injection géo-distribué pour correspondre à l’étape sept de votre modèle.

Pour les applications qui ne touchent jamais l’internet public, les injecteurs sur site testent la charge derrière votre pare-feu tout en rapportant sur la même plateforme — c’est ainsi que la plupart du trafic ERP interne et portail est modélisé.

Comment vérifier le modèle par rapport à la production

Un modèle de trafic est une hypothèse tant que vous ne comparez pas ses sorties au réel. Capturez l’arrière-plan pendant l’exécution du test — événements d’attente en base, saturation des pools de connexions, profondeur des files, activité d’autoscaling, taux de requêtes CDN à l’origine, limitation du fournisseur d’identité. Ces signaux expliquent les chiffres ci-dessous.

Après le test, mettez cinq mesures côte à côte avec la production pour la même fenêtre :

1. Débit par transaction. Si le débit du test est bien en dessous de la production au même nombre d’utilisateurs, le temps de réflexion est trop long ou le script manque des appels.
2. Pourcentages de mix transactionnel. Une dérive ici signifie que la logique de branchement du script ne correspond pas aux mouvements réels des utilisateurs.
3. Taux de hit du cache. Un test à 95 % contre une production à 70 % indique un jeu de données trop restreint.
4. Taux et types d’erreurs. La production a presque toujours un taux d’erreur de base. Un test sans erreur saute généralement quelque chose.
5. Durée moyenne de session. Cela valide tout le calcul de concurrence de l’étape trois.

Puis analysez vos résultats de test de charge par rapport à ces cinq mesures, ajustez le script, et relancez. Deux itérations suffisent généralement pour obtenir un modèle assez proche pour être fiable.

Questions fréquentes

En résumé

Un pattern de trafic réaliste est défini par quatre mesures, pas un seul chiffre : la vitesse d’arrivée des sessions, ce que ces sessions font, la durée des pauses des utilisateurs entre actions, et leur localisation. Chacune est déjà présente dans vos journaux.

Extrayez ces quatre, appliquez la loi de Little pour obtenir une donnée de concurrence vérifiable, et ajustez la montée en charge pour correspondre à une vraie heure au lieu d’une ligne droite. Puis validez le test par rapport à la production et ajustez. C’est plus de travail que de choisir un nombre rond d’utilisateurs virtuels, mais c’est la seule version de test dont vous pouvez vous servir.

Testez votre modèle de trafic dans de vrais navigateurs

LoadView exécute vos flux de session dans de vrais navigateurs depuis plus de 40 zones AWS et Azure, avec des courbes de charge que vous façonnez selon le rythme d’arrivée mesuré. Les plans de tests de charge enterprise ajoutent des sous-comptes, SSO, et migration de scripts depuis des outils hérités.

Planifiez une démo avec un ingénieur performance LoadView pour parcourir votre modèle de trafic.