gsc-toolkit — l'outil qui surveille 60 sites sans personne devant l'écran
Un outil interne du groupe : 1 068 753 lignes de données Search Console, 114 propriétés Google et 120 propriétés Bing, et deux rapports hebdomadaires qui s'envoient seuls chaque lundi matin.
Durée
Développement continu depuis fin août 2026, 16 commits au 8 septembre 2026
Équipe
1 experts
Technologies clés
1 068 753
Lignes dans la table requête × page de la base SQLite
114
Propriétés Google Search Console suivies quotidiennement
120
Propriétés Bing Webmaster Tools vérifiées et suivies
2
Rapports hebdomadaires envoyés automatiquement chaque lundi (par site et de parc)
#Le problème : soixante sites, un seul regard possible à la fois
Le groupe opère un parc de plusieurs dizaines de sites — réseau d'acquisition locale, sites d'export, produits internes — chacun avec sa propre propriété Search Console et, pour la plupart, sa propre propriété Bing Webmaster. Consulter chaque propriété une par une pour savoir ce qui bouge n'est pas une tâche qu'un humain répète chaque semaine sur soixante sites : la donnée existe, mais personne ne la regarde tant qu'il faut l'aller chercher.
Deux problèmes distincts se posaient. Le premier est le volume : consulter soixante propriétés Search Console à la main, chacune avec son propre historique, ne laisse voir qu'un instantané et jamais une tendance comparée à la semaine précédente. Le second est la qualité de la donnée elle-même : une vérification sur nehos-groupe.com a montré qu'une position moyenne de 1,2 sur une requête pouvait recouvrir dix-neuf affichages déclenchés par des robots — des outils de suivi ou des agents IA interrogeant Google avec des variables de gabarit non substituées dans la requête elle-même. Un tableau de positions qui ne distingue pas un humain d'un robot n'est pas un tableau de bord, c'est du bruit habillé en chiffres.
#Ce qui a été construit
L'outil collecte chaque nuit les données de perf_page et perf_qp (requête × page) sur les 114 propriétés Google via l'API Search Console, et interroge l'API Bing Webmaster Tools sur les 120 propriétés vérifiées côté Bing — gratuite, elle donne des volumes de recherche que Google ne fournit jamais sans dépense publicitaire. Tout est stocké dans une base SQLite locale : pas de flux brut qui transite dans une fenêtre de contexte, seulement des agrégats calculés à la demande. Deux rapports partent chaque lundi par e-mail via Brevo : le rapport par site détaille les requêtes de la semaine avec leur évolution de position, les opportunités en position 4-20 où un titre réécrit change tout, les pages très vues sans un clic, et l'indexation par section. Le rapport de parc couvre tous les sites suivis, classés non par taille mais par ce qui a le plus bougé — un clic gagné ou perdu pèse plus que le volume brut. Un filtre écarte les requêtes qui ne viennent pas d'un humain (variables de gabarit {{brand}}, balises de contexte, questions de plus de douze mots) et signale toute position bâtie sur moins de trente affichages comme statistiquement peu fiable. Côté Bing, l'outil soumet aussi les URL des sitemaps par lot — jusqu'à 10 000 par jour et par site, un quota qui varie fortement d'un domaine à l'autre et qu'il faut lire avant d'envoyer, sous peine de voir un lot entier rejeté.
#La méthode
Le développement a procédé par itérations hebdomadaires, chaque fonctionnalité déclenchée par un usage réel plutôt que par une liste de fonctionnalités décidée à l'avance : le rapport de parc est né du besoin de ne pas envoyer soixante e-mails, le filtre anti-robots est né d'une anomalie repérée en production sur nehos-groupe.com elle-même, la soumission Bing consciente du quota est née d'un lot de 500 URL rejeté en bloc sur un site qui n'en acceptait que 96 par jour. Chaque comportement nouveau est couvert par un test unitaire avant d'être considéré comme fait, conformément à la doctrine du groupe de tester systématiquement toute nouvelle logique.
#Ce que ça change concrètement
Avant l'outil, savoir qu'une position de tête sur une requête ne pesait rien demandait de croiser manuellement les affichages jour par jour dans l'interface Search Console — personne ne le fait sur soixante sites, une fois, encore moins chaque semaine. Aujourd'hui, le filtre tourne seul et le rapport arrive déjà nettoyé. La différence se voit dans les chiffres eux-mêmes : sur nehos-groupe.com, vingt requêtes affichaient une position de première page avant le filtre ; une seule restait après — la requête de marque, appuyée sur cinquante-sept affichages réels. Les dix-neuf autres reposaient sur un à huit affichages, largement compatibles avec du bruit ou des robots.
Le même principe s'applique à la soumission d'URL vers Bing : annoncer un succès sans vérifier le quota du site produirait un rapport flatteur et faux. L'outil lit le quota réel, plafonne dessus, et dit explicitement ce qui reste en attente plutôt que de le taire.
#Ce que ça prouve pour une mission d'agence
Cette réalisation est un suivi mensuel de visibilité GEO/AEO appliqué à nous-mêmes avant d'être proposé en mission. Le principe qui la sous-tend — ne jamais confondre un signal et sa mesure, publier ce qui ne va pas avec ce qui va — est le même que celui qui a produit nos outils gratuits et notre réseau de 50 sites locaux : le GEO (Generative Engine Optimization) ne se pilote pas à l'instinct, il se pilote avec une base de données propre et une lecture honnête de ce qu'elle contient.
Si votre agence IA actuelle vous montre un tableau de positions sans jamais mentionner combien d'affichages les soutiennent, la question à poser est simple : combien de ces chiffres résisteraient au même filtre ?
L'essentiel
gsc-toolkit est un outil interne du groupe qui collecte chaque nuit les données de 114 propriétés Search Console et interroge l'API Bing Webmaster sur 120 propriétés, dans une base SQLite locale qui totalise 1 068 753 lignes au 8 septembre 2026.
Il produit et envoie par e-mail deux rapports hebdomadaires sans intervention : un rapport détaillé par site (requêtes, positions en page 1, opportunités en position 4-20, pages très vues sans clic) et un rapport de parc qui couvre l'ensemble des sites suivis, classés par ce qui a le plus bougé dans la semaine.
Le code source fait 1 507 lignes réparties sur quatre modules, couvertes par 138 tests unitaires, avec un historique de 16 commits depuis sa création.
Questions fréquentes sur cette réalisation
Parce que le problème réel n'était pas le suivi de position mais le pilotage d'un parc entier avec une donnée fiable. La plupart des outils du marché facturent par propriété suivie, ce qui devient coûteux à l'échelle de soixante sites, et aucun ne filtre nativement les requêtes générées par des robots ni ne croise Google et Bing dans un même rapport de parc. Construire l'outil a permis d'adapter exactement le filtre anti-robots à ce que nous observions sur nos propres données, et de le faire évoluer en quelques heures quand un nouveau cas apparaissait — comme le filtre de fiabilité statistique, ajouté après avoir constaté qu'une position affichée à 1,2 pouvait reposer sur dix-neuf affichages.
En cherchant les traces que laisse un gabarit de prompt mal nettoyé : une variable non substituée comme {{brand}}, une balise <context>, la mention littérale company url:. À cela s'ajoute un critère de forme — une question de plus de douze mots relève d'un prompt, pas d'une recherche tapée dans une barre d'adresse. Sur nehos-groupe.com, ce filtre a fait passer le nombre de positions de première page considérées comme fiables de vingt à une seule, la requête de marque elle-même.
L'outil lit le quota propre au site avant d'envoyer — il varie de 96 URL par jour pour un domaine récent à 10 000 pour un domaine établi — et plafonne le lot à ce quota plutôt que de l'ignorer. La première version ne le faisait pas : un lot de 500 URL envoyé à un site qui n'en acceptait que 96 par jour était rejeté en totalité par l'API, avec un message d'erreur qui n'indiquait pas la vraie cause. Le reliquat non soumis est annoncé dans les journaux et repris le jour suivant par une tâche planifiée, sans jamais forcer le quota.
Parce qu'ils répondent à deux questions différentes. Le rapport par site sert à optimiser un domaine précis : quelles requêtes progressent, quelles pages sont vues sans être cliquées, quelles opportunités sont à portée de main. Le rapport de parc sert à répartir l'attention sur soixante sites : il classe par ce qui a bougé — un clic gagné ou perdu, une progression d'indexation — plutôt que par volume brut, pour qu'un petit site qui décolle ne soit pas noyé sous le plus gros site du parc.
Le code n'est pas packagé comme un produit commercial autonome pour l'instant : c'est un outil interne, construit pour un usage interne. La méthode, en revanche, est directement mobilisable en mission — c'est elle qui alimente notre offre de suivi GEO mensuel : collecte automatisée, filtrage des faux signaux, rapport qui arrive sans qu'on ait à aller le chercher.