Revue de page d’inscription par IA : vérifiez tout le parcours, jusqu’à l’e-mail

Un agent IA peut vérifier plus que le formulaire. Avec une boîte de réception de test, il peut suivre l’inscription jusqu’à l’e-mail de vérification et vérifier les bugs qui n’apparaissent qu’à ce moment-là.

Mis à jour le 5 novembre 2026

Notre recommandation, d’emblée. Nous éditons Proxy Mail QA, nous ne sommes donc pas neutres. Dans cet article, nous le recommandons pour la partie d’une revue d’inscription qui se passe après l’appui sur le bouton : l’e-mail de vérification arrive-t-il, son code ou lien termine-t-il l’inscription, l’e-mail est-il envoyé et construit correctement, et en arrive-t-il exactement un. Proxy Mail QA ne juge ni l’apparence de votre page ni son taux de conversion, il ne peut pas recevoir de codes SMS, et il ne teste pas la connexion via réseaux sociaux comme Sign in with Google.

Demandez à un agent IA de vérifier une page d’inscription et il regardera en général le formulaire : les libellés, les champs, le bouton. C’est la partie qui casse rarement. Les bugs qui atteignent les utilisateurs se trouvent dans la suite :

Le lien de vérification pointe vers localhost : il fonctionne sur votre machine et nulle part ailleurs.
Rien n’arrive, car le fournisseur d’e-mail est encore en mode sandbox.
Deux e-mails arrivent, car le formulaire est envoyé deux fois ou deux parties du code en envoient chacune un.
L’e-mail indique que le lien est valable 24 heures, et le serveur l’expire au bout d’une.
Le lien fonctionne encore après avoir été utilisé, ou après l’envoi d’un plus récent.

Aucun de ces bugs n’apparaît tant qu’un vrai e-mail n’arrive pas dans une vraie boîte de réception. Cet article montre comment laisser un agent les vérifier à chaque revue.

Ce que vérifie l’agent

Étape	Comment	À quoi ressemble un échec
L’e-mail arrive	`wait_for_code` ou `wait_for_link` attend jusqu’à 30 secondes, en ignorant tout ce qui est antérieur à l’inscription (`since`)	Rien n’arrive. `check_delivery` indique ce qui a atteint l’adresse et la cause probable, comme un fournisseur en mode sandbox ou un courrier refusé pour échec DMARC
Le code ou le lien termine l’inscription	L’agent tape le code ou ouvre le lien dans son propre navigateur, puis vérifie qu’il est connecté	Une page d’erreur, un lien expiré ou une inscription qui n’aboutit pas
L’e-mail est envoyé correctement	`check_email` : SPF, DKIM et DMARC, liens vers localhost ou en http simple, destination du lien (`expect_host`), expiration indiquée, partie en texte brut, taille, phrases données et langue	`local_links` en échec, ou le lien mène à la production depuis le staging
Exactement un e-mail arrive	`count_emails` avec `since`	Un compte de 2
Les liens utilisés et remplacés cessent de fonctionner	Le prompt ou le skill `auth_regression_pack` rouvre un lien utilisé, et un lien plus ancien après un plus récent	L’ancien lien connecte encore quelqu’un

Proxy Mail QA n’ouvre jamais les liens lui-même : un lien à usage unique est donc encore inutilisé quand l’agent le reçoit. L’agent ne voit que le code ou le lien et quelques informations à son sujet, jamais le texte de l’e-mail.

Le connecter dans Qoder

Dans le Marketplace Qoder, connectez Proxy Mail QA depuis l’onglet Connectors (site international, site Chine), ou installez le plugin pour les mêmes outils plus huit skills.
Connectez-vous à Proxy Mail QA dans votre navigateur quand Qoder le demande, et choisissez le projet que l’agent peut utiliser.
Réglez le niveau d’autorisation de Qoder sur Ask every time, et non Auto approve, et approuvez chaque étape Proxy Mail QA.

Pour l’ajouter plutôt à la main, ouvrez Qoder IDE Settings → MCP, choisissez + Add dans l’onglet My Servers, et ajoutez :

{
  "mcpServers": {
    "proxymail-qa": {
      "type": "http",
      "url": "https://api.proxymail.qa/mcp"
    }
  }
}

Demander la revue

Review the sign-up at https://staging.acme.dev/signup with Proxy Mail QA. Start a run.
Sign up with a new address (use form_values for the fields), note the time just before
you submit, and finish the verification with the code or link from the email.
Check you're signed in. Run check_email with expect_host: staging.acme.dev, and
count_emails since the sign-up: exactly one email should have come.
Then request a second verification email, and check the first link no longer works.
Finish the run and give me the report, with what to fix first.

Le prompt test_signup_flow du serveur exécute de la même façon les étapes d’inscription, check_email et count_emails (pas le second e-mail de vérification), dans les clients qui affichent les prompts MCP. Avec le plugin installé, le skill proxymail-qa couvre une inscription unique, auth-regression-pack répète l’inscription, la réinitialisation du mot de passe et les invitations de la même façon à chaque fois, et account-email-audit déclenche chaque e-mail de compte envoyé par votre app et liste ce qu’il faut corriger.

Le rapport

finish_run renvoie la session en Markdown : chaque étape, ce qui a réussi et échoué, avec une raison d’une ligne pour chaque vérification. Collez-le dans la pull request. Quand vous relancez auth_regression_pack plus tard, son rapport indique ce qui a changé depuis les dernières exécutions : une modification qui a cassé l’e-mail de réinitialisation apparaît comme un changement, pas comme une longue liste à lire.

Constats fréquents, et quoi changer

Constat	Cause habituelle	Correction
Le lien mène à `localhost`	Le lien est construit à partir d’une URL codée en dur	Construisez-le à partir d’une variable d’environnement contenant l’URL publique de l’app. Corrections pour Supabase, Firebase, Auth.js et d’autres
Rien n’arrive	Le fournisseur d’e-mail n’envoie qu’aux adresses vérifiées	Terminez la configuration production du fournisseur, ou vérifiez le domaine d’envoi
Deux e-mails	Le formulaire est envoyé deux fois, ou votre code et votre service d’authentification en envoient chacun un	Désactivez le bouton pendant la requête ; envoyez depuis un seul endroit
L’expiration indiquée est fausse	Le modèle et le serveur ont des réglages différents	Tirez les deux d’un même réglage
Un ancien lien fonctionne encore	Les jetons ne sont pas effacés lorsqu’ils sont utilisés ou remplacés	Rendez chaque lien à usage unique, et invalidez les plus anciens quand un nouveau est envoyé

Pour éviter qu’elles ne reviennent, donnez une règle à l’agent, dans les règles de votre projet ou au début d’une tâche d’authentification :

When changing sign-up, login, password reset, invites or any email-sending code:
- Build links from the app's public URL setting, never a hard-coded localhost.
- Keep the expiry stated in an email equal to the one the server enforces.
- Make single-use links and codes stop working once used or replaced.
- Tell me which emails to test by hand after the change.

Ce qu’il ne fait pas

Examiner la page elle-même. La mise en page, la formulation, l’accessibilité et la vitesse demandent d’autres outils, ou une personne. Voir Comment examiner ma page d’inscription.
SMS, applications d’authentification et connexion via les réseaux sociaux. Proxy Mail QA reçoit uniquement des e-mails.
Créer des comptes ou envoyer des formulaires. C’est l’agent qui le fait, avec ses propres outils de navigateur.
Fonctionner avec un fournisseur d’e-mail en mode sandbox. Il peut seulement vous montrer que rien n’est arrivé, et pourquoi.
Tester les sites en production de grands services grand public, comme Google, Instagram ou Amazon. Il sert aux applications que vous développez ou que vous êtes autorisé à tester, en préproduction ou en local.

Plus de détails : tester la vérification d’e-mail, le MCP server et Proxy Mail QA pour Qoder.

Essayez-le lors de votre prochain test d’inscription

Offre gratuite, sans carte bancaire. Créez une adresse et regardez arriver le code ou le lien.

Créer un compte gratuitOuvrir l'application