Power Automate, ce n'est pas de "l'IA" : c'est le plombier de Microsoft 365
Avant de décider si Power Automate est ton outil, mieux vaut savoir ce que c'est vraiment, car le nom trompe. Power Automate est la brique d'automatisation de la Power Platform de Microsoft : il déplace des données entre tes applis, déclenche des alertes, lance des approbations et exécute des flux quand quelque chose se passe. Né comme des règles fixes —si un e-mail avec pièce jointe arrive, range-le dans SharePoint—, on lui a greffé de l'IA depuis (Copilot pour monter le flux, AI Builder pour lire un document). Mais son ADN reste celui d'un moteur de flux déterministe collé à Office, pas d'un système qui décide avec discernement. Confondre les deux est la première erreur chère.
C'est pourquoi ce guide ne parle pas de "comment automatiser Microsoft 365" —c'est une autre conversation, monter une couche d'IA sur ta suite, qu'on traite dans IA pour Microsoft 365—. Il parle d'une décision d'avant : quand Power Automate est le bon outil pour ton entreprise et quand tu le forces à faire une chose pour laquelle il existe mieux. C'est le même exercice que choisir un outil d'automatisation, appliqué au cas de qui vit déjà dans Microsoft.
Quand Power Automate est la réponse évidente
Il y a trois situations où Power Automate gagne presque sans discussion, et les trois tiennent à où ton entreprise vit déjà, pas à l'intelligence de l'outil. La première : tu es dans Microsoft 365 jusqu'au cou. Si ton mail est Outlook, tes documents vivent dans SharePoint et Teams, tes gens travaillent dans Excel et ton identité est gouvernée par Entra (l'ancien Azure AD), Power Automate parle cette langue nativement. Aucun connecteur à maintenir, aucune permission à négocier : l'outil est déjà dans ton périmètre et ton administrateur le contrôle déjà.
La deuxième : les flux d'approbation. Congés, notes de frais, validation d'une facture, une intégration qui demande trois feux verts. Power Automate le fait particulièrement bien —cartes d'approbation dans Teams et Outlook, avec la trace de qui a approuvé quoi et quand— et c'est la raison pour laquelle beaucoup l'adoptent sans avoir décidé rien d'autre. La troisième : le RPA sur de vieux systèmes sans API. Si tu as un ERP de quinze ans ou une appli bureau où il faut cliquer à la main, les desktop flows de Power Automate automatisent cette interaction comme un robot qui utilise l'écran. Là il affronte UiPath et Automation Anywhere, pas Zapier.
Le modèle de licence que personne ne regarde avant la facture
C'est là que presque tout le monde prend peur. Power Automate arrive "inclus" dans beaucoup de plans Microsoft 365, et ce mot —inclus— est le piège. Ce qui arrive gratuit, ce sont les flux qui ne touchent que des applis Office standard avec les connecteurs de base. Dès qu'un flux franchit la ligne des connecteurs premium (SQL Server, Salesforce, SAP, Dataverse, HTTP, connecteurs sur mesure), il cesse d'être gratuit et réclame une licence payante. Et cette ligne, on la franchit presque toujours, parce que le vrai travail reste rarement dans Office.
Le modèle de licence a, en 2026, trois formes principales, et se tromper coûte de l'argent à l'échelle. La licence par utilisateur laisse une personne exécuter tous les flux qu'elle veut ; elle est rentable quand peu d'utilisateurs ont besoin de capacités premium. La licence par flux (ou par processus) paie un flux précis peu importe combien de gens le déclenchent ; elle gagne quand un même flux est utilisé par beaucoup. Et le RPA non surveillé —un bot qui tourne seul, sans personne devant— se licencie à part, par bot, et c'est de loin la ligne la plus chère. À cela s'ajoute la passerelle de données on-premise si tu as besoin qu'un flux cloud touche une donnée qui vit sur ton serveur : c'est une capacité premium, pas un extra gratuit.
| Modèle | Ce qu'il paie | Quand c'est rentable |
|---|---|---|
| Par utilisateur | Qu'une personne exécute des flux premium illimités | Peu d'utilisateurs avec besoins premium |
| Par flux / processus | Un flux précis, quel que soit qui le déclenche | Un flux utilisé par beaucoup |
| RPA non surveillé | Un bot qui tourne seul, personne devant | Robotiser du legacy à volume (la ligne chère) |
| Passerelle de données | Pont vers des données on-premise depuis le cloud | Flux touchant ton serveur, pas juste Office |
La discipline est la même que calculer le ROI d'une automatisation : ne regarde pas le prix d'entrée —le "tu l'as déjà avec ton 365"—, chiffre au volume et au type de flux que tu vas exécuter dans un an, connecteurs premium et RPA compris si tu en as besoin. Un "inclus" qui se déclenche dès que tu touches un système réel n'est pas gratuit ; c'est une décision de coût que tu paies plus tard.
Cloud flows et desktop flows : deux outils sous un même nom
Un détail qui déroute les nouveaux venus : sous le nom "Power Automate" vivent deux produits distincts. Les cloud flows tournent dans le cloud de Microsoft et connectent des applis par API —c'est ce qui affronte Make, n8n ou Zapier, et pour choisir entre ces deux familles, le même critère que Make vs n8n vaut—. Les desktop flows sont du RPA : un robot installé sur une machine qui pilote des applis de bureau en imitant un humain —ouvre l'écran, clique, tape, copie—. Ils servent exactement à l'inverse : des systèmes sans API auxquels on ne peut parler que par l'interface.
La différence compte au moment de décider, car chacun résout un problème et chacun se paie autrement. Si ton automatisation connecte des applis modernes avec API, tu veux des cloud flows et tu affrontes le terrain du no-code habituel. Si ton automatisation doit se battre avec un vieux programme sans API, tu veux des desktop flows et tu es sur le terrain du RPA, plus fragile par nature : un changement d'écran du système legacy casse le robot. Cette fragilité est exactement ce qui transforme la maintenance des automatisations en la ligne que personne ne budgète —et en RPA elle pèse double.
Là où Power Automate flanche (et quoi regarder alors)
Power Automate est un excellent moteur de flux, mais il a deux plafonds à voir avant de t'y marier. Le premier est le plafond du discernement : par conception il exécute des règles, il ne décide pas sur un contexte ambigu. Copilot t'aide à monter le flux et AI Builder sait lire un document au format connu, mais quand le travail exige de lire du texte libre, comprendre l'intention d'un mail ou réconcilier ce qui ne colle pas entre trois systèmes, Power Automate s'arrête au bord. Là tu n'as pas besoin d'un flux plus long : tu as besoin d'une couche de décision —des modèles de langage avec la logique autour— montée par-dessus, ce qui est le vrai sujet d'automatiser avec l'IA face à l'automatisation classique.
Le second est le plafond de la maison fermée : Power Automate est de Microsoft et il brille dans Microsoft. Dès que ton opération vit à moitié dehors —ton CRM est HubSpot, ton produit tourne sur Google Cloud, ton équipe travaille dans Notion et Slack— tu forces l'outil à franchir des frontières où d'autres options sont plus naturelles et moins chères. Non qu'il ne puisse pas ; c'est que tu cesses de profiter de son seul grand atout (l'intégration native avec Office) et tu ne gardes que ses coûts. Quand le flux doit parler à des systèmes du dehors, le vrai problème n'est plus l'outil mais intégrer l'IA à tes systèmes sans que ça casse quand l'un change tout seul.
| Ta situation | Power Automate | Regarder aussi |
|---|---|---|
| Tout dans Microsoft 365, flux Office | Adéquation naturelle | — |
| Approbations et alertes internes | Dur à battre | — |
| Legacy sans API (RPA) | Desktop flows, terrain propre | UiPath, Automation Anywhere |
| Connecter des applis modernes avec API | Cloud flows, ça marche | Make, n8n, Zapier |
| Décision sur texte/contexte | S'arrête au bord | Couche IA sur mesure au-dessus |
| Stack à moitié hors Microsoft | Tu forces l'outil | Options neutres au fournisseur |
Alors, Power Automate ou pas ?
La version honnête : oui si ton entreprise vit dans Microsoft 365, tes automatisations consistent à déplacer des données Office, lancer des approbations ou robotiser un système legacy, et tu as le modèle de licence clair avant de passer à l'échelle. Avec nuances si ton stack est à moitié dehors ou si le travail exige un vrai discernement : là Power Automate peut être une pièce —le bras qui exécute dans Office— mais pas le système entier, et la décision de fond redevient quels processus automatiser et avec quelle adéquation, pas quel outil acheter. La marque est la dernière décision, pas la première.