Dashboard SEO et GEO : les 9 blocs, et pourquoi trois ne donneront jamais le même total

On a lancé une SERP française sur « reporting seo », le mot-clé que cette page vise, pour voir ce qu'une API en rend vraiment. Google y sert un AI Overview complet, avec deux références. Les deux ressortent avec le même domaine : google.com, derrière une redirection google.com/goto?url=. Le nom réel des sources, YouTube et Semrush, n'existe que dans un champ texte à côté.

C'est un assez bon résumé de ce qu'est un tableau de bord qui couvre Google et les IA en 2026 : la donnée existe, elle est atteignable, et elle n'est jamais tout à fait celle qu'on croit lire.

Le 27 août 2026, on a sondé un par un les endpoints qui alimentent les neuf blocs de notre propre tableau de bord : neuf endpoints Google et huit endpoints DataForSEO, sur 16 propriétés Search Console et 43 propriétés GA4. Pour chacun, quatre questions : quelle fraîcheur, quel plafond, quelle latence, quel coût. Ce qui suit est le relevé, y compris les deux endroits où il nous a donné tort.

Trois blocs du même tableau, trois totaux différents

Commençons par le résultat le plus dérangeant, parce qu'il fissure la façon dont la plupart des tableaux de bord sont montés.

La Search Console rend un total quand on l'interroge sans dimension. Elle rend des lignes quand on groupe par requête, et d'autres lignes quand on groupe par page. Les trois ne tombent pas sur le même chiffre. On l'a mesuré sur 5 propriétés, sur les 28 jours clos du 28 juillet au 24 août 2026.

Sur vydera.com, grouper par requête ne laisse voir que 20,6 % des clics : 143 des 180 clics de la fenêtre n'apparaissent dans aucune ligne de requête. Sur une propriété du portefeuille, la même opération en montre 67,4 %. Google écarte les requêtes rares pour des raisons de confidentialité, et l'ampleur de ce filtre dépend du profil de trafic du site, pas d'un réglage que vous auriez raté.

Dans l'autre sens, grouper par page rend plus de clics que le total : de 100,5 % à 106,4 %, et jusqu'à 120,7 % des impressions. Chacun de ces cinq relevés tient en un seul appel, le dépassement ne vient donc pas d'une pagination mal recollée de notre côté.

Deux honnêtetés à poser tout de suite. n = 5 propriétés : c'est une fourchette observée, pas une loi, et cela n'a aucune valeur de test. Et le rapport entre clics visibles et impressions visibles s'inverse d'un site à l'autre : une propriété du portefeuille montre 46,6 % de ses clics mais 84,2 % de ses impressions, une propriété du portefeuille fait exactement le contraire. La relation n'est pas monotone, et notre mesure n'explique pas pourquoi. Même chose pour l'asymétrie de la dimension PAGE, faible sur les clics et forte sur les impressions : elle est mesurée, le mécanisme de déduplication qui pourrait l'expliquer ne l'est pas.

La conséquence opérationnelle, elle, n'a rien d'ambigu. Ne jamais afficher un total et un détail côte à côte sans dire de quelle dimension chacun sort. Le décideur qui additionne votre tableau des requêtes et le compare au grand chiffre du haut a raison de venir vous voir : c'est le tableau qui ment, pas lui.

Les neuf blocs, et d'où vient chaque donnée

Voici le tableau de bord tel qu'on le monte, bloc par bloc. Six tiennent sans rien débourser, sur les APIs Google. Trois passent par DataForSEO et sont facturés à l'appel. Chaque bloc ouvre l'appel exact, la fraîcheur mesurée, le plafond mesuré et la réserve à connaître avant de le brancher.

Deux absences volontaires. Le suivi de positions n'a pas de bloc à lui : les positions de votre propre site sont déjà dans la Search Console et ne coûtent rien. On n'achète un ranked_keywords que pour regarder un domaine qu'on ne possède pas. Et les Core Web Vitals de terrain n'y sont pas non plus : c'est le vrai trou de ce relevé, on y revient plus bas.

GA4 devance la Search Console de deux jours

La fraîcheur est le premier réglage à trancher, parce qu'elle décide de ce que vous affichez sur le graphique du haut.

Mesurée à l'identique sur une propriété du portefeuille et sur vydera.com, en prenant la dernière date présente dans une réponse groupée par DATE et non la dernière date à clics non nuls : la Search Console en dataState: final accuse 2 jours de retard. En dataState: all, elle en accuse zéro et sert la journée en cours.

GA4, lui, sert aussi la journée en cours : 0 jour de retard, 30 sessions déjà comptées le jour du relevé. Sur le même écran, GA4 devance donc la Search Console de deux jours.

Le piège est dans le all. La journée qu'il sert est forcément partielle : elle n'est pas finie. Un tableau de bord qui l'affiche sans le dire montre une chute quotidienne qui n'existe pas, et vous passerez un lundi matin à chercher une panne. La règle est simple : final pour toute courbe de tendance, all seulement si le dernier point est étiqueté « partiel ».

Dernier détail de fraîcheur, dans l'autre sens : la donnée s'arrête entre le 4 avril 2025, où l'API rend zéro ligne, et le 15 avril 2025, où elle en rend cinq. Soit environ 16 mois d'historique. Une comparaison à l'année sur 18 mois n'est pas possible par l'API, quel que soit votre outil.

Les plafonds qui mordent, et ceux qui n'existent pas

Un plafond documenté et un plafond mesuré sont deux choses différentes. Voilà ceux qu'on a réellement touchés.

• 25 000 lignes par appel, exactement. rowLimit: 25001 et 50000 renvoient tous deux un HTTP 400 « is not a valid row limit value ». La pagination par startRow prend ensuite le relais jusqu'à épuisement naturel : 25 354 lignes de requêtes en 2 appels sur une propriété du portefeuille.
• SEARCH_APPEARANCE ne se combine avec rien. « Cannot group by search appearance dimension together with another dimension. » Toutes les autres combinaisons passent, y compris les cinq restantes ensemble : DATE, QUERY, PAGE, COUNTRY et DEVICE dans le même appel.
• La donnée horaire est plafonnée à 231 heures. La dimension HOUR exige dataState: hourly_all, sinon HTTP 400. Et la fenêtre est bornée quoi que vous demandiez : 8 jours demandés rendent 199 heures, 12 jours et 20 jours rendent 231 heures dans les deux cas, soit environ 9,6 jours. DATE et HOUR ne se groupent pas ensemble.
• Sur l'inspection d'URL, la limite est la latence, pas le quota. 6 445 à 6 642 ms par appel, 6 549 ms de moyenne sur 3 appels. Épuiser le quota documenté de 2 000 par jour et par propriété demanderait 218 minutes en séquentiel, soit plus de trois heures et demie. Nous ne l'avons pas atteint et nous n'avons pas cherché à le faire : le brûler pour le confirmer aurait privé nos audits d'indexation du même quota.
• Le quota GA4 se lit dans la réponse. Avec returnPropertyQuota: true, l'API rend son propre compteur : 39 979 jetons restants sur l'heure pour la propriété, mais 13 979 seulement pour le projet. Sur un tableau de bord qui interroge 43 propriétés, c'est le plafond projet qui mord en premier, et il ne figure sur aucune page de doc que vous liriez avant de coder.

Un dernier, plus vicieux : l'inspection d'URL ne rend pas le même jeu de champs d'une URL à l'autre. Dix champs sur notre page d'accueil, cinq sur une URL jamais explorée, onze sur une page présente au sitemap, qui gagne au passage un bloc de résultats enrichis. Un tableau de bord qui suppose un schéma fixe casse précisément sur les URL qu'on a le plus envie d'inspecter. Et tant qu'à publier ce qui gêne : notre page /lab n'a jamais été explorée, et notre page de contact française l'a été pour la dernière fois le 11 juin 2026.

Le bloc sitemap, lui, se résume à un seul champ utile. lastDownloaded donne l'âge de la dernière lecture par Google : 10 jours sur vydera.com contre 2 jours sur une propriété du portefeuille, ce qui en dit plus long sur la fréquence d'exploration que n'importe quel graphique. Le champ indexed des contenus, lui, renvoie 0 partout : il n'est plus alimenté. Ne le branchez pas.

Le bloc citations IA existe. On attendait un trou, on a trouvé un prix.

Le plan de cet article disait : côté citations IA, il n'existe pas d'API publique équivalente à la Search Console, et c'est ce qui explique le tarif des outils GEO du marché. La mesure ne le confirme pas.

La version exacte est plus nuancée, et plus utile. Il n'existe pas d'API de première partie et sans frais : ni OpenAI, ni Anthropic, ni Perplexity ne vous ouvrent l'équivalent d'une Search Console sur leurs réponses. En revanche une API tierce le fait, elle fonctionne, et nous l'avons facturée pendant ce relevé.

• llm_mentions/target_metrics_lite rend un nombre de mentions et un volume de recherche IA pour un domaine : 0,101 $ l'appel. Sur une propriété du portefeuille, plateforme google, France et français : 6 mentions et 650 de volume de recherche IA. 10 entités par appel.
• chat_gpt/llm_scraper rejoue une recherche ChatGPT et rend les sources citées : 0,004 $ l'appel, 13,7 secondes de latence. Sur la requête testée, 6 sources citées, mais 0 résultat de recherche, 0 requête de fan-out et 0 entité de marque renvoyés, alors même que force_web_search était à true.
• serp/google/organic/live/advanced rend l'AI Overview complet : 0,0035 $ l'appel, un mot-clé, 2,9 secondes.

Le bloc citations IA n'est donc pas le trou du tableau de bord. Il est payant, il est bon marché, et il a deux murs qu'il faut connaître avant de vendre du suivi GEO en France.

Premier mur : la plateforme ChatGPT refuse la France. Avec platform: chat_gpt et location_code: 2250, la tâche revient en erreur 40501 « Invalid Field: 'location_code' », et l'appel n'est pas facturé. Seuls location_code: 2840 et language_code: en passent. Autrement dit, le suivi des mentions ChatGPT sur le marché français n'est pas disponible par cette voie. La plateforme google, celle des AI Overviews, accepte la France et le français sans broncher.

Second mur : les sources de l'AI Overview sont masquées. C'est le constat par lequel on a commencé. Sur « reporting seo » en France, l'item ai_overview revient entièrement chargé, avec ses deux références. Mais le champ domain de chacune vaut google.com et l'URL est une redirection. Un tableau de bord qui compte « notre domaine dans les références de l'AI Overview » en lisant domain comptera zéro pour l'éternité. Le nom réel de la source est dans le champ source, et c'est un libellé, pas un domaine.

Le bloc que personne ne branche, et qui ne coûte rien

Un bloc du tableau existe déjà chez vous et n'est presque jamais regardé : les référents IA dans GA4. Un runReport sur la dimension sessionSource, et vous avez les visites arrivées depuis une réponse d'assistant.

Sur vydera.com, 28 jours, 691 sessions réparties sur 22 sources : claude.ai 5 sessions, gemini.google.com 2 sessions. Aucune autre source IA détectée.

Sept sessions sur 691. Le chiffre est ridicule et on le publie tel quel, parce qu'il dit deux choses justes. La première : le signal existe, il est traçable, et il ne coûte rien à brancher. La seconde : 7 sessions n'ont aucune valeur de test, et personne ne devrait piloter quoi que ce soit dessus aujourd'hui.

Une précision qui compte pour la suite. GA4 mesure les visites venues d'une réponse IA, pas les citations sans clic. Ce n'est pas un substitut au suivi des citations, c'est l'autre bout de la chaîne : l'un mesure l'exposition, l'autre le résultat. Sur la lecture de votre site par les moteurs IA, on a traité la partie amont dans notre guide llms.txt.

Ce que ça coûte, et pourquoi notre propre ledger avait tort

Les trois blocs payants, à un appel chacun, un mot-clé et un domaine, reviennent à 0,132536 $ pour une relève : 0,0035 pour l'AI Overview, 0,101 plus 0,004 pour les mentions LLM, 0,024036 pour les backlinks. Ce chiffre est une addition de coûts mesurés, pas une projection. Nous n'avons pas extrapolé le coût mensuel d'un suivi de N mots-clés, et ce chiffre ne s'y prête pas : il faudrait une nouvelle mesure, sur le volume réel visé.

Le relevé entier, sept appels aux endpoints payants dont un refusé à zéro, a coûté 0,246736 $.

Et c'est ici que la mesure nous a donné tort. Notre propre ledger interne portait cet avertissement, écrit après un passage précédent : « ne pas se fier au tarif affiché, mesurer le solde avant et après ». Faux, sur les deux moitiés.

Sur les 7 appels, le champ cost de la réponse égale le delta de solde qui encadre l'appel, à la sixième décimale. Et le tarif publié dans /v3/appendix/user_data le reproduit exactement, à condition d'ajouter la composante per_result à la composante per_request : 0,1 + 0,001 × 1 = 0,101 pour les mentions, 0,024 + 0,000036 × 1 = 0,024036 pour les backlinks, 0,012 + 0,00012 × 10 = 0,0132 pour les mots-clés positionnés. L'écart du passage précédent s'explique sans supposer le moindre surcoût caché : une somme de tarifs per_request seuls sous-estime mécaniquement la facture dès qu'un endpoint facture aussi au résultat.

La seconde moitié de l'avertissement était pire. Pendant ce chantier, le solde a bougé de 0,09 $ entre deux relevés sans qu'aucun appel de notre script soit en cours, soit exactement le tarif d'un autre endpoint : le compte est partagé entre plusieurs projets. Un encadrement de solde avant et après une série d'appels n'attribue donc rien de fiable. C'est le champ cost de chaque réponse qui est l'instrument juste ; le solde ne sert qu'à le contrôler. Le ledger a été corrigé.

Ce qu'on n'a pas pu mesurer, et pourquoi on le dit quand même

Le vrai trou de ce tableau de bord n'est pas là où le plan l'annonçait. Ce sont les Core Web Vitals de terrain. Aucune clé API Google n'existe sur le poste : la variable prévue est déclarée et vide. CrUX renvoie donc un 403 « Method doesn't allow unregistered callers », et PageSpeed Insights un 429, son quota anonyme partagé étant déjà épuisé.

Il faut lire ça pour ce que c'est : deux échecs d'identifiant, pas un verdict sur ces APIs. CrUX fonctionne parfaitement avec une clé, nous n'en avions pas. Le trou se répare par un formulaire d'activation dans la console Google Cloud, pas par un abonnement. C'est le genre de nuance qu'un audit pressé transforme en « CrUX ne marche pas », et c'est faux.

Puisqu'on parle de rigueur, l'aveu qui va avec. Le premier passage de notre script rapportait une erreur CrUX « API key not valid ». Elle venait de notre propre code, qui collait une variable vide dans l'URL et envoyait ?key=null. L'erreur réelle est le 403. Le script ne joint plus le paramètre quand la clé est absente. Un bug de script avait failli devenir un fait publié, et c'est exactement de cette façon qu'un tableau de bord se met à mentir poliment pendant six mois.

Trois autres blocs restent hors de portée, et on préfère le dire que de les remplir approximativement :

• Les passages des crawlers IA sur le site. Webflow n'expose pas les logs serveur, et aucune API ne contourne ça.
• La part de voix dans les réponses IA suivie dans le temps. Vérifié à l'exécution : aucun projet de suivi n'existe aujourd'hui sur vydera.com. C'est une dette assumée, pas une limite technique.
• Bing Webmaster Tools. Aucune clé sur le poste, l'API n'a pas été appelée. Nous n'avons donc rien à en dire.

Refaire la mesure chez vous

Tout ce qui précède se rejoue avec un jeton OAuth en lecture seule sur la Search Console et sur GA4, et un compte DataForSEO pour les trois blocs payants. Le principe tient en une phrase : on sonde chaque endpoint isolément et on lit la réponse pour ses propres métadonnées, plutôt que de faire confiance à la documentation.

Trois règles qui nous ont évité de publier des chiffres faux.

1. Mesurer la fraîcheur sur la dernière date présente dans une réponse groupée par DATE, pas sur la dernière date à clics non nuls. La seconde vous fera croire à un retard qui n'existe pas, surtout sur un petit site. Et si l'API rend des lignes de date à zéro impression sur un type de recherche que vous n'utilisez pas, ce n'est pas une fraîcheur : c'est un tableau vide daté.
2. Un 403 ou un 429 n'est pas un résultat. C'est un identifiant manquant ou un quota partagé. Le noter comme tel, jamais comme un verdict sur l'API.
3. Le coût se lit dans la réponse, appel par appel. Pas au solde, surtout si le compte sert à plusieurs projets.

Sur le choix de ce qu'on met dans le tableau une fois les sources branchées, on a publié la grille ailleurs : quels KPI servent à décider, et comment traduire tout ça en euros sans mentir. Pour les définitions, l'entrée webmaster tools du glossaire pose le vocabulaire. Et si vous préférez que ce soit branché, mesuré et relu par quelqu'un d'autre, c'est ce que fait notre offre de suivi de performance.