Six mois d’agents LLM sur mon monitoring SEO : le bilan honnête

La stack en mots simples

Un planificateur se déclenche plusieurs fois par jour. Chaque tâche lance une session d’agent LLM headless avec un travail étroit : tirer la donnée Search Console fraîche et écrire un résumé sur sept jours, vérifier que chaque URL surveillée répond toujours en 200, comparer les titres et les données structurées des pages clés à ceux de la veille, sonder le llms.txt et le balisage schema de chaque site. La sortie atterrit dans un fil Telegram, et une copie part dans un journal que la session suivante peut lire.

La pièce qui a fait passer l’échelle : un fichier registre unique qui décrit chaque site. Ajoutez un site au registre et il hérite de toute la suite de monitoring le jour même. Mon catalogue de 5 200 pages et ce portfolio tournent sur la même stack.

Ce que les agents font bien

Collecter et recouper, sans fatigue. Chaque matin, l’agent GSC compare les sept derniers jours aux sept précédents, nomme les pages qui montent et celles qui décrochent, vérifie le nombre de pages indexées contre une référence connue, et signale ce qui a bougé au-delà du bruit. Je n’ai pas ouvert Search Console pour un contrôle de routine depuis février.

Deuxième force : confronter les affirmations au site réel. Mon agent de récap ne se contente pas de dire qu’une page a perdu des clics ; il va chercher la page et vérifie que le title, la meta description et le schema sont intacts avant de spéculer. Cette seule habitude tue la plupart des fausses alertes du type « quelque chose a cassé ».

Le matin où mon agent a inventé une cause

En juin, le récap a signalé une page française au taux de clic faible et l’a expliqué avec assurance : les AI Overviews de Google absorbaient les clics. Un problème. Les AI Overviews n’étaient pas déployés en France. Le vrai souci de la page était banal : position 6 à 9 sur ses requêtes à volume, et un CTR bas, c’est exactement à quoi ressemble une position 6 à 9.

L’agent n’a pas menti ; il a reconnu un motif. Érosion de CTR plus 2026 plus SEO égale AI Overview dans l’essentiel de ce que le modèle a lu, donc c’est devenu l’explication. Il a hérité du battage ambiant comme il hérite de tout le reste.

Le correctif a été une règle permanente, pas un meilleur modèle : aucune cause ne peut être nommée sans vérifier l’état réel d’abord. Quel marché ? La fonctionnalité y est-elle seulement déployée ? Quelle est la position réelle sur les requêtes qui comptent ? Depuis cette règle, la qualité des diagnostics a plus changé qu’avec n’importe quel réglage de prompt.

Le goulot dont personne ne parle : décider

En juillet, le pipeline avait une panne d’un autre genre. Chaque récap du matin se terminait par une action proposée, chacune raisonnable, chacune en attente de mon feu vert. Huit récaps se sont empilés sans réponse. La machine à analyser tournait parfaitement et rien ne se passait, parce que la ressource rare n’a jamais été l’analyse. C’était mes décisions.

On a restructuré : les récaps quotidiens sont désormais de l’information pure, et les décisions se regroupent dans une session hebdomadaire plafonnée à trois, argumentées sur des fenêtres de données propres. Ce dernier point pèse plus qu’il n’y paraît. Les comparaisons sur sept jours respirent avec la météo ; un changement de title qui ressemblait à un échec dans le bruit quotidien s’est révélé, sur de vraies fenêtres avant-après, avoir amélioré le CTR. Le rollback que j’ai failli approuver aurait défait un changement qui marchait.

Les règles qui ont survécu à six mois

1. Vérifier l’état réel avant toute affirmation. Donnée GSC fraîche et HTML réellement servi, jamais la mémoire ou la supposition.
2. Les agents informent, les humains décident. Rien ne part en production sans une décision humaine nommée.
3. Chaque changement embarque son rollback. Sauvegarde locale de l’état précédent plus un chemin de retour écrit, avant de pousser.
4. Décider chaque semaine, sur des fenêtres longues. La donnée quotidienne sert à repérer les incendies, pas à juger les expériences.
5. Alerter sur l’échec, pas seulement le succès. Une tâche de monitoring qui meurt en silence est pire que pas de monitoring, parce qu’on lui fait confiance.

Est-ce que ça vaut le coup ?

Les coûts, honnêtement : plusieurs jours de mise en place, de l’entretien de prompts quand un rapport dérive en qualité, et le faux positif absurde de temps en temps. Mon moniteur de quota a déjà déclenché une alerte sur un motif d’erreur trouvé dans sa propre sortie de log.

En face : je surveille deux sites et la présence d’un réseau de 168 implantations d’un coup d’œil matinal sur un fil de discussion, les anomalies remontent le jour où elles arrivent au lieu de la semaine où je pense à regarder, et tout le système se transfère à un nouveau site en ajoutant une entrée de registre. Pour un opérateur solo, l’arbitrage n’est pas serré.

FAQ

Quel modèle fait tourner les agents ?

Claude, en sessions headless lancées par le planificateur de l’OS. Le motif est indépendant du modèle : tâche étroite, donnée fraîche, sortie structurée, un canal de livraison.

Les agents modifient-ils les sites ?

Pas d’eux-mêmes. Ils lisent, comparent et rapportent. Les changements passent par des scripts qu’un humain déclenche après décision, chacun avec sauvegarde et rollback écrit.

Par quel agent commencer ?

Le récap Search Console quotidien. C’est le meilleur signal pour le moins de tuyauterie, et il vous apprend immédiatement où vos agents vont extrapoler.

Le monitoring décrit ici est celui qui a attrapé l’écart de conformité llms.txt de l’article précédent. Les deux systèmes ne font qu’une stack.