fast-mailer : comment sortir le modèle de l’envoi a ramené un e-mail à quelques secondes
fast-mailer permet à un agent IA d’envoyer un e-mail Gmail en une commande shell au lieu de piloter une interface mail. Fonctionnement, vérifications du code et limites d’un outil tout neuf.
HISTOIRE DE CONSTRUCTION · OUTILS POUR AGENTS
Un agent qui met d’une à quatre minutes pour envoyer un seul e-mail ne réfléchit pas intensément. Il attend : qu’un navigateur charge, qu’un bouton apparaisse, que son prochain tour arrive. L’auteur de fast-mailer, un petit dépôt open source publié le 24 septembre 2026, raconte qu’un ami a rencontré exactement ce problème. La solution n’a pas été un modèle plus intelligent. Il a retiré le modèle de la seule partie du travail qui n’en avait jamais eu besoin.
En bref
- fast-mailer est un dépôt sous licence MIT qui permet à tout agent capable de lancer une commande shell d’envoyer un e-mail Gmail en un seul appel :
python send.py to subject body. GitHub - Selon l’auteur, l’agent de son ami est passé de 1 à 4 minutes par e-mail à environ 14 secondes. Le README mesure l’appel d’envoi seul à environ 0,6 à 1 seconde. Le reste, c’est le tour de l’agent lui-même.
- C’est une v1.0.0 du premier jour, sans tests. Elle demande à Gmail plus de droits que l’envoi n’en exige, et j’ai trouvé une vérification d’entrée à ajouter avant d’y faire passer du texte non fiable.
RÉPONSE RAPIDE
Pourquoi c’est rapide
L’agent rédige l’e-mail et le transmet. Un simple script construit le message et l’envoie directement à l’API Gmail. Pas de navigateur, pas de serveur d’outils à démarrer, aucun appel au modèle entre « envoyer » et « envoyé ».
Ce qui est rapporté
Cette section s’appuie sur le dépôt public tel qu’il était le 24 septembre 2026 (4 commits, 0 étoile, licence MIT) et sur le récit de l’auteur sur la raison de sa création. J’ai lu tout le code. Les chiffres de vitesse viennent de l’auteur et du README ; je n’ai envoyé aucun vrai e-mail.
Le problème : un agent fait le travail d’un script
Beaucoup de configurations d’agents envoient du courrier comme le ferait une personne : ouvrir Gmail dans un navigateur, cliquer sur Nouveau message, taper, cliquer sur Envoyer. Chaque étape est un aller-retour par le modèle, qui regarde la page et décide quoi faire ensuite. Le fichier de compétence du dépôt classe la voie navigateur en dernier et la qualifie de « minutes - last resort only » (« minutes, dernier recours uniquement »). L’auteur n’a pas publié comment l’agent de son ami envoyait ses e-mails auparavant ; le navigateur est donc le suspect probable, pas un fait confirmé.
Ce que contient le dépôt
| Élément | Rôle |
|---|---|
send.py | Bibliothèque standard Python uniquement. Construit un message MIME, rafraîchit le jeton OAuth en mémoire, envoie au point d’accès d’envoi de Gmail et affiche un JSON avec l’ID du message et le temps écoulé. |
Dossier triggers/ | Déposez un fichier .txt ou .json par e-mail, puis lancez python send.py watch --once. Les fichiers envoyés vont dans triggers/sent/, les échecs reçoivent le suffixe .failed. |
cli/gmaild.mjs | Démon Node 18+ optionnel sur 127.0.0.1 qui garde une connexion TLS chaude vers Gmail et rafraîchit le jeton toutes les 5 minutes. |
cli/auth-server.js | Connexion Google unique qui enregistre un jeton de rafraîchissement dans secrets/. |
skills/fast-mailer/SKILL.md, AGENTS.md | Instructions indiquant à Claude Code, Cursor, ZCode et outils similaires quelle commande lancer, plus un plugin ZCode. |
D’où viennent les 14 secondes
L’appel d’envoi est bref. Le cœur de send.py est un seul POST HTTPS d’un message encodé en base64 vers gmail.googleapis.com/gmail/v1/users/me/messages/send, le point d’accès que Google documente pour cela. Le README l’estime à 0,6-1 seconde à froid et à environ 0,5 seconde avec le démon.
Où passent alors les ~13 autres secondes ? C’est ma lecture, pas une mesure : l’agent doit encore lire la demande, écrire la commande, attendre le résultat et répondre. Cela fait un tour de modèle au lieu de dizaines. Le fichier de skill demande même de répondre « uniquement le message_id + ms. Pas de narration », ce qui raccourcit aussi la dernière étape.
Le gain ne vient pas d’un envoi plus rapide, mais de moins de tours de modèle entre la demande et le résultat.
Ce que j’ai vérifié dans le code
J’ai lancé send.py hors ligne dans un bac à sable, avec de faux identifiants et l’appel réseau remplacé, donc rien n’a été envoyé. La construction du message a pris environ 1,4 ms. Les affirmations de sécurité du README ont tenu dans les chemins testés :
- Seuls deux hôtes sont autorisés :
oauth2.googleapis.cometgmail.googleapis.com. Toute autre URL est refusée. - Les noms de fichiers de triggers doivent suivre un motif strict.
../x.txt, les noms avec espaces et les fichiers cachés ont été rejetés. - Avant chaque requête, l’hôte est résolu et bloqué s’il pointe vers une adresse privée ou locale. Les redirections sont limitées à 2.
- L’expéditeur Python n’écrit jamais dans le fichier du jeton. Le démon enregistre les jetons rafraîchis avec le mode de fichier 0600.
Une lacune : les champs objet et destinataire ne sont pas contrôlés pour les sauts de ligne. Dans mon test hors ligne, un objet Hello + saut de ligne + Bcc: attacker@example.net a produit un vrai en-tête Bcc supplémentaire. Si l’agent n’envoie que ce que vous avez tapé, cela n’a pas d’importance. S’il peut placer dans l’objet du texte venant d’une page web ou d’un e-mail reçu, si. Un correctif court :
# add at the top of send_email() in send.py
for field in [to, subject, sender or ""] + list(cc or []):
if "\r" in field or "\n" in field:
raise ValueError("line break in a header field")À vous : chronométrez votre propre chemin
Pour voir où passe le temps de votre agent, chronométrez le script seul et comparez avec le tour complet de l’agent. Le script renvoie son propre champ ms ; ce petit enrobage ajoute le temps réel autour :
start=$(date +%s.%N)
python send.py you@example.com "timing test" "hello" | tee /tmp/send.json
end=$(date +%s.%N)
echo "script wall time: $(echo "$end - $start" | bc) s"
# the gap between this and the agent's full reply time is model timeAnalyse (Jack Gross)
La leçon générale : gardez le modèle hors du chemin critique
Le schéma est simple et vaut d’être copié au-delà du courrier. Quand une tâche a une forme fixe (destinataire, objet, corps), laissez le modèle remplir les champs et le code ordinaire faire le reste. Chaque étape que le modèle doit surveiller et approuver coûte des secondes et ajoute une chance d’erreur. Passer de 1-4 minutes à 14 secondes, c’est une réduction d’environ 4x à 17x, et presque tout vient des tours de modèle supprimés, pas d’un réseau plus rapide.
Le dossier triggers est l’idée la plus intéressante. Il sépare « décider quoi envoyer » de « l’envoyer ». Un agent, une tâche cron ou une personne peut mettre des e-mails en file sous forme de fichiers, et un seul passage les envoie tous. La boîte d’envoi devient aussi facile à inspecter avant que quoi que ce soit ne parte.
Limites à garder en tête
- Tout neuf. Publié le jour de la rédaction, v1.0.0, aucun test dans le dépôt, pas encore d’utilisateurs extérieurs. Les 14 secondes sont le rapport d’une personne sur une configuration.
- Droits larges. La connexion demande
gmail.modifyetgmail.readonly. La documentation de Google indique que la portée plus étroitegmail.sendsuffit pour envoyer. Un jeton volé dans cette configuration permet de lire et modifier votre courrier, pas seulement d’envoyer. - Contrôle des en-têtes. Ajoutez la vérification des sauts de ligne ci-dessus avant d’y faire passer du texte non fiable.
- Les limites de Gmail s’appliquent toujours. Google plafonne l’envoi par jour (par exemple 2 000 messages par utilisateur sur Google Workspace, 500 pour les comptes d’essai) et 500 destinataires par message via l’API. Le script n’a ni limitation de débit ni nouvelle tentative au-delà d’un rafraîchissement du jeton ; les envois en masse buteront sur ces plafonds.
- La vitesse a un revers. Sans étape navigateur, plus d’écran où un humain jette un œil au brouillon. Si votre agent doit demander avant d’envoyer, ce contrôle doit maintenant vivre dans ses instructions.
- Mise en place. Il faut votre propre projet Google Cloud et client OAuth, et l’assistant de connexion utilise le port 80 par défaut.
- Gmail uniquement. Pas d’Outlook ni de SMTP générique, et pas de pièces jointes dans le code actuel.
Verdict
fast-mailer est une petite correction lisible à un problème réel et courant, et son modèle de sécurité est plus soigné que celui de la plupart des outils de premier jour. Prenez-le comme un bon point de départ : restreignez la portée à gmail.send, ajoutez la vérification des en-têtes et gardez une validation humaine là où elle compte. La leçon dépasse largement le courrier : moins de tours de modèle valent mieux qu’un modèle plus rapide.
FAQ
fast-mailer utilise-t-il un modèle d’IA pour envoyer les e-mails ?
Non. L’agent rédige le contenu, puis un script l’envoie via l’API Gmail sans appel au modèle entre les deux.
Les 14 secondes correspondent-elles à l’envoi d’un e-mail ?
C’est le temps du tour complet de l’agent selon l’auteur. L’appel d’envoi seul prend environ 0,6 à 1 seconde d’après le README.
Avec quels agents fonctionne-t-il ?
Avec tout agent capable de lancer des commandes shell. Le dépôt fournit des instructions pour Claude Code, Cursor et ZCode.
Sources : fast-mailer sur GitHub (code, README, SKILL.md, historique des commits, lus le 24 septembre 2026) · API Gmail : users.messages.send · Limites d’envoi Gmail dans Google Workspace. Les durées de 1-4 minutes et 14 secondes proviennent de l’auteur du dépôt.