Power Apps ou sur mesure : la bonne réponse dépend de preuves, pas d’une préférence
Power Apps reste défendable si les tests des cas difficiles sont concluants, si vous maîtrisez le coût prévu au contrat et si votre équipe sait déployer, sécuriser, prendre en charge et restaurer l’application. Envisagez une application dédiée seulement après avoir reproduit une limite importante qu’une correction raisonnable n’a pas levée. Avant de migrer, vérifiez que les bénéfices attendus et documentés justifient son coût et son risque.
Avant de tout réécrire, vous pouvez renforcer Power Platform ou conserver ce qui fonctionne et confier la contrainte bloquante à un module dédié. Si l’audience, les licences, l’exécution des requêtes dans la source — la délégation —, le hors-ligne, les politiques de données ou la reprise restent inconnus, suspendez la décision et notez : preuve manquante. Dans ce guide, le tenant désigne l’instance organisationnelle Microsoft qui regroupe notamment les identités, les licences, les politiques et les environnements Power Platform. Un tenant n’est donc pas un environnement.
Isolez d’abord la cause. Une application lente peut venir d’une formule non délégable, d’un modèle SharePoint mal interrogé ou d’un flux mal conçu : ces défauts peuvent parfois être corrigés. À l’inverse, une démonstration fluide sur cinquante lignes ne prouve ni le comportement au volume, ni l’accès d’invités, ni la continuité dans une zone sans réseau, ni la capacité de l’équipe à reprendre l’outil.
Les cinq conclusions possibles après vérification
- Statut
- DÉCISION EN ATTENTE — Réunir la preuve manquante
- Quand il est défendable
- Une donnée capable de changer l’architecture manque : audience, requête réelle, licence, politique de données, hors-ligne, restauration ou exploitation.
- Action suivante
- Obtenir la première preuve manquante. Ne pas remplacer l’inconnu par zéro, par un avis ou par une démonstration commerciale.
- Statut
- CONSERVER — Garder Power Apps
- Quand il est défendable
- Les cas difficiles passent, le coût contractuel est compris, les droits sont maîtrisés et l’équipe sait déployer, restaurer et soutenir l’application.
- Action suivante
- Archiver les preuves et définir les événements qui déclencheront une nouvelle revue : volume, audience, licence, politique du tenant ou criticité.
- Statut
- RENFORCER — Corriger l’architecture Power Platform
- Quand il est défendable
- Le besoin convient à la plateforme, mais données, formules, environnements, rôles, propriétaires ou supervision sont insuffisants.
- Action suivante
- Traiter le défaut mesuré, rejouer le test et recalculer le TCO avant de financer une reconstruction.
- Statut
- HYBRIDE — Sortir seulement la contrainte
- Quand il est défendable
- Une fonction déborde du cadre actuel, mais une frontière propre permet de conserver ce qui fonctionne sans dupliquer règles et données.
- Action suivante
- Contractualiser l’interface entre systèmes (API), l’identité, les données de référence, les erreurs et le propriétaire de chaque côté.
- Statut
- RECONSTRUIRE — Préparer une application dédiée
- Quand il est défendable
- Une limite importante a été reproduite et ni remédiation ni frontière hybride testée ne couvre le besoin dans des conditions acceptables.
- Action suivante
- Construire par coexistence, avec recette métier, migration répétable, critères de bascule et retour arrière joué.
Chacune de ces cinq décisions doit reposer sur une preuve et déboucher sur une action précise. Si votre équipe ne peut pas nommer la première preuve à réunir, la décision reste en attente.
Règle de décision
Une preuve doit pouvoir invalider votre option préférée
- Testez les requêtes : le résultat peut écarter le maintien en l’état.
- Effectuez une restauration complète. Elle peut montrer que la sortie n’est pas aussi simple que prévu.
- Comparez le gain d’usage et le TCO du prototype dédié ; si le gain ne justifie pas le coût, écartez la reconstruction.
- Si la correction réussit, Power Apps peut redevenir préférable.
Incident actif : arrêtez l’arbitrage
Si l’application est indisponible, si des données semblent perdues, si un compte est compromis ou si une politique vient de suspendre un flux, traitez d’abord l’incident et organisez le fonctionnement en mode dégradé. La refonte viendra ensuite : elle ne remplace ni une restauration ni une procédure de réponse à incident.
Avant de comparer les outils ou les tarifs, identifiez votre situation de départ : partez-vous de zéro ou d’une Power App déjà utilisée ? L’ordre des vérifications n’est pas le même.
Vous ne choisissez pas de la même manière pour un nouveau projet et une Power App déjà utilisée
Pour un nouveau projet, vérifiez d’abord qu’un type d’application Power Platform couvre réellement la tâche. Pour une application déjà utilisée, identifiez la cause du problème avant d’abandonner un outil adopté. Les preuves à réunir sont les mêmes, mais leur ordre change.
Chemin A · nouveau projet
- Observer trois tâches représentatives et leurs exceptions.
- Choisir le type d’application envisagé d’après son audience et ses données.
- Prototyper la requête, l’identité, le hors-ligne et le parcours les plus risqués.
- Faire valider licences, politiques de données, rôles, environnements et exploitation.
- Comparer le coût total de possession des quatre options, coûts de sortie compris.
Chemin B · application existante
- Geler une version connue et documenter l’incident ou la gêne précise.
- Inventorier application, données, flux, connecteurs, identités et propriétaires, sans dépendre du seul créateur de l’application — le « maker ».
- Reproduire le problème sur une copie, mesurer les conditions dans lesquelles il survient et en identifier la cause.
- Tester une correction limitée avant toute réécriture.
- Comparer maintien corrigé, hybride et dédié sur les mêmes scénarios.
Ce que vous comparez réellement
Power Apps recouvre plusieurs familles. Dans une application canevas, l’équipe compose librement l’interface. Une application pilotée par modèle s’organise autour du modèle de données Dataverse, tandis que Power Pages sert à créer des sites externes adossés à Dataverse. Avec une application dédiée, l’équipe choisit pour le projet l’interface, l’environnement d’exécution — le runtime —, l’identité, les données et le mode d’exploitation. Les traiter comme quatre produits interchangeables produirait de faux écarts.
Quatre familles à confronter au même besoin
- Option
- Application canevas
- Point fort à vérifier
- Parcours interne très spécifique et intégration Microsoft 365
- Contre-preuve à chercher
- Requêtes non délégables, usage externe, accessibilité ou hors-ligne non couvert
- Dépendance structurante
- Connecteurs, sources et runtime Power Apps
- Option
- Pilotée par modèle
- Point fort à vérifier
- Données relationnelles Dataverse, vues, formulaires et processus structurés
- Contre-preuve à chercher
- Expérience très sur mesure ou besoin sortant du modèle
- Dépendance structurante
- Dataverse, rôles et cycle de vie Power Platform
- Option
- Power Pages
- Point fort à vérifier
- Portail web externe lié à Dataverse
- Contre-preuve à chercher
- Identité, marque, volumétrie ou tarification externe incompatible
- Dépendance structurante
- Capacité Power Pages, Dataverse et gouvernance du tenant
- Option
- Application dédiée
- Point fort à vérifier
- Expérience, intégrations et architecture conçues au besoin
- Contre-preuve à chercher
- TCO, délai, exploitation ou dépendance à une équipe sous-estimés
- Dépendance structurante
- Code, hébergement, sécurité, support et compétences choisies
Commencez donc par aligner la surface, l’audience et les données. Comparer une application canevas interne à un portail client dédié sans garder le même public fausse le verdict.
Une préférence ne devient une décision qu’après avoir recherché des faits capables de la contredire.
Le type d’application ne suffit pas pour trancher. Appliquez maintenant les mêmes cinq tests à chaque option.
Cinq tests pour séparer une limite de plateforme d’un défaut corrigeable
Chaque test doit produire une trace : capture d’un avertissement, requête rejouable, compte de test, facture, export restauré, journal de déploiement ou procès-verbal de recette. « Cela devrait marcher » et « le commercial nous l’a dit » ne sont pas des preuves d’architecture.
Test 1 — la tâche et les données les plus difficiles
Prenez trois cas normaux, une exception et un échec. Notez les entrées, la règle, le résultat attendu, la personne qui décide et le temps d’attente acceptable. Rejouez ensuite les requêtes sur un jeu représentatif : volume, relations, filtres, tri, recherche, pièces jointes, simultanéité et historique.
Ne confondez pas stockage et interrogation. Microsoft documente jusqu’à 30 millions d’éléments dans une liste ou bibliothèque SharePoint. Il publie aussi un seuil de vue ou requête de 5 000. Dans une application canevas, 500 — configurable jusqu’à 2 000 — concerne le traitement local de certaines opérations non délégables. Ce n’est pas une « limite Power Apps à 2 000 lignes ». Une formule non délégable peut surtout retourner un sous-ensemble incomplet et conduire à une décision fausse.
Preuve attendue
Un test de délégation doit vérifier le résultat, pas seulement la vitesse
- Identifier la source, la colonne, l’opérateur et la formule.
- Lire les avertissements de délégation dans l’éditeur.
- Comparer le nombre et l’identité des résultats à une requête de référence.
- Tester le cas au-delà des 500 et 2 000 premières lignes.
- Conserver une preuve après chaque correction.
Test 2 — l’audience, l’identité et les droits réels
Un salarié du tenant, un invité Microsoft Entra B2B provenant d’une autre organisation et un utilisateur public n’accèdent pas à l’outil dans les mêmes conditions. Pour chacun, vérifiez séparément l’identité, la licence et les droits. Pour un invité d’application canevas, contrôlez aussi l’invitation et chaque autorisation sur les sources sous-jacentes. Une licence dans un tenant ne confère pas automatiquement les mêmes droits dans un autre. Pour un portail, comparez Power Pages et une identité dédiée sur les volumes et parcours réels. Un simple partage n’est pas un portail client.
Testez au minimum un compte sans privilège administratif, un compte invité, un compte désactivé et la révocation d’un accès. Vérifiez ce que l’utilisateur voit dans l’interface, mais aussi ce qu’il peut lire directement dans SharePoint, Dataverse ou l’API. Dans Dataverse, les rôles sont cumulatifs : un rôle bien configuré peut être contredit par un autre rôle ou une équipe.
Le choix d’une architecture ne suffit pas à démontrer la conformité au Règlement général sur la protection des données (RGPD). Documentez la finalité, les catégories de données, leur minimisation, les durées de conservation, les destinataires, les sous-traitants et les transferts, puis faites examiner les mesures par les personnes chargées de la protection des données. Si le traitement est susceptible d’engendrer un risque élevé pour les droits et libertés, demandez au délégué à la protection des données (DPO) ou au conseil compétent de déterminer si une analyse d’impact relative à la protection des données (AIPD) est requise.
Test 3 — le contexte d’usage, le hors-ligne et l’accessibilité
Pour un usage terrain, reproduisez perte de réseau, reprise, synchronisation, conflit, batterie faible, appareil ancien et volume réaliste. Le mode dit offline-first, pensé pour continuer sans réseau, s’appuie ici sur Dataverse et Power Apps Mobile. Il ne transforme pas le navigateur ou une liste SharePoint en application hors-ligne générale. Si le travail doit continuer plusieurs heures sans réseau, le résultat de ce test peut suffire à départager le renforcement, l’architecture hybride et l’application dédiée.
Pour une application canevas autonome configurée offline-first, la documentation actuelle exclut du mode hors ligne les connecteurs non-Dataverse comme SharePoint et les flux Power Automate. Vérifiez aussi relations, volumes synchronisés, pièces jointes, ordre des données, premier téléchargement et comportement en arrière-plan : le mot « hors-ligne » ne suffit pas à couvrir le parcours terrain. Ajoutez la perte ou le remplacement d’un appareil au protocole : données locales, effacement, reprise et accès résiduel doivent avoir un responsable et une preuve.
Pour l’accessibilité, utilisez le vérificateur pour repérer des alertes, sans le considérer comme une preuve de conformité. À lui seul, il ne démontre le respect ni des Web Content Accessibility Guidelines (WCAG) ni du Référentiel général d’amélioration de l’accessibilité (RGAA). Parcourez chaque tâche au clavier, à 200 % de zoom, avec une police agrandie, un lecteur d’écran et les erreurs de validation. Contrôlez ordre de focus, nom accessible, contraste, messages, réactivité et orientation. Une interface « jolie dans le studio » n’est pas encore une interface utilisable.
Test 4 — le tenant : licences, connecteurs et cycle de vie
Dans le tenant, examinez ensemble les politiques de prévention de la perte de données (DLP, Data Loss Prevention), les interfaces de programmation (API) et la gestion du cycle de vie applicatif (ALM, Application Lifecycle Management).
Inventoriez l’application, ses composants, ses flux Power Automate, connecteurs directs et indirects, passerelles, API personnalisées, connexions, comptes d’exécution et environnements. Pour chaque élément, notez propriétaire, licence, authentification, politique de données, fréquence, limite, alerte et procédure d’échec. Relevez aussi la région de chaque environnement et celle des systèmes connectés : la localisation d’un environnement ne prouve pas celle de toute la chaîne de données.
Les droits de requêtes liés à la licence, la protection de service Dataverse et les limites propres aux connecteurs obéissent à des règles différentes. Les nombres publiés évoluent et ne constituent pas une promesse de débit métier. Les politiques DLP peuvent interdire une combinaison, suspendre ou mettre en quarantaine une application ou un flux : vérifiez les politiques effectives du tenant.
Les politiques avancées de connecteurs (ACP, Advanced Connector Policies) publiées en 2026 reposent sur une liste d’autorisation stricte pour les connecteurs certifiés. En mode mixte, elles se combinent aux politiques classiques ; c’est alors la règle la plus restrictive qui s’applique. Les connecteurs personnalisés et HTTP ne sont pas encore couverts par ACP : continuez à les gouverner avec les politiques classiques. Inventoriez, simulez et déployez progressivement. Une règle sauvegardée trop tôt peut bloquer tout connecteur qui n’a pas été explicitement autorisé.
Pour une application importante, exigez au minimum développement, test et production séparés, solutions, variables d’environnement, références de connexion, contrôle de version et déploiement reproductible. Un pipeline transporte une solution, pas vos données métier. Données, secrets, connexions et identités nécessitent leur propre plan et leur propre test.
Test 5 — propriété, support, restauration et sortie
Nommez le propriétaire métier, le propriétaire technique, un suppléant et le responsable du support. Définissez qui répond à une question utilisateur, qui corrige une règle, qui administre le tenant et qui contacte Microsoft lors d’un incident plateforme. Le support éditeur ne remplace ni la maintenance de votre application ni la continuité de votre activité.
Exportez, puis restaurez sur un environnement séparé. Vérifiez application, flux, données, connexions, identités, secrets, variables, rôles et automatisations. Les solutions et fichiers extraits améliorent l’auditabilité et le contrôle de version dans Power Platform ; ils ne deviennent pas une application React ou Next.js. Le runtime désigne ici l’environnement technique qui exécute l’application. Les limites documentées de l’export permettent d’en déduire que quitter ce runtime peut exiger de reconstruire l’interface et la logique, de refaire les intégrations et de migrer les données ; ce n’est pas une règle Microsoft qui garantirait le même effort pour chaque projet.
La preuve minimale attendue pour chaque axe
- Axe
- Besoin
- Question qui tranche
- Les cas difficiles sont-ils couverts ?
- Preuve acceptable
- Scénarios rejoués et résultats comparés
- Ce qui empêche de conclure
- Tâche ou exception inconnue
- Axe
- Données
- Question qui tranche
- Les requêtes sont-elles exactes au volume ?
- Preuve acceptable
- Jeu représentatif et référence indépendante
- Ce qui empêche de conclure
- Avertissement non expliqué
- Axe
- Audience
- Question qui tranche
- Chaque identité a-t-elle licence et droits ?
- Preuve acceptable
- Comptes réels de test et révocation
- Ce qui empêche de conclure
- Invité/public non testé
- Axe
- Usage
- Question qui tranche
- Le parcours fonctionne-t-il dans son contexte ?
- Preuve acceptable
- Appareils, réseau, clavier, zoom, lecteur d’écran
- Ce qui empêche de conclure
- Usage hors ligne ou accessibilité seulement supposés
- Axe
- Tenant
- Question qui tranche
- La solution reste-t-elle déployable et autorisée ?
- Preuve acceptable
- Politiques, environnements, solutions et journaux
- Ce qui empêche de conclure
- DLP, connexion ou propriétaire inconnu
- Axe
- Sortie
- Question qui tranche
- Peut-on reprendre l’application sans son créateur initial ni son environnement d’origine ?
- Preuve acceptable
- Restauration complète sur environnement séparé
- Ce qui empêche de conclure
- Simple fichier exporté
Pour chaque ligne encore sans preuve, définissez le prochain test à réaliser au lieu de retenir une hypothèse favorable. Une fois ces éléments réunis, comparez les coûts sans avantager l’option la moins documentée.
Comparez quatre coûts totaux de possession (TCO) à 1, 3 et 5 ans
Le prix d’une licence n’est pas le coût d’une application. Comparez Power Apps actuel, Power Apps renforcé, une architecture hybride et une application dédiée avec les mêmes familles de coûts. Comptez conception, migration, coexistence, formation, licences, hébergement, administration, maintenance, support métier, capacité, connecteurs, supervision, sécurité et réversibilité.
TCO sur N années = coûts ponctuels + coûts mensuels × 12 × N N = 1, 3 ou 5 coût inconnu : le total ne peut pas être calculé coût confirmé à 0 € : le total peut être calculé
Si vous valorisez du temps interne, écrivez la méthode : heures, rôle, coût retenu et période. Ne comptez pas la même heure dans la construction, la maintenance et le support. Sans méthode défendable, gardez ce poste inconnu ; un faux zéro favorise artificiellement l’option qui mobilise le plus l’équipe.
Les repères publics au 3 août 2026
La page française Microsoft affichait Power Apps Premium à 17,30 € HT par utilisateur et par mois, avec paiement annuel ; HT signifie « hors taxes ». Elle affichait aussi 10,40 € HT avec un minimum de 2 000 postes/licences, avec paiement annuel et contact commercial. Le plan Developer gratuit était réservé au développement et au test, pas à la production. L’extension de capacité de base de données Dataverse était affichée à 34,70 € HT par Go et par mois, avec paiement annuel ; Go signifie « gigaoctet ».
Le guide de licences de juillet 2026 indique la fin de commercialisation de l’ancien abonnement Power Apps « per app » en janvier 2026 : ne bâtissez pas un budget actuel sur l’ancien repère à 5 USD. Le paiement à l’usage (PAYG, pay-as-you-go) est documenté à 10 dollars américains (USD) par utilisateur actif unique, par application et par mois. Plusieurs ouvertures de la même application dans le mois ne recomptent pas cet utilisateur. Le montant reste en USD : utilisez votre facture ou contrat Azure, jamais une conversion automatique cachée.
Une connexion mutualisée réduit-elle le nombre de licences ?
Non, pas automatiquement. Dans son guide de licences de juillet 2026, Microsoft parle de multiplexing lorsqu’une organisation mutualise ou réachemine des connexions, interpose une couche technique ou automatise un processus pour réduire le nombre d’utilisateurs ou d’appareils qui accèdent directement au service. La page 25 précise qu’une personne ou un appareil qui saisit, interroge, consulte ou accède autrement à Power Apps, Power Automate ou Power Pages doit être correctement licencié, que l’accès soit direct ou indirect. Ajouter des couches intermédiaires ne change pas ce principe.
Un budget limité au compte de service ou à la connexion partagée serait donc incomplet. La page 25 ne choisit cependant pas la référence commerciale applicable et ne dit pas que toute automatisation impose la même licence par utilisateur. Identifiez les personnes et appareils qui accèdent réellement au service, puis le modèle de licence applicable. Le guide ne remplace pas votre contrat : faites confirmer le scénario exact par votre équipe Microsoft ou un partenaire certifié Microsoft avant de chiffrer.
Prix public ≠ prix contractuel ≠ TCO
Confirmez pays, devise, taxes, engagement, remise, seuil, droit Microsoft 365, connecteurs, Dataverse, flux, capacité, utilisateurs externes et canal d’achat. Un droit inclus dans un scénario ne signifie pas « Power Apps gratuit pour tout ».
Atelier de décision local · aucune donnée envoyée
Réunir les preuves et comparer quatre coûts totaux de possession (TCO)
Ce modèle ne note pas votre projet. Une information critique manquante suspend la décision. Un coût inconnu reste inconnu. Les résultats sont des aides de cadrage, jamais un devis, un audit de sécurité ou une validation de licence.
Résultat du diagnostic
Décision suspendue
Décision suspendue — il manque une information qui peut changer le choix
- À vérifier signifie qu’aucune preuve fiable n’est encore disponible ; non signifie que le contrôle a été réalisé mais que son résultat est insatisfaisant.
- Le diagnostic ne remplace ni une inconnue ni un contrôle fondateur en échec par une hypothèse favorable.
Inconnues critiques
- Précisez s’il s’agit d’un nouveau projet ou d’une Power App existante.
- Précisez qui utilisera l’application : salariés, invités ou public.
- Précisez la surface envisagée : canevas, application pilotée par modèle, Power Pages ou combinaison.
- Précisez où vivent les données principales : SharePoint, Dataverse, SQL ou autre source.
- Précisez ce qui arrive à l’activité si l’application devient indisponible.
- Confirmez si les utilisateurs doivent travailler sans réseau.
- Confirmez si une expérience externe fortement personnalisée est nécessaire.
- Renseignez le nombre d’utilisateurs actuels ; zéro explicite est valide.
- Renseignez le nombre d’utilisateurs projetés ; zéro explicite est valide.
- Les tâches, utilisateurs, erreurs et résultats attendus ont été observés.
- Les sources de données, volumes, requêtes et avertissements de délégation ont été testés.
- Les licences, connecteurs, flux, passerelles, API et comptes d’exécution ont été inventoriés.
- Les parcours, le clavier, le zoom, le lecteur d’écran et les contraintes de marque ont été testés.
- Les rôles, politiques de données et connecteurs autorisés ont été vérifiés dans le tenant.
- Développement, test et production sont séparés, avec solutions et déploiements reproductibles.
- Un propriétaire de secours, un responsable de support et une procédure d’incident sont nommés.
- L’export, la restauration, les données, connexions et secrets ont été testés sur un environnement séparé.
- Les cas les plus difficiles ont été testés et Power Platform couvre réellement le besoin visé.
Prochaine preuve : Précisez s’il s’agit d’un nouveau projet ou d’une Power App existante.
Options encore défendables : aucune tant que les preuves critiques manquent.
4. Emporter le dossier de décision
La copie reprend les inconnues, contradictions, hypothèses de coût et limites. L’impression utilise uniquement la commande du navigateur.
Diagnostic arrêté : 18 élément(s) critique(s) à traiter.
Afficher le dossier copiable
DOSSIER DE DÉCISION — POWER APPS OU APPLICATION SUR MESURE Généré localement dans le navigateur ; aucune donnée envoyée. CONTEXTE Projet : à vérifier Audience : à vérifier Surface Power Platform : à vérifier Données principales : à vérifier Criticité : à vérifier Hors-ligne requis : à vérifier Marque externe forte : à vérifier Utilisateurs actuels : à confirmer Utilisateurs projetés : à confirmer ÉLÉMENTS CONTRÔLÉS - non vérifié — aucune preuve fiable — Les tâches, utilisateurs, erreurs et résultats attendus ont été observés. - non vérifié — aucune preuve fiable — Les sources de données, volumes, requêtes et avertissements de délégation ont été testés. - non vérifié — aucune preuve fiable — Les licences, connecteurs, flux, passerelles, API et comptes d’exécution ont été inventoriés. - non vérifié — aucune preuve fiable — L’identité, les invités, les droits sur les données et l’audience externe ont été testés. - non vérifié — aucune preuve fiable — Le besoin hors-ligne a été reproduit sur les appareils, données et modes de synchronisation visés. - non vérifié — aucune preuve fiable — Les parcours, le clavier, le zoom, le lecteur d’écran et les contraintes de marque ont été testés. - non vérifié — aucune preuve fiable — Les rôles, politiques de données et connecteurs autorisés ont été vérifiés dans le tenant. - non vérifié — aucune preuve fiable — Développement, test et production sont séparés, avec solutions et déploiements reproductibles. - non vérifié — aucune preuve fiable — Un propriétaire de secours, un responsable de support et une procédure d’incident sont nommés. - non vérifié — aucune preuve fiable — L’export, la restauration, les données, connexions et secrets ont été testés sur un environnement séparé. - non vérifié — aucune preuve fiable — Les cas les plus difficiles ont été testés et Power Platform couvre réellement le besoin visé. - non vérifié — aucune preuve fiable — La partie à sortir de Power Platform peut être isolée sans dupliquer les règles ni fragiliser les données. DÉCISION Orientation : Décision suspendue Conclusion : Décision suspendue — il manque une information qui peut changer le choix Option recommandée : aucune Options défendables : aucune - À vérifier signifie qu’aucune preuve fiable n’est encore disponible ; non signifie que le contrôle a été réalisé mais que son résultat est insatisfaisant. - Le diagnostic ne remplace ni une inconnue ni un contrôle fondateur en échec par une hypothèse favorable. Prochaine vérification : Précisez s’il s’agit d’un nouveau projet ou d’une Power App existante. Inconnues critiques : - Précisez s’il s’agit d’un nouveau projet ou d’une Power App existante. - Précisez qui utilisera l’application : salariés, invités ou public. - Précisez la surface envisagée : canevas, application pilotée par modèle, Power Pages ou combinaison. - Précisez où vivent les données principales : SharePoint, Dataverse, SQL ou autre source. - Précisez ce qui arrive à l’activité si l’application devient indisponible. - Confirmez si les utilisateurs doivent travailler sans réseau. - Confirmez si une expérience externe fortement personnalisée est nécessaire. - Renseignez le nombre d’utilisateurs actuels ; zéro explicite est valide. - Renseignez le nombre d’utilisateurs projetés ; zéro explicite est valide. - Les tâches, utilisateurs, erreurs et résultats attendus ont été observés. - Les sources de données, volumes, requêtes et avertissements de délégation ont été testés. - Les licences, connecteurs, flux, passerelles, API et comptes d’exécution ont été inventoriés. - Les parcours, le clavier, le zoom, le lecteur d’écran et les contraintes de marque ont été testés. - Les rôles, politiques de données et connecteurs autorisés ont été vérifiés dans le tenant. - Développement, test et production sont séparés, avec solutions et déploiements reproductibles. - Un propriétaire de secours, un responsable de support et une procédure d’incident sont nommés. - L’export, la restauration, les données, connexions et secrets ont été testés sur un environnement séparé. - Les cas les plus difficiles ont été testés et Power Platform couvre réellement le besoin visé. TCO COMPARABLES Formule : coûts ponctuels + coûts mensuels × 12 × années. Chaque poste est compté une fois. Power Apps actuel ou configuration minimale : Ponctuel : à confirmer Mensuel : à confirmer TCO 1 an : à confirmer TCO 3 ans : à confirmer TCO 5 ans : à confirmer Inconnues : Mode de licence ; Coût ponctuel : Conception, configuration ou construction initiale ; Coût ponctuel : Migration des données et coexistence ; Coût ponctuel : Formation et accompagnement du changement ; Coût ponctuel : Sortie et réversibilité prévues ; Coût mensuel : Hébergement ou plateforme hors licences ci-dessus ; Coût mensuel : Administration, maintenance et évolutions ; Coût mensuel : Support utilisateurs et continuité métier ; Coût mensuel : Capacité, connecteurs, supervision et autres Power Platform cadré ou renforcé : Ponctuel : à confirmer Mensuel : à confirmer TCO 1 an : à confirmer TCO 3 ans : à confirmer TCO 5 ans : à confirmer Inconnues : Mode de licence ; Coût ponctuel : Conception, configuration ou construction initiale ; Coût ponctuel : Migration des données et coexistence ; Coût ponctuel : Formation et accompagnement du changement ; Coût ponctuel : Sortie et réversibilité prévues ; Coût mensuel : Hébergement ou plateforme hors licences ci-dessus ; Coût mensuel : Administration, maintenance et évolutions ; Coût mensuel : Support utilisateurs et continuité métier ; Coût mensuel : Capacité, connecteurs, supervision et autres Architecture hybride : Ponctuel : à confirmer Mensuel : à confirmer TCO 1 an : à confirmer TCO 3 ans : à confirmer TCO 5 ans : à confirmer Inconnues : Mode de licence ; Coût ponctuel : Conception, configuration ou construction initiale ; Coût ponctuel : Migration des données et coexistence ; Coût ponctuel : Formation et accompagnement du changement ; Coût ponctuel : Sortie et réversibilité prévues ; Coût mensuel : Hébergement ou plateforme hors licences ci-dessus ; Coût mensuel : Administration, maintenance et évolutions ; Coût mensuel : Support utilisateurs et continuité métier ; Coût mensuel : Capacité, connecteurs, supervision et autres Application dédiée : Ponctuel : à confirmer Mensuel : à confirmer TCO 1 an : à confirmer TCO 3 ans : à confirmer TCO 5 ans : à confirmer Inconnues : Mode de licence ; Coût ponctuel : Conception, configuration ou construction initiale ; Coût ponctuel : Migration des données et coexistence ; Coût ponctuel : Formation et accompagnement du changement ; Coût ponctuel : Sortie et réversibilité prévues ; Coût mensuel : Hébergement ou plateforme hors licences ci-dessus ; Coût mensuel : Administration, maintenance et évolutions ; Coût mensuel : Support utilisateurs et continuité métier ; Coût mensuel : Capacité, connecteurs, supervision et autres LIMITES Ce dossier n’est ni un devis, ni une validation de licence, de sécurité ou de conformité. Confirmez les prix dans votre contrat, les politiques dans votre tenant et les résultats sur des cas réels.
Interpréter le résultat sans retenir trop vite l’option la moins chère
Un TCO incomplet n’est pas un TCO nul. Si les coûts de sortie ou de support de Power Apps restent inconnus, tout comme le coût de migration vers l’application dédiée, aucun des deux totaux ne doit être affiché. Une fois les données complètes, comparez aussi l’incertitude : montant contractuel, dépendance à une personne, fréquence d’évolution, capacité de restauration et coût d’une interruption.
Ne monétisez pas automatiquement chaque heure « gagnée ». Une heure libérée ne devient une économie de trésorerie que si une dépense est réellement évitée. Pour une analyse financière plus large, utilisez ensuite le guide dédié au retour sur investissement (ROI) d’une application métier, en gardant séparées trésorerie, capacité réaffectée et bénéfices qualitatifs.
Le coût ne suffit pas pour trancher. Les cinq scénarios suivants montrent pourquoi une même option peut être adaptée ou non selon l’audience, le contexte d’usage et les preuves encore manquantes.
Cinq scénarios fictifs pour voir comment la conclusion peut changer
Les exemples ci-dessous sont des compositions pédagogiques. Ils ne sont ni des cas clients, ni des budgets ou délais de marché. Leur rôle est de montrer quelles preuves orientent le choix — et quelles informations empêchent encore de conclure.
Scénario fictif composite 1 · formulaire interne
Vingt salariés saisissent des demandes simples
Les salariés sont déjà dans le tenant. Les données sont peu relationnelles, les requêtes délégables passent sur le volume projeté et aucun hors-ligne n’est requis. Les licences, environnements, rôles et propriétaires sont confirmés. Dans ce contexte, Power Apps peut être le choix le plus défendable ; une reconstruction devrait prouver un bénéfice absent du scénario.
Si la solution vit dans l’environnement par défaut avec un seul maker, la réponse devient « renforcer », pas forcément « reconstruire ».
Scénario fictif composite 2 · terrain
Des techniciens travaillent avec un réseau intermittent
La question décisive n’est pas « Power Apps a-t-il un mode offline ? », mais « ce profil Dataverse, sur ces appareils, avec ces pièces jointes et conflits, reproduit-il le travail attendu ? ». La réussite d’un pilote Power Apps Mobile peut suffire à justifier un renforcement. En cas d’échec, une fonction de collecte isolable ouvre la voie à un hybride. L’application dédiée devient défendable seulement si tout le travail exige un offline-first incompatible et inséparable.
Scénario fictif composite 3 · outil critique
Deux cent cinquante utilisateurs dépendent de l’outil
Deux cent cinquante utilisateurs ne rendent pas Power Apps inadapté par principe. À cette échelle, il faut toutefois connaître le coût contractuel, vérifier les droits de requêtes et les limites des connecteurs, puis tester la charge utile. Il faut aussi savoir qui intervient en l’absence du propriétaire et avoir exécuté une restauration. Tant que ces éléments manquent, il est trop tôt pour trancher. Power Apps reste envisageable, à condition qu’un responsable d’exploitation soit nommé.
Scénario fictif composite 4 · portail client
Identité externe et expérience de marque exigeante
Un partage canevas à des invités B2B, Power Pages et une application dédiée n’offrent ni les mêmes parcours ni le même modèle d’identité. Comparez inscription, récupération de compte, droits sur les données, consentement, marque, accessibilité, volume, coût externe et référencement lorsqu’il est pertinent.
Si Power Pages couvre le parcours, conservez-le dans la comparaison. Si seul un élément de marque ou d’identité manque, un module dédié peut compléter l’ensemble. Une reconstruction complète ne se justifie que si ces écarts persistent et si le coût total la rend soutenable.
Scénario fictif composite 5 · maker parti
L’application fonctionne mais personne n’ose la modifier
Le départ du maker révèle d’abord un défaut de propriété et de documentation. Inventoriez solutions, flux, connexions, comptes, règles et données ; nommez un suppléant ; restaurez sur un environnement séparé. Si l’application redevient déployable et compréhensible, le bon choix est probablement de la renforcer. Une reconstruction ne se justifie que si une limite fonctionnelle ou d’exploitation persiste après cette reprise.
Comment la même situation peut produire plusieurs conclusions
- Situation
- 20 salariés
- Preuve favorable à Power Apps
- Requêtes, licences et gouvernance validées
- Preuve favorable au dédié
- Parcours clé impossible à couvrir
- Verdict sans preuve
- Ne pas trancher
- Situation
- Terrain
- Preuve favorable à Power Apps
- Offline-first Dataverse testé avec succès
- Preuve favorable au dédié
- Offline critique, échec reproduit et frontière inséparable
- Verdict sans preuve
- Ne pas trancher
- Situation
- 250 utilisateurs
- Preuve favorable à Power Apps
- Coût et exploitation maîtrisés
- Preuve favorable au dédié
- Limite durable et bénéfices documentés justifiant le coût total ou le surcoût du dédié
- Verdict sans preuve
- Ne pas trancher
- Situation
- Portail client
- Preuve favorable à Power Apps
- Power Pages couvre identité et marque
- Preuve favorable au dédié
- Parcours externe essentiel non couvert
- Verdict sans preuve
- Ne pas trancher
- Situation
- Maker parti
- Preuve favorable à Power Apps
- Reprise et restauration réussies
- Preuve favorable au dédié
- Maintenance toujours impraticable après remédiation
- Verdict sans preuve
- Ne pas trancher
Ces exemples ne désignent pas une solution valable partout. Quand un test échoue, tentez d’abord une correction ciblée avant de financer une reconstruction.
Testez une correction ciblée avant de financer une reconstruction
Décrivez le problème et le résultat attendu, puis nommez le responsable, l’échéance et le test qui permettra de conclure. Un résultat toujours insatisfaisant renforce le dossier de reconstruction. Si la correction tient, une migration entière devient peut-être inutile.
Le test vous aide alors à distinguer un défaut remédiable d’une limite durable de plateforme.
Corrections à tester avant de conclure à une limite de plateforme
- Symptôme
- Résultats incomplets
- Ce qu’il faut vérifier
- Formule non délégable, type de colonne, filtre ou source
- Correction à tenter
- Réécrire la requête, indexer ou déplacer la logique vers une source adaptée
- Comment décider
- Comparer les résultats au-delà de 500 et 2 000 lignes
- Symptôme
- Lenteur
- Ce qu’il faut vérifier
- Appels répétés pour chaque ligne (effet N+1), flux synchrone, pièces jointes ou réseau
- Correction à tenter
- Mesurer, réduire les appels, mettre en cache ce qui peut l’être ou revoir le modèle
- Comment décider
- Temps et exactitude sur trois scénarios réels
- Symptôme
- Droits incohérents
- Ce qu’il faut vérifier
- Rôles cumulatifs, partage direct ou autorisation de source
- Correction à tenter
- Revoir groupes, rôles, équipes et principe du moindre privilège
- Comment décider
- Tests avec comptes internes, invités, révoqués et sans privilège
- Symptôme
- Déploiement fragile
- Ce qu’il faut vérifier
- Environnement par défaut, absence de solution ou connexion codée en dur
- Correction à tenter
- Séparer environnements, utiliser solutions, variables et références de connexion
- Comment décider
- Déploiement reproductible puis retour arrière sur environnement de test
- Symptôme
- Dépendance au maker
- Ce qu’il faut vérifier
- Propriétaire unique, flux personnels, absence de documentation
- Correction à tenter
- Suppléance, comptes appropriés, inventaire et procédure d’incident
- Comment décider
- Modification et restauration menées sans le maker initial
- Symptôme
- Usage externe difficile
- Ce qu’il faut vérifier
- Mauvaise surface, identité ou licence non choisie
- Correction à tenter
- Comparer invités B2B, Power Pages, hybride et dédié sur un parcours
- Comment décider
- Inscription, droits, révocation, marque et coût validés
- Symptôme
- Hors-ligne insuffisant
- Ce qu’il faut vérifier
- Architecture SharePoint/navigateur ou profil Dataverse inadéquat
- Correction à tenter
- Pilote Power Apps Mobile + Dataverse ou extraction d’un module terrain
- Comment décider
- Coupures, conflits et reprise réussis sur appareils réels
Chaque correction doit donc avoir un test, une échéance interne et une décision attendue. Sans ces trois éléments, le défaut reste ouvert et l’arbitrage est seulement repoussé.
Lecture du résultat
Un résultat satisfaisant, insatisfaisant ou absent ne conduit pas à la même décision
- Résultat satisfaisant : archivez la trace datée et poursuivez la comparaison.
- Résultat insatisfaisant : un défaut corrigeable appelle une nouvelle correction ciblée ; un périmètre ou un inventaire de licences incomplet maintient la décision en suspens ; une limite de plateforme reproduite ouvre l’étude de l’hybride puis de l’application dédiée.
- Preuve absente : aucune conclusion fiable n’est encore possible. La décision reste en attente et le prochain test doit être nommé.
Si le test reste négatif après cette correction bornée, la migration devient une hypothèse sérieuse. Elle doit encore préserver une voie de retour.
Si vous reconstruisez, organisez la migration, les tests et le retour à l’ancien outil
Le mot « migration » masque souvent quatre travaux : comprendre l’existant, construire la cible, déplacer les données et faire changer l’organisation. Aucun export de solution ne réalise seul ces quatre travaux. Transformez la décision en séquence vérifiable.
- Consigner l’existant. Notez la version de l’application, les solutions, flux, connecteurs, environnements, propriétaires, sources, comptes, licences et politiques de données.
- La recette avant les écrans. Décrivez trois cas normaux, les exceptions, les erreurs, les droits, les documents produits et les temps de réponse attendus. Ces résultats servent de référence métier ; les captures des écrans actuels ne suffisent pas.
- Une restauration indépendante. Exportez puis restaurez l’ancien outil sur un environnement séparé. Vérifiez les données, connexions, identités, secrets, rôles et automatisations avant de dépendre de cette reprise.
- Un transfert reproductible. Avant de déplacer les données, attribuez un propriétaire aux doublons, clés, valeurs manquantes, pièces jointes, historiques, référentiels et règles de conservation. Le transfert utilise ensuite un script ou une procédure versionnée, un journal des rejets, un rapprochement des comptes et une vérification d’intégrité. Une copie manuelle unique ne suffit pas.
- Le parcours complet, puis les tests utilisateurs.Construisez d’abord un seul parcours avec identité, données, règle, sortie, journal et support. Testez ensuite cas normaux, exceptions, droits, accessibilité, charge utile, appareils et fonctionnement dégradé avec les utilisateurs. Chaque écart reçoit un responsable et une décision. Ne reproduisez pas tous les écrans avant d’avoir prouvé l’architecture.
- Coexistence, bascule et retour à l’ancien outil.Nommez le système maître, les écritures autorisées, la synchronisation, la gestion des conflits et la durée de double exploitation afin d’éviter deux sources de vérité. Avant la bascule, jouez le retour : précisez le déclencheur, le décideur, la dernière donnée fiable, la durée maximale, la communication et la procédure de réactivation de l’ancien outil. Un document non testé reste une hypothèse.
- L’extinction après stabilité. Une fois la stabilité mesurée, retirez les accès et connexions, archivez ce qui doit l’être, révoquez les secrets, arrêtez les flux et les licences, conservez les preuves et fixez la durée de rétention.
Données
Système maître, clés, correspondance des champs, rejets, intégrité, historique et conservation.
Bascule
Coexistence, synchronisation, gel des écritures, conditions de bascule ou de suspension et retour à l’ancien outil.
Exploitation
Rôles, secrets, supervision, incident, support, sauvegarde, restauration et extinction.
Ne supprimez pas l’ancien outil au premier succès
Définissez avant la bascule la période d’observation, les indicateurs d’erreur, le décideur d’extinction et les preuves à conserver. La coexistence coûte de l’argent, mais une extinction prématurée peut rendre le retour à l’ancien outil impossible.
Vous n’avez pas besoin d’attendre la décision finale. Répartissez dès maintenant les preuves à réunir, les essais à mener et leurs responsables ; la réunion suivante pourra alors s’appuyer sur des résultats plutôt que sur des préférences.
Ce que vous pouvez faire lundi sans choisir encore la technologie
Réunissez le responsable métier, un créateur ou administrateur Power Platform, la personne en charge du tenant et un utilisateur représentatif. Ces quatre-vingt-dix minutes servent à inventorier les preuves disponibles et celles qui manquent, pas à choisir déjà une architecture.
- 1Choisir trois tâches réelles, dont une exception et un échec récent ; nommer l’audience et les comptes de test.
- 2Inventorier application, données, flux, connecteurs, passerelles, connexions et propriétaires.
- 3Relever les avertissements de délégation, comparer un résultat au-delà des premières lignes et tester une restauration séparée.
- 4Ouvrir licences et factures réelles, puis identifier les politiques DLP, environnements et rôles effectivement appliqués.
- 5Remplir l’atelier de décision et laisser la décision en attente si une preuve critique manque ou si un contrôle fondateur est insatisfaisant.
- 6Définir une correction ciblée ou un prototype du cas le plus risqué, avec un responsable, une date et les critères de la prochaine décision.
Livrable de la réunion
Le contenu minimal du compte rendu
- Orientation actuelle : décision en attente, conserver, renforcer, hybride ou dédié.
- Preuves positives et contradictions observées.
- Première inconnue critique à lever.
- Estimation du coût total des quatre options, ou liste exacte des montants encore inconnus.
- Responsable, test et date de la prochaine décision.
Si la question dépasse Power Platform, deux comparaisons voisines éclairent la même décision. Le guide Airtable, Notion ou application métier traite du même arbitrage hors écosystème Microsoft, et celui consacré au remplacement de Microsoft Access par une application web couvre le cas d’une base héritée. Si le besoin lui-même n’est pas encore établi, le diagnostic en trois situations évite d’acheter une solution avant d’avoir nommé le problème.
Trois contrôles décident ensuite du niveau d’exigence. La gestion des droits d’accès confronte les rôles réellement appliqués dans le tenant à ceux que le métier croit en place. Les contrôles de sécurité d’une application métier listent ce qu’il faut prouver avant d’élargir l’audience. Une bascule éventuelle suit la méthode de migration sans interruption de service, retour arrière compris.
Si votre équipe ne peut pas réunir ces éléments, ne commandez pas encore une réécriture. Commencez par un inventaire et un prototype des cas difficiles. Vous pouvez ensuite décrire votre projet à Hagnéré Code — ou d’abord vérifier comment choisir un prestataire sur preuves ; indiquez explicitement que conserver Power Apps reste une issue acceptable.
Avant de transmettre ce dossier, vérifiez enfin ce que chaque source prouve — et ce qu’elle ne prouve pas.
Comment lire les sources et les limites de ce guide
Les affirmations techniques et tarifaires de cette page reposent sur les pages produit, le guide de licences, Microsoft Learn et la Commission nationale de l’informatique et des libertés (CNIL), consultés à nouveau le 3 août 2026. La documentation officielle décrit le cadre général de la plateforme ; elle ne prouve pas que votre tenant, votre contrat, vos données et votre application correspondent au scénario décrit.
Les prix, licences, capacités et limites d’API sont volatils. Le chiffre public sert de repère daté, jamais de devis. Les contrôles de sécurité, accessibilité et conformité nécessitent les politiques, rôles, technologies d’assistance et obligations de votre contexte. Les scénarios fictifs illustrent une méthode et ne constituent pas des références de coût, de délai ou de performance.
Portée des principales familles de sources
- Source
- Page tarifaire
- Ce qu’elle peut établir
- Prix marketing public à une date
- Ce qu’elle n’établit pas
- Votre prix contractuel ou TCO
- Source
- Guide de licences
- Ce qu’elle peut établir
- Cadre général, droits publiés et règle de multiplexing
- Ce qu’elle n’établit pas
- L’interprétation de votre contrat particulier
- Source
- Microsoft Learn
- Ce qu’elle peut établir
- Fonctionnement et limites documentés
- Ce qu’elle n’établit pas
- La réussite dans votre application
- Source
- CNIL
- Ce qu’elle peut établir
- Principes de protection des données dès la conception
- Ce qu’elle n’établit pas
- La conformité de votre traitement particulier
- Source
- Test dans le tenant
- Ce qu’elle peut établir
- Résultat observable dans une configuration
- Ce qu’elle n’établit pas
- La stabilité future après changement
- Source
- Atelier de décision local
- Ce qu’elle peut établir
- Inconnues, contradictions et calculs saisis
- Ce qu’elle n’établit pas
- Audit, devis ou recommandation professionnelle
Une source officielle décrit le cadre général ; vos essais montrent le comportement obtenu dans votre configuration. Il faut les deux pour décider, sans confondre documentation et résultat observé.
Conserver Power Apps peut être la bonne décision
Ce guide n’est pas un argumentaire contre le low-code, c’est-à-dire le développement avec peu de code. Si les essais réussissent dans votre environnement, si l’équipe sait exploiter et restaurer l’application et si son coût total reste favorable à risque comparable, conserver Power Apps est un choix valable.