FlowKit

Déclencher un workflow à la réception d'un email : le node Email Trigger (IMAP) de n8n

Publié le 3 août 2026 · 10 min de lecture

Le webhook déclenche un workflow quand une application vous appelle ; le Schedule Trigger quand l'horloge le décide. Mais une énorme partie des événements qui méritent une automatisation arrivent par un canal bien plus ancien : l'email. Une demande de support, une facture fournisseur en pièce jointe, une candidature, une commande confirmée par un tiers qui n'a pas d'API — tout cela atterrit dans une boîte mail, et y reste tant qu'un humain ne l'ouvre pas. Le node Email Trigger (IMAP) de n8n transforme cette boîte en point d'entrée de workflow : chaque nouveau message devient un item, avec son expéditeur, son sujet, son corps et ses pièces jointes, prêt à être classé, extrait, transféré ou traité.

Le phénomène qu'on cherche à endiguer porte un nom depuis trente ans : la « surcharge email », décrite par Steve Whittaker et Candace Sidner dans leur étude fondatrice Email overload: exploring personal information management of email (CHI 1996, ACM — voir sur Google Scholar). Leur constat tient toujours : la boîte de réception sert à la fois de file de tâches, d'archive et de canal de communication, trois fonctions qu'aucun tri manuel ne concilie durablement. C'est exactement l'argument pour déplacer le tri au moment de la réception, automatiquement — ce que ce guide met en place.

Pourquoi IMAP : le trigger email universel

n8n propose plusieurs façons de réagir à un email : le trigger du node Gmail, celui d'Outlook, et le node Email Trigger (IMAP). Les deux premiers sont liés à un fournisseur et à son API propriétaire, avec l'authentification OAuth qui va avec. Le troisième parle IMAP, le protocole standard que pratiquement toutes les boîtes mail du monde exposent : une adresse chez OVH ou Infomaniak, une boîte Outlook ou Gmail, un serveur mail auto-hébergé, la messagerie fournie avec votre hébergement web.

C'est ce qui en fait le trigger de choix pour les adresses fonctionnelles d'une PME — contact@, support@, factures@ — qui vivent rarement chez un seul grand fournisseur. Pas d'application à déclarer dans une console développeur, pas de consentement OAuth à renouveler, pas de quota d'API propriétaire : un hôte, un port, un identifiant, un mot de passe, et le workflow démarre à chaque nouveau message.

Deux exceptions raisonnables à cette préférence : si votre messagerie est entièrement chez Google, le node Gmail avec son propre trigger est souvent plus simple à configurer et plus riche en opérations (labels, threads) — notre guide de connexion Gmail couvre ce chemin. Même logique côté Microsoft 365, détaillée dans notre guide Outlook / Microsoft 365. IMAP reste le dénominateur commun quand la boîte est ailleurs, ou quand vous voulez un montage qui survive à un changement de fournisseur.

Créer le credential IMAP

Le credential demande quatre informations, toutes fournies par votre hébergeur mail :

  • Hôte : le serveur IMAP du fournisseur — ssl0.ovh.net chez OVH, mail.infomaniak.com chez Infomaniak, outlook.office365.com pour Outlook, imap.gmail.com pour Gmail. En cas de doute, la page d'aide « configurer un client mail » de votre fournisseur les donne.
  • Port : 993, le port IMAP standard en SSL/TLS, avec l'option de connexion sécurisée activée. C'est le réglage à utiliser partout aujourd'hui.
  • Utilisateur : l'adresse email complète, dans la quasi-totalité des cas.
  • Mot de passe : celui de la boîte — avec une nuance importante pour les grands fournisseurs.

Le cas Gmail. Google n'accepte plus les mots de passe de compte classiques sur IMAP. Il faut d'une part vérifier qu'IMAP est activé dans les paramètres Gmail, d'autre part créer un mot de passe d'application — ce qui suppose la validation en deux étapes active sur le compte. C'est ce mot de passe d'application, pas celui du compte, qui va dans le credential. Si cette gymnastique vous semble lourde, c'est le signe qu'il faut plutôt utiliser le node Gmail natif : son trigger dédié passe par OAuth et évite toute cette configuration.

Une fois le credential enregistré, le bouton de test du node vous dit immédiatement si la connexion passe. Une erreur d'authentification sur une boîte OVH ou Infomaniak vient presque toujours d'un mot de passe dédié à la messagerie, différent de celui du compte client.

Les paramètres du node Email Trigger (IMAP)

Le node est court, mais chacun de ses réglages a des conséquences concrètes :

  • Mailbox : le dossier surveillé, INBOX par défaut. Vous pouvez pointer n'importe quel dossier IMAP — et c'est même la bonne pratique, on y revient plus bas : un dossier dédié (n8n, a-traiter) alimenté par une règle de tri côté serveur, plutôt que la boîte de réception entière.
  • Action après lecture : ce que le node fait d'un message une fois récupéré, typiquement le marquer comme lu. C'est le comportement clé de tout le montage : un message marqué comme lu ne matche plus la règle de récupération et ne sera donc pas retraité au prochain passage. Ne désactivez ce marquage que si vous savez exactement pourquoi.
  • Téléchargement des pièces jointes : activé, le node attache chaque fichier du message en données binaires à l'item de sortie — indispensable pour traiter des factures PDF ou des documents reçus par email.
  • Format de sortie : Simple livre les champs prêts à l'emploi (expéditeur, sujet, corps texte et HTML) ; Raw fournit le message brut au format source, utile pour des besoins d'analyse fine (en-têtes complets, par exemple) au prix d'un parsing à votre charge.
  • Custom email rules : les options avancées permettent de personnaliser la règle de recherche IMAP, ["UNSEEN"] étant la logique par défaut — ne prendre que les messages non lus. On peut la restreindre (par expéditeur, par sujet) en syntaxe de recherche IMAP, mais le filtrage est généralement mieux placé dans une règle de tri côté serveur.

Comment le node fonctionne réellement

Contrairement à un webhook qui attend passivement, le node maintient une connexion à la boîte IMAP et vérifie l'arrivée de nouveaux messages correspondant à sa règle. Dès qu'un message matche — non lu dans la mailbox surveillée, avec la règle UNSEEN par défaut — le workflow s'exécute avec ce message en entrée, puis le node applique son action après lecture (le marquage comme lu).

Ce fonctionnement a une conséquence heureuse : les emails arrivés pendant une interruption de l'instance (redémarrage, mise à jour, panne) ne sont pas perdus. Au redémarrage, ils sont toujours non lus dans la boîte, donc toujours éligibles à la règle UNSEEN : le trigger les récupère et les traite. La file d'attente, c'est la boîte mail elle-même.

Mais la même mécanique crée le piège le plus sournois de ce node : tout ce qui marque un message comme lu le rend invisible pour le trigger. Ouvrez la boîte dans un client mail sur votre téléphone, ou laissez un collègue « jeter un œil » à la boîte support — et les messages consultés disparaissent du champ du trigger sans erreur, sans trace, sans exécution. C'est la première chose à vérifier quand « certains emails ne déclenchent pas le workflow » : qui d'autre lit cette boîte ?

Exploiter la sortie : classer, extraire, décider

Chaque email traité devient un item avec l'expéditeur, le sujet, le corps en texte et en HTML, et les pièces jointes en binaire si le téléchargement est activé. Tout l'intérêt du tri automatique se joue dans les nodes suivants :

  • Classifier le type de demande : un node Text Classifier route chaque message vers la bonne branche — question commerciale, demande de support, facture, spam — à partir du sujet et du corps. Notre guide du Text Classifier détaille la définition des catégories et les seuils de confiance.
  • Extraire les données des factures reçues en pièce jointe : le binaire du PDF part vers une chaîne d'extraction structurée (montant, fournisseur, échéance), comme dans notre guide extraire les données de factures PDF avec l'IA.
  • Détecter le phishing avant qu'un humain ne clique : expéditeur, liens et formulations passent au crible d'une analyse dédiée — le montage complet est dans notre guide détecter phishing et spam avec l'IA.
  • Préparer une réponse en brouillon : pour les demandes classées comme simples, un node LLM rédige une proposition de réponse qu'un humain valide avant envoi.

Exemple : trier automatiquement la boîte support@

Le montage représentatif, décrit de bout en bout :

  1. Email Trigger (IMAP) surveille le dossier n8n de la boîte support@, alimenté par une règle serveur (voir section suivante). Format Simple, marquage comme lu, pièces jointes activées.
  2. Text Classifier répartit chaque message en quatre catégories : urgent, question-produit, facturation, autre. Le prompt de catégorie décrit chaque cas en une phrase avec deux exemples.
  3. Branche urgent : un node Slack poste le message dans le canal d'astreinte avec l'expéditeur et le sujet, mention du responsable incluse.
  4. Branches question-produit et facturation : un node HTTP Request crée un ticket dans l'outil de support avec la bonne catégorie pré-remplie, et le corps de l'email en description.
  5. Branche autre : le message part dans un dossier de revue hebdomadaire, sans notification.

Ce workflow existe en version téléchargeable : tri d'emails par IA via IMAP, prompts de classification et branches déjà câblés — il ne reste que le credential IMAP et le canal Slack à renseigner.

Le pattern robuste : adresse dédiée, dossier dédié

Tous les pièges vus plus haut (messages lus par un humain, double traitement, INBOX partagée) ont la même solution structurelle :

  • Une adresse dédiée au flux à automatiser (factures@, support@) plutôt qu'une boîte personnelle où se mélangent messages à traiter et conversations humaines.
  • Une règle de tri côté serveur (un « sieve » ou une règle de filtrage chez OVH, Infomaniak, Gmail ou Outlook) qui déplace les messages à traiter dans un dossier n8n dès leur arrivée — par expéditeur, par sujet, ou tout ce qui matche le flux.
  • Le trigger pointé sur ce dossier, et personne d'autre ne le consulte. Les humains gardent l'INBOX ; n8n a son dossier ; le marquage comme lu ne peut plus entrer en collision avec un client mail.

Bénéfice secondaire : la règle serveur fait office de premier filtre gratuit. Les newsletters et notifications automatiques n'atteignent jamais le dossier n8n, donc ne consomment ni exécution ni appel de modèle IA.

Pièges fréquents

  • Ouvrir la boîte surveillée dans un client mail (téléphone, webmail) qui marque les messages comme lus : ils deviennent invisibles pour le trigger, sans erreur ni log. Le symptôme classique du « workflow qui rate des emails ».
  • Surveiller INBOX sur une boîte partagée au lieu d'un dossier dédié alimenté par une règle serveur : collisions garanties entre le tri humain et le tri automatique.
  • Désactiver le marquage comme lu sans autre mécanisme de déduplication : les mêmes messages restent éligibles à la règle UNSEEN et peuvent être retraités.
  • Utiliser le mot de passe du compte Google au lieu d'un mot de passe d'application sur Gmail : la connexion IMAP sera refusée. Et si vous êtes entièrement chez Google, le node Gmail est de toute façon le chemin le plus simple.
  • Oublier d'activer le téléchargement des pièces jointes puis chercher le PDF de facture dans le JSON : les fichiers n'existent en binaire que si l'option est activée.
  • Brancher deux workflows sur la même mailbox avec la même règle : le premier qui marque le message comme lu le vole à l'autre. Deux dossiers distincts, alimentés par deux règles serveur, règlent le problème proprement.
  • Choisir le format Raw sans en avoir besoin : le message brut exige un parsing manuel que le format Simple rend inutile la plupart du temps.

En résumé

Le node Email Trigger (IMAP) est le déclencheur universel des boîtes mail : quatre champs de credential (hôte, port 993, utilisateur, mot de passe), un dossier à surveiller, et chaque email devient un item exploitable avec son sujet, son corps et ses pièces jointes. Sa mécanique tient en une règle — récupérer les messages non lus, les marquer comme lus après traitement — dont découlent à la fois sa robustesse (les emails arrivés pendant une panne sont rattrapés) et son unique vrai piège (toute lecture externe fait disparaître des messages). Le pattern adresse dédiée + règle serveur + dossier n8n neutralise ce piège une fois pour toutes. Pour passer du déclencheur au système complet — classification des demandes, priorisation, extraction des pièces jointes et réponses en brouillon — le Pack Inbox IA (79 €) fournit l'ensemble des workflows de tri et de priorisation de boîte mail, prêts à importer, dont la version aboutie de l'exemple support@ décrit dans ce guide.

FAQ

Questions fréquentes

Le node Email Trigger (IMAP) de n8n fonctionne-t-il avec n'importe quelle boîte mail ?

Oui, c'est précisément son intérêt : IMAP est un protocole standard supporté par pratiquement tous les fournisseurs — OVH, Infomaniak, Outlook, Gmail, un serveur mail auto-hébergé. Il suffit de l'hôte IMAP du fournisseur, du port 993 (SSL/TLS), d'un identifiant et d'un mot de passe. Seule nuance : pour Gmail, il faut activer IMAP dans les réglages et créer un mot de passe d'application (avec la validation en deux étapes active), et le node Gmail dédié avec son propre trigger est souvent plus simple à mettre en place.

Que deviennent les emails arrivés pendant que mon instance n8n était arrêtée ?

Avec la règle par défaut basée sur UNSEEN, le trigger récupère au redémarrage les messages encore non lus dans la boîte, y compris ceux arrivés pendant l'interruption. La condition indispensable : que rien d'autre ne les ait marqués comme lus entre-temps. Un client mail ouvert sur la même boîte (téléphone, webmail) qui marque les messages comme lus les rend invisibles pour le trigger — d'où la recommandation d'une adresse ou d'un dossier dédié que seul n8n consulte.

Comment éviter que le même email soit traité deux fois par n8n ?

Laissez le node marquer les messages comme lus après traitement (le comportement clé du paramètre d'action après lecture) et assurez-vous qu'aucun autre processus ne lit la même mailbox avec la même règle. Si deux workflows doivent réagir à la même boîte, faites-les lire deux dossiers distincts alimentés par des règles de tri côté serveur, plutôt que deux triggers sur INBOX qui se disputeraient les mêmes messages.

Bundle FlowKit Complet

269 €