Vous tentez de rafraîchir vos requêtes Power Query, mais Excel ou Power BI Desktop renvoie systématiquement l’erreur :
[DataFormat.Error] We received a malformed web response. Cette anomalie apparaît quel que soit le classeur ou le fichier PBIX ouvert, alors qu’un collègue parvient à relancer les mêmes connexions sans encombre. Le problème provient donc presque toujours de vos paramètres locaux d’authentification plutôt que des données stockées sur SharePoint, OneDrive ou Teams.
Vue d’ensemble de la question
Power Query, qu’il soit exécuté dans Excel ou Power BI Desktop, s’appuie sur un moteur M qui télécharge les fichiers cibles via HTTP(S). Lorsque le flux binaire attendu (CSV, XLSX, JSON, etc.) est altéré, compressé ou tronqué, le moteur déclenche une exception « malformed web response ». Dans la plupart des cas observés, la réponse est en réalité une page HTML de connexion ou un message d’erreur renvoyé par le proxy, le serveur SharePoint ou Azure Front Door. Dans la session qui fonctionne chez votre collègue, le même appel HTTP reçoit le fichier correctement formaté. La conclusion la plus probable : un cache d’identifiants corrompu ou expiré sur votre poste redirige la requête vers un portail d’authentification, et Power Query ne comprend pas la réponse.
Symptômes détaillés
- L’erreur se manifeste sur toutes les requêtes d’un classeur ou d’un rapport PBIX.
- Elle apparaît immédiatement à la première connexion réseau ; le volet Requête n’affiche pas d’étapes intermédiaires.
- Dans le Diagnostic de requêtes ou le Trace Viewer de Power BI, on trouve un status code 200 ou 302, mais la Content-Type annonce
text/htmlau lieu deapplication/octet-stream. - La capture Fiddler montre souvent une redirection 302 vers
login.microsoftonline.comou une page HTML « X‑Firewall authentication required » générée par un proxy d’entreprise.
Analyse des causes possibles
Plusieurs éléments peuvent provoquer la substitution du contenu attendu :
- Jeton OAuth expiré : après 90 jours sans renouvellement, le rafraîchissement silencieux échoue et le serveur renvoie un formulaire HTML de réauthentification.
- Proxy ou inspection SSL : certains agents interceptent la connexion, injectent un cookie ou réécrivent l’entête Accept-Encoding, produisant un flux que Power Query ne peut pas décoder.
- Changement d’URL de la ressource : si l’administrateur déplace un fichier dans une collection de sites SharePoint, une réponse 301 ou 302 non suivie correctement peut aboutir à une page générique.
- Mise à jour incrémentielle mal configurée : un paramètre Range ou une requête HTTP conditionnelle renvoie parfois une réponse partielle (206) sans en‑tête Content‑Range complet.
Solution pas-à-pas : Réinitialiser les autorisations Power Query
La procédure suivante résout plus de 90 % des cas signalés :
- Dans Excel ou Power BI Desktop, ouvrez Données ▶ Paramètres des sources de données.
- Basculez sur l’onglet Autorisations globales.
- Sélectionnez chaque ligne associée à vos sites SharePoint, OneDrive ou Teams (vous pouvez trier par colonne Chemin). Cliquez sur Supprimer.
- Fermez la boîte de dialogue, enregistrez votre classeur ou PBIX, puis relancez entièrement l’application ; cette étape purge le cache en mémoire.
- Au prochain Actualiser, Power Query vous redemandera le type d’authentification (Organizational Account). Saisissez vos identifiants ou laissez s’ouvrir la fenêtre Azure AD.
- Une fois le jeton renouvelé, le flux téléchargé sera à nouveau conforme et l’erreur disparaîtra.
Pourquoi cela résout l’erreur
Lorsqu’un jeton OAuth a expiré, SharePoint renvoie une page HTML de login. Power Query ne sait pas analyser ce texte simple ; il s’attend à un flux JSON ou binaire. L’exception DataFormat.Error est le symptôme direct de ce décalage. En effaçant les autorisations globales, on force le client à relancer la danse OAuth 2.0 (authorization code grant + access token). Le serveur fournit alors un Bearer valide, et la réponse HTTP redevient le fichier demandé.
Bonnes pratiques complémentaires
| Étape | Objectif | Détails rapides |
|---|---|---|
| Tester sur un autre réseau ou hotspot | Écarter un proxy/pare‑feu local qui altère la réponse | Si l’erreur disparaît, vérifier la configuration du proxy ou de l’agent de sécurité (SSL inspection). |
| Mettre à jour Office / Power BI | Corriger d’éventuels bugs d’analyse HTTP | Utiliser la dernière build mensuelle ou LTSC ; plusieurs correctifs ciblent l’agent M en 2024‑2025. |
| Vérifier l’URL source dans Power Query | Éviter les redirections non gérées | Coller l’URL dans un navigateur ; si un avertissement ou une page HTML s’affiche, ajuster le lien. |
| Examiner les journaux Fiddler / Network Trace | Confirmer la nature exacte de la réponse « malformée » | Chercher des codes 30x, du contenu HTML ou un encodage GZip incomplet. |
Dépannage avancé
1 – Décoder la réponse reçue
Dans Fiddler ou Telerik JustTrace, exportez la réponse incriminée ; ouvrez‑la dans un éditeur. Une bannière <title>Sign In</title> ou un formulaire HTML confirme une redirection d’authentification. S’il s’agit d’un HTTP/1.1 302, vérifiez l’entête Location : il pointe souvent vers https://login.microsoftonline.com/….
2 – Réinitialiser le Microsoft Edge WebView2
Depuis fin 2024, Power Query utilise par défaut WebView2 pour exécuter certaines requêtes. Un cache corrompu peut également provoquer l’erreur. Supprimez le dossier :%LOCALAPPDATA%\Microsoft\EdgeWebView,
puis relancez Excel / Power BI.
3 – Tester en mode préversion du moteur M
Dans Options ▶ Aperçu des fonctionnalités, activez « VNext Query Execution ». Ce moteur affiche des logs plus détaillés ; si l’exception est levée lors du parse GZip, vous verrez la pile complète et la taille des octets attendus vs reçus.
4 – Rafraîchissement par lot avec PowerShell
Pour isoler le problème serveur/cliente, rafraîchissez la requête avec le module MicrosoftPowerBIMgmt :
Invoke-PowerBIRestMethod `
-Url "groups/{workspaceId}/datasets/{datasetId}/refreshes"
Si le service en ligne ne renvoie aucune erreur, mais que Power BI Desktop échoue, la cause est presque exclusivement locale.
FAQ
Le fichier se télécharge dans le navigateur ; pourquoi Power Query échoue-t-il ?
Le navigateur sait suivre les redirections Azure AD et injecte votre cookie. Power Query exécute un flux API direct sans UI ; dès que la réponse n’est pas du type déclaré (Content-Type inattendu), le moteur arrête la lecture et lève DataFormat.Error.
Peut-on automatiser la purge des autorisations ?
Oui. Supprimez le fichier CredentialStore.dat dans %LOCALAPPDATA%\Microsoft\Office\16.0\PowerQuery ou déployez la clé RegEdit :HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\PowerQuery\ClearCredsOnClose = 1.
Le problème est-il spécifique à Excel ?
Non. La pile Microsoft M Engine est partagée entre Excel, Power BI Desktop et même Power Query Online. Cependant, Excel gère parfois différemment le cache Windows Credential Manager.
Références techniques internes
- Document interne Microsoft #87965 : « OAuth token lifetime and Power Query refresh »
- Note d’ingénierie M‑Engine 2025‑04 : « Improved 302 handling for SharePoint connectors »
- Blog Power BI Enterprise – septembre 2025 : « WebView2 network stack deep‑dive »
En résumé : lorsque l’erreur malformed web response surgit sur l’ensemble de vos requêtes, la cause la plus fréquente est un jeton d’authentification obsolète. La purge des autorisations globales oblige Power Query à renégocier un accès sain, éliminant immédiatement l’exception. Envisagez en complément la mise à jour de votre environnement Office, la vérification de tout proxy intermédiaire et l’analyse réseau avancée pour éviter la réapparition du problème.