Prenons un cas hypothétique. Une personne est tannée d’un tableur et de la double saisie. Elle monte un formulaire Power Apps, ajoute un flux Power Automate et règle en quelques jours un irritant qui traînait depuis des mois. La boucle courte est excellente. Le risque apparaît lorsque le petit outil devient une dépendance sans changer de mode d’exploitation.

Une application canevas Power Apps s’exécute dans un client Web ou mobile. Ses formules réagissent aux événements des contrôles, puis un connecteur appelle SharePoint, Dataverse, SQL Server ou un autre service. Power Automate démarre sur un déclencheur — ajout d’une ligne, horaire ou appel — et exécute des actions avec les connexions configurées.

formulaire Power Apps → connecteur → source de données
                             ↓
                       déclencheur de flux
                             ↓
              validation → approbation → mise à jour → avis

La connexion a une identité. Si elle appartient au créateur et que son compte est désactivé, le flux peut cesser. Si elle possède trop de droits, chaque action du flux hérite d’un accès trop large. Un processus d’équipe devrait utiliser une identité de service contrôlée ou des connexions partagées appropriées, avec secret géré, propriétaire secondaire et droits limités aux tables nécessaires.

Le connecteur masque aussi des limites. Une formule Power Apps peut être délégable, donc traduite et exécutée par la source, ou être calculée localement sur un nombre limité de lignes. Un filtre non délégable semble fonctionner avec 200 enregistrements et oublie des résultats quand la liste en contient 20 000. Les avertissements de délégation et un test avec le vrai volume font partie de la validation.

Le niveau de contrôle suit l’impact

Je classerais les solutions en trois catégories :

Catégorie	Exemple	Contrôle minimal
personnel	rappel ou liste remplaçable	propriétaire, export occasionnel
équipe	demande de congé ou inventaire local	relève, environnement test, journal d’exécution
critique	paiement, conformité, données sensibles	produit géré, identité de service, ALM, reprise et soutien

La promotion vers un produit n’enlève aucun crédit à l’auteur. Elle ajoute des environnements développement/test/production, une solution exportable, des variables d’environnement et un déploiement contrôlé. Modifier directement la production rend le rollback difficile. Une version exportée et les dépendances documentées permettent de revenir.

Power Automate retente certaines actions après une erreur transitoire. C’est utile pour une lecture, dangereux pour une création non idempotente. Chaque demande importante reçoit un identifiant unique et la cible refuse un doublon. Si l’approbation expire ou le connecteur retourne un timeout après l’écriture, le flux vérifie l’état avant de recommencer. Les exécutions en erreur alimentent une file ou une alerte avec un propriétaire, pas seulement l’historique personnel du créateur.

La gouvernance de la plateforme passe par des politiques de prévention de perte de données. Elles empêchent, par exemple, de mélanger un connecteur d’entreprise avec un service grand public dans le même flux. Les environnements séparent essais et production. Le partage de l’application ne donne pas automatiquement le bon accès à chaque source; je teste avec un compte ordinaire et je vérifie que l’utilisateur ne peut ni lire ni modifier plus que l’écran ne montre.

Mon test de vacances dure une heure : désactiver le compte du créateur dans un environnement test, soumettre une demande, provoquer un timeout, puis restaurer la dernière version. Si une autre personne peut trouver le flux, comprendre ses connexions, reprendre un élément et expliquer les données touchées, l’outil a franchi le cap. Sinon, sa popularité a dépassé son architecture et il faut le reprendre avant les vraies vacances.