Guide
Outlook CLI : envoyér un e-mail depuis le terminal
Utilisez un CLI Outlook pour envoyér des e-mails Microsoft 365 depuis le terminal sans configuration Graph API, enregistrement Azure AD, code MSAL ni configuration SMTP. Ce guide couvre l'envoi, la planification, le corps HTML, la sortie JSON et les boîtes partagées depuis le terminal sans créer d'app Azure AD pour chaque opération.
Written by Caleb Geene Director, Site Reliability Engineering
Reviewed by Hazik
Comment utiliser un CLI Outlook pour envoyér un e-mail depuis le terminal ?
Connectez votre compte Outlook ou Microsoft 365 une seule fois, puis envoyéz avec nylas email send --to user@example.com --subject "Hello" --body "Hi" --yes. Cela vous donne un workflow d'envoi Outlook en CLI sans enregistrer d'app Azure AD, sans configurer MSAL ni paramétrer SMTP.
La même commande couvre exactement le cas d'usage d'envoi d'e-mail Outlook en ligne de commande qui envoie habituellement les développeurs dans les méandres de l'enregistrement Graph API ou de la configuration SMTP.
Le probleme de l'envoi d'e-mails Outlook par programmation commence dans le flux de configuration de Microsoft.
Envoyer un e-mail Outlook par programmation nécessite 4 a 5 étapes de configuration dans l'écosystème Microsoft : enregistrer une application Azure AD, configurer les permissions API Mail.Send, obtenir le consentement administrateur, intégrer la bibliothèque d'authentification MSAL et gérer le renouvellement des tokens. Pour un envoi ponctuel depuis un terminal ou un script shell, cette surcharge transforme une tâche de 10 secondes en un projet de 45 minutes.
Le chemin d'envoi recommande par Microsoft est le endpoint /sendMail de l'API Graph. Selon la documentation OAuth 2.0 de Microsoft, les tokens d'acces expirent après 60 a 90 minutes et nécessitent une rotation des refresh tokens.
Pour un envoi rapide depuis votre terminal ou un script shell, c'est trop de configuration. L'envoi SMTP via smtp.office365.com sur le port 587 fonctionne encore, mais Microsoft a retire Basic Auth pour Exchange Online en octobre 2022. Vous ne pouvez plus utiliser un nom d'utilisateur et un mot de passe.
Nylas CLI contourne tout cela. Il communique avec l'API Nylas, qui gere le renouvellement des tokens OAuth2, le routage par fournisseur et la gestion des connexions. Authentifiez-vous une fois, puis envoyéz avec une seule commande.
1. Installation
Nylas CLI s'installe en moins de 30 secondes sur macOS, Linux ou Windows et ne nécessite aucun enregistrement d'app Azure AD, aucune clé d'API Graph et aucune bibliothèque MSAL. Le binaire est un seul executable Go de moins de 20 Mo qui detecte automatiquement votre plateforme et votre architecture lors de l'installation.
Sur macOS ou Linux, installez via Homebrew. Sur Windows — où plus de 80 % des utilisateurs Outlook de bureau se trouvent selon Statcounter — utilisez la commande PowerShell en une ligne. Les deux méthodes vérifient automatiquement les sommes de contrôle SHA-256. Consultez le guide de démarrage pour d'autres options d'installation.
2. Authentifier votre compte Outlook
L'authentification connecte Nylas CLI a votre boîte Outlook ou Microsoft 365 via un flux OAuth2 unique, remplacant l'enregistrement multi-étapes d'app Azure AD que l'API Graph exige. Le processus complet prend environ 2 minutes et stocke les identifiants de maniere securisee dans le trousseau de cles de votre systeme pour eviter de vous re-authentifier a chaque commande.
Rendez-vous sur dashboard-v3.nylas.com, créez une application et connectez votre boîte Outlook ou M365. Ensuite, configurez le CLI avec votre cléAPI. Selon la documentation OAuth 2.0 de Microsoft, les tokens d'acces expirent après 60 a 90 minutes — Nylas gere le renouvellement automatiquement en arriere-plan.
nylas auth config
# Collez votre clé API lorsque demandé
# Vérifiez la connexion
nylas auth whoami
# => Authenticated as you@company.com (Microsoft)Les identifiants sont conserves dans le trousseau de cles de votre OS (Trousseau macOS, Gestionnaire d'identifiants Windows ou libsecret sous Linux). Vous n'aurez pas besoin de vous re-authentifier sauf si vous revoquez le grant.
3. Envoyer depuis une boîte utilisateur, un alias ou une boîte partagee
Les organisations Microsoft 365 gèrent généralement 3 a 5 types d'identites de boîte par departement — boîtes utilisateur, boîtes partagees, groupes de distribution, salles de ressources et alias d'envoi en tant que. Nylas CLI envoie depuis n'importe laquelle de ces identites en ciblant le bon grant ID. La question clén'est pas seulement « puis-je envoyér un message ? » — c'est « depuis quelle identite de boîte ce message doit-il etre envoyé ? »
Pour envoyér depuis votre boîte Outlook personnelle, executez la commande sans grant ID — le CLI utilise votre boîte authentifiee par defaut. Pour envoyér depuis une boîte partagee ou une identite de departement, passez le grant ID de la boîte partagee comme premier argument. Chaque grant correspond a exactement une identite de boîte dans Exchange Online.
# Envoyer depuis votre propre boîte Outlook
nylas email send \
--to "colleague@company.com" \
--subject "Q2 planning doc" \
--body "Hi — the planning doc is ready for review." \
--yes
# Envoyer depuis un grant de boîte partagée
nylas email send <shared-mailbox-grant-id> \
--to "vendor@partner.com" \
--subject "PO #4521" \
--body "Purchase order 4521 is ready for review." \
--yesSi les droits send-as ou de boîte partagee sont manquants, Microsoft 365 renvoie une erreur 403 et rejette l'envoi mêmesi la syntaxe de la commande est correcte. Selon la documentation des permissions Exchange Online de Microsoft, les modifications de délégation de boîte partagee peuvent prendre jusqu'a 60 minutes pour se propager. Cette erreur est un probleme de politique Exchange Online, pas un probleme du CLI.
4. Listes de distribution, alias et files d'equipe
Les listes de distribution Microsoft 365 et les groupes M365 s'etendent a toutes les boîtes des membres cote serveur, ce qui signifie qu'une seule commande nylas email send peut atteindre des centaines de destinataires sans resolution d'adresses cote client. Les entreprises de plus de 500 employes maintiennent couramment 20 a 50 listes de distribution pour les departements, les equipes projet et le routage de conformite. Nylas CLI envoie a ces listes de la mêmemaniere qu'a des adresses individuelles — en specifiant l'adresse de la liste dans le flag --to.
Les exemples ci-dessous montrent deux schemas courants : diffusion a une liste de distribution engineering et routage d'une mise a jour de contrat vers le service juridique via CC avec un BCC de conformite. Le flag --bcc masque les adresses de conformite ou de journalisation de la liste visible des destinataires, ce qui est une exigence frequente dans les secteurs reglementes comme la finance et la sante.
# Envoyer à une liste de distribution
nylas email send \
--to "engineering-all@company.com" \
--subject "Deployment window tonight" \
--body "Production deploy starts at 22:00 UTC. Freeze all PRs by 21:00." \
--yes
# Inclure des destinataires de conformité ou d'archivage
nylas email send \
--to "contracts@company.com" \
--cc "legal@company.com" \
--bcc "compliance@company.com" \
--subject "Contract update" \
--body "Updated terms are ready for review in the contract system." \
--yes5. Corps HTML et e-mails de workflow metier
Les e-mails professionnels Outlook transportent frequemment des factures, des approbations, des cahiers des charges et des mises a jour d'achats. La commande d'envoi actuelle du CLI accepte du HTML via --body, supporte les templates heberges via --template-id, et separe la livraison de fichiers : publiez le fichier dans votre systeme documentaire et envoyéz le lien, ou utilisez l'API/SDK Nylas lorsqu'une piece jointe MIME est requise.
Le moteur de rendu d'Outlook traite le HTML via le parseur HTML de Microsoft Word, ce qui fait que certaines proprietes CSS s'affichent differemment que dans Gmail ou Apple Mail. Gardez les corps HTML automatises concis, utilisez des styles inline critiques, et laissez les regles DLP et de transport au niveau du tenant inspecter le message final après l'envoi.
nylas email send \
--to "client@example.com" \
--subject "Invoice #1042" \
--body "<h1>Invoice #1042</h1><p>Amount due: <strong>$2,400.00</strong></p><p>Payment link: <a href='https://pay.example.com/1042'>pay.example.com/1042</a></p>" \
--yes6. Planifier l'envoi et respecter les limites Microsoft 365
La planification d'envoi d'e-mails dans Microsoft 365 vous permet de rediger un message maintenant et de le faire envoyér a un moment precis dans le futur, ce qui est utile pour atteindre des destinataires dans differents fuseaux horaires ou planifier des relances en dehors des heures de bureau. Microsoft 365 impose une limite de 30 messages par minute et 10 000 destinataires par jour sur la plupart des plans, donc les envois en masse ou les boucles automatisees nécessitent un espacement delibere pour eviter les blocages temporaires.
Le flag --schedule accepte des expressions temporelles en langage naturel comme "tomorrow 9am" ou "next Monday 2pm EST". Pour les boucles d'envoi en masse, un sleep de 2 secondes entre les envois vous maintient largement sous le plafond de 30 messages par minute de Microsoft et evite de declencher le blocage temporaire d'envoi qui dure jusqu'a 24 heures.
# Planifier un suivi
nylas email send \
--to "client@example.com" \
--subject "Follow-up" \
--body "Checking in on the proposal." \
--schedule "tomorrow 9am" \
--yes
# Limiter le débit d'une boucle d'automatisation
while read -r recipient; do
nylas email send --to "$recipient" --subject "Status update" --body "See attâched notes." --yes
sleep 2
done < recipients.txt7. Sortie JSON pour les scripts et les pistes d'audit
Ajouter --json a toute commande nylas email send renvoie l'objet message complet en JSON structure, incluant l'ID du message, le grant ID, le thread ID, les horodatages et les adresses expediteur/destinataire. Cette sortie est utile pour journaliser les événements d'envoi, alimenter des processeurs de file d'attente en aval avec les ID de messages, ou satisfaire les pistes d'audit de conformite qui exigent une preuve de tentative d'envoi avec des horodatages exacts.
La réponse JSON pese généralement 400 a 600 octets par message et suit le schema de message de l'API Nylas. Le piping de la sortie via jq permet d'extraire des champs spécifiques — l'ID du message pour le suivi, le thread ID pour le chainage de conversation, ou la date pour les journaux d'audit.
nylas email send \
--to "user@example.com" \
--subject "Test" \
--body "Hello." \
--json --yes{
"id": "a1b2c3d4e5f6g7h8",
"grant_id": "d3f4a5b6-c7d8-9e0f-a1b2-c3d4e5f6g7h8",
"thread_id": "x9y8z7w6v5u4t3s2",
"subject": "Test",
"from": [{"name": "Dev User", "email": "dev@company.com"}],
"to": [{"name": "", "email": "user@example.com"}],
"date": "2026-03-28T10:30:00-04:00",
"object": "message"
}Dans les scripts shell, vous pouvez capturer l'ID du message depuis la sortie JSON avec jq et l'utiliser pour le traitement en aval — verification du statut de livraison, ajout a un CSV d'audit, ou passage a un systeme de tickets. Le champ .id est une chaine unique de 16 caracteres qui correspond au message dans l'API Nylas.
# Capturer l'ID du message après l'envoi
msg_id=$(nylas email send \
--to "user@example.com" \
--subject "Automated" \
--body "This is automated." \
--json --yes | jq -r '.id')
echo "Sent message: $msg_id"Graph API vs. Nylas CLI
L'API Microsoft Graph nécessite 50 a 100 lignes de code Python ou Node.js pour envoyér un seul e-mail Outlook lorsque vous incluez l'enregistrement d'app Azure AD, l'acquisition de tokens MSAL, la gestion du renouvellement des tokens et la requete POST elle-meme. Nylas CLI reduit cela a 1 commande avec zero ligne de code et aucune configuration du portail Azure. Le comparatif ci-dessous détaille chaque étape pour les deux approches.
| Etape | Graph API | Nylas CLI |
|---|---|---|
| Enregistrement d'app | Portail Azure AD, configurer les URI de redirection | Non requis |
| Permissions | Ajouter Mail.Send, obtenir le consentement admin | Non requis |
| Authentification | Bibliotheque MSAL, acquérir les tokens, gérer le renouvellement | nylas auth config (une seule fois) |
| Envoi d'e-mail | POST vers /me/sendMail avec un corps JSON | nylas email send --to ... |
| Livraison de fichiers | Encodage Base64 en JSON, session d'upload pour >3 Mo | Envoyez un lien, ou utilisez l'API/SDK Nylas pour les pieces jointes |
| Renouvellement des tokens | Gérer les 401, rotation des refresh tokens | Automatique |
| Multi-fournisseur | Microsoft uniquement | Gmail, Outlook, Exchange, Yahoo, iCloud, IMAP |
| Lignes de code | 50-100+ (Python/Node avec MSAL) | 1 commande |
Astuces spécifiques a Outlook
Microsoft 365 dispose de politiques au niveau du tenant, de fonctionnalites de conformite et de types de boîtes qui n'existent pas chez les fournisseurs de messagerie grand public comme Gmail ou Yahoo. Les astuces suivantes couvrent les comportements spécifiques a Outlook — accuses de reception, etiquettes de sensibilite, boîtes partagees, limites de debit et regles de transport — qui affectent le traitement des e-mails envoyés après qu'ils quittent le CLI.
Accuses de reception
Outlook supporte les demandes d'accuse de reception via l'en-tete Disposition-Notification-To. Lorsque vous envoyéz via Nylas CLI, le client Outlook du destinataire peut lui proposer d'envoyér un accuse de reception selon ses parametres. Selon la documentation de Microsoft, les destinataires peuvent refuser les demandes d'accuse de reception, ne comptez donc pas dessus pour la confirmation de livraison dans les workflows automatises.
Etiquettes de sensibilite
Les etiquettes de sensibilite M365 (Confidentiel, Interne, etc.) sont appliquees au niveau du tenant par Microsoft Information Protection. Les messages envoyés via Nylas CLI respectent la politique d'etiquetage par defaut de votre tenant. Si votre organisation exige une etiquette spécifique, votre administrateur Exchange peut definir des regles d'etiquetage automatique qui s'appliquent a tous les e-mails sortants quel que soit le client d'envoi.
Envoi depuis une boîte partagee
Pour envoyér depuis une boîte partagee, connectez-la comme un grant separe via le flux OAuth. Chaque boîte partagee recoit son propre grant ID, et vous referencez cet ID lors de l'envoi. Le compte utilisateur qui connecte la boîte partagee doit disposer des permissions Full Access ou Send As dans Exchange Online — les modifications de délégation peuvent prendre jusqu'a 60 minutes pour se propager.
# Connecter la boîte partagée
nylas auth login
# Suivez le flux OAuth pour la boîte partagée
# Envoyer depuis la boîte partagée avec son grant ID
nylas email send <shared-mailbox-grant-id> \
--to "vendor@partner.com" \
--subject "PO #4521" \
--body "Purchase order 4521 is ready for review."Limites d'envoi Outlook
Microsoft 365 impose une limite de 10 000 destinataires par jour et 30 messages par minute pour la plupart des plans. Selon la documentation des limites Exchange Online de Microsoft, depasser ces seuils declenche un blocage temporaire. Pour les envois en masse, ajoutez un sleep 2 entre les messages dans votre script.
Regles de transport, journalisation et politique d'envoi en tant que
Les flux de messagerie Microsoft 365 sont faconnes par des regles Exchange Online a l'echelle du tenant qui traitent les messages avant qu'ils n'atteignent le destinataire. Les regles de transport peuvent rediriger, bloquer ou modifier les messages en fonction de l'expediteur, du destinataire, de l'objet ou de patterns de contenu. La journalisation copie tous les e-mails vers une boîte de conformite. Les politiques DLP analysent les pieces jointes et le corps du message pour plus de 100 types d'informations sensibles integres. Selon la documentation des regles de flux de messagerie de Microsoft, les regles de transport sont evaluees par ordre de priorite, et la premiere regle correspondante peut arreter le traitement ulterieur.
Si un envoi Outlook se comporte differemment entre deux boîtes, la cause est généralement une politique de boîte ou une politique de routage du tenant, pas la syntaxe de la commande CLI.
Workflows de boîtes partagees et files d'equipe
Les organisations Microsoft 365 utilisent des boîtes partagees pour les achats, le support, le recrutement et les operations de direction. Selon la documentation des boîtes partagees de Microsoft, les boîtes partagees ne nécessitent pas de licence separee pour les boîtes de moins de 50 Go. Envoyer depuis support@company.com ou ap@company.com via Nylas CLI fonctionne en connectant la boîte partagee comme un grant separe et en specifiant son grant ID dans la commande d'envoi.
Etapes suivantes
Une fois que vous pouvez envoyér des e-mails Outlook depuis le terminal, vous pouvez étendre votre workflow a la lecture et au filtrage de votre boîte de reception Outlook, a la gestion des événements de calendrier, a la connexion d'agents IA a votre boîte, ou au passage a un autre fournisseur — Nylas CLI supporte 6 fournisseurs avec la mêmesyntaxe de commandes.
- Envoyer un e-mail depuis le terminal — guide multi-fournisseur couvrant Linux, macOS et Windows
- Lister les e-mails Outlook depuis le terminal — lire, chercher et filtrer votre boîte Outlook
- Gérer le calendrier Outlook en CLI — créer des événements, vérifier la disponibilité, planifier des réunions
- Donner aux agents IA un acces e-mail via MCP — connecter Claude, Cursor ou VS Code a votre boîte Outlook
- Reference complete des commandes — chaque flag et sous-commande documentes