VBA Outlook dans Excel — envoyer un e-mail depuis une macro (et ce que casse New Outlook)

Testé sur : Excel 365 v2509 · Excel 2021 · Excel 2019 (Outlook classique) · dernière vérification le 12/06/2026

En bref — Envoyer du courrier depuis Excel, c'est piloter le modèle objet d'une autre application. Deux décisions comptent : comment vous vous connectez à Outlook (le late binding avec CreateObject est le choix portable) et comment vous envoyez (.Display pour relire sans risque, .Send pour tirer aussitôt et heurter l'invite de sécurité). Une chose à savoir d'emblée : « New Outlook » a retiré tout support de VBA — ceci ne marche qu'avec l'Outlook classique.

Sub EnvoyerDepuisExcel()
    Dim olApp As Object, mail As Object
    Set olApp = CreateObject("Outlook.Application")   ' late binding — aucune référence requise
    Set mail = olApp.CreateItem(0)                    ' 0 = olMailItem

    With mail
        .To = "[email protected]"
        .Subject = "Rapport quotidien"
        .Body = "Chiffres en pièce jointe. — envoyé depuis Excel"
        .Attachments.Add ThisWorkbook.FullName
        .Display                                       ' relire ; .Send tire aussitôt
    End With

    Set mail = Nothing
    Set olApp = Nothing
End Sub

Le modèle mental : vous télécommandez une autre app, vous n'écrivez pas du code Excel

Tout le reste de votre macro parle à Excel. Pas ceci. CreateObject("Outlook.Application") atteint un programme séparé et le dirige. Cela recadre chaque question qui suit : se connecter à Outlook est une poignée de main inter-applications (les différences de version comptent donc), et envoyer du courrier franchit une frontière de sécurité qu'Excel n'impose jamais à ses propres cellules (un mur d'invites de consentement est donc voulu, pas un bug).

Gardez cette image, et les deux vraies décisions deviennent évidentes. D'abord, comment obtenir une poignée sur Outlook — lier tôt avec une référence, ou tard avec CreateObject ? Ensuite, comment envoyer réellement — faire surgir le brouillon pour qu'un humain le vérifie, ou tirer et rencontrer l'invite de sécurité ? Réglez ces deux-là, et le reste n'est que remplir .To, .Subject, .Body.

La seule règle : le late binding (CreateObject) voyage ; l'early binding vous attache à une machine

C'est la décision qui détermine si votre macro survit à un envoi à un collègue :

L'early binding exige une référence (Outils → Références → Microsoft Outlook XX.0 Object Library). Vous obtenez IntelliSense et des constantes nommées comme olMailItem — mais le fichier est désormais lié à cette version précise de bibliothèque et lève « Projet ou bibliothèque introuvable » sur un PC avec un autre Outlook. Le late binding (CreateObject("Outlook.Application"), variables en Object) n'a pas de référence, marche entre versions, et c'est le bon défaut pour du code partagé.

Le coût du late binding est que les constantes nommées n'existent pas — vous utilisez leurs valeurs numériques : CreateItem(0) au lieu de CreateItem(olMailItem). Un petit prix pour la portabilité :

' ✓ LATE BINDING — portable, aucune référence, survit aux différences de version
Dim olApp As Object
Set olApp = CreateObject("Outlook.Application")
Dim mail As Object
Set mail = olApp.CreateItem(0)        ' 0 = olMailItem (la constante n'existe pas ici)

' L'EARLY BINDING (avec la référence) permettrait :
'   Dim olApp As Outlook.Application
'   Set mail = olApp.CreateItem(olMailItem)
' ...mais casse avec « Projet ou bibliothèque introuvable » sur une autre version d'Outlook.

Utilisez l'early binding pendant l'écriture — IntelliSense aide vraiment — puis passez au late binding avant de partager. (Pour retrouver une instance existante au lieu d'en lancer une nouvelle, GetObject s'associe à CreateObject.)

Le piège : .Send heurte un mur de sécurité — .Display est souvent ce que vous voulez

La seconde décision est comment le courrier part. .Send expédie aussitôt — et sur la plupart des configurations cela déclenche la garde d'accès programmatique d'Outlook, l'invite « Un programme tente d'envoyer un message en votre nom », ou un refus net par stratégie :

.Display     ' ✓ ouvre le brouillon, un humain relit et clique Envoyer — pas d'invite de sécurité
.Send        ' ⚠ tire aussitôt ; attendez-vous à l'invite ou à un blocage par stratégie

.Display contourne tout le problème en gardant un humain dans la boucle : l'e-mail s'ouvre, entièrement rempli, et la personne clique Envoyer. Pour un flux « rédige-moi 50 e-mails personnalisés à survoler et envoyer », ce n'est pas une limite — c'est le design le plus sûr. Réservez .Send à l'automatisation de confiance sans surveillance, et sachez que le faire marcher en silence, c'est traiter le modèle de sécurité (un emplacement de confiance, une stratégie Exchange, ou un outil comme Redemption), pas un correctif d'une ligne.

Le mur que vous ne pouvez pas contourner par le code : New Outlook n'a pas de VBA

C'est la partie que les anciens tutoriels n'évoquent pas, et en 2026 le plus important ici :

« New Outlook » — le client web reconstruit que Microsoft déploie par défaut — ne prend en charge ni VBA, ni les compléments COM, ni les macros. Pas d'éditeur VBA, pas de ThisOutlookSession, pas d'Outlook.Application à automatiser. Tout cet article exige l'Outlook classique.

Ce n'est pas de la spéculation ; c'est la direction annoncée par Microsoft, et le remplacement officiel est Power Automate, pas un VBA plus récent. L'Outlook classique tourne encore aujourd'hui, et CreateObject("Outlook.Application") le pilote toujours — mais vous automatisez désormais un client que votre propre éditeur a marqué pour la mise au rebut. Si vous choisissez où investir, cela compte : une macro qui envoie via l'Outlook classique repose sur un terrain déjà en cours de déblaiement.

Quand utiliser quoi

L'opinion : ne bâtissez pas de nouvelle automatisation sur Outlook VBA en 2026

La ligne à laquelle je m'engage : si vous démarrez de zéro, n'ancrez pas votre automatisation d'e-mail à Outlook VBA. Cela marche dans l'Outlook classique aujourd'hui, et si vous avez déjà une macro qui tourne, laissez-la tourner. Mais Microsoft a été explicite : New Outlook — le défaut des nouvelles installations — n'a pas de VBA, et « le défaut » est là où vos utilisateurs vont, qu'ils l'aient choisi ou non. Écrire des macros toutes neuves contre Outlook.Application, c'est bâtir sur des fondations que le propriétaire a déjà affichées pour démolition.

Traitez donc l'Outlook VBA existant comme un héritage à maintenir, pas un motif à étendre. Quand il vous faut une nouvelle automatisation « Excel atteint le monde extérieur » — e-mail, plannings, déplacements inter-apps — choisissez quelque chose qui ne dépend pas d'un modèle de processus que Microsoft retire. Les quelques minutes passées à câbler CreateObject et à combattre l'invite de sécurité sont mieux investies dans une approche qui existera encore après la fin du déploiement de New Outlook.

Erreurs courantes de VBA Outlook (et la solution)

Quand l'automatisation d'e-mail s'accumule — décrivez plutôt la tâche

Vous ne vouliez pas étudier les modes de liaison et les invites de sécurité. Vous vouliez « envoyer à chaque manager les chiffres de son équipe chaque lundi ». Le temps de choisir le late binding, d'esquiver le mur du .Send avec .Display, et de découvrir que la moitié de vos utilisateurs sont sur New Outlook où rien ne tourne, la plomberie a mangé la matinée. ExcelMaster Agent vous laisse décrire le résultat en français clair — « découpe cette feuille par manager et rédige à chacun un e-mail avec ses lignes en pièce jointe » — et le fait sans s'appuyer sur un modèle de processus que Microsoft retire, en sauvegardant d'abord votre classeur. Essayer gratuitement →

Guides associés

• VBA On Error — Resume Next vs GoTo & pourquoi les macros cachent les bugs
• VBA MsgBox — Oui/Non, boutons & la règle des parenthèses
• VBA VLookup — le plantage « introuvable » et quand un Dictionary gagne
• VBA Copy Paste — éviter le presse-papiers pour des macros plus rapides
• VBA boucle For dans Excel — 8 exemples concrets

FAQ

Comment envoyer un e-mail depuis Excel en VBA ? Créez un objet application Outlook avec CreateObject("Outlook.Application"), un élément de courrier avec CreateItem(0), définissez .To, .Subject et .Body, puis appelez .Display pour relire ou .Send pour tirer. Utilisez le late binding (As Object) pour que la macro tourne sur n'importe quelle version d'Outlook, et n'oubliez pas : il faut l'Outlook classique.

Quelle est la différence entre early et late binding pour Outlook ? L'early binding exige une référence à la Microsoft Outlook Object Library et donne IntelliSense et des constantes comme olMailItem, mais lie le fichier à une version d'Outlook. Le late binding utilise CreateObject avec des variables As Object — aucune référence, pleinement portable — au prix de nombres comme 0 au lieu de olMailItem. Partagez le code en late binding.

Pourquoi VBA .Send déclenche-t-il un avertissement de sécurité ? La garde d'accès programmatique d'Outlook affiche « Un programme tente d'envoyer un e-mail en votre nom » pour empêcher un logiciel malveillant d'envoyer en silence. Utilisez .Display pour qu'un humain clique Envoyer, ce qui évite l'invite. Pour envoyer sans surveillance, vous devez satisfaire le modèle de sécurité — un emplacement de confiance, une stratégie Exchange, ou un outil comme Redemption.

VBA fonctionne-t-il dans New Outlook ? Non. New Outlook — le client web que Microsoft rend par défaut — n'a ni VBA, ni compléments COM, ni support de macros. CreateObject("Outlook.Application") ne pilote que l'Outlook classique. Le remplacement recommandé par Microsoft pour l'automatisation est Power Automate.

Comment joindre un fichier à un e-mail Outlook en VBA ? Utilisez .Attachments.Add avec un chemin complet : .Attachments.Add ThisWorkbook.FullName joint le classeur courant. Enregistrez d'abord le classeur, sinon FullName ne renvoie que le nom de fichier sans chemin et la pièce jointe sera introuvable.