DSI : Sécurisez et automatisez vos apps Power Platform connectées à SQL (SSO Entra ID + ALM)

Introduction

Déployer une application Power Apps connectée à SQL Server devrait être une formalité. Pourtant, dans un contexte d’ALM Power Platform avec des environnements DEV, TEST et PROD, les difficultés sont fréquentes : sources de données à reprendre, connexions à recréer, formules qui ne fonctionnent plus et flux Power Automate à tester de nouveau.

Une bonne pratique permet de fiabiliser les déploiements : combiner les variables d’environnement de Power Platform avec l’authentification Microsoft Entra ID, anciennement Azure Active Directory.

L’objectif est de disposer d’une seule solution, déployable dans plusieurs environnements, sans avoir à reconnecter manuellement la base SQL après chaque import.

À qui s’adresse cette bonne pratique ?

Cette approche concerne directement :

• les makers Power Apps qui utilisent SQL comme source de données dans des applications Canvas ;
• les équipes Power Platform et Centres d’excellence qui industrialisent les déploiements ;
• les profils ALM et DevOps qui administrent les environnements et les solutions ;
• les DSI qui souhaitent sécuriser et standardiser l’accès aux données.

Cette configuration est particulièrement adaptée lorsque vous utilisez des environnements DEV, TEST et PROD et que votre modèle SQL varie selon l’environnement, notamment grâce à des schémas distincts.

Le scénario que de nombreuses équipes ont déjà rencontré

Vous finalisez votre application Power Apps dans l’environnement DEV. Elle fonctionne, les flux Power Automate sont prêts et la solution est correctement structurée.

Vous la déployez ensuite en production, mais deux situations peuvent se présenter :

• l’application ne fonctionne plus, car elle pointe encore vers la table DEV.Clients, qui n’existe pas en production ;
• l’application fonctionne, mais continue à lire ou à modifier les données de l’environnement DEV.

Commence alors une série d’opérations manuelles : suppression de la source SQL, création d’une nouvelle connexion, correction des formules, vérification des flux, nouvelle publication et reprise des tests.

Le problème ne vient pas nécessairement de l’application. Il vient souvent du fait que la connexion SQL n’a pas été conçue pour prendre en charge le cycle de vie ALM.

Pourquoi le schéma SQL devient une variable essentielle

Dans de nombreuses entreprises, SQL Server ou Azure SQL est structuré de la manière suivante :

• monserveur / mabase / DEV / Clients ;
• monserveur / mabase / TEST / Clients ;
• monserveur / mabase / PROD / Clients.

Le serveur, la base de données et le nom de la table restent identiques. Seul le schéma SQL change selon l’environnement.

Cette organisation permet de cloisonner les données de développement, de test et de production sans multiplier les infrastructures.

Lorsque le schéma est figé dans la connexion, chaque déploiement nécessite toutefois une intervention manuelle. Il doit donc être traité comme un paramètre dépendant de l’environnement.

La solution : variables d’environnement SQL et authentification Entra ID

La bonne pratique consiste à décomposer la référence SQL et à stocker les paramètres susceptibles de varier dans des variables d’environnement Power Platform.

Les paramètres à rendre portables

• SQL_Serveur : monserveur.database.windows.net ;
• SQL_Base : mabase ;
• SQL_Schema : DEV, TEST ou PROD selon l’environnement ;
• Table : Clients, avec un nom identique dans chaque environnement.

L’accès à SQL est ensuite sécurisé avec Microsoft Entra ID et les identités Microsoft 365, plutôt qu’avec un identifiant SQL et un mot de passe stocké dans la connexion.

Mise en place pas à pas dans Power Apps et Power Automate

1. Créer les variables d’environnement

Dans votre solution Power Platform, créez les variables suivantes :

Les valeurs doivent être renseignées dans chaque environnement. Une fois cette configuration réalisée, les déploiements peuvent suivre un processus répétable.

2. Activer l’authentification Microsoft Entra ID sur SQL Server

L’utilisation de Microsoft Entra ID apporte des bénéfices en matière de sécurité et de simplicité :

• suppression des mots de passe SQL à stocker, gérer et renouveler ;
• authentification unique pour les utilisateurs ;
• meilleure traçabilité des connexions et des opérations ;
• gestion centralisée des identités et des groupes ;
• application plus simple du principe du moindre privilège.

3. Connecter Power Apps à SQL avec les paramètres définis

Lors de la configuration de la source SQL dans Power Apps, les paramètres attendus sont les suivants :

• méthode d’authentification : Microsoft Entra ID ;
• serveur : SQL_Serveur ;
• base de données : SQL_Base ;
• schéma : SQL_Schema ;
• table : Clients.

Le nom de la table reste identique. Seul le schéma dépend de l’environnement cible.

4. Déployer la solution

La solution peut ensuite être exportée depuis l’environnement DEV, puis importée dans les environnements TEST et PROD.

Lors de l’import, les valeurs configurées dans l’environnement cible permettent d’utiliser le schéma correspondant :

• TEST.Clients dans l’environnement de test ;
• PROD.Clients dans l’environnement de production.

L’objectif est d’éviter les modifications manuelles, les formules cassées et les erreurs de connexion après le déploiement.

Avant et après la mise en place des variables

Sans variables d’environnement

1. Exporter la solution.
2. Importer la solution.
3. Ouvrir l’application.
4. Supprimer la source SQL existante.
5. Créer une nouvelle connexion.
6. Réparer les formules concernées.
7. Vérifier les flux Power Automate.
8. Publier de nouveau l’application.
9. Reprendre les tests.

Selon la complexité de la solution, cette intervention peut demander entre une et trois heures et augmenter le risque d’erreur.

Avec les variables d’environnement et Microsoft Entra ID

1. Exporter la solution depuis DEV.
2. Importer la solution dans l’environnement cible.
3. Vérifier la valeur des variables, notamment SQL_Schema.
4. Publier et exécuter les tests de validation.

Dans un scénario correctement industrialisé, le déploiement peut être fortement raccourci et le risque d’erreur manuelle considérablement réduit.

Appliquer la même logique à Power Automate

La même approche peut être appliquée aux flux Power Automate.

Lorsque les flux utilisent les connexions, références et variables correctement intégrées à la solution, ils peuvent être déployés avec l’application et configurés pour l’environnement cible.

Cette organisation permet :

• d’éviter la création de flux distincts pour chaque environnement ;
• de conserver une seule solution et un même ensemble de flux ;
• de réduire les opérations de maintenance ;
• de limiter les erreurs de configuration entre DEV, TEST et PROD.

Industrialiser le cycle DEV, TEST et PROD

Utiliser les pipelines et les solutions managées

Une fois les variables d’environnement en place, l’étape suivante consiste à industrialiser le cycle de déploiement avec :

• des solutions non managées en développement et des solutions managées en production afin de mieux contrôler les modifications ;
• Power Platform Pipelines, Azure DevOps ou GitHub Actions pour automatiser les exports, les imports, les validations et les promotions ;
• une stratégie de gouvernance portée par un Centre d’excellence : conventions de nommage, règles de connecteurs, gestion des rôles et politiques DLP.

L’objectif est de rendre les déploiements reproductibles et de réduire la dépendance aux interventions manuelles, y compris lorsque les membres de l’équipe changent.

Sécuriser les identités et les accès SQL

Microsoft Entra ID simplifie l’authentification, mais plusieurs décisions doivent être formalisées :

• quelle identité se connecte : utilisateur, groupe ou compte de service ;
• quels droits SQL sont nécessaires : lecture, écriture, tables, vues ou procédures ;
• comment les accès sont attribués, contrôlés et révoqués ;
• comment les opérations sont journalisées et auditées.

Le principe du moindre privilège doit être appliqué afin d’éviter d’accorder des droits d’administration trop étendus.

Stabiliser l’interface entre Power Apps et SQL

Lorsque Power Apps interroge directement SQL, il est recommandé de stabiliser l’interface de données :

• privilégier les vues ou les procédures stockées comme couche d’abstraction ;
• limiter le couplage entre Power Apps et la structure interne de la base SQL ;
• documenter un contrat de données précisant les noms, les types et les champs obligatoires ;
• conserver une structure cohérente dans les différents schémas.

Cette organisation réduit les risques de régression lorsque la structure SQL évolue.

Checklist de déploiement Power Apps, SQL et Power Automate

Avant le premier déploiement

• Les environnements DEV, TEST et PROD sont créés et correctement gouvernés.
• Les rôles et les politiques DLP sont définis.
• La solution contient les applications, les flux, les références de connexion et les autres composants nécessaires.
• Les variables SQL_Serveur, SQL_Base et SQL_Schema sont créées.
• Les valeurs sont renseignées dans chaque environnement.
• Les paramètres complémentaires nécessaires, comme le port ou le délai d’expiration, sont documentés.

Côté SQL et sécurité

• L’authentification Microsoft Entra ID est activée sur SQL.
• Les groupes ou comptes nécessaires sont créés pour les makers, les utilisateurs et les comptes de service.
• Les droits SQL respectent le principe du moindre privilège.
• L’accès est limité aux tables, vues et procédures réellement nécessaires.
• La journalisation et l’audit des opérations sont vérifiés.

Côté Power Apps

• La configuration SQL repose sur les paramètres définis pour l’environnement.
• Le nom de la table, par exemple Clients, est identique dans tous les schémas.
• Aucune valeur propre à DEV n’est écrite en dur dans les formules.
• Les opérations de lecture et d’écriture ont été testées.
• Les erreurs, les volumes importants et les cas limites ont été vérifiés.

Côté Power Automate

• Les flux utilisent les composants et références de connexion intégrés à la solution.
• Les flux ne sont pas dupliqués inutilement pour chaque environnement.
• Les propriétaires et les connexions des flux sont vérifiés.
• Les flux ne dépendent pas uniquement du compte personnel d’un maker.
• Une gestion minimale des erreurs, des alertes ou des journaux est mise en place.

Import et validation

• La solution est exportée depuis DEV avec une version clairement identifiée.
• Après l’import en TEST, les valeurs des variables sont contrôlées.
• Les parcours métiers, les permissions et les performances sont testés dans TEST.
• Après l’import en PROD, les variables, les connexions et la publication sont vérifiées.
• Un test rapide de production contrôle l’accès, la création, la modification, les flux et les journaux.

À retenir

• Dans un cycle ALM Power Platform, une connexion SQL configurée en dur peut générer des difficultés lors du passage de DEV à TEST et PROD.
• Les variables d’environnement permettent de centraliser les paramètres qui changent selon l’environnement.
• Microsoft Entra ID améliore la sécurité, la traçabilité et la gouvernance des accès.
• Une solution correctement structurée réduit le temps consacré aux déploiements et aux corrections manuelles.
• Cette architecture peut également être utilisée avec Azure SQL.

Pour aller plus loin

• Découvrez Microsoft Power Platform
• Du buzz aux usages : Microsoft 365 Copilot et les agents IA, top ou flop ?
• Contacter Kwanzeo pour échanger sur votre projet Power Platform