Notre méthode de formation Power Platform

D'où vient cette méthode

• Des heures sur Microsoft Learn pour les fondamentaux.
• Des heures sur les chaînes de Reza Dorani et Shane Young pour voir construire.
• Des déplacements en Europe et aux États-Unis pour suivre l'actualité produit.
• Des dizaines de projets en clientèle, où l'application doit fonctionner en production.
• Et surtout : des heures sur les forums Power Apps et Power Automate à répondre à des inconnus.

C'est le forum qui apprend le plus. Un problème réel, un contexte incomplet, aucune solution toute faite. Il faut poser les bonnes questions avant de proposer quoi que ce soit. C'est exactement la posture qu'on transmet en formation.

Les cinq principes

Déroulé type d'une journée

1. Heure 1
   Cadrage

   On choisit ensemble le processus réel qui servira de support.
2. Heures 2 et 3
   Modélisation des données

   Listes SharePoint ou tables Dataverse, colonnes, relations, choix du bon support selon le volume.
3. Heures 4 et 5
   Construction de l'application

   Sans aucune mise en forme.
4. Heure 6
   Automatisation Power Automate

   Notification, approbation, écriture.
5. Heure 7
   Test et revue

   Test par un utilisateur qui n'a pas construit, puis revue de dette technique et plan de suite.

Les bonnes pratiques transmises systématiquement

Ces points reviennent dans chaque formation, quel que soit le format. Ce sont ceux qui coûtent le plus cher quand ils sont découverts en production.

• Délégation : Comprendre la limite de 500 lignes par défaut, savoir la porter à 2000, et connaître les fonctions délégables selon la source. Elles ne sont pas les mêmes entre SharePoint, Dataverse et SQL Server. Une application non déléguée a l'air de fonctionner et renvoie des résultats faux.
• Indexation SharePoint : Indexer les colonnes utilisées en filtre. Sans index, la liste se bloque au-delà du seuil d'affichage.
• Nommage : Préfixer les contrôles et les variables. Screen1 et Button2 rendent l'application impossible à reprendre par quelqu'un d'autre.
• Variables : Savoir choisir entre Set, UpdateContext et les collections. Ne pas empiler des variables globales par défaut.
• Formules nommées : Sortir la logique de OnStart vers App.Formulas quand c'est possible. L'application démarre plus vite et la logique est centralisée.
• Variables d'environnement : Les URL, les adresses mail et les identifiants de site ne sont jamais écrits en dur. Sinon la migration vers la recette ou la production casse tout.
• Gestion d'erreur dans Power Automate : Utiliser des scopes Try et Catch avec la configuration Configure run after. Un flux qui échoue en silence est pire qu'un flux absent.
• Environnements séparés : Développement, recette, production. Les solutions gérées pour transporter, jamais de modification directe en production.
• Traçabilité : Un écran ou une variable de version dans l'application, et un journal des changements. On doit pouvoir dire qui a modifié quoi et quand.
• Périmètre de reprise : Savoir identifier ce qu'on peut modifier soi-même et ce qui demande un appel à un architecte. C'est le point le plus important pour une équipe qui reprend une application existante.

Pour aller plus loin sur le premier point, lire notre article sur la délégation Power Apps.

Ce que cette méthode ne fait pas

Formats et tarifs

• ›Découverte Power Platform : 1 jour.
• ›Citizen developer encadré : 2 jours.
• ›Parcours Power Apps : 3 jours.
• ›1 000 € HT par jour, jusqu'à 8 participants. 600 € HT la demi-journée. 100 € HT par participant supplémentaire de 9 à 12. Forfait de personnalisation 1 000 € HT. Déplacement hors Île-de-France facturé au réel.