Meilleurs clients mail pour développeurs 2026 : TUI, script…

Le cycle 2025-2026 s’est discrètement transformé en une bonne année pour le mail en terminal. aerc a capitalisé sur son passage à FOSDEM 2025 avec une base Go 1.23 ; Himalaya a atteint la v1.2.0 en février 2026 ; NeoMutt poursuit sa cadence mensuelle avec une sortie le 2026-05-04 ; et Thunderbird Monthly Release 145 a ajouté le support natif d’Exchange Web Services, comblant la dernière lacune pour les développeurs coincés en Microsoft 365. Résultat : en 2026, un développeur peut avoir un vrai client mail clavier, plain-text d’abord, scriptable, sur Linux, Mac ou Windows, sans payer un centime. Voici les sept que nous ferions vraiment tourner, avec les compromis explicités.

Comment nous avons sélectionné

Nous avons testé chaque client face à un workflow taillé pour développeur : un compte IMAP avec quelques milliers de threads archivés, un compte JMAP sur Fastmail, un Maildir pour le mail personnel et une boîte Microsoft 365 pour le client final. Critères durs : raccourcis vim ou style vim, vue source brute (headers, parties MIME) consultable, rendu code/patch, accès au niveau protocole (IMAP/JMAP/Maildir sans passer par le webmail) et scriptabilité — ex-command, API plugin ou CLI pipeable.

Nous avons écarté tout client dont l’architecture force le mail à transiter par des serveurs propriétaires (Hey, Superhuman). Nous avons écarté les clients grand public soignés qui refusent d’exposer la source d’un message ou l’arbre MIME des pièces jointes (la plupart des apps iOS-first).

Les critères de verdict qui comptent pour nous :

Raccourcis clavier. Style vim/Emacs, ou rebindable vers ça. Pas de repli souris acceptable pour le triage.
Plain text d’abord. HTML rendu à la demande, pas par défaut ; bascule en vue source en une touche.
Natif au protocole. IMAP, JMAP, Maildir, SMTP — pas une abstraction propriétaire.
Scriptable. Lire/envoyer/chercher depuis un script ou un pipeline shell ; pas de workflows uniquement pilotés par l’UI.
Compatible git et patch. Rendu de diff inline, pièces jointes pipables vers git am, ou les deux.
Licence honnête. Open source de préférence, commercial accepté si la licence n’est pas hostile à l’utilisateur.

1. aerc — TUI conçu pour le hacker exigeant

Idéal pour : Les développeurs qui vivent dans tmux et veulent un mail conscient de git.

aerc est un client mail en terminal écrit en Go (92,5 % du code) sous licence MIT. Il propose des raccourcis vim, un système ex-command, un terminal embarqué pour composer des mails à côté d’autres threads ou de dépôts git, le rendu inline des diffs et patchs, et il supporte les backends IMAP, JMAP, Maildir, Notmuch et Mbox. Le projet se décrit comme « parfait pour le hacker exigeant » — et après test, cette présentation tient. (Source : aerc-mail.org, consulté le 2026-05-27.)

Les fonctions qui changent la donne pour un workflow développeur sont concrètes :

Compose en terminal embarqué. Ouvrez un nouvel onglet avec un shell et un dépôt git à portée pendant que vous rédigez une réponse. Pas de danse alt-tab.
Gestion des patchs. Support de première classe pour git send-email et git am. Mise en évidence inline des diffs sans configuration.
HTML à la demande. Le rendu HTML est opt-in via des filtres (w3m ou le navigateur terminal intégré). Le défaut est plain text ou plain text formaté — exactement ce qu’il faut pour des threads chargés en code.
ex-commands. Tout ce que vous faites en interactif, vous pouvez le scripter — :filter, :pipe, :read s’intègrent aux outils shell.

Le compromis à accepter d’emblée : aerc passe par une mailing list pour les contributions (le miroir GitHub est en lecture seule), la configuration est en TOML chargé, et il n’y a pas de repli GUI. Si vous faites du pair-programming sur le triage mail, votre binôme doit aussi être un utilisateur du terminal.

Idéal pour : Power users Linux/macOS qui font du mail à côté de git, veulent que les workflows de patchs paraissent natifs et acceptent l’engagement TUI.

À éviter si : Vous avez besoin d’un GUI pour trier les newsletters HTML, ou vous partagez un setup avec des coéquipiers non-terminal.

2. NeoMutt — le classique terminal, modernisé

Idéal pour : Vétérans de Mutt qui veulent des patchs modernes et maintenus sans abandonner la mémoire musculaire.

NeoMutt est un fork de Mutt qui rassemble « beaucoup de vieux patchs Mutt » mis à jour et documentés — le patch Sidebar étant l’exemple canonique, repris ensuite par le Mutt upstream. Le projet sort à cadence mensuelle ; la sortie la plus récente est datée du 2026-05-04. (Source : neomutt.org, consulté le 2026-05-27.)

Si vous êtes déjà utilisateur de Mutt, NeoMutt est l’upgrade indolore : votre .muttrc fonctionne pour l’essentiel, le drop-in binaire est propre, et les ajouts (sidebar, intégration notmuch, améliorations de couleurs) sont exactement ce que vous auriez patché à la main. Si vous découvrez le mail en terminal en 2026, aerc a de meilleurs réglages par défaut ; NeoMutt est le bon choix quand vous héritez d’une configuration existante ou que vous travaillez dans une boîte qui s’est standardisée sur Mutt il y a des années.

Ce que NeoMutt fait mieux qu’aerc, concrètement : la souplesse des macros et des bindings, notmuch comme backend de première classe, et un corpus communautaire de 25 ans (cherchez « muttrc github » — des milliers de dotfiles sont publics). Ce qu’aerc fait mieux : les défauts, le rendu HTML, la compose embarquée, la grammaire ex-command.

Idéal pour : Mutt incumbents, utilisateurs notmuch, ceux qui aiment éditer leur config jusqu’à ce que tout soit exactement à leur main.

À éviter si : Vous démarrez de zéro sans muttrc existant — aerc demande moins de rampe d’accès.

3. Himalaya — CLI Rust, pipeable JSON

Idéal pour : Les développeurs qui veulent que le mail soit atteignable depuis xargs, un script ou un autre TUI.

Himalaya est un client mail en ligne de commande écrit en Rust (99,2 % de Rust selon le dépôt). Il supporte les backends IMAP, JMAP, SMTP, Maildir et m2dir, expose un mode de sortie JSON, et est publié sous licence AGPL-3.0. La dernière version stable est v1.2.0, sortie le 19 février 2026. (Source : github.com/soywod/himalaya, consulté le 2026-05-27.)

Himalaya n’est pas un TUI au sens d’aerc ou NeoMutt — c’est une commande. Vous lancez himalaya envelope list, vous pipez le JSON dans jq, vous le câblez dans une fonction shell ou un plugin Neovim. La surface d’authentification est inhabituellement large : anonyme, login, plain, OAuth bearer, XOAUTH2, SCRAM-SHA-256, plus HTTP basic et bearer pour JMAP. La configuration TOML supporte plusieurs comptes dans un seul fichier, et la découverte (PACC, autoconfiguration Thunderbird, SRV RFC 6186) fait qu’une mise en route manuelle est rare.

Le cadrage honnête : Himalaya est presque toujours un complément, pas un client unique. La plupart des développeurs l’associent à aerc ou NeoMutt pour la lecture, et utilisent Himalaya pour les bouts scriptés — envoi en masse, recherche programmatique, notifications CI/CD. Comme outil « lire l’actu du jour en 30 secondes », le pipeline JSON bat l’ouverture d’un GUI.

Besoin d’une remise à plat du triage avant que tout ça ait du sens ? Comment gérer plusieurs comptes mail couvre les fondations.

Idéal pour : Workflows orientés shell, automatisation scriptable, utilisateurs Neovim qui veulent des primitives mail dans leur éditeur.

À éviter si : Vous voulez vivre dans une seule app pour lire, écrire et chercher.

4. Thunderbird — le repli GUI open source qui a enfin rattrapé son retard

Idéal pour : Les développeurs qui ont besoin d’un GUI, veulent de l’open source et ont une boîte Microsoft 365 dans la pile.

Thunderbird est maintenu par MZLA Technologies Corporation (une filiale de Mozilla) sous licence MPL 2.0. Il tourne sous Windows, macOS et Linux, et est livré sur deux canaux : le 128 ESR (l’extended-support release stable actuel) et le Monthly Release. Monthly Release 145 a ajouté le support natif d’Exchange Web Services, livré fin 2025. Le support JMAP est en place depuis Thunderbird 115 (2023). (Source : blog Thunderbird, community office hours décembre 2025.)

Pour un développeur qui a essayé les clients TUI et a fait demi-tour, Thunderbird est le bon point de départ en 2026. L’API d’extension est réelle (cherchez les extensions Thunderbird sur MozillaAddons — écosystème activement maintenu), la vue source d’un message est à une touche (Ctrl+U), et la couverture de protocoles est désormais réellement complète : IMAP, POP3, JMAP et EWS (Exchange) dans le même binaire.

Deux victoires spécifiquement développeur à souligner :

Les filtres sont scriptables à un niveau utile. Combinés avec la vue source, vous bâtissez un système de triage qui approxime l’UI de filtres Gmail en pur config local.
Support d’Exchange sans Outlook. Si votre job tourne sous Microsoft 365, Thunderbird 145 Monthly est la première option GUI non-Outlook crédible qui gère Exchange nativement (plutôt qu’avec un pont IMAP fragile).

Le compromis : Thunderbird n’est pas un TUI. C’est un GUI desktop avec des entrailles amicales pour développeurs, pas un client developer-first. Le démarrage est plus lent qu’aerc, le système de raccourcis est rebindable mais les défauts sont taillés GUI, et l’index de recherche peut traîner sur des setups multi-comptes de plus de 50 Go.

Idéal pour : Exigence GUI, environnements Microsoft 365, préférence open source, équipes multiplateformes.

À éviter si : Vous voulez un lancement sous 100 ms et un workflow 100 % clavier — passez à aerc ou NeoMutt.

5. Mailspring — Electron, moteur natif, sous MIT

Idéal pour : Les développeurs qui veulent un GUI soigné sans la lenteur de démarrage de Thunderbird et qui ne sont pas allergiques à Electron.

Mailspring est un client mail desktop avec un moteur de synchronisation C++ natif et une UI Electron. Il tourne sous macOS, Windows et Linux, supporte Gmail, iCloud, Office 365, Fastmail, Outlook.com, Yahoo et IMAP/SMTP générique, et est entièrement open source sous licence MIT. Le tier Pro coûte 8 $/mois et ajoute les accusés de lecture, le tracking de liens, l’envoi différé, les modèles et l’enrichissement de contacts. (Source : getmailspring.com, consulté le 2026-05-27.)

Mailspring occupe une niche bizarre : trop soigné pour la foule terminal, trop plat pour ceux qui veulent la couche collaborative de Spark. Pour un développeur qui veut un GUI gratuit, activement maintenu et qui ne verrouille pas des fonctions derrière un paywall dans le tier gratuit, c’est un choix raisonnable. Le moteur de sync C++ natif est plus rapide que les backends JavaScript qu’embarquent la plupart des clients Electron.

Les limites honnêtes : il n’y a pas d’API publique de plugin documentée comme celle de Thunderbird. Le code est bidouillable (MIT, forkez-le), mais vous n’êtes pas la cible de l’histoire d’extensibilité existante. Si « scriptable » compte plus que « GUI soigné », passez votre chemin.

Idéal pour : Développeurs multiplateformes qui veulent un GUI gratuit avec boîte unifiée et n’ont pas besoin de scripting.

À éviter si : Vous voulez une API plugin documentée, ou vous préférez payer pour le poli Gmail-natif de Mimestream sur Mac.

6. Apple Mail — avec AppleScript et Shortcuts

Idéal pour : Développeurs Mac-only qui préfèrent automatiser le client de série plutôt qu’installer une autre app.

Apple Mail sur macOS Sequoia 15.4 (mars 2025) a gagné les catégories de boîte Apple Intelligence et les résumés on-device. Pour un usage développeur, la fonctionnalité plus pertinente est la surface AppleScript et Shortcuts présente de longue date : Mail.app expose un dictionnaire de scripting, ce qui signifie que vous pouvez construire des automatisations d’inbox, des exporteurs de pièces jointes et des règles de classement en AppleScript appelable depuis le shell, sans outil tiers.

Apple Mail n’est pas un client developer-first. C’est un client de série avec une surface d’automatisation que la plupart des gens oublient. Le dictionnaire AppleScript couvre messages, comptes, boîtes, signatures et règles. Shortcuts sur macOS (depuis Monterey) se superpose à ça et vous donne une interface click-and-build aux mêmes actions.

À quoi cela sert : automatisations d’inbox routinières qui ne justifient pas un outil dédié. Sauvegarde auto des pièces jointes d’un expéditeur connu dans un dossier projet, archivage des threads après la fin d’un événement calendrier, dispatch des messages d’un domaine vers un dossier taggé. Rien de révolutionnaire, mais ça vient avec l’OS et ça coûte zéro.

À quoi cela ne sert pas : toute équipe multiplateforme, tout ce qui doit tourner sur un serveur, tout ce qui demande une composition patch-friendly. La vue source d’Apple Mail existe (Cmd+Option+U) mais est maladroite, et le rendu HTML est opiniâtré.

Idéal pour : Développeurs Mac-only, automatisation légère, préférence « je ne veux pas d’une app de plus ».

À éviter si : Vous bougez entre plateformes, ou vous voulez un vrai triage clavier à la vitesse.

7. Spark — couche de triage d’équipe, pas un client développeur

Idéal pour : Petites équipes où un ou deux membres sont développeurs et les autres non.

Spark est un client mail multiplateforme soigné (Mac, Windows, iOS, Android) avec boîtes partagées, commentaires de thread et brouillons assistés par IA. Ce n’est pas un client orienté développeur. Nous l’incluons ici parce que pour des workflows d’équipe — où le développeur est un rôle parmi support, vente et ops — la couche collaborative de Spark est le bon compromis.

Le compromis que Spark impose : un traitement côté serveur, votre mail transite par l’infrastructure de Readdle pour alimenter les fonctions intelligentes. Pour la plupart des développeurs c’est inacceptable comme client principal ; pour des équipes où l’alternative est une bouillie Slack+Gmail fragmentée, c’est un choix défendable.

Nous incluons Spark dans la liste strictement pour qu’un développeur qui évalue « sur quoi mon équipe devrait se standardiser » ait l’option couverte. Comme client développeur personnel, l’absence de vue source plain-text, le manque de hooks de scripting et le routage serveur plaident tous contre.

Fatigué du bruit newsletter dans n’importe lequel de ces clients ? Leave Me Alone gère proprement la couche désabonnement en masse à travers les fournisseurs — voyez notre tour d’horizon des outils de désabonnement pour le comparatif.

Idéal pour : Petites équipes mixtes ; fondateurs qui font tourner les ops à côté de l’engineering.

À éviter si : Vous voulez un client developer-first, ou vous ne pouvez pas faire transiter le mail par des serveurs tiers.

Comparatif côte à côte

Les sept clients arbitrent sur trois axes : GUI ou TUI, profondeur de scriptabilité et largeur de protocoles. aerc et Himalaya sont les plus scriptables ; Thunderbird et Mailspring sont les GUIs les plus complets ; NeoMutt est le plus configurable ; Apple Mail et Spark sont du côté « automatisation comme arrière-pensée ». Côté licences, six sur sept sont open source — Spark est la seule exception.

Client	Type	Licence	Protocoles	Atout
aerc	TUI (Go)	MIT	IMAP, JMAP, Maildir, Notmuch, Mbox	Compose embarquée, rendu de patchs
NeoMutt	TUI (C)	GPL-2.0+	IMAP, POP, SMTP, Maildir, Notmuch	Compatible Mutt, config profonde
Himalaya	CLI (Rust)	AGPL-3.0	IMAP, JMAP, SMTP, Maildir	Pipeable JSON, scriptable
Thunderbird	GUI (XUL/Rust)	MPL 2.0	IMAP, POP, JMAP, EWS	GUI + API extension + EWS
Mailspring	GUI (Electron + C++)	MIT	IMAP, SMTP (Gmail/O365/Fastmail/…)	Sync rapide, tier gratuit complet
Apple Mail	GUI (Cocoa)	propriétaire (gratuit avec macOS)	IMAP, POP, Exchange, iCloud	AppleScript + Shortcuts
Spark	GUI (propriétaire)	propriétaire	IMAP, OAuth (Gmail, O365)	Triage d’équipe, boîte partagée

Si vous préférez ne pas vous engager sur un seul client, Mailbird est l’option multiplateforme soignée pour ceux qui veulent un GUI sans la complexité developer-first — il est construit pour les knowledge workers Windows, pas pour les développeurs. Bon à savoir ; pas à recommander comme client dev principal.

Pourquoi pas Hey, Superhuman ou Mailbird

Hey de Basecamp fait tout transiter par sa propre infrastructure sans porte de sortie IMAP. Superhuman est un front-end Gmail à 30 $/mois sans scripting, sans vue source, sans intégration IDE. Mailbird est un GUI Windows-first conçu pour les knowledge workers, pas les développeurs — pas de bascule source plain-text, pas d’API plugin, pas de mode terminal. Les trois sont des choix raisonnables pour des non-développeurs ; aucun ne passe la barre de base d’un développeur.

Hey de Basecamp. Hey ferme délibérément IMAP et SMTP — l’architecture est « votre mail vit dans Hey, point final ». Pour le public de Basecamp c’est une feature. Pour un développeur qui doit scripter un export en masse, intégrer un workflow git ou simplement changer de client sans tout réimporter, c’est rédhibitoire. Hey n’a pas changé ça en 2026.

Superhuman. 30 $/mois pour un wrapper Gmail rapide est un choix parfaitement valable si votre seule métrique est la vitesse-vers-zéro sur un compte Gmail. Le produit n’a pas de couche de scripting, pas de système de plugin, pas de vue source, et pas d’intégration pertinente pour développeurs. L’appeler « client mail pour développeurs » demande des définitions créatives de « développeur ».

Mailbird. Mailbird est un bon client mail Windows pour knowledge workers — boîte unifiée, panneau d’apps avec Slack et WhatsApp, raccourcis clavier soignés. Ce n’est explicitement pas un client développeur : pas de vue source plain-text par défaut, pas d’API plugin pour de la logique custom, pas de mode terminal/TUI. Nous recommandons Mailbird dans notre tour Windows et tour Mac pour un usage général ; il n’a pas sa place dans une liste centrée développeurs.

Quand aucun de ces clients ne convient

Si votre workflow est principalement de l’automatisation côté serveur (mail CI/CD, routage d’alertes, envoi transactionnel), oubliez les clients et utilisez une bibliothèque : imaplib + email en Python, lettre en Rust, nodemailer en Node, net/mail en Go. Si vous êtes sur iOS comme appareil principal, aucune des options développeur ne fonctionne — repliez-vous sur Apple Mail et délestez le scripting vers votre Mac ou un serveur.

Usages côté serveur. Lecture d’accusés de réception webhook en CI, dédup d’alertes, envoi transactionnel — aucun n’a besoin d’un client. Utilisez une bibliothèque, écrivez un petit daemon, loggez dans votre pile d’observabilité existante.

Développeurs iOS-first. Les clients TUI n’existent pas sur iOS. Les options réalistes sont Apple Mail (avec Shortcuts tournant sur l’appareil), Spark (côté serveur, acceptez le compromis) ou Gmail web. Le tooling developer-first n’est pas là.

Vous voulez un GUI soigné ET un TUI dans une seule app. Ça n’existe pas en 2026. Le plus proche est faire tourner Thunderbird + aerc en parallèle sur le même compte IMAP — ils n’entrent pas en conflit, ils lisent simplement le même état côté serveur.

Besoin de gérer trois ou quatre comptes à la fois sans perdre le contexte ? Notre guide pour gérer plusieurs comptes mail déroule les patterns de boîte unifiée.

Lectures associées :

Alexis Dollé

Fondateur & Rédacteur en chef

Alexis Dollé, expert mail depuis 10+ ans et utilisateur terminal de longue date. Fondateur d’Email Tools. Je teste chaque client sur un vrai workflow développeur — IMAP + JMAP + Maildir, git send-email et une boîte Microsoft 365 pour le client final — puis j’en parle comme à un collègue. Pas de blabla marketing, pas de classement sponsorisé, chaque affirmation sourcée.

Questions fréquentes

Quel est le meilleur client mail pour développeurs en 2026 ? : aerc

aerc, si vous vivez dans un terminal. Raccourcis vim, terminal embarqué pour composer à côté de git, rendu des patchs et diffs en première classe, support JMAP. Comme repli GUI qui respecte les réflexes développeur, Thunderbird et son API d’extension est le deuxième choix le plus sûr.

Mutt est-il encore pertinent, ou faut-il passer à aerc ? : NeoMutt reste à jour

NeoMutt reste activement maintenu — la sortie du 2026-05-04 est la plus récente — et reste le bon choix si votre mémoire musculaire est déjà dans mutt. aerc est le meilleur pari pour qui démarre de zéro en 2026 : meilleurs réglages par défaut pour le HTML, compose en terminal embarqué, système ex-command plus propre.

Peut-on utiliser Himalaya comme client mail unique ? : plutôt en complément

Si votre workflow tolère une interface en ligne de commande uniquement, oui. Himalaya v1.2.0 (sortie le 19 février 2026) est stable pour un usage quotidien IMAP, JMAP, SMTP et Maildir. Il se combine bien avec notmuch ou aerc comme couche de lecture. Pour la plupart des développeurs c’est un complément, pas un remplaçant.

Thunderbird supporte-t-il JMAP ? : oui, depuis 115

Oui — JMAP a été ajouté dans Thunderbird 115 (2023) et reste supporté dans le 128 ESR et le canal Monthly Release. Thunderbird 145 Monthly a ajouté le support natif d’Exchange Web Services. Pour un client libre et open source qui gère IMAP, JMAP et maintenant EWS, Thunderbird est l’option GUI la plus complète.

Pourquoi ni Hey, ni Superhuman, ni Spark pour les développeurs ? : les bases manquent

Hey de Basecamp est fermé et opiniâtré ; tout passe par son infrastructure propriétaire sans porte de sortie IMAP. Superhuman est un front-end Gmail sans intégration IDE ni git. Spark est correct pour le triage en équipe mais n’offre aucune vue source plain-text, aucun hook scriptable, et fait transiter les mails par les serveurs de Readdle. Les fonctions pertinentes pour un développeur sont minimales dans les trois cas.

Mailspring est-il scriptable ? : pas d’API plugin documentée

Mailspring est open source sous licence MIT et utilise un moteur de synchronisation C++ natif avec une UI Electron. Le code est bidouillable mais il n’existe pas d’API publique de plugin documentée comme Thunderbird en expose une. Pour la « scriptabilité », aerc, Himalaya ou NeoMutt sont mieux taillés — chacun est construit autour de la configuration as code.

Sources