Comment recevoir des e-mails via API : webhooks, IMAP et interrogation

Votre application a besoin de réagir quand un e-mail arrive. Peut-être qu'elle analyse les codes de vérification dans un test automatisé. Peut-être qu'elle achemine les e-mails des clients dans un système de tickets d'assistance. Peut-être qu'elle traite les données entrantes d'un partenaire qui communique par e-mail.

Quel que soit le cas d'usage, « recevoir des e-mails par programme » se réduit à trois approches : interrogation IMAP, webhooks et interrogation API. Chacun a des compromis différents en latence, complexité et exigences d'infrastructure.

Approche 1 : Interrogation IMAP

IMAP est le protocole standard pour lire les e-mails d'un serveur. Vous vous connectez au serveur IMAP, recherchez des messages et les téléchargez. Chaque client e-mail — Thunderbird, Outlook, Apple Mail — utilise IMAP sous le capot.

Pour l'accès par programme, vous faites la même chose en code : connexion, recherche, récupération, analyse.

Comment cela fonctionne

1. Ouvrir une connexion IMAP au serveur de courrier
2. Sélectionner la boîte de réception (ou un dossier spécifique)
3. Rechercher les messages correspondant à vos critères (non vu, l'objet contient X, de Y)
4. Récupérer les messages correspondants
5. Analyser le contenu (en-têtes, corps, pièces jointes)
6. Répéter à un intervalle

Exemple Python

import imaplib
import email
import time
from email.header import decode_header

def poll_inbox(host, port, user, password, interval=5):
    """Continuellement interroger les nouveaux e-mails via IMAP."""
    imap = imaplib.IMAP4_SSL(host, port)
    imap.login(user, password)

    while True:
        imap.select("INBOX")
        status, messages = imap.search(None, "UNSEEN")

        for msg_id in messages[0].split():
            status, msg_data = imap.fetch(msg_id, "(RFC822)")
            raw = msg_data[0][1]
            msg = email.message_from_bytes(raw)

            subject = decode_header(msg["Subject"])[0][0]
            if isinstance(subject, bytes):
                subject = subject.decode()

            sender = msg.get("From")
            print(f"Nouvel e-mail de {sender} : {subject}")

            # Traiter l'e-mail ici — extraire les codes, acheminer vers la logique de l'application, etc.

        time.sleep(interval)

# Se connecter à une boîte de réception gérée Reusable.Email
poll_inbox(
    host="imap.reusable.email",
    port=993,
    user="votre-boîte@reusable.email",
    password="votre-mot-de-passe",
    interval=10,
)

Avantages et inconvénients

Avantages :

• Protocole standard — fonctionne avec n'importe quel serveur de courrier, n'importe quelle langue
• Pas de point de terminaison public requise (votre code établit la connexion)
• Accès complet à tous les messages, dossiers et métadonnées
• Fonctionne avec chaque boîte de réception gérée Reusable.Email (3 $ une seule fois)

Inconvénients :

• L'interrogation ajoute de la latence (secondes à minutes selon l'intervalle)
• Les connexions persistantes nécessitent de la gestion (délais d'expiration, reconnexions)
• La mise à l'échelle vers de nombreuses boîtes de réception nécessite un regroupement de connexion

IMAP IDLE : Réduire la latence

La plupart des serveurs IMAP prennent en charge la commande IDLE, qui maintient la connexion ouverte et pousse les notifications quand un nouvel e-mail arrive. Cela réduit la latence de votre intervalle d'interrogation à quasi temps réel.

# Utilisation d'imapclient pour le support IDLE
from imapclient import IMAPClient

client = IMAPClient("imap.reusable.email", ssl=True)
client.login("votre-boîte@reusable.email", "votre-mot-de-passe")
client.select_folder("INBOX")

# Démarrer le mode IDLE — le serveur nous notifiera des nouveaux messages
client.idle()
responses = client.idle_check(timeout=300)  # Attendre jusqu'à 5 minutes
client.idle_done()

# Traiter les nouveaux messages indiqués par les réponses

Approche 2 : Webhooks

Avec les webhooks, le serveur e-mail pousse une requête HTTP vers votre point de terminaison quand un nouveau message arrive. Votre application n'interroge pas — elle écoute.

Comment cela fonctionne

1. Enregistrer une URL webhook auprès du fournisseur d'e-mail
2. Quand l'e-mail arrive, le fournisseur envoie une requête POST HTTP à votre URL
3. Le corps POST contient les données du message (expéditeur, objet, corps, pièces jointes)
4. Votre point de terminaison traite les données et retourne une réponse 200
5. Si votre point de terminaison est en panne, le fournisseur réessaye (avec backoff)

Architecture

L'e-mail arrive → Reusable.Email → POST HTTP → Votre point de terminaison → Logique d'application

C'est pilotée par événement. Pas de boucle d'interrogation, pas de connexions persistantes, pas de cycles gaspillés en vérifiant les boîtes de réception vides.

Considérations

Vous avez besoin d'un point de terminaison public. Votre URL webhook doit être accessible depuis Internet. En développement, les outils comme ngrok peuvent exposer un serveur local. En production, c'est votre infrastructure API régulière.

Gérer les nouvelles tentatives. Si votre point de terminaison retourne une réponse autre que 200, le fournisseur réessayera. Votre logique de traitement doit être idempotente — traiter deux fois le même e-mail ne devrait pas causer de problèmes.

Sécurité. Validez que les demandes webhook proviennent réellement de votre fournisseur d'e-mail. Vérifiez les signatures, vérifiez les adresses IP source ou utilisez les secrets webhook.

Quand utiliser les webhooks

Les webhooks sont la bonne approche quand :

• Vous avez besoin d'un traitement en temps réel (sans délai d'interrogation)
• Vous construisez un produit où l'e-mail est une entrée centrale (tickets d'assistance, analyse entrante)
• Vous exécutez déjà un serveur Web qui peut recevoir des requêtes HTTP
• Vous êtes sur la couche white-label de Reusable.Email, qui prend en charge les webhooks pour les événements e-mail

La couche white-label (30 $/mois) inclut le support webhook, une API REST et des boîtes de réception gérées illimitées. Pour la décomposition complète, voir Identifiants SMTP & IMAP à la demande.

Approche 3 : Interrogation API

Certains fournisseurs d'e-mail exposent une API REST pour vérifier les boîtes de réception. Au lieu de vous connecter via IMAP, vous effectuez des demandes HTTP GET à un point de terminaison API qui retourne les messages en JSON.

Comment cela fonctionne

1. Faire une requête HTTP au l'API du fournisseur (par ex., GET /inboxes/{id}/messages)
2. Analyser la réponse JSON
3. Traiter les nouveaux messages
4. Répéter à un intervalle

Avantages et inconvénients

Avantages :

• Des appels HTTP simples — aucune bibliothèque IMAP requise
• Les réponses JSON sont faciles à analyser
• Fonctionne bien avec les cadres Web modernes et les fonctions serverless

Inconvénients :

• Toujours une interrogation (mêmes compromis de latence que l'interrogation IMAP)
• API spécifique au fournisseur — enfermement du fournisseur
• Limites de débit sur les appels API
• Pas un protocole standard

Quand utiliser l'interrogation API

L'interrogation API fonctionne bien pour les intégrations légères où ajouter une bibliothèque IMAP semble lourd — fonctions serverless, scripts simples ou prototypes. Pour tout ce qui est de qualité production, IMAP ou les webhooks sont plus robustes.

Choisir la bonne approche

Facteur	Interrogation IMAP	Webhooks	Interrogation API
Latence	Secondes (configurable)	Temps réel	Secondes (configurable)
Nécessite un point de terminaison public	Non	Oui	Non
Protocole standard	Oui (IMAP)	Non (HTTP, mais universel)	Non (spécifique au fournisseur)
Fonctionne avec n'importe quel serveur de courrier	Oui	Dépend du fournisseur	Dépend du fournisseur
Complexité	Moyenne	Basse (une fois configurée)	Basse
Meilleur pour	Test, traitement par batch	Produits temps réel	Scripts simples

Comment Reusable.Email correspond

Toutes les boîtes de réception gérées (3 $ une seule fois) prennent en charge IMAP. Connectez-vous à imap.reusable.email:993 avec SSL/TLS, utilisez n'importe quelle bibliothèque IMAP et lisez les e-mails par programme. Cela fonctionne pour les tests, les pipelines CI/CD et les applications qui peuvent tolérer la latence d'interrogation.

La couche white-label (30 $/mois) ajoute des webhooks. Quand l'e-mail arrive dans n'importe quelle boîte de réception sous votre domaine, Reusable.Email envoie une requête POST HTTP à votre point de terminaison avec les données complètes du message. C'est l'approche pour les produits qui ont besoin d'un traitement d'e-mail en temps réel.

Les deux approches utilisent les mêmes boîtes de réception sous-jacentes. Vous pouvez commencer avec l'interrogation IMAP lors du développement et passer aux webhooks quand vous avez besoin d'une livraison en temps réel.

Modèles courants

Attendre un e-mail dans un test

def wait_for_email(imap, subject_match, timeout=30):
    start = time.time()
    while time.time() - start < timeout:
        imap.select("INBOX")
        _, msgs = imap.search(None, "UNSEEN")
        for mid in msgs[0].split():
            _, data = imap.fetch(mid, "(RFC822)")
            msg = email.message_from_bytes(data[0][1])
            if subject_match in msg["Subject"]:
                return msg
        time.sleep(2)
    raise TimeoutError(f"Pas d'e-mail correspondant à '{subject_match}'")

Extraire un code de vérification

import re

def extract_code(msg):
    body = msg.get_payload(decode=True).decode()
    match = re.search(r"\b(\d{4,8})\b", body)
    return match.group(1) if match else None

Acheminer l'e-mail vers la logique d'application

# Gestionnaire webhook (exemple Flask)
@app.route("/webhook/email", methods=["POST"])
def handle_email():
    data = request.json
    sender = data["from"]
    subject = data["subject"]
    body = data["text"]

    if "support" in data["to"]:
        create_support_ticket(sender, subject, body)
    elif "billing" in data["to"]:
        process_billing_email(sender, subject, body)

    return "", 200

Gestion des erreurs et fiabilité

Quelle que soit l'approche que vous choisissez, la réception des e-mails doit gérer l'échec avec élégance.

La connexion IMAP se coupe. Les interruptions réseau tueront votre connexion IMAP. Enveloppez votre boucle d'interrogation dans un gestionnaire de reconnexion qui se réauthentifie et reprend d'où il s'est arrêté. L'indicateur UNSEEN sur les messages assure que vous ne retraitez pas les e-mails que vous avez déjà gérés.

L'indisponibilité du point de terminaison webhook. Si votre point de terminaison webhook est inaccessible, le fournisseur d'e-mail réessayera avec un backoff exponentiel. Concevez votre gestionnaire pour être idempotent — traiter deux fois le même e-mail doit produire le même résultat, pas des entrées dupliquées dans votre base de données.

E-mails mal formés. Pas chaque e-mail suit parfaitement les normes RFC. Votre code d'analyse doit gérer les en-têtes manquants, l'encodage invalide et les structures MIME inattendues sans se planter. Utilisez les blocs try/except autour de l'analyse des e-mails et enregistrez les défaillances pour investigation.

Limites de débit. Les serveurs IMAP peuvent limiter le nombre de connexions simultanées ou d'opérations par minute. Pour les scénarios de volume élevé (de nombreuses boîtes de réception, interrogation fréquente), utilisez le regroupement de connexion et respectez les limites du serveur.

# Interrogation IMAP robuste avec reconnexion
def robust_poll(host, port, user, password, callback, interval=10):
    while True:
        try:
            imap = imaplib.IMAP4_SSL(host, port)
            imap.login(user, password)
            while True:
                imap.select("INBOX")
                _, msgs = imap.search(None, "UNSEEN")
                for mid in msgs[0].split():
                    try:
                        _, data = imap.fetch(mid, "(RFC822)")
                        msg = email.message_from_bytes(data[0][1])
                        callback(msg)
                    except Exception as e:
                        print(f"Erreur traitement du message {mid}: {e}")
                time.sleep(interval)
        except (imaplib.IMAP4.error, ConnectionError, OSError) as e:
            print(f"Connexion perdue: {e}. Reconnexion...")
            time.sleep(5)

Et ensuite ?

Pour un guide complet de l'e-mail en développement — test, staging, boîtes de réception par utilisateur et construction de produits e-mail — voir API e-mail pour les développeurs. Pour le cas d'usage spécifique de la construction d'environnements de test, lire Comment construire un environnement de test d'e-mail avec une API de courrier jetable.