Des approbations Power Automate soudainement silencieuses ? Un flux SharePoint marqué « Réussi », mais des e‑mails absents ou livrés avec plusieurs jours de retard. Voici un diagnostic éprouvé, la cause racine observée (pare‑feu) et un plan d’action durable.
Vue d’ensemble de la question
Une organisation utilisait depuis près d’un an un flux Power Automate déclenché à la soumission d’un élément dans une liste SharePoint. Ce flux démarre une demande d’approbation adressée à trois personnes. Depuis quelque temps, bien que chaque exécution s’affiche « Réussi » dans l’historique, les symptômes suivants ont été constatés :
- aucun des approbateurs, ou seulement un ou deux, reçoivent l’e‑mail de demande d’approbation ;
- certains messages arrivent avec plusieurs jours de retard.
Les tests habituels (recréation du flux, vérification du connecteur Outlook, consultation du dossier « Courrier indésirable » et contrôle d’incidents Exchange Online) n’ont révélé aucune erreur.
Réponse et solution (résumé exécutif)
Diagnostic final : une mise à jour du pare‑feu de l’organisation bloquait les e‑mails émis par le service d’approbations Power Automate. Après ajustement de la règle de sécurité :
- tous les approbateurs ont de nouveau reçu les notifications immédiatement ;
- aucune modification du flux n’a été nécessaire.
Pourquoi un flux peut réussir alors que l’e‑mail n’arrive pas
Le connecteur d’approbations crée et enregistre la demande côté service Power Automate. À ce stade, l’action dans le flux est considérée comme réussie. La distribution par e‑mail est ensuite gérée par un pipeline de messagerie distinct (file d’attente + livraison SMTP via les infrastructures Microsoft et, parfois, via des relais régionaux). Si un pare‑feu ou une passerelle anti‑spam en aval filtre, retarde ou rejette ces e‑mails, le flux reste vert car le problème survient après l’action d’approbation.
Plan de diagnostic détaillé
Le cheminement ci‑dessous vous permet de confirmer rapidement si le souci provient du flux, d’Exchange, d’Outlook ou d’un filtre réseau/sécurité.
Vérifications rapides à forte valeur
| Étape de vérification | Pourquoi c’est utile | Action recommandée |
|---|---|---|
| Contrôler l’historique des exécutions | Confirmer qu’il n’y a pas d’échec dans Power Automate | Onglet Historique d’exécution du flux |
| Vérifier l’arrivée des e‑mails côté serveur | Éliminer un problème Exchange/Outlook local | Ouvrir Outlook Web, dossiers Boîte de réception et Courrier indésirable |
| Consulter la santé des services Microsoft 365 | Détecter un incident global Exchange Online ou Approvals | Centre d’administration → Santé |
| Isoler l’envoi SMTP | Identifier un filtre de sécurité (pare‑feu, passerelle mail) | Demander à l’équipe IT les journaux du pare‑feu/passerelle |
| Ouvrir un ticket Power Platform | Escalade si aucune cause locale n’est trouvée | Centre d’administration Power Platform → Help + support |
Approche pas‑à‑pas, avec signaux d’orientation
- Anatomie d’une exécution « Réussie »
Dans l’historique, ouvrez une exécution problématique et vérifiez :- l’action « Créer une approbation » ou « Démarrer et attendre une approbation » est en vert (statut Succeeded) ;
- les sorties (Outputs) indiquent un identifiant d’approbation et un ou plusieurs destinataires ;
- aucune branche d’erreur n’est empruntée.
- Contrôle côté boîte aux lettres
Demandez à chaque approbateur de vérifier via Outlook Web (pour éliminer un add‑in local) : Boîte de réception, Courrier indésirable, Règles de boîte de réception, et Rechercher globalement par objet du message (ex. « Nouvelle demande d’approbation »).
Interprétation : si aucun e‑mail n’apparaît alors que le flux est vert, suspectez une filtration serveur/réseau. - Traçage Exchange
Exécutez un message trace sur une plage d’horodatages où les approbations ont été envoyées. Relevez pour chaque destinataire : état (Delivered, Quarantined, Deferred, Expanded, Failed), code SMTP, et raison (Spam, Policy, Connection filtering, etc.).
Interprétation : un statut Deferred répété ou un Failed depuis une adresse IP Microsoft est compatible avec un blocage extérieur (pare‑feu/passerelle). - Inspection des journaux pare‑feu/passerelle
Ciblez les tranches horaires des envois et filtrez sur : ports 25/587, TLS, domaines d’expéditeur liés à Power Automate/Approvals, et adresses IP source appartenant à Microsoft 365. Recherchez des événements connection reset, policy drop, greylisting ou des refus de négociation TLS. Interprétation : si vous voyez des connexions refusées depuis les plages Microsoft, une règle récente est probablement en cause. - Contournement contrôlé pour confirmer l’hypothèse
En coordination avec la sécurité, créez une règle temporaire « autoriser » pour les messages correspondant aux signatures d’expéditeur du service d’approbations (domaine, DKIM, certificat TLS émetteur Microsoft). Relancez un test. Si les e‑mails arrivent immédiatement, la cause racine est confirmée.
Ce qui a causé l’incident dans le cas étudié
Mise à jour d’une politique réseau. Une règle de pare‑feu introduite lors d’une mise à jour de la politique de sécurité a commencé à bloquer certaines routes SMTP sortantes provenant du service d’approbations. La règle ne visait pas explicitement Power Automate, mais un pattern réseau jugé « non approuvé ». Le flux restait vert, mais la notification par e‑mail n’atteignait plus tous les approbateurs, ou arrivait après plusieurs jours par ré‑essais.
Correctifs côté sécurité
Pour éviter un nouvel incident sans affaiblir la posture de sécurité :
- Autoriser explicitement les expéditeurs et signaux d’authentification Microsoft : s’appuyer sur la combinaison SPF, DKIM et DMARC valides, plutôt que sur une liste d’IP figées susceptibles d’évoluer.
- Préférer des critères robustes : validation du certificat TLS présenté par les émetteurs Microsoft, vérification de l’en‑tête d’authentification (Authentication‑Results) et du domaine signé DKIM.
- Éviter les exceptions trop larges : ne pas désactiver globalement l’antispam. Créer des allow rules étroites conditionnées aux contrôles d’authentification réussis.
- Documenter dans le référentiel sécurité les domaines et services utilisés par Power Automate/Exchange et leur cycle de revue.
Exemple de logique de règle (pseudo‑politique)
SI protocole = SMTP ET TLS = requis ET certificat émetteur = Microsoft* ET Authentication-Results (SPF=pass OU DKIM=pass) ET DMARC=pass ET domaine expéditeur = service d'approbations/notifications* ALORS Autoriser (skip greylisting, pas de délai) SINON Appliquer politiques antispam habituelles
Remarque : adaptez la terminologie à votre pare‑feu/passerelle. L’objectif est d’autoriser un trafic légitime authentifié plutôt que de forcer un passage aveugle.
Renforcer la résilience côté Power Automate
Même si la cause racine était réseau, quelques améliorations rendent votre processus plus robuste.
Ajouter un canal de secours
- Notification Teams en parallèle de l’e‑mail (message de canal, chat, ou carte Adaptive Cards) afin que l’approbateur soit alerté même si sa messagerie filtre l’e‑mail.
- Rappels programmés : si aucune réponse n’est reçue dans X heures, renvoyer la notification (e‑mail/Teams) et/ou notifier un groupe de supervision.
- Journalisation : écrire chaque demande et chaque relance dans SharePoint/Dataverse avec horodatage pour faciliter le support.
Patron de flux recommandé
- Déclencheur : « Lors de la création d’un élément dans SharePoint ».
- Étape A : « Créer une approbation » (ou « Démarrer et attendre une approbation » si vous voulez bloquer).
- Étape B : « Notifier approbateurs via e‑mail et Teams » (branches parallèles).
- Étape C : « Jalon de contrôle » (Delay jusqu’à T minutes, puis vérifier l’état de l’approbation).
- Étape D : si pas de réponse, « Rappel » et enregistrement d’un événement d’alerte.
- Étape E : en cas de refus/expiration, escalade vers un responsable.
Guide de test après correctif
Une fois la règle pare‑feu ajustée, exécutez cette batterie de tests pour valider le retour à la normale.
| Test | Attendu | Ce qu’il faut vérifier |
|---|---|---|
| Soumission SharePoint avec 3 approbateurs | 3 e‑mails reçus < 1 min | Horodatages d’émission vs réception, dossiers Inbox |
| Relance automatique à +2 h | Rappel reçu sur chaque canal | Historique du flux, absence d’erreurs de notification |
| Réponse depuis Teams | Statut de l’approbation mis à jour | Traçabilité dans SharePoint/Dataverse |
| Message trace Exchange | Delivered (pas de Deferred/Quarantine) | Courbes de délais stables et faibles |
Informations complémentaires utiles
| Étape de vérification | Pourquoi c’est utile | Action recommandée |
|---|---|---|
| 1. Contrôler l’historique des exécutions | Confirmer qu’il n’y a pas d’échec dans Power Automate | Onglet Historique d’exécution du flux |
| 2. Vérifier l’arrivée des e‑mails côté serveur | Éliminer un problème Exchange/Outlook local | Ouvrir Outlook Web, dossiers Boîte de réception et Courrier indésirable |
| 3. Consulter la santé des services Microsoft 365 | Détecter un incident global Exchange Online ou Approvals | Centre d’administration → Santé |
| 4. Isoler l’envoi SMTP | Identifier un filtre de sécurité (pare‑feu, passerelle mail) | Demander à l’équipe IT les journaux du pare‑feu/passerelle |
| 5. Ouvrir un ticket Power Platform | Escalade si aucune cause locale n’est trouvée | Centre d’administration Power Platform → Help + support |
Bonnes pratiques pour éviter les interruptions
- Ajouter un canal de secours (notification Teams ou Adaptive Card) si l’e‑mail échoue.
- Documenter les plages d’adresses IP et domaines utilisés par Power Automate/Exchange et les inclure dans la liste blanche du pare‑feu.
- Mettre en place une alerte dans le flux : si la réponse d’approbation n’est pas reçue dans X heures, envoyer un rappel ou créer une tâche Teams.
- Créer un tableau de bord (SharePoint/Power BI) pour suivre les délais d’acheminement des notifications et le taux de réponses en première tentative.
Tableau de tri des causes probables
| Symptôme | Probable cause | Comment confirmer | Correctif |
|---|---|---|---|
| Flux vert, aucun e‑mail chez personne | Filtrage réseau/passerelle | Journal pare‑feu, message trace Deferred/Failed | Règle d’autorisation ciblée + tests |
| Flux vert, e‑mail chez 1/3 approbateurs | Filtre/Quota/Boîte individuelle | Règles Outlook, boîte pleine, quarantaine | Nettoyage boîte, règle d’exception sécurisée |
| Retard de plusieurs jours | Greylisting ou ré‑essais SMTP | Logs passerelle, files d’attente | Lever le greylisting pour expéditeurs authentifiés |
| Certains flux OK, d’autres non | Modèles d’e‑mail/expéditeurs différents | Comparer en‑têtes (SPF/DKIM/DMARC) | Aligner l’authentification & la règle pare‑feu |
Checklist opérationnelle
- Le flux Approvals s’exécute en succès avec des sorties cohérentes.
- Les approbateurs reçoivent tous la notification e‑mail en < 60 secondes.
- La règle pare‑feu/passerelle inclut une condition sur SPF/DKIM/DMARC ou le certificat TLS Microsoft.
- Un canal de secours (Teams/Adaptive Card) est en place.
- Un rappel automatique et un mécanisme d’escalade sont configurés.
- Un message trace hebdomadaire est revu pour détecter les anomalies.
FAQ rapide
Faut‑il réécrire le flux ?
Non, si la cause est réseau. Le flux n’a pas besoin d’être modifié : c’est la livraison du message qui a été bloquée.
Pourquoi un seul approbateur reçoit‑il l’e‑mail ?
Les boîtes peuvent être soumises à des politiques différentes (règles personnelles, Safe Sender, quotas). Vérifiez au cas par cas, mais gardez l’hypothèse d’un filtrage en amont si le phénomène est large.
Comment réduire le risque de retard ?
Évitez le greylisting pour les expéditeurs authentifiés, et vérifiez que la passerelle n’impose pas un throttling agressif sur les domaines Microsoft.
Est‑ce un incident Microsoft 365 ?
Dans ce cas réel, non. Les services étaient sains. Le blocage provenait d’une nouvelle règle interne.
Procédure d’isolement technique (annexe)
- Comparer deux envois : un e‑mail issu d’« Envoyer un e‑mail (V2) » et un e‑mail issu d’« Approvals ». Si le premier passe systématiquement et le second non, la signature d’expéditeur Approvals est la cible du filtre.
- Analyser un en‑tête complet : relever Authentication‑Results, Received, From/Return‑Path. Chercher des mentions de réputation, de différé (4xx) ou de rejet (5xx).
- Observer les certificats TLS présentés lors des sessions SMTP depuis Microsoft 365 et valider qu’ils sont acceptés par la passerelle.
Conclusion
Un flux d’approbation Power Automate peut fonctionner parfaitement tout en devenant silencieux si la chaîne de livraison e‑mail est interrompue en aval. Dans l’incident étudié, la mise à jour d’une politique de pare‑feu a bloqué les e‑mails du service d’approbations, provoquant des notifications manquantes ou tardives. La levée ciblée du blocage a rétabli immédiatement la situation, sans toucher au flux. En consolidant la configuration sécurité (règles d’autorisation basées sur l’authentification du message) et en ajoutant un canal de secours (Teams/Adaptive Cards), vous rendez vos approbations à la fois fiables et résilientes.