Si vous gérez un site qui vend des billets, propose des produits en édition limitée ou gère tout type de vente très prisée, vous savez déjà ce qui se passe lorsque trop de personnes se connectent en même temps.
Le site plante, les vrais clients tombent sur des pages d'erreur, et les robots raflent discrètement tout ce qui est en promotion.
Une salle d'attente virtuelle est la solution standard : lorsque la demande augmente brusquement, CrowdHandler place les visiteurs dans une file d'attente ordonnée et les fait passer à un rythme que votre infrastructure est réellement capable de gérer, ce qui permet au site de rester accessible et à chacun d'avoir une chance équitable d'y accéder.
Cela fonctionne très bien lorsque la « salle d'attente » se trouve à l'entrée de l'ensemble de votre site. Le problème, c'est que les applications modernes sont de moins en moins conçues de cette manière, et que beaucoup d'entre elles sont protégées par un système qui semble solide, mais qui ne l'est pas.
La baguette qui ne jamais
Vous connaissez bien la fouille de sécurité. Le videur vous palpe, vous échangez un signe de tête, puis vous passez. En réalité, rien n'a été vérifié. C'est ainsi que fonctionnent la plupart des applications web : beaucoup de gesticulations, mais aucun contact réel.
Pourquoi tout le monde construit-il comme ça ?
Ainsi, la pile moderne se divise clairement en deux.
- Il y a une interface utilisateur, généralement statique ou générée côté serveur.
- Il existe une API qui fonctionne en parallèle, souvent sur son propre domaine et parfois dans un cloud totalement distinct.
C'est désormais la norme. Next.js, Nuxt, Remix, SvelteKit et Astro l'encouragent tous. Les plateformes de commerce « headless » vous le fournissent déjà séparé : d'un côté, une vitrine hébergée ; de l'autre, une API publique ; l'intégration étant laissée à la charge de l'utilisateur.
Hébergez le front-end sur Vercel, Netlify ou Cloudflare Pages, et vous obtiendrez le modèle adopté par la quasi-totalité des plateformes de commerce électronique et de billetterie en 2026 : un front-end rapide, essentiellement statique, et une API qui effectue tout le travail en arrière-plan.
Idéal pour l'expérience développeur. Idéal pour la vitesse de chargement des pages. C'est toutefois là que le modèle de sécurité présente des failles.
Pourquoi le front-end n'est qu'une
Le front-end est d'une légèreté incroyable. Il se compose de balises, de scripts et d'un peu de mise en forme, et on pourrait lui envoyer la moitié du trafic Internet sans qu'il ne bronche, car il n'y a pratiquement rien qui puisse le surcharger.
Toutes les opérations coûteuses, fragiles et critiques se trouvent dans l'API. Ainsi, si votre page d'accueil s'appuie sur le site statique tandis que votre API répond aux appels inter-domaines depuis sa propre adresse, vous avez protégé la partie qui n'allait jamais tomber en panne et laissé complètement exposée celle qui, elle, risque de tomber en panne.
Les clients passent par l'entrée surveillée. Les ennuis, eux, s'introduisent par une porte latérale que personne ne surveille.
On tombe sans cesse sur ce genre de situation : des SPA et des applications de type SPA conçues exactement de cette manière. Beaucoup de gens préféreraient sincèrement ne pas en savoir plus, et tant que tout fonctionne encore, il est logique de ne pas remuer la boue.
Les équipes qui préfèrent y voir clair souhaitent manifestement une zone d'attente s'étendant sur les deux mi-temps, et non un bouclier ne protégeant que celle qui est inoffensive.
Nous disposons de deux méthodes qui ont fait leurs preuves pour y parvenir.
Stratégie n° 1 : utiliser votre principal comme proxy pour l'API#
La meilleure solution, si vous en avez la possibilité, est de ne plus considérer du tout l'API comme une adresse distincte. Redirigez ses appels vers votre domaine principal et installez un pare-feu devant l'ensemble, qu'il s'agisse de CrowdHandler, de Cloudflare ou de tout autre service déjà en place.
Si vous procédez ainsi, le front-end léger se fera enfin le porte-parole de l’ensemble du système. Une tentative de DDoS se voit attribuer une position dans la file d’attente. Un appel API qui s’écarte du scénario normal se voit attribuer une position dans la file d’attente. L’attaquant fait la queue derrière vos véritables clients, comme n’importe qui d’autre. Si votre architecture vous offre cette flexibilité, optez d’abord pour cette solution.
Stratégie n° 2 : placer les travailleurs en périphérie devant les terminaux critiques
Quand ça ne plie pas, il faut passer aux grands moyens. Les ouvriers spécialisés dans les bords ont placé des renforts devant l’API, aux un ou deux endroits qui supportent le poids.
Dans une boutique en ligne, c'est presque toujours l'appel à « ajouter au panier » qui prime, et il convient d'expliquer pourquoi. Il est impossible de passer à la caisse sans cette étape ; c'est donc le point de contrôle évident. Cependant, cela comporte également un risque en soi, car une personne qui se contente d'ajouter des articles au panier peut tout de même gâcher l'expérience des acheteurs sérieux sans jamais acheter le moindre article.
C'est la technique classique des « ticket-bots » : remplir les paniers pour empêcher les vrais acheteurs d'y accéder, puis revendre cet accès, ou bien les mettre en vente, les racheter, et ainsi de suite, encore et encore.
Pour ce faire, l'utilisateur effectue une requête auprès de l'API CrowdHandler et comptabilise les visites associées à l'identifiant du produit, en les traitant comme si elles provenaient de la page qui déclenche normalement l'appel, c'est-à-dire généralement la page de détails du produit. Vous n'êtes pas légitimement dans la file d'attente pour cette page ? Dans ce cas, l'appel à l'API n'est pas effectué pour vous.
Le fait d'installer le module de traitement à cet endroit précis présente un avantage discret. Il est situé directement au niveau du véritable goulot d'étranglement, à savoir l'API plutôt que le site statique, ce qui signifie que notre système d'ajustement automatique peut analyser la charge réelle et autoriser le passage des utilisateurs à un rythme qui reflète la réalité.
Si vous ne vous concentrez que sur le site hôte, vous vous retrouvez face à un composant qui ne fait pratiquement jamais d’effort, ce qui revient à effectuer un réglage les yeux bandés. De plus, comme ce site hôte n’effectue que très peu d’opérations, sa partie de l’intégration reste minime : une touche de JavaScript pour écarter les utilisateurs à la demande, tandis que l’ensemble de la validation et de la gestion du rythme s’effectue au niveau de l’API.
Le piège ne fonctionne que si toutes les pièces
Il y a une règle à ne surtout pas négliger, et c'est justement celle que beaucoup oublient : fermez la session dès qu'un utilisateur quitte le site.
Une fois qu'un visiteur a payé, cette session doit prendre fin ; elle ne peut donc pas être réutilisée pour un deuxième tour. Si vous la laissez active, un bot performant se mettra en file d'attente une seule fois, puis effectuera la transaction en boucle indéfiniment. En appliquant cette règle, vous supprimez cette possibilité, forçant ainsi l'attaquant à se comporter à chaque fois comme un acheteur lambda suivant le parcours normal : en passant par la file d'attente, la page produit et l'appel validé.
Le piège ne capture quoi que ce soit que si toutes ses pièces tiennent bien en place. Il suffit d'un seul élément mal fixé pour que l'ensemble se referme sur du vide.
Vous n'avez pas besoin de réécrire votre
Pour être clair sur la portée de ce projet, il ne s'agit pas d'une refonte. Il s'agit principalement de charger et d'ajuster des « edge workers » que nous développons et maintenons déjà, avec des versions prêtes pour :
- AWS CloudFront
- Cloudflare
- Netlify
- Akamai
Vous protégez un ou deux terminaux, sans toucher à votre code principal. Nous avons mis en œuvre cette solution en toute discrétion pour de nombreux clients utilisant une grande variété de piles technologiques, et c'est ce même mécanisme qui fonctionne en arrière-plan de notre intégration Shopify.
Quand ça mérite qu'on en
Si une petite voix au fond de vous ne cesse de vous murmurer que votre infrastructure est un peu plus vulnérable que vous ne l’admettriez à voix haute, n’hésitez pas à nous en parler. Même si une file d’attente traditionnelle vous semble excessive, c’est ainsi que vous bénéficierez d’une limitation de débit fluide et d’une protection contre les attaques DDoS intégrées aux parties de votre application qui cèdent réellement, et non à celles qui ne bronchent même pas.
Vous avez besoin d'un peu plus de sécurité ? Inscrivez-vous gratuitement à CrowdHandler.