5 skills pour construire un système SEO

---
name: seo-geo-audit
description: |
  Audit GEO (Generative Engine Optimization) d'une page ou d'un texte : note le contenu sur 7 scores algorithmiques (Surprise, Grounding, Content Effort, Alignement RRF, RAG Structurer, Freshness Guard, Action Engine) pour détecter la "Médiocrité Statistique" et garantir la citation par les moteurs génératifs (Google SGE / AI Overview, SearchGPT, Perplexity). Pipeline en 5 étapes : cadrer le texte + l'intention → noter les 7 scores avec problèmes localisés → calculer le score global → prioriser les corrections → plan de réécriture. Règle anti-hallucination stricte : aucun chiffre ni date inventé, placeholder [À SOURCER] obligatoire.

  TOUJOURS utiliser ce skill quand l'utilisateur dit : "audit GEO", "score GEO", "optimiser pour les moteurs génératifs", "GEO Sentinel", "mon texte est-il citable par l'IA", "SGE / AI Overview", "pourquoi ChatGPT/Perplexity ne me cite pas", "analyse ce texte pour le GEO", "Surprise Score", "Grounding Score d'une page", "ce contenu survivra-t-il aux filtres IA".
---

# Skill : Audit GEO (GEO Sentinel)

## Quand déclencher

Auditer une page ou un texte déjà rédigé pour le GEO (Generative Engine Optimization) : savoir s'il sera cité par les moteurs hybrides (Google SGE / AI Overview, SearchGPT, Perplexity) ou rejeté comme contenu générique.

Diffère de `seo-entites-vectorielles` (qui prépare les entités *avant* rédaction) et de `seo-workflow-article` (qui *rédige*). Ici on **note un texte existant** et on liste les corrections.

## Posture

Tu n'es pas un coach bienveillant, tu es un **Validateur de Signaux**. Un texte n'est pas de la littérature, c'est un ensemble de vecteurs de données. Tu rejettes :

- un texte agréable mais vide de preuves → risque d'hallucination ;
- un texte juste mais qui répète le consensus → Low Surprise, oubli mémoriel ;
- un texte qui explique sans permettre d'agir → pas d'Action Engine.

Sois impitoyable mais constructif : chaque problème détecté doit être actionnable.

## Concepts clés

- **Médiocrité Statistique** : le contenu que n'importe quelle IA aurait pu générer ; cible n°1 de l'audit.
- **Surprise Metric** (architecture Titans) : le gradient d'apprentissage, seul le contenu à fort gradient est gravé en Neural Memory, le reste est oublié.
- **Grounding Score** : densité de triplets [Sujet] + [Relation] + [Entité/Valeur] ; l'ancrage factuel.
- **Weight Decay** : l'oubli architectural des contenus anciens : justifie le Freshness Guard.
- **Answer-first pattern** : réponse directe dans les 2-3 premières phrases ; nourrit le RAG Structurer.

## Input requis

| Source | Obligatoire |
|--------|-------------|
| Le texte à auditer (page, article, section) | Oui |
| La requête cible / l'intention principale visée | Oui |
| Le secteur + le type de page (éditorial, produit, locale) | Recommandé |
| Les concurrents top 10 (pour juger la divergence) | Optionnel |

## Les 7 scores GEO

Chaque score est noté **0-100**. Pour chaque score, lister les **problèmes localisés** : phrase problématique + raison précise et actionnable.

### 1. Surprise Score : algorithme de mémorisation
- Mesure le gradient d'apprentissage du texte.
- Cherche : distance sémantique au consensus, inversion de valeur, data propriétaire.
- Exigence : le texte doit contenir **une donnée que tu es le seul à posséder**.
- Problèmes typiques : répétition du consensus, similarité avec Wikipédia, absence de thèse originale.

### 2. Grounding Score : l'ancrage factuel
- Mesure la densité de triplets [Sujet] + [Relation] + [Entité Nommée/Valeur].
- Cherche : dates précises, chiffres, noms de lois, citations exactes.
- Exigence : **2 preuves atomiques par 100 mots minimum**.
- Problèmes typiques : affirmations vagues, "bientôt", "important", absence de données chiffrées.

### 3. Content Effort : preuve de travail humain
- Mesure les signaux que l'IA ne peut pas simuler (E-E-A-T).
- Cherche : "j'ai testé", méthodologie, processus documenté, anecdotes d'échec.
- Exigence : prouver **plus de 30 secondes de travail réel**.
- Problèmes typiques : synthèse générique, absence d'expérience personnelle, théorie pure.

### 4. Alignement RRF : Reciprocal Rank Fusion
- Mesure la couverture vectorielle et les micro-intentions.
- Cherche : réponse aux intentions explicites ET latentes (prix, intégration, support…).
- Exigence : **aucun trou sémantique** dans la couverture de la requête.
- Priorité : intentions explicites, questions fréquentes, micro-intentions. Les objections enrichissent le contexte mais sont optionnelles (impact limité, ~5%).
- Problèmes typiques : aspects implicites manquants, questions Know/Do/Comparatif non répondues.

### 5. RAG Structurer : lisibilité machine
- Mesure la capacité d'un Retriever à parser le contenu.
- Cherche : proximité titre-réponse (**<30 mots après un H2**), tableaux, listes structurées.
- Exigence : **pyramide inversée** à chaque section, format natif LLM (answer-first).
- Problèmes typiques : intros vagues, structure narrative, absence de tableaux comparatifs.

### 6. Freshness Guard : biais de récence
- Mesure l'obsolescence du contenu (conséquence du Weight Decay).
- Cherche : dates récentes, mentions temporelles explicites.
- Exigence : références à **2026**, mention "À jour en [Mois]".
- Problèmes typiques : données de 2023 ou antérieures, absence de timestamp.

### 7. Action Engine : utilité & conversion
- Mesure la capacité du texte à permettre l'action.
- Cherche : verbes d'action, liens vers outils / templates / calculatrices.
- Exigence : transformer le "Savoir" en "Faire".
- Problèmes typiques : explication théorique sans outil, absence de call-to-action fonctionnel.

## Pipeline (5 étapes)

1. **Cadrer** : récupérer le texte, la requête cible et le type de page. Vérifier la longueur minimale exploitable (au moins 100 caractères).
2. **Noter les 7 scores** : passer le texte au crible des 7 critères ci-dessus ; pour chacun, noter 0-100 et lister chaque problème (phrase + raison).
3. **Calculer le score global** : moyenne arithmétique des 7 scores, arrondie. Compter le nombre total de problèmes.
4. **Prioriser les corrections** : trier les scores du plus bas au plus haut ; attaquer d'abord les 2-3 scores les plus faibles (effort de correction le plus rentable).
5. **Plan de réécriture** : pour chaque problème prioritaire, une action concrète. Aucune réécriture inventée : si une donnée chiffrée ou une date manque, marquer `[À SOURCER]`.

## Barème de lecture du score global

| Score global | Verdict | Action |
|--------------|---------|--------|
| 80-100 | Citable | Corrections cosmétiques, refresh périodique |
| 60-79 | Fragile | Corriger les 2 scores les plus bas avant publication |
| 40-59 | À retravailler | Réécriture des sections faibles, injection de data |
| 0-39 | Médiocrité Statistique | Le contenu n'aurait pas dû exister tel quel : refonte |

## Output obligatoire

```
AUDIT GEO, Requête : "[Requête cible]"
Type de page : [éditorial / produit / locale]

| Score | Note /100 | Problèmes | Diagnostic court |
|---|---|---|---|
| Surprise | 38 | 4 | Répète le consensus, aucune data propriétaire |
| Grounding | 52 | 6 | 0,8 preuve / 100 mots, sous le seuil de 2 |
| Content Effort | ... | ... | ... |
| Alignement RRF | ... | ... | ... |
| RAG Structurer | ... | ... | ... |
| Freshness Guard | ... | ... | ... |
| Action Engine | ... | ... | ... |

SCORE GLOBAL : XX/100, [Verdict] | Problèmes totaux : XX

Problèmes localisés (extraits) :
- [Surprise] « phrase exacte » → raison + correction proposée
- [Grounding] « phrase exacte » → raison + correction proposée

Plan de réécriture priorisé :
1. [Score le plus bas] : action concrète
2. [Score suivant] : action concrète
3. ...
```

## Règle anti-hallucination (absolue)

- Ne jamais inventer un chiffre, une date, une statistique ou une source pour "remplir" un score Grounding ou Freshness.
- Toute donnée manquante recommandée → placeholder `[À SOURCER]`, jamais une valeur fabriquée.
- Ne pas inventer une anecdote d'expérience pour gonfler le Content Effort : signaler que l'auteur doit en fournir une.

## Règles absolues

- Identifier **tous** les problèmes, même mineurs : un audit complaisant ne sert à rien.
- Citer la phrase exacte du texte pour chaque problème : un problème non localisé n'est pas corrigeable.
- Ne jamais noter un score sur l'impression générale : chaque note doit s'appuyer sur des problèmes listés (ou leur absence).
- Le score global est une moyenne des 7, pas une somme pondérée : aucun score ne "rachète" un autre.
- Le Surprise Score sans data propriétaire plafonne : une bonne structure ne compense pas l'absence d'info unique.

## Enchaînement workflow

En amont : `seo-entites-vectorielles` (cartographie des entités à intégrer). En aval, selon les scores faibles : `seo-workflow-article` (réécriture complète), `seo-product-led-seo` (si Action Engine faible → créer un outil), `seo-brief-contenu` (si Alignement RRF faible → re-briefer la structure Hn).

## Sauvegarde

Output dans un fichier `geo-audit-YYYY-MM-DD-slug.md`.

## Concepts liés

surprise-metric · grounding-score · surprise-gap · weight-decay · rrf · answer-first-pattern · structural-information-geo · metriques-visibilite-geo · e-e-a-t · fully-meets

---
name: seo-recherche-mots-cles
description: |
  Recherche de mots-clés from scratch : partir d'une thématique ou de quelques seed keywords et produire une liste exhaustive, qualifiée et priorisée, chaque mot-clé avec son intention et sa difficulté. Pipeline en 5 étapes : cadrer la thématique → expansion sémantique → qualification (intention/difficulté) → filtrage du bruit → tableau priorisé. Règle : volume optionnel (affiché seulement s'il vient d'une donnée réelle, jamais estimé), difficulté jamais inventée. Sortie obligatoire : une section de pré-décision (statut RAW / HYPOTHÈSE / VALIDÉ / OBSOLÈTE / BLOQUÉ, pré-décision URL par cluster ou raison de non-décision, score business sur 5, documents de la base documentaire du projet, matière qualifiée, SERP) qui nourrit le rapport de pré-décision du workflow mots-clés ; sans elle le skill n'a pas terminé.

  TOUJOURS utiliser ce skill quand l'utilisateur dit : "recherche de mots-clés", "trouve-moi des mots-clés", "keyword research", "liste de mots-clés sur [thème]", "quels mots-clés cibler", "explore les requêtes sur", "j'ai une thématique, sors les mots-clés", "expansion de mots-clés".

  Première brique du workflow mots-clés : sa sortie alimente seo-clustering-mots-cles puis seo-mots-cles-decisionnels.
---

# Recherche de mots-clés

## Quand déclencher

Partir d'une thématique ou de seed keywords et produire une liste de mots-clés exhaustive, qualifiée et priorisée. C'est l'amont de tout : tant que la liste n'existe pas, ni le clustering ni le brief n'ont de matière.

## Doctrine

- **Colonne Volume optionnelle** : le volume peut figurer dans le livrable si les chiffres viennent d'une donnée réelle (GSC, Keyword Planner, Ahrefs, Semrush). Sans donnée réelle, pas de colonne plutôt qu'un chiffre estimé. La difficulté reste un proxy déclaratif, jamais un chiffre inventé.
- On ne part pas des concurrents. On part de l'intention de l'audience et de l'offre.
- Un mot-clé sans intention claire n'est pas un mot-clé, c'est du bruit.
- Exhaustivité d'abord, tri ensuite : générer large, filtrer après.

## Input requis

| Source | Obligatoire |
|--------|-------------|
| Thématique ou 3-5 seed keywords | Oui |
| Secteur + audience / persona | Oui |
| Offre (ce qu'on vend, point de conversion) | Oui, sinon le funnel est inqualifiable |
| Marché géo + langue | Oui |
| Export GSC / Ahrefs / Semrush si dispo | Recommandé, rend les volumes réels |

## Pipeline (5 étapes)

1. **Cadrer** : thématique, périmètre, ce qui est dans le scope et ce qui en sort.
2. **Expansion sémantique** : pour chaque seed, générer :
   - modificateurs (comment, pourquoi, prix, avis, meilleur, vs, sans…)
   - questions (patterns People Also Ask)
   - longue traîne (3 mots et plus)
   - co-occurrences et entités liées
   - synonymes et variantes lexicales
   Objectif : **50 à 150 mots-clés bruts** minimum avant tri.
3. **Qualifier chaque mot-clé** : intention (Know-Simple / Know / Do, cf. `seo-cluster-aeo`), difficulté estimée (proxy : nb de mots, présence de marques, type de SERP), étage de funnel. (Volume : optionnel, uniquement depuis une donnée réelle.)
4. **Filtrer le bruit** : retirer hors-sujet, hors-intention vs l'offre, doublons stricts, requêtes branded concurrent non pertinentes.
5. **Livrable** : tableau priorisé.

## Sortie de pré-décision (obligatoire)

Ce skill est une étape du workflow mots-clés complet [document non fourni : workflow-mots-cles-complet.md]. Sa sortie porte un `statut_decision` (RAW, HYPOTHÈSE, VALIDÉ, OBSOLÈTE, BLOQUÉ) et nourrit le rapport de pré-décision, seule sortie visible du workflow ; toute sortie de ce skill qui contredit ce rapport devient OBSOLÈTE. Format complet : [document non fourni : rapport-mots-cles-format.md].

Ce que le rapport de pré-décision rend, et que ce skill doit rendre possible sur son périmètre :

1. Diagnostic en trois lignes.
2. Pré-décision par marché (5 max) : Marché / Page / Score business sur 5 (intention 0-2, proximité offre 0-2, conversion directe 0-1) / Docs de la base documentaire (documents qui traitent le sujet, par type : transcripts, clients, notes, wiki) / Matière qualifiée (objection, cas, méthode, preuve, résultat, verbatim) / SERP (compatible, à vérifier, non vérifiée) / Pré-décision (utiliser, renforcer l'existant, créer, conserver et enrichir, analyser avant restauration, candidat avec validation SERP requise, bloqué, attendre).
3. Ce qui est bloqué, et par quoi : statut, raison, actions autorisées, actions interdites ; « décision stratégique requise » quand c'est le positionnement (cette décision revient au responsable du projet) ; « pré-décision impossible avant analyse SERP de N requêtes » sinon. Jamais « à trancher ».
4. À ne pas produire maintenant.
5. Fiabilité, une ligne ; analyse technique derrière ; logs du workflow en annexe.

Règles : signaux de demande séparés (Suggest, Search Console, calls, acteurs), jamais agrégés en verdict, aucun volume estimé ; matière comptée en documents de la base documentaire puis qualifiée par lecture, jamais en occurrences d'un mot ; « cannibalisation » interdit sans SERP ni conflit GSC, « chevauchement potentiel à vérifier » ; une requête secondaire sert à repérer une sous-intention, jamais à placer un title, un H2 ou une FAQ par défaut ; aucune page sans validation SERP + matière suffisante ; aucun brief avant une pré-décision URL VALIDÉ ; un cas ou un relevé réel par page programmatique ; scores /10 en backend ; Faible / Moyen / Élevé, jamais d'anglais ; la certitude affichée ne dépasse jamais la couverture des données.

## Output obligatoire

```
RECHERCHE MOTS-CLÉS : '[Thématique]'

| Mot-clé | Intention | Difficulté | Funnel | Demande observée | Note |
|---|---|---|---|---|---|
| ... | Know | Moyenne | Know | moyenne (Suggest 12 · GSC 0 · calls 4 · acteurs 2) | ... |
| ... | Do | Élevée | Pré-décision | forte (Suggest 40 · GSC 56 · calls 9 · acteurs 5) | ... |

Synthèse : [nb total] mots-clés · [nb] Do · [nb] Know · [nb] Know-Simple
Top 5 à prioriser : [liste]

RAPPORT DE DÉCISION (obligatoire, voir « Sortie de pré-décision ») : diagnostic, chiffres, état, P1/P2/P3 avec preuve, confiance, effort, risque. Aucun score affiché.
```

## Règles absolues

- Deux scores affichés par mot-clé ou cluster [document non fourni : rapport-mots-cles-format.md] : score business sur 5 avec ses composantes (intention 0-2, proximité offre 0-2, conversion directe 0-1) et score matière = nombre de documents de la base documentaire qui traitent le sujet (≥ 3 occurrences du champ lexical), par type de source (transcripts, clients, notes, wiki). Le comptage dit où chercher ; le verdict de matière vient de la lecture par type. Zéro document = pas de page.
- Gouvernance des pré-décisions [document non fourni : rapport-mots-cles-format.md] : une pré-décision finale par cluster avec statut VALIDÉ / À VÉRIFIER / BLOQUÉ / REJETÉ ; les sorties de ce skill sont des HYPOTHÈSES tant que le rapport n'a pas tranché, et deviennent OBSOLÈTES si elles le contredisent ; aucune page créée sans validation SERP + matière suffisante ; aucun brief avant une pré-décision URL VALIDÉ ; un candidat à la création reste « validation SERP requise » ; les scores /10 restent en backend, le rapport lit adéquation offre, intention, preuve, SERP, décision.
- Sortie finale du workflow [document non fourni : rapport-mots-cles-format.md] : une pré-décision URL par cluster (utiliser / renforcer l'existant / créer / conserver / analyser avant restauration / à confirmer après validation SERP) ou la raison explicite pour laquelle on ne peut pas encore décider (« Décision stratégique requise » pour le positionnement, « Pré-décision impossible avant analyse SERP de N requêtes ») ; jamais « à trancher ». Signaux de demande affichés séparément, jamais agrégés en verdict. Matière qualifiée par type (objection, cas concret, méthode, preuve, résultat, verbatim), jamais comptée en occurrences. « Cannibalisation » interdit sans SERP ni conflit GSC : « chevauchement potentiel à vérifier ». Une requête secondaire sert à repérer une sous-intention, jamais à placer un title, un H2 ou une FAQ par défaut.
- Signaux de demande obligatoires sur chaque mot-clé, affichés séparément et jamais agrégés en niveau : signaux possédés (variantes Google Suggest, impressions Search Console, fréquence dans les calls, acteurs spécialisés ; People Also Ask, YouTube, Trends quand disponibles), signaux bruts affichés à côté du niveau. Jamais un volume estimé ; un volume réel (Keyword Planner) s'affiche en plus, avec sa source. Méthode : [document non fourni : demande-observee.md].
- Le rapport de pré-décision fait partie de la sortie. Sans lui, le skill n'a pas terminé. Il se rédige à partir du tableau, aucune phrase sans mot-clé ou chiffre derrière, aucun score affiché.
- **Volume optionnel** : affiché seulement s'il vient d'une donnée réelle, jamais estimé. Difficulté = proxy déclaratif, jamais un chiffre inventé.
- Si un export d'outil est fourni, utiliser **ses** chiffres, ne jamais les arrondir ni les estimer au hasard.
- Générer large (50+ avant filtrage), livrer trié.
- Chaque mot-clé a une intention identifiée, ou il dégage de la liste.

## Enchaînement workflow

`seo-recherche-mots-cles` (cette liste) → `seo-clustering-mots-cles` (regroupe en pages) → `seo-mots-cles-decisionnels` (isole les convertisseurs) → `seo-brief-contenu` / `seo-cluster-aeo` / `seo-programmatique-pseo`.

## Sauvegarde

Output dans `wiki/keywords/recherche-YYYY-MM-DD-slug.md`.

## Concepts liés

`know-simple-know-do` · `funnel` · `rrf` · `clustering-mots-cles` · `mots-cles-decisionnels` · `brief-contenu`

---
name: seo-mots-cles-decisionnels
description: |
  Isole les mots-clés décisionnels : les requêtes transactionnelles et bas de funnel qui convertissent, par opposition aux requêtes informationnelles qui ne font que du trafic. Pipeline en 5 étapes : définir l'offre et le point de conversion → repérer les signaux décisionnels → classer par étage de décision → scorer le potentiel de conversion → shortlist priorisée avec page et format recommandés. Part d'une liste existante ou d'une thématique. Sortie obligatoire : une section de pré-décision (statut RAW / HYPOTHÈSE / VALIDÉ / OBSOLÈTE / BLOQUÉ, pré-décision URL par cluster ou raison de non-décision, score business sur 5, documents de la base documentaire du projet, matière qualifiée, SERP) qui nourrit le rapport de pré-décision du workflow mots-clés ; sans elle le skill n'a pas terminé.

  TOUJOURS utiliser ce skill quand l'utilisateur dit : "mots-clés décisionnels", "mots-clés transactionnels", "mots-clés qui convertissent", "requêtes bas de funnel", "requêtes Do", "mots-clés bottom funnel", "quels mots-clés rapportent", "trie ma liste par potentiel de conversion", "mots-clés commerciaux".

  Brique de conversion du workflow mots-clés : se branche après seo-recherche-mots-cles ou seo-clustering-mots-cles.
---

# Mots-clés décisionnels

## Quand déclencher

Isoler, dans une liste ou une thématique, les requêtes qui amènent un client, pas seulement du trafic.

## Doctrine

- Le trafic n'est pas l'objectif, la conversion l'est. Un mot-clé à 10 000 vues/mois sans intention d'achat vaut moins qu'un mot-clé à 80 vues qui amène un client.
- Un mot-clé décisionnel = l'internaute est en train de choisir, comparer ou acheter. Il a mentalement sorti la carte bleue.
- Le décisionnel se repère à ses **modificateurs**, pas à son volume.
- Bas de funnel ≠ forcément faible volume : "meilleur [catégorie]" peut peser lourd.
- Le décisionnel se traite en priorité : c'est le ROI le plus court du SEO.

## Input requis

| Source | Obligatoire |
|--------|-------------|
| Liste de mots-clés OU thématique | Oui |
| Offre : ce qu'on vend, prix, point de conversion (formulaire, achat, démo, appel) | Oui |
| Audience / persona | Oui |
| Autres acteurs du marché (pour les requêtes branded) | Recommandé |

## Signaux décisionnels (table de modificateurs)

| Catégorie | Modificateurs |
|-----------|---------------|
| **Achat direct** | acheter, commander, prix, tarif, devis, abonnement, s'inscrire |
| **Comparaison** | meilleur, top, vs, comparatif, alternative à, lequel choisir |
| **Évaluation** | avis, test, retour d'expérience, fiable, arnaque |
| **Local / immédiat** | près de moi, [ville], en ligne, livraison, ouvert |
| **Marque** | [ta marque], [ta marque] avis/prix, [nom d'outil] alternative |

## Étages de décision

- **Do : Achat** : l'internaute veut transformer maintenant.
- **Do : Comparatif** : il choisit entre options, toi inclus.
- **Do : Local** : intention d'achat + contrainte géographique.
- **Do : Marque** : il te connaît déjà, ou connaît un autre acteur du marché.
- **Know commercial** : "comment choisir un X", pré-décision, à capter tôt.

## Pipeline (5 étapes)

1. **Définir l'offre** : ce qu'on vend, le prix, le point de conversion réel.
2. **Repérer les signaux** : passer la liste ou la thématique au filtre des modificateurs décisionnels.
3. **Classer par étage de décision** : ranger chaque mot-clé retenu.
4. **Scorer le potentiel de conversion** : proximité à l'offre (1-5) × intention d'achat (1-5) × faisabilité de ranker (1-5), produit ramené sur une **échelle 0-10 (arrondi entier)**. Flag les requêtes branded sur un autre acteur pour vérifier la légitimité.
5. **Livrable** : shortlist priorisée ; pour chaque mot-clé : page cible (landing, comparatif, page produit, page locale), format, CTA.

## Sortie de pré-décision (obligatoire)

Ce skill est une étape du workflow mots-clés complet [document non fourni : workflow-mots-cles-complet.md]. Sa sortie porte un `statut_decision` (RAW, HYPOTHÈSE, VALIDÉ, OBSOLÈTE, BLOQUÉ) et nourrit le rapport de pré-décision, seule sortie visible du workflow ; toute sortie de ce skill qui contredit ce rapport devient OBSOLÈTE. Format complet : [document non fourni : rapport-mots-cles-format.md].

Ce que le rapport de pré-décision rend, et que ce skill doit rendre possible sur son périmètre :

1. Diagnostic en trois lignes.
2. Pré-décision par marché (5 max) : Marché / Page / Score business sur 5 (intention 0-2, proximité offre 0-2, conversion directe 0-1) / Docs de la base documentaire (documents qui traitent le sujet, par type : transcripts, clients, notes, wiki) / Matière qualifiée (objection, cas, méthode, preuve, résultat, verbatim) / SERP (compatible, à vérifier, non vérifiée) / Pré-décision (utiliser, renforcer l'existant, créer, conserver et enrichir, analyser avant restauration, candidat avec validation SERP requise, bloqué, attendre).
3. Ce qui est bloqué, et par quoi : statut, raison, actions autorisées, actions interdites ; « décision stratégique requise » quand c'est le positionnement (cette décision revient au responsable du projet) ; « pré-décision impossible avant analyse SERP de N requêtes » sinon. Jamais « à trancher ».
4. À ne pas produire maintenant.
5. Fiabilité, une ligne ; analyse technique derrière ; logs du workflow en annexe.

Règles : signaux de demande séparés (Suggest, Search Console, calls, acteurs), jamais agrégés en verdict, aucun volume estimé ; matière comptée en documents de la base documentaire puis qualifiée par lecture, jamais en occurrences d'un mot ; « cannibalisation » interdit sans SERP ni conflit GSC, « chevauchement potentiel à vérifier » ; une requête secondaire sert à repérer une sous-intention, jamais à placer un title, un H2 ou une FAQ par défaut ; aucune page sans validation SERP + matière suffisante ; aucun brief avant une pré-décision URL VALIDÉ ; un cas ou un relevé réel par page programmatique ; scores /10 en backend ; Faible / Moyen / Élevé, jamais d'anglais ; la certitude affichée ne dépasse jamais la couverture des données.

## Output obligatoire

```
MOTS-CLÉS DÉCISIONNELS : '[Offre]'

| Mot-clé | Étage | Score conv. /10 | Page cible | Format | CTA |
|---|---|---|---|---|---|
| ... | Do : Comparatif | 5/10 | Page comparatif | Tableau + verdict | Devis |

Top 3 à attaquer en premier : [liste + justification]

RAPPORT DE DÉCISION (obligatoire, voir « Sortie de pré-décision ») : diagnostic, chiffres, état, P1/P2/P3 avec preuve, confiance, effort, risque. Aucun score affiché.
```

## Règles absolues

- Deux scores affichés par mot-clé ou cluster [document non fourni : rapport-mots-cles-format.md] : score business sur 5 avec ses composantes (intention 0-2, proximité offre 0-2, conversion directe 0-1) et score matière = nombre de documents de la base documentaire qui traitent le sujet (≥ 3 occurrences du champ lexical), par type de source (transcripts, clients, notes, wiki). Le comptage dit où chercher ; le verdict de matière vient de la lecture par type. Zéro document = pas de page.
- Gouvernance des pré-décisions [document non fourni : rapport-mots-cles-format.md] : une pré-décision finale par cluster avec statut VALIDÉ / À VÉRIFIER / BLOQUÉ / REJETÉ ; les sorties de ce skill sont des HYPOTHÈSES tant que le rapport n'a pas tranché, et deviennent OBSOLÈTES si elles le contredisent ; aucune page créée sans validation SERP + matière suffisante ; aucun brief avant une pré-décision URL VALIDÉ ; un candidat à la création reste « validation SERP requise » ; les scores /10 restent en backend, le rapport lit adéquation offre, intention, preuve, SERP, décision.
- Sortie finale du workflow [document non fourni : rapport-mots-cles-format.md] : une pré-décision URL par cluster (utiliser / renforcer l'existant / créer / conserver / analyser avant restauration / à confirmer après validation SERP) ou la raison explicite pour laquelle on ne peut pas encore décider (« Décision stratégique requise » pour le positionnement, « Pré-décision impossible avant analyse SERP de N requêtes ») ; jamais « à trancher ». Signaux de demande affichés séparément, jamais agrégés en verdict. Matière qualifiée par type (objection, cas concret, méthode, preuve, résultat, verbatim), jamais comptée en occurrences. « Cannibalisation » interdit sans SERP ni conflit GSC : « chevauchement potentiel à vérifier ». Une requête secondaire sert à repérer une sous-intention, jamais à placer un title, un H2 ou une FAQ par défaut.
- Chaque cluster ou mot-clé retenu porte ses signaux de demande séparés (méthode [document non fourni : demande-observee.md]) à côté de l'intention et de la matière : intention forte + demande faible = terrain vide, « demande à confirmer » et mesure GSC à J+90, jamais une priorité présentée comme acquise.
- Le rapport de pré-décision fait partie de la sortie. Sans lui, le skill n'a pas terminé. Il se rédige à partir du tableau, aucune phrase sans mot-clé ou chiffre derrière, aucun score affiché.
- Ne jamais classer décisionnel un mot-clé purement informationnel pour gonfler la liste.
- Requête branded sur un autre acteur → vérifier la légitimité : page comparative honnête, aucune tromperie.
- Chaque mot-clé décisionnel pointe vers une page avec offre + CTA, sinon il ne convertit pas.
- Prioriser proximité à l'offre + faisabilité, pas le volume brut.

## Enchaînement workflow

Après `seo-recherche-mots-cles` ou `seo-clustering-mots-cles` → alimente `seo-product-led-seo` (outils pour les requêtes Do) et `seo-brief-contenu` (pages de conversion).

## Sauvegarde

Output dans `wiki/keywords/decisionnels-YYYY-MM-DD-slug.md`.

## Concepts liés

`know-simple-know-do` · `funnel` · `product-led-seo` · `fully-meets` · `cannibalisation` · `e-e-a-t`

---
name: seo-brief-contenu
description: |
  Brief éditorial complet avec structure Hn optimisée pour le Passage Ranking, basé sur les vecteurs sémantiques attendus par Google. Ne copie jamais les concurrents, au contraire identifie ce qu'ils n'ont pas dit. Pipeline en 7 étapes : décodage requête → vecteurs sémantiques → micro-intentions → structure Hn → contenu par H2 → signaux E-E-A-T → format multimodal. Sortie obligatoire : une section de pré-décision (statut RAW / HYPOTHÈSE / VALIDÉ / OBSOLÈTE / BLOQUÉ, pré-décision URL par cluster ou raison de non-décision, score business sur 5, documents de la base documentaire du projet, matière qualifiée, SERP) qui nourrit le rapport de pré-décision du workflow mots-clés ; sans elle le skill n'a pas terminé.

  TOUJOURS utiliser ce skill quand l'utilisateur dit : "brief", "structure Hn", "plan de page", "quels H2 mettre", "plan de rédaction SEO", "brief éditorial", "structure d'article SEO".
---

# Brief de contenu et structure Hn

## Quand déclencher

Produire un brief éditorial complet avec structure Hn optimisée pour le Passage Ranking, basé sur les vecteurs sémantiques, sans copier les concurrents.

## Doctrine

- La structure Hn est la colonne vertébrale du ranking. Mauvais plan = mauvais contenu.
- On regarde les concurrents pour identifier ce qu'ils **n'ont pas dit**, pas pour copier.
- Le brief est rédigé en premier par l'humain. L'IA améliore, elle ne crée pas.
- Chaque H2 = un vecteur sémantique attendu par Google.
- Au moins 1 H2 doit générer un Surprise Gap (contre-intuitif ou différenciant).

## Input requis

| Source | Obligatoire |
|--------|-------------|
| Mot-clé principal + cluster de requêtes | Oui |
| Micro-intentions / FAQ patterns | Oui |
| Contexte E-E-A-T (cas concrets, données propriétaires) | Recommandé |
| Type de page (landing, article, pilier) | Recommandé |

## Structure V2 (skill `seo-structure-hn-v2`)

L'étape « structure Hn » du pipeline suit `seo-structure-hn-v2` : modèle Hn (pattern 1), contenu par section réponse directe / preuve / détails / limite (pattern 2), article de méthode en mini-formation (pattern 3). Brief : une section sans matière qualifiée est marquée `[MATIÈRE MANQUANTE]`.

## Pipeline (7 étapes)

1. **Décoder la requête** : intention primaire (Info/Trans/Nav/Déc) + intentions latentes
2. **Lister les vecteurs sémantiques** : entités, co-occurrences, vocabulaire expert
3. **Identifier les micro-intentions** : avant/pendant/après la décision
3 bis. **Questions par perspective** : appliquer la méthode des questions par perspective [document non fourni : questions-par-perspective.md] (praticien, recherche, sceptique, argent, acheteur ; chaque réponse sourcée, sinon `[MATIÈRE MANQUANTE]`). Les désaccords et les trous donnent les H2 différenciants ; le tableau « Perspectives » va dans le brief
4. **Construire la structure Hn** : H1 avec différenciateur + H2 vecteurs + H3 micro-intentions + H2 FAQ
5. **Définir le contenu par H2** : type, longueur, éléments obligatoires
6. **Identifier les signaux E-E-A-T** : expérience, expertise, autorité, confiance
7. **Définir le format multimodal** : vidéo, tableau, calculateur, template

## Sortie de pré-décision (obligatoire)

Ce skill est une étape du workflow mots-clés complet [document non fourni : workflow-mots-cles-complet.md]. Sa sortie porte un `statut_decision` (RAW, HYPOTHÈSE, VALIDÉ, OBSOLÈTE, BLOQUÉ) et nourrit le rapport de pré-décision, seule sortie visible du workflow ; toute sortie de ce skill qui contredit ce rapport devient OBSOLÈTE. Format complet : [document non fourni : rapport-mots-cles-format.md].

Ce que le rapport de pré-décision rend, et que ce skill doit rendre possible sur son périmètre :

1. Diagnostic en trois lignes.
2. Pré-décision par marché (5 max) : Marché / Page / Score business sur 5 (intention 0-2, proximité offre 0-2, conversion directe 0-1) / Docs de la base documentaire (documents qui traitent le sujet, par type : transcripts, clients, notes, wiki) / Matière qualifiée (objection, cas, méthode, preuve, résultat, verbatim) / SERP (compatible, à vérifier, non vérifiée) / Pré-décision (utiliser, renforcer l'existant, créer, conserver et enrichir, analyser avant restauration, candidat avec validation SERP requise, bloqué, attendre).
3. Ce qui est bloqué, et par quoi : statut, raison, actions autorisées, actions interdites ; « décision stratégique requise » quand c'est le positionnement (cette décision revient au responsable du projet) ; « pré-décision impossible avant analyse SERP de N requêtes » sinon. Jamais « à trancher ».
4. À ne pas produire maintenant.
5. Fiabilité, une ligne ; analyse technique derrière ; logs du workflow en annexe.

Règles : signaux de demande séparés (Suggest, Search Console, calls, acteurs), jamais agrégés en verdict, aucun volume estimé ; matière comptée en documents de la base documentaire puis qualifiée par lecture, jamais en occurrences d'un mot ; « cannibalisation » interdit sans SERP ni conflit GSC, « chevauchement potentiel à vérifier » ; une requête secondaire sert à repérer une sous-intention, jamais à placer un title, un H2 ou une FAQ par défaut ; aucune page sans validation SERP + matière suffisante ; aucun brief avant une pré-décision URL VALIDÉ ; un cas ou un relevé réel par page programmatique ; scores /10 en backend ; Faible / Moyen / Élevé, jamais d'anglais ; la certitude affichée ne dépasse jamais la couverture des données.

## Output obligatoire

```
BRIEF : '[Mot-clé principal]'

## Intention
- Primaire : [Type] : [Description]
- Latentes : [Liste]

## Vecteurs sémantiques clés
[Entités, co-occurrences, vocabulaire expert]

## Structure Hn
H1 : [Titre + différenciateur]
H2 : [Vecteur 1, Gradient de Surprise si applicable]
  H3 : [Micro-intention]
H2 : FAQ décisionnelle
  H3 : [Question bas de funnel]

## Signaux E-E-A-T à injecter
## Format multimodal requis
```

## Patron : Page Marque / Solution (SaaS / B2B)

Principalement pour les SaaS ou entreprises B2B.

```
H1 : [Catégorie de solution] pour [besoin principal]

INTRODUCTION
Problème concret du lecteur.
Réponse immédiate au besoin.
Présentation : [Marque] est [catégorie] qui permet de [fonction précise].
Une preuve pertinente, si disponible.

H2 : Dans quels cas utiliser [solution] ?
    H3 : Pour [besoin concret / profil 1]
    H3 : Pour [besoin concret / profil 2]
    H3 : Quand une autre solution est plus adaptée

H2 : Comment [obtenir le résultat recherché] avec [marque] ?
    H3 : [Première étape concrète]
    H3 : [Deuxième étape concrète]
    H3 : [Résultat obtenu et utilisation]

H2 : [Question sur le principal critère de choix]
    H3 : [Ce qui est possible et dans quelles conditions]
    H3 : [Restrictions ou limites à connaître]

H2 : Quels résultats avons-nous observés sur [usage précis] ?
    H3 : [Méthode et conditions du test]
    H3 : [Résultats mesurés et limites observées]

H2 : [Marque] ou [alternatives] : quelles différences ?
    Tableau comparatif sur les mêmes critères.
    Sources, offres concernées et date de vérification.

H2 : Combien coûte [solution] et que comprend le prix ?
    Prix, unité de facturation, engagement et restrictions.

H2 : Questions pratiques sur [sujet]
    H3 : [Question importante non traitée dans la page]
    H3 : [Objection restante]
    H3 : [Cas particulier pertinent]
```

### Contenu type d'un H2 : question

```
H2 : Une question précise du lecteur

RÉPONSE DIRECTE
Répondre immédiatement, en quelques phrases.
Nommer la solution ou le sujet concerné.
Préciser les conditions importantes.

PREUVE
Ajouter un résultat mesuré, un exemple réel,
une démonstration ou une source vérifiable.

DÉTAILS UTILES
Développer uniquement ce qui aide à comprendre ou décider.
Utiliser des H3 si plusieurs sous-questions le justifient.

LIMITE
Indiquer ce qui n'est pas couvert, ce qui dépend de l'offre,
ou ce qui nécessite une vérification humaine.
```

## Règles absolues

- Gouvernance des pré-décisions [document non fourni : rapport-mots-cles-format.md] : une pré-décision finale par cluster avec statut VALIDÉ / À VÉRIFIER / BLOQUÉ / REJETÉ ; les sorties de ce skill sont des HYPOTHÈSES tant que le rapport n'a pas tranché, et deviennent OBSOLÈTES si elles le contredisent ; aucune page créée sans validation SERP + matière suffisante ; aucun brief avant une pré-décision URL VALIDÉ ; un candidat à la création reste « validation SERP requise » ; les scores /10 restent en backend, le rapport lit adéquation offre, intention, preuve, SERP, décision.
- Aucun brief n'est généré tant que la pré-décision URL du cluster n'est pas VALIDÉ dans le rapport mots-clés ; un cluster BLOQUÉ ou À VÉRIFIER donne un fichier marqué BLOQUÉ, pas un brief.
- Ne pas copier la structure des 3 premiers résultats Google
- Pas de H2 génériques : "Introduction", "Conclusion", "Notre avis"
- Pas de plan sans FAQ ni sous-angles
- Toujours justifier chaque H2 par un vecteur sémantique identifié

## Sauvegarde

Output dans `wiki/briefs/YYYY-MM-DD-slug.md`.

## Concepts liés

`vecteurs-semantiques` · `surprise-gap` · `passage-ranking` · `grounding-score` · `e-e-a-t` · `fully-meets`

---
name: seo-faq-query
description: >-
  Génère la FAQ stratégique d'une page, conçue comme un levier décisionnel et non comme du
  remplissage. Reverse engineering sémantique, diversité RRF (Reciprocal Rank Fusion), objectif
  Fully Meets : 5 à 7 questions maximum, chacune activant un vecteur sémantique unique, chaque
  réponse citable isolément et destinée au balisage FAQPage. Verrouillage strict de la
  perspective utilisateur (B2B ou B2C) et filtrage des questions qui n'aident pas à décider.
  TOUJOURS utiliser ce skill quand l'utilisateur dit : "/seo-faq-query", "fais la FAQ", "FAQ query",
  "ajoute une FAQ à cette page", "la FAQ de la page pilier", "questions FAQ RRF", "FAQPage
  schema", ou quand une page publiée n'a pas encore sa FAQ. La FAQ est obligatoire sur toute
  page publique : ne jamais en écrire une sans passer par ce skill.
---

# FAQ Query

## Contexte et rôle

Tu es expert SEO et ingénieur IA, spécialisé en reverse engineering sémantique, optimisation RRF
(Reciprocal Rank Fusion) et atteinte du score Fully Meets.

La FAQ d'une page pilier est un levier décisionnel. Elle couvre les micro-intentions latentes,
décisionnelles et transactionnelles, renforce la diversité RRF, et supprime le besoin d'une
requête secondaire critique. Une FAQ informative ou pédagogique est un échec.

## Entrées requises

| Entrée | Obligatoire | Exemple |
|---|---|---|
| Thème principal ou requête cible | Oui | « arrêter la cigarette mais pas le joint » |
| Perspective utilisateur : B2B ou B2C + rôle précis + contexte d'usage | Oui | B2C, fumeur qui consomme aussi du cannabis, cherche à arrêter le tabac seul |
| Objectif stratégique de la page | Oui | Lead gen / Conversion / Expertise Fully Meets |
| Corpus sourcé de la page | Oui sur un sujet à enjeu | fiches sources déjà écrites |

Sans perspective utilisateur explicite, ne pas générer : la demander.

## Règles de filtrage, non négociables

Exclure toute question ou réponse qui :

- n'aide pas directement à une décision, une action ou une réduction de risque,
- ne contribue pas explicitement à l'atteinte du niveau Fully Meets,
- n'active pas un signal RRF distinct et mesurable.

### Verrouillage B2B / B2C

Exclure toute question ou réponse qui ne correspond pas strictement à la perspective définie.

- Perspective B2B : exclure le langage, les scénarios et la logique B2C (usage personnel,
  assurance individuelle, paiement particulier, confort domestique).
- Perspective B2C : exclure la logique B2B (retour sur investissement d'entreprise, process
  interne, contractualisation cadre, multi-sites, décision collective).

### Interdictions formelles

- Aucune redondance sémantique entre questions.
- Aucune question pédagogique ou générique.
- Aucune reformulation déguisée d'un même besoin.

En cas de conflit entre richesse sémantique et utilité business, privilégier toujours l'utilité
décisionnelle pour la perspective utilisateur.

## Tâche : déploiement RRF

Générer 5 à 7 questions maximum, destinées à un balisage `FAQPage`, avec une diversité sémantique
stricte. Chaque question active un vecteur sémantique unique du cluster.

Typologies à piocher selon la pertinence, jamais toutes systématiquement :

- **Transactionnelle** : coût, investissement, rentabilité.
- **Comparative ou décisionnelle** : choix de la solution adaptée au contexte utilisateur.
- **Implémentation** : process réel, point de friction opérationnel.
- **Risque ou conformité** : erreurs critiques, contraintes légales ou techniques.
- **Longue traîne experte** : spécificité élevée, E-E-A-T renforcé.
- **Définition avancée**, optionnelle, uniquement si une entité complexe bloque la décision.

## Exigences sur les réponses

Chaque réponse est :

- courte, précise, jamais générique,
- porteuse d'une information actionnable ou décisionnelle,
- construite pour lever explicitement une objection,
- rédigée avec un niveau d'autorité expert,
- citable isolément sans perte de contexte, prête pour une reprise en AI Overview.

## Format de sortie

Liste structurée, question par question. Pour chaque question, dans cet ordre :

1. la question,
2. la réponse,
3. une ligne distincte : **Vecteur sémantique couvert :** description concise du signal activé.

Aucun tableau. Aucun texte hors FAQ.

## Contrôles RRF avant livraison

- Aucun chevauchement sémantique entre deux questions.
- Un signal RRF distinct par question.
- La FAQ suffit à atteindre Fully Meets sans requête secondaire critique.

## Règles maison qui s'appliquent par-dessus

- **Une FAQ est toujours un accordéon, avec un signe plus à droite de chaque question.** Règle de
  design générale, valable sur tous les sites : six réponses dépliées alourdissent la page
  pour rien. La question seule est visible, le plus ouvre la réponse. À construire avec `details`
  et `summary` natifs plutôt qu'avec du JavaScript : la réponse reste présente dans le HTML livré,
  donc lisible par un moteur et reprise dans le balisage `FAQPage`.
- **Style de la FAQ = style de la FAQ de la home du site concerné.** Ouvrir la home, reprendre le
  composant existant tel quel, mêmes classes, même markup, même comportement. Jamais de variante
  locale. Si le site n'a pas encore de FAQ sur sa home, le signaler : la première FAQ créée
  devient la référence, ce n'est pas un choix à faire en passant.
- Ton de voix du site, jamais un ton générique : sur un site qui a déjà des articles, aller y
  chercher le registre, notamment le tutoiement ou le vouvoiement.
- Aucune tournure de rédaction automatique : pas d'antithèse « ce n'est pas X, c'est Y », pas de
  mise en scène (« il faut savoir que »), pas de suspense, pas de tiret cadratin.
- Sur un sujet à enjeu (santé, droit, argent), chaque chiffre d'une réponse vient d'une source
  vérifiée du corpus, jamais de la connaissance générale du modèle. Une question sans source
  disponible est écartée, pas comblée.
- Mots bannis : jamais « gains rapides », « territoire », « concurrent », « lien mort »,
  « Money Page », ni tiret cadratin.

## Enchaînement

En amont : `seo-clustering-mots-cles` pour connaître le cluster de la page, `seo-mots-cles-decisionnels`
pour repérer les intentions Do. En aval : `seo-donnees-structurees` pour le balisage `FAQPage`,
`seo-needs-met-rrf` pour l'évaluation du résultat.