Un agent de SEO programmatique

Un agent de SEO programmatique rend service sur trois tâches : transformer des lignes de données en pages qui répondent chacune à une vraie requête, contrôler chaque page selon des règles avant sa mise en ligne, et mener de petites expériences datées une fois les pages publiées. Il est dangereux sur une seule : décider tout seul qu’une page est bonne. Générer dix mille pages ne coûte presque rien depuis des années. Ce qui coûte, c’est de publier des pages fausses, creuses ou identiques, et un agent commet cette erreur plus vite que n’importe quel stagiaire.

J’ai fait du SEO programmatique avec et sans agents. Sur Derrick, que j’ai cofondé, j’ai construit plus de 100 variantes de pages dans Webflow à partir d’un Google Sheet, avant qu’une IA utilisable existe, et deux ans plus tard, sans aucun travail SEO supplémentaire, elles apportaient encore 88 clics par jour. Depuis, le site est passé sous Astro et des agents ont repris une grande partie du travail récurrent selon des règles écrites : c’est ce dispositif que je décris ici. Les chiffres sont dans l’étude de cas Derrick.

Séparez les rôles avant d’écrire un prompt

Un agent unique qui planifie, rédige, contrôle et mesure finit par corriger sa propre copie. Je répartis le travail en rôles aux instructions distinctes, et seul le rôle principal a le droit de trancher.

Rôle	Fait	Ne fait jamais
Agent Head of SEO	Planifie la semaine à partir des données, rend les verdicts des tests	Rédiger des pages
Agent rédacteur	Transforme une ligne de données et un brief en brouillon de page	Décider de ce qui est publié
Agent optimiseur	Améliore les pages existantes : titres, maillage interne, sections manquantes	Toucher aux pages en test
Agent expérimentateur	Mène des tests bornés et rédige des verdicts datés	Changer ses critères de succès en cours de test
Contrôleur (script et juge)	Exécute les contrôles avant mise en ligne ci-dessous	Corriger ce qu’il signale

Le rôle principal et les experts tournent sur le modèle le plus puissant disponible, parce que leur travail relève du jugement. Les sous-tâches purement mécaniques, comme un rechercher-remplacer sur les templates, vont à un petit modèle rapide. Une contrainte structure le dispositif dans Claude Code : un sous-agent ne peut pas lancer un autre sous-agent, donc toute la délégation s’organise depuis le sommet.

Chaque page part d’une ligne de données sourcée

L’agent écrit à partir des données, jamais de mémoire. Chaque ligne porte les faits que la page affirmera et leur provenance, pour que le contrôleur puisse les vérifier ensuite. Disons que vous vendez un outil de données et publiez une page par cas d’usage :

{
  "slug": "enrich-companies-recruitment-agencies",
  "query_target": "enrich company list for recruitment agencies",
  "facts": {
    "feature_name": "Enrich Companies",
    "cost": "1 credit per company",
    "source": "/features/enrich-companies"
  },
  "unique_content": ["columns a recruiter needs and why", "two questions from support tickets"],
  "status": "draft"
}

C’est le champ unique_content qui compte. Une page qui se contente de changer le nom du cas d’usage dans un template relève du contenu quasi dupliqué que les règles de Google sur le spam décrivent comme un abus de contenu à grande échelle. Si une ligne n’a rien de spécifique à dire, la page ne doit pas exister. La conception de cette base est traitée dans le chapitre base de données du guide SEO programmatique.

Chez Derrick, les faits produit vivent dans un seul fichier, et un script vérifie qu’une fonctionnalité existe avant qu’une page la cite. Les comptes ne sont jamais tapés dans une page : un script les calcule. Cela supprime toute une famille d’erreurs, comme une page qui cite encore un ancien nombre de fonctionnalités après la sortie des nouvelles.

Contrôlez chaque page avant sa mise en ligne

Le contrôleur fait passer deux types de tests. Les contrôles mécaniques sont un script : même entrée, même verdict. Les contrôles subjectifs vont à un modèle juge, dans un contexte vierge, qui ne voit que la page et la ligne de données, jamais le raisonnement du rédacteur.

Contrôle	Type	Échoue quand
Chaque fait affirmé correspond à un champ de la ligne	Script	Un prix, un compte ou un nom de fonctionnalité absent de la source
La fonctionnalité existe	Script	La fonctionnalité citée n’a pas de page sur le site
Quasi-doublon	Script	Similarité de texte avec une autre page au-dessus de votre seuil
Mots interdits et noms de concurrents	Script	La moindre occurrence
Liens internes valides	Script	Un lien renvoie une erreur
Longueur du title et de la meta, un seul H1	Script	Hors limites
Répond à la requête cible dès le premier écran	Juge	Le juge ne peut pas citer la réponse
Dit quelque chose qu’un template ne pourrait pas dire	Juge	Le contenu unique conviendrait à n’importe quelle ligne

Les pages en échec repartent avec la raison ; l’agent ne publie rien lui-même. Il ouvre une pull request, un humain la fusionne. Après toute modification des instructions du rédacteur, un jeu de briefs figés est relancé et comparé aux sorties précédentes, pour qu’une correction à un endroit ne casse pas discrètement des pages ailleurs.

Testez sur quelques pages, avec une date de verdict

Une fois les pages en ligne, l’agent expérimentateur propose des changements et les teste sur un ensemble borné, typiquement 10 pages, jamais toute la famille. Chaque test est écrit avant de commencer :

# illustrative test spec
test_id: title-with-price
hypothesis: Putting the credit cost in the title raises CTR on feature pages
pages: [list of 10 slugs]
control: [10 comparable slugs, unchanged]
metric: CTR at comparable positions, Search Console
start: 2026-11-10
verdict_on: 2026-12-08
decision_rule: keep if CTR gap above 20% relative and positions stable
pages_frozen: true

La date de verdict est à quatre semaines et fixée à l’avance. Le drapeau pages_frozen ne fonctionne que si toutes les autres routines le lisent : une routine qui ignorait une telle déclaration a faussé l’un de nos tests (chapitre 12).

Méfiez-vous d’abord de votre propre mesure

L’incident le plus instructif de notre système SEO est une erreur de mesure que l’agent Head of SEO a trouvée dans ses propres exports en novembre 2026, racontée en entier dans le chapitre sur la mesure. Deux règles en sont sorties :

• Avant de combiner deux exports, vérifiez que leurs totaux concordent.
• Quand un chiffre commande une décision, confirmez-le avec un second instrument indépendant plutôt qu’en regardant une troisième fois le premier.

Les indicateurs à suivre à chaque étape du funnel sont dans le chapitre sur le suivi des performances.

Votre prochaine étape : choisissez une famille de pages, écrivez le schéma de ligne de données avec une source pour chaque fait et un champ unique_content, et faites passer les contrôles mécaniques à dix pages existantes avant de laisser un agent en rédiger une nouvelle.