Chez CrowdHandler, c’est souvent la première question qu’on nous pose : « Prendrez-vous en charge le principe « One In, One Out » ? » Et la réponse est : « Oui, bien sûr… mais, pour la plupart des utilisateurs, nous ne le recommandons pas ».
Nous savons par expérience que le simple fait de définir un débit d'entrée adapté constitue un moyen plus efficace de gérer le trafic que la règle « un qui entre, un qui sort », et qu'il s'agit de la meilleure solution pour la grande majorité de nos clients.
Malheureusement, de nombreux propriétaires de sites web entendent « oui, nous prenons en charge le principe « One In, One Out » », mais ne retiennent pas la deuxième partie de notre conseil. Pour eux, le concept de « One In, One Out » semble tellement logique qu’ils ont du mal à imaginer que le trafic puisse être géré autrement. Ils décident donc de cocher l’option « One In, One Out » et de mettre leur site en ligne… pour finalement constater que des files d’attente se forment et que les utilisateurs se plaignent du temps d’attente.
Alors, quel est le problème avec le principe « un qui entre, un qui sort » ?
Le problème, c'est que la simplicité de la formule « One In, One Out », telle que la plupart d'entre nous la comprenons, ne correspond pas à la réalité du trafic sur les sites web et des parcours des utilisateurs. Le seuil « One In, One Out » peut s'avérer à la fois hors de propos et problématique.
Cela n’a-t-il aucune importance ? Imaginons que vous ayez un site web d’une capacité de 1 000 utilisateurs et que vous autorisiez l’accès à 100 utilisateurs par minute. Vous savez que la durée moyenne d’une session est de dix minutes ; ainsi, en partant d’un démarrage à froid (avec 0 utilisateur), vous vous attendriez à atteindre la capacité maximale en dix minutes. Après cela, si le principe « One In, One Out » fonctionnait comme beaucoup le supposent, le calcul serait simple : 1 000 / 10. Vous vous attendriez à ce que le premier lot de 100 utilisateurs quitte le site à la 10e minute, moment auquel vous autoriseriez l’entrée des 100 utilisateurs suivants, et ainsi de suite.
Ceux qui ont bien suivi en cours d'algèbre ont peut-être remarqué que, à ce stade, la variable de capacité de 1 000 s'est annulée d'elle-même. Il suffirait de fixer le taux d'entrée à 100 pour obtenir exactement le même résultat.
Cependant, le principe « un qui entre, un qui sort » n’est pas seulement hors de propos dans ce scénario. Il pose carrément problème. En effet, cette équation simpliste « un qui entre, un qui sort » fait également abstraction de deux facteurs essentiels : les délais d’expiration des sessions et la capacité de traitement des commandes.
Problème n° 1 : expirations de session
D'accord, disons que le parcours moyen d'un utilisateur peut prendre dix minutes. Mais bon nombre d'utilisateurs ne passeront jamais à la caisse – et s'ils le font, vous ne le saurez peut-être pas (à moins d'avoir mis en place un système de détection des abandons de panier). Ainsi, plutôt que de laisser les sessions des utilisateurs s'éterniser et risquer d'affecter durablement la capacité du système, nous les interrompons après un certain délai.
Le délai d'expiration par défaut d'une session sur CrowdHandler est de 15 minutes, ce qui signifie que la place de chaque utilisateur sera conservée pendant 15 minutes après sa dernière activité. Cela permet aux utilisateurs de faire une petite pause, de répondre à un e-mail urgent ou de comparer rapidement les prix sur un autre site pendant leur visite, puis de revenir dans la file d'attente sans avoir à tout recommencer depuis le début.
Si l'on tient compte de ces 15 minutes, la durée moyenne réelle d'une session utilisateur est donc de 25 minutes. Pour revenir à notre équation, 1 000/25 signifie que le débit effectif n’est que de 40 entrées et sorties par minute si nous appliquons la règle « One In, One Out » avec 1 000 utilisateurs. D’après notre calcul initial, nous nous attendrions à ce qu’une file d’attente de 3 000 personnes soit vide au bout de 30 minutes, avec un temps d’attente médian de 15 minutes. Mais si l'on tient compte du délai d'expiration de la session, les 1 000 premiers utilisateurs quitteront la file d'attente au cours des 10 premières minutes, puis les 2 000 utilisateurs restants la videront à un rythme de 40 par minute, ce qui prendra 50 minutes. La file d'attente entière mettra donc en réalité une heure à se vider, avec un temps d'attente médian de 30 minutes. Soit deux fois plus longtemps.
« Ah ! », pensez-vous. « Mais je ne vais pas laisser entrer les 1 000 premiers utilisateurs à raison de 100 par minute ; je vais maximiser le débit et m’en tenir uniquement au principe “One In, One Out” pour laisser entrer les 1 000 premiers utilisateurs dès la première minute, ce qui me permettra d’optimiser ma capacité. » Eh bien, c’est une mauvaise idée pour deux raisons, mais la première est la suivante : avec le principe « One In, One Out », dans notre scénario type, les 2 000 utilisateurs restants dans la file d’attente ne bougeront pas du tout pendant 25 minutes, lorsque les premières sessions enregistrées commenceront à expirer. Ces utilisateurs verront une position dans la file d’attente qui ne bouge pas et une estimation de temps d’attente catastrophique. C’est exactement le genre d’expérience utilisateur que vous essayez d’éviter. De plus, à moins de prendre soigneusement en compte l’expiration des sessions dans votre seuil « One In, One Out », vous aurez en réalité moins de passages en caisse à long terme, en plus d’une file d’attente tenace.
Problème n° 2 : capacité des caisses
Ce problème trouve son origine dans un autre malentendu : le fait de fonder les paramètres « One In, One Out » sur les résultats des tests de charge.
Les tests de charge ont tendance à augmenter progressivement le trafic (tout comme lorsque l'on définit un débit dans CrowdHandler !) et reproduisent souvent le trafic quotidien, ce qui suppose que les visiteurs sont plus nombreux à naviguer sur le site qu'à effectuer des achats. Cependant, lors d'un lancement de produit très fréquenté ou d'un scénario de « drop », le taux de passages en caisse sera bien plus élevé que dans le trafic normal. Vous devez partir du principe que la plupart des utilisateurs que vous introduisez au début d'un parcours utilisateur passeront en caisse dès que possible.
À bien des égards, le nombre d’utilisateurs simultanés que vous estimez que votre site peut prendre en charge n’a pas d’importance. Ce qui compte, c’est le nombre de paiements ou de transactions qu’il peut traiter par minute. Si de nombreux sites peuvent prendre en charge 1 000 utilisateurs simultanés, très peu sont capables de traiter 1 000 paiements par minute. Baser les paramètres « One In, One Out » sur les métriques d’utilisateurs simultanés ne tiendra pas compte du pic de transactions réelles qui se produit lors d’une mise en ligne ou d’un lancement, et le site risque davantage de planter sous l’afflux de commandes qui se produira à la 10e minute de notre scénario type, si vous autorisez l’accès à 1 000 utilisateurs dès la première minute.
Une analogie utile est celle d’un magasin physique pouvant accueillir 1 000 personnes mais ne disposant que de 10 caisses. Bien que le magasin puisse accueillir confortablement 1 000 clients, il ne peut traiter efficacement que 10 commandes par minute. Laisser entrer 1 000 clients en même temps ne fera que créer de longues files d’attente de personnes frustrées, sans que la situation ne s’améliore, les transactions s’accumulant. Il en va de même en ligne, sauf que le risque ne se limite pas à de longues files d’attente, mais peut également entraîner des pannes de serveurs.
Comment bien s'y prendre
Une façon d'atténuer les problèmes liés au principe « One In, One Out » consisterait à effectuer certains calculs complexes lors de la configuration. Il pourrait s'agir, par exemple, d'augmenter la capacité « One In, One Out », de réduire les paramètres de délai d'expiration des sessions, de calculer les ratios entre sessions et passages en caisse, de s'assurer que l'option « Détruire la session lors du passage en caisse » est activée et de déterminer les durées réelles des parcours utilisateurs.
En fait, cela nous a tellement attristés de voir des clients compromettre leurs ventes en raison de mauvais réglages « One In, One Out » que nous avons ajouté un outil de vérification qui effectue ces calculs et leur propose des recommandations :
Pour certains clients – ceux pour qui le nombre de sessions simultanées constitue véritablement un indicateur critique de performance, qui sont convaincus de bien comprendre tous les résultats de leurs tests de charge et qui ont une vision claire des paramètres optimaux pour les délais d'expiration des sessions ainsi que de leur impact sur le seuil « One In, One Out » –, ces calculs peuvent s'avérer pertinents. Si vous faites partie de ces clients, nous vous tirons notre chapeau.
Mais pour la plupart des clients, la réponse est bien plus simple : oubliez les calculs compliqués basés sur des limites théoriques et des tests de charge peu fiables, et concentrez-vous sur les indicateurs qui ont un impact réel sur l'expérience utilisateur. La réussite passe par la compréhension de votre débit de pointe avéré, et non par celle d'un nombre hypothétique d'utilisateurs simultanés.
Pour la plupart des sites, cela implique d’ajuster le débit d’entrée à une valeur légèrement supérieure à votre débit maximal de finalisation de commande. (Un bon point de départ consiste à diviser par 60 le nombre maximal de commandes que vous avez traitées avec succès en une heure, puis à fixer le débit à une valeur légèrement supérieure à ce chiffre.) Cela permettra d’assurer un bon flux de visiteurs sur votre site.
Commencez par une configuration prudente, puis surveillez attentivement les performances. Si la file d'attente s'allonge mais que le site reste parfaitement opérationnel, vous pouvez toujours augmenter le débit ; la fonctionnalité « Autotune » de CrowdHandler peut vous y aider.
En résumé : privilégiez les performances avérées
En tant que stratégie de file d'attente, cela peut sembler logique, mais une compréhension simpliste du principe « un entré, un sorti » ne tient pas compte des facteurs concrets qui interviennent lors de la mise en œuvre. Cela entraîne souvent des problèmes tels que de longs délais d'attente, des clients mécontents et des échecs lors du paiement, car les calculs reposent sur des hypothèses : des indicateurs peu fiables ou irréalistes.
Ainsi, même si nous sommes favorables à cette approche, notre conseil est le suivant : ne fixez pas de seuil « One In, One Out » sans en comprendre exactement la signification, et privilégiez vos taux de finalisation de commande plutôt que les indicateurs d'utilisateurs simultanés. En vous concentrant sur des performances avérées et sur les limites réelles de votre site, vous améliorerez l'expérience utilisateur pour tous.