8.2 : Envoyer un rapport par email automatiquement

Sophie referme le Planificateur de tâches configuré en 8.1 : « Le rapport se génère bien chaque matin à 8h. Mais personne ne va aller le chercher sur le serveur. Il faut qu’il arrive directement dans ma boîte mail. » Dernière étape avant que l’automatisation soit vraiment complète : livrer le résultat, pas seulement le produire.

Send-MailMessage : simple, mais obsolète

Pendant longtemps, l’envoi d’un email en PowerShell reposait sur une seule cmdlet, très simple d’usage :

Send-MailMessage -From "[email protected]" `
                  -To "[email protected]" `
                  -Subject "Rapport de supervision - $(Get-Date -Format 'dd/MM/yyyy')" `
                  -Body "Voir le rapport en pièce jointe" `
                  -Attachments "C:\Nordika\Rapports\rapport.txt" `
                  -SmtpServer "smtp.nordika.local"

Point de vigilance important, à connaître avant tout script écrit aujourd’hui : Send-MailMessage est officiellement marquée obsolète par Microsoft depuis PowerShell 7.x, car elle ne supporte pas les protocoles d’authentification modernes exigés par la plupart des fournisseurs de messagerie actuels (OAuth2, notamment pour Microsoft 365 et Gmail). Elle continue de fonctionner sur un relais SMTP interne à l’ancienne, sans authentification renforcée, mais Microsoft recommande de ne plus s’appuyer dessus pour du code neuf.

L’alternative recommandée : Microsoft Graph pour Microsoft 365

Pour un environnement Microsoft 365 (le cas de beaucoup d’entreprises comme Nordika), l’approche moderne passe par le module Microsoft.Graph.Mail, qui utilise l’API Graph avec authentification OAuth2 :

Install-Module Microsoft.Graph.Mail -Scope CurrentUser
Connect-MgGraph -Scopes "Mail.Send"

$message = @{
    Message = @{
        Subject = "Rapport de supervision - $(Get-Date -Format 'dd/MM/yyyy')"
        Body = @{
            ContentType = "Text"
            Content = "Voir le rapport en pièce jointe"
        }
        ToRecipients = @(
            @{ EmailAddress = @{ Address = "[email protected]" } }
        )
    }
}

Send-MgUserMail -UserId "[email protected]" -BodyParameter $message

Retour d’expérience terrain : cette approche demande un peu plus de configuration initiale côté Azure AD (enregistrement d’une application, permissions déléguées ou applicatives selon le contexte d’exécution — interactif ou automatisé sans surveillance), mais c’est la seule vraiment pérenne face au durcissement progressif des exigences de sécurité imposées par Microsoft 365 ces dernières années. Pour un script planifié sans utilisateur connecté (comme la tâche créée en 8.1), on privilégiera une authentification par certificat plutôt que par mot de passe, pour rester cohérent avec les principes de sécurité déjà posés en section 6.

Une alternative multiplateforme : le module MailKit

Pour un serveur SMTP générique, en dehors de tout écosystème Microsoft 365, le module communautaire Send-MailKitMessage (basé sur la bibliothèque .NET MailKit) offre une syntaxe proche de l’ancien Send-MailMessage, tout en supportant les protocoles modernes :

Install-Module -Name Send-MailKitMessage -Scope CurrentUser

$credentialSMTP = Get-Credential

Send-MailKitMessage -From "[email protected]" `
                     -RecipientList "[email protected]" `
                     -Subject "Rapport de supervision" `
                     -TextBody "Voir le rapport en pièce jointe" `
                     -AttachmentList "C:\Nordika\Rapports\rapport.txt" `
                     -SMTPServer "smtp.nordika.local" `
                     -Port 587 `
                     -Credential $credentialSMTP `
                     -UseSecureConnectionIfAvailable

Source officielle : la page Microsoft Learn de Send-MailMessage mentionne explicitement son statut obsolète et renvoie vers Microsoft.Graph.Mail comme remplacement recommandé pour un environnement Microsoft 365. Pour un serveur SMTP tiers, la documentation du module Send-MailKitMessage, disponible sur la PowerShell Gallery (vue en 6.1), détaille l’ensemble des paramètres de sécurisation de la connexion (TLS, ports).

Un exemple concret Nordika : automatiser la livraison du rapport de la section 7

En reprenant le script du TP N°3 et la planification de la leçon 8.1 :

# Génération du rapport (vu au TP N°3 de la section 7)
$rapportFinal | Format-Table -AutoSize | Out-File -FilePath "C:\Nordika\Rapports\rapport-$(Get-Date -Format 'yyyyMMdd').txt"

# Envoi via Microsoft Graph, avec authentification par certificat pour un contexte non interactif
Connect-MgGraph -ClientId $appId -TenantId $tenantId -CertificateThumbprint $thumbprint

$message = @{
    Message = @{
        Subject = "Rapport de supervision - $(Get-Date -Format 'dd/MM/yyyy')"
        Body = @{ ContentType = "Text"; Content = "Rapport généré automatiquement, voir pièce jointe." }
        ToRecipients = @(@{ EmailAddress = @{ Address = "[email protected]" } })
        Attachments = @(
            @{
                "@odata.type" = "#microsoft.graph.fileAttachment"
                Name = "rapport.txt"
                ContentBytes = [Convert]::ToBase64String([IO.File]::ReadAllBytes("C:\Nordika\Rapports\rapport-$(Get-Date -Format 'yyyyMMdd').txt"))
            }
        )
    }
}

Send-MgUserMail -UserId "[email protected]" -BodyParameter $message

Retenez le message principal de cette leçon : contrairement à la plupart des cmdlets vues depuis le début de la formation, Send-MailMessage fait partie des rares exceptions où la solution la plus simple à trouver en ligne n’est plus la bonne à utiliser aujourd’hui. Vérifier le statut d’une cmdlet sur la documentation officielle avant de l’adopter dans un script destiné à durer est un réflexe qui s’applique bien au-delà du seul envoi d’email.

Dans la prochaine leçon, on élargit encore le terrain d’automatisation en intégrant PowerShell dans un pipeline CI/CD.