Votre architecture Power Platform, qui l'a vraiment challengée ?
Une équipe qui construit vite sur Power Platform n'a presque jamais le recul pour juger sa propre architecture. Ce n'est pas une question de compétence. On ne s'auto-évalue jamais bien.
Résumer cet article avec une IA
Le lien ouvre l'assistant choisi avec une question pré-remplie pointant vers cette page.
La réponse courte
Une architecture Power Platform construite en interne est rarement challengée par quelqu'un d'extérieur.
Ce n'est pas un défaut de l'équipe. C'est structurel : celui qui construit est le plus mal placé pour voir ses propres angles morts.
Une heure de regard extérieur suffit souvent à valider un choix, ou à repérer celui qui posera problème dans six mois.
Pourquoi une équipe ne voit pas les limites de sa propre architecture
Une revue d'architecture Power Platform est un examen critique des choix techniques d'une solution : stockage des données, environnements, flux, sécurité.
En interne, ces choix ont été faits sous contrainte de délai, un par un, souvent par la même personne.
Chaque décision était raisonnable au moment où elle a été prise.
Le problème apparaît quand on les additionne et que l'usage grandit.
Je le vois à chaque fois : l'équipe connaît parfaitement sa solution, mais elle ne la compare à rien.
La grille de lecture d'une heure
Voici ce que je regarde quand on me montre une solution Power Platform pour la première fois.
SharePoint ou Dataverse : le stockage tient-il la charge ?
La question n'est pas « lequel est le meilleur ». C'est « lequel correspond à votre volumétrie et à votre criticité ».
Une liste SharePoint convient à un besoin simple et peu critique.
Dès que les données deviennent relationnelles, volumineuses ou sensibles, avec des droits fins par rôle, Dataverse devient le choix raisonnable.
J'ai détaillé cette décision dans notre guide SharePoint ou Dataverse.
Le découpage d'environnements survivra-t-il à la montée en charge ?
Beaucoup de solutions vivent dans l'environnement par défaut, sans séparation entre développement, test et production.
Ça fonctionne au début. Ça devient risqué quand une modification part directement en production, ou quand plusieurs équipes partagent le même espace.
Je regarde si le découpage actuel permet de faire évoluer la solution sans casser ce qui tourne.
Pourquoi ce flux tombe-t-il en erreur de façon récurrente ?
Un incident production Power Automate récurrent a presque toujours une cause lisible dans le code d'erreur.
Selon Microsoft Learn, les codes 400 (400, 401, 403, 404) indiquent généralement un problème de configuration, d'authentification ou de permissions, corrigible de votre côté.
Les codes 500 et 502 sont des erreurs transitoires côté service Microsoft, à revoir au niveau du service.
Cette distinction évite de passer des heures à corriger un flux qui n'est pas en cause, ou au contraire d'attendre Microsoft pour un problème de connexion expirée.
La solution proposée par l'équipe tient-elle la route ?
Souvent, l'équipe a déjà une idée de la solution. Elle veut juste savoir si c'est la bonne.
Mon rôle est de la valider ou de la remettre en question, avec des arguments. Pas de tout refaire.
Dans la majorité des cas, l'idée est bonne. Il manque un ajustement.
Le point aveugle le plus courant : vous ne savez pas quand ça casse
C'est le sujet que je retrouve le plus souvent, et il est documenté par Microsoft.
Les alertes ne vont qu'aux propriétaires du flux
D'après la documentation Microsoft sur les notifications d'échec, les alertes email par exécution ne sont envoyées qu'au propriétaire et aux co-propriétaires du flux.
Les administrateurs d'environnement ou de tenant ne les reçoivent pas.
Une période de 28 jours s'applique avant qu'un nouvel email d'alerte puisse être envoyé pour le même flux.
Concrètement : si le propriétaire est absent ou a quitté l'entreprise, personne n'est prévenu. Et une seconde panne dans le mois peut passer inaperçue.
Voir toutes les défaillances d'un environnement
Microsoft recommande aux administrateurs d'utiliser l'expérience Monitor du centre d'administration Power Platform pour voir toutes les défaillances, y compris celles qui ne déclenchent pas d'email (source).
Mesurer et alerter
Chaque flux dispose d'un tableau de bord d'analytics sur sa page de détails : taux de succès et d'échec, durée moyenne d'exécution, historique glissant sur 30 jours (source).
Pour aller plus loin, Application Insights peut être connecté aux flux cloud au niveau de l'environnement, pour créer des alertes personnalisées sur les échecs de déclencheurs, d'actions ou d'exécutions (source).
Une heure, pas un audit
Je ne vous propose pas un audit complet ici.
Je vous propose une heure de visio avec un architecte certifié, sur votre environnement réel, pas sur un schéma.
C'est le premier motif de SOS Prod : un avis d'architecture sur ce que votre équipe a construit. 190 € HT l'heure, compte-rendu écrit sous 24 h avec les actions recommandées.
Si le sujet dépasse l'heure, vous recevez un devis clair. Vous en faites ce que vous voulez.
Si vous avez besoin d'un état des lieux complet du tenant, c'est un autre exercice : notre audit et gouvernance Power Platform.
Et parfois, une heure ne sert à rien. Si c'est votre cas, je vous le dirai au cadrage gratuit de 30 minutes.
Ahmed Bouchaala - BA-IT
FAQ
Qu'est-ce qu'une revue d'architecture Power Platform ?
C'est un examen critique des choix techniques d'une solution Power Platform : stockage des données, environnements, flux, sécurité et supervision. L'objectif est de valider ce qui tient et de repérer ce qui posera problème à la montée en charge.
Pourquoi mes alertes d'échec Power Automate n'arrivent-elles pas à l'administrateur ?
Parce que les alertes email par exécution ne sont envoyées qu'au propriétaire et aux co-propriétaires du flux, selon Microsoft Learn. Les administrateurs doivent utiliser l'expérience Monitor du centre d'administration Power Platform pour voir toutes les défaillances.
Comment savoir si une erreur Power Automate vient de mon flux ou de Microsoft ?
Les codes 400, 401, 403 et 404 indiquent généralement un problème de configuration, d'authentification ou de permissions, corrigible de votre côté. Les codes 500 et 502 sont des erreurs transitoires côté service Microsoft.
Faut-il choisir SharePoint ou Dataverse pour une application Power Apps ?
SharePoint convient aux besoins simples et peu critiques. Dataverse est préférable dès que les données sont relationnelles, volumineuses ou sensibles, avec des droits fins par rôle.
Une heure suffit-elle pour challenger une architecture Power Platform ?
Une heure suffit pour valider un choix précis, diagnostiquer un incident ou trancher une décision. Pour un état des lieux complet du tenant, un audit de gouvernance est plus adapté.
Combien coûte un support urgent Power Platform chez BA-IT ?
La session SOS Prod coûte 190 € HT de l'heure, avec un cadrage gratuit de 30 minutes. Une intervention sous 4 h est majorée de 50 %.