khalilbenaz Power Automate Designer
Workflow
1. Analyser le besoin d'automatisation
Cartographier le processus AVANT d'ouvrir Power Automate :
- Déclencheur : qu'est-ce qui lance le flow ? (email reçu, fichier déposé, formulaire soumis, heure planifiée, appel HTTP)
- Données d'entrée : quelles informations sont disponibles au déclenchement ?
- Étapes : quelles actions manuelles remplace-t-on ?
- Sorties : notifications, fichiers créés, enregistrements mis à jour, appels API
Critère go/no-go : si le processus contient des décisions subjectives ou nécessite une interface graphique legacy non automatisable par API, préférer un Business Process Flow ou un Desktop Flow.
2. Choisir le type de flow
| Type | Cas d'usage | Limite clé |
|---|---|---|
| Cloud Flow automatisé | Trigger event-driven (email, SharePoint, Teams) | Dépend de la disponibilité du connecteur |
| Cloud Flow instantané | Déclenché manuellement ou via bouton Teams/mobile | Nécessite une interaction humaine |
| Cloud Flow planifié | Batch quotidien/hebdomadaire, rapports récurrents | Pas de réactivité aux événements |
| Desktop Flow (RPA) | Applications sans API (ERP legacy, interfaces Windows) | Machine cible doit être active + Power Automate Desktop installé |
| Business Process Flow | Guidage étape par étape (onboarding, validation multi-niveaux) | Uniquement avec Dataverse |
3. Configurer les connecteurs
Connecteurs standard courants : SharePoint, Outlook, Teams, Excel Online, Forms, Planner, OneDrive, Dataverse.
Connecteur personnalisé (API interne ou tierce non couverte) :
# Exemple de définition OpenAPI minimale pour connecteur custom
openapi: "2.0"
info:
title: Mon API Interne
version: "1.0"
host: api.monentreprise.com
basePath: /v1
schemes: [https]
paths:
/orders/{id}:
get:
operationId: GetOrder
parameters:
- name: id
in: path
required: true
type: string
responses:
200:
description: OK
Importer via Data > Custom connectors > New custom connector > Import an OpenAPI file.
Authentification : préférer OAuth 2.0 ou API Key stockée dans un connecteur custom plutôt qu'un mot de passe hardcodé dans une action HTTP.
4. Construire la logique du flow
Structures de contrôle essentielles :
Condition → branchement binaire (if/else)
Switch → branchement sur valeur (évite les Condition imbriqués)
Apply to each → itération sur tableau
Do until → boucle conditionnelle (max 60 itérations par défaut)
Parallel branch → actions concurrentes (gain de temps si indépendantes)
Scope → regroupement logique + Try/Catch
Déclarer les variables en tête de flow (toutes en bloc, avant toute logique) :
Initialize variable — Name: varErrorMessage Type: String Value: ""
Initialize variable — Name: varCounter Type: Integer Value: 0
Initialize variable — Name: varItems Type: Array Value: []
Conseil : utiliser Compose pour stocker des expressions complexes et les réutiliser par outputs('Compose_NomEtape') — évite la duplication.
5. Maîtriser les expressions
Fonctions indispensables (syntaxe copiable) :
# Date/heure
formatDateTime(utcNow(), 'yyyy-MM-dd')
addDays(utcNow(), -7)
convertTimeZone(utcNow(), 'UTC', 'Romance Standard Time')
# Chaînes
concat(triggerBody()?['subject'], ' — traité')
replace(body('Get_item')?['Title'], ' ', '_')
toLower(trim(variables('varInput')))
split(body('Action')?['emails'], ';')
# Collections
first(body('Get_items')?['value'])
length(body('Get_items')?['value'])
join(variables('varItems'), ', ')
contains(body('Action')?['tags'], 'urgent')
# Conditions inline
if(equals(body('Action')?['status'], 'active'), 'Actif', 'Inactif')
coalesce(triggerBody()?['optionalField'], 'valeur_defaut')
# HTTP / JSON
json(body('HTTP_Call'))
string(variables('varCounter'))
base64(concat(variables('user'), ':', variables('password')))
Accès aux propriétés dynamiques : utiliser ?['champ'] (null-safe) plutôt que ['champ'] pour éviter les erreurs si le champ est absent.
6. Gérer les erreurs (pattern Try/Catch)
Structure recommandée :
[Scope] TRY
├── Action 1
├── Action 2
└── Action N
[Scope] CATCH
Configure run after: TRY → has failed / has timed out / has been skipped
├── Compose — ErrorDetails:
│ concat('Erreur: ', result('Scope_TRY')?[0]?['error']?['message'])
├── Send email — notif à l'équipe
└── Terminate — Status: Failed, Message: outputs('Compose_ErrorDetails')
Politique de retry sur chaque action HTTP/connecteur :
- Default : 4 retries, intervalles exponentiels — suffisant dans 90 % des cas
- Fixed : utile pour les APIs avec rate-limiting strict (ex: toutes les 60 s)
- None : actions idempotentes où un double-appel serait problématique
7. Tester et déboguer
- Test manuel : déclencher depuis le portail, vérifier chaque entrée/sortie dans l'historique d'exécution (icône "..." > Run history).
- Testeur d'expressions : dans le champ d'expression, cliquer sur "Peek code" pour valider sans exécuter le flow.
- Compose de debug : ajouter temporairement un
Composeavecoutputs()pour inspecter un objet complet. - Données de test réalistes : inclure champs vides, caractères spéciaux (
&,<,"), tableaux vides, valeurs null. - Vérifier les limites : 30 jours de rétention historique (plan standard), 5 minutes max par action (timeout).
8. Déployer entre environnements
Toujours passer par les Solutions (pas les flows standalone) :
Power Platform Admin Center
└── Solutions > New solution
├── Add existing > Cloud flows
├── Add existing > Custom connectors
└── Add existing > Connection references ← clé pour les connexions env-spécifiques
Export/import entre environnements :
# Via Power Platform CLI (pac)
pac solution export --path ./solution.zip --name MonSolution --managed false
pac solution import --path ./solution.zip --environment prod-env-id
Les Connection References permettent de pointer vers des connexions différentes par environnement sans modifier le flow.
Anti-patterns / Pièges
| Piège | Impact | Correction |
|---|---|---|
Apply to each imbriqués sur grands volumes |
Timeout 30 min, throttling | Requêtes OData filtrées côté source ; traitement par batch |
| Modifier un flow directement en production | Pas de rollback possible | Solutions + pipeline ALM (GitHub Actions / Azure DevOps) |
Stocker des credentials dans Compose ou des commentaires |
Fuite de secrets dans l'historique | Connecteur custom avec API Key, Azure Key Vault via HTTP |
Ignorer Configure run after |
Échecs silencieux, données corrompues | Toujours configurer le CATCH sur chaque scope critique |
Utiliser Get items sans filtre OData |
Quota de 5 000 lignes SharePoint épuisé | Filtre $filter=Status eq 'Pending' + $top=100 avec pagination |
| Trigger "When an item is created or modified" en boucle | Infinite loop si le flow modifie le même item | Ajouter une colonne FlowProcessed ou vérifier le Modified by |
Bonnes pratiques 2026
- Nommer toutes les actions (jamais laisser "Send an email (V2)") — l'historique et les expressions
outputs('NomAction')en dépendent. - Utiliser les environnements Managed (Power Platform Managed Environments) pour activer le DLP et les politiques de gouvernance.
- Documenter dans les descriptions de chaque action — le champ "Note" est consultable sans ouvrir le flow.
- Éviter les connecteurs Premium inutiles : un connecteur HTTP standard peut remplacer un connecteur Premium si l'API est accessible publiquement.
- Activer le journal d'audit (Microsoft Purview) pour les flows manipulant des données sensibles.
- Versionner les solutions avec semantic versioning (1.0.0 → 1.1.0) avant chaque déploiement en production.
Communication Rules — MANDATORY
- Ultra-concise. No filler, no preamble, no pleasantries.
- Never say "happy to help", "sure!", "great question", "let me", or similar.
- Tool first, talk second. Act before explaining.
- Result first. Lead with outcome, not process.
- Stop when done. No summary, no recap, no trailing commentary.
- No politeness wrappers. Direct and blunt.
- Minimum words. If one word works, do not use ten.
- No unsolicited explanations.
- No emoji unless asked.