Comment récupérer des erreurs dans Power BI ?

Une erreur dans Power BI n’est pas un simple désagrément visuel : elle peut interrompre un rafraîchissement, fausser un indicateur ou, plus insidieusement, faire disparaître des lignes utiles après un nettoyage trop radical. La bonne réponse n’est donc pas toujours de cliquer sur Supprimer les erreurs. Il faut d’abord savoir ce que l’erreur signale, où elle est produite et quelle donnée métier elle concerne.

Power Query offre les outils les plus efficaces pour récupérer les lignes en erreur, analyser leur détail et construire un traitement durable. Le modèle de données et le service Power BI apportent ensuite leurs propres mécanismes, notamment pour les calculs DAX et les échecs de rafraîchissement. L’enjeu est de convertir une anomalie technique en processus de contrôle fiable.

Une démarche rigoureuse repose sur trois principes : isoler l’erreur, identifier sa cause et choisir un traitement traçable. Cela évite de dégrader silencieusement les analyses tout en sécurisant les chargements futurs.

Comprendre les erreurs que Power BI peut rencontrer

Le terme « erreur » recouvre plusieurs réalités dans Power BI. Une cellule peut contenir une valeur d’erreur dans Power Query, une étape de transformation peut devenir invalide, un calcul DAX peut échouer, ou le service peut refuser un rafraîchissement. Le traitement pertinent n’est pas le même dans chaque cas.

Les erreurs de conversion sont les plus courantes. Elles apparaissent souvent après l’étape Type modifié, que Power Query ajoute parfois automatiquement. Par exemple, une colonne censée contenir des montants peut comporter « N/A », un symbole monétaire inattendu, une cellule vide codée sous forme de tiret ou un montant avec une virgule décimale interprétée selon une autre culture.

Détecter précisément les erreurs dans l’éditeur Power Query

Ouvrez Transformer les données depuis Power BI Desktop pour accéder à l’éditeur Power Query. Dans le volet droit, les Étapes appliquées constituent votre premier outil de diagnostic : cliquez sur les étapes une à une jusqu’à identifier celle où les valeurs deviennent erronées. Une erreur présente dès l’étape Source relève généralement de la donnée amont ; une erreur introduite plus loin provient d’une transformation.

Le profilage des données, activable depuis l’onglet Affichage, complète cette lecture. Les indicateurs de qualité de colonne signalent les valeurs valides, vides et erronées. La distribution et le profil de colonne aident à repérer les formats aberrants : un code « inconnu » dans une colonne de dates, des libellés dans une colonne de quantités, ou une valeur exceptionnellement longue dans un identifiant.

Attention toutefois à la portée de cette analyse. Selon les réglages et le volume de données, l’aperçu et certains profils peuvent s’appuyer sur un échantillon. Avant de valider une règle de nettoyage, basculez le profilage sur l’ensemble du jeu de données lorsque cette option est disponible et testez un rafraîchissement complet.

Conserver les lignes fautives avec l’interface

Pour examiner uniquement les lignes concernées, sélectionnez la colonne à contrôler puis utilisez la commande Conserver les erreurs, généralement accessible dans les commandes de réduction ou conservation des lignes. Power Query filtre alors la table sur les erreurs de la ou des colonnes sélectionnées.

Cette opération est très utile pour une investigation ponctuelle, car elle permet de voir les autres champs de la même ligne : identifiant client, fichier d’origine, date d’import, code produit ou système émetteur. C’est ce contexte qui permet de remonter à la source et de distinguer une erreur isolée d’un défaut systémique.

Ne réalisez pas ce filtre directement dans votre requête de production si vous souhaitez préserver le chargement normal. La pratique la plus sûre consiste à créer une référence de la requête : la requête principale conserve les données propres, tandis que la requête de contrôle ne conserve que les erreurs. Désactivez le chargement de cette dernière si elle sert uniquement au diagnostic, ou chargez-la dans une table d’audit si elle doit être suivie.

Récupérer les erreurs avec le langage M

L’interface est suffisante pour un contrôle manuel. Pour une requête rejouable, traçable et exploitable à chaque rafraîchissement, le langage M est préférable. Power Query dispose notamment de la fonction Table.SelectRowsWithErrors, qui récupère les lignes contenant une erreur dans les colonnes indiquées.

Table.SelectRowsWithErrors(#"Type modifié", {"Montant", "Date commande"})

Cette instruction produit une table d’anomalies à partir de l’étape Type modifié. Elle est particulièrement adaptée si les erreurs existent déjà dans les colonnes. Ajoutez à cette table les colonnes de contexte utiles — identifiant de transaction, nom du fichier, date de chargement — afin que les équipes métier ou les propriétaires de source puissent agir sans devoir reproduire votre analyse.

Lorsque vous voulez tester une conversion sans faire échouer la requête, employez l’expression try. Elle retourne un enregistrement indiquant si l’opération a réussi, avec la valeur obtenue ou l’erreur rencontrée. Exemple pour contrôler une colonne qui devrait devenir numérique :

let
    Source = #"Étape précédente",
    Controle = Table.AddColumn(Source, "Test montant", each try Number.From([Montant brut])),
    Erreurs = Table.SelectRows(Controle, each [Test montant][HasError])
in
    Erreurs

La colonne Test montant contient un enregistrement. En développant cette colonne dans l’interface, vous pouvez récupérer notamment HasError, Value et le détail de l’erreur. Selon le cas, les informations Reason, Message et Detail sont précieuses pour comprendre si la cause est une conversion, une valeur introuvable ou un défaut de connecteur.

Créer une table de quarantaine plutôt que perdre des données

Dans les flux sensibles, séparez explicitement les données valides des données rejetées. La logique est simple :

1. conserver la valeur brute provenant de la source ;
2. tenter la transformation dans une colonne de contrôle ;
3. diriger les lignes en erreur vers une requête de quarantaine ;
4. charger les lignes valides dans le modèle avec le type attendu ;
5. suivre le volume et le motif des rejets dans un rapport de qualité.

Cette architecture est plus saine que la suppression aveugle, surtout pour les données financières, commerciales, réglementées ou de production. Elle permet de corriger la source, de rejouer l’import et de documenter ce qui a été exclu du modèle analytique.

Corriger l’erreur à la bonne étape

Une fois les lignes récupérées, la résolution dépend de la cause. Le traitement doit être placé au plus près de l’étape qui introduit le problème, sans masquer une anomalie qui devrait être corrigée dans le système source.

Adapter les types et les paramètres régionaux

Pour les dates et les nombres, vérifiez la culture utilisée par la source. Un fichier européen utilisant la virgule décimale ne se convertit pas forcément avec les mêmes paramètres qu’un fichier américain. Dans Power Query, utilisez Modifier le type > Utiliser les paramètres régionaux plutôt qu’une conversion générique lorsque le format d’origine est connu.

Conservez autant que possible la colonne brute jusqu’à la validation. Cela facilite les contrôles et évite de perdre une information qui pourrait expliquer l’anomalie. La séquence la plus robuste consiste souvent à nettoyer les caractères inutiles, normaliser les valeurs sentinelles telles que « N/A » ou « - », puis convertir le type.

Remplacer une erreur seulement si la règle métier le justifie

La commande Remplacer les erreurs peut substituer une erreur par null, zéro, une date de référence ou une autre valeur. C’est utile si cette substitution a une signification claire. Une quantité manquante ne vaut pas nécessairement zéro ; une date invalide ne doit pas être remplacée par la date du jour pour « faire passer » le chargement.

En M, un remplacement explicite peut prendre cette forme :

Table.ReplaceErrorValues(#"Étape précédente", {{"Montant", null}})

Documentez la convention retenue et, si le remplacement peut influer sur un KPI, ajoutez un indicateur de qualité. Une colonne ou une mesure comptant les lignes corrigées informe les utilisateurs que les résultats reposent sur des données partiellement normalisées.

Résoudre les erreurs de structure et de connexion

Une erreur du type « colonne introuvable » survient souvent lorsqu’un fichier source change : en-tête renommé, feuille Excel modifiée, export incomplet ou champ supprimé dans une API. Remonter la source est en général préférable à une succession de contournements. Si la variabilité est attendue, construisez une requête tolérante : vérifiez l’existence des colonnes attendues, contrôlez le schéma avant les transformations et centralisez les noms de fichiers ou d’onglets dans des paramètres.

Pour les erreurs d’accès, contrôlez les paramètres de source de données dans Power BI Desktop, puis, après publication, les identifiants et la passerelle dans le service Power BI. Un rapport qui fonctionne sur le poste de son auteur peut échouer dans le service si le chemin est local, si la passerelle n’a pas accès au répertoire ou si le compte configuré n’a plus les autorisations nécessaires.

Gérer les erreurs DAX sans cacher un problème de données

Power Query prépare et charge les données ; DAX calcule dans le modèle. Une erreur DAX ne se récupère pas avec Table.SelectRowsWithErrors. Elle exige de revoir la mesure ou la colonne calculée concernée.

Le cas classique est la division. Au lieu d’écrire une division brute, utilisez DIVIDE, qui permet de définir le résultat alternatif lorsque le dénominateur est nul ou absent :

Taux de marge = DIVIDE([Marge], [Chiffre d’affaires], BLANK())

Pour les conversions potentiellement fragiles, IFERROR peut aussi éviter l’affichage d’une erreur, mais il ne doit pas devenir un cache-misère. Un résultat vide est souvent préférable à un zéro artificiel ; il convient ensuite d’expliquer ce vide dans le contexte métier. Vérifiez également les relations du modèle, les valeurs du dénominateur et le contexte de filtre : une mesure erronée peut provenir d’une modélisation incohérente et non d’une formule isolée.

Diagnostiquer un échec de rafraîchissement dans Power BI Service

Lorsqu’un jeu de données s’actualise dans Power BI Desktop mais échoue après publication, consultez l’historique des actualisations du modèle sémantique dans Power BI Service. Le message d’erreur et l’étape concernée permettent de savoir si le problème est lié à la source, aux identifiants, à la passerelle, à une limite de connecteur ou à la requête elle-même.

Les points à vérifier, dans cet ordre, sont généralement les suivants :

• la source est-elle accessible depuis l’environnement du service et non seulement depuis votre poste ;
• les identifiants sont-ils valides et correctement associés à la source ;
• la passerelle est-elle en ligne, à jour et autorisée à lire les ressources requises ;
• les niveaux de confidentialité ou les règles de combinaison de sources bloquent-ils la requête ;
• le schéma de la source a-t-il changé depuis le dernier rafraîchissement réussi ;
• l’erreur touche-t-elle toutes les requêtes ou un seul flux de données.

Mettre en place un processus durable de contrôle qualité

La meilleure gestion des erreurs est préventive. Organisez les requêtes en couches : une couche d’extraction proche de la source, une couche de nettoyage et de typage, puis une couche métier destinée au modèle. Chaque couche devient plus facile à diagnostiquer, et la donnée brute reste disponible pour comparaison.

Ajoutez des contrôles simples mais actionnables : nombre de lignes reçues, nombre de lignes rejetées, taux de valeurs nulles sur les champs critiques, date de dernière donnée reçue, doublons d’identifiant et répartition des motifs d’erreur. Un tableau de bord de qualité n’a pas besoin d’être complexe ; il doit surtout alerter quand la situation change.

Enfin, versionnez les fichiers et les requêtes importantes. Le format de projet Power BI et les pratiques de gestion de code adaptées à votre organisation facilitent la revue des modifications. À défaut, conservez des copies datées avant une refonte significative et documentez chaque règle de nettoyage. Power Query ne remplace pas une véritable stratégie de versioning : annuler une action dans une session n’est pas une solution de restauration à long terme.