L'email est la seule intégration dont chaque organisation dispose déjà. Les fournisseurs y envoient leurs factures, les formulaires y transmettent leurs réponses et les machines y expédient leurs alertes. L'ingestion d'emails transforme cette contrainte en interface plutôt qu'en tâche manuelle : un script se connecte à une boîte, lit ce qui est arrivé et déclenche une action.
C'est un modèle ancien et sous-estimé, car l'autre solution, demander à chaque partenaire d'adopter votre API, est rarement envisageable. Cet article explique dans quels cas il est utile, comment le rendre fiable et quand un webhook représente réellement un meilleur choix.
À quoi sert l'ingestion d'emails par IMAP
L'ingestion d'emails est utile chaque fois que l'expéditeur ne souhaite pas ou ne peut pas s'intégrer directement à votre système.
Documents envoyés par des partenaires. Factures, bons de commande, bordereaux de livraison et relevés arrivent en pièces jointes depuis des organisations qui ne développeront jamais d'intégration avec votre système. Souvent, toute l'intégration se résume à un script qui les classe par expéditeur et par référence.
Alertes provenant d'équipements. De nombreux appareils ne savent envoyer que des emails, notamment les systèmes de sauvegarde, les outils de supervision et les anciennes machines industrielles. L'ingestion par IMAP leur fournit un point de collecte unique.
Réponses de formulaires et messages reçus. Cela comprend tout système qui vous envoie un message structuré par email, y compris les avis de non-remise et les réponses automatiques d'absence sur lesquels vous souhaitez agir.
Validations par réponse. Une personne qui répond « oui » à un message vient d'accomplir une étape d'un processus. Lire automatiquement cette réponse est souvent plus simple que de créer une interface à laquelle personne ne souhaite se connecter.
Mettre en place un système qui reste fiable
Le fonctionnement de l'ingestion d'emails n'a rien d'extraordinaire. Sa fiabilité dépend de quelques décisions essentielles.
Attribuez-lui sa propre boîte. N'utilisez ni un dossier dans la boîte de quelqu'un ni un espace partagé avec une personne qui lit les mêmes messages. Une adresse dédiée empêche qu'un utilisateur faisant du rangement invalide les hypothèses du script. Ici, elle ne coûte rien puisque les boîtes ne sont pas facturées par utilisateur.
Utilisez des identifiants limités à cette tâche. Ne réutilisez pas le compte d'une personne. Si les identifiants du script sont divulgués ou doivent être renouvelés, seul le script doit être concerné.
Déplacez les messages traités au lieu de les supprimer. Un dossier « traités » fournit une piste d'audit et permet de relancer le traitement après la correction d'un défaut. La suppression rend chaque erreur définitive, et des erreurs finiront par se produire.
Prévoyez qu'un même message puisse arriver deux fois. Les nouvelles tentatives, les reconnexions et les retraitements sont inévitables. Utiliser le Message-ID comme clé et ignorer tout message déjà vu transforme un doublon potentiellement dangereux pour les données en une opération sans effet.
Rendez les défaillances visibles. Un script qui cesse de consulter une boîte passe inaperçu jusqu'à ce que quelqu'un demande où sont parties les factures. Il doit émettre une alerte lorsqu'il ne s'est pas exécuté, pas uniquement lorsqu'il rencontre une erreur.
Pourquoi IMAP convient à cet usage
L'ingestion d'emails fonctionne par IMAP, car IMAP constitue un véritable système de fichiers distant pour la messagerie plutôt qu'un simple protocole de téléchargement.
Vous pouvez effectuer une recherche sur le serveur, récupérer uniquement les en-têtes avant de décider s'il faut télécharger le corps, déplacer les messages entre les dossiers et définir des indicateurs, le tout sans télécharger la boîte entière. Le script peut ainsi rester sélectif et peu coûteux, ce qui compte lorsque la boîte contient plusieurs années d'historique.
IMAP bénéficie aussi d'une prise en charge universelle, et c'est son principal avantage. Chaque langage possède une bibliothèque, le protocole n'a pas évolué d'une manière qui casse les implémentations et un script écrit aujourd'hui fonctionnera encore dans dix ans. Peu d'API propriétaires offrent une garantie aussi solide.
À savoir : l'offre gratuite comprend IMAP. Une boîte d'ingestion destinée uniquement à la réception ne coûte donc rien. Elle ne peut toutefois pas envoyer de messages. Tout processus qui répond automatiquement nécessite un forfait payant ou son propre profil SMTP.
Le coût de fonctionnement
Le coût est souvent la bonne surprise, car il est inférieur à ce que la plupart des gens imaginent.
Une boîte d'ingestion est une boîte mail ordinaire, et le nombre de boîtes est plafonné selon le forfait au lieu d'être facturé individuellement. Le coût marginal d'une douzième adresse d'ingestion est donc nul. C'est ce qui rend une boîte par source raisonnable plutôt qu'excessive. Vos véritables dépenses sont l'espace pris dans le stockage partagé et le temps consacré à résoudre les problèmes.
Cette différence modifie les choix d'architecture par rapport aux plateformes qui facturent par utilisateur. Sur ces services, l'ingestion est souvent concentrée dans une seule adresse surchargée parce que chaque adresse supplémentaire coûte de l'argent. Le script doit ensuite séparer plusieurs flux sans aucun rapport entre eux. Ici, la solution la moins chère est aussi la plus propre.
Quand préférer un webhook
Être clair sur ce point évite de construire le mauvais système.
Si votre partenaire propose un webhook, utilisez-le. L'envoi à l'initiative de la source surpasse l'interrogation périodique en matière de latence, de fiabilité et de clarté : vous recevez des données structurées dès qu'un événement survient, au lieu de le découvrir lors de la vérification suivante et d'avoir à analyser du texte. L'ingestion d'emails est la solution de repli lorsqu'aucune option de ce type n'existe.
L'interrogation périodique a elle aussi une fréquence minimale raisonnable. Une vérification par minute convient ; une vérification par seconde est abusive et finira par être limitée. Si votre besoin est véritablement en temps réel, l'email n'est pas le bon moyen de transport, quelle que soit la façon dont vous le lisez.
Enfin, analyser des emails rédigés par des personnes est un combat perdu d'avance. Extraire un numéro de bon de commande d'un message généré par une machine est fiable. Déduire une intention d'un paragraphe écrit par une personne ne l'est pas. Tout processus qui en dépend produira un flux continu d'échecs que personne ne pourra éliminer.
Dépasser une seule boîte mail
L'ingestion d'emails s'adapte bien à la montée en charge. Son architecture dépend du nombre de flux à traiter.
Pour quelques sources, une boîte par source constitue la solution la plus claire. Chaque script lit sa propre adresse et une modification apportée à l'un ne peut pas affecter les autres. Comme le nombre de boîtes est plafonné par forfait au lieu d'être facturé individuellement, vingt adresses d'ingestion coûtent autant qu'une seule.
Pour de nombreuses sources du même type, une boîte unique précédée d'un catch-all fonctionne mieux : invoice-acme@ et invoice-globex@ arrivent au même endroit, tandis que l'adresse elle-même contient les informations de routage dont le script a besoin. C'est la même technique que celle d'un alias par inscription, appliquée aux machines plutôt qu'aux fournisseurs.
Lorsque le volume devient réellement important, n'oubliez pas que l'espace de stockage est partagé. Une boîte d'ingestion qui accumule des pièces jointes finira par le consommer. Un quota et une politique de conservation doivent donc faire partie de la conception dès le départ, et non être découverts plus tard. Ce point est expliqué dans notre guide sur les quotas de stockage des boîtes mail.
