Power Query affiche Formula.Firewall : faut-il changer la confidentialité ou reconstruire la combinaison ?

Formula.Firewall ne signifie pas automatiquement que vos niveaux de confidentialité sont « mal réglés ». L’erreur peut signaler deux problèmes différents : des sources dont les niveaux ne permettent pas la combinaison, ou une requête qui mélange accès direct à une source et référence à une autre requête selon un schéma que votre environnement bloque.

Ne choisissez pas “Ignorer les niveaux de confidentialité” comme premier correctif. Relevez le message exact, cartographiez les sources et les valeurs qui passent de l’une à l’autre, puis décidez entre quatre voies : corriger une classification réellement erronée, restructurer les requêtes, aligner l’environnement ou faire valider un flux de données intentionnel.

Cet article s’adresse au responsable de reporting ou à l’utilisateur Excel/Power BI qui combine plusieurs sources et doit préparer une décision sûre avant de modifier le fichier ou de demander une formation. Il ne remplace ni la politique de sécurité de l’organisation ni l’avis du propriétaire des données.

Pourquoi Power Query bloque-t-il une combinaison ?

Le pare-feu de confidentialité de Power Query cherche à empêcher qu’une donnée provenant d’une source soit envoyée involontairement vers une autre. Ce risque peut être discret : lorsque Power Query replie des transformations vers une source, une valeur utilisée comme filtre, chemin ou paramètre peut partir vers cette source pendant l’évaluation. Microsoft Learn — Data Privacy Firewall

Microsoft distingue notamment les niveaux suivants :

• Private : données sensibles ou confidentielles, isolées des autres sources ;
• Organizational : données accessibles à un groupe de confiance, combinables avec d’autres sources organisationnelles selon les règles du produit ;
• Public : données pouvant être visibles par tous ;
• None : absence de protection Power Query, à réserver à un cadre contrôlé où la conformité est assurée autrement.

Le niveau doit décrire la sensibilité et le périmètre de confiance réels, pas simplement le réglage qui fait disparaître l’erreur. Microsoft Learn — niveaux de confidentialité

Commencez par le message exact, pas par une recette trouvée en ligne

Deux familles d’erreur peuvent se ressembler à l’écran mais n’appellent pas le même diagnostic.

1. Niveaux incompatibles

Le message indique que la requête accède à des sources dont les niveaux de confidentialité ne peuvent pas être utilisés ensemble. Il faut alors identifier chaque source, son niveau, le propriétaire de sa classification et la donnée susceptible de franchir la frontière.

La bonne question n’est pas « quel niveau débloque la requête ? », mais « quelle circulation de données est autorisée, et par qui ? ». Une source interne ne devient pas publique parce qu’elle contient seulement trois colonnes. Deux sources privées ne deviennent pas automatiquement combinables non plus : le niveau privé vise précisément l’isolement.

2. Référence à une requête et accès direct à une source

Le message indique qu’une requête « references other queries or steps » tout en accédant directement à une source. Historiquement, cette structure était bloquée dans certains environnements même lorsque les niveaux étaient compatibles. Les comportements ont depuis divergé selon les produits et versions.

Dans Power BI Desktop, Microsoft a introduit en juillet 2026 un réglage permettant cette structure lorsque les niveaux sont compatibles ; il est activé par défaut à partir de cette version et rapproche Desktop du service Power BI, des passerelles et de Power Query Online. Ce changement ne désactive pas le pare-feu : les niveaux restent évalués. Microsoft Learn — réglage Power BI Desktop de juillet 2026

Si le fichier fonctionne dans un environnement et échoue dans un autre, relevez donc le produit, la version, le mode d’actualisation et la passerelle avant de réécrire la logique.

La carte SOURCE–NIVEAU–PASSAGE–PREUVE

Travaillez sur une copie, avec des données fictives, désensibilisées ou expressément autorisées. Remplissez une ligne par source réelle — pas seulement par requête affichée :

La colonne « valeur qui peut sortir » est centrale. Une combinaison ne se limite pas à la table finale : un filtre, une clé, un chemin de fichier ou un fragment d’URL peut déjà transporter une information vers une autre source.

Un diagnostic en six décisions

1. Capturer le contexte reproductible

Notez le texte complet de l’erreur, le nom de la requête et de l’étape, le produit, la version et l’endroit où l’actualisation s’exécute : Excel Windows, Power BI Desktop, service, Power Query Online ou passerelle. Ajoutez les sources visibles dans Paramètres des sources de données et leurs niveaux actuels.

Ne copiez pas de secrets, identifiants ou données réelles dans un forum ou une demande de devis. Une description de structure et un exemple factice suffisent souvent à qualifier le besoin.

2. Dessiner le flux, y compris les petits paramètres

Représentez chaque accès à une source et chaque référence entre requêtes. Cherchez en particulier :

• une valeur extraite d’une requête puis utilisée dans une URL, un chemin ou une instruction SQL ;
• une fusion entre source interne et source publique ;
• une requête de préparation réutilisée par plusieurs requêtes ;
• une fonction personnalisée qui ouvre un fichier ou appelle une API pour chaque ligne ;
• un paramètre dont l’origine n’est plus visible dans la requête finale.

Cette carte permet de distinguer une combinaison locale de résultats déjà chargés d’un envoi potentiel de valeurs vers une source distante.

3. Vérifier les classifications avec les bons responsables

Si un niveau paraît incohérent, ne le changez pas seul pour tester sur le fichier de production. Faites confirmer la sensibilité par le propriétaire de la donnée ou la personne chargée de la gouvernance. Un fichier téléchargé sur le web n’est pas forcément public ; une URL accessible après authentification n’est pas une preuve de libre diffusion.

Microsoft avertit que l’option Fast Combine — ignorer les niveaux de confidentialité — peut exposer des données sensibles ou confidentielles à une personne non autorisée. Elle ne doit pas être activée sans certitude sur les données et sans politique qui l’autorise. Support Microsoft — définir les niveaux de confidentialité

4. Réduire le cas sans réduire la protection

Créez un exemple minimal avec les mêmes types de sources et la même architecture, mais des valeurs factices. Vérifiez séparément :

1. chaque accès à une source ;
2. chaque requête de préparation ;
3. la combinaison finale ;
4. le passage éventuel d’une valeur vers une autre source.

Si l’erreur apparaît avant la combinaison finale, vous avez probablement localisé la frontière utile. Si elle disparaît seulement quand une source réelle est remplacée, comparez connexion, classification et comportement du connecteur ; ne concluez pas que la donnée réelle est « fautive ».

5. Choisir le correctif qui correspond à la cause

Microsoft cite la requête intermédiaire et la séparation entre accès aux sources et combinaison comme pistes lorsque la structure doit être modifiée. Le choix exact dépend toutefois du produit, des connecteurs et de la politique de l’organisation.

6. Revalider le résultat et le lieu d’exécution

Après correction, contrôlez au minimum les lignes, les périodes, les totaux, les doublons et les erreurs. Puis testez à l’endroit où le flux doit réellement s’actualiser. Un fichier qui fonctionne dans Power BI Desktop n’est pas encore une preuve qu’il fonctionnera avec la passerelle, les identités et les réglages du service.

Documentez enfin : sources, niveaux validés, valeur transmise, architecture retenue, environnement testé et responsable de la décision. Cette preuve aidera autant la maintenance que la formation.

Cas fictif : liste clients interne et taux de change public

Une analyste possède une table privée contenant client, devise et montant. Elle veut récupérer des taux publics. Une première requête utilise la devise de chaque ligne pour construire des appels web. Le résultat attendu paraît banal, mais des valeurs issues de la source privée sont envoyées vers le service externe : le pare-feu peut bloquer ce passage.

Une architecture plus sûre à examiner consiste à récupérer indépendamment une table publique de taux autorisés, puis à la joindre localement à la table interne. Cela limite les données envoyées au service public. Mais ce scénario est fictif : fréquence d’appel, licence de la source, clés nécessaires et règles de l’organisation doivent encore être vérifiées.

Exercice corrigé

Classez les trois situations suivantes.

1. Deux bases de l’organisation sont confirmées Organizational et la combinaison échoue seulement sur un ancien Power BI Desktop.
2. Un matricule issu d’un fichier RH Private est injecté dans l’URL d’un service public.
3. Une source a été marquée Public par l’auteur, mais son propriétaire et sa sensibilité sont inconnus.

Correction :

1. Vérifier la version et le réglage introduit en juillet 2026, puis tester l’environnement cible ; ne pas restructurer d’abord par automatisme.
2. Stopper et faire qualifier le flux : la valeur privée risque de sortir vers la source publique. Ignorer les niveaux ne résout pas le problème de gouvernance.
3. Traiter la classification comme non validée. Identifier le propriétaire et la politique avant de choisir un niveau ou une architecture.

Quelle suite de formation demander ?

La formation Excel avec Power Query de StraFormation présente un parcours Fondations de 14 heures et un parcours Avancé de 21 heures. Les fondations conviennent si vous devez encore structurer acquisition, transformations, combinaisons, chargement et contrôles. Le parcours avancé devient une piste lorsque vous devez maintenir plusieurs sources, comprendre les dépendances, examiner le query folding, les erreurs et la performance.

La page publique ne suffit pas à confirmer que votre version, vos connecteurs ou votre politique de confidentialité seront reproduits en formation. Avant le devis, transmettez sans donnée sensible :

• le message Formula.Firewall exact et l’étape concernée ;
• Excel ou Power BI, la version et le lieu d’actualisation ;
• le type de chaque source et son propriétaire ;
• les niveaux configurés, s’ils sont connus et validés ;
• la valeur susceptible de passer d’une source à l’autre ;
• un schéma ou un exemple factice reproductible ;
• le résultat attendu, les contrôles et l’échéance ;
• le nombre de participants et le rôle de la personne qui validera l’architecture.

La meilleure demande n’est donc pas « apprenez-nous à enlever Formula.Firewall ». C’est : aidez-nous à expliquer le flux, préserver la confidentialité et choisir une architecture reproductible dans notre environnement.

Sources vérifiées

• Microsoft Learn — Behind the scenes of the Data Privacy Firewall, mise à jour du 8 novembre 2025.
• Microsoft Learn — Privacy levels in Power Query, mise à jour du 26 juin 2024.
• Microsoft Learn — réglage des partitions du pare-feu dans Power BI Desktop, mise à jour du 2 juillet 2026.
• Support Microsoft — Set privacy levels (Power Query), consulté le 27 septembre 2026.
• Microsoft Learn — Security best practices for Power Query, mise à jour du 30 septembre 2025.
• StraFormation — Formation Excel avec Power Query, consultée le 27 septembre 2026.