Comment configurer un proxy dans Power BI Desktop

Comment configurer un proxy dans Power BI

Si vous cherchez comment configurer un proxy dans Power BI, partez d’un fait simple : ce guide concerne Power BI Desktop sous Windows, pas tous les produits Microsoft avec un écran de connexion. C’est important, car Power BI Desktop suit généralement les règles réseau définies par Windows, et vous ne trouverez parfois aucun bouton « proxy » clair dans l’application elle-même. Une mauvaise hypothèse peut vous faire perdre un après-midi.

Suivez cette approche si Power BI Desktop ne parvient pas à se connecter, n’atteint pas le service Power BI ou échoue lors de l’actualisation. Si le problème ne concerne qu’une seule source de rapport, la correction se trouve peut-être ailleurs. Si l’erreur apparaît avant le chargement du premier jeu de données, le proxy est un suspect plus probable.

1. Vérifiez quelle application Power BI vous utilisez

Commencez par confirmer que vous êtes bien dans Power BI Desktop pour Windows. L’application de bureau, le service Power BI dans un navigateur et la passerelle locale ne se comportent pas de la même manière, et ils ne partagent pas un seul réglage de proxy. Si vous êtes dans le navigateur, ce sont les paramètres proxy du navigateur qu’il faut examiner.

Ce guide ne couvre pas les applications mobiles Power BI ni la configuration proxy Windows générique pour toute la machine. Il ne couvre pas non plus une stratégie réseau Microsoft 365 à l’échelle du tenant. Le cas précis ici est simple : proxy Power BI Desktop Windows doit accéder à un proxy pour la connexion, l’actualisation ou l’accès au service.

Ce cadre étroit fait gagner du temps. Beaucoup de temps.

Avant de modifier quoi que ce soit, ouvrez Power BI Desktop et notez le moment exact de l’échec. Si l’erreur apparaît à la connexion, c’est une piste. Si elle apparaît lors de l’actualisation, c’en est une autre. Si une passerelle est impliquée, c’est une troisième piste, et la solution n’est peut-être pas sur votre ordinateur portable.

2. Identifiez les détails exacts du proxy exigés par votre réseau

Il vous faut plus que « nous utilisons un proxy ». Il vous faut le nom d’hôte, le port, la méthode d’authentification et savoir si l’entreprise utilise un fichier PAC ou une configuration manuelle du proxy. Sans ces informations, vous avancez à l’aveugle.

Demandez le proxy host dans le format attendu par votre équipe réseau, par exemple un nom DNS ou une adresse IP. Demandez aussi le numéro de port. Si une authentification est requise, vérifiez s’il s’agit d’identifiants simples, d’une connexion de domaine, de NTLM, de Kerberos ou d’autre chose. Ce seul détail change toute la configuration.

Certaines organisations publient un fichier PAC et attendent de Windows qu’il détecte automatiquement le proxy. D’autres veulent un serveur proxy fixe saisi manuellement. Si vous ne savez pas lequel vous avez, vérifiez avec l’IT avant de commencer. Une configuration manuelle sur un réseau en PAC seul échoue souvent d’une manière qui ressemble à un problème Power BI.

Pour clarifier rapidement la terminologie, la page VPN और प्रॉक्सी शब्दावल? peut aider à distinguer le vocabulaire des proxys de celui des VPN. Les deux sont souvent confondus dans les tickets internes, ce qui crée une confusion évitable.

Gardez aussi une information de plus sur papier : savoir si le proxy change selon l’emplacement réseau. Un ordinateur portable à la maison, en Wi‑Fi ou sur le réseau de l’entreprise peut voir des règles proxy différentes. Cette différence compte quand un rapport fonctionne le lundi et échoue le mardi.

3. Vérifiez à quoi Power BI essaie réellement d’accéder sur Internet

Power BI Desktop ne fait pas une seule requête Internet. Il en fait plusieurs. La connexion Microsoft est un chemin, l’accès au service Power BI en est un autre, la communication avec la passerelle en est un troisième, et chaque source de données peut en ajouter d’autres. Un proxy peut bloquer un chemin et laisser les autres intacts.

Commencez par la connexion. Si Power BI Desktop ne peut pas authentifier votre compte Microsoft ou votre compte d’organisation, le proxy bloque peut-être les points de terminaison Microsoft. Testez ensuite l’accès au service Power BI lui-même. Puis regardez votre source de données : SQL Server, SharePoint, API web ou fichiers stockés derrière un réseau d’entreprise.

La communication avec la passerelle mérite un contrôle à part. Une passerelle personnelle ou d’entreprise peut nécessiter un accès réseau distinct, surtout si elle s’exécute sur une autre machine. Si l’application de bureau fonctionne mais que l’actualisation planifiée échoue plus tard, le proxy n’est peut-être qu’un élément parmi d’autres.

Une question utile est la suivante : quelle connexion échoue en premier ? L’échec initial pointe généralement vers la couche pertinente. C’est plus efficace que de fixer le message d’erreur final en espérant qu’il raconte toute l’histoire. En général, ce n’est pas le cas.

Pour la planification réseau autour des points de terminaison et des ports du proxy, consultez les numéros de port proxy pour le web scraping. Le contexte est différent, mais le principe de base reste le même : le numéro de port compte autant que le nom d’hôte.

4. Configurez le proxy au niveau de Windows pour Power BI Desktop

La configuration la plus courante consiste à définir le proxy dans Windows afin que Power BI Desktop l’hérite. Power BI Desktop n’offre généralement pas de panneau de configuration proxy séparé pour l’utilisation normale sur ordinateur de bureau. Autrement dit, ce sont souvent les paramètres réseau Windows qui déterminent le résultat.

Ouvrez les paramètres proxy de Windows et vérifiez si votre entreprise utilise une configuration automatique ou manuelle. Si vous avez un fichier PAC, saisissez l’emplacement du script fourni par votre équipe IT. Si vous avez un proxy manuel, indiquez le serveur et le port exactement comme ils vous ont été fournis. Une seule erreur dans le port peut tout bloquer.

Ne devinez pas les règles de contournement. Si votre équipe réseau vous indique que les adresses locales ou certains domaines Microsoft doivent contourner le proxy, saisissez ces exceptions exactement. Un proxy qui intercepte le trafic interne peut casser le trafic de la passerelle ou l’accès à une source de données locale. C’est une panne fréquente, et elle semble aléatoire jusqu’à ce que vous compariez la liste des exceptions.

Si votre environnement repose sur un plan de sécurité plus large, l’article sur le choix d’un VPN n’est pertinent qu’à titre de comparaison. Les VPN et les proxys ne sont pas la même chose, et un VPN ne remplace pas une règle proxy pour Power BI Desktop.

Redémarrez Power BI Desktop après avoir modifié les paramètres proxy de Windows. Puis, si la politique IT l’exige, redémarrez aussi Windows. Certaines modifications du proxy ne s’appliquent pas complètement tant que la pile réseau n’a pas rechargé sa configuration. Cette petite étape évite beaucoup de faux tests.

5. Gérez l’authentification proxy et les invites d’identifiants

Si le proxy exige un nom d’utilisateur et un mot de passe, Power BI Desktop peut vous les demander lors de la connexion, de l’actualisation ou de la première connexion à une source de données. L’invite peut venir de Windows, d’un flux de connexion Microsoft via le navigateur ou de la source de données elle-même. L’écran se ressemble. La cause n’est pas toujours la même.

Si votre organisation utilise l’authentification intégrée, le proxy peut accepter les identifiants de votre session Windows. Dans ce cas, le compte utilisé pour vous connecter à Windows compte.

Surveillez les demandes répétées. Une demande est normale dans certaines configurations. Des invites répétées indiquent généralement l’un de ces trois problèmes : les identifiants sont incorrects, le proxy n’accepte pas la méthode d’authentification, ou Power BI Desktop atteint un autre point de terminaison qui nécessite une autre règle. C’est fastidieux, mais utile.

Si vous avez besoin d’un modèle plus approfondi du comportement d’un proxy authentifié, le guide des bonnes pratiques d’authentification proxy fournit le bon contexte. Il aide quand votre entreprise mélange connexion navigateur, connexion Windows et identifiants proxy dans le même flux.

Une habitude pratique ici : n’enregistrez pas de mauvais identifiants en continuant à réessayer. Après trois échecs, arrêtez-vous et confirmez la méthode proxy avec l’IT. Un compte verrouillé n’aide personne, et il peut faire paraître le problème proxy plus grave qu’il ne l’est.

6. Vérifiez que Power BI peut se connecter et charger les données via le proxy

Testez la configuration en trois étapes. D’abord, ouvrez Power BI Desktop et connectez-vous. Ensuite, connectez-vous à une source simple que vous connaissez bien. Enfin, actualisez un petit jeu de données ou une requête d’exemple. Gardez le test simple pour pouvoir déterminer à quelle étape l’échec se produit.

Le succès de la connexion ne suffit pas. Power BI peut se connecter mais échouer lorsqu’il atteint une source web ou la connexion au service. Un tableau de bord peut sembler sain alors que l’actualisation est cassée en arrière-plan. C’est pourquoi un vrai test de données est indispensable.

Si vous utilisez des sources web ou des récupérations automatisées dans d’autres outils, l’article sur la rotation de proxy pour le web scraping explique pourquoi des requêtes répétées peuvent provoquer des comportements différents. Power BI ne fait évidemment pas du scraping, mais des appels répétés à une source peuvent tout de même déclencher des règles proxy, des limites d’authentification ou des filtres de point de terminaison.

Vérifiez le texte exact de l’erreur. Un avertissement de certificat n’est pas la même chose qu’un échec d’authentification. Un délai d’attente n’est pas la même chose qu’une connexion refusée. Si vous pouvez capturer le message et l’horodatage, l’IT pourra les comparer aux journaux du proxy. Sans ces détails, vous leur faites deviner aussi.

Si la connexion fonctionne sur un réseau et échoue sur un autre, notez la différence. Le Wi‑Fi du bureau, le Wi‑Fi à domicile et les sessions passées par VPN se comportent souvent différemment. Trois tests valent mieux qu’un seul.

7. Résolvez les points de défaillance proxy courants dans Power BI

Le blocage des points de terminaison Microsoft est un problème fréquent. Power BI Desktop peut avoir besoin d’accéder à plusieurs services Microsoft, et un proxy ou un pare-feu strict peut en bloquer un seul. Si la connexion échoue mais que la navigation web fonctionne encore, ne partez pas du principe que le proxy est bon. La navigation et Power BI ne sont pas identiques.

L’inspection des certificats peut aussi poser problème. Certains outils de sécurité inspectent le trafic HTTPS et insèrent leurs propres certificats. Si Power BI Desktop ou un composant Microsoft associé ne fait pas confiance à cette chaîne de certificats, la connexion peut échouer. Cela se manifeste généralement par une erreur de connexion sécurisée plutôt que par un message proxy clair.

Les problèmes de passerelle méritent un examen séparé. Si la machine de passerelle se trouve dans un autre sous-réseau, un autre bureau ou un autre segment cloud, elle peut nécessiter son propre proxy ou sa propre règle de pare-feu. Une modification du proxy sur votre portable ne corrigera pas une passerelle qui ne peut pas accéder à Internet depuis son propre réseau. C’est simple, mais facile à manquer.

Les échecs d’actualisation après une modification du proxy proviennent souvent d’identifiants enregistrés ou d’un ancien chemin de connexion. Essayez de supprimer les identifiants de la source de données concernée dans Power BI Desktop, puis saisissez-les à nouveau. Testez ensuite de nouveau. Un seul identifiant obsolète peut continuer à échouer longtemps après que le proxy lui-même est correctement configuré.

Si vous souhaitez une comparaison plus large des méthodes de masquage réseau, l’article sur comment masquer votre adresse IP peut vous aider à expliquer la différence entre un proxy, un VPN et une connexion directe à votre équipe réseau. La conversation se passe généralement mieux quand tout le monde emploie les mêmes mots.

8. Sachez quand impliquer votre équipe IT ou réseau

Faites intervenir l’IT lorsque la politique proxy échappe à votre contrôle. Si l’entreprise utilise un fichier PAC, des listes d’autorisation de pare-feu, une inspection des certificats ou une authentification centralisée, vous n’êtes probablement pas autorisé à corriger cela seul. Ce n’est pas une limite de Power BI. C’est un problème de politique réseau.

Contactez-les avec quatre éléments : la version exacte de Power BI Desktop, le message d’erreur exact, le proxy ou fichier PAC utilisé, et l’heure de l’échec. Quatre éléments suffisent pour lancer une vraie vérification. « Ça ne marche pas » ne suffit pas.

Si l’équipe proxy vous demande le protocole source, indiquez si l’échec s’est produit à la connexion, à l’accès au service, à la communication avec la passerelle ou sur une source de données précise. Plus vous serez précis, moins vous recevrez d’allers-retours par e-mail. Petit détail, gros gain.

Il existe aussi des cas où le problème n’a rien à voir avec Power BI. Une stratégie de domaine peut bloquer le flux de connexion Microsoft. Une règle de pare-feu peut bloquer le port 443 vers un point de terminaison spécifique. Une politique de certificats peut rejeter l’inspection. Tous ces éléments relèvent de l’équipe réseau, pas d’un utilisateur de bureau qui doit deviner.

Pour les entreprises qui gèrent de nombreux outils connectés, l’article sur le coût des proxys authentifiés peut aider à cadrer les discussions budgétaires lorsque l’équipe décide si une nouvelle couche de proxy vaut la surcharge opérationnelle. Les discussions budgétaires sont rarement agréables, mais elles valent mieux que des pannes mystérieuses.

Zone de problème À vérifier Qui le corrige généralement
Échec de connexion Points de terminaison Microsoft, authentification proxy, identifiants Windows IT ou équipe réseau
Échec de l’actualisation Chemin de la source de données, identifiants enregistrés, règles d’exclusion du proxy Responsable Power BI avec l’aide de l’IT
Passerelle hors ligne Accès à la machine de passerelle, pare-feu, règles proxy locales Administrateur de passerelle ou équipe réseau
Erreur de certificat Outils d’inspection, chaîne de confiance, politique de certificats d’entreprise Équipe sécurité ou réseau

Si votre organisation veut un ensemble de définitions plus clair pour les tickets internes, gardez l’article SOCKS5 proxy vs HTTP proxy à portée de main. Le vocabulaire est simple, et un vocabulaire simple réduit les mauvais tickets. Les mauvais tickets ralentissent chaque modification de proxy.

Dernier point pratique : gardez une note de la configuration qui fonctionne une fois que tout est opérationnel. Enregistrez le mode proxy Windows, l’emplacement du fichier PAC ou le nom d’hôte du proxy manuel, le port et la date de la modification. Le mois suivant, si quelque chose change encore, vous n’aurez pas besoin de repartir de zéro.