Power Apps n’est pas un outil sans code. La plateforme de Microsoft se positionne sur un spectre qui va du no-code au code-first avec React et TypeScript, et la frontière entre ces modes s’estompe à chaque mise à jour. Réduire Power Apps à une solution « sans code » revient à ignorer la moitié de ses capacités actuelles.
Code Apps : Power Apps intègre du développement full-code en React
L’introduction des Power Apps Code Apps en septembre 2026 change la nature même de la plateforme. Un développeur peut désormais écrire une application web moderne en React, TypeScript et Vite dans son IDE habituel, puis la publier directement dans Power Apps via le Power Apps CLI.
A lire aussi : Puis-je apprendre le codage sans aucune connaissance ?
Concrètement, l’application est développée localement comme une SPA classique. Un flux « build and push » la relie à un environnement Power Platform, génère une URL Power Apps et la soumet aux mêmes règles de gouvernance, DLP et permissions que n’importe quelle app Canvas ou Model-driven.
Ce scénario est du développement professionnel pur. Aucune formule Power Fx, aucun éditeur visuel. Le fait que Microsoft l’intègre dans Power Apps montre que la plateforme ne se limite plus au low-code, encore moins au no-code.
A voir aussi : Java est-il bon pour le développement Web
Canvas vs Model-driven : le niveau de code réellement nécessaire
La distinction entre les deux types d’applications Power Apps détermine le degré de « sans code » auquel on peut prétendre.
Applications Model-driven et Dataverse
Les apps Model-driven génèrent leur interface à partir du modèle de données dans Dataverse. La configuration se fait par paramétrage : vues, formulaires, règles métier. Un utilisateur sans compétence technique peut produire une application fonctionnelle pour des scénarios de gestion standardisés.
Nous observons que ce mode reste le plus proche du no-code véritable. Tant que le processus métier suit les conventions de Dataverse, le besoin en code reste marginal.
Applications Canvas et Power Fx
Les apps Canvas offrent une liberté visuelle complète, mais cette liberté a un coût technique. Dès qu’on dépasse un formulaire basique, Power Fx devient nécessaire pour gérer la logique conditionnelle, les délégations de requêtes, les collections et les contextes de navigation.
Power Fx n’est pas un langage de programmation au sens classique, mais sa syntaxe s’apparente à celle d’Excel poussé dans ses limites. Un citizen developer peut s’y perdre rapidement sur des apps de plus de dix écrans avec des sources de données multiples.
- Formules de délégation : nécessaires dès que les jeux de données dépassent la limite de lignes par défaut, ce qui exige une compréhension technique des connecteurs
- Gestion des collections et variables : nécessaire pour le state management dans les apps Canvas complexes, comparable à un mini framework front-end
- Composants personnalisés PCF (Power Apps Component Framework) : développés en TypeScript, ils étendent l’interface Canvas bien au-delà du no-code
Co-édition par agents IA : un troisième mode ni no-code ni classique
Microsoft a rendu disponible en septembre 2026 la co-édition assistée par agents IA dans Power Apps Studio. L’utilisateur décrit son besoin en langage naturel, et Copilot génère l’application et son modèle de données.
Ce mode brouille la classification. L’utilisateur ne code pas, mais il ne manipule pas non plus un éditeur visuel au sens traditionnel. Il pilote un agent qui produit du Power Fx, configure des connecteurs et structure les tables Dataverse.
Nous recommandons de ne pas confondre « je n’ai pas écrit de code » avec « il n’y a pas de code ». L’agent génère du code Power Fx et des configurations que quelqu’un devra relire, déboguer et maintenir. Sur un processus métier critique, déléguer entièrement à Copilot sans revue technique expose à des erreurs de logique silencieuses.
Power Platform et connecteurs : où le no-code atteint ses limites
L’écosystème Power Platform propose plus de mille connecteurs pour relier Power Apps à des services tiers et aux briques Microsoft (Teams, SharePoint, Dynamics 365, SQL Server). La configuration d’un connecteur standard relève effectivement du no-code.
La réalité se complique avec les connecteurs personnalisés. Dès qu’une API tierce n’a pas de connecteur natif, il faut créer un connecteur custom à partir d’une définition OpenAPI, gérer l’authentification OAuth, et parfois écrire des transformations de données dans Azure Functions ou Power Automate.
- Connecteurs premium : nécessitent une licence Power Apps Premium (tarif public affiché à 19,10 euros HT par utilisateur et par mois en paiement annuel), ce qui implique une décision budgétaire, pas seulement technique
- Connecteurs personnalisés : exigent une maîtrise des API REST, de l’authentification et souvent du JSON, compétences qui sortent du périmètre d’un utilisateur no-code
- Politiques DLP : la gouvernance des connecteurs impose des contraintes que seul un administrateur Power Platform peut configurer correctement
Positionnement réel de Power Apps sur l’échelle no-code / low-code / pro-code
Power Apps couvre trois niveaux de développement simultanément. Les apps Model-driven avec Dataverse permettent un usage quasi no-code pour des cas métier structurés. Les apps Canvas avec Power Fx relèvent du low-code dès que la complexité augmente. Les Code Apps en React/TypeScript sont du développement professionnel à part entière.
Qualifier Power Apps de « sans code » est une simplification marketing. La plateforme permet de démarrer sans écrire une ligne, mais la majorité des projets en production nécessitent du Power Fx ou du code. Le spectre s’est encore élargi avec les Code Apps et la co-édition par agents IA, qui ajoutent des modes de développement que la dichotomie no-code/low-code ne capture plus.
Pour un projet interne simple (formulaire de validation, tableau de bord opérationnel connecté à SharePoint), Power Apps fonctionne sans code. Pour tout le reste, prévoir des compétences techniques dans l’équipe reste la recommandation la plus honnête.
