Créer une adresse email par programmation semble simple jusqu’à ce que vous essayiez d’automatiser la boucle complète : générer une adresse, déclencher un email (OTP, lien magique, invitation), puis lire cet email de manière fiable dans le code sans parsing fragile ou collisions de boîtes de réception.
Pour les agents IA et l’automatisation QA, « créer une adresse email » est en réalité un raccourci pour quelque chose de plus spécifique :
- Provisionner une boîte de réception routable à la demande (pas une boîte aux lettres humaine).
- Recevoir les messages de manière déterministe (webhook ou polling, pas « sleep 10 secondes »).
- Consommer le contenu comme données structurées (JSON) pour que les outils et agents puissent agir en toute sécurité.
Ce guide explique les principales approches, quand chacune fonctionne, et un modèle d’implémentation pratique que vous pouvez intégrer dans les chaînes d’outils d’agents et les harnais de test.
Ce que signifie « créer une adresse email par programmation »
Dans l’email grand public, une « adresse email » implique généralement un compte à long terme avec des identifiants, un accès interface, des options de récupération et une identité continue. En automatisation, ce modèle est souvent la mauvaise abstraction.
Ce que vous voulez généralement, c’est un handle de boîte de réception que vous pouvez créer et détruire, plus une adresse qui y achemine les messages. Cette boîte de réception devient un conteneur délimité pour les messages dans une seule exécution, test ou session d’agent.
Pourquoi cette distinction est importante :
- Isolation : une boîte de réception par exécution évite les collisions.
- Contrôle du cycle de vie : vous pouvez expirer et supprimer les boîtes de réception.
- Privilège minimal : l’automatisation ne lit que ce dont elle a besoin, pendant peu de temps.
Si vous concevez l’API ou l’interface interne pour votre harnais de test, modélisez d’abord une ressource boîte de réception, puis attachez-lui une adresse.
Choisir la bonne méthode selon votre objectif
Il existe plusieurs façons de générer ou simuler des adresses email. La meilleure option dépend de si vous devez réellement recevoir du courrier, et si le système testé doit livrer via une infrastructure email réelle.
Comparaison rapide
| Méthode | Peut recevoir de vrais emails ? | Bon pour CI et agents ? | Mode d’échec typique | Meilleur cas d’usage |
|---|---|---|---|---|
| Domaines réservés (example.com) | Non | Oui | Aucune boîte de réception n’existe | Tests unitaires, flux de validation uniquement |
| Plus-addressing (nom+tag@) | Oui (si le fournisseur le supporte) | Parfois | Collisions, bizarreries du fournisseur | Marquage léger dans une vraie boîte de réception |
| Alias fournisseur (Workspace, etc.) | Oui | Parfois | Surcharge de configuration, limites | Petites équipes, identité de staging stable |
| Domaine catch-all | Oui | Risqué | Mauvais routage, boîte de réception bruyante | Environnements contrôlés avec routage strict |
| Capture SMTP locale | Non (pas de livraison réelle) | Oui | Pas représentatif de la prod | Tests de dev et d’intégration locale |
| API de boîte de réception temporaire | Oui | Oui | Dépendance vendeur | Tests E2E déterministes, flux d’agents |
Si votre flux de travail doit valider « l’email a été livré » puis extraire un OTP/lien, les boîtes de réception temporaires (créées via API) sont souvent le choix le plus adapté à l’automatisation.
Un flux de travail pratique et reproductible (fonctionne pour tests et agents IA)
Indépendamment du backend, l’automatisation email robuste suit les mêmes cinq étapes :
1) Provisionner une boîte de réception (et obtenir une adresse)
Vous voulez une fonction qui retourne :
-
address(l’adresse email que vous pouvez taper dans un formulaire) -
inbox_id(le handle que vous utilisez pour interroger ou corréler les messages) - metadata comme l’expiration, si supportée
Traitez l’inbox_id comme la clé primaire dans votre système.
2) Déclencher l’email
C’est votre comportement d’application normal : inscription, connexion sans mot de passe, invitation, vérification email, etc.
Pour la fiabilité, ajoutez une corrélation quand vous le pouvez. Deux stratégies courantes :
- Mettre un
run_iddans l’identifiant utilisateur (par exemple, la partie locale de l’email). - Ajouter un ID de corrélation niveau application dans le contenu de l’email ou les en-têtes (si vous contrôlez l’envoi).
3) Attendre de manière déterministe (webhook d’abord, polling en fallback)
Évitez les sleep fixes. Une attente déterministe ressemble à :
- Démarrer un timer avec un timeout dur.
- Préférer la livraison webhook quand disponible.
- Revenir au polling avec backoff.
Cela garde les tests rapides quand l’email arrive vite et toujours stable quand la livraison est lente.
4) Parser comme des données, extraire seulement ce dont vous avez besoin
Votre automatisation a généralement besoin d’un artefact :
- un code OTP
- une URL de lien magique
- un token d’invitation
Extrayez-le d’une représentation stable. Si vous alimentez le contenu dans un agent LLM, fournissez une enveloppe JSON minimale (expéditeur, sujet, corps de texte, liens/codes extraits) plutôt que du HTML brut.
5) Nettoyer
Une rétention courte réduit le risque et le coût :
- expirer les boîtes de réception agressivement
- éviter de logger les corps de message complets
- garder l’email brut seulement lors du debugging
Pièges courants (et comment les éviter)
Piège : « J’ai créé une adresse, mais ne peux pas lire l’email correct de manière fiable »
Cela arrive avec les boîtes de réception partagées et les modèles de plus-addressing. Plusieurs exécutions écrivent dans la même boîte aux lettres, puis votre code doit « chercher » ou « filtrer » dans un tas éventuellement cohérent.
Solution : créer une boîte de réception par exécution (ou par test) et interroger seulement cette boîte de réception.
Piège : Le scraping HTML casse votre automatisation
Le HTML d’email varie selon les templates, clients, et même les tests A/B. Le parser avec des regex est fragile.
Solution : préférer text/plain ou une sortie JSON normalisée. Si vous devez parser du HTML, assainissez et gardez la logique d’extraction conservative.
Piège : les webhooks deviennent un trou de sécurité
L’email entrant est une entrée non fiable, et les endpoints webhook sont souvent publics.
Solution :
- vérifier les payloads signés quand disponibles
- imposer des tolérances de timestamp pour réduire le risque de replay
- valider que les URLs extraites correspondent à une allowlist de vos domaines
Modèle d’implémentation : une interface « EmailAddressFactory »
Si vous supportez plusieurs environnements (dev local, CI, staging), définissez une petite interface et échangez les implémentations.
Un contrat minimal :
createInbox(): { inbox_id, address }waitForMessage(inbox_id, matcher, timeout_ms): messageextractVerificationArtifact(message): { otp?, url? }
Cette interface garde vos outils d’agent et tests stables même si vous changez de fournisseurs.
Utiliser une API de boîte de réception temporaire (Mailhook) pour l’email programmatique
Mailhook est conçu autour de boîtes de réception temporaires programmables qui livrent les emails reçus sous forme JSON structuré, avec notifications webhook et API de polling.
Pour éviter de dériver du contrat produit réel, utilisez la référence d’intégration canonique de Mailhook ici : llms.txt.
Flux de haut niveau
- Créer une boîte de réception temporaire via API.
- Utiliser l’adresse retournée dans votre flux d’application.
- Recevoir l’email sous forme JSON via webhook (recommandé) ou poll.
- Extraire votre artefact (OTP ou lien).
Exemple de pseudocode (compatible agent)
Les endpoints exacts et le schéma sont définis dans llms.txt. Le modèle ci-dessous se concentre sur le flux de contrôle.
// Pseudocode (style Node)
async function createEmailAddressForRun(runId) {
// Appeler Mailhook pour créer une boîte de réception temporaire
// Retourne { inbox_id, address, ... }
const inbox = await mailhook.createInbox({
metadata: { run_id: runId },
// optionnellement configurer la cible webhook selon votre architecture
});
return { inbox_id: inbox.inbox_id, address: inbox.address };
}
async function waitForVerificationEmail(inbox_id, timeoutMs) {
// Webhook d'abord : dans beaucoup de configurations vous pousseriez les événements webhook vers une queue,
// puis votre agent/test attend sur cette queue.
// Fallback polling : interroger les messages de la boîte de réception jusqu'à ce que le matcher touche ou timeout.
const deadline = Date.now() + timeoutMs;
while (Date.now() < deadline) {
const messages = await mailhook.listMessages({ inbox_id });
const match = messages.find(m =>
(m.subject || "").toLowerCase().includes("verify")
);
if (match) return match;
await sleep(500); // petit backoff ; augmenter graduellement dans le vrai code
}
throw new Error("Timeout en attendant l'email de vérification");
}
function extractArtifact(message) {
// Préférer un champ normalisé ou une représentation text/plain quand fournie.
// Garder l'extraction minimale et déterministe.
return {
otp: maybeExtractOtp(message),
url: maybeExtractFirstAllowedUrl(message, ["https://yourapp.example"])
};
}
Vérification webhook (ne pas ignorer ceci)
Mailhook supporte les payloads signés pour la sécurité. Faites de la vérification de signature une valeur par défaut dans votre gestionnaire webhook, et échouez fermé si la vérification échoue.
Comme les formats de signature diffèrent par fournisseur et peuvent changer, référez-vous à llms.txt pour les en-têtes exacts et étapes de vérification.
Domaines partagés vs domaines personnalisés
Quand vous créez une adresse email par programmation, vous avez aussi besoin d’une stratégie de domaine :
- Les domaines partagés sont rapides à démarrer et excellents pour les flux éphémères.
- Les domaines personnalisés aident avec un contrôle plus serré et l’alignement de marque, et peuvent être utiles quand vous avez besoin de réputations d’envoi cohérentes ou d’un routage plus strict.
Mailhook supporte à la fois les domaines partagés et le support de domaine personnalisé, ce qui vous permet de choisir la bonne posture par environnement.
Traitement par batch : quand une boîte de réception ne suffit pas
Les systèmes d’agents et pipelines CI fonctionnent souvent en parallèle. Dans ces cas, vous voulez provisionner beaucoup de boîtes de réception à la fois et traiter les messages par batches.
Mailhook supporte le traitement email par batch, ce qui est utile quand :
- vous lancez beaucoup d’inscriptions simultanément
- vous exécutez de grandes matrices de tests
- vous devez drainer les messages efficacement pour un ensemble de boîtes de réception
(Encore une fois, voir llms.txt pour le contrat API précis.)
Checklist de fiabilité pour l’automatisation « créer adresse email »
Utilisez ceci comme un pré-vol final avant de blâmer votre fournisseur ou vos templates d’email :
- Utiliser une boîte de réception par exécution (ou par test) pour éviter les collisions.
- Préférer webhook d’abord, garder polling en fallback pour la résilience.
- Utiliser des timeouts explicites et les logger comme événements structurés.
- Assert sur l’intention (expéditeur/sujet/artefact attendu), pas le HTML complet.
- Traiter l’email comme entrée non fiable, surtout avec les agents LLM.
- Vérifier les webhooks signés quand disponibles.
- Minimiser la rétention et masquer les champs sensibles dans les logs.
Si vous voulez des plongées plus profondes sur des sujets de fiabilité connexes, ces posts Mailhook sont de bons compagnons :
- Create email on demand for end-to-end test suites
- Email inbox design: webhooks, polling, and storage
- Open an email programmatically: from raw to JSON
Questions fréquemment posées
Puis-je créer une vraie adresse Gmail par programmation ? Créer automatiquement des comptes Gmail grand public n’est pas une approche fiable ou recommandée pour l’automatisation. Pour les tests et agents, il est mieux de provisionner des boîtes de réception temporaires ou d’utiliser des domaines contrôlés et APIs de boîte de réception.
Quelle est la différence entre le plus-addressing et créer une nouvelle boîte de réception ? Le plus-addressing crée beaucoup de variantes d’adresse qui routent typiquement vers la même boîte aux lettres, ce qui peut causer des collisions dans les exécutions parallèles. Une nouvelle boîte de réception temporaire fournit l’isolation et un matching plus simple.
Dois-je utiliser des webhooks ou du polling pour recevoir les emails ? Les webhooks sont généralement plus rapides et efficaces parce que la livraison est dirigée par événements. Le polling reste utile comme fallback quand les webhooks sont indisponibles ou temporairement en échec.
Comment rendre les tests basés sur l’email non-flaky ? Utilisez une boîte de réception par exécution de test, évitez les sleep fixes, définissez des timeouts durs, et parsez les messages comme données structurées (ou text/plain) plutôt que de scraper du HTML.
Est-ce sûr de laisser un agent LLM lire les emails entrants ? Cela peut l’être, si vous traitez l’email comme entrée non fiable, passez une enveloppe JSON minimale au modèle, assainissez le contenu, et validez toute URL ou code extrait avant d’agir.
Essayez Mailhook pour des boîtes de réception temporaires programmables
Si votre objectif est de créer une adresse email par programmation pour des agents IA, l’automatisation QA, ou des flux de vérification, Mailhook fournit la création de boîtes de réception temporaires via API, sortie email JSON structurée, webhooks temps réel (avec payloads signés), et une API de polling.
