Les données SEO ne sont vraiment utiles que lorsqu’elles conduisent à une décision. Google Search Console et Bing Webmaster Tools affichent les clics, les impressions, le taux de clics et la position moyenne. Je voulais cependant un processus reproductible qui transforme ces chiffres en tâches concrètes : pages à améliorer, articles à écrire, liens à ajouter et anciennes URL à migrer.

C’est pour répondre à ce besoin que j’ai créé le projet open source GSC + Bing to Obsidian SEO Pipeline. Cet outil en ligne de commande, écrit en TypeScript, collecte les performances de recherche et transforme un coffre Obsidian en base de connaissances SEO exploitable.

Pourquoi j’ai créé ce projet

Je gère plusieurs propriétés de recherche : un site principal, du contenu complémentaire et d’anciennes propriétés qui conservent parfois un historique précieux. Consulter chaque tableau de bord séparément empêche de voir clairement les relations entre ces sources.

Je voulais répondre à des questions directement opérationnelles :

  • Quelles requêtes non liées à la marque sont déjà classées entre les positions 5 et 20 ?
  • Quelles pages obtiennent beaucoup d’impressions, mais un faible CTR ?
  • Depuis quel article de blog faut-il créer un lien vers une page principale ?
  • Plusieurs pages sont-elles en concurrence sur la même intention de recherche ?
  • Une ancienne propriété se positionne-t-elle encore sur des requêtes qui méritent d’être migrées ?

Je souhaitais également conserver les données brutes. Chaque recommandation doit pouvoir être reliée à une requête, une page, une période et des métriques précises.

Le fonctionnement du pipeline

Le pipeline suit quatre grandes étapes.

1. Lire les propriétés configurées

Chaque propriété est définie comme une source avec un identifiant, un libellé, une URL, un type et, si nécessaire, une expression qui identifie les requêtes de marque. Le type permet de distinguer un site principal, un blog, un ancien domaine ou toute autre source.

Les informations sensibles restent locales. Les identifiants, clés API, chemins du coffre et véritables fichiers de sources sont exclus de Git. Des fichiers d’exemple sûrs expliquent la configuration attendue.

2. Récupérer les données quotidiennes

Pour Google, le CLI interroge l’API Search Console afin de produire plusieurs vues : requêtes, pages, couples requête-page, pays, appareils et lignes datées. La pagination s’effectue par lots de 25 000 lignes.

Une période est téléchargée jour par jour. Le pipeline crée ainsi des instantanés quotidiens vérifiables, puis les agrège en jeux de données par période et par année. Le CTR et la position moyenne pondérée sont recalculés à partir des impressions, ce qui évite de moyenner des moyennes.

La dernière mise à jour ajoute Bing Webmaster Tools. Comme son API est différente, un adaptateur récupère les statistiques des requêtes, des pages et des relations page-requête avant de les normaliser dans les mêmes colonnes principales. Chaque ligne indique son moteur de recherche. Les résultats restent séparés dans SEO/GSC/ et SEO/Bing/ afin de pouvoir les comparer sans les mélanger par erreur.

3. Conserver les fichiers CSV bruts

Chaque export contient la source, le moteur, les dimensions, les clics, les impressions, le CTR, la position moyenne et la période. Les jeux comportant une requête reçoivent aussi une version hors marque, construite à partir de l’expression configurée pour la source.

Le coffre Obsidian devient à la fois une archive et un espace de travail :

SEO/
  GSC/
    sources/<source-id>/raw/daily/
    sources/<source-id>/raw/ranges/
    sources/<source-id>/raw/yearly/
    sources/<source-id>/reports/
    sources/<source-id>/ideas/
    combined/
  Bing/
    sources/
    combined/

Ces niveaux quotidien, périodique et annuel permettent d’étudier une date, une campagne ou une année entière dans un tableau croisé dynamique.

4. Transformer les métriques en actions

La couche d’analyse exclut les requêtes de marque lorsque le filtre est configuré et recherche deux signaux principaux :

  • les couples requête-page avec beaucoup d’impressions et un CTR inférieur à 2 % ;
  • les requêtes ayant au moins 50 impressions et une position comprise entre 5 et 20.

Le pipeline génère ensuite des rapports Markdown et des fichiers d’idées prêts à être utilisés avec une IA : gains rapides, faible CTR, possibilités de classement et nouveaux articles. Chaque idée indique la page classée, son intérêt, l’action suggérée, sa priorité et les métriques d’origine.

L’analyse combinée cherche aussi les liens internes possibles entre blog et site principal, les candidats à une migration, les requêtes partagées et les signes de cannibalisation. La combinaison source + requête + page sert de clé stable : une nouvelle exécution actualise une idée existante au lieu de la dupliquer.

Les commandes que j’utilise

Je peux d’abord vérifier les accès sans télécharger de données :

pnpm gsc:verify
pnpm bing:verify

Je peux ensuite récupérer les 30 derniers jours pour toutes les sources actives :

pnpm gsc:pull -- --all --last-days 30
pnpm bing:pull -- --all --last-days 30

L’analyse locale reconstruit les rapports à partir des fichiers déjà présents dans Obsidian, sans nouvel appel à Google :

pnpm gsc:analyze -- --all --from 2026-06-01 --to 2026-06-30
pnpm gsc:rebuild

Cette séparation permet de faire évoluer indépendamment la collecte, le stockage et l’analyse. Modifier un filtre de marque ne nécessite pas un nouveau téléchargement depuis l’API.

L’évolution du projet

J’ai créé la première version fonctionnelle le 25 juin 2026. Elle prenait déjà en charge l’authentification Google, la collecte, les exports CSV, les rapports Markdown, l’analyse locale et les observations combinées entre sources.

Le 30 juin, j’ai déplacé les véritables définitions dans un fichier local gsc-sources.json ignoré par Git, amélioré les exemples et les instructions, puis ajouté l’illustration d’architecture utilisée dans cet article. Le dépôt est ainsi devenu plus sûr à partager et plus simple à comprendre.

Le 12 juillet, j’ai étendu le pipeline à Bing Webmaster Tools. Cette mise à jour apporte des commandes de vérification et de collecte séparées, un adaptateur pour l’API Bing, un stockage qui tient compte du moteur et des sorties compatibles pour les dimensions disponibles. Les fichiers vides sont volontairement conservés lorsque Bing n’a aucune ligne ou ne fournit pas l’équivalent d’une dimension Google : ils constituent une trace d’audit au lieu de masquer une absence de résultat.

Ce que j’ai appris

La partie la plus précieuse du projet n’est pas la connexion à l’API, mais le modèle de données construit autour d’elle.

Les instantanés quotidiens rendent les reconstructions possibles. Les métadonnées de sources permettent l’analyse croisée. La séparation entre données brutes et dérivées préserve la confiance. Les clés stables rendent l’automatisation répétée gérable. Enfin, Markdown produit un résultat lisible par moi, consultable dans Obsidian et utilisable par des outils d’IA sans enfermer le processus dans un tableau de bord supplémentaire.

Le pipeline reste volontairement local et basé sur des fichiers. Je peux ouvrir chaque CSV, vérifier chaque recommandation, modifier le code et reconstruire la base. Pour mon processus de travail, c’est précisément son intérêt.

Le code source et le guide d’installation sont disponibles sur GitHub.