⚡ Microsoft Power Apps – RAD / Low-Code (éco Microsoft)

Checklist (à imprimer)

• ✅ Données : Dataverse ou SharePoint/SQL ? (ownership clair) :contentReference[oaicite:14]{index=14}
• ✅ Volumétrie : taille listes/tables, besoin de filtres, perf (p95).
• ✅ Gouvernance : environnements, DLP, RBAC, audit.
• ✅ Process : approvals/notifications via Automate.
• ✅ ALM : dev → test → prod + rollback.
• ✅ Licence : vérifier plans/FAQ tenant. :contentReference[oaicite:15]{index=15}

Canvas : “tu dessines l’app”

Tu maîtrises :
- écrans / composants
- règles UI (formules)
- navigation
- connecteurs data

Bon pour :
- formulaire de saisie
- outil support interne
- app “terrain”
        

Model-driven : “l’app suit le modèle data”

Tu maîtrises :
- tables Dataverse
- formulaires/vues/commandes
- sécurité data
- process & intégrations

Bon pour :
- SI interne structuré
- besoin audit/security fort
        

Dataverse = tables, colonnes, relations pour apps métiers. :contentReference[oaicite:17]{index=17}

Règle de décision rapide

Si tu veux aller TRÈS vite sur UI -> Canvas
Si tu veux une structure data + gouvernance -> Model-driven (Dataverse)
Dans le doute : POC 1 semaine sur 1 use-case + volumétrie réelle
        

Connecteurs internes fréquents (SI)

Power Apps se connecte à Dataverse ou à de nombreuses sources (SharePoint, Microsoft 365, SQL…). :contentReference[oaicite:20]{index=20}

Azure (quand tu passes “niveau SI”)

Azure = utile si :
- intégrations event-driven
- fonctions / services externalisés
- monitoring centralisé
- besoins enterprise (secrets, identity, etc.)
        

Dataverse supporte l’intégration avec Azure (ex: passage de contexte d’exécution vers des solutions Azure). :contentReference[oaicite:21]{index=21}

Règles anti-catastrophe

• Ne mélange pas 15 sources dans la même app : commence par 1 “source of truth”.
• Isole l’intégration : si ça touche SI, passe par une couche d’API (idempotency, erreurs).
• Pense gouvernance : environnements, DLP, secrets, audit.

Template opérationnel (à copier)

Use-case : Demande d’accès (internal)
Data (Dataverse/SharePoint) :
- Request(id, requester, type, status, createdAt)
- Decision(requestId, approver, decision, comment)

UI :
- List (My requests / Pending approvals)
- Form (create/edit)
- Admin view (audit)

Automate :
- on submit -> notify approver (Teams/Email)
- on approve -> status=Approved -> notify requester
        

Qualité minimale

• Validation inline + messages utilisateur clairs.
• RBAC (qui voit quoi) + audit actions sensibles.
• Environnements : DEV/TEST/PROD + release notes + rollback.

Power Apps vise le développement rapide d’apps métiers connectées à plusieurs sources. :contentReference[oaicite:22]{index=22}

KPI d’outil interne

- temps moyen d’un traitement (submit -> done)
- backlog approvals
- taux d’erreur (form submissions)
- p95 latence écran principal
- adoption (users/week)
        

DLP (Data Loss Prevention)

Objectif :
- empêcher mélange de connecteurs “sensibles” / “publics”
- contrôler exfiltration data
- imposer des policies par environnement
        

RBAC & audit

• Rôles : Admin, Maker, User, Auditor.
• Accès data : par entité + par “owner/team”.
• Audit : actions sensibles (submit/approve/delete).

Dataverse est conçu pour stocker/manager des données d’apps métiers de façon sécurisée. :contentReference[oaicite:23]{index=23}

ALM : discipline de release

- versionner
- release notes
- smoke tests
- rollback plan
- monitoring post-release
        

Pour la partie licences/plans, Microsoft publie une FAQ Power Platform (variable selon offres). :contentReference[oaicite:24]{index=24}

Delegation (concept clé)

Power Apps doit parfois composer avec des limites côté source de données : certaines opérations ne peuvent pas être “poussées” côté serveur, ce qui oblige à traiter côté client (et ça ne scale pas). Microsoft appelle ça “data source limits / delegation”. :contentReference[oaicite:25]{index=25}

Règles pratiques :
- filtre/tri côté serveur (delegable) si possible
- éviter les fonctions non délégables sur gros volumes
- indexer / structurer la data (Dataverse ou SQL)
        

Mitigations

Heuristique de bascule

Si tu as :
- logique métier "heavy"
- gros volumes + requêtes complexes
- besoin d’architecture modulaire + tests poussés
=> Power Apps reste possible, mais coût ↑
=> benchmark Mendix/OutSystems ou dev custom
        

Règle de choix

Si tu es "Microsoft centric" + outils internes -> Power Apps
Si tu veux un programme enterprise multi-apps -> Mendix / OutSystems
Si tu veux desktop CRUD rapide -> WinDev
        

Risques & mitigations

Playbook “démarrer Power Apps en entreprise” (7 jours)

1. Définir 1 use-case internal tool + owner métier.
2. Choisir data source (SharePoint vs Dataverse). :contentReference[oaicite:30]{index=30}
3. Construire 3 écrans (List / Form / Admin).
4. Ajouter 1 flow Automate (approval + notification).
5. Mettre DEV/TEST/PROD + DLP + RBAC.
6. Tester volumétrie + delegation risks. :contentReference[oaicite:31]{index=31}
7. Release notes + rollback plan + KPI adoption/perf.