Refresh Power Query cassé en production : où s'arrête la responsabilité du consultant ?

Vous livrez un rapport. L'actualisation tourne, les chiffres sont bons, le client est satisfait. Trois semaines plus tard, un appel : « le dashboard est mort, plus rien ne s'actualise ». Que s'est-il passé ? Un refresh Power Query peut se rompre pour des raisons très différentes, et c'est cette diversité qui rend la question de la responsabilité délicate.

Côté conception (votre périmètre) :

• Une requête M qui ne réplie pas (query folding rompu) et ramène toute la table avant de filtrer, faisant exploser les volumes et la durée d'actualisation.
• Une jointure ou un append mal posé qui duplique les lignes à chaque rafraîchissement.
• Un référencement de colonne en dur qui casse dès que la source change de schéma.

Côté environnement client (hors de votre contrôle) :

• Une colonne renommée ou supprimée dans la base source par une autre équipe.
• Une passerelle de données (gateway) tombée ou des identifiants expirés.
• Une montée de version de l'API source ou un quota Fabric atteint.

Le principe directeur est simple à énoncer : vous répondez de ce que vous avez conçu, pas de ce que l'environnement du client devient après votre départ.

Si l'actualisation casse parce que votre requête M dépendait d'un nom de colonne en dur, sans gestion d'erreur, et qu'un simple renommage suffit à tout faire tomber, c'est un défaut de robustesse imputable à votre conception. Un professionnel certifié est censé écrire des transformations défensives.

En revanche, si la source de données change de structure de façon imprévisible, si la gateway de l'entreprise tombe, ou si le service IT modifie les droits d'accès, vous n'êtes pas responsable d'un événement que vous ne maîtrisiez pas et qui survient hors de votre mission. La frontière se trace ainsi :

La frontière ci-dessus est théorique. En pratique, ce qui tranche un litige, c'est ce que dit votre contrat. Un consultant qui a livré un rapport « clé en main » sans préciser le périmètre s'expose à ce que le client considère toute panne comme étant de son ressort, y compris des mois plus tard.

Quelques clauses simples changent radicalement votre exposition :

• Définir la fin de la prestation : à quel moment la mission de développement s'arrête et où commence (ou non) une maintenance.
• Distinguer build et run : préciser si la maintenance des actualisations, la surveillance et la correction d'incidents font l'objet d'un contrat de TMA séparé.
• Lister les dépendances externes : nommer les sources, gateways et environnements dont la stabilité ne relève pas de vous.

Sans périmètre écrit, le consultant est présumé responsable de tout, indéfiniment. Avec un périmètre écrit, chaque incident se rattache clairement à une zone de responsabilité.

Un dashboard qui ne s'actualise plus n'est pas un simple désagrément technique. Si le client pilote son activité dessus, l'arrêt a un coût : décisions reportées, équipes qui reviennent à des extractions manuelles, fiabilité du pilotage compromise pendant la panne.

Si un volume de données explosé fait dépasser une capacité Fabric ou une licence Premium, la facture cloud peut grimper de plusieurs milliers d'euros en quelques jours d'actualisations en boucle. Là encore, si la cause est une requête M défaillante de votre conception, le client cherchera à vous en imputer le surcoût.

Ce sont des dommages immatériels classiques : pas de bien détruit, mais une perte financière liée à votre prestation. Le montant peut être modeste pour une PME, ou significatif pour une organisation qui a bâti son reporting opérationnel sur vos modèles.

Même avec un périmètre impeccable et des requêtes M robustes, le risque zéro n'existe pas : un litige peut naître d'une simple divergence d'interprétation sur ce qui relevait de votre mission. La RC Pro couvre précisément ces situations, en finançant votre défense pour démontrer la frontière de responsabilité, et en indemnisant le client si une faute de conception est avérée.

Pour les consultants qui assurent aussi une maintenance applicative et manipulent au quotidien plusieurs environnements clients, il est pertinent de regarder au-delà de la seule faute. Le matériel informatique protège vos propres outils de travail — postes, écrans, équipement — dont dépend votre capacité à intervenir vite en cas d'incident chez un client.

L'essentiel est de ne pas aborder la phase de run sans filet. Un consultant Power BI qui documente son périmètre, écrit des transformations défensives et s'appuie sur une RC Pro adaptée transforme un risque de litige potentiellement coûteux en un incident gérable et borné.