Gérer les erreurs en Power Query : try, otherwise et contrôles

Une actualisation qui plante un lundi matin à cause d’une cellule « N/A » dans un export : tout utilisateur de Power BI a vécu ce moment. Power Query a pourtant tout ce qu’il faut pour encaisser les données imparfaites, à condition de choisir la bonne stratégie : intercepter l’erreur, la remplacer, écarter la ligne, ou au contraire la faire parler. Cet article passe les quatre en revue, avec le code et les cas où chacune s’impose.

D’abord, comprendre d’où vient l’erreur

Une erreur Power Query naît presque toujours à l’une de ces trois étapes : une conversion de type (du texte dans une colonne de nombres), un accès à une source (fichier déplacé, classeur renommé), ou un calcul impossible (division par zéro, clé absente). Cliquez sur la cellule Error : Power Query affiche le message exact. Ce réflexe évite de corriger au hasard.

Stratégie 1 : intercepter avec try … otherwise

// Conversion qui ne plante jamais : null si la valeur est inconvertible
try Number.From ( [Montant] ) otherwise null

// Division protégée
try [CA] / [Quantité] otherwise 0

try … otherwise est l’équivalent du SIERREUR d’Excel : on tente l’opération, on fournit une valeur de repli. À utiliser au niveau de l’expression, dans une colonne personnalisée. La forme sans otherwise renvoie un enregistrement décrivant l’erreur, ce qui permet des traitements plus fins (garder le message dans une colonne de diagnostic, par exemple).

Stratégie 2 : remplacer ou écarter en masse

// Remplacer les erreurs d'une colonne par une valeur
Table.ReplaceErrorValues ( Source, {{"Montant", 0}, {"Date", null}} )

// Supprimer les lignes en erreur (sur certaines colonnes ou toutes)
Table.RemoveRowsWithErrors ( Source, {"Montant"} )

L’interface propose les deux : clic droit sur la colonne, « Remplacer les erreurs » ou « Supprimer les erreurs ». Le choix n’est pas anodin. Remplacer conserve la ligne (bon pour un montant optionnel), supprimer écarte silencieusement des données. Si vous supprimez, comptez ce que vous perdez : un Table.RowCount avant et après, ou mieux, une requête dédiée qui isole les lignes fautives pour les examiner.

Stratégie 3 : créer des erreurs explicites

Quand une requête alimente d’autres personnes, une erreur claire vaut mieux qu’une donnée fausse qui passe inaperçue :

if [Taux] > 1 then
    error Error.Record (
        "Taux invalide",
        "Le taux dépasse 100 %",
        "Vérifier la saisie dans le fichier source, ligne " & Text.From ( [Index] )
    )
else [Taux]

Error.Record fabrique une erreur avec raison, message et détail. Celui qui ouvrira la requête dans six mois saura quoi corriger sans archéologie. C’est notre convention sur les requêtes livrées aux clients : les contrôles métier lèvent des erreurs qui expliquent, en français, quoi vérifier et où.

Stratégie 4 : fiabiliser la source plutôt que rattraper

Les erreurs récurrentes signalent souvent un problème en amont qu’aucun try ne réglera durablement : un export dont les colonnes changent de nom, un fichier saisi à la main sans validation, un séparateur décimal qui varie selon le poste. Dans ces cas, la vraie correction est structurelle : figer le format de l’export, verrouiller la saisie, ou brancher la requête sur la base plutôt que sur le fichier. La règle que nous appliquons : un incident, un try ; deux incidents identiques, une correction à la source.

Erreurs Power Query : les questions qui reviennent

Pourquoi l’aperçu est-il correct mais l’actualisation plante ?

L’aperçu de l’éditeur ne charge que les premières lignes : l’erreur se cache plus loin dans le fichier. Actualisez l’aperçu sur la requête entière ou triez la colonne suspecte pour faire remonter les valeurs atypiques.

Comment isoler les lignes en erreur pour les examiner ?

Dupliquez la requête, puis gardez uniquement les erreurs : Table.SelectRowsWithErrors ( Source ). Cette requête de contrôle, chargée dans une table à part, devient votre liste d’anomalies à traiter côté source.

try fonctionne-t-il sur une source entière ?

Oui : try Excel.Workbook ( File.Contents ( Chemin ) ) permet de gérer proprement un fichier absent, par exemple pour enchaîner sur un fichier de secours ou une table vide. Utile pour les dossiers alimentés à la main où il manque parfois un mois.

Des requêtes qui encaissent les données réelles sans tomber, c’est ce qui sépare un rapport de démonstration d’un outil de production. Nos projets data & BI livrent des chaînes contrôlées de bout en bout, contrôles métier compris.