Tester un e-mail de validation Wi-Fi,
pas seulement le code

Décomposer la réussite en trois résultats

Pour tester les e-mails d’un portail Wi-Fi public, ne vous arrêtez pas à « code reçu ». La réception de l’e-mail, l’acceptation du code ou du lien par le portail, et l’accès au réseau depuis l’appareil d’origine sont trois résultats distincts. Le premier peut être obtenu alors que les deux autres échouent à cause d’un jeton expiré, d’une session perdue ou d’une règle de la passerelle.

Définissez les critères de validation avec les équipes de développement et d’exploitation : dans quel délai l’e-mail doit apparaître, quel événement de service confirme la validation et quelle page HTTPS de test contrôlée doit s’ouvrir après l’autorisation. Ne vous fiez pas uniquement au message « réussite » du portail : il peut provenir du cache alors que la passerelle n’a pas encore accordé l’accès.

Isoler l’adresse et la session pour chaque test

Effectuez les tests dans un environnement de test ou sur un réseau pour lequel vous avez l’autorisation. Utilisez une nouvelle adresse pour chaque cas indépendant et consignez son numéro ainsi que la session de l’appareil. Réutilisez l’adresse uniquement pour les tests de continuité, comme le renvoi d’un code ou des clics répétés. N’utilisez pas les adresses e-mail, numéros de chambre, réservations ou pièces d’identité de vrais clients dans vos données de test.

Ouvrez la boîte de réception temporaire Tmpkey et vérifiez qu’elle affiche une véritable adresse et un compte à rebours, et non deux e-mails de démonstration. Gardez les identifiants de la boîte dans le même navigateur : changer de navigateur ne permet pas de retrouver automatiquement la boîte. Si la page de réception est inaccessible parce que le portail n’a pas autorisé l’accès au réseau, prévoyez d’abord une connexion mobile fonctionnelle, puis consultez Comment ouvrir une boîte de réception anonyme avant l’autorisation pour distinguer un blocage réseau d’un problème de distribution.

Commencez par une matrice, puis ajoutez des combinaisons

Établissez une référence avec un parcours normal, puis ne modifiez qu’une variable à la fois. Notez le système et sa version, le navigateur, l’état d’autorisation du réseau et le mode de validation. Après un échec, ne changez pas simultanément d’adresse, d’appareil et de navigateur : vous ne pourriez pas identifier la cause de l’écart.

À partir de cette base, ajoutez les versions d’iOS, d’Android et des systèmes de bureau utilisées par votre public cible. La navigation privée, le stockage désactivé et le changement de langue peuvent faire l’objet de tests complémentaires. Définissez la compatibilité attendue avec le produit : il n’est pas nécessaire de tester aveuglément toutes les combinaisons.

Consigner trois horodatages pour mesurer la réception

Notez T0 : clic sur « Envoyer le code » ; T1 : demande acceptée par le service du portail ; T2 : e-mail visible pour la première fois dans la boîte de réception. T1−T0 couvre le traitement côté interface et de la demande ; T2−T1 couvre la mise en file d’attente, le transport et l’affichage dans la boîte. Ne réduisez pas ces deux durées à un vague « serveur de messagerie lent ». Une réponse positive de l’API ne signifie pas que le message a été remis.

Synchronisez les fuseaux horaires et les horloges des clients et des serveurs, et associez les journaux à l’aide de préférence d’un identifiant de requête. L’interrogation périodique de la boîte peut retarder l’affichage par rapport à l’arrivée réelle : indiquez que T2 est une « heure observée dans l’interface ». Si vous y êtes autorisé, vérifiez ensuite l’heure d’arrivée dans les journaux de distribution ; ne prenez pas le champ Date de l’e-mail pour l’heure de réception.

Répétez les tests et consignez séparément la médiane, les cas les plus lents et le taux d’échec. Définissez les seuils selon les engagements du portail et la durée de validité du code, plutôt que d’imposer un délai fixe à tous les réseaux.

Vérifier le contenu, pas seulement les six chiffres

L’objet doit indiquer l’usage prévu et l’adresse de l’expéditeur doit appartenir au domaine attendu. Un nom d’affichage identique ne garantit pas la même origine. Pour évaluer SPF, DKIM et DMARC, il faut consulter les en-têtes complets de l’e-mail ou les journaux de distribution : un badge d’expéditeur ne suffit pas.

• HTML : Après désactivation des images distantes, le code, sa durée de validité et les conseils de sécurité restent lisibles. L’affichage ne déborde pas sur les écrans étroits et le contraste est suffisant en mode clair comme en mode sombre.
• Texte brut : Le code et les liens sont complets, sans balises résiduelles. Les retours à la ligne ne coupent pas le code et la copie n’ajoute aucun caractère invisible.
• Contenu cohérent : Les deux versions ont le même objectif, le même code et la même durée de validité ; la version traduite ne contient pas d’instructions dans une autre langue.

Une boîte de réception temporaire permet de vérifier l’affichage, mais ne donne pas toujours accès au MIME d’origine ni à l’affichage des deux versions du message. Pour confirmer l’envoi des deux formats, consultez vos propres journaux d’envoi, le message d’origine ou un client de test contrôlé. Ne déduisez pas de la seule apparence de la page que le texte brut est présent.

Suivre le lien de validation jusqu’à la session d’origine

Vérifiez l’adresse cible réelle, pas seulement le texte du bouton. Le lien doit utiliser le domaine HTTPS attendu ; les redirections ne doivent pas mener vers un site non autorisé et les paramètres ne doivent pas transmettre de données personnelles superflues. Testez toute la chaîne de redirection avec un compte fictif et ne conservez dans les journaux que les chemins et les statuts expurgés des données sensibles.

Valider séparément sur le même appareil et sur un autre appareil

Si la demande est lancée dans une fenêtre de connexion du système et que l’e-mail est consulté dans un navigateur complet, le lien peut ouvrir une autre session de cookies. Ouvrir sur un téléphone un lien de validation demandé sur un ordinateur pose aussi la question de l’association à un appareil. Déterminez d’abord ce que le lien valide : l’adresse, le navigateur actuel ou la session de la passerelle d’origine. Un refus sur un autre appareil peut être le comportement attendu, mais il faut expliquer comment revenir à l’appareil d’origine pour saisir le code ou en demander un nouveau.

Testez aussi les ouvertures répétées du lien. Vérifiez que la page n’autorise pas plusieurs appareils sans lien avec la demande et qu’un jeton déjà utilisé renvoie un état compréhensible. Ne désactivez pas l’association à l’appareil et n’assouplissez pas la validation des redirections pour faire réussir le test.

En cas de renvoi, testez aussi en inversant l’ordre

Effectuez deux demandes successives et distinguez-les par leurs identifiants : A et B. Essayez ensuite l’ancien et le nouveau code. L’ordre d’apparition dans la boîte ne permet pas de déterminer lequel est le plus récent : un retard dans la file d’attente peut faire arriver A après B. Si seul le dernier code est valide, l’interface, le service de validation et le contenu de l’e-mail doivent l’indiquer de façon cohérente. Toute autre règle doit également être clairement annoncée.

En environnement contrôlé, testez les demandes répétées, le dépassement de la fréquence autorisée et le retour à la normale après la fin du délai d’attente. La limitation de débit doit être appliquée côté serveur, pas seulement par la désactivation du bouton. Après un délai d’attente réseau, ne déclarez pas immédiatement que la demande n’a pas été envoyée : le serveur peut l’avoir acceptée. Consignez les résultats réels et évitez les tentatives excessives, susceptibles de déclencher les protections anti-abus du réseau.

Tester séparément l’expiration de l’e-mail et celle du jeton du portail

Par défaut, une adresse e-mail temporaire Tmpkey reste valable 3 heures ; le portail détermine séparément la durée de validité de ses codes et liens de validation. Votre boîte peut encore être valable deux heures alors qu’un jeton envoyé quelques minutes plus tôt a déjà expiré. Prolonger la boîte ne renouvelle pas le jeton du portail.

Prévoyez au moins deux cas distincts : l’e-mail est encore valide, mais le jeton a expiré — la validation doit être refusée et une nouvelle demande doit être possible ; l’e-mail a expiré, mais le jeton du portail est encore dans sa période de validité déclarée — vérifiez le comportement propre au portail, sans supposer que l’expiration de l’adresse révoque automatiquement un jeton déjà émis. Testez également les limites de l’expiration, la réutilisation d’un jeton et la vérification de l’heure côté serveur.

Les paramètres de test qui raccourcissent le TTL sont réservés aux environnements isolés ; consignez les écarts par rapport à la production. Observez séparément le moment où l’adresse temporaire est réellement détruite et ne simulez pas l’expiration du serveur en modifiant l’horloge du téléphone.

Le renouvellement conserve l’adresse ; le changement d’adresse ferme l’ancienne boîte

Chaque renouvellement ajoute 3 heures. Une adresse reste active au maximum 24 heures à partir de sa création ; l’heure d’expiration renvoyée par le service fait foi. Lors du test, vérifiez que l’adresse reste identique, que les anciens messages sont conservés et que le compte à rebours est actualisé. À l’approche de la limite, ne vous attendez pas à obtenir 3 heures supplémentaires complètes.

Changer d’adresse crée une nouvelle boîte valable 3 heures par défaut et détruit l’ancienne. Terminez le cas de test en cours et enregistrez les preuves nécessaires après les avoir expurgées, puis changez d’adresse. Ne le faites pas en attendant un e-mail avant de conclure que l’absence de message sur l’ancienne adresse est un problème de distribution. La nouvelle adresse ne remplace pas automatiquement celle que le portail avait enregistrée auparavant.

Des preuves reproductibles, inutilisables pour se connecter

Pour chaque entrée, consignez le numéro du cas, l’environnement et la version de build, les versions de l’appareil et du navigateur, l’état du réseau, le mode de validation, l’adresse expurgée, l’identifiant de requête, les trois horodatages ainsi que les résultats attendus et observés. Cochez séparément « réception », « validation » et « accès au réseau » au lieu d’indiquer simplement « réussi » ou « échoué ».

Pour associer plusieurs tests à une même adresse, utilisez un code propre au cas ou un hachage contrôlé ; ne conservez pas les identifiants complets. La destruction de la boîte de test ne supprime ni les captures jointes au ticket, ni les fichiers téléchargés, ni les copies dans des systèmes externes : effacez-les séparément.

Une boîte temporaire ne mesure pas la délivrabilité globale

Une réussite ponctuelle ne décrit que le résultat obtenu à un moment donné, par un parcours donné et pour un domaine de réception donné. Elle ne renseigne pas sur le classement en spam, les règles de réputation ou l’affichage dans Gmail, Outlook et les messageries d’entreprise. Avant le lancement, testez avec des adresses réelles dont l’utilisation est autorisée, vérifiez le comportement chez chaque fournisseur et mettez en place un suivi en production de la distribution, des rebonds et des validations abouties.

Si le portail refuse explicitement les adresses jetables, consignez cette règle d’acceptation sans chercher à la contourner. N’utilisez pas une adresse qui sera détruite pour la vérification d’identité, les notifications de paiement, les changements de réservation, la récupération de compte ou les échanges à long terme avec le service client. Une adresse anonyme ne masque pas l’origine réseau et ne remplace pas un audit de sécurité.

Pour la prochaine série de tests : recevez d’abord, décidez ensuite si vous devez conserver l’adresse

Pour un test ponctuel, utilisez une adresse dédiée et parcourez toute la chaîne. Pour des tests de régression sur plusieurs jours, envisagez un alias de transfert longue durée si vous avez besoin d’une adresse stable : les messages sont transférés vers votre propre boîte et la configuration est gérée séparément de l’archivage des 30 derniers jours. Le transfert ajoute une étape au parcours ; ne mélangez pas directement ses délais avec ceux de la boîte temporaire.

Pour les étapes à suivre sur le portail, consultez Guide d’utilisation des e-mails sur les réseaux Wi-Fi des hôtels, aéroports et cafés ; pour connaître les données traitées, consultez la Politique de confidentialité.