Comment nous construisons des listes d’attente bêta sécurisées sur Cloudflare
Une liste d’attente bêta n’est un actif commercial que si les adresses sont réelles.
La plupart des équipes commencent avec un champ d’adresse e-mail et un bouton d’envoi. C’est suffisant pour tester une landing page. Ce n’est pas suffisant lorsque la liste commence à orienter les plans de lancement, les vagues d’invitations, les mises à jour destinées aux investisseurs ou les décisions produit. Si n’importe qui peut envoyer l’adresse de quelqu’un d’autre, ou si un bot peut remplir la base de données en une nuit, l’équipe obtient une demande bruyante au lieu d’un signal exploitable.
Voici la méthode que j’utilise pour créer une liste d’attente bêta prête pour la production sur Cloudflare : double opt-in, contrôles anti-bot côté serveur, liens de vérification à durée de vie courte, tokens hachés, envoi SMTP via l’hébergement e-mail existant, paramètres administrateur séparant par défaut les lignes vérifiées des lignes historiques, et étape de validation qui ne prétend pas qu’une infrastructure configurée est déjà en production.
Une implémentation récente de liste d’attente bêta a confirmé cette méthode dans le cadre d’une mise en production réelle, sans nécessiter de système complet de comptes. L’élément important est la structure du travail : une petite interface d’inscription avec des limites strictes autour du consentement, des abus, de la délivrabilité, de la qualité des données et du déploiement.
Le problème commercial résolu par une liste d’attente sécurisée
Une liste d’attente a deux fonctions.
Elle doit recueillir la demande et aider l’équipe à agir sur cette demande. C’est sur ce deuxième point que les formulaires faibles échouent.
Si vous ne pouvez pas faire confiance à la liste, chaque suivi devient plus lent. Vous vous demandez combien de lignes proviennent de bots. Vous hésitez avant d’envoyer des e-mails d’invitation. Vous exportez les données, les nettoyez manuellement et ne savez toujours pas si la personne contrôle l’adresse. La liste devient une métrique de vanité approximative au lieu d’un outil de lancement.
Une liste d’attente bêta sécurisée vous fournit des données d’entrée plus propres :
L’objectif n’est pas de rendre un formulaire simple compliqué. L’objectif est de faire en sorte que le formulaire signifie réellement ce que l’entreprise pense qu’il signifie.
L’architecture Cloudflare
La stack principale est volontairement réduite.
Cloudflare Workers gère la requête. Cloudflare Turnstile vérifie si l’inscription semble humaine. D1 stocke les lignes de la liste d’attente et les enregistrements de vérification en attente. L’hébergement SMTP/e-mail existant envoie l’e-mail de confirmation via TLS. Une tâche de nettoyage Worker planifiée supprime les enregistrements en attente expirés.
Cette stack suffit à de nombreuses équipes en phase de démarrage. Vous n’avez pas besoin d’ajouter un système complet de comptes utilisateurs simplement pour recueillir une liste bêta responsable.
Le flux se présente ainsi :
Les équipes produit disposent ainsi d’une séparation claire : un intérêt en attente n’est pas la même chose qu’une demande vérifiée.
Le double opt-in est une décision produit
Le double opt-in est souvent présenté comme une question d’hygiène des e-mails. Je le considère comme une question d’hygiène produit.
Si une liste bêta doit déterminer qui obtient l’accès en premier, l’équipe doit savoir que chaque adresse appartient à quelqu’un qui l’a confirmée. Une fenêtre de confirmation de 24 heures suffit pour une inscription normale et est suffisamment courte pour éviter que des lignes en attente obsolètes ne restent indéfiniment.
Le lien de confirmation ne doit pas modifier l’état à lui seul. Les scanners de liens, les aperçus d’e-mails et les requêtes GET accidentelles existent. Le modèle le plus sûr consiste à laisser le lien afficher une page de confirmation, puis à demander à l’utilisateur d’appuyer sur un bouton qui envoie un POST same-origin.
Ce clic supplémentaire est minime. La limite qu’il crée est utile.
Cela simplifie également le support. Si quelqu’un affirme ne jamais s’être inscrit, vous pouvez montrer un flux qui exigeait l’accès à la boîte de réception et une action de confirmation explicite avant que l’adresse n’entre dans la liste vérifiée.
Protection contre les bots sans formulaire hostile
Une bonne liste d’attente ne doit pas donner l’impression de passer un examen de sécurité.
La protection doit se trouver principalement derrière le formulaire. Dans cette implémentation, le Worker valide côté serveur un widget Cloudflare Turnstile géré. La validation vérifie le token, l’action attendue et le hostname attendu. Un widget navigateur sans validation côté serveur n’est qu’un élément décoratif ; le Worker doit effectuer la vérification.
Turnstile n’est qu’une couche. Le formulaire utilise également un champ honeypot pour détecter simplement les bots, un corps de requête limité afin que les charges trop volumineuses ne consomment pas inutilement le temps du Worker, une limitation de débit par IP utilisant une clé et une limitation des tentatives par adresse utilisant une clé.
La limite par adresse est importante, car la vérification d’un e-mail peut devenir un vecteur de nuisance. Vous ne voulez pas que quelqu’un déclenche à répétition des e-mails de confirmation vers la même boîte de réception.
La réponse publique reste générique. Elle ne doit pas révéler si une adresse existe déjà, est en attente de vérification, est supprimée ou a atteint une limite. Cela évite de transformer l’endpoint d’inscription en outil d’énumération d’adresses e-mail.
Stockage des tokens : hachez ce que vous envoyez
Les liens de vérification sont sensibles, car ils prouvent l’accès à la boîte de réception.
L’implémentation envoie un token aléatoire dans le lien de l’e-mail, mais D1 ne stocke qu’un hash utilisant une clé de ce token. Lors de la confirmation, le Worker hache le token envoyé et le compare au hash stocké. Le token brut ne se trouve pas dans la base de données.
Cette conception garde le système simple tout en réduisant l’impact potentiel. Si une table de vérifications en attente fuit, l’attaquant n’obtient pas de liens de confirmation immédiatement utilisables.
Le token est à usage unique. Après une confirmation réussie, le Worker supprime l’enregistrement en attente. Les lignes en attente expirées sont nettoyées de manière opportuniste lors des opérations normales sur la liste d’attente et via un Cloudflare Cron quotidien planifié.
Ce mécanisme de nettoyage permet de garder une table réduite sans tâches manuelles de base de données.
Envoi d’e-mails via l’hébergement e-mail existant
De nombreuses équipes disposent déjà d’un hébergement e-mail. Elles n’ont pas toujours besoin d’un nouveau fournisseur d’e-mails transactionnels pour une liste d’attente bêta.
Dans l’implémentation que j’ai vérifiée, une adresse d’expédition dédiée a été créée sur l’hébergement e-mail existant, et le Worker envoie les messages via SMTP sur TLS. L’e-mail est simple : confirmez votre inscription à la bêta, le lien est valable 24 heures, ignorez ce message si vous n’en êtes pas à l’origine.
C’est suffisant pour cette tâche.
La valeur ne vient pas d’un design d’e-mail sophistiqué. Elle vient d’un expéditeur connu, d’un objectif précis et d’un chemin d’envoi qui peut être testé avant le lancement. Pour une startup, cela vaut souvent mieux que d’ajouter un fournisseur supplémentaire avant même que le produit n’ait des utilisateurs.
Les vues administrateur doivent protéger l’équipe contre les mauvaises hypothèses
La sécurité ne concerne pas uniquement l’endpoint public.
La vue administrateur doit refléter le contrat de données. Les adresses vérifiées doivent s’afficher par défaut. Les anciennes lignes non vérifiées ou historiques peuvent rester disponibles, mais elles doivent nécessiter un filtre explicite. L’export CSV doit suivre la même règle.
Cela évite une erreur fréquente au lancement : exporter toutes les lignes historiques et les considérer comme une demande confirmée.
Dans une implémentation récente, la liste de production contenait déjà des adresses historiques avant l’adoption du nouveau modèle de vérification. Le plan de migration conserve ces adresses comme entrées historiques. Il ne marque pas silencieusement les anciennes lignes comme vérifiées simplement parce que le nouveau système dispose désormais d’un état vérifié.
C’est la différence entre migrer et réécrire l’historique.
Configuré ne signifie pas en production
Cette limite fait partie du service que je fournirais à une autre équipe.
Une boîte e-mail peut exister. Un widget Turnstile peut exister. Les noms des secrets Worker peuvent être configurés. Les tests peuvent réussir. Rien de tout cela ne signifie que le site public utilise déjà la nouvelle liste d’attente.
Pour l’implémentation de référence actuelle, le flux de double opt-in est implémenté et vérifié localement. La migration D1 en attente, la nouvelle version du Worker et le Cron de nettoyage planifié nécessitent encore une approbation de mise en production et un déploiement. Le site public utilise toujours l’ancien formulaire de liste d’attente jusqu’à cette étape.
Cette distinction protège l’entreprise. Une migration D1 modifie la structure des données de production. Un déploiement Worker modifie le comportement des inscriptions. Un Cron ajoute une mutation en arrière-plan. Chaque étape nécessite une fenêtre de mise en production explicite, une vérification et une réflexion sur le retour arrière.
Une liste d’attente sécurisée ne doit pas être mise en ligne à la légère simplement parce qu’elle porte le mot « sécurisée ».
À quoi ressemble la vérification
Pour une livraison de liste d’attente prête pour la production, je veux des preuves avant le lancement.
L’implémentation de référence a réussi 150 tests. Astro check a signalé 0 erreur. Le build de production a réussi. Le travail concernait uniquement le web ; les modifications existantes de l’application native ont donc été laissées intactes.
La checklist de mise en production reste importante après cela :
C’est la différence entre « le code compile » et « le tunnel d’inscription est prêt à recevoir du trafic ».
Quand cette approche est utile aux startups
Ce modèle est utile lorsqu’une équipe est proche de la bêta, mais pas encore prête à mettre en place des comptes complets.
Vous lancez peut-être une application mobile, un outil SaaS, une alpha privée, une fonctionnalité AI protégée ou une liste de réservation de matériel. Vous devez recueillir la demande, mais aussi disposer de données propres et du consentement avant de commencer à envoyer des invitations.
Une liste d’attente Cloudflare sécurisée vous offre cela sans ajouter un backend volumineux :
La solution est suffisamment réduite pour être déployée rapidement et suffisamment stricte pour être fiable.
Besoin de cela pour votre produit ?
Je peux vous aider à concevoir, sécuriser ou implémenter ce type de flux d’inscription pour une équipe produit.
Le travail utile ne consiste pas à ajouter un CAPTCHA sur un formulaire. Il consiste à décider ce que signifie une inscription, comment le consentement est prouvé, où les tokens sont stockés, comment les e-mails sont envoyés, ce que les administrateurs voient par défaut et comment la mise en production est vérifiée avant l’arrivée du trafic public.
Si votre liste bêta est sur le point de devenir un élément de votre plan de lancement, il vaut la peine de la rendre fiable avant de l’utiliser pour prendre des décisions.