Concevoir des flux planifiés dans Power Automate — traitement de fin de mois, détermination des jours ouvrés et rappels en pratique

« À l’approche de la fin de chaque mois, quelqu’un du service comptable envoie un e-mail à tous les services : “la date limite de remboursement des notes de frais est le ◯. » « Chaque matin après le début du travail, quelqu’un ouvre la liste des commandes et vérifie à l’œil qu’il ne reste rien de non traité. » « Les documents dont la date limite de soumission est dépassée sont recoupés avec un registre et relancés un par un. » Même dans les entreprises qui ont déjà adopté Microsoft 365, ce type de travail où « une personne agit en observant un calendrier et un registre » reste étonnamment courant. Un oubli se transforme en incident, et pourtant le seul mécanisme pour éviter d’oublier repose sur la mémoire de la personne concernée et son calendrier Outlook.

L’exécution planifiée de Power Automate (le déclencheur Recurrence) permet d’automatiser ce type de tâche récurrente. Mais dès que l’on essaie de le mettre en place concrètement pour les pratiques métier japonaises, on se heurte immédiatement à trois obstacles : l’heure par défaut est en UTC (temps universel coordonné), la notion de « jour ouvré » n’existe pas nativement, et il faut écrire soi-même des expressions pour déterminer des notions comme « la fin du mois » ou « la clôture du 20 ». Cet article présente les spécifications et les pièges du déclencheur Recurrence, une boîte à outils de calculs de dates, la détermination des jours ouvrés à l’aide d’une liste maîtresse des jours fériés, la conception de rappels qui ne relancent pas à l’excès, et les risques opérationnels propres aux flux planifiés.

Par ailleurs, nous avons détaillé, dans un article distinct, la manière de traiter à l’échelle d’un système entier les exigences japonaises liées à l’ère de calendrier, aux jours fériés et aux dates de clôture : « Traitement de l’ère de calendrier japonaise, des jours fériés et des dates de clôture dans les applications métier — conception résiliente au changement d’ère, JapaneseCalendar et calcul des jours ouvrés en pratique ». Cet article-ci en est le volet pratique appliqué aux flux Power Automate.

1. L’essentiel à retenir

• L’heure du déclencheur Recurrence est traitée comme de l’UTC si aucun fuseau horaire n’est spécifié. On évite l’accident consistant à croire avoir réglé « tous les matins à 9h » alors que le flux se déclenche en réalité à 18h heure du Japon en sélectionnant « (UTC+09:00) Osaka, Sapporo, Tokyo » dans le champ de fuseau horaire et en indiquant explicitement l’heure de début.¹²
• « S’exécuter uniquement les jours ouvrés » peut se construire avec la fréquence « Semaine » associée à une sélection des jours (lundi à vendredi). Cependant, les jours fériés ne sont pas pris en compte. Une date fixe comme « le 20 de chaque mois » peut se construire avec une date/heure de début et la fréquence « Mois », mais on ne peut pas spécifier une date variable comme « le dernier jour de chaque mois » ou « le jour ouvré précédent si la date de clôture tombe un jour férié » : la solution pratique consiste donc à « s’exécuter tous les jours et vérifier par expression ».²
• utcNow() dans une expression est lui aussi toujours en UTC. Convertissez-le avec convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time') avant d’utiliser « aujourd’hui » en heure du Japon. Oubliez cette conversion dans un flux qui s’exécute vers 8h du matin, et « aujourd’hui » devient en réalité la veille.³⁴
• Il n’existe aucun mécanisme intégré pour reconnaître les jours fériés japonais. Il n’y a pas non plus de fonction pour cela dans la liste des fonctions d’expression,⁵ si bien que la pratique courante consiste à conserver sa propre liste maîtresse des jours fériés (une liste SharePoint, etc.), à faire déterminer par le flux, dès le départ, si « aujourd’hui est un jour ouvré », et à le terminer sinon. Le fichier CSV des jours fériés du Cabinet Office peut servir de source primaire pour cette liste maîtresse.⁶
• Concevez les rappels comme un message par personne, regroupé, plutôt qu’un message par enregistrement. Les actions d’opérations sur les données comme Filter array et Create HTML table permettent de construire cela de façon lisible, en évitant les boucles Apply to each imbriquées.⁷
• Un flux planifié est difficile à surveiller : on ne remarque pas facilement qu’il « ne s’exécute plus ». Concevez dès le départ des notifications d’échec et un enregistrement des exécutions, en partant du principe des spécifications suivantes : désactivation après 14 échecs consécutifs, désactivation après 90 jours sans déclenchement, et un historique d’exécution qui ne couvre que 28 jours par défaut.⁸⁹

2. Faire l’inventaire des tâches où « quelqu’un regarde un calendrier et agit »

La première chose à faire n’est pas de construire un flux, mais d’identifier chaque tâche « pilotée par l’observation d’un calendrier » et de déterminer si elle se prête ou non à une exécution planifiée.

Le tri repose sur trois critères : le critère peut-il être exprimé sous forme de données (un « dossier qui semble juste un peu suspect » ne peut pas être automatisé), la règle du jour d’exécution peut-elle être mise en mots, et peut-on récupérer le lendemain en cas d’échec (ce qui n’est pas possible relève du chapitre 8, terrain du développement).

Parmi ces critères, le deuxième constitue l’obstacle le plus difficile dans les pratiques métier japonaises. Même quelque chose d’aussi simple que « envoyer le rappel de clôture à la fin du mois » implique en réalité des ajustements humains du type « avancer au jour ouvré précédent si la fin de mois tombe un week-end ou un jour férié, et envoyer avant les congés lors d’une année de Golden Week ». Considérez que le travail consistant à formaliser ce savoir tacite en spécification écrite constitue le véritable cœur de la construction du flux. Construire le flux en laissant ce point flou, et l’on perd la confiance des utilisateurs, sous des formes comme « un e-mail de relance est parti un jour férié » ou « le rappel avant les congés est parti pendant les congés eux-mêmes ».

3. Bases et pièges du déclencheur Recurrence

Un flux cloud planifié se crée en tant que « flux cloud planifié », et l’on configure la fréquence et l’intervalle avec le déclencheur Recurrence.¹ La fréquence peut être choisie parmi secondes, minutes, heures, jours, semaines ou mois, avec un intervalle minimal de 60 secondes et maximal de 500 jours.⁸ La spécification elle-même est simple, mais c’est aussi un déclencheur riche en pièges.

Piège 1 : le fuseau horaire par défaut est UTC — « ça aurait dû être 9h, mais c’est parti à 18h »

C’est l’accident le plus fréquent. Si vous ne sélectionnez pas de fuseau horaire, l’heure de début du déclencheur Recurrence est interprétée au format UTC avec un Z final (YYYY-MM-DDThh:mm:ssZ). Sélectionnez le Japon dans le champ de fuseau horaire, et l’heure de début est traitée comme une heure locale dans ce fuseau (YYYY-MM-DDThh:mm:ss, sans Z).¹² Si vous construisez un « flux qui notifie tous les matins à 9h », la bonne approche est de régler le fuseau horaire sur « (UTC+09:00) Osaka, Sapporo, Tokyo » et l’heure de début sur 9:00.

Piège 2 : sans heure de début spécifiée, le flux se déclenche une fois dès l’enregistrement

Si vous ne spécifiez pas de date/heure de début, la première exécution se déclenche immédiatement au moment où vous enregistrez le flux.² Cela ne pose pas de problème en phase de test, mais cela peut se transformer en incident si vous enregistrez en fin de journée un flux comportant un e-mail de relance, et que tout le monde reçoit une relance sur-le-champ. Spécifiez toujours la date/heure de début.

De plus, si vous ne spécifiez pas « à ces heures/à ces minutes » dans les options avancées, chaque exécution après la première est calculée par rapport à l’heure de l’exécution précédente, si bien que l’accumulation de retards fait dériver progressivement l’heure d’exécution.² Pour un flux que vous souhaitez exécuter à heure fixe chaque jour, il est plus sûr de spécifier explicitement l’heure d’exécution en plus de la date/heure de début.

Piège 3 : « jours ouvrés uniquement » fonctionne, mais les options mensuelles détaillées sont limitées

Régler la fréquence sur « Semaine » permet de choisir les jours de la semaine (lundi à vendredi), et régler la fréquence sur « Jour » ou « Semaine » permet aussi de spécifier une heure précise (heure/minute). Autrement dit, « 9h les jours ouvrés uniquement » peut se construire avec les seuls réglages du déclencheur. En revanche, ces options détaillées ne sont disponibles que lorsque la fréquence est « Jour » ou « Semaine » — la fréquence « Mois » ne propose aucun champ pour spécifier une date comme « le 20 de chaque mois » ou « le dernier jour de chaque mois ».²

Cela dit, si la date est fixe et mensuelle, il n’est pas nécessaire d’exécuter le flux tous les jours. En réglant la date/heure de début sur la date visée (par exemple 9h00 le 20 du mois prochain) et la fréquence sur « Mois », l’exécution devient mensuelle, ancrée sur la date/heure de début, si bien que « 9h le 20 de chaque mois » peut se construire avec les seuls réglages du déclencheur.² Évitez de déclencher 365 fois par jour un flux qui n’a besoin de s’exécuter que 12 fois par mois en écartant la plupart des exécutions par une condition : cela rend l’historique d’exécution plus difficile à lire et gaspille inutilement le quota de requêtes.

La configuration « exécuter tous les jours et déterminer, par une expression en tête de flux, si aujourd’hui est la date visée » devient nécessaire pour un traitement mensuel dont la date elle-même varie. Des dates comme « le dernier jour de chaque mois » (du 28 au 31 selon le mois), « le jour ouvré précédent si le 20 tombe un week-end ou un jour férié », ou « le N-ième jour ouvré de chaque mois » ne peuvent pas être exprimées par le déclencheur. Nous traitons cette expression de détermination au chapitre suivant. Notez également que spécifier une date fixe de départ entre le 29 et le 31 exige de vérifier concrètement, par la mise en œuvre, ce qui se passe pour un mois où ce jour n’existe pas ; il est donc plus sûr de privilégier dès le départ l’approche « exécution quotidienne + vérification » pour tout traitement proche de la fin de mois.

Piège 4 : l’heure d’été — une précaution qui ne concerne que les sites à l’étranger

Si vous écrivez l’heure en UTC sans sélectionner de fuseau horaire, l’heure d’exécution se décale d’une heure à chaque changement saisonnier dans une région pratiquant l’heure d’été (DST). Si vous avez sélectionné un fuseau horaire, le planning suit le changement saisonnier et reste cohérent.¹⁰ Le Japon ne pratiquant pas l’heure d’été, il n’y a aucun impact réel pour un usage purement national, mais si le même flux gère aussi des notifications pour un site à l’étranger, il faut sélectionner explicitement le fuseau horaire de ce site.

Piège 5 : une expression écrite dans le déclencheur est figée au moment de l’enregistrement

Écrivez une expression comme utcNow() dans l’entrée d’un déclencheur, et cette valeur est calculée et figée au moment où vous enregistrez le flux. Elle n’est pas recalculée à chaque exécution.¹¹ Gardez à l’esprit que l’idée de placer une expression dans le déclencheur « parce que je veux que l’heure de début soit aujourd’hui » ne fonctionne tout simplement pas.

Piège 6 : le temps où le flux était désactivé n’est jamais rattrapé

Le déclencheur Recurrence ne traite pas rétroactivement, après réactivation, les échéances manquées pendant que le flux était désactivé — il reprend simplement au cycle suivant.¹⁰ Un incident du type « désactiver le flux de traitement de fin de mois pendant quelques jours pour une modification, et cela a justement recouvert la date d’exécution de fin de mois, si bien que le traitement du mois n’a tout simplement pas eu lieu » est tout à fait possible. Faites de la vérification de la prochaine date d’exécution planifiée une pratique standard avant de désactiver un flux planifié.

4. La boîte à outils du calcul de dates — déterminer la fin de mois, le début de mois et les dates de clôture avec des expressions

Les calculs de dates au sein d’un flux s’écrivent avec les mêmes expressions (fonctions) que celles partagées avec Logic Apps.⁵ Pour rappel, ce que renvoie utcNow() est toujours l’heure actuelle en UTC.¹² Il est donc conseillé de structurer le flux de façon à construire « aujourd’hui en heure du Japon » une seule fois au début du flux, le stocker dans une variable (ou un Compose), et le réutiliser ensuite : cela rend les expressions bien plus lisibles.

convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time', 'yyyy-MM-dd')

convertTimeZone(horodatage, source, destination, format) est la fonction de conversion de fuseau horaire,¹³ et le nom de fuseau horaire utilise celui de la liste des fuseaux horaires de Windows. Celui du Japon est « Tokyo Standard Time ».⁴ Si vous préférez ne pas écrire d’expression, il existe aussi une action « Convertir le fuseau horaire » qui fait la même chose.¹³

La raison pour laquelle cette conversion est indispensable tient à l’écart de 9 heures entre l’UTC et l’heure du Japon. Jusqu’à 9h du matin heure du Japon, il s’agit encore de la veille en UTC. Écrivez formatDateTime(utcNow(), 'yyyy-MM-dd') dans un flux qui s’exécute à 8h, et le « aujourd’hui » obtenu correspond en réalité à la date de la veille. Comme ce décalage de date apparaît ou non selon l’heure d’exécution, il passe facilement inaperçu lors des tests, et se révèle en production sous des formes comme « un traitement censé être du début de mois s’est aussi exécuté le tout dernier jour du mois ».

Voici un résumé des modèles de détermination une fois construit « aujourd’hui en heure du Japon » (désigné ci-après par Aujourd'hui).

addDays, addToTime, startOfMonth, formatDateTime et dayOfWeek sont toutes des fonctions définies dans la référence d’expressions commune à Logic Apps et Power Automate.⁵ Les expressions combinées du tableau ci-dessus sont un modèle d’implémentation propre à l’auteur : lors de leur adoption, testez-les avec des dates couvrant la fin de mois, le début de mois et une année bissextile (29 février) avant de les mettre en production. Nous avons écrit à quel point un bug de date qui ne se déclenche qu’à une date précise peut être redoutable, et comment choisir les dates à tester au préalable, au chapitre 4 de l’article sur l’ère de calendrier japonaise, les jours fériés et les dates de clôture.

5. Déterminer les jours ouvrés — conserver les jours fériés dans une liste maîtresse

Il n’existe aucune détermination des jours fériés intégrée

Pour le répéter, Power Automate n’a aucune fonctionnalité intégrée pour reconnaître les jours fériés japonais. Le réglage du jour de la semaine du déclencheur Recurrence ne regarde littéralement que le jour de la semaine, et la liste des fonctions d’expression ne va pas au-delà de l’arithmétique de dates, du formatage et de la conversion de fuseau horaire — il n’existe aucune fonction qui renvoie « ce jour est-il un jour férié ». Nous avons expliqué en détail, au chapitre 3 de l’article sur l’ère de calendrier japonaise, les jours fériés et les dates de clôture, pourquoi calculer les jours fériés par une formule est fondamentalement impossible en principe (les équinoxes ne sont finalisés que l’année précédente, et les jours fériés eux-mêmes se déplacent en raison de modifications législatives ou de lois de mesures spéciales). La conclusion reste la même ici : la bonne réponse est de conserver les jours fériés sous forme de données (une liste maîtresse) accompagnées d’une procédure de mise à jour.

La façon la plus simple de faire cela dans Power Automate consiste à créer une « liste maîtresse des jours fériés » sous forme de liste SharePoint (une colonne de date plus une colonne de nom). Comme source primaire, vous pouvez utiliser le fichier CSV des dates et noms de jours fériés, de l’an Showa 30 (1955) jusqu’à l’année suivante, publié par le Cabinet Office (les jours fériés de substitution y figurent également comme lignes).⁶ Seules les dates finalisées étant publiées, la conception doit s’étendre jusqu’à inscrire, une fois par an, dans le calendrier métier, la tâche d’importer les dates de l’année suivante dans la liste maîtresse. Oublier cette mise à jour se traduit directement par un dysfonctionnement, sous la forme d’une notification de relance envoyée un jour férié de l’année suivante. Par ailleurs, conservez les jours de fermeture de l’entreprise, comme les congés d’été ou l’anniversaire de fondation, dans une liste séparée plutôt que de les mélanger avec la liste maîtresse des jours fériés — car « la vérification d’une échéance de virement bancaire ne doit regarder que les jours fériés » alors que « une relance interne doit aussi tenir compte des jours de fermeture de l’entreprise » : l’ensemble de jours de repos à consulter diffère selon l’usage.

Le « garde-fou des jours ouvrés » en tête de flux

Pour un flux que vous souhaitez exécuter uniquement les jours ouvrés, placez la vérification suivante en tête de flux, en plus du réglage du jour de la semaine de Recurrence (lundi à vendredi).

1. Construire « aujourd’hui en heure du Japon » (chapitre 4)
2. Exécuter « Get items » (obtenir des éléments) de SharePoint sur la liste maîtresse des jours fériés, et rechercher la date d’aujourd’hui avec une requête de filtrage du type HolidayDate eq 'Aujourd'hui'¹⁴
3. Effectuer la même recherche sur la liste des jours de fermeture de l’entreprise
4. En cas d’au moins un résultat, arrêter l’exécution avec l’action « Terminate »

Terminate est l’action qui arrête l’exécution d’un flux sur-le-champ et le termine dans l’état spécifié (Succeeded/Failed/Cancelled) — elle ne peut pas être placée à l’intérieur d’une boucle Apply to each ou Do until.¹⁵ Régler l’état sur « Cancelled » à cet endroit permet de distinguer d’un coup d’œil, dans l’historique d’exécution, « un jour ignoré parce que ce n’était pas un jour ouvré » d’« un jour où le traitement s’est réellement exécuté ». Cela facilite grandement les investigations ultérieures, comparé à tout regrouper sous « Succeeded ».

« Avancer au jour ouvré précédent » et « N jours ouvrés avant »

Ce dont un rappel de clôture de fin de mois a réellement besoin, ce n’est pas « chaque fin de mois », mais « le jour ouvré précédent si la fin de mois est un jour de repos ». Cela peut s’exprimer, dans un flux qui s’exécute chaque jour ouvré, en vérifiant que « aujourd’hui est un jour ouvré, et il n’existe pas un seul jour ouvré entre demain et la fin du mois ». En implémentation, on parcourt dans l’ordre les dates de demain jusqu’à la date de fin de mois (expression du chapitre 4), et dès qu’on trouve un jour qui n’est ni un week-end ni présent dans la liste maîtresse des jours fériés, on conclut que « aujourd’hui n’est pas le dernier jour ouvré » et l’on sort de la boucle.

N jours ouvrés avant, comme dans « relancer 3 jours ouvrés avant la date d’échéance de paiement », suit la même logique de reformulation. On remplace « quand on arrive à N jours ouvrés avant l’échéance » par « s’exécuter chaque jour ouvré, compter le nombre de jours ouvrés entre aujourd’hui et l’échéance, et vérifier s’il correspond à N ». Compter les jours ouvrés consiste simplement à compter les jours qui ne sont « ni un week-end, ni dans la liste maîtresse des jours fériés, ni dans la liste des jours de fermeture de l’entreprise ». Cela dit, un traitement en boucle de flux qui compte les dates un jour à la fois se transforme, dès que le nombre de dossiers concernés dépasse quelques centaines, en une boucle du nombre de dossiers multiplié par le nombre de jours, ce qui gonfle à la fois le temps d’exécution et le nombre d’appels d’API. Une fois cette échelle atteinte, il est plus sain de sortir le calcul des jours ouvrés du flux (une table de jours ouvrés dans une base de données, ou une petite API), ou de le traiter comme relevant du développement, au chapitre 8.

6. Concevoir les rappels et relances — un seul message par responsable, regroupé

Prérequis : le registre doit déjà être des données

On ne peut automatiser la relance des éléments en retard que si « ce dont il s’agit, qui en est responsable, et quand c’est dû » peut être récupéré sous forme de données. Si votre registre est encore un fichier Excel qui circule en pièce jointe d’e-mail sur un dossier partagé, envisagez d’abord de le migrer vers une liste SharePoint. Ce qui suit suppose une liste SharePoint comportant les colonnes « Date d’échéance », « Statut » et « Responsable ».

Filtrer dès l’extraction

Plutôt que de récupérer tous les éléments de la liste puis de brancher sur une condition à l’intérieur du flux, filtrez les éléments en retard côté serveur avec la requête de filtrage (un filtre OData) de Get items.¹⁴

DueDate lt '2026-07-18' and Status ne 'Terminé'

Intégrez dans la partie date l’expression « aujourd’hui en heure du Japon » construite au chapitre 4. Notez que les noms de colonnes de la requête de filtrage doivent être écrits avec les noms internes de SharePoint, et non les noms d’affichage visibles à l’écran, et que seuls 100 éléments sont renvoyés par défaut : une liste comportant un grand nombre d’éléments nécessite soit de spécifier une limite (Top Count), soit de configurer la pagination.¹⁴

Éviter l’enfer du Apply to each — comment regrouper en un seul message

Parcourir directement les résultats d’extraction avec Apply to each et envoyer un e-mail pour chacun conduit, si le responsable A a 10 éléments non traités, à ce qu’il reçoive 10 e-mails chaque matin. Poursuivez cela quelques semaines, et les notifications finissent immanquablement par ne plus être lues, tuant le mécanisme de rappel lui-même. La règle est de regrouper les notifications en un seul message par responsable. Avec les actions d’opérations sur les données, on peut construire cela selon le déroulé suivant.⁷

1. Utiliser Select pour construire, à partir des résultats d’extraction, un tableau des adresses e-mail des responsables, puis utiliser union() pour supprimer les doublons et obtenir une « liste des responsables à notifier aujourd’hui ».⁵
2. Parcourir cette liste de responsables avec Apply to each, et à l’intérieur, utiliser Filter array pour extraire « uniquement les éléments de ce responsable ».
3. Utiliser Create HTML table pour les mettre en forme dans un tableau (objet, date d’échéance, statut), l’intégrer dans le corps d’un seul e-mail (ou message Teams), et n’envoyer que ce message unique (activer l’affichage HTML pour le cas de l’e-mail⁷).

Voici à quoi ressemble l’ensemble.

flowchart TD
    Rec[Déclencheur Recurrence<br/>Jours ouvrés, 9h00, fuseau horaire : Osaka, Sapporo, Tokyo] --> Today[Créer la date du jour en heure du Japon<br/>convertTimeZone]
    Today --> Hol{Aujourd'hui figure-t-il dans la liste des<br/>jours fériés ou de fermeture de l'entreprise ?}
    Hol -- Oui --> Term[Terminate, Cancelled<br/>Fin car ce n'est pas un jour ouvré]
    Hol -- Non --> Get[Get items<br/>Extraire les éléments en retard et non terminés]
    Get --> Any{Des éléments trouvés ?}
    Any -- Non --> End([Fin, aucune notification])
    Any -- Oui --> Sel[Créer la liste des responsables avec Select<br/>Dédupliquer avec union]
    Sel --> Each[Boucle par responsable]
    Each --> Filter[Filter array<br/>Extraire uniquement les éléments de ce responsable]
    Filter --> Table[Mettre en forme dans un tableau avec Create HTML table]
    Table --> Send[Envoyer une seule notification au responsable<br/>Teams ou Outlook]
    Send --> Log[Enregistrer le résultat de l'exécution dans une liste de journalisation]

Choisir entre Teams et Outlook

Choisissez le canal de notification en fonction de la nature du message.

La répartition classique consiste à utiliser Teams pour les résumés quotidiens, et l’e-mail pour les rappels formels avant clôture et les relances de retard. Envoyer le même contenu sur les deux canaux n’est pas recommandé, car cela ne fait qu’augmenter le volume total de notifications.

Concevoir sans trop relancer

Le plus grand danger de l’automatisation des rappels est d’en envoyer tellement qu’ils finissent tous ignorés. La relance manuelle possède un frein naturel — c’est gênant à dire, donc on limite spontanément la fréquence — mais un flux n’en a aucun. Il faut intégrer ce frein dans la conception.

• Concevoir le volume total. Tous les matins, tout le monde, tous les éléments est le pire scénario. Réduisez les conditions d’envoi — par exemple, n’envoyer quotidiennement que les éléments dus aujourd’hui ou en retard, et limiter les rappels préalables à deux occasions seulement : 3 jours ouvrés avant, et la veille.
• Ajouter des paliers. Notifier d’abord uniquement la personne concernée, puis ajouter le supérieur en destinataire une fois le retard poursuivi pendant N jours ouvrés — répartissez ainsi l’escalade. Envoyer tout au supérieur dès le départ transforme la notification en simple bruit.
• Prévoir un moyen d’arrêter. Offrez toujours une sortie où les notifications s’arrêtent dès le lendemain une fois que le responsable passe la colonne de statut de la liste à « Terminé ». Si les rapports d’achèvement restent de simples réponses par e-mail, le flux continue de relancer, et le responsable finit par détester le flux.
• Garder fiable l’idée que « pas de notification = pas de problème ». Cela ne tient que combiné avec la surveillance abordée au chapitre suivant.

7. Précautions opérationnelles — un flux planifié dont on ne remarque pas l’arrêt

Avec un flux déclenché par un événement, le métier remarque « j’ai soumis la demande et ça n’a pas fonctionné ». Un flux planifié n’a pas ce détecteur. Si le rappel de fin de mois s’est arrêté, la clôture prend simplement du retard sans que personne ne dise rien. Basez votre conception opérationnelle sur les spécifications suivantes.

• Il existe des conditions qui désactivent automatiquement un flux. Un flux dont le déclencheur ou les actions échouent en continu est désactivé au bout de 14 jours, tout comme un flux qui subit un throttling continu. De plus, un flux jamais déclenché pendant 90 jours peut être désactivé (cela ne s’applique pas à un flux dont le propriétaire dispose d’une licence premium ou d’une licence de capacité telle que Process ; le propriétaire et les copropriétaires sont notifiés 30 jours avant la désactivation, et il est possible de le réactiver pour le maintenir).⁸ Si vous construisez un « flux qui ne s’exécute qu’une fois par trimestre », attention à cette règle des 90 jours.
• Par défaut, seuls 28 jours d’historique d’exécution sont visibles.⁹ Pour un flux mensuel, ce calcul revient à ne pouvoir vérifier que la toute dernière exécution. Ajouter, en fin de flux, une étape qui ajoute une ligne — « date/heure d’exécution, nombre d’éléments traités, résultat » — à une liste SharePoint de journalisation permet de vérifier « est-ce que ça a bien fonctionné le mois dernier » indépendamment de l’expiration de l’historique. C’est pour cela que l’étape d’enregistrement du journal se trouve à la fin du schéma du chapitre 6.
• Donner au flux lui-même un moyen de détecter les échecs. Sans une branche qui notifie un administrateur en cas d’échec (une action configurée avec la condition d’exécution « en cas d’échec »), personne ne remarque un échec pendant les 14 jours qui précèdent la désactivation. Nous détaillons la construction de la gestion des erreurs et des tentatives de nouvelle exécution dans « Conception de la gestion des erreurs et des tentatives dans Power Automate ».
• Le départ ou la mutation du propriétaire arrête tout le planning. Un flux déclenché par Recurrence s’exécute sur la connexion du créateur du flux.¹¹ Si le compte du propriétaire est désactivé, la connexion se rompt, le flux commence à échouer, puis finit par se désactiver. Terminez la configuration des copropriétaires et l’inventaire des connexions dès le premier jour de mise en production.¹⁶ Les aspects pratiques de la transmission sont détaillés dans « Prévenir la dépendance à une seule personne dans Power Automate — propriétaire, connexions, transmission ».
• Le temps passé désactivé n’est jamais rattrapé (piège 6 du chapitre 3). Lorsque vous désactivez un flux pour une modification ou une gestion d’incident, vérifiez la prochaine date d’exécution planifiée, et décidez à l’avance d’un exécution manuelle de secours pour les cas où vous auriez recouvert cette date.¹⁰

8. Jusqu’où aller avec Power Automate ?

L’exécution planifiée est un excellent point d’entrée vers l’automatisation, mais transformer en flux tout ce qui « s’exécute périodiquement » est dangereux. Voici un repère approximatif pour tracer la limite.

Intuitivement, la limite se situe à peu près ici : Power Automate jusqu’à « faire remarquer », le développement pour « finaliser » (réécrire les données du système central). Nous avons vu, plus d’une fois, des cas où tenter de construire le traitement de clôture lui-même comme un flux se transformait en une explosion de branches ; les choses se sont généralement stabilisées en revenant à une répartition où « la clôture elle-même s’exécute sur le système existant ou via un développement sur mesure, et seul le rappel évitant l’oubli de clôturer reste un flux ». Par ailleurs, pour un traitement récurrent qui se termine entièrement à l’intérieur d’un serveur sans passer par le cloud, PowerShell et le Planificateur de tâches peuvent parfois s’avérer plus simples et plus faciles à maintenir. Le choix entre les deux est traité dans « Choisir entre Power Automate et PowerShell/le Planificateur de tâches ».

9. Conclusion

La véritable substance de la conception d’un flux planifié réside moins dans la configuration du déclencheur Recurrence lui-même que dans ce qui se trouve en amont et en aval. En amont, il s’agit de mettre en spécification explicite le savoir tacite d’« agir en observant un calendrier » : que se passe-t-il si la fin de mois tombe un jour férié, qui inscrit les jours fériés dans la liste maîtresse et quand. Un flux construit sans avoir tranché ces points finira tôt ou tard par mal fonctionner face au calendrier japonais. En aval, il s’agit de la pratique opérationnelle permettant de remarquer un arrêt : un historique d’exécution de 28 jours, les différentes conditions de désactivation automatique, un planning qui s’arrête quand le propriétaire part. Intégrez dès le départ des notifications d’échec et un journal d’exécution, en partant du principe qu’un flux planifié s’arrête silencieusement.

Les points techniques se résument à trois : rendre le fuseau horaire explicite (le défaut est l’UTC), convertir les dates en heure du Japon avant de les vérifier, et conserver les jours fériés dans une liste maîtresse et rejeter les jours non ouvrés avec un garde-fou en tête de flux. Une fois ces trois points maîtrisés, regroupez les notifications par responsable, et donnez aux relances à la fois des paliers et une sortie. Faites tout cela, et une part considérable du travail « où une personne agit en observant un calendrier » peut être remplacée par un flux planifié en qui l’on peut avoir confiance. Et lorsque vous vous surprendrez à vouloir vous engager dans un traitement de « finalisation » — comme le processus de clôture ou les traitements batch du système central — ce sera le moment d’envisager de basculer vers le développement.

Articles connexes

• Automatiser les processus métier avec Power Automate — flux cloud, flux de bureau et gestion robuste des erreurs
• Traitement de l’ère de calendrier japonaise, des jours fériés et des dates de clôture dans les applications métier — conception résiliente au changement d’ère, JapaneseCalendar et calcul des jours ouvrés en pratique
• Conception de la gestion des erreurs et des tentatives dans Power Automate
• Prévenir la dépendance à une seule personne dans Power Automate — propriétaire, connexions, transmission
• Choisir entre Power Automate et PowerShell/le Planificateur de tâches

Domaines de conseil associés

Komura Software LLC intervient aussi bien sur la revue de conception des traitements planifiés et des rappels réalisés avec Power Automate que sur le développement des traitements de clôture, des calculs de jours ouvrés et des batchs d’intégration avec les systèmes centraux qui dépassent ce qu’un flux peut gérer.

• Conseil technique et revue de conception
• Développement d’applications Windows
• Contact

Liens de référence

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Comment faire fonctionner un flux planifié Power Automate tous les matins à 9h, heure du Japon ?

Dans le champ de fuseau horaire du déclencheur Recurrence, sélectionnez « (UTC+09:00) Osaka, Sapporo, Tokyo » et indiquez l'heure de début. Si vous ne précisez pas de fuseau horaire, l'heure de début est traitée comme une heure UTC (temps universel coordonné) suivie d'un Z final ; en pensant régler « 9:00 », le flux se déclenchera en réalité à 18h heure du Japon. Par ailleurs, utcNow() dans les expressions renvoie lui aussi toujours l'heure UTC : lorsque vous utilisez « la date d'aujourd'hui » dans un flux, convertissez-la d'abord en heure du Japon, par exemple avec convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time', 'yyyy-MM-dd').

Power Automate dispose-t-il d'une fonctionnalité permettant de reconnaître les jours fériés japonais ?

Aucune fonctionnalité intégrée n'existe pour cela. Le réglage du jour de la semaine du déclencheur Recurrence permet une exécution « jours ouvrés uniquement », mais il ne tient pas compte des jours fériés, et aucune fonction de la liste des expressions ne renvoie non plus les jours fériés. En pratique, on constitue soi-même une liste maîtresse des dates de jours fériés (par exemple une liste SharePoint), on recherche en tête de flux si « la date d'aujourd'hui figure dans cette liste », et on termine le flux si ce n'est pas un jour ouvré. Pour mettre à jour cette liste, le fichier CSV des jours fériés publié par le Cabinet Office peut servir de source primaire.

Peut-on créer un flux qui ne s'exécute que le dernier jour ouvré de chaque mois ?

Pour une date fixe comme « le 20 de chaque mois », en réglant la date/heure de début sur la date visée et la fréquence sur « Mois », on obtient une exécution le même jour et à la même heure chaque mois, ancrée sur la date/heure de début. En revanche, le déclencheur Recurrence ne propose aucune option pour indiquer directement « le dernier jour de chaque mois », et les réglages détaillés de jour de la semaine ou d'heure ne sont disponibles que lorsque la fréquence est « Jour » ou « Semaine ». Pour un traitement dont la date varie, comme la fin de mois, on construit un flux qui s'exécute tous les jours (ou tous les jours ouvrés), on détermine en tête de flux, par une expression, si « aujourd'hui est la fin du mois » ou « aujourd'hui est un jour ouvré », et on termine le flux les jours où la condition n'est pas remplie. La détermination de la fin de mois peut s'écrire avec l'expression « aujourd'hui est la fin du mois si le mois d'aujourd'hui diffère de celui de demain ». « Exécuter le jour ouvré précédent si la fin de mois tombe un week-end ou un jour férié » s'exprime de la même façon, en ajoutant à cette structure une vérification de la liste maîtresse des jours fériés.

Mon flux planifié s'est désactivé sans que je m'en rende compte. Pourquoi ?

Power Automate comporte plusieurs conditions qui désactivent automatiquement un flux. Un flux dont le déclencheur ou les actions échouent en continu est désactivé au bout de 14 jours, tout comme un flux qui subit un throttling (dépassement de limite) continu. Par ailleurs, un flux jamais déclenché pendant 90 jours peut être désactivé (cela ne s'applique pas si le propriétaire dispose d'une licence premium ou d'une licence de capacité, et le propriétaire ainsi que les copropriétaires sont notifiés 30 jours avant la désactivation). Comme personne ne remarque facilement l'arrêt d'un flux planifié, il est essentiel d'intégrer dès le départ des notifications d'échec et un enregistrement des exécutions.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.