Choisir entre Power Automate, PowerShell et le Planificateur de tâches — connecter les outils d'automatisation là où ils excellent, sans les mélanger

« Sur le serveur de la comptabilité, un traitement de nuit en PowerShell tourne depuis près de dix ans. Récemment, en parallèle, des personnes du terrain ont commencé à créer des flux de demande et de notification avec Power Automate. Deux filières « d’automatisation » qui n’ont ni la même façon d’être construites ni le même emplacement se multiplient dans l’entreprise, et on ne sait plus avec quel outil créer une nouvelle automatisation, ni même qui a une vue d’ensemble. » Nous recevons de plus en plus souvent ce type de consultation de la part de PME ayant déjà adopté Microsoft 365.

PowerShell + le Planificateur de tâches et Power Automate sont tous deux des outils pour « faire automatiquement un travail défini », mais leurs domaines de prédilection se recoupent à peine. Précisément parce qu’ils ne se recoupent pas, forcer tout vers l’un des deux devient pénible, et mélanger sans fixer de frontière produit un assemblage impossible à maintenir. Cet article met d’abord en ordre la différence de nature entre les deux outils, puis explique le critère de choix pour décider avec lequel construire, ainsi que les schémas de connexion pour les faire cohabiter. La conception d’ensemble de Power Automate est traitée dans « Automatiser les processus métier avec Power Automate — Flux cloud, flux de bureau et gestion robuste des erreurs », et l’initiation à PowerShell lui-même dans « Les bases des commandes PowerShell — les opérations à connaître d’abord et une utilisation sûre » ; nous nous concentrons donc ici sur « le critère de choix » et « la connexion » entre les deux.

1. La conclusion, d’abord

• Le premier critère de décision est l’emplacement de la cible. Si la cible est un fichier local, un dossier partagé, un serveur ou l’OS, la ligne de base est PowerShell + le Planificateur de tâches ; si la cible est une donnée sur Microsoft 365 (SharePoint, Outlook, Teams, etc.) accompagnée de notifications ou d’approbations, la ligne de base est Power Automate.
• Le point faible de PowerShell est la notification aux personnes. La cmdlet classique Send-MailMessage est officiellement dépréciée (obsolete), et il n’existe pas d’alternative directe au sein de PowerShell.¹ Il est plus économique de confier les notifications et les approbations à Power Automate.
• Le point faible de Power Automate est l’atteinte de l’environnement local et les gros volumes de données. Pour qu’un flux cloud atteigne un serveur de fichiers interne, une passerelle de données locale ou une connexion à un flux de bureau est nécessaire, et l’une comme l’autre sortent du droit d’utilisation fourni avec Microsoft 365 (fonctionnalités premium).²³⁴
• Pour connecter les deux, le premier candidat est un couplage faible où PowerShell dépose un fichier de résultat sur SharePoint, et Power Automate le détecte via le déclencheur « Lorsqu’un fichier est créé (propriétés uniquement) » (When a file is created (properties only) dans l’UI anglaise) pour enchaîner vers une notification ou une approbation.⁵
• Power Automate for desktop dispose d’une action « Exécuter un script PowerShell », permettant d’appeler un script existant depuis un flux. Cependant, l’appel depuis un flux cloud est une fonctionnalité premium, et la gestion de la machine d’exécution devient également nécessaire.⁶⁴
• L’historique d’exécution d’un flux cloud n’est visible que 28 jours par défaut.⁷ Pour un traitement nécessitant une trace, conservez-la via un fichier de log côté PowerShell ou en la réécrivant dans une liste SharePoint.
• Au final, ce n’est pas une question technique : construire avec l’outil pour lequel il y a quelqu’un capable d’en assurer la maintenance est souvent la bonne réponse. Une automatisation que seul son créateur sait réparer présente le même risque, quel que soit l’outil.

2. La nature des deux outils

Commençons par confirmer que les deux appartiennent à des terrains de jeu séparés.

Un complément sur la ligne « Gestion des changements » du tableau. Exporter un flux consiste à se connecter au portail Power Automate, à sélectionner le flux visé dans la navigation de gauche sous « Mes flux » > « Flux cloud », puis à choisir « Package (.zip) » depuis la flèche vers le bas à côté de « Exporter » dans le menu. Ce que l’on récupère est un package zip, peu adapté à une revue de différences ligne par ligne comme pour un script. L’export est en outre réservé au propriétaire ou aux copropriétaires du flux. Pour une gestion de versions continue, Microsoft recommande d’utiliser l’ALM via les solutions Dataverse plutôt que l’export/import de packages.⁸

L’important, c’est que « le lieu d’exécution » et « qui le crée » diffèrent tous deux entre les deux colonnes de ce tableau. PowerShell + le Planificateur de tâches tourne sur une machine interne, est créé par une personne sachant coder, et se gère comme du code. Power Automate tourne dans le cloud, peut être créé même par une personne du terrain qui s’y connaît, sans avoir à se soucier de la plateforme d’exécution. Autrement dit, cette coexistence des deux n’est pas un simple doublon d’outils : c’est la coexistence de deux cultures, « l’automatisation du service informatique » et « l’automatisation du terrain ». C’est justement pour cela qu’imposer une unification vers l’un des deux par simple décret échoue le plus souvent.

3. Le tableau de décision : avec quoi construire ?

Lorsque nous recevons une consultation, nous tranchons selon trois critères : « où se trouve la cible », « qui la crée et la maintient », et « une notification ou une approbation à une personne est-elle nécessaire ». C’est plus rapide à voir avec des exemples concrets, d’où ce tableau de décision.

En parcourant les colonnes verticalement, on voit que l’outil se décide presque de manière biunivoque avec la colonne « cible ». L’exception est le dernier cas, à cheval — « le traitement est local, la notification est cloud » —, précisément le cas d’usage des schémas de connexion du chapitre 6.

À l’inverse, les choix suivants finissent par devenir pénibles.

• Faire glisser jusqu’au traitement de fichiers vers Power Automate pour la seule raison qu’on veut une notification. Introduire une passerelle ou du RPA pour atteindre l’environnement local augmente les licences et le périmètre à gérer (chapitre 5).
• Faire créer par le service informatique, en PowerShell, un flux de demande SharePoint utilisé par le terrain. C’est possible, mais écrire en code l’écriture sur SharePoint ou la notification Teams demande beaucoup d’efforts pour peu de bénéfice, et cela finit en pièce unique que le terrain ne peut pas modifier lui-même.
• Choisir au cas par cas selon le responsable, sous prétexte que les deux permettent de le faire. Cela mène directement au problème de maintenance abordé au chapitre 7. Fixer une seule règle interne du type « si la cible est ici, l’outil est celui-là » suffit déjà à limiter considérablement le désordre de la coexistence.

4. Les limites du côté PowerShell

Les notifications par e-mail et Teams sont pénibles

Dès qu’une demande du type « prévenez-moi par e-mail une fois terminé » s’ajoute à un traitement de nuit PowerShell, les choses se compliquent soudainement. La cmdlet Send-MailMessage, utilisée depuis longtemps, est officiellement dépréciée (obsolete) au motif qu’elle ne garantit pas une connexion sécurisée au serveur SMTP, et son avertissement précise explicitement qu’« il n’existe pas d’alternative directe au sein de PowerShell ». Les alternatives présentées sont la bibliothèque tierce MailKit, ou le SDK PowerShell Microsoft Graph (Send-MgUserMail) pour les utilisateurs d’Exchange Online.¹

L’envoi via Graph fonctionne, mais il faut assumer une préparation conséquente pour un seul besoin de notification : enregistrement d’une application auprès de Microsoft Entra ID, octroi d’autorisations (scopes), gestion d’un certificat ou d’un secret. Il en va de même pour les notifications Teams : appeler directement depuis du code impose un seuil d’entrée élevé côté authentification. Ici, la recommandation la plus simple est de confier les notifications à Power Automate. Avec les actions standard Outlook et Teams, on peut les mettre en place en quelques minutes, sans enregistrement d’application supplémentaire.

Les « tâches sauvages » qui tournent sur le PC d’un responsable

Un incident classique de l’automatisation via le Planificateur de tâches est le cas où la tâche a été implantée non pas sur un serveur, mais sur le PC d’un responsable. Elle ne tourne plus si la personne éteint son PC en partant, et elle s’arrête discrètement en cas de changement de mot de passe de l’utilisateur d’exécution ou de départ de la personne. De plus, comme le Planificateur de tâches se trouve localement sur chaque machine, il n’existe aucun endroit où lister ce qui tourne, et où, dans l’entreprise.

Le remède est modeste mais tient en trois points : (1) regrouper les tâches à exécution planifiée sur un serveur défini (à défaut, un PC d’administration toujours allumé) ; (2) documenter la liste des tâches avec leur objectif et leur responsable ; (3) conserver la définition de la tâche elle-même sous forme de script, par exemple via Register-ScheduledTask, pour pouvoir la reconstituer même si la machine change.⁹ Même si le script lui-même est géré sous Git, si la configuration côté Planificateur de tâches (heure de démarrage, utilisateur d’exécution, dossier de travail) reste manuelle, l’environnement ne pourra pas être reconstitué.

Le stockage des identifiants

Lorsqu’un script se connecte à une base de données ou à un service externe, la question de savoir où placer le mot de passe se pose toujours. Écrire en dur dans le .ps1 est hors de question ; la réponse standard de PowerShell est le module SecretManagement associé à l’extension SecretStore. On peut ainsi stocker les secrets chiffrés localement et les récupérer depuis le script avec Get-Secret.¹⁰ La configuration à utiliser pour une exécution sans surveillance via le Planificateur de tâches (paramétrage dans le contexte du compte d’automatisation) est également documentée officiellement.¹¹ Notez que cet ensemble de modules est désormais considéré comme « fonctionnellement complet » : le développement de nouvelles fonctionnalités est terminé, mais le support des correctifs de sécurité continue.¹⁰

Power Automate, en revanche, conserve l’authentification vers les connecteurs (les connexions) côté plateforme, ce qui évite à celui qui construit le flux d’avoir à se soucier de ce problème. C’est une force cachée de Power Automate, mais cela crée en contrepartie un autre problème de gestion : les connexions sont liées au compte du propriétaire du flux. Ce point est traité dans « La dépendance à une seule personne dans Power Automate — pour que les flux ne s’arrêtent pas quand leur créateur quitte l’entreprise ».

5. Les limites du côté Power Automate

Impossible d’atteindre un fichier local ou un environnement local

Comme un flux cloud tourne dans le cloud Microsoft, il n’atteint pas directement, tel quel, un dossier partagé du réseau interne ou une base de données locale. Il existe principalement deux moyens d’y parvenir.

1. La passerelle de données locale. Installer une application résidente dans l’entreprise pour servir de pont avec le cloud. L’ouverture d’un port entrant n’est pas nécessaire, seule une connexion sortante suffit à faire fonctionner l’ensemble, ce qui en fait un mécanisme relativement sûr.¹² Elle permet une connexion vers le système de fichiers ou SQL Server via la passerelle, mais son utilisation nécessite une licence prenant en charge la passerelle.²
2. Via un flux de bureau (RPA). Appeler, depuis un flux cloud, un flux de bureau tournant sur un PC, en lui confiant le traitement local. Ce « déclenchement/cette exécution planifiée d’un flux de bureau depuis un flux cloud » est en soi une fonctionnalité premium.⁴

Le point important, c’est que dans les deux cas, cela sort du droit d’utilisation Power Automate fourni avec Microsoft 365. Le droit d’utilisation intégré à Microsoft 365 (seeded license) ne comprend ni les connecteurs premium, ni la passerelle locale, ni le RPA.³ Autrement dit, « je veux traiter les fichiers du dossier partagé avec Power Automate » est une demande plus coûteuse qu’il n’y paraît. Les niveaux de licence et la frontière entre standard et premium sont détaillés dans « Les licences Power Automate et la frontière entre connecteurs standard et premium », à consulter avant de trancher.

Deux solutions réalistes sans coût supplémentaire existent : déplacer le stockage des fichiers concernés vers SharePoint/OneDrive, ou confier le traitement du dossier partagé à PowerShell et ne faire porter à Power Automate que le travail côté cloud. La seconde est le schéma de connexion du chapitre suivant.

Les gros volumes de données et la logique complexe sont pénibles

Traiter, ligne par ligne dans une boucle de flux, un CSV de plusieurs centaines de milliers de lignes n’est pas ce pour quoi Power Automate est conçu. Il existe aussi une limite du nombre d’exécutions d’actions par jour selon la licence, fixée à 6 000 actions par utilisateur et par jour pour le droit d’utilisation fourni avec Microsoft 365.³ Le rapprochement, l’agrégation et la transformation de gros volumes sont des traitements que PowerShell ou .NET peuvent terminer en quelques minutes. Pour des exemples concrets d’écriture, les combinaisons de Group-Object et Compare-Object traitées dans « Recueil de commandes PowerShell pratiques — étoffer les petites fonctionnalités souvent utilisées au quotidien » s’appliquent directement.

Par ailleurs, une logique où les branchements conditionnels s’empilent en profondeur devient difficile à lire à l’écran d’un flux, et ne peut pas être testée. La limite d’une exécution de flux cloud, plafonnée à 30 jours au maximum¹³, se fait sentir pour une attente d’approbation, mais bien avant cela, « une logique dont le schéma des branchements ne tient pas sur une feuille A4 » relève du domaine du code.

L’historique d’exécution disparaît au bout de 28 jours

L’historique d’exécution d’un flux cloud n’est visible que pendant 28 jours par défaut.⁷ Pour une exigence du type « vérifier trois mois plus tard si le traitement de tel jour a bien tourné », l’historique d’exécution ne suffit pas. Avec PowerShell, on peut écrire soi-même un fichier de log et le conserver pendant des années (cette conception est détaillée dans l’article sur la maintenance des logs). Si une trace est nécessaire avec Power Automate, intégrez dans le flux lui-même une étape qui réécrit le résultat du traitement dans une liste SharePoint. Pour la conception complète incluant notification en cas d’erreur et nouvelles tentatives, consultez « La gestion des erreurs et la conception des tentatives dans Power Automate ».

6. Les schémas de connexion pour mélanger les deux

Puisque les domaines de prédilection des deux ne se recoupent pas, il y aura forcément des tâches à cheval, du type « le traitement en PowerShell, la notification ou l’approbation en Power Automate ». Il existe trois schémas de connexion.

Schéma a : couplage faible via un fichier (recommandé)

PowerShell, exécuté par le Planificateur de tâches, dépose le résultat du traitement (CSV de résultat, fichier de synthèse) dans une bibliothèque SharePoint, et Power Automate le détecte via le déclencheur « Lorsqu’un fichier est créé (propriétés uniquement) » du connecteur SharePoint, pour enchaîner vers une notification ou une approbation. Ce déclencheur est un véritable déclencheur du connecteur standard, et les changements sont typiquement détectés en quelques minutes (le mécanisme reposant sur un sondage périodique côté SharePoint, la détection n’est pas instantanée).⁵

Si la langue d’affichage du locataire est l’anglais, ce nom en français ne permettra pas de le retrouver ; nous indiquons donc aussi le nom en UI anglaise. Utilisez-le pour la recherche dans la liste des déclencheurs.⁵

Notez que le déclencheur au nom proche « ファイルが作成されたとき(フォルダー内)» (When a file is created in a folder) est déprécié, avec entre autres la contrainte de ne pas se déclencher dans les sous-dossiers : ne le choisissez pas pour une nouvelle construction.⁵

Le schéma suivant représente le déroulement de ce modèle. Le Planificateur de tâches démarre le script PowerShell à 02:00 → le script effectue l’agrégation, le traitement de fichiers et la sortie de logs, puis produit un CSV de résultat et une synthèse → ceux-ci sont déposés dans une bibliothèque SharePoint → ce dépôt est détecté par le déclencheur « Lorsqu’un fichier est créé », ce qui démarre le flux cloud → le flux examine le contenu de la synthèse, et en cas de fin normale, notifie l’achèvement sur Teams ; en cas d’erreur, notifie le responsable et, si nécessaire, l’oriente vers un flux d’approbation ou de traitement — un flux à sens unique.

flowchart TD
    T[Planificateur de tâches démarrage 02:00] --> PS[Script PowerShell<br/>Agrégation, traitement de fichiers, sortie de logs]
    PS --> OUT[Production du CSV de résultat et de la synthèse]
    OUT --> UP[Dépôt dans la bibliothèque SharePoint]
    UP --> TRG[Démarrage du flux cloud<br/>Lorsqu'un fichier est créé]
    TRG --> CHK{Contenu de la synthèse}
    CHK -- Fin normale --> OK[Notification d'achèvement sur Teams]
    CHK -- Erreur présente --> NG[Notification au responsable<br/>Si nécessaire, orientation vers approbation/traitement]

La méthode de dépôt de PowerShell vers SharePoint se choisit selon la manière dont la tâche est exécutée. Configurer le dossier de sortie comme cible de synchronisation OneDrive/SharePoint (le script se contentant d’écrire dans un dossier local) est la méthode la plus simple, mais le client de synchronisation est une application qui tourne dans la session utilisateur connectée. Pour une tâche de nuit configurée en « s’exécuter que l’utilisateur soit connecté ou non », ou sur un serveur où personne n’est connecté, la synchronisation ne fonctionne pas, et le fichier écrit localement n’est jamais téléversé, si bien que le flux ne se déclenche pas non plus — un coup dans le vide. Pour une petite exploitation de jour sur un PC surveillé par une personne, la synchronisation suffit amplement, mais pour une exécution nocturne et sans surveillance, utilisez plutôt PnP.PowerShell ou l’API Graph pour téléverser directement depuis le script, ou bien préparez une session qui reste connectée pour la synchronisation et incluez-la dans ce qui est surveillé. Cela ajoute de la préparation côté authentification, mais permet d’éliminer par construction le problème du « fichier censé être là mais absent ».

PnP.PowerShell est un module PowerShell open source produit par la communauté (et non un produit officiel Microsoft) permettant d’opérer SharePoint Online, Teams et d’autres services de Microsoft 365. Il comporte plus de 700 cmdlets et permet de téléverser des fichiers ou de manipuler des listes directement depuis un script. Cependant, alors qu’il était auparavant possible de se connecter facilement via une application Entra ID partagée, cette application a été retirée en septembre 2024, rendant désormais obligatoire l’enregistrement, par l’utilisateur lui-même, de sa propre application Entra ID. Ce n’est plus « installer le module suffit à le faire fonctionner » : prévoyez, au moment de décider de son adoption, l’effort d’enregistrement d’application et d’octroi d’autorisations.¹⁴

La raison de recommander ce schéma est que la frontière est fixée sous une forme visible : le fichier. Le côté PowerShell ignore l’existence de Power Automate, et le côté Power Automate ignore le contenu du script. Quand l’un des deux tombe en panne, il suffit de vérifier si le fichier existe sur SharePoint pour identifier immédiatement de quel côté vient le problème. On peut aussi séparer les responsables : le script au service informatique, le flux de notification à la personne du terrain qui s’y connaît. De plus, le fichier lui-même déposé fait aussi office de trace, comblant le problème des 28 jours d’historique d’exécution.⁷

Schéma b : appeler PowerShell depuis Power Automate for desktop

Power Automate for desktop (PAD) dispose d’une action « Exécuter un script PowerShell (Run PowerShell script) », qui permet d’exécuter n’importe quel code PowerShell depuis un flux de bureau, et de récupérer la sortie via une variable (PowershellOutput).⁶ Cela permet d’appeler un actif de script existant comme composant du flux, dans une architecture où « le traitement lui-même reste un script, et seuls le démarrage et les opérations d’écran avant/après sont confiés à PAD ».

Cette action ne comporte que trois paramètres de configuration.⁶

La sortie est récupérée via deux variables : PowershellOutput (la sortie du script) et ScriptError (les erreurs survenues pendant l’exécution). Pour renvoyer une valeur au flux, la méthode officielle consiste à la passer à Write-Output côté PowerShell.⁶

# Exemple minimal destiné à être collé dans le champ « PowerShell code to run » de l'action PAD.
# %InputFolder% est une variable côté PAD, remplacée par une chaîne avant que PowerShell ne s'exécute
$targetFolder = '%InputFolder%'
$count = (Get-ChildItem -LiteralPath $targetFolder -Filter '*.csv' -File).Count

# Le contenu renvoyé via Write-Output se retrouve dans la variable PowershellOutput
Write-Output $count

Autrement dit, vu du côté PAD, ce composant n’a que deux points d’entrée/sortie : l’entrée est « une variable insérée dans le corps du code », la sortie est « la chaîne PowershellOutput ». Comme la valeur de retour n’est pas structurée et revient sous forme de chaîne, si vous voulez renvoyer plusieurs valeurs, l’architecture consiste à les regrouper dans une ligne CSV ou en JSON, puis à analyser PowershellOutput en aval. Avec, en plus, un délai d’expiration par défaut de seulement 10 secondes, cette action ne convient pas à un usage où l’on « fait porter tout le corps du traitement de nuit par cette seule action ». Pour un traitement long, tenez compte aussi des points de vigilance ci-dessous avant de trancher.

Il y a cependant trois points de vigilance. Premièrement, cette action démarre en interne powershell.exe, c’est-à-dire Windows PowerShell 5.1.¹⁵ Un script écrit en partant du principe de PowerShell 7 risque de ne pas fonctionner tel quel. Deuxièmement, il existe un réglage de délai d’expiration (valeur par défaut : 10 secondes), qu’il faut explicitement allonger ou rendre illimité pour appeler un traitement long. Troisièmement, si vous souhaitez l’exécuter sans surveillance à heure fixe, le déclenchement depuis un flux cloud est une fonctionnalité premium⁴, et une licence d’exécution sans surveillance ainsi qu’une gestion de la machine d’exécution deviennent également nécessaires. Il vaut mieux évaluer froidement si « payer un coût supplémentaire pour exécuter à heure fixe avec PAD plutôt qu’avec le Planificateur de tâches » en vaut la peine. Cela peut devenir une option pour une entreprise qui exploite déjà du RPA (opérations d’écran) avec PAD et dispose donc déjà de la plateforme d’exécution, mais sinon, le schéma a suffit.

Schéma c : recevoir une requête HTTP via une API maison

Il s’agit de doter un flux d’une URL via le déclencheur « Lorsqu’une requête HTTP est reçue (When an HTTP request is received) » du flux cloud, et de l’appeler avec Invoke-RestMethod côté PowerShell pour le démarrer — ou, à l’inverse, de monter une petite API web interne que le flux appelle. Ce déclencheur relève du connecteur premium de requête/réponse HTTP.¹⁶ Un mécanisme d’authentification OAuth est également prévu pour restreindre l’appelant (par exemple, aux seuls utilisateurs du locataire).¹⁷

C’est le schéma le plus flexible, avec une forte réactivité en temps réel et la possibilité de transmettre des paramètres, mais la gestion des URL, l’authentification et la retransmission en cas d’erreur font d’un coup basculer dans le domaine du développement. Arrivé à ce point, ce n’est plus une simple « connexion entre Power Automate et PowerShell », mais un petit développement de système, dont il faut décider s’il sera pris en charge en interne ou si sa conception sera confiée à un tiers.

En résumé : d’abord le schéma a, puis b si la plateforme PAD existe déjà, et c uniquement lorsque l’exigence de temps réel est clairement établie. La conception du couplage faible s’applique plus largement aux intégrations par fichier ; les bonnes pratiques d’exclusion mutuelle et de remise sont aussi traitées dans « Les bases du contrôle d’exclusion pour l’intégration de fichiers - bonnes pratiques de verrouillage de fichiers et de claim atomique ».

7. Le problème du « personne ne maîtrise les deux »

Nous avons jusqu’ici écrit des critères de décision sous l’angle technique, mais ce qui compte finalement le plus sur le terrain, c’est « qui peut en assurer la maintenance ». Une personne sachant écrire du PowerShell au service informatique, une personne sachant manipuler Power Automate sur le terrain, et personne qui maîtrise les deux : c’est la norme dans une PME.

C’est pourquoi, même pour un traitement techniquement mieux adapté à PowerShell, décider de le construire en Power Automate parce que la personne qui sait l’écrire va partir (ou l’inverse) est une décision parfaitement rationnelle. Ce qui compte plus que la supériorité d’un outil, c’est de savoir s’il y aura, dans cinq ans, quelqu’un en interne capable de le réparer. Le tableau de décision (chapitre 3) est « la solution optimale en supposant qu’il y a quelqu’un pour en assurer la maintenance » : en l’absence de cette personne, on ajuste la solution optimale en fonction des personnes disponibles, et non l’inverse.

Cela posé, il y a deux choses à faire, communes aux deux outils.

• Lister ce qui existe. Rassemblez, dans un même registre, la liste des tâches du Planificateur de tâches (sur quelle machine, à quelle heure, quoi, sous la responsabilité de qui) et la liste des flux Power Automate (propriétaire, connexions, objectif). Le plus dangereux dans une entreprise où les deux filières coexistent, c’est que l’une soit invisible depuis l’autre.
• Conserver sous une forme transmissible. Les scripts vers Git, les définitions de tâche vers un script d’enregistrement⁹, les flux vers une configuration de copropriétaires et un export. Une automatisation sans spécifications, c’est la production en série de versions miniatures du système sans code source ni documentation. La conception concrète de la passation côté flux est détaillée dans l’article sur les mesures contre la dépendance à une seule personne.

8. Conclusion

PowerShell + le Planificateur de tâches et Power Automate ne sont pas des outils concurrents, mais des outils séparés dont les périmètres se recoupent à peine. Le local, le serveur, les fichiers et les gros volumes de données pour PowerShell ; les données sur Microsoft 365 et les notifications/approbations pour Power Automate. Cette ligne de base détermine l’emplacement de la plupart des automatisations.

Les tâches à cheval sur la frontière ne devraient pas être forcées vers l’un des deux, mais connectées en couplage faible via un fichier déposé sur SharePoint comme frontière : c’est solide aussi bien du point de vue des licences que de la maintenance. La difficulté de PowerShell en matière de notification (dépréciation de Send-MailMessage) et la difficulté de Power Automate à atteindre l’environnement local (passerelle et RPA en premium) se compensent mutuellement, chacun via le domaine où l’autre excelle.

Et, avec la même importance que le choix des outils, il faut décider dès le départ « qui en assure la maintenance » et « où, quoi, tourne ». La coexistence de deux filières d’automatisation est saine en soi. Seul le mélange désordonné pose problème. Nous recevons aussi volontiers des consultations dès le stade où il s’agit de clarifier la vue d’ensemble des automatisations internes, ou de trancher au cas par cas avec quel outil construire.

Articles connexes

• Automatiser les processus métier avec Power Automate — Flux cloud, flux de bureau et gestion robuste des erreurs
• Les tâches du Planificateur de tâches ne s’exécutent pas ou se terminent en 0x1 — diagnostic des causes et conception d’une exploitation sûre
• Scripts PowerShell avancés — automatiser en toute sécurité l’investigation de logs, l’archivage et la mise en rapport
• Les licences Power Automate et la frontière entre connecteurs standard et premium
• La dépendance à une seule personne dans Power Automate — pour que les flux ne s’arrêtent pas quand leur créateur quitte l’entreprise
• Les flux d’exécution périodique de Power Automate — la détermination des jours ouvrés et la conception du traitement de fin de mois

Domaines de conseil associés

合同会社小村ソフト (Komura Software LLC) accompagne, depuis la mise en ordre des traitements par lots internes en PowerShell jusqu’à la revue de conception d’une plateforme d’automatisation incluant Power Automate, en intégrant la question de « avec quel outil construire ».

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

Références

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.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

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

Faut-il automatiser avec Power Automate ou avec PowerShell ?

Le critère de base est l'emplacement de la cible. Si la cible est un fichier local, un dossier partagé, un serveur, une base de données ou une opération de l'OS — bref, un environnement Windows interne — PowerShell + le Planificateur de tâches est souvent plus stable et plus facile à maintenir. Si la cible est une donnée sur Microsoft 365 (SharePoint, Outlook, Teams, etc.) accompagnée de notifications ou d'approbations, les flux cloud Power Automate sont plus adaptés. Il est aussi réaliste de séparer le corps du traitement de la notification : le traitement lourd en PowerShell, la notification ou l'approbation destinée aux personnes en Power Automate.

Est-il difficile d'envoyer des notifications par e-mail ou vers Teams depuis PowerShell ?

La cmdlet Send-MailMessage, longtemps utilisée par défaut, est officiellement dépréciée (obsolete) car elle ne garantit pas une connexion sécurisée au serveur SMTP, et il n'existe pas d'alternative directe au sein de PowerShell. Il existe bien une méthode via Send-MgUserMail du SDK PowerShell Microsoft Graph, mais elle nécessite une préparation (enregistrement d'application, octroi d'autorisations) relativement lourde pour le seul besoin d'une notification. En pratique, une architecture où PowerShell se contente d'écrire le résultat dans un fichier, en laissant à Power Automate la détection et la notification, est plus simple à gérer.

Power Automate peut-il traiter des fichiers dans un dossier partagé local ?

C'est possible, mais pour qu'un flux cloud atteigne un fichier du réseau interne, une passerelle de données locale est nécessaire, et le droit d'utiliser cette passerelle n'est pas inclus dans le droit d'utilisation Power Automate fourni avec Microsoft 365 : une licence de niveau supérieur est requise. Faire appeler un flux de bureau (RPA) depuis un flux cloud est également une fonctionnalité premium. Si vous souhaitez vous en tenir à l'existant sans licence supplémentaire, il est réaliste d'envisager d'abord soit de déplacer les fichiers concernés vers SharePoint/OneDrive, soit de confier le traitement du dossier partagé à PowerShell + le Planificateur de tâches.

Quelle est la façon la plus simple de faire communiquer un traitement de nuit PowerShell avec Power Automate ?

Nous recommandons un couplage faible via un fichier. PowerShell, exécuté par le Planificateur de tâches, dépose un CSV ou un fichier de synthèse du résultat dans une bibliothèque SharePoint, et Power Automate le détecte avec le déclencheur « Lorsqu'un fichier est créé (propriétés uniquement) » pour enchaîner vers une notification ou une approbation. Aucun des deux mécanismes n'a besoin de connaître l'intérieur de l'autre, ce qui rend le diagnostic simple en cas de panne de l'un des deux, et permet aussi de séparer les responsables. Il existe aussi la méthode consistant à appeler directement PowerShell depuis l'action « Exécuter un script PowerShell » de Power Automate for desktop, mais elle ajoute des prérequis de licence et de gestion de machine.

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.