Power Automate : cinq règles pour des automatisations qui tiennent en production

Automatiser une tâche avec Power Automate prend une après-midi. Un formulaire arrive, un courriel part ; une facture est déposée, une approbation est demandée ; une ligne est ajoutée, un tableau se met à jour. Le premier flux fonctionne, on en crée un deuxième, puis un dixième.

Les problèmes arrivent plus tard, et ils ne font pas de bruit. Un flux affiche « réussi » alors qu’il n’a rien fait. Un autre attend des données que plus rien ne lui envoie. Un troisième a été créé par un collaborateur parti depuis, et personne ne sait ce qu’il fait. Automatiser sans code est facile ; faire en sorte que ça tienne ne l’est pas.

Voici ce que nous avons appris en construisant nos propres automatisations.

1. Ce que Power Automate permet, et ce que la licence autorise

Un flux Power Automate part d’un déclencheur — un courriel reçu, un fichier déposé, une heure programmée — et enchaîne des actions dans d’autres applications grâce à des connecteurs : Outlook, SharePoint, Teams, Excel, et des centaines d’autres.

La licence compte davantage qu’on ne le croit. Une licence gratuite permet de créer des flux, mais uniquement avec les connecteurs dits standard, et sans pouvoir les partager. Dès qu’un flux doit utiliser un connecteur premium ou un connecteur personnalisé, il faut une licence Power Automate Premium. Et pour qu’un flux tourne indépendamment de la personne qui l’a créé, Microsoft propose une licence dite Process, attribuée au flux lui-même — à condition qu’il soit rangé dans une solution, nous y reviendrons.

Vérifiez ce point avant de construire : découvrir, flux terminé, qu’un connecteur exige une licence que personne n’a, coûte une semaine.

Un autre plafond se découvre souvent trop tard : le nombre d’actions par jour. Chaque étape exécutée par un flux compte comme une action. Microsoft fixe une limite quotidienne — 40 000 actions par utilisateur disposant d’une licence Premium, 250 000 par licence Process. Un flux qui parcourt chaque nuit plusieurs milliers de lignes, avec une dizaine d’étapes pour chacune, peut l’atteindre bien plus vite qu’on ne l’imagine. Estimez le volume avant de concevoir : nombre d’éléments par exécution, multiplié par le nombre d’étapes, multiplié par le nombre d’exécutions par jour.

2. Notre cas : un relais qui ne perd rien

Notre académie en ligne collecte des informations — inscriptions, résultats de diagnostic — qui doivent arriver dans notre CRM. Un flux s’en charge toutes les dix minutes : il va chercher ce qui attend sur le site, l’écrit dans le CRM, puis confirme au site ce qui a bien été traité.

Le choix de faire venir chercher les données plutôt que de les pousser a une conséquence utile : si le CRM est indisponible un moment, rien n’est perdu. Les données attendent sur le site, et partent au cycle suivant, sans que personne ait à intervenir.

Ce fonctionnement paraît banal. Il repose pourtant sur des choix qui font toute la différence, et que résument les règles suivantes.

3. Cinq règles apprises sur nos propres flux

Règle 1 — Ne confirmer qu’après avoir écrit. Notre relais ne dit au site « c’est traité » qu’une fois l’écriture dans le CRM réussie. Si le flux s’interrompt au milieu — coupure, erreur, maintenance —, rien n’a été confirmé, et tout repasse au cycle suivant. C’est la différence entre un flux qui perd des données en silence et un flux qui, au pire, les traite dix minutes plus tard.

Règle 2 — Pouvoir rejouer sans créer de doublon. Puisqu’un élément peut repasser, le flux doit pouvoir le traiter deux fois sans rien dupliquer. La méthode : chaque élément porte un identifiant unique, et le flux met à jour l’enregistrement existant au lieu d’en créer un nouveau. Et un élément qui échoue plusieurs fois de suite gagne à être mis à l’écart pour examen, plutôt que de repasser indéfiniment.

Règle 3 — Un « succès » ne prouve rien s’il n’y avait rien à traiter. L’historique d’un flux affiche « réussi » dès que le flux s’est exécuté sans erreur — y compris quand il n’avait aucune donnée à traiter. Un flux peut ainsi réussir des centaines de fois sans avoir jamais rien écrit. La seule preuve qu’une automatisation fonctionne, c’est une vraie donnée qui la traverse de bout en bout et qu’on retrouve à l’arrivée.

Règle 4 — Vérifier les deux bouts de la chaîne. Une chaîne d’automatisation a un bout qui écrit et un bout qui lit. Les deux peuvent tomber en panne sans rien signaler : un flux qui remplit une table que plus personne ne consulte, ou un flux qui attend une donnée que plus rien n’envoie. Dans les deux cas, aucune erreur ne s’affiche — il ne se passe simplement rien. Quand on arrête ou modifie un flux, on se demande toujours qui l’alimentait et qui dépendait de lui.

Règle 5 — Le nom d’un flux ne dit pas ce qu’il fait. « Relais site vers CRM » : lequel des sites ? Quelle table ? Un nom rassure, il ne prouve rien. Documentez chaque flux — ce qu’il lit, ce qu’il écrit, qui en répond — et rangez-le dans une solution. Une solution rend le flux portable : on le développe et on le teste dans un environnement, puis on le déploie en production, au lieu de le modifier directement là où il sert. C’est aussi la condition pour lui attribuer une licence Process.

4. Par où commencer

Les meilleurs premiers flux ont trois qualités : ils suppriment une tâche répétitive que quelqu’un fait réellement chaque semaine, ils touchent peu de systèmes, et leur échec se voit tout de suite.

Quelques exemples qui remplissent ces conditions :

• l’accusé de réception d’une demande envoyée par un formulaire, avec copie au responsable concerné ;
• l’approbation d’une dépense : la demande part au responsable, sa réponse revient au demandeur et s’inscrit dans une liste ;
• le classement des pièces jointes reçues dans une boîte partagée vers le bon dossier SharePoint ;
• le rappel d’une échéance inscrite dans une liste, quelques jours avant la date.

Commencez par un seul, faites-le traverser par une vraie donnée, et documentez-le avant de passer au suivant.

Ce qu’il ne faut pas automatiser, en revanche : un processus mal défini. Si trois personnes traitent la même demande de trois façons différentes, automatiser l’une des trois ne règle rien — cela rend le désordre plus rapide, et plus difficile à corriger. Avant de construire le flux, écrivez le processus : qui reçoit quoi, qui décide, que se passe-t-il en cas de refus ou d’absence. Si vous n’arrivez pas à l’écrire en une page, le problème n’est pas encore l’automatisation.

5. Cinq questions avant d’automatiser

1. Qui fait cette tâche aujourd’hui, et combien de fois par semaine ? Sans réponse précise, le gain est une impression.
2. Quels connecteurs faut-il, et votre licence les couvre-t-elle ?
3. Que se passe-t-il si le flux s’arrête au milieu ? Des données perdues, ou traitées plus tard ?
4. Comment saurez-vous qu’il fonctionne, autrement que par le mot « réussi » ?
5. Qui en répond quand son créateur sera absent ou parti ?

Une automatisation qui répond à ces cinq questions fera gagner du temps pendant des années. Les autres en feront perdre, un jour, à quelqu’un qui ne saura pas pourquoi.

SIGA IT Consulting conçoit et déploie des automatisations Power Automate pour les entreprises d’Afrique centrale. Découvrez notre offre Applications d’entreprise — ou commencez par mesurer où en est votre entreprise avec notre diagnostic de maturité.