Lorsque vous installez CrowdHandler et que vous configurez une salle d'attente, nous souhaitons que tout se passe bien dès le départ.
Nous sommes ravis de constater que de nombreux utilisateurs ont installé CrowdHandler directement en production, en pleine situation d'urgence liée à la charge, et qu'ils ont pu constater à quel point cet outil leur a sauvé la mise.
Mais, même avec la meilleure volonté du monde… des erreurs peuvent arriver. Voici donc quelques conseils. Sept pièges dans lesquels nous avons vu des clients tomber – accompagnés de conseils pour les éviter et garantir une mise en place plus fluide.
Tu penses être prêt… ?
Imaginons que vous vous apprêtiez à lancer un nouveau produit, un nouveau service ou une nouvelle promotion.
Vous savez que votre site risque de rencontrer des problèmes liés à la demande ou à la charge. Peut-être vous attendez-vous à une forte demande parce que vous proposez un produit extrêmement rare, ou à un problème de charge élevé parce que vous savez qu'un nombre sans précédent de visiteurs va se connecter à votre site en même temps.
Vous savez donc que vous allez avoir besoin d’une salle d’attente. En fait, vous intégrez cette salle d’attente dès le début. Elle fera partie intégrante de l’expérience utilisateur. Vous savez exactement comment elle va fonctionner et comment la file d’attente sera intégrée à la solution que vous développez. Elle aura été testée de fond en comble. Il n’y a aucune chance que cela tourne mal.
...N'est-ce pas ?
Pour plus de sécurité, passons en revue les problèmes les plus courants liés à l'intégration personnalisée de CrowdHandler et voyons comment les éviter.
1. Tests fonctionnels limités
Nous voyons souvent des clients tester leur intégration sur mesure, soigneusement élaborée, auprès d'un petit groupe de parties prenantes internes : cinq ou dix personnes qui effectuent quelques parcours utilisateur types et vérifient que les utilisateurs sont bien mis en file d'attente et redirigés vers le site.
Cependant, ce type de test ne vous donne pas une idée réaliste du fonctionnement du site lorsqu'une file d'attente est active. En effet, une fois que ces quelques utilisateurs ont franchi les étapes de la salle d'attente et ont été autorisés à accéder au site, il n'y a plus de file d'attente. Or, de nombreux problèmes d'intégration n'apparaissent généralement que lorsque la file d'attente se met en place sur un site très fréquenté.
Lors de vos tests, vous devez impérativement vérifier que les utilisateurs conservent leur statut « promu » (généralement indiqué par un cookie CrowdHandler) sur le site cible. Plutôt que de vous contenter de faire passer vos utilisateurs test de la salle d'attente vers le site, vous devriez vérifier si la session CrowdHandler est bien maintenue.
Par conséquent, vous devriez au moins :
- Réglez le taux sur 0, ce qui déclenchera la file d'attente
- Augmenter temporairement le débit pour permettre à certains utilisateurs d'accéder au service
- Rétablissez le débit à 0 (ce qui crée à nouveau une file d'attente active)
- Vérifiez ensuite que les utilisateurs qui ont été transférés sur le site peuvent toujours suivre des parcours utilisateurs fonctionnels.
Il est essentiel de ramener le débit à 0 après avoir autorisé l'accès à certains utilisateurs car, à ce stade, si la session CrowdHandler d'un utilisateur est interrompue, celui-ci sera renvoyé dans la file d'attente. En revanche, si vous maintenez un débit élevé, ces utilisateurs ne seront pas renvoyés dans la file d'attente et vous ne vous rendrez pas compte que votre intégration présente un problème.
2. L'environnement de production ne correspond pas à l'environnement de développement
Bien sûr, tout le monde aimerait pouvoir affirmer que ses environnements de préproduction et de développement reflètent fidèlement l'environnement de production… mais, d'après notre expérience, c'est rarement le cas.
L'un des problèmes les plus courants que nous avons constatés est le suivant : un client passe des jours, voire des semaines, à effectuer des tests sur son environnement de développement ou de préproduction, puis applique la même configuration au site de production une heure avant la mise en ligne, en s'attendant à ce que tout fonctionne exactement de la même manière. Lorsqu'il se rend compte que ce n'est pas le cas, il est déjà trop tard.
Cela s'explique par le fait que les éléments qui ont tendance à différer entre l'environnement de production et l'environnement de développement sont précisément ceux qui pourraient poser problème à un « waiting room ». Bon nombre des mesures de protection que les utilisateurs doivent mettre en place sur leur site de production – par exemple, le fait de placer le site derrière un CDN, d'utiliser un pare-feu ou une protection contre les bots – ne sont généralement pas nécessaires sur l'environnement de test ; par conséquent, certains aspects de votre routage réseau ou de votre configuration peuvent être différents.
Veillez donc à prêter attention aux différences concernant :
- Routage réseau (notamment dans le cadre des implémentations CDN et DNS)
- Protection contre les bots, infrastructure de pare-feu ou configurations non conformes à l'environnement de production
Pour vous assurer de ne pas rencontrer de problèmes majeurs à un stade avancé, nous vous recommandons de mettre en production au moins 24 heures avant la date prévue. Une fois les tests fonctionnels terminés dans un environnement de développement ou de préproduction, limitez-les à une partie de l’environnement de production qui ne vous posera pas de problème – un modèle d’URL spécifique et protégé qui ne risque pas de gêner les utilisateurs réels – et effectuez quelques tests à petite échelle dans l’environnement de production. Vous pourriez même effectuer un petit test en production au milieu de la nuit.
Mais… n'attends pas la dernière minute.
3. Blocage d'adresses IP
Les intégrations personnalisées transmettent l'adresse IP de l'utilisateur à l'API CrowdHandler, afin que nous puissions vérifier qu'elle ne figure pas sur une liste noire. Cependant, il n'est pas rare que certains sites soient configurés de telle manière qu'ils nous envoient par erreur l'adresse IP d'un serveur proxy au lieu de celle de l'utilisateur… ce qui déclenche à tort le blocage de l'adresse IP par CrowdHandler.
Cela ne pose généralement problème que si vous configurez vous-même votre intégration (si vous utilisez l'une de nos intégrations, nous nous sommes déjà chargés de tout cela), mais il est assez facile de se tromper, alors soyez vigilant.
En savoir plus : Dépannage des intégrations d'API personnalisées
4. Fixer un taux trop élevé
La plupart des gens pensent que leur site peut supporter un trafic bien plus important qu’il ne le peut réellement. C’est pourquoi, d’après notre expérience, les clients fixent souvent un débit entrant beaucoup trop élevé.
S'il s'agit de votre première mise en service, vous ne savez pas à quel volume de trafic vous attendre et, honnêtement, vous ne savez pas encore quel volume de trafic vous êtes capable de gérer. Ne vous laissez pas tromper par la capacité de votre site à traiter des milliers de requêtes par seconde ; cela ne correspondra pas au nombre réel de personnes que vous pourrez acheminer depuis votre file d'attente.
Les sites capables de gérer facilement plus de 60 utilisateurs par minute (c'est-à-dire une nouvelle session par seconde) sont assez rares ; vous devriez donc probablement commencer par 30 ou moins, à moins que vous ne connaissiez vraiment le profil de charge de votre site.
En bref : mieux vaut commencer par un taux bas. Ensuite, si vous êtes agréablement surpris, vous pourrez facilement augmenter ce taux. En revanche, il peut s'avérer plus compliqué de rétablir un taux trop bas.
Voir aussi : Pourquoi les tests de charge ne fonctionnent-ils pas ?
5. Exclusions d'URL
Si vous utilisez l'intégration DNS, l'intégration CDN ou votre propre intégration côté serveur avec un contrôleur frontal, celle-ci vérifiera chaque URL afin de rediriger les utilisateurs vers la file d'attente.
Cependant, certaines URL sont susceptibles d'être appelées par des applications tierces et ne doivent pas être envoyées dans une file d'attente ; il convient donc de les exclure.
Un exemple évident est celui d’une passerelle de paiement. Un utilisateur effectue une transaction via, par exemple, PayPal ou Stripe, et la passerelle de paiement renvoie un reçu de confirmation de commande en accédant à une URL sur votre serveur. Si vous n’avez pas exclu cette URL, l’intégration CrowdHandler (qui vérifie chaque URL, rappelez-vous) intervient alors et indique que la passerelle de paiement doit être mise en file d’attente. La commande ne sera jamais finalisée et l’utilisateur ne pourra pas valider son achat.
C'est là une raison supplémentaire de procéder à des tests fonctionnels complets, bien à l'avance. Définissez votre débit sur 0 afin de vous assurer que la file d'attente est active, puis testez des parcours utilisateur complets, y compris ceux impliquant des applications tierces susceptibles de dépendre de votre domaine protégé.
En savoir plus : Dépannage des intégrations d'API personnalisées
6. Simplifier à l'excès le modèle
L'une des principales raisons pour lesquelles les utilisateurs apprécient CrowdHandler réside dans ses modèles personnalisables, et nous avons pu constater que certains ont su faire preuve d'une grande créativité et réaliser des projets passionnants grâce à la liberté offerte par ces modèles.
Le modèle par défaut, ou « de départ », comprend différents messages et états correspondant à plusieurs scénarios, dont certains sont plus évidents que d’autres. Il s’agit notamment des cas suivants : la salle n’est pas encore ouverte, la salle est pleine, l’utilisateur est bloqué en raison d’un comportement suspect, ou l’utilisateur ne s’est pas encore vu attribuer de place dans la file d’attente.
Cependant, lorsque les utilisateurs personnalisent le modèle, il leur arrive souvent de ne prendre en compte que le « scénario idéal » et de négliger — voire, pire encore, de supprimer complètement — certains messages d'erreur et états moins évidents. Ainsi, lorsqu'un utilisateur se retrouve confronté à l'une de ces situations, il se retrouve face à une interface utilisateur qui ne lui est guère utile.
Il est important de comprendre que les utilisateurs ont besoin de voir des informations de retour, même si celles-ci leur indiquent quelque chose que vous ne considérez pas comme positif, comme leur position actuelle, la barre de progression ou le temps d'attente estimé. D'après notre expérience, masquer ces éléments est contre-productif. Sans eux, les utilisateurs risquent d'adopter un comportement imprévisible ou de mal réagir face au manque d'informations. Vous risquez de perdre des ventes, voire de nuire à votre réputation.
7. Définition de délais d'expiration extrêmes pour les sessions
Toutes les applications web utilisent le concept de délai d'expiration de session, et CrowdHandler ne fait pas exception.
La durée par défaut de CrowdHandler est de 15 minutes, ce qui correspond à une durée de session relativement courante pour une application web. Cela signifie simplement qu’une fois qu’un utilisateur a cliqué sur un élément, CrowdHandler considérera qu’il est toujours connecté pendant les 15 minutes suivantes.
L'utilisateur maintient sa session active en cliquant sur les pages, mais grâce à un délai d'expiration de 15 minutes, il peut s'absenter 15 minutes pour se préparer un café et revenir sans se retrouver en fin de file d'attente. Lorsqu'il effectue un nouveau clic, cela réactive la session, ce qui lui laisse encore largement le temps de naviguer.
Il faut garder à l'esprit que le nombre de sessions ne constitue qu'un indicateur très simplifié de la charge pesant sur votre application. Lorsque les utilisateurs s'absentent pour aller se faire un café, ils ne génèrent aucune charge sur votre application.
Nous constatons toutefois que certains clients règlent la durée de la session soit à une valeur bien trop faible, soit à une valeur bien trop élevée.
Dans tous les cas, c’est contre-productif. Si ce seuil est trop bas, vous risquez de renvoyer les utilisateurs dans la file d’attente en plein milieu de leur visite. S’il est trop élevé, vous pourriez vous retrouver à gérer une file d’attente très longue, car les sessions des utilisateurs restent actives longtemps après leur départ.
En savoir plus : « Un qui entre, un qui sort »
Prêt à réussir du premier coup ?
Vous prévoyez une forte affluence ou une demande importante, et vous êtes prêt à aménager une salle d'attente ?