Playbooks concrets

Playbook : automatisation SEO et GEO

Le SEO (Search Engine Optimization) consiste à faire remonter les pages web dans les résultats Google et Bing. Le GEO (Generative Engine Optimization) est la discipline plus récente qui vise à rendre votre contenu visible dans les réponses générées par l'IA : ChatGPT, Perplexity, Claude et outils similaires. Les deux exigent d'auditer ce qui ne fonctionne pas, de le corriger et d'indiquer aux robots d'exploration que la correction existe. Claude Code et l'API Anthropic automatisent chacune de ces étapes à grande échelle.

Un pipeline SEO automatisé typique comporte quatre phases :

1. Audit : parcourir le site, extraire les balises meta, les titres, les attributs alt, les données structurées (JSON-LD) et les scores de vitesse de page. Claude lit le HTML brut et produit une liste de problèmes priorisée.
2. Injection on-page : Claude Code modifie directement les fichiers source en insérant des balises title corrigées, des attributs meta description, des attributs alt sur les images et des blocs JSON-LD schema.org.
3. Signaux d'indexation : un petit script Node.js appelle l'API IndexNow (supportée par Bing et Yandex) pour pousser immédiatement les URLs mises à jour, et appelle l'API Google Search Console pour demander une nouvelle exploration.
4. Visibilité IA (GEO) : ajoutez un fichier llms.txt à la racine de votre site afin que les robots IA puissent lire un résumé structuré de votre site, et ajoutez des blocs JSON-LD speakable pour que les assistants vocaux et IA citent préférentiellement votre contenu.

Claude Code est idéal pour la phase d'injection car il lit, modifie et vérifie les fichiers en une seule session sans copier-coller. La Batch API d'Anthropic (50 % moins chère, limite de débit indépendante) gère la génération en masse quand vous avez besoin de centaines de meta descriptions ou de résumés de pages en une seule exécution.

Méthode : un pipeline de contenu

Un pipeline de contenu est une séquence d'étapes reproductible qui part d'une idée brute et aboutit à un contenu publié. Claude peut servir de moteur à chaque étape : brief, rédaction, alignement de voix, relecture et préparation à la publication. Exécuter ces étapes sous forme de prompts distincts et centrés produit de meilleurs résultats qu'une seule requête géante du type « rédige-moi un article ».

Les cinq étapes suivent un ordre clair :

1. Brief : définissez le sujet, le public, le nombre de mots et l'objectif en un seul prompt. Demandez à Claude de renvoyer un plan structuré pour approbation avant toute rédaction.
2. Rédaction : envoyez le plan approuvé ainsi que les sources éventuelles. Claude rédige le brouillon complet en une seule passe.
3. Voix : collez deux ou trois exemples de votre écriture existante et demandez à Claude de réécrire le brouillon pour correspondre à votre ton, à la longueur de vos phrases et à votre vocabulaire.
4. Relecture : lancez un prompt distinct demandant à Claude de jouer le rôle d'un éditeur. Il vérifie les lacunes logiques, les répétitions, les introductions faibles et les affirmations non étayées.
5. Publication : générez le livrable final, qu'il s'agisse de HTML propre, d'un fichier Markdown ou d'un email formaté, prêt à coller dans votre CMS (système de gestion de contenu) ou à envoyer directement.

Maintenir chaque étape dans son propre prompt vous offre un point de contrôle pour approuver ou ajuster avant de continuer. Cela vous permet également de choisir différents modèles Claude : utilisez claude-opus-4-8 pour les étapes de brief et d'alignement de voix où le jugement compte, et claude-sonnet-4-6 pour la rédaction en volume afin de limiter les coûts.

Playbook : jeux de données synthétiques

Un jeu de données synthétique est un ensemble de données d'entraînement ou d'évaluation généré par un modèle plutôt que collecté auprès d'humains. Quand vous avez besoin de milliers de paires question-réponse, les écrire à la main est impraticable. Le Batch API (point de terminaison asynchrone d'Anthropic pour les requêtes en volume) vous permet de soumettre jusqu'à 10 000 requêtes en un seul appel, les traite en moins de 24 heures et vous facture 50 % de moins que l'API standard. Pour la plupart des tâches de création de jeux de données, le temps d'exécution réel est inférieur à 10 minutes.

Le schéma de base est le suivant : construire une liste d'objets prompt, les envoyer en batch, interroger l'état jusqu'à la fin, puis télécharger et valider les résultats. Chaque requête dans le batch reçoit son propre custom_id (une chaîne que vous choisissez) pour pouvoir associer chaque réponse à son enregistrement source.

Décisions clés avant de commencer :

• Choix du modèle : claude-opus-4-8 pour des paires de la meilleure qualité ; claude-sonnet-4-6 pour l'équilibre entre vitesse et coût ; claude-haiku-4-5 pour le volume avec des formats simples.
• Template de prompt : un system prompt qui impose le format de sortie (JSON, sans tiret cadratin, sans noms de marques à exclure), un user prompt par ligne de vos données source.
• Passe de validation : après le téléchargement, exécuter un script qui vérifie chaque élément par rapport à votre schéma et signale les éléments vides, les doublons ou les chaînes interdites avant d'utiliser les données pour le fine-tuning.
• Limites de débit : le Batch API possède sa propre limite de débit indépendante, séparée de l'API en direct, et ne concurrence donc pas votre trafic de production.

La sortie est un fichier JSONL (JSON Lines : un objet JSON par ligne), qui est le format d'entrée standard pour les pipelines de fine-tuning tels que Hugging Face Trainer ou les scripts de fine-tuning Llama.

Playbook : recherche avec les outils web

Quand Claude Code fonctionne avec les outils web activés, il peut se déployer en éventail (lancer plusieurs recherches en même temps) plutôt que d'interroger une requête à la fois. Cela réduit considérablement le temps réel sur les tâches de recherche qui nécessitent une douzaine de sources.

La boucle de recherche comporte quatre étapes :

1. Planifier les requêtes : décomposer la question en 3 à 6 sous-questions distinctes avant de récupérer quoi que ce soit.
2. Déploiement en éventail : lancer toutes les requêtes en parallèle afin que les résultats arrivent ensemble.
3. Récupérer et vérifier : accéder aux meilleures URL, recouper les affirmations sur au moins deux sources indépendantes et signaler les contradictions.
4. Synthétiser avec des citations : rédiger la réponse en associant chaque affirmation factuelle à une source numérotée pour que le lecteur puisse la vérifier.

La vérification contradictoire consiste à essayer activement de réfuter ce que l'on vient de trouver. Avant d'accepter une affirmation, on se demande : une autre source la contredit-elle ? La source est-elle récente ? Est-elle primaire (étude originale, documentation officielle) ou secondaire (un billet de blog qui résume le travail de quelqu'un d'autre) ? Privilégiez les sources primaires et notez les dates de publication.

Lors de la rédaction de la synthèse finale, chaque phrase affirmant un fait doit se terminer par une citation entre crochets comme [1], et votre liste de sources doit inclure l'URL et la date d'accès. Cela rend le rapport vérifiable et vous protège si une source est modifiée ultérieurement.

Playbook : construire une base de connaissances

Une base de connaissances est une collection structurée de documents, de notes ou d'enregistrements qu'un agent IA peut interroger et citer. Les quatre opérations essentielles sont : ingérer (importer le contenu), dédupliquer (supprimer les doublons), lier (connecter les éléments associés), et rappeler (retrouver le bon fragment au bon moment).

Claude Code est le point d'entrée pour ces quatre opérations. Pointez-le vers un dossier et il peut lire chaque fichier, en résumer le contenu, écrire une sortie structurée (JSON, Markdown) et établir des références croisées entre les sujets. L'essentiel est de donner à Claude un schéma cohérent dès le départ afin que chaque élément ingéré dispose des mêmes champs : id, source, summary, tags et links.

La déduplication consiste à repérer le contenu sémantiquement identique même lorsque la formulation diffère. Demandez à Claude de comparer les résumés et de signaler les éléments dont le sens se chevauche au-delà d'un seuil (par exemple, 80 pour cent). La liaison consiste à identifier les éléments qui référensent le même concept et à écrire des [[wikilink]] explicites ou des références croisées JSON entre eux.

Pour le rappel, le schéma durable le plus simple est un fichier d'index en texte brut (souvent appelé INDEX.md) que Claude met à jour après chaque exécution d'ingestion. Au moment du rappel, Claude lit d'abord l'index, puis récupère uniquement les fichiers dont il a besoin. Cela maintient une faible consommation de tokens et des réponses précises. Le pipeline complet se présente ainsi :

• Étape 1 - Ingestion : Claude lit les fichiers sources, extrait les métadonnées structurées et écrit un enregistrement JSON par document.
• Étape 2 - Déduplication : Claude compare les résumés, fusionne les doublons et ajoute un champ merged_into à l'enregistrement supprimé.
• Étape 3 - Liaison : Claude parcourt tous les enregistrements et écrit des tableaux related pointant vers les identifiants associés.
• Étape 4 - Indexation : Claude régénère INDEX.md avec une ligne par enregistrement : identifiant, titre, tags.
• Étape 5 - Rappel : Au moment de la requête, Claude lit l'index, sélectionne les identifiants candidats, lit uniquement ces fichiers et répond.

Playbook : développement d'application mobile

Créer une application mobile avec Expo (un framework qui encapsule React Native pour vous permettre de faire tourner votre app sur iOS et Android depuis un seul code source) s'associe naturellement avec Claude Code. Vous décrivez un écran ou une fonctionnalité en langage courant, Claude Code génère le composant, et Expo Go (l'application de prévisualisation à installer sur votre téléphone) reflète la modification en quelques secondes via le rechargement à chaud.

La boucle de base est la suivante : ouvrez Claude Code à la racine de votre projet, demandez une fonctionnalité, examinez le diff, exécutez npx expo start pour afficher un QR code, puis scannez-le avec Expo Go. Pas de pipeline de compilation à attendre pendant le développement.

Quand vous êtes prêt à distribuer, Expo propose deux chemins :

• EAS Build (Expo Application Services) : compilation cloud qui produit un vrai binaire .apk ou .ipa sans avoir besoin de Xcode ou d'Android Studio en local.
• EAS Submit : envoie ce binaire directement sur l'App Store ou Google Play depuis la ligne de commande.

Une règle importante : après toute commande npx expo install qui ajoute une dépendance native, redémarrez le bundler Metro (le serveur de développement local qu'utilise Expo) avec le flag --clear, sinon l'application peut afficher un écran blanc. Demandez à Claude Code de vous le rappeler dans ses propres instructions.

Playbook : livrables multilingues

Un livrable multilingue est tout actif (page web, email, jeu de données, mention légale) qui doit exister dans deux langues ou plus et rester cohérent : mêmes faits, même ton, même structure, sans divergence dans le temps. Le risque est la dérive : une langue est mise à jour, les autres non.

L'approche professionnelle est la traduction à source unique : un fichier source faisant autorité est le seul endroit où les humains rédigent et valident le contenu. Chaque version linguistique en est dérivée, jamais éditée indépendamment. Claude traite cela comme un pipeline en trois étapes.

• Étape 1 - Rédiger : Écrire ou finaliser la source dans une seule langue (généralement le français ou l'anglais). La verrouiller avant de traduire.
• Étape 2 - Traduire : Transmettre la source verrouillée à Claude avec un brief de style explicite. Un appel par langue cible, ou un appel batch pour toutes les langues en même temps.
• Étape 3 - Valider : Effectuer un contrôle de cohérence : comparer les termes clés, les chiffres et les formules juridiques dans tous les résultats avant la publication.

Dans Claude Code (l'agent de codage CLI et IDE), vous pouvez automatiser ce pipeline avec un petit script qui lit le fichier source, appelle l'Anthropic API une fois par langue, écrit chaque résultat dans un fichier versionné et consigne un résumé des différences. L'Anthropic Batch API permet d'envoyer toutes les demandes de traduction en un seul appel HTTP avec 50 pour cent de remise et environ cinq minutes de temps réel pour cent requêtes, ce qui rend les grands jeux de données multilingues pratiques et économiques.

Playbook : un livrable HTML partageable

Le livrable le plus simple que vous puissiez partager par e-mail ou messagerie est un fichier HTML unique et autonome : un seul fichier, aucun serveur, aucune dépendance, qui s'ouvre dans n'importe quel navigateur par un double-clic. Le principe clé est d'inliner tout le contenu, c'est-à-dire que le CSS est placé dans une balise <style>, le JavaScript dans une balise <script>, et les images sont intégrées sous forme d'URI de données Base64 (un encodage textuel de données binaires). Rien n'est chargé depuis le réseau.

Lorsque vous demandez à Claude de produire un tel fichier, le schéma le plus fiable consiste à lui fournir une liste de contraintes explicites afin qu'il ne puisse pas ajouter accidentellement une référence externe. Erreurs courantes à interdire : un attribut href pointant vers un CDN, un attribut src pointant vers une URL externe, et tout énoncé import effectuant une requête à l'exécution.

Avant d'envoyer le fichier, validez-le hors ligne : déconnectez-vous d'Internet (ou désactivez le Wi-Fi), ouvrez le fichier dans votre navigateur et interagissez avec chaque fonctionnalité. Si quelque chose est vide ou défectueux, la cause est presque toujours une ressource inline manquante.

• Placez tout le CSS dans un seul bloc <style> dans le <head>.
• Placez tout le JS dans un seul bloc <script> avant </body>.
• Convertissez les images avec Node : Buffer.from(fs.readFileSync(path)).toString('base64'), puis préfixez avec data:image/png;base64,.
• Si les données sont volumineuses (une liste, un quiz), inlinez-les sous forme de variable JS, et non d'un appel fetch.

Playbook : une pile d'automatisation personnelle

Une pile d'automatisation personnelle combine trois couches : les tâches planifiées (exécuter un agent Claude Code selon un calendrier cron), les hooks (déclencher des actions avant ou après des événements Claude Code spécifiques) et un second cerveau (un dépôt de connaissances structuré, comme un vault Obsidian, que Claude peut lire et mettre à jour). Ensemble, ils transforment Claude en un assistant persistant qui travaille même quand vous n'êtes pas au clavier.

Les tâches planifiées utilisent le planificateur de tâches de votre OS (Planificateur de tâches Windows, cron sur Linux/macOS) pour appeler claude en mode headless (c'est-à-dire sans terminal interactif, entièrement automatisé). Le flag --print fait écrire la réponse de Claude sur stdout et quitter immédiatement, ce qui est idéal pour les scripts. Combinez-le avec -p "votre prompt" et redirigez la sortie vers un fichier journal ou dirigez-la vers un autre outil.

Les hooks sont des commandes shell enregistrées dans .claude/settings.json sous la clé hooks. Claude Code les déclenche à des points définis du cycle de vie : PreToolUse, PostToolUse, Stop et Notification. Un hook Stop, par exemple, peut automatiquement synchroniser un fichier mémoire vers votre vault à chaque fin de session, afin de ne jamais perdre le contexte entre les sessions.

• Actualisation planifiée : un agent nocturne récupère de nouvelles données, met à jour les notes et valide les modifications.
• Hook Stop : écrit un résumé de session dans MEMORY.md au moment où Claude se termine.
• Hook PreToolUse : valide ou journalise chaque écriture de fichier avant qu'elle ne se produise.
• Lectures du second cerveau : Claude lit des fichiers markdown structurés depuis votre vault au démarrage de session pour restaurer le contexte complet en quelques secondes, plutôt que de relire le code brut.

Playbook : transformer une corvée en skill

Chaque flux de travail comporte des tâches répétitives : lancer le même audit, générer le même rapport, appliquer la même liste de vérification à la revue de code. La première fois, on improvise. La deuxième, on copie depuis l'historique. La troisième, il faut un skill. Un skill est un fichier d'instructions réutilisable que Claude Code charge à la demande via une commande slash, pour ne plus résoudre deux fois le même problème.

Le déclencheur pour capturer un skill est simple : remarquer le moment où l'on rouvre une conversation précédente pour copier un prompt déjà écrit. Ce moment est un signal. La corvée a mérité un nom.

Un fichier skill se place dans ~/.claude/skills/<skill-name>/SKILL.md pour une utilisation globale, ou dans .claude/skills/<skill-name>/SKILL.md à l'intérieur d'un projet pour un usage limité à ce projet. Claude Code l'expose sous la forme /skill-name dans la barre de chat. Le fichier est en Markdown simple : une description en haut, puis les instructions exactes à suivre à chaque exécution.

Pour construire un bon skill, extrayez les parties invariantes (les étapes qui ne changent jamais) et laissez des espaces réservées pour les parties qui varient selon l'exécution. Les schémas courants incluent :

• Une liste de vérification de revue de code appliquée à chaque pull request
• Un générateur de notes de version qui lit git log et formate la sortie
• Un scan de sécurité qui vérifie une liste fixe de règles OWASP
• Un audit qualité de dataset exécuté avant chaque fine-tune

Playbook : se faire citer par les LLM (GEO)

Cette leçon est un playbook de terrain pour le GEO (Generative Engine Optimization : la pratique consistant à faire citer votre site par des assistants IA comme Claude, ChatGPT et Perplexity quand ils répondent à des questions). Elle est distillée de mois de pratique réelle sur des sites en production jusqu'en 2026, et le résumé honnête, d'emblée, est celui-ci : le GEO est lent, cumulatif, et repose surtout sur le fait de mériter les citations grâce à des données uniques et une expertise réelle, pas sur des astuces techniques. La couche technique décrite ci-dessous ne vous fait pas gagner de citations ; elle se contente de retirer les obstacles qui, sinon, vous rendraient invisible aux robots d'indexation et aux modèles qui décident qui est cité.

L'étape un consiste à être récupérable (fetchable). Votre fichier robots.txt (le fichier texte à la racine d'un domaine qui indique aux robots d'indexation automatisés ce qu'ils ont le droit d'accéder) doit explicitement autoriser les robots IA. Mi-2026, les robots nommés à autoriser incluent GPTBot et OAI-SearchBot (OpenAI), ClaudeBot et anthropic-ai (Anthropic), PerplexityBot (Perplexity), Google-Extended (le signal d'entraînement IA de Google, distinct du Googlebot classique), CCBot (Common Crawl, un jeu de données sur lequel beaucoup de modèles s'entraînent), Bytespider (ByteDance), Amazonbot (Amazon), et Meta-ExternalAgent (Meta). Votre robots.txt devrait aussi déclarer l'emplacement de votre sitemap (une ligne du type Sitemap: https://example.com/sitemap.xml) afin que les robots puissent découvrir chaque page systématiquement, au lieu de ne suivre que les liens qu'ils croisent par hasard.

L'étape deux consiste à être lisible sans JavaScript. La plupart des robots d'indexation des LLM n'exécutent pas le JavaScript quand ils récupèrent une page ; ils lisent la réponse HTML brute. Si votre site est une single-page app (une application dont le framework JS génère le contenu côté client après le chargement de la page) sans rendu côté serveur, les robots voient une coquille vide et rien de ce que vous avez écrit n'est jamais lu, encore moins cité. La solution consiste à livrer soit un repli noscript avec du contenu réellement rendu, soit des pages HTML statiques entièrement pré-rendues qui contiennent le texte complet, générées au moment du build ou via un service de rendu, afin que le robot reçoive la page finie dès la première requête.

L'étape trois est llms.txt, un format défini sur llmstxt.org : un fichier en markdown brut à la racine de votre domaine qui fait office de plan de votre site, écrit spécifiquement pour être consommé par des modèles de langage. Un détail crucial confirmé lors d'un audit réel : chaque lien listé dans llms.txt doit pointer vers l'URL profonde réelle de cette section (par exemple https://example.com/docs/pricing), jamais vers la page d'accueil. Si chaque entrée renvoie vers la page d'accueil, un modèle qui lit le fichier n'a aucun moyen de citer une page spécifique ; il "sait" seulement que la page d'accueil existe.

L'étape quatre est les données structurées, c'est-à-dire le JSON-LD (un bloc au format JSON intégré dans le HTML d'une page qui décrit son contenu selon un schéma compris par les moteurs de recherche et d'autres systèmes) : gardez-le honnête et utilisez des types pertinents comme Course, FAQPage, Organization et Person avec des liens sameAs (des URL pointant vers vos profils officiels sur d'autres plateformes, utilisées pour confirmer l'identité). Mais connaissez ses limites. Un verdict de terrain issu de tests menés sur plusieurs assistants, daté de juillet 2026, a établi que l'influence du JSON-LD sur les citations des LLM est faible et indirecte : il alimente principalement les graphes de connaissance et les résultats enrichis des moteurs de recherche, que les LLM ne consomment ensuite que partiellement, de seconde main. Ne vous attendez pas à ce que le balisage schema à lui seul fasse bouger significativement votre taux de citation.

L'étape cinq est le vrai levier, et il est hors site (off-site), pas sur site : être mentionné sur des pages auxquelles les LLM font déjà confiance, comme les annuaires, la couverture presse, les transcriptions de vidéos YouTube, les forums et les blogs tiers faisant autorité. Une marque qui n'existe que sur son propre domaine se fait rarement citer, car le modèle n'a aucune confirmation indépendante que la marque ou l'affirmation est réelle ; c'est la corroboration par des sources externes fiables qui fait pencher la balance.

L'étape six est la mesure. Chaque mois, posez aux assistants eux-mêmes des questions directes comme "qui est [marque]" ou "meilleur [catégorie] à [lieu]", suivez le moment où votre marque commence à apparaître dans les réponses, et corrélez le changement avec ce que vous avez réellement livré (une nouvelle fiche d'annuaire, une mention presse, un llms.txt mis à jour). C'est un retour lent, souvent décalé de plusieurs semaines ou mois par rapport au travail effectué, et c'est précisément pourquoi le cadrage "cumulatif, à mériter" compte plus que n'importe quel correctif technique isolé.