On voit passer beaucoup de « systèmes SEO avec une dizaine d’agents ». Si on regarde ce qu’ils font, la plupart lisent des données, produisent une liste de recommandations et s’arrêtent là. Ils n’écrivent rien sur le site. Et surtout, ils ne mesurent pas ce qui s’est passé après.
Je me suis construit mon propre système d’autopilot SEO, que j’appelle Cortex. Il tourne chaque jour sur un serveur, même quand mon ordinateur est éteint. Ce qui m’a pris le plus de temps n’est pas la partie « agents ». C’est la boucle : constater, agir, vérifier, mesurer, et être capable de dire si l’action a servi à quelque chose.
Voici les étapes pour monter un système de ce type, ce qui a cassé chez moi et comment je l’ai réparé. Je ne donne aucun chiffre tiré de mon journal interne : ce que je raconte est du vécu, pas une mesure. Les seuls faits chiffrés viennent de la documentation de Google.
À retenir
Un autopilot SEO utile ferme la boucle : il constate, agit sur le site, revérifie en ligne, puis mesure avant et après. Sans écriture ni mesure, c’est un tableau de bord avec des suggestions.
Un relecteur indépendant du rédacteur, qui refuse souvent, vaut mieux qu’un contrôle indulgent. Chez moi, il a bloqué un prix trompeur avant publication.
D’après la documentation de Google, un changement de title peut mettre « quelques jours à quelques semaines » à être pris en compte : la fenêtre de mesure doit en tenir compte.
Une page modifiée pendant la mesure doit « se reposer », sinon l’effet est mélangé. Un registre des modifications manuelles évite que le système écrase le travail humain.
Les coûts dérapent vite si chaque appel recharge tout le contexte de l’outil : fixer un budget par run, le compter et le logger.
Ce qui sépare un autopilot d’un rapport automatisé
Un rapport automatisé répond à « qu’est-ce qui ne va pas ? ». Un autopilot répond à trois questions de plus : qu’est-ce qu’on change, est-ce que le changement est sûr, et est-ce qu’il a fonctionné.
La dernière est celle qu’on saute le plus. Pourtant, sans elle, on ne sait pas si le système améliore quelque chose ou s’il s’agite. Je suis parti de cette idée : une action sans mesure avant et après n’est pas une action SEO, c’est un pari.
Mon architecture tient en une chaîne. Un job quotidien sur un serveur fait le constat (Search Console, PageSpeed, indexation). Une étape d’enquête creuse ce qui ressort. Puis un agent d’action par site déroule : plan, rédacteur, contrôles automatiques, relecteur indépendant, sauvegarde, écriture, revérification en ligne, retour arrière automatique si le contrôle échoue. Chaque action est inscrite dans un registre. Une mesure compare les 28 jours avant et les 28 jours après. Le matin, je reçois un brief avec une seule décision à prendre.
Étape 1 : des données fiables, et leurs limites
Tout part de Search Console. Quelques points de la documentation changent la façon de construire le constat.
D’abord la position. D’après l’aide Search Console sur le rapport de performance, la position affichée est la plus haute occupée par un lien de votre site, moyennée sur les requêtes concernées, et le CTR est le rapport clics sur impressions. Une position moyenne n’est donc pas un classement stable : il faut la lire avec prudence.
Ensuite la fraîcheur et le volume. La documentation de l’API Search Analytics indique que les données sont généralement disponibles après deux à trois jours, que l’API expose au maximum 50 000 lignes par jour et par type de recherche, et que les résultats se parcourent par pagination, par pas de 25 000 lignes. Elle précise aussi que le système peut abandonner des données quand on regroupe par page et par requête, et que pour des totaux exacts il faut retirer ces dimensions. Conséquence pratique : ne jamais comparer un total exact à une somme de lignes, et ne pas mesurer sur les trois derniers jours.
Pour l’indexation, l’API d’inspection d’URL donne le statut de la version présente dans l’index Google. Elle ne teste pas une page en direct. Mon agent ne doit donc pas conclure « la page est indexable » à partir de là : il constate ce que Google a retenu, pas ce que le site sert aujourd’hui.
Étape 2 : trouver quoi traiter
Mon repérage de quick wins est volontairement simple. Je cherche les pages proches de la première page dont le CTR est nettement sous celui des autres pages du même site à la même position, marque mise à part. L’idée : comparer un site à lui-même, à position égale, plutôt qu’à une courbe moyenne de CTR trouvée en ligne.
La marque mise à part est un point de méthode. Les requêtes de marque ont un CTR très différent, et elles masqueraient le signal. Une page qui sous-performe à position égale a souvent un title ou une description qui ne donne pas envie, ou qui ne répond pas à l’intention de la requête.
Ce repérage produit des candidats, pas des décisions. L’étape d’enquête vérifie que la page est bien indexée, qu’elle répond à la requête et qu’aucune autre page du site ne vise la même chose.
Étape 3 : des agents qui écrivent, et un relecteur qui refuse
C’est ici que la plupart des démonstrations s’arrêtent. Faire écrire un agent est facile. Lui faire écrire sans casser le site est le vrai travail.
Mon dispositif sépare les rôles. Un agent planifie. Un rédacteur propose. Des contrôles automatiques vérifient ce qui se vérifie par code (longueur, format, présence des éléments obligatoires). Puis un relecteur indépendant, qui n’a pas écrit le texte, juge s’il est publiable.
Ce relecteur refuse souvent, et c’est voulu. Il a attrapé un prix trompeur avant publication. Il a aussi refusé des textes qui paraphrasaient la page au lieu d’apporter quelque chose. Un rédacteur qui se relit lui-même valide presque tout.
Quand le relecteur refuse, je ne l’assouplis pas. À la place, le rédacteur reçoit les derniers motifs de refus pour apprendre. Assouplir le contrôle fait monter le taux de publication, et c’est exactement ce qu’il ne faut pas optimiser.
Après validation viennent la sauvegarde de l’état précédent, l’écriture, puis la revérification en ligne : le système recharge la page publiée et contrôle que le changement est bien là et que rien d’autre n’a bougé. Si le contrôle échoue, le retour arrière est automatique. Sans cette dernière brique, je ne laisserais jamais un agent écrire.
Étape 4 : mesurer, et protéger la mesure
La mesure compare une fenêtre avant et une fenêtre après l’action, sur la page concernée. Deux précautions m’ont coûté cher à découvrir.
Laisser la page se reposer
Si on retouche une page pendant la fenêtre de mesure, on ne sait plus quelle modification a produit quoi. Le système impose donc un repos : une page modifiée n’est plus touchée tant que sa mesure n’est pas terminée.
Pour fixer la durée, il faut aussi connaître le délai côté Google. D’après la documentation sur les title links, Google doit réexplorer et retraiter la page, ce qui peut prendre « quelques jours à quelques semaines ». La même page rappelle que Google peut générer un titre différent de celui qu’on a écrit s’il juge que le title ne reflète pas la page. Un title modifié n’est donc pas forcément un title affiché : le système doit pouvoir le constater.
Le jour où le pilote a failli écraser mon travail
Première faille vécue : le pilote ne voyait que ses propres actions. Il a failli réécrire une page que j’avais modifiée à la main quelques jours plus tôt. Il ne savait pas qu’elle était « en repos », puisque c’était moi, pas lui, qui l’avais touchée.
Le correctif est un registre des modifications manuelles, que le pilote lit avant chaque décision. Dès que je change une page à la main, je l’y inscris. Ce n’est pas élégant, mais ça règle le problème.
Les actions sans URL
Deuxième piège : certaines actions portent sur des fichiers, comme llms.txt, le sitemap ou robots.txt. Elles n’ont pas d’URL de page, donc pas de mesure page par page. On ne peut les suivre qu’à l’échelle du site, et l’effet est peu attribuable. Je les consigne dans le registre, mais je ne prétends pas en mesurer le résultat.
Étape 5 : le coût, avant qu’il ne vous surprenne
Mes premiers tests ont brûlé beaucoup de tokens. La cause : chaque appel rechargeait tout le contexte de l’outil, avec ses instructions, ses fichiers de configuration et son historique, alors que la tâche demandait trois lignes de contexte.
Je suis passé à un contexte minimal : chaque agent reçoit ce dont il a besoin pour sa tâche et rien d’autre. La leçon plus générale : un budget par run, fixé à l’avance, compté et loggé. Si le run dépasse, il s’arrête et me prévient. Pas de compensation silencieuse.
Étape 6 : garder l’humain là où ça compte
Le brief du matin ne contient qu’une décision pour moi. Tout le reste est soit fait et vérifié, soit écarté avec une raison.
Sur un site client sensible, je garde le go. Certains sites restent en mode propositions seulement : le système constate, enquête, rédige, mais n’écrit pas. L’autonomie se gagne site par site, pas d’un bloc.
Un exemple en cours : mesfrais.pro
Sur mon propre site mesfrais.pro, j’ai fait réécrire les titles d’un gabarit de pages. Le relecteur indépendant a rejeté la première version : le texte promettait un avantage fiscal à tort sur certaines fiches. Un humain pressé l’aurait peut-être laissé passer.
J’ai ensuite réduit le périmètre au seul title, pour isoler l’effet. Pas de modification du contenu en même temps. Le retour arrière est prêt.
Je n’ai pas encore de résultat. La fenêtre de mesure n’est pas terminée, et quand elle le sera, elle dira seulement ce qui s’est passé sur ces pages, pas ce qui se passerait ailleurs. Je préfère l’écrire tel quel que d’annoncer un gain avant l’heure.
Ce que je ferais lundi matin
Commencer par un seul type d’action, comme les titles d’un gabarit. Un périmètre étroit rend la mesure lisible.
Écrire le registre avant l’agent : actions du système, modifications manuelles, dates, état avant. Le pilote le lit avant chaque décision.
Séparer rédacteur et relecteur, avec un cadrage du relecteur qui part du principe que le texte est à refuser. Ne pas l’assouplir quand il refuse beaucoup.
Prévoir le retour arrière avant la première écriture, et la revérification en ligne juste après.
Décider du repos des pages et de la longueur de la fenêtre de mesure, en tenant compte des délais décrits par Google.
Fixer un budget par run et réduire le contexte de chaque appel au strict nécessaire.
Garder le mode propositions seulement sur les sites où une erreur coûte cher.
Limites
Ce billet raconte un système que j’ai construit pour mes besoins. Je ne donne pas de chiffres internes, donc vous ne pouvez pas juger de son efficacité sur ma parole, et je ne prétends pas qu’il améliore le trafic. Mon seul cas décrit en détail n’a pas encore de résultat.
Comparer 28 jours avant et après reste une comparaison simple. Elle ne neutralise ni la saisonnalité, ni les mises à jour de Google, ni le fait que Google peut réécrire un title. Une hausse après action n’est pas la preuve que l’action en est la cause.
Enfin, les points de documentation cités datent de leur lecture à la date de cet article et peuvent évoluer. Cette documentation ne donne pas, sur les pages que j’ai ouvertes, de quota précis pour l’API d’inspection d’URL : vérifiez-les avant de dimensionner un job.