Pourquoi nous avons automatisé tout l'écosystème Google (et ce que ça change pour vos résultats)
La plupart des agences SEO passent leurs journées dans des interfaces web. Search Console dans un onglet, Google Business Profile dans un autre, Google Tag Manager dans un troisième, GA4 quelque part. On ouvre, on clique, on attend. Chez Chappygo, on a arrêté.
On a construit quatre outils en ligne de commande qui parlent directement aux API Google. Au lieu de cliquer, on lance une commande. Au lieu de refaire la manipulation sur quinze clients, on scripte une fois. Ce texte explique pourquoi, comment la stack est bâtie, et ce que ça change pour un client qui signe avec nous plutôt qu'avec une agence qui travaille à la souris.
Sommaire
- Le problème des agences qui font tout à la main
- Les 4 outils qu'on a construits en interne
- Pourquoi on ne vend pas ça comme de la magie
- Ce que ça change concrètement pour vos résultats
- Les limites de l'automatisation
- Retour d'expérience : pourquoi chaque outil existe
- FAQ
Le problème des agences qui font tout à la main
Capsule. Une agence moyenne passe plusieurs heures par semaine à cliquer dans les interfaces Google pour des tâches répétitives (indexation, avis GBP, setup GA4, reporting). Chappygo a codifié ces tâches en scripts. Le gain redonne du temps pour le travail de fond, celui qui fait vraiment progresser un client en SERP.
Quand on regarde le workflow moyen d'une agence SEO classique, le schéma est répétitif. Un consultant passe quarante minutes à indexer trente URLs dans Search Console après une vague de publication. Un autre refait la même chose sur Google Business Profile pour répondre à douze avis. Un troisième configure GA4 à la main pour le quinzième client de l'année. Chaque action est simple, mais leur somme devient une taxe invisible.
Le pire, c'est que personne ne paie une agence pour cliquer sur "Demander l'indexation". On paie pour le contenu de fond, la stratégie de cocons, l'analyse d'un client qui stagne en position 8. Pourtant, ce travail passe en dernier, noyé sous les tâches mécaniques.
Voici le tableau qu'on a dressé avant de construire les outils.
| Tâche | Approche manuelle classique | Approche Chappygo |
|---|---|---|
| Indexer 50 URLs après une publication batch | ~40 minutes, erreurs d'URL possibles, pas de log | Une commande, traçable, exécutable en série |
| Répondre à 20 avis GBP | Session navigateur, copier-coller, risque d'incohérence | Script batch avec garde-fou anti-double-post |
| Configurer GA4 + GTM lead tracking sur un nouveau client | 30 à 60 minutes par site, erreurs de trigger fréquentes | Une commande idempotente, vérifiable |
| Reporting mensuel multi-clients | Onglets Excel à jongler entre 10 outils | Script Python qui agrège les sources |
Le coût caché du travail manuel
Le vrai problème n'est pas que ces tâches prennent du temps. C'est qu'elles le prennent à des gens payés pour faire un travail plus utile. Une heure passée à cliquer dans Search Console, c'est une heure qu'on ne passe pas à écrire un article de fond ou à comprendre pourquoi telle page ne convertit pas.
Il y a un second effet. Quand une tâche est pénible, on la repousse. On sait qu'on devrait vérifier l'indexation de ce client, mais l'idée d'ouvrir Search Console, copier chaque URL, cliquer, attendre, recommencer, nous dissuade. Trois mois plus tard, on a cinquante URLs en attente et un client impatient. La friction manuelle génère de la dette opérationnelle.
Les 4 outils qu'on a construits en interne
Capsule. Chappygo dispose de quatre scripts Python qui couvrent l'écosystème Google : gsc-cli (Search Console), gmb-cli (Business Profile), gtm-ga4-cli (Tag Manager + GA4), et dashboard.py (reporting agrégé). Chacun remplace une interface web par une commande reproductible.
| Outil | À quoi ça sert | Ce que ça remplace | Bénéfice direct |
|---|---|---|---|
gsc-cli | Indexation d'URLs, soumission de sitemaps, top queries, inspection d'URL | Interface web Search Console | Indexation batch de 50+ URLs en une commande |
gmb-cli | Comptes, localisations, avis, réponses, posts | Interface web Google Business Profile | Réponses et posts en série, traçables |
gtm-ga4-cli | Configuration du lead tracking dans GTM + GA4 | Setup manuel (1h+ par client) | Une commande idempotente, vérifiable |
dashboard.py | Agrégation mensuelle de tous les indicateurs clients | Onglets Excel entre dix outils | Score SEO/GEO instantané par client |
gsc-cli, l'outil qu'on utilise tous les jours
gsc-cli parle à l'API Google Search Console et couvre les opérations qu'on fait après chaque publication ou refonte : indexer une URL, soumettre un sitemap, inspecter une page, lire les top queries et top pages sur 30 jours, détecter les URLs vieilles qui traînent encore dans l'index.
La commande qu'on lance le plus est l'indexation en batch. On lui passe un fichier texte avec 50 URLs, elle itère, logge les succès, garde les échecs dans un .pending.txt pour reprise ultérieure. Le quota Google Indexing API est de 200 publish requests par jour et par projet Cloud, documenté officiellement par Google (voir developers.google.com). Quand on dépasse, le script sauvegarde et reprend le lendemain.
gmb-cli, pour les fiches locales
gmb-cli couvre Google Business Profile. Lister les comptes et localisations, lire les avis et la note moyenne, répondre à un avis, programmer un post. Sans lui, chaque intervention sur une fiche locale passe par l'interface web Google, qui est lente et qui change de design tous les six mois.
L'outil devient intéressant sur le travail en série. On traite cinq fiches clients, on répond à trente avis, on programme trois posts depuis un terminal. Chaque action est loggée, ce qui évite les doubles réponses et permet de relire ce qui a été dit à un client six mois plus tard.
gtm-ga4-cli, né d'un vrai cas client
gtm-ga4-cli est l'outil le plus récent. Il configure le suivi de conversion generate_lead dans Google Tag Manager et GA4 sans passer par le navigateur. Il crée le trigger CUSTOM_EVENT, le tag GA4 correspondant, publie une version, et marque l'événement comme clé dans GA4. Le tout de façon idempotente : si on relance, rien ne se duplique.
L'authentification réutilise le même client OAuth que gsc-cli. Il faut juste ajouter deux scopes (tagmanager.edit.containers et analytics.edit) sur le projet Cloud Console (voir cloud.google.com). Une fois configuré, on peut setter le lead tracking sur un nouveau client en moins de cinq minutes.
dashboard.py, le tableau de bord interne
dashboard.py est à part. Ce n'est pas un client d'API Google, c'est un agrégateur. Il scanne le dossier client, compte les articles, lit les scores SEO/GEO dans les fichiers d'audit, vérifie la présence des fichiers de stratégie (REGLAS, KEYWORD-MAP, CONTENT-CALENDAR), et croise avec trois sources externes : PageSpeed Insights via l'API officielle, les totaux GSC 30 jours via gsc-cli, et un cache GEO manuel.
Avant, le reporting mensuel multi-clients demandait une demi-journée de jonglage entre dix outils. Maintenant, une commande régénère le tableau de bord complet. Le gain n'est pas tant le temps que la fiabilité : on ne peut plus oublier un client dans le rapport.
Pourquoi on ne vend pas ça comme de la magie
Capsule. Ces outils ne sont pas de l'IA. Ce sont des scripts Python qui appellent des API documentées. La valeur est dans le fait de les avoir écrits, pas dans une prétendue sophistication technique.
Il faut le dire clairement, parce que le marché est saturé de promesses. Ces quatre outils ne sont pas de l'intelligence artificielle. Ils n'apprennent rien, ne génèrent rien, ne décident rien. Ce sont des scripts Python qui appellent des API publiques documentées par Google. La valeur n'est pas dans la sophistication du code, qui reste lisible. Elle est dans le fait qu'on a pris la peine de les écrire, de les maintenir, et de les utiliser tous les jours.
De l'ingénierie de processus, pas de l'IA magique
La différence avec une agence qui brandit le terme "IA" à tout bout de champ, c'est qu'on ne cache pas le processus. Les CLIs sont décrits, leurs limites sont connues, et on peut expliquer à un client technique exactement ce qui se passe quand on lance une commande. Pas de boîte noire : un script, une API, un quota, un fichier de log.
Cette transparence a une vertu commerciale concrète. Quand un client demande "comment vous avez fait pour indexer ces 50 URLs en deux heures", on montre la commande, le log, la queue .pending.txt pour les URLs restantes. Le client voit ce qu'il paie.
On écrit plus en détail sur la méthodologie globale dans notre page services SEO/GEO et dans la méthode SEO/GEO détaillée. L'automatisation n'est qu'un pilier, le plus visible, pas le plus important.
Ce que ça change concrètement pour vos résultats
Capsule. Trois effets pour le client : réactivité (une URL indexée en heures plutôt qu'en semaines), reproductibilité (le même processus appliqué à tous les clients), et reporting (un tableau de bord lisible plutôt que dix exports Excel).
Réactivité
Quand on publie un article chez un client, l'URL est soumise à l'indexation dans la foulée. Pas le lendemain, pas la semaine prochaine quand le consultant aura le temps d'ouvrir Search Console. Google fait ce qu'il veut du reste, mais on ne perd pas la fenêtre de crawling par négligence.
Idem quand une page est refondue. On pousse la nouvelle version, on soumet l'URL, on vérifie le canonical, on inspecte l'état dans GSC. Trois commandes, traçables. Sans automatisation, ces vérifications sautent dès que la charge client monte.
Reproductibilité
Le second bénéfice, c'est que le processus est identique pour tous les clients. Pas de variabilité selon l'humeur du consultant, pas d'étape oubliée vendredi soir. Quand on a quinze clients en production, cette régularité maintient la qualité moyenne.
C'est aussi ce qui permet d'onboarder un nouveau client vite. La stack est prête, on branche la propriété Search Console, on configure le lead tracking en une commande, on génère le premier rapport. Le temps de démarrage, celui qui coûte cher en agence classique, est comprimé.
Reporting
Le reporting mensuel est l'endroit où le client voit la différence le plus vite. Plutôt qu'un Excel bricolé avec des chiffres copiés depuis quatre outils, on génère un tableau de bord actualisé qui croise les vraies sources. Si un chiffre manque (GA4 pas connecté), il est marqué "en attente" plutôt qu'inventé. La règle interne est stricte : on ne met jamais un chiffre non vérifié dans un livrable client.
Pour creuser la mécanique, on a écrit un comparatif GA4, Search Console, Clarity et GTM qui explique ce que chaque outil mesure.
Les limites de l'automatisation
Capsule. Automatiser ne remplace ni la stratégie, ni le contenu, ni la relation client. Ça libère le temps qu'on passe sur ces trois piliers.
L'automatisation ne remplace pas le jugement. Elle ne choisit pas les mots-clés d'un cocon sémantique. Elle ne décide pas si un article doit faire 1 400 ou 2 200 mots. Elle ne sait pas si tel client B2B a intérêt à viser "industriel" plutôt que "PME". Ce qu'elle fait, c'est libérer le temps qu'on passe sur ces décisions-là.
Voici ce que la stack ne fait pas :
- Ça ne remplace pas la stratégie. Le choix des silos, l'analyse SERP, l'identification du bon mot-clé pour le bon buyer persona restent un travail humain. Les CLIs n'ont pas d'opinion sur le positionnement.
- Ça ne remplace pas le contenu. Aucun script ne produit un article de 2 000 mots avec un retour d'expérience vérifié et des sources citées. La rédaction reste le coeur du métier.
- Ça ne remplace pas la relation client. Les outils ne font pas la réunion mensuelle, ne répondent pas au mail anxieux, ne négocient pas les priorités.
- Ça ne corrige pas un site mal construit. Si le WordPress est hacké, si le Next.js est mal render en SSR, si le robots.txt bloque les bots utiles, aucun script ne sauve la situation.
Une dernière limite, technique. Les API Google changent. Des scopes sont dépréciés, des quotas évoluent, des fonctionnalités disparaissent. La stack demande de la maintenance régulière. Une agence qui ne maintient pas ses outils finit avec des scripts cassés qui font plus de mal que de bien.
Retour d'expérience : pourquoi chaque outil existe
Capsule. Aucun des quatre CLIs n'est né d'une idée théorique. Chacun répond à un problème réel rencontré sur un client ou sur le fonctionnement interne.
gsc-cli, né d'un besoin d'indexation en masse
Le scénario fondateur de gsc-cli est un pic de publication. À un moment de l'année 2026, on a publié cinquante et un articles d'un coup pour un client, en réponse à un problème de désindexation massif. Cinquante et une URLs à pousser dans Search Console. À la main, c'était quarante minutes de copier-coller avec le risque d'en oublier la moitié.
On a écrit le script en une après-midi. Premier run, cinquante et une URLs en moins d'une minute de travail effectif (le runtime est plus long à cause des quotas Google, mais le travail humain est nul). Le script est devenu l'outil qu'on lance après chaque publication, même pour une seule URL, parce que taper une commande n'est pas plus long que d'ouvrir l'interface web.
gmb-cli, né du besoin de répondre aux avis en série
gmb-cli est né d'un problème plus discret. On avait cinq fiches Google Business Profile à gérer, avec une trentaine d'avis non répondus cumulés. Le faire à la main demandait deux heures à basculer entre les fiches et à copier-coller des réponses en adaptant le ton.
On a écrit le script. Maintenant, la lecture des avis est scriptée (sortie JSON), et la réponse se fait en une commande par avis. On a aussi ajouté un mode "lecture seule" pour les fiches où le client répond lui-même, parce qu'on a appris à nos dépens qu'il faut demander avant de répondre à la place d'un dirigeant.
gtm-ga4-cli, né d'un client (Educasium)
gtm-ga4-cli a une origine très spécifique : un client, Educasium, dont le formulaire de contact poussait les leads vers HubSpot mais restait invisible pour GA4. Aucune conversion n'était remontée. Le tag de conversion n'était pas configuré. Pour un client qui paie pour savoir d'où viennent ses leads, c'était un trou noir.
Plutôt que de configurer le tag à la main (30 à 60 minutes, risque d'erreur), on a écrit une commande qui crée le trigger CUSTOM_EVENT, le tag GA4 associé, publie la version GTM, et marque l'événement comme clé dans GA4. Première exécution : cinq minutes. Standard de l'onboarding depuis.
dashboard.py, né de la douleur du reporting mensuel
dashboard.py a eu l'effet le plus grand sur l'organisation interne. Avant lui, le reporting mensuel demandait une demi-journée par vague de clients, à jongler entre exports Search Console, captures PageSpeed Insights, fichiers Excel, et comptage manuel des articles. On oubliait la moitié des chiffres (on n'en inventait aucun), mais le résultat était inégal d'un mois sur l'autre.
Le script scanne désormais tout seul : comptage d'articles, présence des fichiers de stratégie, scores SEO/GEO des audits, PageSpeed mobile via l'API, totaux GSC 30 jours via gsc-cli. Le rapport généré est cohérent, comparable d'un client à l'autre, produit en une commande. Le temps gagné est investi dans l'analyse, pas dans la collecte.
FAQ
Vos outils sont-ils compatibles avec n'importe quel site ?
Les CLIs parlent aux API Google, pas au site. Ils fonctionnent dès qu'on a un accès Search Console, GBP, GTM ou GA4 sur la propriété du client. Le CMS sous-jacent (WordPress, Next.js, Wix, Shopify) n'a pas d'importance. Pour le lead tracking, il faut que le formulaire pousse un événement JavaScript exploitable, ce qu'on vérifie au cas par cas.
Faut-il être technique pour travailler avec vous ?
Non, c'est le contraire. Les outils sont techniques, mais pensés pour que le client n'ait pas à le devenir. Vous recevez un reporting lisible, vous validez une stratégie, vous voyez les positions bouger. La stack interne est notre problème, pas le vôtre.
Pourquoi ne pas utiliser les outils existants du marché ?
On en utilise certains pour d'autres usages (DataForSEO pour la recherche de mots-clés). Mais sur l'écosystème Google, les outils du marché sont soit trop génériques, soit trop chers, soit fermés. Construire en interne permet d'adapter la stack au workflow de l'agence, de garder le contrôle sur les quotas, et de ne pas dépendre d'un éditeur qui peut changer sa grille tarifaire du jour au lendemain.
L'automatisation réduit-elle la qualité ?
Si elle est mal pensée, oui. Un script qui pousse cinquante URLs sans log ni vérification peut faire plus de mal que de bien. La règle interne est qu'un humain valide ce que le script exécute : on décide quelles URLs indexer, on relit les réponses aux avis, on contrôle le contenu des posts GBP. L'automatisation accélère l'exécution, elle ne supprime pas le contrôle.
Les outils sont-ils open source ?
Pas encore. On a une philosophie open-source mindset (documentation publique des patterns, partage des apprentissages), mais le code reste interne pour l'instant. Ça pourrait changer si la stack se stabilise et qu'on prend le temps de la documenter pour un usage externe.
Que se passe-t-il si une API Google change ?
Ça arrive régulièrement. Un scope est déprécié, un endpoint change de format, un quota évolue. On surveille les annonces Google Developers, on maintient les scripts, et quand quelque chose casse, on corrige. La maintenance fait partie du coût réel de l'automatisation, et c'est pour ça qu'on ne recommande jamais à un client non-technique de reproduire la stack sans équipe pour la maintenir.
Si vous lisez jusqu'ici, la question logique est : qu'est-ce que ça donne sur un client comme le vôtre ? La réponse passe par un diagnostic. On regarde votre propriété Search Console, l'état de votre Google Business Profile, votre setup GA4/GTM, et on identifie les écarts par rapport à une stack propre. Quarante minutes, gratuit, sans engagement.
Réservez votre diagnostic gratuit et on regarde ensemble ce que la stack peut changer pour votre site.