Un agent qui rédige chaque jour des articles et les intègre au maillage interne

Le client et ses difficultés

Cette société de services informatiques vend des prestations pour lesquelles la visibilité dans les moteurs de recherche est une source majeure de demandes. Elle n’avait pas besoin d’un seul article par mois, mais d’un flux régulier de contenus cohérents qui renforcent son autorité dans plusieurs domaines spécialisés. C’est un travail éditorial sans fin : quelqu’un doit tenir le calendrier des sujets, éviter les doublons et savoir quels articles relier entre eux.

Le choix des mots-clés posait aussi problème. Dans les services B2B, il est facile de se concentrer sur des questions comme « combien cela coûte », auxquelles les résumés générés par le moteur répondent directement. Ce trafic n’arrive pas sur le site et, même lorsqu’il y arrive, se transforme rarement en discussion commerciale. Il fallait viser des requêtes à intention commerciale.

Troisième enjeu : la rapidité. Un nouvel article doit être signalé immédiatement aux moteurs et intégré à son cluster. Le laisser isolé pendant deux semaines revient à gaspiller le travail. Enfin, et surtout, l’agent devait renforcer les contenus déjà proches d’un bon classement, plutôt que de créer de nouvelles pages isolées que personne ne retrouverait.

Ce que nous avons mis en place

Nous avons créé un agent qui gère tout le cycle, du choix du sujet à l’évaluation des résultats. La rédaction s’appuie sur Claude, les données de performance proviennent de l’API Search Console, et l’état de l’agent, l’historique des articles et la carte des liens sont stockés dans Supabase. Le processus est planifié sur un serveur.

Chaque exécution commence par l’analyse d’un graphe de connaissances interne. L’agent examine les clusters déjà couverts, repère les lacunes et identifie ce qui génère réellement des impressions dans chaque domaine. Il choisit alors un sujet qui comble un manque au lieu de répéter ce qui existe déjà.

Il sélectionne ensuite le mot-clé. L’agent croise les données de Search Console et les suggestions du moteur de recherche, puis écarte les requêtes auxquelles le moteur répond sans visite du site. Pour la requête retenue, il examine les résultats existants et rédige un article assorti d’une section de questions-réponses balisée avec des données structurées.

L’article est publié directement en production, dans les deux langues. L’agent envoie aussitôt une notification IndexNow aux moteurs, puis crée le maillage. Il ne se contente pas d’ajouter des liens dans le nouvel article : il revient aussi sur les anciens articles du même cluster pour les relier à cette nouvelle publication.

Un mode d’amélioration fonctionne séparément. Les requêtes classées entre la huitième et la trentième position sont considérées comme des contenus à optimiser, et non comme une raison d’écrire un nouvel article depuis zéro. L’agent revient ensuite mesurer l’effet de l’intervention.

Fonctionnement actuel

L’agent tourne en continu et publie un ou deux articles par jour, en polonais et en anglais. Quelques minutes après chaque publication, le contenu est signalé aux moteurs et intégré au maillage interne dans les deux sens : le nouvel article renvoie vers les anciens, et les anciens vers le nouveau.

La décision de publier un nouvel article ou d’améliorer un contenu existant repose sur les données de classement réelles, et non sur un calendrier conçu plusieurs mois auparavant. Personne dans l’entreprise ne gère de calendrier éditorial : l’ordre dépend des lacunes et des contenus proches du seuil de rentabilité.

Résultats

Le système publie un à deux articles par jour dans deux langues, le polonais et l’anglais. Le maillage interne et la notification aux moteurs via IndexNow sont automatisés à chaque publication. L’agent apprend à partir des données de Search Console : ses décisions s’appuient ainsi sur les contenus qui se classent réellement.

Ce que nous ferions autrement

La première version produisait de bons articles, et c’était justement le problème : de bons textes sans cluster ni maillage ne changent pas grand-chose. Nous avons ajouté plus tard le graphe de liens et le mode d’amélioration, qui ont produit les résultats. Si nous recommencions, nous construirions d’abord la carte des clusters et le mécanisme de maillage, puis ajouterions la rédaction.

Nous avions également sous-estimé la tendance de l’agent à choisir des requêtes informationnelles. Les recherches auxquelles le moteur répond directement paraissent intéressantes dans les statistiques et séduisent le modèle. Le filtre devait donc les exclure de manière stricte et explicite : une simple recommandation dans les instructions ne suffisait pas.