Depuis le 9 septembre 2026, un bouton “Dashboard” est apparu dans le menu ”+ Créer” de vos rapports Google Analytics. Et si vous maintenez déjà une dizaine de rapports Looker Studio branchés sur GA4, la première question que soulèvent les Dashboards GA4, ce n’est pas “comment ça marche”. C’est : est-ce que je peux en supprimer une partie, et lesquels exactement ? Cet article ne va pas vous montrer trente captures d’écran pour construire votre premier tableau de bord. Il répond à la seule chose qui compte quand on hérite d’un parc de dashboards ingérable : quels rapports basculer en natif, lesquels ne jamais toucher, et pourquoi. Précision de vocabulaire tout de suite, parce qu’elle sème la confusion : depuis avril 2026, Looker Studio a été rebaptisé Data Studio (avec une offre gratuite Data Studio et une offre payante Data Studio Pro). J’emploie les deux noms dans cet article, ils désignent le même outil.
Ce qui a changé le 9 septembre 2026
Les Dashboards GA4 sont un constructeur de tableaux de bord natif, intégré directement dans la propriété. Vous y accédez par Rapports, bouton ”+ Créer”, puis “Dashboard”. Vous posez vos cartes sur un canvas en grille par glisser-déposer, et vous publiez le tableau directement dans la navigation de gauche de la propriété, sans passer par la bibliothèque de rapports ni par un outil tiers.
Sur le papier, ça ressemble à un Looker Studio miniature enfermé dans GA4. Dans les faits, c’est autre chose, et le piège serait de le traiter comme un remplaçant de Data Studio. Ce n’en est pas un. C’est un outil de pilotage interne, rapide, avec des limites très nettes qui tracent précisément sa frontière d’usage. Ces limites ne sont pas des détails techniques à mettre en note de bas de page : ce sont elles qui décident, rapport par rapport, si vous pouvez migrer ou non.
Ce que Dashboards GA4 sait faire
Le principe est volontairement simple. Un canvas en grille, des cartes qu’on dépose et qu’on redimensionne, et six familles de visualisations : les indicateurs clés (score cards), les tableaux, les courbes, les barres, les donuts et les entonnoirs. C’est ce dernier point qui mérite l’attention : l’entonnoir était jusqu’ici un territoire quasi exclusif des Explorations. Le voir arriver dans un dashboard natif, publiable en un clic, intéresse directement les équipes e-commerce qui veulent afficher un tunnel d’achat sans monter une exploration complète.
La vraie nouveauté n’est pas visuelle, elle est dans le circuit. Un dashboard natif se publie dans la navigation de gauche et devient visible par toute la propriété. Pas d’export, pas de partage de lien à gérer, pas de connecteur à configurer. Pour créer et publier, il faut le rôle Éditeur ou Administrateur sur la propriété ; les autres utilisateurs peuvent consulter. Court, factuel, et déjà suffisant pour beaucoup d’équipes qui n’ont jamais ouvert Looker Studio de leur vie.
Les cinq limites qui décident de tout
Voici le cœur du sujet. Cinq limites, documentées par Google, qui déterminent à elles seules ce que Dashboards remplace et ce qu’il ne remplacera jamais. Prenez-les une par une, avec leur conséquence pratique.
| Limite | Détail | Conséquence pratique |
|---|---|---|
| Nombre de cartes | 15 maximum en propriété standard, 30 en 360 | Impossible de reproduire un rapport client à 40 blocs |
| API | Non supportée | Aucune automatisation, aucun versionnage, aucun déploiement multi-propriété |
| Segments | Non supportés | Toute lecture par cohorte ou par audience reste dans les Explorations |
| Comparaisons par carte | Non supportées | Comparaison uniquement globale, sur toute la page |
| Partage | Tout dashboard publié est partagé avec la propriété | Pas de dashboard “brouillon” visible de vous seul une fois publié, ni de partage à un tiers sans accès à la propriété |
Ajoutez une sixième contrainte qui passe souvent inaperçue : vous êtes limité aux métriques natives de GA4. Pas de métrique calculée à la volée, pas de champ personnalisé façon Data Studio. Si votre rapport client repose sur un taux maison (coût par lead qualifié, marge par canal), Dashboards ne le fera pas.
Chacune de ces limites est une frontière. Le plafond de cartes exclut le rapport dense. L’absence d’API exclut tout ce qui doit tourner tout seul ou se dupliquer. L’absence de segments renvoie l’analyse par audience aux Explorations. Le partage à toute la propriété exclut le rapport confidentiel et le rapport client. Retenez ça, et la moitié de vos décisions de migration sont déjà prises.
Ce que Dashboards règle et que Looker Studio ne réglait jamais
Voici la partie que personne n’écrira, parce qu’elle ne fait pas un bon titre d’annonce. Pour beaucoup d’équipes, la douleur quotidienne du reporting n’a jamais été “je veux plus de visualisations”. C’était “mon rapport affiche une erreur de quota à 9 h du matin”. Le connecteur GA4 de Looker Studio passe par l’API Data de GA4, et cette API a des quotas. Un dashboard un peu ambitieux, ouvert par plusieurs personnes en même temps, et vous tombez sur le fameux message d’erreur, le rapport à moitié vide, la carte qui ne charge pas.
Un dashboard natif lit les données là où elles sont. Pas de connecteur, pas d’API Data dans la boucle, donc pas d’erreur de quota. C’est l’argument décisif pour une équipe qui vit avec un rapport en erreur une matinée sur trois. Si votre douleur, c’est la fiabilité et pas la richesse, Dashboards résout votre problème du jour au lendemain.
Attention à ne pas surinterpréter. Le seuillage (thresholding) et l’échantillonnage sont des comportements de GA4 lui-même, pas du connecteur. Passer au natif fait disparaître les erreurs de quota de l’API, pas les limites de la donnée. Un chiffre seuillé restera seuillé dans un dashboard natif. Si vous voyez aujourd’hui des trous dans vos données, vérifiez d’abord s’il s’agit d’un rapport cassé par le connecteur ou d’un vrai problème de collecte : ce n’est pas le même diagnostic, et Dashboards ne règle que le premier.
Dashboards, Explorations, rapports personnalisés ou Data Studio : le comparatif
C’est le tableau que tout le monde cherche et que Google documente mal. Quatre surfaces de restitution, quatre usages, à ne pas confondre.
| Critère | Dashboards | Explorations | Rapports personnalisés | Looker / Data Studio |
|---|---|---|---|---|
| Public visé | Interne, pilotage rapide | Analyste, ad hoc | Interne, rapport standard | Client, externe, direction |
| Segments | Non | Oui | Partiel | Oui |
| Blending de sources | Non, GA4 seul | Non, GA4 seul | Non | Oui, multi-sources |
| Partage externe | Non, via la propriété | Non | Non | Oui, lien ou PDF |
| Automatisation / API | Non | Non | Non | Oui, connecteurs et planification |
| Plafond de complexité | Bas, 15 cartes | Élevé | Moyen | Très élevé |
Lecture rapide : Dashboards occupe la case “page KPI interne consultée tous les matins”. Les Explorations gardent l’analyse fine et segmentée. Les rapports personnalisés restent le tableau standard dans l’interface. Et Looker / Data Studio conserve tout ce qui touche au client, à l’externe, au blending et à l’automatisation. Chacun sa case, et surtout : arrêtez de faire faire à Looker Studio le travail d’une simple page KPI.
La grille de décision en 6 questions
Vous avez un rapport devant vous et vous vous demandez où il doit vivre. Répondez à ces six questions dans l’ordre. La première réponse “oui” qui vous sort de Dashboards tranche la question.
- Avez-vous besoin de croiser GA4 avec une autre source (coûts, CRM, BigQuery) ? Si oui, ce n’est pas Dashboards. Direction Looker / Data Studio ou BigQuery.
- Le destinataire a-t-il un accès à la propriété GA4 ? Si non, ce n’est pas Dashboards. Un dashboard natif ne se partage pas hors de la propriété.
- Avez-vous besoin de segments ou d’une lecture par audience ? Si oui, ce sont les Explorations.
- Le rapport doit-il se déployer sur plusieurs propriétés ? Si oui, ce n’est pas Dashboards : pas d’API, pas de duplication inter-propriétés.
- Dépassez-vous 15 blocs (30 en 360) ? Si oui, le natif ne suivra pas.
- Le rapport doit-il survivre à un changement d’outil ou être versionné ? Si oui, restez sur un support exportable.
Si vous répondez “non” aux six, félicitations : votre rapport a sa place dans un dashboard natif, et vous pouvez probablement retirer l’équivalent de votre parc Looker Studio. Dans le cas contraire, vous savez maintenant exactement pourquoi il doit rester ailleurs.
Le cas BigQuery
Pour l’audience de ce blog, c’est la ligne de fracture. Dashboards ne lit que GA4. Point. Tout ce qui touche à l’export BigQuery, aux requêtes personnalisées, aux données de coût importées, aux jointures CRM ou aux tables blendées reste hors de portée du natif. Si votre reporting s’appuie sur BigQuery, Dashboards ne réduit pas l’intérêt de cet export, il le déplace : le natif prend la couche “pilotage GA4 pur”, et BigQuery garde tout le reste.
Concrètement, la pipeline BigQuery vers Data Studio que beaucoup d’entre vous maintiennent reste parfaitement valable. C’est même l’étage qui gagne en clarté maintenant qu’un outil natif absorbe les rapports simples. Si vous n’avez pas encore industrialisé ce circuit, la méthode complète est décrite dans Automatiser ses rapports avec Looker Studio et BigQuery, toujours d’actualité malgré le rebranding. Et pour tout ce qui doit sortir de l’univers Google (Power BI, Tableau, un autre outil BI), le passage par BigQuery reste la bonne porte, détaillé dans Exporter ses données BigQuery vers Power BI, Tableau et Looker.
Migrer, concrètement
Ne supprimez rien dans la précipitation. La bonne méthode tient en quatre temps : inventoriez vos rapports Looker Studio existants, classez chacun selon la question “lit-il uniquement GA4, sans segment, sous 15 blocs ?”, recréez les candidats en dashboard natif, et testez-les sur un cycle de reporting complet avant de supprimer quoi que ce soit. Un mois de double affichage coûte moins cher qu’un rapport supprimé dont personne n’avait vu qu’il servait à quelqu’un.
Les premiers à basculer sont toujours les mêmes : la page KPI interne consultée chaque matin, le suivi de campagne simple, le funnel e-commerce standard. Ceux qu’on ne touche jamais : le rapport client, le rapport blendé sur BigQuery, le rapport segmenté, le rapport automatisé.
Les 3 rapports Looker Studio que vous pouvez retirer dès cette semaine. Un, la page d’accueil KPI (sessions, utilisateurs, conversions, revenus) que toute l’équipe consulte : elle tient largement dans 15 cartes et ne sort jamais de la propriété. Deux, le suivi hebdomadaire d’une campagne unique, sans blending ni coût importé. Trois, le tableau de bord SEO de base branché sur GA4 seul (pages, canal organique, événements clés). Ces trois-là ne justifient plus un connecteur qui plante ; recréez-les en natif, laissez-les tourner un cycle, puis archivez les originaux.
Un préalable, quand même : un dashboard construit sur une propriété mal configurée reproduit l’erreur, en plus visible. Avant de figer vos rapports en natif, un rapide audit de configuration GA4 évite de graver dans le marbre une config bancale.
Les pièges à l’usage
Trois pièges reviennent, et le troisième est le plus original parce que personne ne le documente.
Le plafond de 15 cartes arrive plus vite qu’on croit. Empilez cinq scorecards, deux courbes, trois tableaux, et vous y êtes déjà. Concevez vos dashboards natifs pour l’essentiel, pas pour l’exhaustivité : ce n’est pas un rapport client, c’est une page de pilotage.
Publier, c’est partager avec toute la propriété. Il n’y a pas de “brouillon privé” une fois publié. Prévenez l’équipe avant de pousser un dashboard dans la navigation de gauche, sinon tout le monde hérite de votre expérimentation à moitié finie.
Et le plus bloquant pour les structures multi-propriétés : sans API, un dashboard ne se sauvegarde pas, ne s’exporte pas et ne se duplique pas d’une propriété à l’autre. Pour une agence qui gère trente clients, ou un groupe multi-marques, cela veut dire tout refaire, propriété par propriété, à la main. Aucun déploiement centralisé, aucun modèle réutilisable. C’est probablement la limite qui disqualifie Dashboards pour la moitié des lecteurs de ce blog, et elle mérite d’être dite clairement plutôt que noyée dans une liste de features.
Conclusion : une architecture de reporting à trois étages
La réponse à la question du titre n’est pas “abandonnez Looker Studio”. Elle est : vous allez en supprimer un tiers, et savoir lequel vous fera gagner un temps considérable. L’architecture qui tient la route en 2026 tient en trois étages. Dashboards pour le pilotage interne quotidien, rapide et fiable. Looker / Data Studio sur BigQuery pour le rapport client, les blends et l’automatisation. Les Explorations pour l’analyse ad hoc et segmentée. Chacun son étage, et surtout : cessez de demander à un dashboard Looker Studio branché en direct sur le connecteur GA4 de faire un travail de page KPI, parce que c’est exactement cette couche intermédiaire qui se fait grignoter.
Car c’est ça, le vrai mouvement de fond. Google réinternalise la restitution dans GA4 (Dashboards, Ask Advisor, insights générés) au moment même où il pousse l’analyse avancée vers BigQuery. Le dashboard Looker Studio branché en direct sur le connecteur, celui qui vivait entre les deux, est pris en tenaille des deux côtés. Si vous voulez comprendre l’autre versant de ce mouvement, l’assistant qui absorbe l’analyse, jetez un œil à Ask Advisor GA4 : l’IA Google remplace-t-elle le data analyst ?. Faites l’inventaire cette semaine, testez sur un cycle, et vous aborderez le Q4 avec un reporting plus léger et plus fiable.