Un tableau vide ne démontre pas l’arrêt de la collecte
Le tableau de statistiques ne termine plus son chargement après une erreur API, ou une carte affiche un accès refusé. Cela peut concerner le compte connecté, la propriété sélectionnée, une limite de requêtes ou l’affichage local. Le site peut continuer à transmettre des événements pendant que WordPress ne parvient plus à consulter les rapports.
Le résultat recherché est le retour des données attendues pour le bon service et la bonne période, avec un accès adapté. Il ne s’agit pas de créer une nouvelle propriété vide pour faire disparaître une erreur. La collecte des visites, leur traitement par le service et la récupération d’un rapport dans WordPress sont des étapes distinctes. Une panne de la dernière ne justifie pas de remplacer les balises du site.
Le parcours détaillé utilise Site Kit by Google lorsqu’il est déjà installé, avec Analytics comme exemple de source. Pour un autre tableau, gardez cette séparation des étapes et utilisez ses propres réglages. Commencez sans ajouter d’extension : la consultation directe du service permet de comparer les données et les droits avant de toucher à WordPress.
Relevez l’erreur exacte, l’heure et le service touché. Précisez si un seul utilisateur du tableau rencontre le problème ou si toute l’équipe le voit. Cette différence est utile : les droits Google d’une personne ne sont pas automatiquement ceux d’un autre administrateur WordPress. Gardez les identifiants et les captures de rapports dans un espace privé adapté aux données qu’ils contiennent.
Relever le compte et la propriété actuellement utilisés
Dans Site Kit → Settings → Connected Services, développez Analytics puis consultez ses réglages. Edit ouvre les paramètres de compte, propriété et flux de données web. Relevez ces références et l’état de Place Google Analytics code sans les modifier. Le but est de savoir quel ensemble de données le tableau demande et qui fournit actuellement la balise au site.
Dans Site Kit → Dashboard, la photo ou l’initiale du compte en haut à droite permet de retrouver le compte Google connecté. Vérifiez son adresse complète. Une session WordPress administrateur donne accès aux réglages du site, mais ne garantit pas que ce compte Google possède les droits sur la propriété Analytics choisie par l’équipe.
Au contrôle du 3 novembre 2026, Site Kit by Google est proposé par Google en version 1.191.0, avec WordPress 5.2/PHP 7.4 minimum et une compatibilité déclarée jusqu’à WordPress 7.1.4. L’extension est gratuite. Ces informations qualifient l’outil existant ; elles ne constituent pas un test sur votre installation ni une obligation de changer sa version pendant l’incident.
Si un autre administrateur a remplacé la propriété connectée, ne revenez pas immédiatement à une référence trouvée dans une ancienne capture. Confirmez avec l’équipe la propriété prévue et le flux qui collecte réellement le site public. Une copie de contrôle peut porter un titre identique tout en devant utiliser une autre configuration. Cette lecture doit produire une correspondance claire entre site, compte et propriété.
Approche 1 : consulter la source directe et comparer une période cohérente
Depuis une carte Analytics du tableau, le lien Source: Analytics permet de rejoindre le service. Vous pouvez aussi ouvrir Google Analytics par votre adresse habituelle, avec le même compte Google. Dans son sélecteur de propriété, retrouvez la référence relevée dans Site Kit. Comparez une période correspondant à celle du tableau plutôt qu’un rapport Temps réel avec un bilan de plusieurs semaines.
Si les données existent dans le service mais pas dans WordPress, la collecte et le stockage de cette période sont au moins disponibles dans la propriété. Examinez maintenant les droits de récupération, la connexion ou l’affichage du tableau. Si la propriété n’est pas accessible directement avec ce compte, corrigez d’abord cet accès. Si elle est accessible mais sans les données attendues, vérifiez la référence, la période et le flux avant d’accuser l’API du tableau.
Les versions actuelles de Site Kit peuvent inclure les données du jour. Elles ne fournissent pas pour autant un suivi en temps réel : les services traitent leurs données et les valeurs récentes peuvent évoluer. La documentation actuelle indique des délais habituels de quelques heures et une récupération périodique. Une visite effectuée à l’instant ne doit donc pas servir de preuve unique d’échec.
Le résultat attendu est une comparaison portant sur la même source et les mêmes dates. Ce parcours ne modifie aucun réglage et n’a pas besoin de retour arrière. Vous pouvez continuer à consulter la source directe pendant la réparation du tableau, sans remplacer la propriété ni effacer l’historique.
Approche 2 : rétablir les droits du compte sur la propriété prévue
Cette voie convient si le service affiche Insufficient permissions ou si le même compte ne peut pas ouvrir la propriété directement. Demandez au responsable de la propriété de vérifier l’adresse Google réellement utilisée dans Site Kit. Donner un rôle WordPress plus élevé ne lui confère pas les droits du service externe.
Dans Google Analytics, un administrateur de la propriété ouvre Administration → Propriété → Gestion des accès à la propriété. Il retrouve l’utilisateur ou utilise + → Ajouter des utilisateurs, saisit l’adresse de son compte Google et choisit le rôle adapté. Pour consulter des rapports, Lecteur peut répondre au besoin. Certaines opérations de configuration ou fonctions avancées demandent davantage : elles doivent être distinguées du simple affichage de données.
Accordez l’accès au niveau de cette propriété lorsque le besoin s’y limite, plutôt qu’à toutes les propriétés du compte. Vérifiez aussi les restrictions de données qui peuvent masquer certaines mesures. Après l’ajout ou la correction, ouvrez de nouveau la source directe avec le compte concerné, puis revenez au tableau Site Kit. Le résultat attendu est l’accès à la propriété prévue et le retour des rapports accessibles à ce rôle.
Conservez le rôle initial et le niveau où il était attribué. Pour annuler une modification inutile, le responsable rétablit les droits à ce même niveau, en tenant compte des accès hérités. Ne retirez pas l’utilisateur de toute l’organisation pour annuler une permission accordée à une seule propriété. Si un bouton Request access est proposé dans Site Kit, il aide à demander l’accès au bon propriétaire ; il ne vous l’accorde pas automatiquement.
Utiliser une vue partagée lorsque l’équipe souhaite seulement lire les chiffres
Si la personne doit uniquement consulter le tableau dans WordPress, le partage de Site Kit peut être une alternative à un accès direct complet au service. Le propriétaire de la connexion, ou l’administrateur autorisé à gérer ce partage, ouvre Site Kit → Dashboard puis l’icône de partage dans l’en-tête.
Dans le service concerné, Edit roles permet de sélectionner les rôles WordPress autorisés à lire ses statistiques. Appliquez avec Apply après avoir vérifié qui possède ces rôles sur le site. Le réglage concerne les utilisateurs de ces rôles, pas seulement la personne dont vous êtes en train d’examiner l’erreur. Il ne faut donc pas ouvrir largement les rapports pour contourner un problème individuel sans examiner cette portée.
Reconnectez-vous avec le rôle de lecture concerné et vérifiez la vue restreinte obtenue. Le résultat attendu est la présence des services partagés et des informations prévues, sans droit de modifier la propriété Google. Cette voie ne donne pas accès aux données directement dans Google Analytics et ne remplace pas les droits nécessaires à une configuration du service.
Pour annuler, le gestionnaire revient dans Edit roles, désélectionne le rôle ajouté et utilise Apply. Rétablissez le choix initial sans réinitialiser tout le partage. Si la récupération du service est elle-même en panne pour son propriétaire, corrigez cette connexion : partager le tableau ne crée pas les données que le service ne renvoie pas.
Approche 3 : reconnecter seulement l’utilisateur dont l’autorisation est devenue invalide
Cette voie convient si les droits de propriété sont corrects mais que Site Kit signale une autorisation du compte devenue invalide. Gardez les références des services connectés et confirmez l’adresse Google attendue avant l’intervention. Une reconnexion personnelle et une déconnexion du module Analytics partagé ont des portées différentes.
Dans Site Kit → Dashboard, ouvrez la photo ou l’initiale du compte en haut à droite, puis choisissez Disconnect. La documentation distingue cette déconnexion utilisateur des actions qui retirent les extraits de code et les réglages du site. Elle permet de reprendre la connexion de ce compte sur ce site. Elle retire ses accès personnels aux services dans Site Kit ; prévoyez donc de les vérifier après le retour.
Utilisez ensuite le parcours de connexion Google proposé par Site Kit et choisissez le compte prévu. Examinez les autorisations demandées. Ne créez pas une nouvelle propriété pour terminer plus vite et ne supprimez pas toutes les connexions Site Kit depuis le compte Google : cette autre action peut affecter plusieurs sites.
Au retour, vérifiez les services, les références et les rapports avec ce même utilisateur. Le résultat attendu est un accès personnel restauré aux données déjà configurées. Si vous avez connecté un mauvais compte, déconnectez cet utilisateur et recommencez avec le bon ; un ancien jeton retiré ne se restaure pas en recopiant un réglage. Si les droits manquent toujours, revenez au parcours de propriété au lieu de répéter la connexion.
Traiter un quota ou une limitation sans multiplier les requêtes
Si la réponse mentionne un quota ou RESOURCE_EXHAUSTED, cessez les actualisations répétées du tableau. La Data API d’Analytics applique des limites liées notamment à la propriété, au projet et aux demandes simultanées. D’autres outils connectés à la même propriété peuvent contribuer à cette consommation. Une nouvelle autorisation utilisateur ne supprime pas automatiquement ces limites.
Conservez le message exact et le service concerné. Une erreur pendant la création d’un compte ou d’une propriété n’est pas nécessairement le même quota qu’une erreur de lecture de rapport. Le code HTTP seul ne suffit pas : certains services utilisent plusieurs codes selon la limite rencontrée. Suivez le délai ou les indications fournis plutôt qu’une durée universelle inventée.
Fermez les onglets de tableau ouverts inutilement et suspendez les actualisations manuelles pendant l’examen. Si plusieurs rapports externes interrogent la propriété très fréquemment, leur mainteneur doit comparer les fréquences, les plages demandées et la réutilisation des réponses. Le but est de réduire les demandes redondantes, sans désactiver la collecte du site.
Après le délai adapté au quota signalé, faites un seul contrôle. Le résultat attendu est le retour de la requête de rapport. Si la limite réapparaît immédiatement, transmettez la chronologie et les outils connus qui utilisent la propriété. Ne recréez pas des propriétés et des clés pour tenter de contourner la limitation.
Si la source fonctionne mais que le tableau reste bloqué dans WordPress
Ouvrez le tableau dans un profil de navigateur propre avec le même compte WordPress autorisé, puis comparez son chargement. Cela aide à isoler une extension de navigateur ou une donnée locale de session. Ne confondez pas ce contrôle avec une ouverture publique du tableau : les statistiques et leurs routes d’administration doivent conserver les permissions prévues.
Dans les outils de développement, ouvrez Network ou Réseau avant de recharger une seule fois. Sélectionnez la requête du tableau en échec et relevez son statut ainsi que sa réponse. Une page HTML de blocage ou de connexion à la place des données attendues oriente vers le parcours WordPress ou une protection devant le site. Une erreur explicite du service Google oriente vers ce service ou ses droits.
Si Console signale un fichier absent ou une erreur apparue après une mise à jour, transmettez le nom du fichier et les versions concernées au mainteneur. Une copie locale ancienne des ressources du tableau ne se corrige pas en supprimant les données Analytics. Ne purgez pas les tables du site ni tous les historiques du service pour renouveler un écran.
Une erreur de certificat ou de connexion sortante doit être corrigée dans l’environnement serveur. Ne désactivez pas la vérification TLS pour faire passer l’appel. Faites examiner l’hôte demandé, l’heure et l’erreur précise, puis contrôlez le même rapport. Le résultat utile est le retour des données avec leurs contrôles d’accès et une connexion chiffrée valide.
Éviter une réinitialisation qui modifie aussi la collecte
Reset Site Kit est une opération plus large que la réparation d’un droit personnel. La réinitialisation retire les préférences et les extraits de code placés par Site Kit, puis demande une nouvelle configuration. Si l’extension était le seul composant qui insérait une balise de mesure, son retrait peut interrompre de nouvelles remontées pendant cette reconfiguration.
La déconnexion d’un service dans Connected Services et la déconnexion d’un utilisateur depuis son menu ne doivent pas être confondues non plus. Avant toute action large, relevez les références, le propriétaire des connexions et l’emplacement des balises déjà utilisées. Ne désactivez pas un module partagé simplement parce qu’un seul utilisateur ne peut pas lire son rapport.
Une nouvelle propriété contient un autre historique. La choisir dans le tableau ne fusionne pas automatiquement les données de l’ancienne et peut également changer la configuration de collecte selon l’outil. Si la propriété prévue est supprimée ou son flux réellement indisponible, la décision de remplacement appartient à un plan de mesure vérifié avec l’équipe.
Le parcours de dépannage doit donc conserver la propriété et les balises tant qu’aucune preuve ne les met en cause. Une erreur API d’accès se répare d’abord à son niveau. Une réinitialisation éventuellement retenue doit disposer de ses références de reconfiguration et d’une validation de la collecte, sans être présentée comme un bouton universel de réparation.
Valider le retour d’un rapport identifiable
Revenez à Site Kit avec l’utilisateur qui rencontrait le problème. Vérifiez le service, la propriété et la période relevés au début, puis ouvrez une carte dont les données étaient déjà disponibles dans la source directe. Le résultat attendu est un rapport chargé sans l’erreur initiale, avec un périmètre cohérent.
Comparez les définitions des mesures avant d’exiger une égalité parfaite entre deux écrans. Une carte peut présenter une mesure ou un filtre différent du rapport ouvert dans Analytics. La période, le fuseau et le caractère provisoire des données récentes comptent également. Le retour d’un chiffre ne suffit pas à valider que vous regardez le bon site.
Si vous avez modifié des droits, contrôlez le compte concerné et vérifiez que les autres membres gardent leur accès prévu. Si vous avez utilisé une vue partagée, validez ses limites avec le rôle ciblé. Si une reconnexion personnelle a été nécessaire, vérifiez les autres services que cet utilisateur devait consulter dans Site Kit.
Conservez les corrections qui ont un effet établi et rétablissez les essais inutiles. Un contrôle de lecture du tableau ne nécessite pas de générer de fausses conversions, d’achats ou de visites en série. La collecte elle-même doit être examinée séparément si la comparaison avec la source a montré un manque réel de données.
Préparer un relais technique qui préserve l’historique
Si le rapport reste inaccessible, transmettez la version de Site Kit, le service touché, la référence de propriété, le compte concerné et l’heure de l’erreur. Ajoutez le résultat de la consultation directe, ainsi que le statut et le texte expurgé de la requête en échec. Indiquez si les autres utilisateurs du tableau rencontrent le même problème.
Le responsable pourra ainsi distinguer un accès retiré, une limite de requêtes et une réponse locale remplacée par une page de blocage. Ne partagez ni jeton ni export complet contenant les cookies de session. Une capture d’un tableau vide sans ses références aide beaucoup moins à préserver le bon historique.
- Données présentes à la source : examiner récupération et affichage dans WordPress.
- Propriété inaccessible au compte : rétablir les droits au niveau nécessaire.
- Vue de lecture souhaitée : utiliser un partage dont les rôles et la portée sont acceptés.
- Autorisation personnelle invalide : reconnecter cet utilisateur sur ce site.
- Limite API signalée : réduire les appels inutiles et suivre le quota concerné.
- Source réellement sans données attendues : ouvrir un diagnostic de collecte avant toute nouvelle propriété ou balise.
Lire trois réponses sans changer de propriété
Dans l’onglet Réseau, conservez uniquement le statut, le type de réponse et le nom du service. Masquez les cookies, les en-têtes d’autorisation et les identifiants avant de transmettre un relevé. Commencez par la propriété et la période relevées dans la source directe.
Sur une copie de WordPress, un compte lecteur a reçu un refus avant tout appel au service fictif. Pour le compte autorisé, le service local a successivement renvoyé un refus, une limite et un rapport disponible. Ce contrôle a vérifié le trajet de lecture et la distinction entre les erreurs. Les droits Google, les chiffres de votre propriété et l’état de la collecte se contrôlent dans votre propre service.
- Une réponse WordPress rest_forbidden oriente vers le rôle du compte sur le site ou les droits de partage du tableau. Vérifiez qui est censé lire ce rapport avant de modifier un accès.
- Un message PERMISSION_DENIED renvoyé par le service oriente vers les droits du compte sur la propriété. Comparez avec l’accès à la source directe. Si la réponse signale RESOURCE_EXHAUSTED, suivez plutôt les indications de délai et de quota.
- Après la correction, rechargez une seule fois et retrouvez une métrique identifiable sur la même période et la même propriété. Un statut 200 seul ne suffit pas. Un rapport vide, une page HTML ou les chiffres d’une autre propriété demandent des vérifications différentes.
