Loop engineering et SEO : créer des agents qui apprennent de leurs actions

Pourquoi tout le monde parle soudainement de loop engineering

Le loop engineering s’est d’abord diffusé dans le développement informatique. Des ingénieurs utilisant Claude Code, Codex ou d’autres agents ont commencé à délaisser les longues conversations faites d’instructions successives. Ils construisent désormais des systèmes capables de se donner leurs propres sous-objectifs, de lancer des tests et de poursuivre leur travail sans attendre une nouvelle intervention humaine.

Le principe tient en quelques mots : un agent en pilote un autre. L’agent coordinateur analyse l’état du projet, choisit la prochaine tâche et transmet les instructions appropriées à un agent exécutant. Un troisième peut relire le résultat, signaler les défauts et demander une correction.

Cette pratique a récemment reçu le nom de « loop engineering ». Le terme est nouveau, le mécanisme l’est beaucoup moins. Les travaux consacrés à ReAct, pour Reasoning and Acting, décrivaient dès 2022 des modèles alternant raisonnement, action et observation. La différence actuelle vient surtout de la maturité des outils, de la durée des sessions et de la capacité des agents à agir sur des environnements réels.

Les modèles peuvent maintenant consulter des fichiers, interroger des API, modifier du code, utiliser un navigateur, appeler un serveur MCP et déléguer certaines tâches à des sous-agents. La boucle quitte le laboratoire. Elle commence à entrer dans nos méthodes de travail.

Comment fonctionne une loop agentique

Une boucle agentique relie un objectif à une série d’actions dont le chemin exact n’est pas entièrement connu à l’avance. À chaque tour, l’agent utilise les informations nouvellement obtenues pour décider de la suite.

Son fonctionnement général peut être représenté ainsi :

Objectif
   ↓
Observer l’état actuel
   ↓
Choisir une action
   ↓
Utiliser un outil
   ↓
Vérifier le résultat
   ↓
Mettre à jour la mémoire
   ↓
Continuer, corriger ou arrêter

L’observation peut provenir d’un test logiciel, d’une réponse API, d’un rapport Search Console ou du contenu réel d’une page. L’agent confronte ensuite ce résultat à ses critères de réussite. Il poursuit son travail lorsque l’objectif reste incomplet, change d’approche lorsque l’action a échoué et s’arrête lorsqu’une condition de sortie est remplie.

Anthropic décrit les agents comme des modèles utilisant des outils et le retour de leur environnement au sein d’une boucle. Son article sur la construction d’agents efficaces insiste aussi sur la nécessité d’obtenir une « vérité terrain » après chaque action. L’agent a besoin d’un résultat observable pour estimer sa progression.

Cette vérité terrain pose déjà une difficulté en SEO. Un test automatisé peut confirmer instantanément qu’un programme fonctionne. La progression d’une page dans Google dépend de signaux plus lents, plus bruités et en partie extérieurs au système. Une boucle SEO doit donc travailler avec plusieurs niveaux de preuve.

Prompt, workflow et loop répondent à des besoins différents

Ces trois notions sont parfois mélangées, alors qu’elles décrivent des degrés d’autonomie distincts. Le tableau suivant permet d’identifier le dispositif adapté à la tâche.

Un workflow convient bien aux tâches dont les étapes sont connues. La création d’un brief éditorial peut suivre une séquence relativement stable : récupérer les résultats de recherche, extraire les contenus, analyser les termes, identifier les questions puis préparer le document.

Une loop devient utile lorsque le nombre d’étapes varie ou que le résultat d’une analyse peut modifier le plan. Une détection de cannibalisation peut conduire à enrichir une page, à fusionner deux contenus, à revoir le maillage ou à ne rien changer. Le contexte détermine la prochaine action.

Cette distinction prolonge celle que j’ai déjà abordée dans mon article consacré au pilotage SEO conversationnel avec MCP. Le MCP donne accès aux outils. La loop organise leur utilisation dans le temps et décide quand les rappeler.

Le SEO fonctionne déjà comme une boucle incomplète

Le référencement naturel suit depuis longtemps un mouvement cyclique. Nous publions une page, Google la crawle, l’indexe, la positionne, puis les données de performance nous aident à la corriger.

Produire
→ publier
→ faire crawler
→ observer les positions
→ analyser les requêtes
→ modifier
→ mesurer de nouveau

Dans la pratique, cette boucle se referme rarement aussi proprement. Les audits génèrent des recommandations qui ne sont jamais réévaluées. Les mises à jour sont publiées sans baseline. Les consultants changent, les décisions disparaissent dans des fichiers et personne ne sait précisément quelle modification a provoqué quel résultat.

Je rencontre souvent ce problème : nous sommes très équipés pour détecter les anomalies, beaucoup moins pour apprendre de nos propres actions. Une page perd du trafic, nous la réécrivons, puis nous passons à la suivante. Trois mois plus tard, le gain ou la perte est visible, mais le lien avec l’hypothèse de départ s’est effacé.

Le loop engineering peut combler cette rupture. Il apporte une mémoire opérationnelle entre l’audit, l’action, la publication et la mesure. L’agent n’exécute plus une analyse isolée. Il suit une hypothèse dans la durée.

Une loop SEO a besoin de sept composants

Une boucle utile ne peut pas reposer sur une invitation vague à « améliorer le SEO ». Elle doit rendre visibles ses objectifs, ses ressources et ses limites.

Le tableau suivant rassemble les composants que je considère nécessaires avant d’autoriser un agent à travailler sur un site.

L’objectif mérite une attention particulière. « Optimiser cette page » laisse trop de place à l’interprétation. Une formulation comme « augmenter les clics issus des requêtes où la page apparaît entre les positions 3 et 10, sans modifier son intention principale ni créer de chevauchement avec les autres contenus » donne à l’agent un cadre exploitable.

Les Agent Skills peuvent ensuite apporter des méthodes spécialisées : analyser une perte de trafic, contrôler un balisage Schema.org, chercher des sources ou inspecter le maillage. La loop sélectionne ces compétences et décide dans quel ordre les employer.

L’évaluateur constitue le cœur du dispositif

La partie la plus difficile du loop engineering SEO se trouve dans l’évaluation. Un agent devient dangereux lorsqu’il sait agir, mais comprend mal la réussite attendue.

Prenons un outil d’optimisation sémantique. Si la boucle reçoit pour unique objectif d’augmenter un score de couverture lexicale, elle ajoutera progressivement les termes manquants. Le score montera. Le texte pourra devenir répétitif, lourd ou éloigné du besoin réel du lecteur.

Le système aura parfaitement exécuté la mauvaise mission.

Les contrôles doivent être séparés en deux catégories. Certains fonctionnent comme des portes obligatoires : aucune erreur factuelle, aucune source inventée, pas de lien cassé, pas de perte d’indexabilité et pas de cannibalisation manifeste. Un échec sur l’un de ces points suffit à rejeter la proposition.

Les autres critères servent à comparer plusieurs versions acceptables : couverture des intentions, précision, fluidité, présence des entités utiles, qualité du maillage et capacité à conduire le lecteur vers une offre. Ils peuvent donner lieu à des scores, à condition de ne jamais oublier qu’un score reste un indicateur partiel.

Je recommande aussi de séparer autant que possible l’agent exécutant de l’évaluateur. Le modèle qui vient de produire une recommandation aura tendance à la défendre. Une nouvelle session, un autre modèle ou un contrôle déterministe apportera davantage de recul.

Pour les contenus, on peut conserver un jeu de requêtes réservé que l’agent rédacteur ne voit jamais. La nouvelle version est évaluée sur ces questions après la rédaction. Cette méthode limite le risque de produire un texte conçu uniquement pour réussir les tests connus.

Quelles loops peut-on construire pour le SEO ?

Les premiers usages devraient concerner des actions observables, réversibles et suffisamment fréquentes pour justifier l’automatisation. Plusieurs boucles répondent déjà à ces conditions.

La boucle de visibilité GEO demande davantage de prudence. Les réponses de ChatGPT, Gemini ou Perplexity varient selon le modèle, la date, la formulation et les sources accessibles. Une seule réponse ne constitue pas une mesure fiable.

Il faut répéter les tests, conserver les versions des prompts, distinguer les mentions des citations et comparer les résultats dans le temps. Mon article sur la manière de mesurer sa visibilité dans les LLM présente les indicateurs qui peuvent alimenter cette boucle.

Exemple : améliorer une page au CTR trop faible

Imaginons une page qui obtient beaucoup d’impressions, se positionne en moyenne entre la quatrième et la huitième place, mais attire moins de clics que les autres pages du site situées dans la même zone.

Une loop SEO pourrait commencer par récupérer les requêtes et calculer l’écart entre le CTR réel et le CTR habituellement observé à cette position. Elle lirait ensuite le title, la meta description et le contenu visible dans les résultats de recherche.

L’agent formulerait une hypothèse : le titre répond mal à l’intention commerciale, manque de précision ou ressemble trop aux titres concurrents. Il produirait plusieurs variantes et justifierait chacune à partir des requêtes réelles.

Un évaluateur vérifierait alors la longueur, l’exactitude de la promesse, la présence naturelle du sujet et la cohérence avec la page. Les titres trop racoleurs seraient rejetés, même s’ils paraissent susceptibles d’attirer davantage de clics.

Après validation humaine, la version choisie serait publiée. La boucle entrerait ensuite dans une phase d’attente, car Google doit recrawler la page et collecter suffisamment d’impressions.

Vingt-huit jours plus tard, le système comparerait la nouvelle période à la baseline. Il tiendrait compte des changements de position et de demande avant d’attribuer l’évolution au nouveau titre. Le résultat serait conservé dans la mémoire du projet :

Hypothèse : le titre manque de précision commerciale
Action : ajout du bénéfice principal et de l’année
Résultat : CTR de 2,1 % à 3,4 %
Position moyenne : stable
Décision : conserver la modification
Apprentissage : ce type de formulation fonctionne sur les pages comparatives

Cette dernière ligne apporte une valeur durable. La boucle ne s’est pas contentée de modifier une page. Elle a produit un enseignement réutilisable sur les prochains contenus.

Les boucles internes et externes ne tournent pas à la même vitesse

Une loop SEO doit composer avec plusieurs temporalités. Les contrôles internes peuvent être lancés en quelques secondes. Les effets sur les moteurs demandent souvent plusieurs semaines.

La boucle interne vérifie immédiatement le statut HTTP, les balises, les liens, le rendu, les données structurées ou l’absence d’erreur factuelle. Elle peut corriger plusieurs fois une proposition avant toute publication.

La boucle intermédiaire surveille le crawl, l’indexation, les impressions et les premières requêtes. Elle permet de repérer une anomalie ou une absence de réaction.

La boucle externe mesure le trafic, les conversions, les positions, les citations dans les moteurs IA et la contribution commerciale. Son signal arrive plus tard et reste exposé à des facteurs que l’agent ne contrôle pas.

Mélanger ces niveaux conduit à de mauvaises décisions. Une page ne doit pas être réécrite tous les trois jours parce que son trafic n’a pas encore progressé. À l’inverse, attendre trois mois pour découvrir une canonical incorrecte serait absurde.

La cadence fait partie de la conception de la boucle.

Le principal danger reste l’optimisation d’un mauvais indicateur

Les agents ont une aptitude inquiétante à exploiter les règles qu’on leur donne. Lorsqu’un objectif chiffré peut être amélioré sans produire la qualité recherchée, ils finissent souvent par trouver le raccourci.

Une boucle éditoriale peut allonger chaque texte pour couvrir davantage de termes. Une boucle de maillage peut multiplier les liens vers les pages prioritaires. Une boucle GEO peut ajouter des citations partout afin d’augmenter artificiellement la densité de preuves.

Chaque décision paraît défendable prise isolément. Leur accumulation dégrade le site.

Les agents peuvent aussi dépasser le périmètre implicite de leur mission. Des recherches récentes sur les actions excessives des agents de code montrent que certains systèmes modifient ou suppriment des éléments qui n’étaient pas concernés par la demande initiale. Le contexte SEO diffère, mais le problème d’autorisation reste comparable.

Les premières boucles devraient donc travailler en lecture seule. Elles analysent, priorisent et préparent des différences entre la version actuelle et la version proposée. La publication, la suppression d’une page ou la création d’une redirection restent soumises à une validation humaine.

L’autonomie peut être élargie progressivement pour les opérations réversibles et bien testées. L’accès direct au CMS arrive beaucoup plus tard.

Comment commencer sans construire une usine à agents

Anthropic recommande de choisir l’architecture la moins complexe capable de résoudre correctement le problème. Ce conseil mérite d’être suivi en SEO, où l’empilement d’agents produit facilement beaucoup de texte, beaucoup de coûts et peu de décisions utiles.

Je commencerais par une boucle étroite sur un processus répétitif :

Détecter une page en baisse
→ diagnostiquer la cause probable
→ proposer une action
→ faire valider cette action
→ mesurer son impact
→ enregistrer l’apprentissage

Chaque étape doit retourner des données structurées. L’hypothèse, la preuve, l’action et le résultat doivent pouvoir être lus indépendamment de la conversation avec le modèle.

Les règles d’arrêt sont définies dès le départ : nombre maximal d’itérations, budget de tokens, seuil de confiance, absence de progression ou besoin d’un arbitrage. L’agent doit également pouvoir déclarer qu’il ne sait pas. Une loop fiable sait parfois interrompre son travail.

L’ajout de sous-agents vient ensuite, lorsque la séparation des rôles apporte un gain mesurable. Un agent peut analyser les données, un autre examiner la page et un troisième contester la recommandation. Leur multiplication n’a aucun intérêt lorsque les critères d’évaluation restent flous.

Ce que je suis en train d’intégrer dans Search Intent

Cette logique influence déjà la manière dont je développe Search Intent. L’application ne se limite plus à lancer une série d’analyses SEO. Elle conserve le contexte d’un projet, les décisions prises, les retours éditoriaux, les actions prévues et leurs résultats.

Une page en baisse peut être ajoutée à une feuille de route, associée à une recommandation puis suivie après sa publication. Une baseline Search Console est enregistrée. La performance est réévaluée après 28, 56 ou 90 jours. Le résultat peut ensuite devenir un apprentissage durable dans la mémoire du projet.

Cette continuité change profondément la qualité du conseil. L’outil peut retrouver ce qui a été tenté, distinguer les hypothèses confirmées des intuitions abandonnées et adapter ses prochaines recommandations au comportement réel du site.

Le consultant garde un rôle central. Il définit les objectifs, choisit les preuves acceptables, arbitre les conflits entre SEO, conversion et image de marque, puis décide du niveau d’autonomie accordé à chaque action.

Les prochaines années donneront probablement accès à des agents capables d’exécuter presque toute la chaîne opérationnelle du référencement. L’avantage concurrentiel viendra de la qualité des boucles que nous leur aurons confiées : leurs données, leurs évaluateurs, leur mémoire et leurs limites.

Pour commencer, choisissez une seule décision SEO récurrente, formalisez les preuves nécessaires et définissez précisément le moment où l’agent doit s’arrêter. Vous aurez déjà construit une première loop. Et vous découvrirez probablement que la partie la plus exigeante n’est pas l’automatisation. Elle consiste à mettre par écrit votre propre manière de juger.