Rendre un flow Power Automate plus robuste : conditions, boucles et gestion des erreurs
Dernière mise à jour : 11 sept.
Vous savez maintenant créer un flow, utiliser un déclencheur, transmettre des données entre plusieurs étapes et lire l’architecture générale d’une automatisation.
Mais un flow simple fonctionne souvent uniquement dans le scénario idéal.
Un email arrive avec les bonnes informations, une seule pièce jointe est présente, le fichier possède le bon format et toutes les connexions répondent correctement.
Dans la réalité, les données sont rarement aussi propres.
Un email peut ne contenir aucune pièce jointe. Il peut en contenir plusieurs. Un fichier peut avoir un format inattendu. Une information peut être absente ou mal renseignée.
Une automatisation professionnelle ne doit pas seulement savoir quoi faire lorsque tout se passe bien.
Elle doit également savoir quoi faire lorsque la situation sort du scénario prévu.
Dans cet article, nous allons construire un cas fil rouge qui utilise :
une condition ;
une boucle ;
une expression simple ;
une gestion des cas non conformes ;
une notification de contrôle.
L’objectif n’est pas de rendre le flow inutilement complexe.
L’objectif est de le rendre capable de traiter la réalité.
Le cas fil rouge
Imaginons un processus dans lequel une équipe reçoit régulièrement des emails contenant des documents en pièce jointe.
Le traitement attendu est le suivant :
détecter les nouveaux emails ;
vérifier si une pièce jointe est présente ;
traiter chaque pièce jointe individuellement ;
enregistrer uniquement les fichiers PDF ;
prévenir l’équipe lorsqu’un fichier ne respecte pas la règle.
La logique générale peut être représentée ainsi :
Nouvel email
↓
Une pièce jointe est-elle présente ?
├── Non : arrêter ou notifier
└── Oui
↓
Pour chaque pièce jointe
↓
Le fichier est-il un PDF ?
├── Oui : enregistrer le fichier
└── Non : envoyer une alerteCe scénario est volontairement simple, mais il ressemble déjà davantage à un processus professionnel qu’à une simple automatisation du type :
Email → Action → Fin
Pourquoi ce cas est intéressant
Ce flow permet de montrer une différence essentielle.
Dans un flow basique, on suppose que les données sont toujours disponibles et conformes.
Dans un flow robuste, on vérifie les hypothèses avant d’utiliser les informations.
Le flow doit notamment gérer plusieurs situations :
aucun fichier n’est joint ;
un seul fichier est joint ;
plusieurs fichiers sont joints ;
le fichier est un PDF ;
le fichier possède un autre format ;
une étape de traitement échoue.
Cette logique apparaît dans de nombreux processus :
classer des documents ;
traiter plusieurs lignes Excel ;
analyser plusieurs fichiers ;
vérifier des réponses de formulaire ;
enregistrer des pièces justificatives ;
transmettre les exceptions à une équipe.
Les outils changent, mais la structure reste souvent la même.
Étape 1: Déclencher le flow au bon moment
Le flow commence avec le déclencheur Outlook :
Lorsqu’un nouvel email arrive (V3)
Dans ses paramètres, vous pouvez notamment définir :
le dossier surveillé ;
la présence éventuelle de pièces jointes ;
certains filtres liés à l’email.
Pour ce scénario, activez la récupération des pièces jointes.
Le déclencheur doit fournir au flow les informations nécessaires pour la suite du traitement.
Cette étape mérite déjà une vérification importante :
Le déclencheur récupère-t-il réellement les fichiers dont les étapes suivantes auront besoin ?
Un flow peut être correctement construit et pourtant ne pas fonctionner si une donnée essentielle n’est pas disponible dès le départ.
Étape 2: Vérifier si une pièce jointe existe
Avant de traiter un fichier, il faut vérifier qu’un fichier existe réellement.
Ajoutez une condition qui contrôle la présence d’au moins une pièce jointe.
La logique est la suivante :
Si l’email contient une pièce jointe, poursuivre le traitement.Sinon, arrêter le flow ou envoyer une notification.
Cette condition évite de lancer inutilement les étapes suivantes.
Elle permet également de définir explicitement le comportement du flow dans un cas souvent oublié : l’email sans pièce jointe.
Vous pouvez choisir de :
terminer le flow sans action ;
envoyer une notification ;
enregistrer l’email pour analyse ;
orienter le message vers une file de traitement manuel.
Le choix dépend du processus métier.
L’important est de ne pas laisser ce scénario sans réponse.
Étape 3: Traiter chaque pièce jointe avec une boucle
Un email peut contenir un seul fichier, mais aussi plusieurs.
Créer une série d’actions séparées pour chaque fichier serait difficile à maintenir.
Power Automate propose une boucle, souvent appelée Apply to each, qui permet de répéter les mêmes actions pour chaque élément d’une liste.
La logique devient :
Pour chaque pièce jointe trouvée, exécuter les mêmes étapes.
À l’intérieur de cette boucle, le flow peut :
lire le nom du fichier ;
récupérer son extension ou son type ;
vérifier s’il respecte la règle ;
l’enregistrer ou déclencher une alerte.
La boucle permet donc de traiter un nombre variable de fichiers avec une seule structure.
Que l’email contienne un fichier ou cinq, le flow réutilise le même traitement.
[Visuel : plusieurs fichiers entrant dans une boucle puis produisant un résultat]
Une notion importante : le changement de contexte
À l’intérieur d’une boucle, les données utilisées ne sont plus exactement les mêmes que celles de l’email global.
Le flow manipule désormais l’élément en cours.
Il faut donc distinguer :
les informations de l’email complet ;
la pièce jointe actuellement traitée ;
les données produites par une action précédente.
Cette distinction est une source fréquente d’erreurs.
Une action peut fonctionner correctement pour le premier fichier, mais utiliser une mauvaise référence pour les suivants si le contexte n’est pas compris.
Lorsque vous travaillez dans une boucle, vérifiez toujours :
Quelle donnée suis-je en train d’utiliser à cette étape ?
Étape 4: Vérifier le format du fichier
Dans notre exemple, seuls les fichiers PDF doivent être enregistrés.
Ajoutez donc une nouvelle condition à l’intérieur de la boucle.
La logique est la suivante :
Si le fichier correspond au format attendu, l’enregistrer.Sinon, envoyer une alerte.
Pour un premier contrôle simple, vous pouvez vérifier l’extension du nom de fichier avec une expression comme :
endsWith(nom_du_fichier, '.pdf')Cette expression renvoie une réponse vraie ou fausse selon le nom analysé.
Il est également possible de comparer le type MIME ou d’utiliser une logique plus stricte selon le niveau de fiabilité attendu.
Pour un exercice débutant, le contrôle de l’extension suffit à comprendre le principe :
la boucle sélectionne un fichier ;
la condition vérifie une règle ;
le résultat détermine la suite du traitement.
Pensez toutefois à prévoir les variantes possibles, comme les extensions écrites en majuscules ou les fichiers mal nommés.
Un contrôle par extension est pratique, mais il ne constitue pas à lui seul une validation complète du contenu du fichier.
Étape 5: Enregistrer les fichiers conformes
Si le fichier respecte la règle, le flow peut l’enregistrer dans SharePoint ou OneDrive.
Choisissez un emplacement clair et stable, par exemple :
/Documents/Emails traités/Le nom du fichier doit également être géré avec attention.
Un nom construit uniquement à partir de la pièce jointe peut provoquer un écrasement si deux emails contiennent un fichier portant le même nom.
Vous pouvez donc intégrer une information complémentaire :
la date de réception ;
un identifiant ;
le nom de l’expéditeur ;
une référence issue de l’email.
L’objectif est d’obtenir un fichier :
correctement classé ;
identifiable ;
retrouvable ;
difficile à écraser par erreur.
Cette étape paraît simple, mais les problèmes de nommage et de classement deviennent rapidement importants lorsque le volume augmente.
Étape 6: Alerter lorsqu’un fichier n’est pas conforme
Si la pièce jointe n’est pas un PDF, le flow ne doit pas nécessairement s’arrêter brutalement.
Il peut prévenir une personne ou une équipe afin qu’une décision soit prise.
Une notification utile doit contenir suffisamment d’informations pour permettre une action rapide :
Pièce jointe non conformeSujet : [sujet de l’email]Fichier : [nom du fichier]Expéditeur : [expéditeur]Raison : format non accepté
Une notification qui indique simplement Erreur dans le flow oblige le destinataire à effectuer lui-même toute la recherche.
Une bonne alerte transforme un problème technique en information exploitable.
Elle doit permettre de comprendre :
ce qui s’est produit ;
sur quel élément ;
dans quel contexte ;
quelle intervention est attendue.
Ce que ce flow vous apprend vraiment
Ce cas ne sert pas uniquement à classer des fichiers.
Il montre comment construire un flow qui s’adapte aux situations rencontrées.
Vous avez utilisé :
un déclencheur ;
une condition avant la boucle ;
une boucle sur une collection ;
une condition à l’intérieur de la boucle ;
une action de sortie ;
une gestion du cas non conforme.
La structure complète ressemble maintenant à ceci :
Déclencheur
↓
Condition : une pièce jointe existe ?
├── Non : arrêter ou notifier
└── Oui
↓
Boucle : pour chaque pièce jointe
↓
Condition : le fichier est-il conforme ?
├── Oui : enregistrer
└── Non : alerterC’est cette capacité à gérer plusieurs chemins qui distingue une automatisation réellement exploitable d’une simple démonstration.
Les erreurs que j’ai faites
Mettre la condition au mauvais endroit
Au début, il m’est arrivé de vérifier la présence d’une pièce jointe avant la boucle, puis de considérer que cette vérification suffisait pour tous les fichiers.
Mais une condition sur l’email ne remplace pas une condition sur chaque pièce jointe.
La bonne structure est :
Vérifier qu’une collection existe → parcourir chaque élément → contrôler chaque élément.
La position d’une condition dans le flow peut donc modifier complètement le résultat.
Oublier le changement de contexte dans Apply to each
À l’intérieur de la boucle, le flow traite l’élément en cours.
Si vous utilisez par erreur une donnée issue de l’email global au lieu de la pièce jointe actuelle, le résultat peut devenir incohérent.
Je vérifie maintenant systématiquement la source de chaque champ utilisé dans une boucle.
Ne pas prévoir le cas sans pièce jointe
Même si la majorité des emails contient un fichier, certains messages n’en auront pas.
Un flow qui suppose toujours qu’une pièce jointe existe finira par échouer.
Le cas “aucune pièce jointe” doit être prévu dès la conception.
Créer une alerte trop vague
Une alerte sans contexte ne permet pas de corriger rapidement le problème.
Aujourd’hui, j’essaie toujours d’inclure dans mes notifications :
l’identifiant du traitement ;
le sujet ;
l’élément concerné ;
la raison du problème ;
l’action attendue.
Une bonne gestion des erreurs ne consiste pas à signaler qu’un problème existe.
Elle consiste à rendre ce problème compréhensible.
Tester avec plusieurs scénarios
Un flow ne doit pas être testé uniquement avec le cas parfait.
Pour notre exemple, je testerais au minimum :
un email sans pièce jointe ;
un email avec un seul PDF ;
un email avec plusieurs PDF ;
un email avec un fichier non conforme ;
un email contenant plusieurs formats ;
un fichier dont le nom est inhabituel.
Ces tests permettent de vérifier non seulement que le chemin principal fonctionne, mais aussi que les exceptions sont correctement traitées.
Un flow qui fonctionne une fois n’est pas nécessairement fiable.
Il faut vérifier comment il réagit lorsque les données changent.
Comment j’utilise cette logique aujourd’hui
Dans mes automatisations email, je ne me demande plus seulement :
Que doit faire le flow lorsque tout se passe bien ?
Je me demande aussi :
que faire si une donnée est absente ?
que faire si plusieurs éléments arrivent en même temps ?
que faire si le format reçu est inattendu ?
que faire si une action échoue ?
qui doit être prévenu ?
quelles informations cette personne doit-elle recevoir ?
Cette manière de raisonner m’aide à concevoir des flows plus fiables avant même de les construire.
Elle permet également de mieux distinguer :
le chemin principal ;
les cas particuliers ;
les erreurs techniques ;
les situations nécessitant une intervention humaine.
L’objectif n’est pas de tout automatiser à n’importe quel prix.
L’objectif est de savoir précisément ce qui peut être automatisé et ce qui doit encore être contrôlé par une personne.
En résumé
Une automatisation professionnelle doit gérer autre chose que le scénario idéal.
Les conditions permettent de contrôler les données avant d’agir.
Les boucles permettent de traiter plusieurs éléments sans dupliquer les actions.
Une condition doit être placée au bon niveau du processus.
Le contexte change à l’intérieur d’une boucle.
Les expressions simples permettent de contrôler plus finement les données.
Une alerte doit contenir suffisamment d’informations pour être exploitable.
Un flow doit être testé avec plusieurs scénarios, y compris les cas incomplets et inattendus.
Pour aller plus loin
Les guides et templates proposés sur SupplyChainKingdom suivent la même philosophie : construire des automatisations simples, utiles et capables de gérer les situations réelles.
L’objectif n’est pas d’ajouter de la complexité.
C’est de créer des flows suffisamment fiables pour pouvoir leur faire confiance.
Commentaires