Context engineering SEO : le vrai levier des agents IA

Le prompt n'est plus le goulot d'étranglement

Donnez exactement le même prompt d'audit à deux agents SEO, vous obtiendrez deux résultats sans rapport. Ce n'est pas une question de formulation. L'un voit les requêtes réelles de la page, son historique de modifications et les règles du site. L'autre ne voit qu'une URL.

« Dis-moi comment améliorer cette page. » La consigne est courte, claire, sans ambiguïté. Elle produit pourtant des recommandations inutilisables tant que l'agent ignore ce que les internautes demandent à cette URL, ce qui a déjà été tenté, et les pages que vous avez décidé de ne plus toucher.

Le context engineering désigne les stratégies qui décident quelles informations entrent dans la fenêtre du modèle, sous quelle forme et à quel moment. Appliqué au SEO, il organise tout ce dont un agent a besoin pour trancher : performance, corpus éditorial, règles métier, outils disponibles et historique des décisions. Ce n'est pas rédiger un meilleur prompt, c'est construire le système qui alimente ce prompt.

Un agent SEO choisit ses outils et son chemin selon l'objectif qu'on lui fixe. Cette autonomie ne vaut rien si le contexte qu'il reçoit reste incomplet sur le périmètre exact de la décision.

Les neuf couches de contexte d'un agent SEO

Le prompt n'est que la dernière couche d'un empilement qui en compte neuf. Chacune répond à une question différente, et l'absence d'une seule suffit à produire une recommandation crédible mais fausse.

La couche outils mérite une précision. Le Model Context Protocol a standardisé la façon dont un modèle appelle des sources externes, ce qui rend ces couches assemblables sans développer une intégration sur mesure par outil.

Brancher un serveur ne suffit pourtant pas. Le pilotage SEO conversationnel fournit l'interface, le context engineering décide de ce qui transite à l'intérieur. Deux consultants équipés de la même stack MCP n'obtiennent pas les mêmes arbitrages, parce qu'ils ne remplissent pas les mêmes couches.

La couche mémoire est celle que presque personne ne branche. Sans elle, un agent repropose chaque semaine la recommandation que vous avez rejetée la semaine précédente, sans jamais comprendre pourquoi elle a été écartée. Un historique des décisions validées et refusées transforme un générateur de suggestions en collaborateur qui apprend de vos arbitrages.

Cas pratique : quatre versions d'un agent d'audit de page

La même consigne, « dis-moi comment améliorer cette page », change complètement de nature selon ce que l'agent a sous les yeux. Voici quatre versions du même agent d'audit, sur un site éditorial de quelques centaines d'URL.

Version 1 : le prompt seul

L'agent reçoit l'URL et la consigne. Il rend des conseils qui conviendraient à n'importe quelle page du web : structurez vos titres, enrichissez le contenu, soignez le maillage. Rien dans la réponse ne prouve qu'il a lu quoi que ce soit.

Version 2 : le contenu réel en plus

On ajoute le texte intégral de la page. L'agent cesse de généraliser et commence à décrire ce qu'il lit. Ses propositions restent pourtant décorrélées de la demande réelle : il suggère d'ajouter une section sur un sujet que personne ne cherche, parce que rien ne lui dit ce que les internautes attendent de cette URL.

Version 3 : les requêtes et la SERP

On injecte les requêtes Search Console associées à la page, leurs positions, et les questions traitées par les pages déjà classées. L'arbitrage devient possible. L'agent repère les requêtes bloquées entre la huitième et la quinzième position, et propose des ajouts nommés au lieu d'un vague « ajoutez une FAQ ».

Version 4 : l'intention business et l'historique

On ajoute le rôle de la page dans le parcours de conversion, son état d'indexation, les modifications passées et leur effet mesuré. C'est le premier palier exploitable en production. L'agent devient capable de conclure « ne touchez pas à cette page », ce qui est souvent la bonne réponse et que les trois versions précédentes ne pouvaient pas formuler.

Le même exercice fonctionne sur d'autres décisions. Un agent de maillage interne suit la même montée en charge, avec des couches différentes, et je détaille son architecture dans un article dédié.

👉 Le saut de qualité entre la version 1 et la version 4 ne vient d'aucune amélioration du prompt. Le prompt est resté presque identique du début à la fin.

Sélectionner sans noyer le modèle

Ajouter du contexte améliore les décisions jusqu'à un seuil, puis les dégrade. Anthropic le formule sans détour dans sa documentation d'ingénierie : le contexte est une ressource limitée, et l'accumulation d'informations non pertinentes dilue l'attention du modèle.

Le réflexe de tout envoyer relève donc de l'erreur d'architecture, pas de la prudence. Un export Search Console de 40 000 lignes injecté brut coûte cher et noie le signal utile. Cinq lignes choisies sur la bonne page valent mieux que le fichier entier.

Quatre mécanismes font ce tri :

• Filtrer sur le périmètre de la décision, jamais sur la disponibilité de la donnée.
• Classer les candidats avant de les présenter, par proximité sémantique ou par potentiel.
• Compresser en résumés structurés plutôt qu'en exports bruts.
• Dater chaque information, pour que l'agent sache ce qui est frais et ce qui ne l'est plus.

La recherche vectorielle sert précisément à cela. Elle réduit un corpus entier à quelques passages pertinents pour la décision en cours. Mon pipeline repose sur des chunks indexés dans une base vectorielle, une mécanique que je détaille dans mon article sur le RAG appliqué au SEO.

Le SEO devient-il du retrieval context engineering ?

Une seconde lecture circule depuis 2025 : optimiser un site reviendrait à fournir du contexte aux moteurs génératifs eux-mêmes. L'idée se tient. Un moteur génératif ne sélectionne plus une page pour un mot-clé, il assemble des passages, des entités et des preuves pour construire sa réponse.

Dans cette logique, le travail éditorial consiste à rendre l'extraction facile. Entités identifiables, relations explicites entre les concepts, réponses autoportantes, affirmations reliées à leurs sources, cohérence des informations d'une page à l'autre.

La nuance est importante, et elle est souvent gommée. Vous ne contrôlez pas le contexte interne d'un moteur IA. Vous augmentez la probabilité que vos informations soient découvertes, comprises, récupérées puis retenues au moment de la synthèse.

Le context engineering décrit un trajet : du site vers l'index, de l'index vers le retrieval, du retrieval vers la fenêtre du modèle. Présenter cette formule comme un remplacement du GEO en ferait une promesse magique de plus. C'est un cadre de lecture, pas une méthode inédite.

Comment vérifier que le contexte est bon

Un contexte se teste, il ne se décrète pas. Six questions suffisent à qualifier n'importe quel agent SEO avant de lui confier une décision.

1. La recommandation s'appuie-t-elle sur des données identifiables et citables ?
2. Ces données sont-elles assez fraîches pour la décision en cours ?
3. L'agent a-t-il reçu les règles d'exclusion du site ?
4. Peut-il justifier son arbitrage sans se contenter de reformuler la consigne ?
5. Produit-il un résultat stable sur plusieurs exécutions successives ?
6. Signale-t-il les informations manquantes au lieu de combler le vide ?

Un « non » à la sixième question coûte le plus cher. Un agent qui invente silencieusement ce qu'il n'a pas est plus dangereux qu'un agent qui refuse de répondre.

Trois actions applicables cette semaine :

• Prenez votre prompt SEO le plus utilisé et listez tout ce que l'agent ne peut pas savoir en le lisant. Cette liste est votre dette de contexte.
• Ajoutez une seule couche, la plus déficitaire, puis comparez les sorties avant et après sur dix cas réels.
• Imposez une justification traçable dans le format de sortie, avec la source de chaque affirmation.

C'est la discipline que j'applique quand je pilote des agents avec Claude Code sur des tâches SEO sensibles, du maillage interne aux mises à jour de balises en série.

Questions fréquentes

Quelle différence entre prompt engineering et context engineering ?

Le prompt engineering optimise la formulation de l'instruction, le context engineering optimise ce que le modèle a sous les yeux au moment de l'exécuter. Le premier agit sur une phrase, le second sur un système de collecte, de filtrage et de mise en forme. Sur une tâche SEO qui dépend de données réelles, le second pèse nettement plus lourd dans le résultat final.

Faut-il donner toutes ses données à un agent SEO ?

Non, et c'est même la meilleure façon de dégrader ses sorties. Un contexte saturé de données non pertinentes dilue l'attention du modèle et augmente le coût de chaque exécution. La règle utile consiste à sélectionner ce qui sert la décision en cours, puis à dater chaque information transmise.

Par quelle couche commencer quand on part de zéro ?

Commencez par les règles métier, parce qu'elles évitent les erreurs irréversibles. Un agent qui ignore vos pages en noindex, vos redirections et vos URL à ne pas toucher produit des dégâts qu'un bon corpus ne rattrapera pas. Les données de performance viennent ensuite, la mémoire des décisions en troisième.

Passez de l'agent bricolé à l'agent fiable

La plupart des agents SEO décevants ne souffrent pas d'un problème de modèle. Ils souffrent d'un problème d'alimentation. Vous leur demandez de décider avec un quart des informations qu'un consultant aurait exigées avant de trancher.

Un agent SEO n'est pas meilleur parce que son prompt est plus long. Il est meilleur parce qu'il reçoit les bonnes données, connaît les règles du site et garde la mémoire des décisions déjà prises.