Construire un agent SEO : les 6 briques, ce qu'on a mesuré, les limites

« Je veux automatiser mon SEO avec des agents. Par quoi je commence, et combien ça coûte ? » La première moitié de la question reçoit partout des réponses. La seconde reçoit des ordres de grandeur inventés.

Alors on a mesuré le nôtre. Le 27 août 2026, un lot de 9 agents a produit 5 articles de ce Lab, en deux phases : une mesure par article, puis une rédaction. Le lot a tourné, on a gardé les journaux, et on les a dépouillés ligne par ligne.

Ce qui suit est ce relevé, y compris les endroits où il contredit ce qu'on croyait avoir. Le plus instructif de tous : un compteur qu'on s'apprêtait à publier sous une étiquette fausse.

Ce qu'on a mesuré, et ce qu'on n'a pas pu mesurer

Trois sources, jamais mélangées.

• Le dépôt, compté octet par octet sur le disque : 13 scripts de mesure pour 3 254 lignes, 7 articles écrits en français et en anglais pour 1 247 lignes de modules, 11 embeds interactifs pour 2 335 lignes, 12 jeux de données pour 826 972 octets.
• Les journaux d'agents du lot terminé, dédoublonnés par identifiant de message pour les jetons et par identifiant de bloc d'appel pour les outils, puis recoupés contre les compteurs de l'orchestrateur.
• Quatre chronomètres relancés pour de vrai, avec un module préchargé qui enveloppe fetch et compte les appels sortants.

Deux précautions valent d'être copiées. D'abord, l'inventaire du dépôt est arrêté au lancement du lot suivant, parce que six agents écrivaient dans les mêmes dossiers pendant le relevé. Entre cette coupure et la mesure, 7 scripts et 10 jeux de données sont apparus : les compter aurait été un doublon. Ensuite, le lot en cours au moment du relevé est exclu. Mesurer un lot depuis l'intérieur donne un total tronqué, qui change après coup.

Une nuance à publier telle quelle, parce qu'elle est facile à rater : les « 3,4 Mo de données » qu'affiche un du -sh comptent des blocs disque et additionnent deux ensembles distincts. Les 12 jeux publiables pèsent 826 972 octets ; les 108 fichiers du dossier, relevés bruts par site compris, pèsent 3 198 479 octets, soit 3,20 Mo. Le compte vient d'un ensemble, le poids de l'autre.

Les six briques, et ce que chacune a coûté

Un agent SEO n'est pas un modèle avec un prompt. C'est un empilement de six briques, et elles ne coûtent pas du tout la même chose.

Le classement est contre-intuitif. L'orchestration est un script de 19 844 octets qui lance les agents, leur donne la même loi et récupère des rapports structurés : c'est elle qui absorbe les 2 h 22 du lot. La vérification, elle, tient en 227 lignes et tourne en 0,048 seconde par article sans un seul appel réseau, compteur à l'appui : c'est la brique la moins chère à faire tourner du lot, et la seule qui empêche de publier un chiffre inventé. Et la brique dont tout le monde parle, les compétences spécialisées, n'a quasiment pas servi : 21 installées, 2 invocations sur tout le chantier, aucune par un agent de mesure ou de rédaction.

88 % du travail est du shell, pas du MCP

Sur le lot mesuré, les 9 agents ont émis 539 appels d'outils. La répartition est brutale : 475 au shell, 29 au navigateur piloté, 15 lectures de fichier, 6 écritures, 1 édition, 8 rapports structurés et 5 appels de service.

Sur l'ensemble du chantier, journaux du lot suivant compris, 3 serveurs MCP seulement ont été appelés, pour 76 appels au total. C'est une observation à un autre périmètre que les 539, et il faut le dire ainsi plutôt que de mettre les deux chiffres dans la même fraction.

La conclusion opérationnelle tient en une phrase : un agent SEO passe sa journée dans un terminal. curl, grep, un script Node de cent lignes, et le fichier de sortie qu'on relit. Les connecteurs servent là où il n'y a pas d'API en ligne de commande. Le reste du temps, ils ajoutent une couche à déboguer. Le sujet est traité sous un autre angle dans notre article sur l'IA agentique appliquée au SEO et au GEO.

Le chiffre qui était exact et faux en même temps

Voici le passage à lire si vous n'en lisez qu'un.

L'orchestrateur affiche, en fin de lot, un totalTokens de 1 574 725. La tentation était énorme : « notre lot a produit 1,5 million de jetons ». Ce chiffre a failli sortir tel quel.

Le dépouillement agent par agent dit autre chose. Ce nombre est la somme des occupations de fenêtre de contexte au dernier message de chaque agent. Pas une production. Sept agents sur neuf tombent au jeton près sur cette lecture, et la somme recalculée vaut 1 580 532, soit 0,4 % au-dessus, l'écart venant de deux agents qui ont produit des messages après le dernier relevé de progression.

Le chiffre n'est pas faux. Il est mal étiqueté. Et c'est très exactement la faute que notre lint a été écrit pour attraper : un nombre exact, repris avec le mauvais libellé, publié sous la signature du dirigeant.

Ce qui a permis de le voir mérite d'être copié : on a compté deux fois, par deux méthodes indépendantes. Sur les appels d'outils, le compteur de l'orchestrateur et le dédoublonnage par identifiant de bloc donnent tous les deux 539, et agent par agent les mêmes neuf valeurs. Sur les jetons, les deux méthodes ne se recoupent pas. C'est cette divergence, et rien d'autre, qui a révélé que le compteur ne mesurait pas ce qu'il annonçait.

Combien de jetons le lot a-t-il réellement produits, alors ? On ne le sait pas. Le journal en donne 93 224 après dédoublonnage, mais il n'écrit pas systématiquement l'état final de chaque message. C'est un plancher, pas un total certifié. On ne divise donc pas 1 574 725 par 93 224 : ce serait diviser un exact par un plancher, et ce ne sont pas deux mesures de la même grandeur.

Conséquence directe et désagréable pour nous : notre propre chiffre publié ailleurs, l'audit à 13 minutes et 58 000 jetons, vient probablement du même compteur. Il n'est pas vérifiable depuis ce dépôt. Il ne figure donc pas ici à côté des chiffres corrigés, tant qu'il n'a pas été revérifié à la source.

Le lot, agent par agent

Voici les neuf agents dans l'ordre de leur lancement, avec ce que chacun a consommé. Les deux colonnes de contexte sont séparées volontairement : l'occupation au dernier message et le pic atteint pendant le run ne disent pas la même chose.

La limite qu'on rencontre en premier, c'est la fenêtre

L'agent chargé de mesurer les signaux E-E-A-T sur un panel d'agences a poussé son contexte à 409 920 jetons au pic, au-dessus de la fenêtre : il a été compacté en cours de route. Deux autres agents ont dépassé 230 000. Son contexte final, 250 858, ne dit donc pas tout ce qui a transité par lui.

C'est la vraie limite d'un agent SEO, et elle arrive bien avant la question du prix. Un agent qui ouvre au moins 241 pages sur 24 domaines tiers sature sa fenêtre avant de saturer un budget. À partir de là, il oublie le début de sa consigne, redemande des fichiers qu'il a déjà lus, et se met à raisonner sur un résumé de son propre travail.

Sur ces neuf agents, l'agent le plus long (2 h 00 min 38) n'est pas celui qui a saturé sa fenêtre : c'est celui qui a fait le plus d'appels d'outils. Avec neuf points, ça ne vaut aucun test statistique, mais ça oriente la parade : découper par mesure, pas par article. Un agent qui mesure, un rapport structuré en sortie, un autre agent qui rédige à partir du rapport. C'est exactement la forme du lot mesuré ici, et c'est pour ça que huit agents sur neuf sont arrivés au bout.

Le coût en argent : la seule facture qu'on ait relevée

Le titre du plan éditorial promettait « le coût réel ». On l'a changé, parce que le coût en euros des agents n'a pas été relevé. Les jetons sont comptés, leur prix ne l'est pas. Le lot a lu 67 306 548 jetons de cache et en a écrit 2 952 977, et ces jetons ne se facturent pas au même tarif que les jetons produits. Sans relevé de facturation, tout montant serait une estimation déguisée en mesure.

Une seule dépense a été mesurée pour de bon, et elle est instructive. Sur le passage DataForSEO du 27 août, la différence de solde avant et après donne 0,41876 $ (de 16,459334 à 16,040574). Le total au tarif affiché, lui, se situe entre 0,2367 et 0,2396 $. Soit 75 à 77 % d'écart.

La fourchette n'est pas de la coquetterie : certains points d'entrée facturent au résultat rendu, et le nombre de résultats facturés n'a pas été relevé. La dépense, elle, est exacte au centième de millième, puisque c'est une différence de solde. Le périmètre l'est aussi : ce premier passage seul, 5 requêtes dont 3 exploitées. Un sixième appel à 0,09 $ est arrivé depuis, il n'entre pas dans le calcul.

Un tarif affiché n'est pas une facture. Relevez le solde avant et après, c'est un appel d'API et trente secondes de travail.

Trois échecs qui valent plus que dix promesses

Un agent sur neuf a été coupé net. Celui qui devait mesurer le hreflang pour l'article 07 s'est arrêté après 2 min 21 et 6 messages sur une erreur de filtrage de contenu. Onze pour cent d'échec, et l'échec avait déjà occupé 63 094 jetons de contexte. Un lot d'agents doit donc prévoir la reprise à l'article, pas au lot : relancer les neuf pour un seul serait absurde.

Un article a dû être retitré. L'article sur le rendu JavaScript promettait un écart entre ce que voit Googlebot et ce que voient les robots IA. La mesure a trouvé zéro écart. Le titre a changé, la mesure non. Une donnée qui contredit l'hypothèse de départ se publie telle quelle, sinon la mesure ne sert à rien.

Un premier jet a inventé des chiffres. Le brouillon de notre article sur llms.txt affirmait des données de logs serveur qui n'avaient jamais été relevées. Le lint de copy, lui, ne voyait rien : il vérifiait les tirets cadratins, pas la véracité. D'où le garde-fou ajouté après coup, la brique 5 : dès que la copy dit « mesuré sur », le script exige que le module déclare les fichiers de données qui portent l'affirmation. Aujourd'hui, 7 modules sur 7 les déclarent.

Quatrième cas, plus petit et tout aussi utile : notre propre documentation annonçait qu'un réassemblage de panel se faisait « sans réouvrir une seule page ». Le compteur d'appels sortants en a trouvé 2. Deux domaines sans relevé sur disque déclenchent quand même leur requête de contrôle avant d'être écartés. La doc décrivait l'intention, pas le code.

Par quoi commencer, dans l'ordre

1. Écrire le contexte projet avant le premier agent. Six fichiers, 73 633 octets chez nous, dont 15 044 pour les seules règles. C'est ce que l'agent lit avant d'agir : périmètre, ton, interdits, où vivent les données.
2. Donner le shell, pas des connecteurs. 88 % des appels y passent. Un connecteur se justifie quand il n'existe aucune API en ligne de commande, pas par principe.
3. Écrire la vérification avant l'orchestration. C'est la brique la moins chère du lot et la seule qui empêche de publier une mesure fabriquée. Sept mots bannis, six motifs de détection d'affirmation chiffrée, cinq champs obligatoires, dix types de balises recomptés après écriture.
4. Orchestrer ensuite, par mesure. Un agent, une mesure, un rapport structuré. Jamais un agent qui mesure et rédige dans la même fenêtre.
5. Garder le dernier geste humain. Nos 7 articles sont créés en brouillon, la publication reste un clic manuel. C'est la seule brique qui rattrape les cinq autres quand elles se trompent en silence.

Si l'entrée par les prompts vous parle davantage que l'entrée par l'architecture, on a publié les prompts qu'on utilise au quotidien.

Refaire la mesure chez vous

Rien de ce qui précède ne demande un outil payant. Cinq gestes suffisent.

• Dédoublonnez les journaux par identifiant de message avant de sommer quoi que ce soit. Sans ça, les jetons sont comptés plusieurs fois : le journal écrit une ligne par fragment de flux.
• Comptez deux fois, par deux chemins indépendants, et publiez l'écart. Quand les deux tombent d'accord, vous tenez un fait. Quand ils divergent, vous tenez un problème d'étiquette.
• Enveloppez fetch avec un module préchargé qui compte les appels sortants. C'est vingt lignes, et c'est ce qui a révélé les 2 requêtes qui n'auraient pas dû exister. Nos relevés : le lint à 0,048 s et 0 requête, l'audit de maillage à 1,323 s et 85 requêtes (1 sitemap plus 84 pages, ce qui recoupe exactement le graphe déjà publié dans notre méthode de maillage interne), l'audit llms.txt à 18,266 s et 31 requêtes.
• Relevez le solde de vos fournisseurs payants avant et après, jamais le tarif affiché.
• Ne relancez pas un script qui écraserait un jeu déjà publié ou qui taperait des serveurs tiers pour rien. Deux de nos durées viennent des journaux et pas d'un chronomètre : 302,7 s pour l'audit d'indexation, 299,3 s pour l'audit de rendu par User-Agent. On les cite comme telles.

Dernière règle, et c'est celle qui sépare une mesure d'un billet d'opinion : un échec technique n'est pas un résultat. Sur les 40 domaines interrogés pour notre audit des crawlers IA, 36 ont été mesurés et 4 renvoient 403 ou 404. Un 403 n'est pas un site qui bloque les robots IA, c'est un site qu'on n'a pas pu lire. Confondre les deux, c'est publier une statistique qui décrit votre pare-feu.

Pour la définition du crawl, et si vous préférez déléguer la chaîne entière plutôt que la construire, c'est ce que fait notre offre d'agence SEO agentique.