PowerBlocks

Guides de dépannage

Guides gratuits, sans connexion, pour corriger les erreurs Power Apps et Power Automate les plus courantes — disponibles en français et en anglais. Issus de débogage en conditions réelles.

Power Apps

Corriger l’avertissement de délégation Power Apps

Le soulignement bleu ondulé dans la barre de formule signale qu’une partie de la formule n’est pas délégable : Power Apps ne récupère alors que les 500 premières lignes (jusqu’à 2000) de la source de données et applique la formule localement sur ce sous-ensemble — des enregistrements sont donc silencieusement ignorés. Correctif immédiat : remplace les fonctions non délégables par des délégables (Filter() avec =, <, >, StartsWith() plutôt que Search() ou des expressions non délégables), et sors les conditions calculées de la requête en pré-calculant une colonne ou une variable. Correctif durable : filtre d’abord côté serveur, puis fais le travail non délégable seulement sur le résultat réduit. Monter la limite à 2000 lignes reste un palliatif, pas une vraie solution.

Passer la limite de lignes Power Apps de 500 à 2000

Par défaut, Power Apps plafonne à 500 lignes les requêtes non délégables. Correctif immédiat : dans Power Apps Studio, ouvre Paramètres (icône engrenage) > Général, trouve « Limite de lignes de données pour les requêtes non délégables », mets 2000, enregistre et republie l’application — c’est le maximum réglable. Correctif durable : les tables de plus de 2000 lignes perdent quand même des enregistrements, et rapatrier 2000 lignes par écran dégrade les performances ; rends plutôt tes requêtes délégables pour que la source fasse le filtrage.

Une galerie Power Apps n’affiche rien — comment corriger

Une galerie Power Apps vide est presque toujours un problème de données, de filtre ou de rafraîchissement — pas un souci de modèle de galerie. Vérifie d’abord la propriété Items : si elle pointe vers une collection, confirme que le ClearCollect dans OnVisible ou OnStart s’est bien exécuté ; si Items est un Filter() qui ne renvoie rien, mets temporairement Items sur la source brute pour confirmer que les données existent. Autres causes fréquentes : un filtre qui compare des types incompatibles (texte vs nombre) ou une variable vide, une limite de délégation qui écarte silencieusement des lignes attendues, ou une source qui a besoin d’un Refresh() après un Patch ou une modification externe. Pour diagnostiquer vite, ajoute un libellé temporaire avec Text = CountRows(ItemsDeTaGalerie) : zéro ligne signifie que c’est la requête, pas le modèle, qui pose problème.

Erreur de syntaxe Power Apps : point-virgule ou virgule ?

Une erreur de syntaxe Power Apps qui pointe une virgule ou un point-virgule inattendu vient presque toujours d’un décalage entre la langue de ton studio et les séparateurs utilisés dans la formule, pas d’un problème de logique. Power Fx adapte sa syntaxe à la région : en anglais, les arguments d’une fonction sont séparés par une virgule et les décimales s’écrivent avec un point (If(x = 1, "a", "b"), 0.5) ; en français (et régions proches), les arguments sont séparés par un point-virgule et les décimales par une virgule (If(x = 1; "a"; "b"), 0,5). Correctif : aligne chaque séparateur sur la langue du studio. En copiant une formule écrite dans l’autre langue, remplace les virgules entre arguments par des points-virgules (ou l’inverse).

Power Apps : Patch() n’enregistre pas ou ne crée pas l’enregistrement

Quand Patch() échoue en silence ou renvoie une erreur dans Power Apps, c’est presque toujours une colonne obligatoire manquante, une incompatibilité de type (texte dans une colonne nombre/choix, ou chaîne dans un lookup/choix qui attend un enregistrement), ou un Patch appliqué à une copie/variable locale au lieu de la vraie source de données. Correctif immédiat : encapsule l’appel dans IfError(Patch(...); Notify("Échec Patch : " & FirstError.Message; NotificationType.Error)) pour faire remonter l’erreur réelle, vérifie le nom logique de la colonne, et passe le véritable enregistrement ou la valeur de choix pour les lookups/choix — par exemple {Value:"Active"} ou le résultat d’un LookUp(). Correctif durable : confirme que l’utilisateur a le droit de créer/modifier sur la table, et patch toujours directement la source de données, jamais une collection ou une variable.

Power Apps lent au démarrage — comment l’accélérer

Une application Power Apps lente au démarrage ou saccadée vient surtout d’un App.OnStart trop chargé qui bloque le rendu, de filtres non délégables, ou d’une même source de données interrogée plusieurs fois. Correctif immédiat : sors la logique non essentielle de OnStart vers le OnVisible de chaque écran, ne charge que ce dont le premier écran a besoin, et utilise Concurrent() pour lancer les chargements de données indépendants en parallèle plutôt qu’à la suite. Correctif durable : remplace les ClearCollect de grandes tables par des requêtes délégables chargées à la demande, garde les filtres délégables pour que le serveur traite les lignes au lieu d’en rapatrier 500 à 2000 localement, et active DelayOutput sur les champs texte pour éviter de re-requêter à chaque frappe.

Créer un écran Power Apps responsive avec les conteneurs

Un écran Power Apps se déforme selon la taille de l’écran quand les contrôles sont placés avec des coordonnées X/Y fixes. Correctif immédiat : dans Paramètres > Affichage, désactive « Mettre à l’échelle » (Scale to fit) — ce qui désactive aussi le verrouillage des proportions (Lock aspect ratio) —, puis « Verrouiller l’orientation » si l’app doit pivoter, et base les tailles sur App.Width et Parent.Width plutôt que sur des pixels codés en dur. Correctif durable : reconstruis l’écran avec des conteneurs à disposition automatique. Donne une taille fixe aux éléments fixes, active Flexible width ou Flexible height avec des Fill portions pour que les autres enfants se partagent l’espace supplémentaire proportionnellement, et imbrique les conteneurs pour former lignes et colonnes. Sur téléphone, change la direction ou la visibilité d’un conteneur selon la propriété Size de l’écran ou App.Width pour les empiler.

Power Apps : la liste déroulante / combo box n’affiche aucun élément

Une liste déroulante ou combo box vide vient généralement de la source Items, du champ d’affichage ou de la délégation. Vérifie que Items pointe vers une source réelle et non vide — pour une colonne choix/lookup, utilise Choices([@TaTable].TaColonne) plutôt que la colonne brute, et teste la source brute si un Distinct/Filter ne renvoie rien. Règle le texte principal (DisplayFields/SearchFields) sur la colonne à afficher : des éléments vides indiquent souvent un champ d’affichage erroné ou vide. Enfin, garde la requête Items délégable — une requête non délégable peut ne rien renvoyer sur une grande source — et vérifie que le champ lié est du texte/choix, pas un enregistrement non extrait.

Power Automate

Power Automate « connexion expirée » / 401 Unauthorized

Une erreur 401 ou « la connexion a expiré » signifie que la connexion stockée derrière ce connecteur ne peut plus s’authentifier : l’identifiant a expiré, le mot de passe a changé, ou le consentement a été révoqué. Correctif immédiat : ouvre l’action en échec, vérifie sa connexion, puis dans Power Automate > Connexions repère la connexion cassée et clique « Corriger la connexion » ou ré-authentifie-toi. Correctif durable : fais tourner les flux de production sur un compte de service dédié dont la politique de mot de passe ne force pas l’expiration, ou utilise un type de connexion à authentification longue durée, pour que la connexion ne casse pas quand quelqu’un change son mot de passe ou quitte l’entreprise.

Power Automate 429 « Too Many Requests » — comment corriger

Un 429 signifie que Power Automate a dépassé la limite de débit du connecteur — trop d’appels en trop peu de temps, souvent à cause d’une boucle qui appelle une action sur chaque élément ou de plusieurs flux exécutés en même temps. Correctif immédiat : si la concurrence est activée sur le « Appliquer à chacun », baisse-la (la boucle traite un élément à la fois par défaut), ajoute un délai entre les appels, ou une stratégie de nouvelle tentative avec backoff exponentiel sur l’action. Correctif durable : regroupe l’opération ou filtre les lignes avant la boucle pour appeler moins souvent le connecteur.

Power Automate : erreurs 404 et 500 — les lire et les corriger

Dans Power Automate, une erreur 404 signifie que l’enregistrement, le fichier ou l’élément référencé par l’action n’existe pas, ou que le chemin/ID est faux — souvent un enregistrement supprimé, le mauvais environnement, ou un ID dynamique résolu à vide. Une erreur 500 signifie que le service a accepté la requête mais a échoué en la traitant, généralement un corps mal formé ou un null inattendu. Correctif immédiat : ouvre l’historique d’exécution, vérifie les entrées réellement utilisées par l’action en échec, et confirme l’enregistrement et l’environnement ; pour un 500, lis les sorties brutes pour le message sous-jacent. Correctif durable : protège-toi des ID vides avant l’action, valide le corps de la requête et les propriétés requises, et ajoute une stratégie de nouvelle tentative pour les 500 transitoires.

Power Automate : fuseaux horaires, dates décalées de quelques heures

Des dates décalées de quelques heures dans Power Automate signalent presque toujours un mélange UTC / heure locale : le flux travaille en UTC par défaut (utcNow(), horodatages de déclencheur), donc afficher ou comparer une valeur locale sans conversion crée un décalage égal à ton fuseau horaire. Correctif immédiat : convertis explicitement pour l’affichage avec convertTimeZone(utcNow(); "UTC"; "Romance Standard Time"; "dd/MM/yyyy HH:mm") (adapte le nom du fuseau à ton cas). Correctif durable : stocke et compare toujours les dates en UTC, ne convertis en local qu’au tout dernier moment (affichage, corps d’email), et sois explicite sur le fuseau source quand tu parses une date saisie par l’utilisateur.

Transférer proprement les flux Power Automate entre environnements

Les flux cassent à l’import car ils se lient à ta connexion personnelle et à des valeurs codées en dur (URLs, ID) qui n’existent pas dans l’environnement cible. Correctif : place les flux dans une solution, remplace les connexions directes par des références de connexion (remappées par environnement à l’import), et remplace les valeurs codées en dur par des variables d’environnement. Après l’import, active le flux et vérifie que les références de connexion sont résolues avant de tester.

Power Automate : « Appliquer à chacun » est lent — comment l’accélérer

Un « Appliquer à chacun » lent dans Power Automate vient généralement d’un traitement séquentiel des éléments sans parallélisme, plus des appels d’API à chaque itération qui s’accumulent. Correctif immédiat : ouvre les Paramètres de la boucle, active le contrôle de concurrence et augmente le degré de parallélisme (jusqu’à 50) — mais seulement si chaque itération est indépendante des autres. Correctif durable : filtre à la source (filtre OData / Filter Query) ou ajoute une action « Filtrer un tableau » avant la boucle pour réduire le nombre d’éléments, et remplace les appels par itération par une action en lot ou des expressions de transformation quand le connecteur le permet — cela évite aussi le throttling (429).

Power Platform — déploiement & ALM

ALM complet : livrer Power Platform de dev à prod

Une livraison Power Platform fiable repose sur quatre composantes : les environnements (dev / recette / prod), le schéma de l’app dans des solutions, les flux Power Automate, et les données réparties entre référence et transactionnel. Règle d’or : on crée uniquement en dev, on promeut via la recette, et on ne modifie jamais la production à la main. Concrètement, en trois étapes : promouvoir la solution dev → recette → prod avec les Pipelines Power Platform, rendre les flux portables avec références de connexion et variables d’environnement avant de les activer dans la cible, puis migrer uniquement les données de référence/config avec le Configuration Migration Tool ou les Dataflows — jamais les données transactionnelles. Avant chaque mise en production : sauvegarder la cible, déployer en géré, valider en recette/UAT, remapper les références de connexion et variables d’environnement, puis faire un test rapide après avoir activé les flux.

Mettre en place un pipeline de déploiement dev → recette → prod

Mets en place trois environnements — Dev, Recette/UAT et Production — et empaquette tout (tables, flux, application canvas) dans une solution. Ne modifie jamais directement la production : crée uniquement en Dev, puis promeus Dev → Recette → Prod avec les Pipelines Power Platform (ou le pac CLI / Azure DevOps pour automatiser), en déployant en solution gérée vers Recette et Prod.

Transférer les données entre environnements Power Platform

Une solution Power Platform déplace le schéma (tables, colonnes, formulaires, apps, flux) mais jamais les lignes : les données de référence et de configuration doivent être migrées séparément. Correctif immédiat : utilise le Configuration Migration Tool — définis un schéma des tables/colonnes à exporter, exporte les données dans un zip, puis importe-les dans l’environnement cible. Pour des transferts plus volumineux ou récurrents, utilise les Dataflows avec des clés alternatives définies sur les tables pour que les lignes soient mises à jour (upsert) au lieu d’être dupliquées à chaque exécution. Le pac CLI, l’import Excel ou XrmToolBox conviennent aussi pour un transfert ponctuel ou automatisé. Ne migre jamais de données transactionnelles ou utilisateur entre environnements — uniquement des données de configuration/référence — et garde des clés alternatives cohérentes pour qu’un nouveau passage reste idempotent.