Les 3 erreurs les plus fréquentes de conception d'un flux Power Automate

 

Au fil des missions réalisées pour différents clients, j'ai pu constater que les mêmes erreurs reviennent régulièrement dans la conception de flux Power Automate.

Elles ne sont pas toujours visibles au premier abord, mais peuvent rapidement nuire à la lisibilité, à la fiabilité et à la maintenabilité de vos automatisations !

Voici selon moi, les trois erreurs les plus courantes… et les bonnes pratiques à adopter pour les éviter.


#1 - Des actions mal nommées

❌  “Condition 12”, “Apply to each 4”, “Compose 5”…

Ces noms par défaut peuvent sembler anodins au départ, mais deviennent vite un cauchemar à maintenir.

Pourquoi c’est une erreur :

Lorsqu’un flux devient complexe, il devient presque impossible de s’y retrouver. Et si une autre personne doit le reprendre, le débogage devient un véritable parcours du combattant.

💡 La bonne pratique :

Appliquer une règle de nommage commune à tous les flux qui :

  • Conserve le nom de l’action initial
  • Respecte la nomenclature camelCase (ou à minima en évitant les espaces dans le texte ajouté)
  • Résume ce que fait cette action simplement

✅  “Condition - ifDocumentFound ”, “Apply to each - documentFound”, “Compose - formatCreationDate”…

C’est un réflexe simple, mais essentiel pour assurer la compréhension et la maintenance dans la durée.


#2 - Aucune gestion d’erreur

Un appel HTTP échoue ? Une donnée est manquante ? Le flux s’arrête… sans prévenir.

Pourquoi c’est une erreur :

Sans gestion d’erreur, les anomalies ne sont détectées qu’après coup — souvent par les utilisateurs finaux. Cela crée de la frustration et nuit à la confiance dans l’outil.

💡 La bonne pratique :

Mettre en place des contrôles d’erreur avec les conditions “Run after” ou des branches parallèles prévoyant une notification automatique (via Teams ou e-mail).

Un flux robuste, c’est un flux capable de se relever tout seul lorsqu’un incident survient.

Exemple de d'intégration de "Run after" dans un flux

#3 - Trop de conditions imbriquées

Si A, alors B… sauf si C, mais seulement si D.

Le résultat : ce n'est plus un flux mais une épopée 

Pourquoi c’est une erreur :

Les conditions imbriquées rendent la lecture difficile, la maintenance fastidieuse et les évolutions risquées.

💡 La bonne pratique :

Simplifier la logique avec des expressions conditionnelles ou l’action “Switch”.

Exemple d'action "Switch" pour remplacer des conditions imbriquées

Et si le processus devient trop complexe, envisager de le découper en plusieurs flux plus ciblés.


En résumé

Un bon flux Power Automate, c’est comme un bon process : il doit être clair, prévisible et facile à faire évoluer.

Concevoir un flux, ce n’est pas empiler des actions : c’est structurer une logique métier de façon lisible et durable.