Automatiser un processus : prévoir aussi son exploitation

Un flux qui réussit une démonstration peut rester fragile au quotidien. Il faut aussi savoir ce qui se passe lorsqu’une demande arrive deux fois, qu’un approbateur est absent ou qu’un service répond trop tard. La conception d’une automatisation Power Platform doit inclure son fonctionnement métier et les moyens de l’exploiter après sa mise en service.

Le bon point de départ est un processus circonscrit, avec un résultat observable et une personne capable de dire s’il est correct. Supprimer une validation inutile ou clarifier un formulaire peut apporter davantage que l’automatisation d’un circuit confus.

1. Écrire le contrat du processus

Décrivez le déclencheur, les données nécessaires, la règle de décision et l’effet attendu. Définissez les états métier : reçu, incomplet, en attente, accepté, refusé, traité ou à reprendre. Chaque état doit avoir une signification lisible par l’équipe, sans dépendre d’un code d’erreur technique.

Précisez les cas qui nécessitent une décision humaine. Un flux peut préparer un document sans être autorisé à l’envoyer, ou enregistrer une demande sans engager une dépense. Ces limites doivent apparaître dans les étapes et les droits de connexion. Pour chaque action engageante, indiquez qui l’autorise, quelles données sont présentées et ce qu’un refus produit.

Recensez les dépendances : formulaires, listes, bibliothèques, applications, connecteurs et services externes. Relevez aussi les volumes attendus, les périodes de pointe et le délai acceptable.

2. Traiter les doublons comme un cas normal

Une notification peut être reçue plusieurs fois ; un utilisateur peut soumettre à nouveau une demande. Prévoyez une clé stable fondée sur l’événement métier, par exemple l’identifiant de la demande et la version de l’opération. Une heure d’exécution ou un nom affiché ne constitue généralement pas une bonne clé.

Avant de produire un effet, enregistrez cette clé dans un stockage adapté avec un mécanisme empêchant réellement les doublons : contrainte d’unicité ou écriture conditionnelle, selon la solution retenue. Lire « absent » puis créer sans protection laisse deux exécutions concurrentes effectuer le même travail. Limiter la concurrence peut aider, mais ne remplace pas l’unicité durable.

Conservez l’état du traitement et l’identifiant de l’objet créé. À la deuxième réception, le flux doit retrouver le résultat existant, poursuivre une étape inachevée ou demander un arbitrage. C’est l’objectif de l’idempotence : rejouer une demande ne doit pas multiplier son effet métier.

Exemple : une demande d’achat interne

Dans ce scénario illustratif, une demande approuvée doit créer un dossier de suivi puis avertir le demandeur. La clé du traitement associe l’identifiant de demande à sa révision approuvée. Un refus clôt le circuit sans créer le dossier ; une modification substantielle déclenche une nouvelle révision à approuver.

Le flux enregistre séparément « dossier créé » et « notification traitée ». S’il s’arrête après la création, la reprise retrouve le dossier grâce à son identifiant et poursuit le contrôle de notification. Elle ne recommence pas toute la chaîne.

Un cas reste délicat : le service d’envoi accepte un message, mais la réponse se perd. L’absence de confirmation ne prouve pas l’absence d’envoi. Si le service ne fournit pas de clé d’idempotence ou de recherche fiable, placez cette notification dans un état à vérifier plutôt que de promettre un envoi exactement une fois. Le même raisonnement est essentiel pour un paiement ou une commande.

3. Construire une reprise explicite

Dans Power Automate, les groupes d’actions et les paramètres d’exécution après une étape permettent de distinguer le chemin normal et le traitement d’échec. Les politiques de nouvelle tentative servent à absorber certaines erreurs transitoires. Microsoft décrit ces mécanismes dans son guide de gestion des erreurs.

Choisissez les reprises selon la nature de l’action. Une indisponibilité temporaire peut justifier des tentatives espacées et limitées ; une donnée obligatoire absente ou un accès refusé demande une correction. Rejouer aveuglément une action qui crée un objet ou envoie un message peut produire un doublon.

Le journal doit permettre de répondre à quatre questions : quelle demande, quelle étape, quel résultat connu et quelle action reste possible ? Enregistrez un identifiant de corrélation, l’état et un message exploitable. Évitez de recopier des pièces jointes ou données sensibles dans chaque alerte. Un responsable doit pouvoir arrêter le flux, corriger la cause et reprendre un dossier identifié sans modifier l’historique au hasard.

4. Donner un propriétaire au service rendu

Le propriétaire métier décide des règles ; le responsable technique suit les connexions, erreurs et évolutions. Documentez les deux rôles et leur remplacement. Vérifiez ce qui arriverait si le créateur du flux changeait de poste ou perdait un droit.

Un principal de service peut être propriétaire de certains flux Power Automate, mais ce choix exige de vérifier les connexions, les prérequis et les règles de licence applicables. Il ne dispense pas de licence par principe. Les possibilités sont détaillées dans la documentation sur les flux appartenant à un principal de service.

Pour chaque connecteur, contrôlez la catégorie de licence, l’identité utilisée, les permissions et les restrictions de l’environnement. Tenez compte du type de déclenchement et des utilisateurs concernés ; la présence d’un abonnement Microsoft 365 ne suffit pas à déduire tous les droits Power Automate. Validez la configuration réelle avec l’administrateur avant de fixer le coût d’exploitation.

Préparez enfin le passage entre développement, test et production. Les références de connexion, paramètres et destinations doivent pouvoir changer sans rechercher manuellement des adresses dispersées dans le flux. Conservez une version exportable et une courte procédure de retour à la version précédente.

5. Faire une recette qui cherche les échecs

Essai	Résultat attendu
Demande complète	Un résultat métier correct et relié à sa demande.
Même événement reçu deux fois	Aucun second effet métier.
Deux réceptions simultanées	Une seule réservation de la clé de traitement.
Donnée absente ou refus métier	Un état compréhensible, sans action engageante.
Arrêt après une création	Reprise à partir du résultat déjà créé.
Réponse d’envoi incertaine	Vérification ou rapprochement prévu avant tout nouvel envoi.
Connexion expirée	Alerte reçue par le responsable et réparation documentée.

Mesurez les demandes terminées, les erreurs, les reprises manuelles, les doublons et le délai de traitement. Vérifiez qu’une alerte conduit à une action réelle. La mise en service suppose des résultats acceptés par le métier, une licence vérifiée et une reprise effectuée en test, au-delà du seul voyant vert d’une exécution.

Les sources Microsoft ont été consultées le 23 octobre 2026. Le scénario ci-dessus est un exemple de conception ; aucune exécution dans un environnement client n’est revendiquée.

IA et automatisation métier · Support