Le site d’un éditeur de contenus pédagogiques disposait d’un menu secondaire de neuf rubriques, organisé historiquement selon la structure interne de l’équipe éditoriale plutôt que selon les habitudes réelles de navigation des visiteurs. Ce cas décrit un test mené sur trois mois, où un agent analysait mensuellement les données de navigation pour proposer une réorganisation, sans jamais l’appliquer lui-même. Il ne traite pas les recommandations de contenu par embeddings, sujet distinct déjà couvert ailleurs.
L’équipe souhaitait vérifier une hypothèse précise : est-ce qu’une analyse régulière du comportement réel des visiteurs, plutôt qu’une refonte ponctuelle décidée une fois pour toutes, permettrait d’ajuster progressivement la navigation à mesure que les habitudes évoluent.
Les données analysées par l’agent
Chaque mois, un outil MCP transmettait à l’agent un export anonymisé des parcours de navigation : taux de clic sur chaque entrée du menu, chemins de sortie les plus fréquents, et taux de rebond par rubrique. Aucune donnée individuellement identifiable n’entrait dans cette analyse, uniquement des agrégats déjà anonymisés en amont par l’outil d’analytics du client.

La proposition générée
À partir de ces données, l’agent produisait une proposition de réorganisation argumentée : quelles rubriques regrouper sous un intitulé commun, lesquelles remonter en position plus visible compte tenu de leur taux de clic élevé malgré une position actuelle peu favorable, et lesquelles descendre faute d’usage réel. Chaque proposition était accompagnée des chiffres qui la justifiaient, pas d’une simple suggestion sans preuve.
{
"proposition": [
{
"action": "remonter",
"rubrique": "Ressources pour enseignants",
"position_actuelle": 7,
"position_proposee": 2,
"justification": "Taux de clic parmi les plus élevés du menu malgré une position peu visible"
},
{
"action": "fusionner",
"rubriques": ["Actualités", "Vie de la communauté"],
"justification": "Moins de 2 % de clics combinés, chemins de sortie très proches"
}
]
}
La validation humaine systématique
Aucune proposition n’a été appliquée automatiquement. Chaque mois, la responsable éditoriale examinait la proposition avec les chiffres à l’appui, et décidait de l’appliquer telle quelle, de l’ajuster, ou de la refuser en expliquant pourquoi. Sur les trois mois du test, une proposition sur trois a été appliquée sans modification, une a été ajustée avant application, et une a été refusée entièrement, l’équipe jugeant la fusion proposée contraire à une convention éditoriale que les chiffres seuls ne pouvaient pas capturer.
| Mois | Décision de l’équipe |
|---|---|
| Mois 1 | Appliquée sans modification |
| Mois 2 | Ajustée avant application |
| Mois 3 | Refusée |
Pourquoi le test s’est limité au menu secondaire
L’équipe a délibérément choisi de ne pas confier la navigation principale du site à ce processus, jugeant l’enjeu trop important pour un test encore en phase d’évaluation. Le menu secondaire, moins visible mais représentatif d’un usage réel, offrait un terrain suffisant pour juger de la pertinence de la méthode sans exposer la structure de navigation la plus critique du site à un processus encore expérimental.
Tester une méthode sur un enjeu secondaire avant de l’étendre à ce qui compte le plus n’est pas de la prudence excessive : c’est simplement la façon la plus raisonnable de vérifier qu’elle tient ses promesses.
Résultat mesuré
Sur les rubriques remontées en position plus visible à la suite des propositions validées, le taux de rebond a baissé de 23 % en moyenne sur la période suivant l’application, comparé à la même période l’année précédente sur les mêmes rubriques. Ce chiffre ne permet pas d’isoler entièrement l’effet de la réorganisation d’autres facteurs saisonniers, mais la direction observée reste cohérente avec l’hypothèse de départ.
En résumé
Ce cas montre qu’une analyse récurrente du comportement de navigation par un agent peut produire des propositions concrètes et argumentées, à condition de garder la décision d’application entièrement du côté humain. La valeur de l’exercice n’est pas venue de la capacité de l’agent à décider seul, mais de sa capacité à transformer des données brutes d’analytics en propositions lisibles et discutables par une équipe éditoriale qui n’avait pas le temps de les analyser elle-même chaque mois.