PL-900, PL-200, PL-300, PL-400, PL-500, PL-600…

Le problème, c’est que la liste est longue, certains examens évoluent, et beaucoup de gens passent “la mauvaise certif” par défaut.

L’objectif de cet article est simple : vous aider à comprendre à quoi servent les certifications Power Platform, quelles sont celles qui existent réellement aujourd’hui, et surtout laquelle choisir selon votre profil.

1. À quoi sert une certification Power Platform ?#

Une certification Microsoft n’est pas juste un badge LinkedIn. Bien utilisée, elle sert à 3 choses.

1) Structurer votre apprentissage#

Power Platform est vaste : Power Apps, Power Automate, Dataverse, Power BI, gouvernance, sécurité, ALM…

Quand on apprend en autodidacte, on maîtrise souvent seulement ce qu’on utilise au quotidien.

Une certification oblige à couvrir les sujets “invisibles” mais indispensables en entreprise (licensing, sécurité, solutions, déploiement…).

2) Prouver votre niveau de manière crédible#

Pour un recruteur, un client ou une DSI, une certification permet de valider rapidement que vous connaissez :

• les concepts fondamentaux,
• les bonnes pratiques Microsoft,
• et le vocabulaire “officiel”.

Ce n’est pas parfait, mais c’est un signal clair.

3) Accélérer votre progression professionnelle#

En freelance ou en cabinet, les certifications peuvent servir à :

• rassurer un prospect,
• justifier un TJM plus élevé,
• être positionné sur des missions plus stratégiques,
• renforcer votre légitimité sur LinkedIn.

2. Ce qu’une certification ne remplace pas#

Il faut être lucide : une certification ne prouve pas que vous êtes “bon en projet”.

Ce qu’elle ne remplace pas :

• l’expérience réelle en production,
• la gestion de la performance et des erreurs,
• l’ALM en conditions réelles,
• la gouvernance (DLP, environnements, rôles, CoE…),
• la capacité à cadrer un besoin métier.

👉 La certification est un accélérateur, pas une preuve absolue.

3. Comment Microsoft structure les certifications Power Platform#

Microsoft organise ses certifications par niveaux.

Niveau Fundamentals#

C’est le niveau “vision globale”.

Idéal pour démarrer, comprendre l’écosystème, et parler le bon langage.

Niveau Associate / Specialty#

C’est le niveau “professionnel opérationnel” :

• maker avancé,
• consultant fonctionnel,
• analyste BI,
• développeur,
• expert RPA.

C’est le niveau le plus rentable pour une carrière.

Niveau Expert#

C’est le niveau architecture et décisions complexes, réservé aux profils expérimentés.

4. Panorama clair des certifications Power Platform disponibles#

Voici les certifications Power Platform principales (les plus connues et les plus utiles).

PL-900 — Power Platform Fundamentals#

La certification d’entrée.

Elle valide que vous comprenez :

• Power Apps, Power Automate, Power BI, Power Pages,
• Dataverse,
• les concepts de connecteurs,
• la logique low-code.

➡️ Parfait pour démarrer, ou pour un profil non technique (chef de projet, manager, AMOA).

PL-200 — Power Platform Functional Consultant#

La certification “terrain entreprise”.

Elle couvre :

• Dataverse (tables, relations, business rules),
• sécurité (rôles, BU, partage, FLS),
• solutions et ALM,
• automatisation Power Automate,
• intégrations Microsoft 365.

➡️ C’est souvent la plus pertinente pour les consultants et freelances.

PL-300 — Power BI Data Analyst#

La certification Power BI.

Elle valide surtout :

• Power Query,
• modélisation,
• DAX,
• optimisation,
• déploiement, RLS, gouvernance Power BI.

➡️ À prendre si Power BI est une vraie compétence principale.

PL-400 — Power Platform Developer#

La certification pro-code.

Elle couvre :

• Dataverse SDK,
• plugins,
• PCF,
• Web API,
• intégrations avancées,
• ALM technique.

➡️ Très valorisée, mais exige une vraie expérience dev.

PL-500 — Power Automate RPA Developer#

La certification orientée automatisation desktop.

Elle valide :

• Power Automate Desktop,
• UI automation,
• orchestration cloud + desktop,
• monitoring et déploiement RPA.

➡️ Très utile si votre spécialité est la RPA.

PL-600 — Power Platform Solution Architect#

La certification la plus “prestigieuse”.

Elle valide :

• architecture globale,
• choix Canvas vs Model-driven vs Pages,
• sécurité et gouvernance,
• stratégie ALM,
• intégrations entreprise,
• gestion des contraintes et des risques.

➡️ À viser uniquement si vous avez déjà une vraie expérience multi-projets.

5. Quelle certification choisir selon votre profil ?#

Voici une grille simple, sans ambiguïté.

Vous débutez ou vous voulez une vue globale#

➡️ PL-900

Vous construisez des apps et flows en entreprise (maker avancé)#

➡️ PL-900 puis PL-200

Vous êtes consultant fonctionnel / chef de projet Power Platform#

➡️ PL-200

Vous faites surtout Power BI#

➡️ PL-300

Vous faites du pro-code (plugins, PCF, intégrations, API)#

➡️ PL-400

Vous êtes orienté RPA / Power Automate Desktop#

➡️ PL-500

Vous êtes senior et vous concevez des solutions complètes#

➡️ PL-600

6. Parcours recommandés (dans quel ordre les passer)#

Parcours “Power Platform généraliste” (le plus logique)#

PL-900 → PL-200 → (ensuite PL-400 ou PL-600 selon évolution)

Parcours “consultant / freelance”#

PL-900 → PL-200 → PL-600

Parcours “développeur”#

PL-900 → PL-400 → PL-600

Parcours “data / BI”#

PL-900 → PL-300

Parcours “RPA”#

PL-900 → PL-500

8. Conclusion : quelle certification choisir en 1 phrase ?#

• Vous commencez : PL-900
• Vous voulez être crédible en entreprise : PL-200
• Vous êtes BI : PL-300
• Vous êtes développeur : PL-400
• Vous faites de la RPA : PL-500
• Vous êtes senior : PL-600

Si vous voulez une trajectoire “carrière + visibilité LinkedIn”, la combinaison la plus rentable aujourd’hui reste :

PL-900 + PL-200, puis PL-600 si vous pouvez.

Ce guide vous aide à prendre une décision éclairée basée sur des critères techniques et financiers concrets.

1. Comprendre les véritables limites de chaque plateforme#

Excel : prototypage rapide, limites structurelles#

Forces techniques :

• Déploiement instantané (OneDrive/SharePoint)
• Formules natives pour calculs métiers
• Modification structure sans migration
• Pas de coût de licence supplémentaire

Limites techniques réelles :

• Délégation Power Apps : 5 000 lignes maximum (non extensible)
• Concurrence : verrouillage fichier entier lors de l’édition
• Pas de transactions ACID : risque de corruption sur écritures simultanées
• Pas de typage strict : validation côté client uniquement
• Pas d’audit trail : aucune traçabilité native des modifications

Seuils de rupture :

• Au-delà de 1 000 enregistrements → performances dégradées dans Power Apps
• Plus de 3 utilisateurs simultanés → problèmes de concurrence
• Besoin de relations entre tables → non gérable

Cas d’usage valides :

• Prototypes/POC à durée de vie inférieure à 3 mois
• Données de référence statiques (moins de 500 lignes)
• Fichiers personnels ou équipe inférieure à 5 personnes

SharePoint : la plateforme collaborative sous-estimée#

Forces techniques :

• Scalabilité réelle : millions d’items par liste (avec architecture adaptée)
• Sécurité granulaire : item-level permissions, folder-level security
• Relations natives : colonnes Lookup, Managed Metadata
• Versioning natif : historique complet des modifications
• Intégration documentaire : pièces jointes sans limite de taille

Limites techniques réelles :

• Seuil de vue de liste : 5 000 items par requête (contournable avec index)
• Délégation Power Apps : limitée à certains opérateurs (égalité, StartsWith, pas Contains)
• Performance des Lookup : dégradation sur relations supérieures à 2 niveaux
• Pas de transactions : pas de rollback natif sur opérations multiples
• Complexité des calculs : colonnes calculées limitées (pas de lookups dans formules)

Optimisations critiques souvent ignorées :

Anti-pattern : Requête non indexée

Filter(SharePointList; Contains(Title; "recherche"))

Pattern optimisé : Index + StartsWith

1. Créer index sur colonne Title dans SharePoint
2. Utiliser opérateur délégable

Filter(SharePointList; StartsWith(Title; "recherche"))

Architecture performante SharePoint :

1. Créer des index sur toutes les colonnes utilisées dans Filter/LookUp
2. Limiter les vues à moins de 5 000 items via folders ou filtres de vue
3. Utiliser des colonnes calculées côté serveur pour les agrégations simples
4. Archiver les données anciennes dans une liste séparée (partitionnement manuel)

Seuils de rupture réels :

• Au-delà de 50 000 items actifs → nécessite architecture avancée (index, vues, archivage)
• Plus de 10 relations inter-listes → devient difficile à maintenir
• Besoin de workflows complexes avec états → limites de Power Automate cloud flows

Cas d’usage valides :

• Applications métiers jusqu’à 100 000 enregistrements avec architecture optimisée
• Forte composante documentaire (gestion de fichiers)
• Budget limité (inclus dans M365)
• Équipe sans compétences Dataverse

Dataverse : la base de données enterprise-grade#

Forces techniques :

• Base relationnelle complète : relations 1:N, N:N avec intégrité référentielle
• Scalabilité illimitée : millions d’enregistrements sans dégradation
• Délégation totale : tous opérateurs supportés dans Power Apps
• Transactions ACID : rollback automatique, isolation des écritures
• Typage fort : validation serveur, contraintes d’intégrité
• Sécurité avancée : row-level security, field-level security, hierarchical security
• Audit complet : traçabilité native de toutes les opérations
• Solutions managées : déploiement ALM avec gestion de versions
• Business rules : logique métier côté serveur (indépendante de l’UI)
• Plugins et workflows : extensibilité via C# pour logique complexe

Limites et coûts réels :

Coût réel sur 3 ans – exemple concret :

Scénario : 50 utilisateurs, application métier critique

Option 1 – SharePoint optimisé :

• Licences M365 : incluses (0€ supplémentaire)
• Développement initial : 40h × 800€ = 32 000€
• Maintenance annuelle : 5 000€
• TOTAL 3 ans : 47 000€

Option 2 – Dataverse Per App :

• Licences : 50 users × 10€/mois × 36 mois = 18 000€
• DB capacity : 50GB × 40€ × 36 mois = 72 000€
• Développement initial : 60h × 800€ = 48 000€
• Maintenance annuelle : 8 000€
• TOTAL 3 ans : 162 000€

Différence : +245% de coût

Seuils de justification économique :

• Volume : supérieur à 100 000 enregistrements actifs avec croissance forte
• Complexité relationnelle : supérieur à 15 tables avec relations multiples
• Criticité : données métiers stratégiques (CRM, ERP, finance)
• Intégration Dynamics 365 : si déjà présent dans l’entreprise
• Conformité stricte : audit trail réglementaire obligatoire

Cas d’usage obligatoires :

• CRM / ERP / Gestion commerciale
• Applications transactionnelles (commandes, inventaire, facturation)
• Workflows métiers complexes avec états et approbations
• Intégration native avec Dynamics 365
• Multi-environnements avec ALM structuré (Dev/Test/Prod)

2. Matrice de décision technique#

Critères de volumétrie#

Critères de complexité relationnelle#

Critères de concurrence utilisateurs#

3. Patterns hybrides : le meilleur des deux mondes#

Pattern 1 : SharePoint + Dataverse sélectif#

Principe : Données documentaires sur SharePoint, données transactionnelles sur Dataverse

Architecture exemple :

• Documents et pièces jointes → SharePoint (natif)
• Commandes clients → Dataverse (transactionnel)
• Produits catalogue → Dataverse (référentiel)
• Relation : Commande.DocumentID → SharePoint via lien

Avantages :

• Stockage fichiers gratuit (SharePoint)
• Performance transactionnelle (Dataverse)
• Coût optimisé (moins de GB Dataverse)

Pattern 2 : SharePoint avec cache Dataverse#

Principe : Données volumineuses sur SharePoint, cache performant sur Dataverse

Workflow :

1. Données principales dans SharePoint (historique complet)
2. Synchronisation quotidienne vers Dataverse (90 derniers jours)
3. Power Apps interroge Dataverse uniquement
4. Archivage automatique SharePoint → Azure Blob Storage

Avantages :

• Performance Power Apps optimale
• Rétention longue durée économique
• Capacité Dataverse maîtrisée

Pattern 3 : Excel pour référentiels statiques#

Principe : Données transactionnelles Dataverse, référentiels simples Excel

Exemple :

• Commandes, clients → Dataverse
• Liste pays, devises, unités de mesure → Excel
• Chargement Excel au démarrage dans collection locale

Avantages :

• Modification référentiels sans déploiement
• Pas de pollution Dataverse avec données statiques
• Coût optimisé

4. Checklist de décision#

Analyse préliminaire (répondre OUI/NON)#

Volume et croissance :

• Plus de 50 000 enregistrements prévus sur 2 ans ?
• Croissance supérieure à 20% par an ?
• Archivage impossible ou non souhaité ?

Complexité technique :

• Plus de 10 tables/entités ?
• Relations N:N nécessaires ?
• Logique métier serveur requise (calculs complexes, validations) ?
• Transactions multi-tables avec rollback ?

Criticité métier :

• Données financières ou réglementées ?
• SLA de disponibilité supérieur à 99% requis ?
• Perte de données = impact business critique ?
• Audit trail réglementaire obligatoire ?

Concurrence et performance :

• Plus de 50 utilisateurs simultanés ?
• Besoin de temps de réponse inférieur à 2 secondes ?
• Écritures simultanées sur mêmes enregistrements ?

Budget et licences :

• Budget récurrent supérieur à 10 000€/an disponible ?
• Dynamics 365 déjà déployé dans l’entreprise ?
• Compétences Dataverse en interne ou budget formation ?

Gouvernance et ALM :

• Environnements multiples requis (Dev/Test/Prod) ?
• Déploiements automatisés via CI/CD nécessaires ?
• Gestion de versions et rollback obligatoires ?

Scoring de décision#

0-3 OUI → SharePoint suffit (avec optimisations)

4-8 OUI → Analyse coût/bénéfice approfondie requise

9+ OUI → Dataverse recommandé

5. Erreurs fréquentes et mythes#

Mythe 1 : "Dataverse est toujours plus performant"#

Faux. Sur de petits volumes (moins de 10 000 items), SharePoint avec index bien configurés peut être aussi rapide que Dataverse, voire plus sur certaines opérations de recherche full-text.

Mythe 2 : "SharePoint ne scale pas"#

Faux. SharePoint peut gérer des dizaines de millions d’items avec une architecture correcte (exemple : Microsoft utilise SharePoint pour Viva Topics avec des milliards d’items). Le problème est la délégation Power Apps, pas SharePoint lui-même.

Mythe 3 : "Excel est toujours à éviter"#

Faux. Pour des référentiels statiques (moins de 500 lignes) modifiés manuellement, Excel peut être plus simple et efficace qu’une table Dataverse. Exemple : liste de codes postaux, pays, catégories métiers.

Mythe 4 : "Dataverse = pas de limites"#

Faux. Dataverse a des limites :

• API calls : 40 000/user/jour (ou 6 000 en Per App)
• Taille message : 128 MB max par requête
• Timeout requêtes : 2 minutes max
• Nombre de tables : 1 024 max par environnement

Erreur 1 : Ne pas évaluer le coût total sur 3-5 ans#

Beaucoup de projets démarrent sur Dataverse sans calculer :

• Licences utilisateurs (récurrentes)
• Capacité DB (croissance exponentielle)
• Environnements multiples (sandbox, dev, test)
• Formation et montée en compétences

Résultat : Facture qui explose après 2 ans.

Erreur 2 : Sous-estimer l’optimisation SharePoint#

Beaucoup abandonnent SharePoint après des problèmes de performance, sans avoir :

• Créé des index sur les colonnes filtrées
• Utilisé des folders pour partitionner
• Optimisé les requêtes Power Apps (StartsWith vs Contains)
• Archivé les données anciennes

Résultat : Migration Dataverse coûteuse alors que SharePoint aurait suffi.

Erreur 3 : Choisir en fonction de la compétence de l’équipe#

"On connaît SharePoint, donc on reste sur SharePoint" même si le besoin justifie Dataverse.

Résultat : Dette technique, workarounds complexes, maintenance cauchemardesque.

6. Cas réel et retour d’expérience#

Migration SharePoint → Dataverse évitée (économie 80k€)#

Contexte :

• Application RH : gestion des congés
• 200 utilisateurs, 25 000 demandes/an
• Performance SharePoint jugée "insuffisante"
• Migration Dataverse planifiée (120k€ sur 3 ans)

Action :

• Audit de l’architecture SharePoint actuelle
• Création de 4 index sur colonnes clés
• Ajout de folders par année pour partitionnement
• Optimisation des formules Power Apps (délégation)
• Archivage automatique supérieur à 3 ans

Résultat :

• Temps de chargement : 8s → 1,2s
• Aucun problème de performance après optimisation
• Coût : 8 000€ (refonte) vs 120k€ (migration)
• ROI : 112k€ économisés

Leçon : Ne pas migrer par défaut. Optimiser d’abord.

7. Arbre de décision simplifié#

Question 1 : Dynamics 365 déjà déployé ?

• OUI → Dataverse (synergie native)
• NON → Question 2

Question 2 : Budget supérieur à 10k€/an disponible ?

• NON → SharePoint ou Excel
• OUI → Question 3

Question 3 : Volume supérieur à 100 000 enregistrements OU croissance supérieure à 50%/an ?

• OUI → Dataverse
• NON → Question 4

Question 4 : Plus de 10 tables avec relations complexes (N:N, hiérarchiques) ?

• OUI → Dataverse
• NON → Question 5

Question 5 : Criticité métier forte (finance, réglementaire, CRM) ?

• OUI → Dataverse
• NON → Question 6

Question 6 : Besoin ALM structuré (CI/CD, solutions managées) ?

• OUI → Dataverse
• NON → SharePoint

Exception : Si moins de 1000 enregistrements ET prototype → Excel acceptable

Conclusion : la décision doit être data-driven#

Le choix entre Excel, SharePoint et Dataverse n’est pas idéologique mais technique et économique :

1. Analysez vos besoins réels : volume, complexité, criticité, budget
2. Calculez le TCO sur 3-5 ans : licences + capacité + développement + maintenance
3. Évaluez les compétences : formation nécessaire vs expertise disponible
4. Testez avec des volumes réalistes : POC avec 80% du volume final, pas 10 lignes
5. Considérez l’hybride : souvent la solution optimale coût/performance

Règles d’or :

✅ Excel : POC, prototypes, référentiels statiques moins de 500 lignes

✅ SharePoint : Apps métiers jusqu’à 100k enregistrements avec architecture optimisée

✅ Dataverse : Apps stratégiques supérieur à 100k enregistrements, relationnel complexe, intégrations multiples

✅ Hybride : Le meilleur des deux mondes dans 60% des cas

La pire erreur : choisir par défaut sans analyse. La meilleure décision : celle basée sur des critères mesurables et un TCO calculé.

Ressources complémentaires :

• Limites de délégation SharePoint (Microsoft)
• Pricing Dataverse Calculator
• SharePoint limits and boundaries

Dans ce guide technique, je vais tenter d’explorer :

• Les fondamentaux et la syntaxe complète
• Le modèle d’exécution et la délégation
• Les patterns avancés et anti-patterns
• L’optimisation des performances
• Les cas d’usage réels en production

1. Anatomie de LookUp : au-delà de la syntaxe#

Syntaxe complète#

LookUp(Source; Condition; Result)

• Source : Table, collection, ou source de données connectée
• Condition : Expression booléenne évaluée pour chaque enregistrement
• Result (optionnel) : Expression retournant la valeur souhaitée (pas seulement un nom de colonne)

Ce que retourne LookUp#

• Si Result est omis → retourne l’enregistrement complet (record)
• Si Result est spécifié → retourne la valeur évaluée (peut être une formule)
• Si aucune correspondance → retourne Blank()
• LookUp retourne toujours le premier enregistrement correspondant selon l’ordre de la source

⚠️ Point critique : L’ordre n’est PAS aléatoire, mais il est non déterministe si la source n’est pas explicitement triée. Sur SharePoint, c’est souvent l’ordre d’ID. Sur Dataverse, ça dépend de l’index utilisé.

2. Délégation : comprendre les limites réelles#

Qu’est-ce qui est délégable ?#

La délégation de LookUp dépend de trois facteurs :

1. La source de données
2. Les opérateurs utilisés dans la condition
3. Les fonctions utilisées dans Result

Tableau de délégation par source#

Exemple de délégation cassée sur SharePoint#

`// ❌ NON DÉLÉGABLE sur SharePoint (Contains non supporté) LookUp(Documents; Contains(Title; "rapport"); ‘Created By’)

// ✅ DÉLÉGABLE sur SharePoint LookUp(Documents; StartsWith(Title; "rapport"); ‘Created By’)`

Comment vérifier la délégation ?#

Dans Power Apps Studio, les formules non délégables affichent un **triangle ** avec l’avertissement "delegation warning".

3. Modèle d’exécution et performance#

Où et quand LookUp s’exécute#

Le contexte d’exécution de LookUp est crucial pour les performances :

Erreur classique déjà observée#

Label1.Text = LookUp(Employees; Email = TextInput1.Text; FullName)

Pourquoi est-ce une erreur? Chaque caractère tapé réévalue la formule. Sur une table de 5000 employés non délégable, cela provoque un freeze de l’app.

Pattern correct#

` TextInput1.OnChange: Set(varEmployeeName; LookUp(Employees; Email = TextInput1.Text; FullName) )

Label1.Text: varEmployeeName`

4. Techniques avancées#

a) LookUp avec formule dans Result#

Result peut être une expression, pas seulement un nom de colonne :

`// Calcul direct dans Result LookUp(Orders; OrderID = 12345; Quantity * UnitPrice * (1 – Discount) )

// Concaténation LookUp(Employees; ID = varEmployeeID; FirstName & " " & LastName & " (" & Department & ")" )`

b) Gérer Blank() proprement#

Méthode classique avec IsBlank#

If( IsBlank(LookUp(Orders; Status = "Open"; OrderID)); "Aucune commande"; "Commande trouvée" )

Méthode moderne avec coalesce (//)#

LookUp(Orders; Status = "Open"; OrderID) // "N/A"

⚠️ Piège : Le coalesce ne fonctionne que si les types correspondent. Si OrderID est un nombre et "N/A" une chaîne, erreur de type.

c) LookUp dans Patch – attention à ce piège silencieux#

Patch(Orders; LookUp(Orders; OrderID = 9999); {Status: "Closed"} )

Problème : Si OrderID 9999 n’existe pas, LookUp retourne Blank(). Patch avec un premier argument Blank() crée un nouvel enregistrement au lieu de mettre à jour.

Solution robuste#

With( {record: LookUp(Orders; OrderID = 9999)}; If( !IsBlank(record); Patch(Orders; record; {Status: "Closed"}); Notify("Commande introuvable"; NotificationType.Error) ) )

d) LookUp vs First(Filter()) – quand choisir ?#

LookUp(Products; SKU = "A123") First(Filter(Products; SKU = "A123"))

Différences subtiles :

Quand utiliser First(Filter()) :

// Besoin de trier avant de prendre le premier First( Sort( Filter(Orders; CustomerID = 1001); OrderDate; Descending ) )

LookUp seul ne permet pas de contrôler l’ordre. Si l’ordre importe, utilisez First(Sort(Filter())).

5. Relations Dataverse et navigation#

LookUp dans les relations many-to-one#

`// Navigation depuis un enregistrement vers sa relation Gallery1.Selected.Account.’Account Name’

// Équivalent avec LookUp (moins performant) LookUp(Accounts; ‘Account ID’ = Gallery1.Selected.’Account ID’; ‘Account Name’ )`

Recommandation : Sur Dataverse, privilégiez la navigation par relation native. C’est plus performant et plus lisible.

LookUp dans les choix (Choice columns)#

`// ❌ ERREUR FRÉQUENTE LookUp(Contacts; Status = "Active")

// ✅ CORRECT – Les choix sont des enums LookUp(Contacts; Status = Status.Active)`

6. LookUp imbriqués – à utiliser avec parcimonie#

// Récupérer le nom du manager du manager LookUp(Employees; ID = LookUp(Employees; ID = varCurrentEmployeeID; ManagerID ); FullName )

Problèmes :

• Performance : Deux requêtes potentiellement non délégables
• Lisibilité : Code difficile à maintenir
• Debugging : Impossible de savoir quelle étape échoue

Alternative recommandée :

// Découper en variables Set(varManagerID; LookUp(Employees; ID = varCurrentEmployeeID; ManagerID) ); Set(varManagerOfManagerName; LookUp(Employees; ID = varManagerID; FullName) );

7. Patterns de cache et optimisation#

Pattern : Cache avec expiration#

`// OnVisible de l’écran If( DateDiff(varLastRefresh; Now(); Minutes) > 5 || IsBlank(varEmployeeData); Set(varEmployeeData; LookUp(Employees; Email = User().Email) ); Set(varLastRefresh; Now()) )

// Utilisation dans l’app Label1.Text = varEmployeeData.FullName Label2.Text = varEmployeeData.Department`

Avantages :

• Une seule requête au lieu de N
• Contrôle de la fraîcheur des données
• Performance maximale

Pattern : Lazy loading conditionnel#

// Ne charge que si nécessaire If( IsBlank(varProductDetails); Set(varProductDetails; LookUp(Products; SKU = varSelectedSKU) ) )

8. Debugging et troubleshooting#

Techniques de débogage#

`// Afficher le résultat complet dans un Label Label_Debug.Text = JSON( LookUp(Orders; OrderID = 12345); JSONFormat.IncludeBinaryData )

// Vérifier si le résultat est Blank Label_Debug.Text = If( IsBlank(LookUp(Orders; OrderID = 12345)); "BLANK RESULT"; "FOUND" )

// Compter les résultats potentiels CountRows(Filter(Orders; Status = "Open"))`

Erreurs courantes et solutions#

10. Checklist des bonnes pratiques#

✅ Toujours vérifier la délégation sur les sources > 2000 lignes

✅ Utiliser LookUp uniquement pour un résultat unique attendu

✅ Mettre en cache les résultats réutilisés (Set/With)

✅ Éviter LookUp dans Text/Visible/DisplayMode sans cache

✅ Gérer explicitement Blank() avec IsBlank ou //

✅ Sécuriser les Patch avec vérification IsBlank

✅ Préférer les relations natives sur Dataverse

✅ Découper les LookUp imbriqués en variables

✅ Tester avec des volumes réalistes (pas seulement 10 lignes)

✅ Documenter les hypothèses sur l’ordre des résultats

Conclusion#

La fonction LookUp est un outil fondamental de Power Apps, mais son utilisation efficace nécessite une compréhension approfondie de :

1. La délégation et ses limites par source de données
2. Le contexte d’exécution et son impact sur les performances
3. La gestion des cas limites (Blank, types, erreurs)
4. Les patterns d’optimisation (cache, lazy loading)

Règle d’or : LookUp est votre allié pour cibler rapidement une donnée précise, mais uniquement si vous anticipez ses comportements et optimisez son contexte d’exécution. Une formule LookUp mal placée peut transformer une app fluide en cauchemar utilisateur.

Sur le papier, le choix semble simple :

• Canvas → flexibilité et design.
• Model-Driven → structure et robustesse.

En réalité, ce choix est stratégique : il impacte directement la scalabilité, la performance et la maintenabilité de votre solution. Un mauvais choix au départ peut coûter cher par la suite.

Canvas Apps : la flexibilité maximale#

Les Canvas Apps sont comparables à une feuille blanche. Le concepteur contrôle totalement l’interface et l’expérience utilisateur.

• Design sur-mesure : interface 100 % personnalisable.
• Connectivité large : plus de 700 connecteurs disponibles (SharePoint, SQL, API, Excel…).
• Ciblage mobile/tablette : parfait pour des apps tactiques sur le terrain.
• Logique intégrée avec Power Fx : langage low-code simple mais puissant.

👉 Exemple typique : une app mobile pour techniciens qui scannent des QR codes, prennent des photos et saisissent leurs rapports.

Points forts#

• Grande flexibilité UX/UI.
• Compatible avec plusieurs sources de données.
• Rapide à mettre en œuvre pour des besoins spécifiques.

Limites techniques#

• Délégation : les Canvas Apps ne peuvent traiter qu’un volume limité de données en local (500 à 2000 lignes par défaut). Au-delà, il faut configurer la délégation, et certains connecteurs ne la supportent pas.
• Performance : plus une app contient de composants, de règles ou de galeries imbriquées, plus elle devient lente.
• Maintenance : les apps créées par des citizen developers peuvent vite devenir difficiles à maintenir sans standards de gouvernance.

Model-Driven Apps : la robustesse des données#

Les Model-Driven Apps fonctionnent sur Dataverse. Ici, c’est le modèle de données qui guide la construction de l’application.

• L’interface est générée automatiquement à partir des tables, relations et formulaires.
• Les fonctionnalités standard sont incluses : recherche avancée, sécurité par rôle, vues, graphiques, intégration avec Dynamics 365.
• L’approche est idéale pour des process métiers complexes et des données fortement structurées.

👉 Exemple typique : la gestion de dossiers clients avec opportunités, contrats, documents et facturation.

Points forts#

• Structure robuste et gouvernance native via Dataverse.
• Sécurité granulaire et intégration avec Azure AD.
• Fonctionnalités prêtes à l’emploi (recherche, graphiques, formulaires).

Limites techniques#

• Licensing : Dataverse est inclus dans certaines licences premium (Power Apps per user, Dynamics 365). Pour des organisations déjà sous Microsoft 365 E3/E5, il faut prévoir un coût supplémentaire.
• Moins de liberté sur l’UI : l’interface reste standardisée Microsoft, même si elle est ergonomique.
• Complexité initiale : nécessite une bonne conception du modèle de données.

Cas client vécu : quand un mauvais choix coûte cher#

Chez un client, une application de type formulaire a été créée par un citizen developer sous forme de Canvas App.

Au départ, l’objectif était simple : permettre aux utilisateurs de saisir quelques données via un formulaire.

Mais avec le temps :

• Les données sont devenues le cœur du processus métier.
• De nouveaux composants, écrans et règles ont été ajoutés.
• L’app s’est alourdie, jusqu’à devenir trop lente et instable.

Résultat : nous avons dû refondre l’app en Model-Driven, car la logique métier et la gestion des relations entre entités auraient dû être confiées dès le départ à Dataverse.

⚠️ Morale : un choix initial mal adapté peut mener à une dette technique coûteuse et une adoption difficile.

Tableau comparatif#

Scalabilité, gouvernance et ALM#

Au-delà du choix fonctionnel, il faut considérer :

• La scalabilité : un Canvas fonctionne bien pour <10 000 enregistrements, mais au-delà, Dataverse + Model-Driven sont plus fiables selon ce que j’ai pu lire dans la littérature tech.
• La gouvernance : Model-Driven hérite des politiques de sécurité Dataverse (sécurité hiérarchique, champs masqués, etc.), quand un Canvas dépend davantage de la discipline du créateur.
• L’ALM (Application Lifecycle Management) : Model-Driven s’intègre plus facilement dans une stratégie DevOps avec solutions, pipelines et déploiements contrôlés.

Alors, comment choisir ?#

👉 Canvas si :

• L’UX est au cœur de l’app.
• Plusieurs sources de données externes sont nécessaires.
• L’application est simple ou tactique (formulaire, mobilité).

👉 Model-Driven si :

• Le processus métier repose sur un modèle de données complexe.
• Vous avez besoin de scalabilité, sécurité et intégration native.
• Votre organisation utilise déjà Dataverse ou Dynamics 365.

👉 Et souvent, le combo gagnant :

Une Model-Driven App pour la gestion robuste des données + une Canvas App pour offrir une interface ergonomique à certains profils d’utilisateurs.

Conclusion#

Canvas et Model-Driven ne s’opposent pas : ils répondent à des besoins différents. Mais le choix initial est stratégique.

Un mauvais choix peut mener à une dette technique, comme dans l’exemple de l’app devenue trop lente. À l’inverse, un choix éclairé garantit une adoption fluide, une performance durable et une solution qui évolue avec l’entreprise.

👉 Vous avez un projet Power Platform ? Discutons-en : mieux vaut prendre la bonne décision dès maintenant que de réécrire demain.

1. Qu’est-ce que le Modern Combobox ?#

Le Modern Combobox est un contrôle qui permet à l’utilisateur de :

• sélectionner une ou plusieurs valeurs parmi une liste (SelectMultiple)
• rechercher (IsSearchable) parmi les options
• afficher des champs personnalisés (ex : afficher le nom, ou un nom + sous‐titre, etc.) selon les sources de données

Ce contrôle fait partie de la famille des Modern Controls et Themes, qu’il faut activer dans les paramètres de l’app Canvas.

2. Propriétés clés & comportements importants#

Voici les propriétés qu’il faut bien connaître, et ce qu’elles impliquent :

3. Avantages du Modern Combobox#

Le Modern Combobox apporte plusieurs améliorations par rapport au combobox classique, notamment :

• Look & Feel plus moderne (UI plus soignée, styles améliorés, support des thèmes modernes).
• Support de la recherche intégrée, ce qui améliore l’expérience utilisateur quand il y a beaucoup d’options.
• Sélection multiple facilitée avec une interface plus claire.
• Meilleure compatibilité pour certaines tailles d’écran : sur petit écran, le flyout de sélection devient plein écran pour améliorer l’ergonomie.

4. Limites et pièges à connaître#

Toute innovation a ses limites. Voici les principales auxquelles faire attention :

5. Bonnes pratiques pour réussir son usage#

Voici des recommandations pour que le Modern Combobox serve vraiment bien votre app :

1. Activer les Modern Controls dès le début Si votre app est neuve, activez Modern Controls dans les paramètres → General → Modern Controls & Themes.
2. Commencer avec un prototype pour tester les scénarios réels.
3. Limiter les options affichées par défaut Par exemple, ne pas charger tous les utilisateurs de l’organisation au démarrage, mais utiliser la recherche pour filtrer.
4. Surveiller la délégation Tester avec de gros volumes de données, vérifier les avertissements, préférer des sources de données performantes.
5. Gérer les valeurs par défaut soigneusement Quand vous utilisez DefaultSelectedItems, s’assurer que ce soit un record exact.
6. UX / Accessibilité
   • S’assurer que le contrôle soit utilisable au clavier.
   • Ajouter un label accessible (AccessibleLabel).
   • Vérifier le rendu sur mobile.

6. Quand privilégier le Modern Combobox — et quand rester sur le classique#

Voici quelques scénarios concrets pour vous aider à choisir :

7. Exemple concret : liste des fournisseurs#

Chez un client, nous avions un besoin : permettre aux utilisateurs de choisir un fournisseur dans une liste d’environ 2 500 éléments stockés dans SharePoint.

• En utilisant le Modern Combobox, seuls ~800 fournisseurs apparaissaient par défaut.
• La recherche était parfois tronquée si l’expression n’était pas délégable.
• Les performances étaient médiocres sur mobile.

Solution :

• Mise en place d’un filtre initial (catégorie, région).
• Utilisation de StartsWith() pour la recherche, afin de rester délégable.
• Tests sur plusieurs appareils pour garantir une bonne expérience utilisateur.

Résultat : l’UX a été nettement améliorée, mais cela a confirmé qu’il fallait adapter le design et ne pas se reposer uniquement sur le contrôle par défaut.

8. Conclusion#

Le Modern Combobox de Power Apps est une excellente évolution : plus esthétique, plus moderne, avec des options de recherche et de sélection multiple qui améliorent l’expérience utilisateur.

Mais ce contrôle a ses limites. Il impose des choix de conception : filtrage des données, gestion de la délégation, paramétrage précis des valeurs par défaut.

👉 Mon conseil : utilisez-le pour vos applications modernes, mais testez tôt avec vos données réelles et prévoyez une stratégie de filtrage pour éviter les mauvaises surprises.

La fameuse phrase : “Mais en fait Bilel, tu fais quoi concrètement dans la vie ?”

Deux options s’offrent alors à moi :

• L’option floue : “Je développe des applications et des automatisations pour des entreprises.”
• L’option précise : “Je suis développeur/architecte sur la Power Platform.”

La seconde option m’oblige systématiquement à présenter la fameuse Power Platform. Et c’est exactement l’objectif de cet article : expliquer simplement ce qu’est la Power Platform, à quoi elle sert, et à qui elle s’adresse.

1. Qu’est-ce que la Power Platform et de quoi est-elle composée ?#

La Power Platform, c’est un ensemble d’outils développés par Microsoft pour créer rapidement des solutions numériques : applications, automatisations, sites web, rapports, chatbots… même sans savoir coder.

Elle repose sur 5 piliers principaux :

⚙️ Power Apps#

Pour créer des applications web ou mobiles, sans avoir à développer comme un dev full-stack. Parfait pour numériser un processus métier.

🔁 Power Automate#

Pour automatiser des flux de travail : envois d’emails, synchronisation de données, notifications, approbations, etc. Moins de tâches répétitives, plus de temps utile.

📊 Power BI#

Pour analyser et visualiser les données dans des dashboards interactifs. L’outil idéal pour prendre des décisions basées sur des chiffres, pas sur l’intuition.

🤖 Copilot Studio (anciennement Power Virtual Agents)#

Pour créer des agents conversationnels (chatbots). Désormais enrichi d’IA générative (via GPT), Copilot Studio permet à n’importe qui de construire un bot capable de comprendre des questions complexes et d’y répondre intelligemment.

🌐 Power Pages#

Pour créer des sites web professionnels (portails clients, formulaires sécurisés, extranets…), connectés à vos données, sans forcément maîtriser HTML/CSS. Un indispensable pour les projets orientés externes.

Et au cœur : Microsoft Dataverse#

Une base de données centralisée, sécurisée, connectée à l’ensemble des outils ci-dessus. C’est le cerveau de la Power Platform.

2. À quel besoin est-ce qu’elle répond ?#

La Power Platform a été conçue pour accélérer la transformation numérique des entreprises.

Avant :#

Créer une application ou automatiser un processus, c’était :

• Long (plusieurs mois),
• Coûteux,
• Réservé à l’IT ou à des prestataires externes.

Aujourd’hui :#

La Power Platform permet aux équipes métiers de créer leurs propres outils, sans forcément faire appel à des développeurs.

👉 Exemples concrets :

• Une DRH crée une app de demande de congés dans Power Apps.
• Un chef de projet connecte ses outils dans Power Automate pour gagner 2 h/jour.
• Un conseiller clientèle met en place un chatbot avec Copilot Studio pour filtrer les demandes.
• Un cabinet de conseil publie un portail client sécurisé avec Power Pages.
• Une PME visualise son chiffre d’affaires en temps réel dans Power BI.

C’est ce qu’on appelle le low-code : créer des solutions personnalisées, rapidement, avec peu (ou pas) de code.

3. Citizen dev vs Pro dev : qui utilise la Power Platform ?#

En école d’ingénieurs, on m’a appris qu’il fallait être développeur professionnel pour déployer une solution IT. Lors d’une expérience en cabinet de conseil, mon manager de l’époque, Paul LEGEARD (qui a fondé par la suite le cabinet Tribu Conseil), a complètement changé ma vision des choses. C’est là que j’ai découvert que la Power Platform a la particularité de s’adresser à tous les profils, techniques ou non :

👩‍💼 Citizen Developers#

Ce sont des utilisateurs métiers (RH, Finance, Logistique…) qui créent eux-mêmes des outils pour répondre à leurs besoins du quotidien.

Grâce au low-code, ils deviennent acteurs de la transformation digitale de leur entreprise.

👨‍💻 Pro Developers#

Ils vont plus loin : intégrations complexes, API, authentification, composants personnalisés…

Ils permettent d’industrialiser, sécuriser et maintenir les solutions construites avec la Power Platform.

👉 La magie opère quand les deux collaborent.

Les citizen dev lancent des idées. Les pro dev les solidifient.

C’est une nouvelle manière de travailler ensemble, plus agile, plus rapide, plus collaborative.

Conclusion#

La Power Platform, c’est bien plus qu’une suite d’outils Microsoft.

C’est une nouvelle façon de digitaliser son entreprise plus vite, avec les bons outils, entre les bonnes mains.

Alors, la prochaine fois qu’on me demande ce que je fais concrètement dans la vie, je pourrai dire :

« J’aide les entreprises à construire elles-mêmes leurs outils numériques… sans dépendre systématiquement de l’IT. »

Et vous, vous vous y mettez quand ?