Sauvegarder des flux : stratégie de sauvegarde par export de solution dans Power Automate

Un flux qui a évolué pendant des mois, utilise plusieurs connexions et fonctionne en production dans plusieurs services peut être perdu rapidement si un environnement est supprimé, un statut de licence change, ou un flux est écrasé par accident. Power Automate ne propose pas de bouton « Enregistrer » classique comme on en connaît avec un logiciel de sauvegarde traditionnel. À la place, toute sauvegarde fiable passe par le même mécanisme que celui prévu pour déplacer des flux entre environnements : l'export d'une solution.

Cet article montre, à partir de la documentation officielle de Microsoft, comment exporter des flux via des solutions, quelle différence font les solutions gérées et non gérées, et comment en tirer une routine de sauvegarde reproductible. Tu gardes ainsi le contrôle sur la possibilité de restaurer tes automatisations en cas d'urgence, au lieu de le découvrir seulement après une perte de données. À jour en : juillet 2026.

Pourquoi Power Automate n'a pas de sauvegarde intégrée

Au quotidien, un flux unique peut être créé, modifié et exécuté sans aucune routine d'export, sans que tu aies à te soucier d'une solution. C'est précisément ce qui devient un problème en cas d'urgence : sans solution, un flux n'existe que comme objet isolé dans un environnement, sans copie versionnée ailleurs. Selon la documentation Microsoft sur l'export de solutions, c'est justement pour cette raison qu'une solution non gérée devrait être créée : « afin de pouvoir créer une copie de sauvegarde en cas de besoin ». Une sauvegarde n'est donc pas un processus automatique en arrière-plan, mais une étape d'export délibérée, que tu déclenches toi-même régulièrement ou que tu automatises.

Les solutions, fondement de toute stratégie de sauvegarde

Avant qu'une sauvegarde ne fonctionne, le flux doit d'abord faire partie d'une solution. La documentation sur les concepts de solution distingue deux types :

• Les solutions non gérées correspondent à l'état de développement. Elles peuvent être modifiées librement et exportées aussi bien en non géré qu'en géré. C'est précisément cette version non gérée qui est considérée comme la véritable source de tes ressources Power Platform et qui devrait être archivée dans un système de gestion de versions.
• Les solutions gérées sont des artefacts de build finalisés, importés dans des environnements de test ou de production. Elles ne peuvent plus être modifiées directement et, ce qui est décisif pour une stratégie de sauvegarde, elles ne peuvent pas non plus être exportées.

Pour qu'une sauvegarde fonctionne, cela signifie : le flux doit se trouver dans une solution non gérée, car c'est uniquement à partir de là que tu peux déclencher un export. Si un flux ne fait pour l'instant partie que de la solution par défaut, il doit d'abord être ajouté à une solution propre et nommée avant qu'un export utile soit possible.

Étape par étape : exporter une solution

Le guide pour exporter une solution décrit la procédure directement dans Power Automate :

• Connecte-toi à Power Automate et sélectionne Solutions dans la navigation de gauche.
• Sélectionne la solution non gérée qui contient le flux, puis clique sur Exporter.
• Dans la section Avant d'exporter, tu devrais activer Publier toutes les personnalisations, car l'export d'une solution non gérée n'emporte que les composants publiés. Tu peux aussi, en option, lancer le vérificateur de solution pour détecter des problèmes de performance et de stabilité.
• Attribue un numéro de version et choisis Exporter en tant que soit Géré soit Non géré. Pour une simple copie de sauvegarde, l'export non géré est le bon choix, car il reste modifiable par la suite.
• Après l'export, un fichier ZIP est disponible au téléchargement. Il contient les flux dans le dossier Workflows, chacun sous forme de fichier JSON distinct. Depuis février 2022, ce format est produit sur plusieurs lignes, justement pour pouvoir être suivi proprement dans un système de gestion de versions comme Git.

Une remarque du même guide mérite d'être gardée en tête avant chaque export : les valeurs des variables d'environnement devraient être supprimées avant l'export, afin qu'aucune valeur spécifique à l'environnement, comme une URL de serveur de test, ne se retrouve par inadvertance dans la sauvegarde et ne réapparaisse lors d'une restauration dans le mauvais environnement.

Sauvegarder des flux isolés sans solution

Tous les flux ne font pas déjà partie d'une solution. Pour ce cas, la documentation sur l'export et l'import de flux hors solution décrit une seconde méthode : l'export classique en paquet, sous forme de fichier ZIP, via Mes flux et l'élément de menu Exporter > Package (.zip). Important en pratique :

• Seul le propriétaire ou copropriétaire d'un flux peut l'exporter de cette façon.
• Pour l'import dans un autre environnement, le rôle Créateur d'environnement y est requis.
• Les paquets de flux ne peuvent pas être mélangés avec des paquets de solution Dataverse ; les deux formats sont incompatibles.

Microsoft indique explicitement, au même endroit, que pour une véritable gestion du cycle de vie applicatif, Dataverse et les solutions constituent la voie recommandée, l'export en paquet restant donc plutôt une solution de transition pour des flux isolés, non éligibles à une solution. Pour une stratégie de sauvegarde fiable portant sur plusieurs flux, il n'existe pas d'alternative aux solutions.

Restauration : importer une solution

Une sauvegarde ne vaut que par sa capacité à être restaurée. La documentation sur l'import d'une solution retient à ce sujet quelques détails importants en cas d'urgence :

• Une solution ne peut pas être importée dans un environnement où la même solution existe déjà. Pour tester une restauration, il te faut donc un environnement séparé.
• Après l'import, tous les composants inclus, c'est-à-dire les flux, les références de connexion et les applications, appartiennent à l'utilisateur qui a effectué l'import.
• Si les flux étaient activés au moment de l'export et que toutes les références de connexion obtiennent des connexions valides lors de l'import, ils sont automatiquement réactivés. Si un flux existe déjà dans le système cible, son état actuel (activé ou désactivé) reste en revanche inchangé.
• Pendant l'import, tous les flux de la solution sont brièvement désactivés puis réactivés. Selon la documentation, celui qui souhaite minimiser cet effet dans des environnements de production a intérêt à travailler avec plusieurs solutions plus petites plutôt qu'une seule grande.

Une routine de sauvegarde qui tient au quotidien

À partir de ces différents éléments de documentation, on peut déduire une routine praticable :

• Regrouper les flux liés entre eux dans des solutions non gérées clairement nommées, plutôt que de tout laisser dans la solution par défaut.
• Exporter régulièrement ces solutions, pas seulement avant des changements majeurs, et archiver les fichiers ZIP versionnés dans un dépôt.
• Supprimer les valeurs des variables d'environnement avant l'export, et documenter à la place les valeurs à définir pour chaque environnement cible.
• Garder des solutions plutôt petites et découpées par thème, afin qu'une restauration ne désactive pas inutilement de nombreux flux non concernés.
• Tester la restauration au moins une fois dans un environnement séparé avant de s'y fier en cas d'urgence.

Pour beaucoup de PME, c'est justement ce dernier point qui constitue la plus grande lacune : un fichier ZIP existe bien quelque part, mais personne n'a jamais vérifié si l'import fonctionne réellement. Chez NordFlux, nous intégrons directement cette routine de sauvegarde et d'export dans notre conseil Power Automate, avec gestion de versions et un test de restauration documenté, afin qu'une perte de flux ne soit plus une urgence, mais une opération de quelques minutes.

Questions fréquentes

Est-il suffisant de dupliquer manuellement des flux plutôt que d'exporter une solution ?

Non, un objet de flux dupliqué reste lié au même environnement et ne constitue pas une copie de sauvegarde externe. Seul l'export d'une solution crée un fichier ZIP en dehors de l'environnement, qui peut être versionné, archivé et importé dans un autre environnement.

Puis-je exporter une solution gérée comme sauvegarde ?

Non. Selon la documentation, les solutions gérées ne peuvent fondamentalement pas être exportées. Pour les sauvegardes, il te faut toujours la solution non gérée sous-jacente à partir de laquelle la version gérée a été créée à l'origine.

Que deviennent les connexions lorsque j'importe une solution dans un nouvel environnement ?

Les références de connexion sont importées avec le reste, mais les connexions elles-mêmes doivent soit être recréées dans le système cible, soit être partagées avec l'utilisateur qui effectue l'import. Sans connexion valide, un flux importé reste visible mais ne peut pas être activé automatiquement.

À quelle fréquence dois-je sauvegarder mes flux via des solutions ?

La documentation ne mentionne pas de fréquence fixe, mais recommande explicitement des exports réguliers et répétés. En pratique, un rythme calé sur la fréquence des changements s'est révélé efficace : après chaque modification substantielle d'un flux, ainsi qu'à intervalle fixe supplémentaire, par exemple chaque semaine, en filet de sécurité.

Dois-je créer une solution propre pour chaque flux ?

Non, ce serait inutilement morcelé. Il est plus judicieux de regrouper dans une solution commune les flux liés entre eux sur le plan thématique ou fonctionnel. Le seul point important est de ne pas laisser une solution devenir trop grande, au risque qu'une seule opération de restauration désactive brièvement tous les flux de l'organisation en même temps.