Data Studio ne fonctionne pas ? Je trouve la cause et je la corrige

Pourquoi Data Studio ne fonctionne pas sur mon rapport ?

Parce que quelque chose a changé sous le graphique, et que Data Studio ne vous prévient pas quand un connecteur tombe en panne. Le graphique affiche simplement une erreur, un vide ou un chiffre qui dérive discrètement. Le temps que quelqu’un s’en aperçoive, le rapport est souvent faux depuis des semaines.

Voici les causes que je rencontre le plus souvent, à peu près par ordre de fréquence.

• Identifiants : une source de données utilise les identifiants du propriétaire d’un compte qui a quitté l’entreprise ou perdu ses accès.
• Quota : les graphiques GA4 échouent avec des erreurs de quota quand de nombreux graphiques et lecteurs se partagent le budget horaire de jetons.
• Fusions : les clés de jointure ne correspondent plus après un changement de nommage, si bien que des lignes disparaissent en silence.
• Champs supprimés : un connecteur a retiré un champ, comme les champs d’extension de lieu de Google Ads supprimés le 4 mai 2026.
• Changements de schéma : une colonne a été renommée dans une feuille Sheets ou une table, ce qui casse tous les champs calculés qui l’utilisaient.
• Volume : les requêtes volumineuses déclenchent des erreurs « trop de lignes » ou expirent.

Comment corriger les erreurs d’identifiants des sources de données dans Data Studio ?

Vérifiez quels identifiants utilise chaque source de données, puis transférez-les sur un compte qui restera. Avec les identifiants du propriétaire, les lecteurs voient les données grâce aux accès du propriétaire de la source. Avec les identifiants du lecteur, chaque lecteur a besoin de son propre accès aux données sous-jacentes. Les deux sont valables, et les deux provoquent des erreurs quand ils sont réglés par accident.

La panne classique est un rapport construit par un freelance ou un ancien salarié, dont toutes les sources reposent sur les identifiants de cette personne. Quand ses accès prennent fin, tout le rapport devient vide. Je réattribue la propriété à un compte partagé ou à un compte de service, réautorise chaque source et teste le rapport en tant que lecteur type.

Pourquoi mon rapport affiche-t-il une erreur de configuration ou une fusion cassée ?

Une erreur de configuration signifie généralement qu’un graphique fait référence à un champ, une métrique ou une dimension qui n’existe plus ou n’est plus compatible. Elle apparaît après des mises à jour de connecteurs, après qu’une personne a renommé une colonne dans Sheets, ou lorsqu’un champ calculé dépend d’un autre champ qui a été supprimé.

Les fusions cassent de façon plus subtile. Une fusion joint au maximum cinq sources, uniquement par jointures d’égalité : un espace en fin de chaîne, une convention de nommage des campagnes modifiée ou une date dans un autre format suffisent pour que les lignes ne correspondent plus. Le graphique se charge toujours, simplement avec des totaux plus faibles. Je compare les totaux fusionnés à ceux de chaque source prise isolément pour trouver où les lignes se perdent, puis je corrige la clé ou déplace la jointure dans Sheets ou BigQuery, où elle peut être vérifiée.

Pourquoi mon rapport Data Studio est-il si lent ?

Les rapports lents envoient généralement trop de requêtes lourdes à la fois. Les longues pages avec des dizaines de graphiques, les tableaux larges, les nombreuses fusions et les requêtes GA4 en direct sur de longues périodes s’additionnent.

Les corrections sont pragmatiques : scinder les pages, supprimer les graphiques inutilisés, réduire les dimensions dans les grands tableaux, remplacer l’historique lent par des extraits et pré-agréger dans BigQuery pour les sources les plus lourdes. Les sources à schéma fixe comme GA4 et Google Ads plafonnent aussi les tableaux à 10 dimensions et 20 métriques : des tableaux conçus au-delà ne se comporteront jamais bien.

Et si les chiffres de mon rapport ne correspondent pas à la source ?

Traitez-le comme un problème de définitions jusqu’à preuve du contraire. Les écarts entre un rapport et GA4, Google Ads ou un CRM viennent généralement des périodes, des fuseaux horaires, des filtres de la source de données, de colonnes de conversion différentes, ou d’un champ calculé qui additionne un ratio au lieu de le recalculer.

Je rapproche un indicateur à la fois de la source, documente chaque écart et corrige ceux qui sont des erreurs. Certains écarts sont légitimes, comme les événements clés GA4 face aux leads du CRM : ils reçoivent alors une mention sur la page plutôt qu’une correction.

Un tableau de bord industriel que j’ai dirigé chez Greenwolf Tech Labs montre bien pourquoi c’est important. Il suit les unités produites et perdues, les unités perdues par machine, la productivité par machine, la disponibilité des opérateurs, les causes de pertes et les coûts de maintenance. Quand de tels chiffres orientent des décisions de maintenance, une erreur de définition n’est pas un détail esthétique.

Faut-il réparer le rapport ou le reconstruire ?

Réparez-le quand la structure est saine et que les problèmes sont précis. Une réparation conserve les URL, les favoris et les envois planifiés existants, et votre équipe n’a pas à réapprendre la mise en page.

Reconstruisez-le quand la logique est copiée dans des dizaines de champs calculés au niveau du rapport sans aucune documentation, quand chaque page se heurte aux limites de quota, ou quand le rapport répond à des questions que plus personne ne pose. Je vous dis dans quel cas vous êtes après l’audit, avant que vous ne payiez l’une ou l’autre option. Les abandons à venir, comme la fin de la prise en charge de MySQL 5.6 et 5.7 d’ici le 26 février 2027, méritent aussi d’être vérifiés dès maintenant si vos rapports utilisent ces bases de données.