Automatiser la rédaction SEO avec Claude Code : la méthode Ahrefs

Son secret ? La mise en place d'un système pour Claude Code. Avec lui, vous pouvez obtenir un brouillon publiable en moins de 12 minutes. Je sais, ça paraît fou sur le papier. Mais le fait est qu'en suivant les bonnes étapes, ça fonctionne extrêmement bien !

La personne à avoir mis au point cette méthode est Ryan Law, directeur du content marketing chez Ahrefs. Son objectif : automatiser la partie pénible du travail rédactionnel grâce à une utilisation judicieuse de l'IA. Dans ce guide, je vous transmets sa technique (en français !) pour générer des brouillons publiables en quelques minutes avec Claude Code.

Avant d'entrer dans le vif du sujet, laissez-moi vous faire une piqûre de rappel.

Claude Code est un outil en ligne de commande développé par Anthropic. Il permet de déléguer des tâches à Claude, le modèle d'IA, directement depuis votre terminal. Ce n'est donc pas un chat avec lequel vous pouvez discuter comme Claude.ai et ChatGPT : on parle d'un outil bien différent !

Claude Code peut :

Pour la rédaction de contenu, c'est surtout ce dernier point qui m'intéresse. Connaissez-vous Ahrefs MCP ? Avec lui, Claude Code peut interroger l'API Ahrefs en direct. Ça lui permet de :

En somme, Claude n’hallucinera plus les données SEO accessibles via Ahrefs (comme ça peut être le cas avec la plupart des IA) : ici, vous profitez d'informations fiables et faciles d'accès !

Content engineering : c'est un terme que Ryan Law emploie dans ses explications. Et en analysant ses recherches, je remarque bien qu'il s'agit d'un concept différent de la simple rédaction assistée par IA. Là où la rédaction assistée va utiliser l’IA comme une plume qui génère des mots, le content engineering va plutôt mettre en place une « infrastructure » qui gère la production de contenu. Je m’explique.

[recommendation title="Définition" bgcolor="default"]

Le content engineering, comme je l’ai dit, ce n'est pas écrire du contenu avec ChatGPT à côté ! C'est concevoir tout un système qui :

Ici, on ne travaille plus avec un prompt : tout se trouve dans le fichier de skill (une sorte de documentation) que vous allez fournir à Claude Code.

Avant de vous lancer dans la mise en place technique, je vous recommande vivement de poser ces trois règles. Si vous les sautez, vous risquez de construire un système qui ne vous servira à rien, si ce n'est produire du mauvais contenu.

Attention à ne pas tomber dans ce piège ! Un système d'IA bien configuré n'est pas là pour compenser un manque d'expérience en rédaction web. Au contraire, il est là pour amplifier votre expertise.

En écrivant vos skills, vous allez « codifier » vos connaissances du métier. Si ces dernières sont solides, le système va produire du bon contenu. Si vous restez trop flou(e), il risque de générer un contenu tout aussi flou. L'outil ne crée pas de l'expertise à partir de rien !

[recommendation title="Notre conseil" bgcolor="default"]

Écrivez une skill UNIQUEMENT sur une étape rédactionnelle que vous savez déjà bien faire à la main. Par exemple, si vous ne savez pas auditer un content gap manuellement, ne demandez pas à Claude Code de le faire à votre place.

Utilisez ce système seulement sur des sujets que vous maîtrisez vraiment. Concrètement, ça doit être sur :

Personnellement, concernant le blog Ahrefs, ça veut dire que je peux me permettre d'utiliser ce système sur tout ce qui est SEO, GEO, content marketing ou encore stratégie de mots-clés. En revanche, je ne vais pas m'aventurer dans la cryptographie post-quantique ou je ne sais quoi. Même si l'IA peut me sortir un texte qui sonne (sûrement) très bien sur le sujet, il me sera impossible de valider sa véracité par manque d'expertise.

[recommendation title="Notre conseil" bgcolor="default"]

Faites-vous une liste de sujets « IA-éligibles » sur un outil comme Google Sheets, histoire de pouvoir la mettre à jour facilement dès que nécessaire. C'est un garde-fou qui sera très pratique pour éviter de rédiger des contenus que vous ne maîtrisez pas.

Oui, cela peut paraître assez paradoxal vu la manière dont je vous parle de cette méthode. Avec elle, vous pourriez aisément publier 30, 50 ou même 100 articles par mois sur un même site. Mais je vous le déconseille vivement.

L'objectif de ce système n'est pas de faire de gros volumes. C'est de :

Pour un blog, s'il n'y a qu'un seul rédacteur impliqué, je dirais que l'idéal est de produire 3 à 4 contenus par mois. Ni plus, ni moins. Si vous vous appliquez à rendre ces articles qualitatifs, experts et bien optimisés, pas besoin d'en remettre une couche. Google et les LLMs seront déjà ravis de vos contenus !

Maintenant, voici comment Ryan Law organise concrètement son système avec Claude Code.

Au lieu d'écrire un méga-prompt qui demande à Claude de « créer un article SEO », découpez la production en plusieurs étapes. Placez-les ensuite dans leur propre fichier Markdown en suivant cet exemple :

Voici justement comment Ryan Law organise ses propres fichiers de skills :

Comme vous le voyez, chaque fichier doit contenir 3 éléments :

Complétez tout cela avec un fichier de skill principal (blog-pipeline.md) qui servira à déclencher tous les autres fichiers dans le bon ordre. C'est celui que vous devez appeler pour générer un article complet.

Si vous laissez la génération de contenu se faire d'un bout à l'autre sans rien sauvegarder, vous allez obtenir un article au bout de 10 minutes. Mais si le résultat est mauvais ? Vous n'aurez alors aucun moyen de savoir où le système a déraillé.

Je vous conseille donc de laisser chaque étape produire son propre fichier. Le plan va être sauvegardé dans outlines/, la recherche dans research/, le brouillon section par section dans drafts/ et ainsi de suite.

Si vous remarquez un résultat final décevant, remontez étape par étape pour identifier celle qui a posé problème. Vous pouvez ainsi ajuster le fichier de skill correspondant et redémarrer depuis cette étape, sans tout reprendre à zéro.

C'est aussi pour ça qu'on parle de content engineering : ici, on applique une logique d'ingénieur au contenu. Et c'est ce qui rend ce système aussi fiable et pérenne.

L'erreur que vous pourriez faire au départ, c'est d'écrire des skills très longs et précis, avec plein d'exemples et de cas particuliers. Car logiquement, on peut se dire : « plus j'en dis à Claude, mieux c'est, car il comprendra encore mieux ce que je veux ».

En réalité c'est faux. Au-delà d'un certain seuil, les fichiers de skill trop longs dégradent les résultats au lieu de les améliorer. En donnant trop d'instructions, on perd de vue l'essentiel et le modèle finit par s'attarder sur des détails inutiles.

L'idéal ? Tester chaque skill avec et sans certaines instructions. Comparez les résultats et gardez uniquement ce qui apporte vraiment quelque chose au contenu. Anthropic propose d'ailleurs un skill creator pour vous aider à automatiser cette comparaison.

[recommendation title="Notre conseil" bgcolor="default"]

Quand vous ajoutez une instruction à un fichier de skill, supprimez-en une autre. Cela va vous inciter à être plus synthétique, précis et à améliorer vos résultats.

Pour rédiger un article SEO sérieux, c'est sûrement le pilier le plus important, puisqu'il s'appuie directement sur les critères EEAT de Google.

Par défaut, les LLMs sont d'excellents producteurs de prose. Cependant, ils ont tendance à inventer des chiffres, générer des sources approximatives et passer à côté de l'intention de recherche réelle. S'il n'y a pas de cadre, vous allez créer du contenu qui sonne bien mais qui ne tient pas vraiment la route quand on creuse.

Je vous recommande donc d'imposer explicitement à Claude Code d'aller chercher des données là où elles existent vraiment. Par exemple avec :

Sans ce cadrage, l'IA va juste parler pour ne rien dire. Ryan Law explique justement que dans ce contexte, les IA deviennent des bloviators, c'est-à-dire qu'elles vont nous dire des choses qui paraissent cohérentes mais qui sont en réalité très creuses.

Avec un tel système, les corrections finales sont beaucoup moins efficaces qu'un bon cadrage de départ.

Plutôt que de laisser Claude produire un brouillon générique puis de passer 1h à le corriger après coup, donnez-lui quelques phrases de cadrage dès le début du process. Par exemple, si vous rédigez un article sur la recherche à facettes, dites-lui :

« Prends un angle e-commerce français, donne des exemples concrets avec Cdiscount, Decathlon ou Vinted et insiste sur la documentation Google de décembre 2024 à propos de la navigation à facettes. »

Ces quelques lignes vont radicalement changer la qualité du brouillon final. Le système va les sauvegarder dans un fichier dédié au contexte et qu'il utilisera comme référence à chaque étape.

Avant de publier un article, lisez attentivement chaque mot qui sort du système. C'est une étape à ne jamais sauter.

Mais bon, il faut admettre que lire des fichiers Markdown bruts dans VSCode, ce n'est pas agréable ni bien efficace. En plus de vous faire mal aux yeux, vous risquez de passer à côté de plusieurs soucis comme des sections déséquilibrées, des paragraphes trop denses ou de mauvaises transitions.

Je vous conseille donc de faire comme Ryan Law et de créer un fichier de skill qui convertit chaque brouillon en un aperçu HTML stylisé au plus proche du rendu final. Faites-le s'ouvrir automatiquement dans Chrome et relisez-le comme s'il s'agissait déjà de l'aperçu pré-publication. Avant même l'intégration, oui !

Tout de suite, vous pourrez remarquer :

Le système que je décris ici n'est pas universel. Bien au contraire, Ryan Law lui-même conseille vivement de le personnaliser selon ses besoins. Si vous voulez l'adopter, calibrez-le sur :

Chaque rédacteur est différent. Et c'est ce qui fait toute la richesse de notre métier ! Tout comme votre voix est unique, la façon dont vous utilisez ces outils doit aussi l'être.

Si vous voulez monter ce système dans une équipe, je vous recommande de partager une base commune (les principes, Ahrefs MCP, les outils techniques…) mais de laisser chacun adapter son propre dossier de skills. N'imposez pas un système unique à toute l'équipe : laissez chaque copilote gérer le tout à sa manière.

Le système dont je vous parle a surtout été popularisé parmi les anglophones. Puisqu'on parle ici principalement de rédaction francophone, j'ai relevé quelques petites adaptations qui me semblent importantes à avoir en tête.

On ne va pas le cacher : la grande majorité des références sur le web sont rédigées en anglais. Pour enrichir le corpus de Claude Code, vous aurez donc beaucoup moins d'articles français à lui offrir.

Il faut donc :

Justement, je vais revenir plus en détail sur le dernier point énoncé : le ton.

Les LLMs produisent un français plus que correct (et ils ne cesseront sans doute jamais de progresser sur ce point), mais ils ont tendance à tomber dans un français très « anglais ». Je m'explique.

Puisque la grande majorité des IA s’appuient sur de l'anglais, les contenus produits dans d'autres langues (dont le français) ont tendance à intégrer des anglicismes.

Par exemple, si vous rédigez des articles médicaux, sachez que le terme « condition médicale » est un calque direct de l'anglais (medical condition) que les LLMs aiment beaucoup reprendre.

Comme j'écris régulièrement pour des marques qui abordent des sujets comme l'eczéma ou le psoriasis, c'est une expression que je vois souvent revenir. Si un jour vous vous retrouvez dans mon cas, je vous conseille d'opter pour des termes plus français comme « affection » ou « trouble de santé » (selon le contexte précis).

Bref, pour vos skills, je vous recommande d'intégrer des instructions très explicites. Pour Ahrefs, ça donnerait quelque chose comme :

La liste peut clairement être étoffée, mais vous voyez l'idée. Sans ce type de consignes, vous obtiendrez du français acceptable mais peut-être pas celui que vous visez.

Pour mettre en place un bon système de production de contenu avec Claude Code, vous allez probablement devoir y passer du temps en amont. Il faudra aussi faire preuve de rigueur et de discipline pour que cela fonctionne dans la durée. Mais croyez-moi, ça en vaut vraiment la peine quand on voit le résultat.

Dans les grandes lignes, voici ce que je vous conseille de retenir :

Si vous voulez tester cette méthode, je vous suggère d'aller au plus simple :

Dès que vous vous sentirez à l'aise avec le système, vous pourrez passer à l'étape supérieure et intégrer plus de fichiers de skills ou gérer d'autres types d'articles. Si vous vous précipitez, c'est là que vous risquez le plus de produire du contenu médiocre.

Des questions sur la mise en place de ce système ? Retrouvez Ahrefs sur LinkedIn, l'équipe sera ravie d'en discuter avec vous !