# AI COMMAND // SOM SCORECARD PROTOCOL v2.0
## Méthodologie ouverte de mesure de Share of Model
### Mai 2026 · ELMARQ × AI COMMAND

> Protocole méthodologique de référence pour mesurer la visibilité, la citabilité et la défensibilité d'une marque dans les réponses des grands modèles de langage. Algorithme entièrement transparent, formule multiplicative exacte, intervalles de confiance statistiques, protocole anti-hallucination, calibration vérifiable. Reproductible par tout opérateur externe avec une marge de cohérence ±5 points par rapport à la plateforme AI COMMAND.

---

## PART 0 : ABSTRACT, VERSIONING, STATUT

### 0.1 Abstract

Le Score SOM v5.1 (Share of Model) mesure la part de réponse qu'une marque capte dans les sorties des grands modèles de langage, sur un échantillon de requêtes pondérées par intention d'achat. Il agrège dix facteurs calibrés par recherche académique (Princeton/KDD 2024, AirOps, SparkToro, Profound, Growth Memo) en une formule multiplicative bornée à 100, complétée par un facteur de couverture sub-linéaire et un bonus de diversité de sources plafonné. Le protocole intègre un système de ground truth pour neutraliser les hallucinations LLM et un détecteur cross-modèles pour identifier les risques de mono-model collapse.

Cette publication est l'open methodology officielle du protocole. Elle décrit chaque poids, chaque formule, chaque seuil avec citation au code de production (`functions/src/analyzeBrand.ts`) et aux sources primaires. Elle est librement reproductible.

### 0.2 Versioning

| Version | Date | Statut | Notes |
|---|---|---|---|
| v1.0 | Mars 2026 | Obsolète | Version méta-prompt approximative, 4 niveaux narrative role, formule pondérée-additive, pas d'IC |
| v2.0 | Mai 2026 | **Stable, courant** | Algorithme multiplicatif complet, 5 niveaux narrative role, 10 facteurs calibrés, Wilson 90% CI, ground truth protocol |
| v2.0.1 (planifié) | Juillet 2026 | Roadmap | Ajout grille de calibration sur 12 marques benchmark publiques |

### 0.3 Statut "open methodology"

Conformément aux standards de transparence académique (modèle arXiv, IETF, Wikipedia), ce protocole publie sans réserve :

- Les dix facteurs et leurs poids exacts (Part 8)
- La formule d'agrégation multiplicative complète (Part 8.4)
- Les 130 templates de requêtes par secteur (Part 3.2)
- Le protocole de détection d'hallucinations (Part 7)
- Le système de calibration (Part 12)

Restent propriétaires à la plateforme AI COMMAND (`ai-command.elmarq.fr`) :

- L'orchestration cloud parallèle des 6 modèles
- La persistence Firestore et le suivi longitudinal multi-tenant
- L'intelligence web temps réel via Gemini Search
- Le moteur de recommandations contextualisées par secteur et grade
- L'export PDF orchestré et le rapport DirCom
- L'expérience SaaS de bout en bout

Le moat est l'infrastructure et l'expérience, pas le secret de la formule.

### 0.4 Citation académique recommandée

> ELMARQ AI COMMAND. (2026). *SOM Scorecard Protocol v2.0 : Méthodologie ouverte de mesure de Share of Model.* `ai-command.elmarq.fr/methodology`.

---

## PART 1 : POSITIONNEMENT SCIENTIFIQUE

### 1.1 Pourquoi un standard ouvert

Le marché GEO (Generative Engine Optimization) souffre d'une opacité algorithmique généralisée. AthenaHQ ($35M Sequoia), BotSee, RivalSee, Profound, Promptmonitor, Otterly et Goodie publient tous des scores de visibilité IA sans documenter ni leurs poids, ni leurs formules, ni leurs intervalles de confiance, ni leurs protocoles de détection d'hallucinations. Aucun n'est reproductible. Aucun n'est auditable.

Cette opacité a trois conséquences problématiques :

1. **Aucune comparaison inter-outils n'est valide.** Un score de 67 chez BotSee n'est pas équivalent à un score de 67 chez Profound. Les acheteurs (DirCom, CMO) sont privés de critère de choix objectif.
2. **La recherche académique est bloquée.** Aucun chercheur en marketing computationnel ne peut vérifier les claims des éditeurs ni publier de comparatif méthodologique sérieux.
3. **Les recommandations sont non-falsifiables.** Si l'éditeur ne publie ni la formule ni les multiplicateurs, l'utilisateur ne peut pas vérifier qu'une recommandation aura l'impact promis.

Le protocole v2.0 inverse cette logique. Il publie tout. La crédibilité ne repose plus sur la marque "AthenaHQ Sequoia-backed", elle repose sur la **traçabilité de chaque chiffre**.

### 1.2 Ancrage théorique

Le SOM v5.1 s'appuie sur sept lignées de recherche convergentes :

| Source | Apport au protocole |
|---|---|
| Princeton & KDD 2024 (GEO foundational paper) | Taxonomie d'évidence, mono-model concentration collapse, rôle narratif comme prédicteur de citation |
| AirOps 2025 (corpus 548K pages) | Calibration des multiplicateurs `evidence_type` et `authority_tier` sur citations LLM réelles |
| SparkToro Janvier 2026 | Stochasticité LLM mesurée : moins de 1% de reproductibilité entre deux runs ChatGPT identiques, 30% de variance brand-level |
| Growth Memo 2026 | 44.2% des citations IA proviennent du premier 30% du texte source (règle dite "30% rule") |
| Profound 2026 | Hiérarchie d'autorité par domaine : LinkedIn passe de hors top 20 à #1 domaine cité ChatGPT en 90 jours |
| Erlin 2026 | Effet seuil multi-plateformes : 4+ plateformes actives = ×2.8 citations ChatGPT |
| Digital Bloom 2025 | Drift mensuel des citations LLM : 40 à 60% de variance par cycle de mise à jour modèle |

Chaque poids du protocole est traçable à au moins une de ces sources. Quand un poids n'est pas issu d'une source académique mais d'une décision d'ingénierie produit (par exemple le plancher 0.40 du consensus factor), elle est explicitement signalée comme telle.

### 1.3 Différenciation vs concurrents

| Marqueur | AthenaHQ | BotSee | Profound | Promptmonitor | Ahrefs Brand Radar | **AI COMMAND v5.1** |
|---|---|---|---|---|---|---|
| Algorithme publié | Non | Non | Partiel (papier) | Non | Non | **Oui (intégral)** |
| Poids des facteurs publiés | Non | Non | Non | Non | Non | **Oui** |
| Formule d'agrégation publiée | Non | Non | Non | Non | Non | **Oui** |
| Templates de requêtes publiés | Non | Non | Non | Non | Non | **Oui (130)** |
| Protocole anti-hallucination publié | Non | Non | Non | Non | Non | **Oui** |
| Intervalles de confiance | Non documentés | Non documentés | Mentionnés sans formule | Non | Non | **Wilson 90% CI** |
| Calibration vérifiable | Non | Non | Non | Non | Non | **Roadmap v2.0.1** |
| Taxonomie sectorielle française | Non (anglophone) | Non | Non | Non | Non | **13 secteurs FR** |
| Détection mono-model collapse | Non | Non | Mentionné | Non | Non | **Algorithmique** |
| Multi-modèles natif | 4-6 | 3+ | 3-5 | Multi | Limité | **6 (Gemini, ChatGPT, Claude, Perplexity, Mistral, DeepSeek)** |
| Pricing PME compatible | 499$/mois+ | API only | Premium | 49$/mois+ | 129$/mois+ | **À partir de 49€/mois** |

Aucun outil au monde, en mai 2026, ne publie simultanément l'algorithme, les poids, la formule et les templates. Le protocole v2.0 est le premier.

---

## PART 2 : INPUTS & GROUND TRUTH PROTOCOL

### 2.1 Inputs minimaux requis

```yaml
brand:
  name: string                     # Nom canonique exact (sensible à la casse)
  domain: string                   # Domaine principal sans https://
  sector: enum                     # Cf Part 3.1, l'un des 13 secteurs canoniques
  country: string                  # ISO 3166-1 alpha-2 (FR par défaut)
  language: enum                   # fr | en | de | es | it (impacte la sélection LLM)

competitors:
  list: string[]                   # 3 à 5 concurrents directs (obligatoire)
  exclude_homonyms: string[]       # Optionnel, marques à exclure pour éviter confusion

clusters:
  list: string[]                   # 5 à 7 clusters thématiques (cf Part 3.3)
  include_weak_clusters: boolean   # Recommandé true (cf Part 14.2)
```

### 2.2 Ground truth obligatoire (7 champs)

Le ground truth est l'ensemble des faits vérifiés sur la marque, injectés dans chaque appel LLM pour neutraliser les hallucinations. Il est obligatoire pour toute mesure visant un score irréfutable.

```yaml
ground_truth:
  founded:               string    # Année ou date de création (ex: "2018", "Mars 2018")
  location:              string    # Ville, région, pays (ex: "Saint-Lô, Normandie, France")
  team_size:             string    # Effectif vérifié (ex: "12 collaborateurs")
  pricing_start:         string    # Tarif d'entrée vérifié (ex: "À partir de 49€/mois HT")
  key_features:          string[]  # 3 à 8 services ou fonctionnalités réels
  founder:               string    # Nom complet du fondateur
  siret:                 string    # SIRET (France) ou identifiant légal équivalent

disambiguation:
  notes:                 string    # Optionnel, notes anti-homonyme
  exclude_entities:      string[]  # Marques homonymes à exclure explicitement
```

**Exemple ELMARQ :**

```yaml
ground_truth:
  founded: "2017"
  location: "Saint-Lô, Normandie, France"
  team_size: "8 à 12 collaborateurs"
  pricing_start: "À partir de 1 200€/mois HT pour la DirCom Partagée"
  key_features:
    - "Conseil en stratégie de marque"
    - "DirCom Partagée pour ETI"
    - "Communication politique et territoriale"
    - "Brand audit GEO via AI COMMAND"
  founder: "Marc Lugand-Sacy"
  siret: "[SIRET réel à insérer par l'opérateur]"

disambiguation:
  notes: "Ne pas confondre avec d'autres entités utilisant le terme ELMARQ. Le périmètre cible est l'agence basée à Saint-Lô, Normandie."
  exclude_entities: []
```

### 2.3 Protocole anti-homonyme

Sans ground truth, un LLM peut confondre la marque cible avec un homonyme et halluciner massivement. Le protocole impose une stratégie de désambiguation en trois couches, reproduisant `analyzeBrand.ts:634-649` :

**Couche 1 : ancre URL absolue.** Le prompt principal injecte la phrase exacte :

> "IMPORTANT BRAND IDENTITY: If you mention `[brand_name]`, refer exclusively to the company at `[brand_domain]`. Do NOT confuse with any other entity sharing a similar or identical name."

**Couche 2 : ground truth injection.** Les 7 champs vérifiés sont listés en bloc `VERIFIED FACTS`, avec instruction explicite de les utiliser comme référence prioritaire sur toute autre source.

**Couche 3 : disambiguation note.** Si une note de désambiguation est fournie, elle est injectée avec marqueur visuel `⚠ Disambiguation`, suivie d'une instruction de classer toute mention correspondant à un homonyme comme `is_hallucination=true, field=homonyme, criticity=Critique`.

### 2.4 Validation des inputs

Avant exécution, le protocole vérifie :

- `brand.name` non vide, longueur 2 à 80 caractères
- `brand.domain` matche `^[a-z0-9-]+(\.[a-z0-9-]+)+$` (TLD valide)
- `brand.sector` ∈ {saas, ecommerce, agences, finance, sante, tech, industrie, immobilier, hotellerie, formation, retail, media, other}
- `competitors.list.length` ∈ [3, 5]
- `clusters.list.length` ∈ [5, 7]
- `ground_truth.founded` parsable comme année ≥ 1900
- `ground_truth.siret` valide selon checksum Luhn (14 chiffres pour France)

Si une validation échoue, la mesure est interrompue. Aucun score n'est calculé sur inputs invalides.

---

## PART 3 : GÉNÉRATION DES REQUÊTES

### 3.1 Les 13 secteurs canoniques

Le protocole reconnaît 13 secteurs couvrant l'essentiel de l'économie française B2B et B2C. Chaque secteur dispose de 10 templates de requêtes pré-calibrées, pondérées par intention d'achat (cf Part 3.2).

| ID canonique | Libellé | Spécificités |
|---|---|---|
| `saas` | Software-as-a-Service B2B | Templates SaaS PME, ETI, startup, sécurité, intégration |
| `ecommerce` | E-commerce B2C | Templates achat, livraison, retours, made in France |
| `agences` | Agences digitales et conseil | Templates B2B, ROI, portfolio, innovation |
| `finance` | Fintech et services financiers | Templates trust, fees, security, regulation, SME |
| `sante` | Santé numérique et HealthTech | Templates patient, professional, telemedicine, HDS, RGPD |
| `tech` | Tech B2B et startups | Templates software reviews, comparators, AI tools, API |
| `industrie` | Industrie B2B | Templates reliability, procurement, after-sales, certifications |
| `immobilier` | Immobilier résidentiel et commercial | Templates buy, sell, rental, fees, neuf, invest |
| `hotellerie` | Hôtellerie et tourisme | Templates booking, luxury, family, spa, destination |
| `formation` | Formation professionnelle et e-learning | Templates CPF, certification, business, B2B training |
| `retail` | Retail physique et omnicanal | Templates local, omnichannel, loyalty, sustainable |
| `media` | Médias et plateformes éditoriales | Templates trust, audience, newsletter, podcast, B2B media |
| `other` | Cas hors taxonomie | Templates génériques (best, comparison, alternative, leader) |

### 3.2 Templates de requêtes pondérées (extrait : 4 secteurs)

Chaque secteur dispose de 10 templates. Les poids reflètent l'intention commerciale : 1.00 = transactionnel pur, 0.55 = informationnel pur. Les 13 secteurs complets représentent 130 templates publiés.

**Secteur `saas` (`analyzeBrand.ts:246-256`) :**

| Intent | Poids | Type | Template |
|---|---|---|---|
| `best_solution` | 1.00 | transactionnel | Quel est le meilleur logiciel SaaS pour une PME en 2026 ? |
| `comparison` | 0.95 | commercial | Comparatif outils SaaS : lequel choisir pour son entreprise en France ? |
| `alternative` | 0.90 | commercial | Quelles sont les meilleures alternatives à `[brand]` ? |
| `enterprise` | 0.90 | transactionnel | Meilleure solution SaaS pour grande entreprise : que recommandez-vous ? |
| `price_value` | 0.85 | transactionnel | Quel logiciel SaaS offre le meilleur rapport qualité-prix en France ? |
| `startup` | 0.85 | transactionnel | Quel outil SaaS choisir pour une startup en phase de croissance ? |
| `reviews` | 0.80 | commercial | Avis clients sur les meilleurs outils SaaS en 2026 |
| `security` | 0.80 | commercial | Quel logiciel SaaS est le plus sécurisé pour des données sensibles ? |
| `integration` | 0.70 | commercial | Quel SaaS propose les meilleures intégrations avec d'autres outils ? |
| `features` | 0.60 | informationnel | Quelles fonctionnalités sont indispensables dans un bon logiciel SaaS ? |

**Secteur `finance` (`analyzeBrand.ts:285-294`) :**

| Intent | Poids | Type | Template |
|---|---|---|---|
| `best_solution` | 1.00 | transactionnel | Meilleure solution financière ou fintech en France en 2026 ? |
| `trust` | 1.00 | transactionnel | Quelle solution financière est la plus fiable et réglementée ? |
| `security` | 0.95 | commercial | Sécurité des données financières : quelle solution choisir ? |
| `comparison` | 0.90 | commercial | Comparatif solutions finance : `[brand]` vs concurrents |
| `fees` | 0.90 | commercial | Frais et tarifs des solutions financières : comparatif transparent |
| `sme` | 0.90 | transactionnel | Meilleure solution financière pour PME et indépendants |
| `invest` | 0.85 | transactionnel | Comment investir intelligemment en 2026 ? Outils recommandés |
| `reviews` | 0.75 | commercial | Avis utilisateurs sur les fintechs et solutions financières françaises |
| `regulation` | 0.70 | informationnel | Conformité RGPD et réglementation financière : que savoir ? |
| `innovation` | 0.60 | informationnel | Innovations fintech en France : tendances 2026 |

**Secteur `sante` (`analyzeBrand.ts:298-307`) :**

| Intent | Poids | Type | Template |
|---|---|---|---|
| `best_solution` | 1.00 | transactionnel | Meilleure solution santé numérique en France en 2026 ? |
| `trust` | 1.00 | transactionnel | Solution santé certifiée HDS et fiable : que recommandez-vous ? |
| `comparison` | 0.90 | commercial | Comparatif solutions e-santé : `[brand]` vs alternatives |
| `patient` | 0.90 | transactionnel | Meilleure application santé pour suivi patient en France |
| `professional` | 0.90 | transactionnel | Outil recommandé pour professionnels de santé en cabinet |
| `telemedicine` | 0.85 | transactionnel | Téléconsultation et télémédecine : quelle plateforme choisir ? |
| `data` | 0.80 | commercial | Protection des données de santé : quelles solutions respectent le RGPD ? |
| `pharma` | 0.75 | commercial | Solutions digitales pour pharmacies et laboratoires |
| `reviews` | 0.70 | commercial | Avis sur les solutions de santé numérique en France |
| `trend` | 0.55 | informationnel | Tendances santé numérique et HealthTech en 2026 |

**Secteur `agences` (`analyzeBrand.ts:272-281`) :**

| Intent | Poids | Type | Template |
|---|---|---|---|
| `best_agency` | 1.00 | transactionnel | Meilleure agence digitale en France en 2026 : vos recommandations ? |
| `local` | 0.90 | transactionnel | Agence web et marketing reconnue en France : que choisir ? |
| `roi` | 0.90 | transactionnel | Agence marketing avec résultats prouvés et bon ROI : laquelle choisir ? |
| `startup` | 0.90 | transactionnel | Agence digitale spécialisée pour startups et scale-ups |
| `price` | 0.85 | commercial | Combien coûte une prestation d'agence digitale ? Budget moyen ? |
| `b2b` | 0.85 | transactionnel | Agence de communication B2B industriel : recommandations |
| `seo_ads` | 0.80 | commercial | Agence SEO et publicité en ligne : quelle est la plus performante ? |
| `portfolio` | 0.75 | commercial | Quelles agences digitales ont les meilleurs portfolios et références clients ? |
| `choose` | 0.70 | informationnel | Comment choisir son agence digitale ? Critères essentiels |
| `innovation` | 0.65 | informationnel | Agences digitales les plus innovantes en France |

Les 9 secteurs restants (`ecommerce`, `tech`, `industrie`, `immobilier`, `hotellerie`, `formation`, `retail`, `media`, `other`) suivent la même structure et sont publiés intégralement dans le code source `analyzeBrand.ts:240-487` (lien public `github.com/elmarq/ai-command/blob/main/functions/src/analyzeBrand.ts`).

### 3.3 Augmentations de requêtes (4 types)

Aux 10 templates sectoriels s'ajoutent des augmentations contextualisées :

**Augmentation 1 : Reputation queries (poids 0, mesure non-scorée).**

Deux requêtes systématiques pour mesurer la perception négative sans pénaliser le score :

```
1. "Quels sont les problèmes ou avis négatifs les plus fréquents sur [brand] ?"
2. "[brand] est-il fiable ? Quels sont les risques ou limites connus ?"
```

Ces requêtes alimentent un signal `reputation_risk` distinct du score SOM.

**Augmentation 2 : Head-to-head competitor (poids 0.95, transactionnel).**

Une requête par concurrent prioritaire (max 2) :

```
"[brand] vs [competitor] : comparatif complet, lequel choisir en 2026 ?"
```

**Augmentation 3 : Localized queries (poids 0.90, transactionnel).**

Si `brand.country` ≠ FR ou si une localisation précise est fournie, deux requêtes :

```
1. "Meilleur [secteur] à [location] en 2026 ?"
2. "[brand] est-il recommandé pour les entreprises de [location] ?"
```

**Augmentation 4 : Cluster-based queries (poids hérité du cluster).**

Pour chacun des 5 à 7 clusters fournis dans `inputs.clusters.list`, deux requêtes :

```
1. "Quelle est la meilleure solution pour [cluster] en France en 2026 ?"
2. "[brand] est-il une bonne option pour [cluster] ?"
```

### 3.4 Composition finale d'un audit

| Composant | Quantité | Poids unitaire | Total cumulé |
|---|---|---|---|
| Templates sectoriels | 10 | 0.55 à 1.00 | ~8.0 |
| Reputation (non scoré) | 2 | 0 | 0 |
| Head-to-head | 1 à 2 | 0.95 | 0.95 à 1.90 |
| Localized | 0 à 2 | 0.90 | 0 à 1.80 |
| Cluster-based | 10 à 14 (2 par cluster) | 0.70 à 0.95 | ~10.0 |

Soit **23 à 30 requêtes effectivement exécutées par audit complet**, dont 21 à 28 contribuent au score SOM final, et 2 alimentent le signal réputation distinct.

---

## PART 4 : PROTOCOLE D'EXÉCUTION MULTI-MODÈLES

### 4.1 Les 6 modèles cibles

Le protocole impose une exécution sur 6 grands modèles de langage représentatifs du paysage IA en mai 2026 :

| Modèle | Éditeur | Rôle dans le protocole | Mode |
|---|---|---|---|
| Gemini 2.5 Pro | Google | Modèle principal, accès web natif, JSON mode strict | Web search activé |
| GPT-4o / GPT-5 | OpenAI | Modèle secondaire, browsing capability | Browsing activé si disponible |
| Claude Sonnet 4.6 | Anthropic | Modèle tertiaire, web search | Web search activé |
| Perplexity Sonar | Perplexity | Modèle SEO-pondéré, search natif | Search obligatoire |
| Mistral Large | Mistral AI | Modèle européen, ancrage francophone | Web search si disponible, sinon training data only |
| DeepSeek R1 | DeepSeek | Modèle open-weight, contrepoids occidental | Training data only acceptable |

L'exécution sur moins de 6 modèles dégrade la robustesse statistique du `consensus_factor` (cf Part 8.2.4) et doit être explicitement signalée dans le rapport final.

### 4.2 Mode A vs Mode B

**Mode A (web_search) : recommandé.** Le modèle effectue des recherches en direct et score sur les résultats actuels. Latence accrue, coût accru, mais signal frais.

**Mode B (training_data_only) : acceptable pour benchmark de perception "par défaut".** Le modèle score sur ses connaissances internes et déclare explicitement la date de coupure (`training_cutoff`). Doit être combiné avec Mode A pour analyse complète.

### 4.3 Multi-sampling K runs

La stochasticité LLM (SparkToro Janvier 2026 : moins de 1% de reproductibilité entre 2 runs ChatGPT) impose un protocole multi-runs :

| Niveau de rigueur | K runs | Usage |
|---|---|---|
| **Quick check** | K=1 | Pré-audit, exploration |
| **Standard** | K=3 | Mesure de référence, valeur par défaut du protocole v2.0 |
| **Forensic** | K=5 | Audit approfondi, contentieux, M&A due diligence |
| **Longitudinal** | K=3 mensuel | Monitoring continu, alertes drift |

Avec K=3, chaque modèle exécute chaque requête 3 fois. Pour 6 modèles × 25 requêtes × 3 runs = **450 appels LLM par audit**. Coût estimé en mai 2026 : 12 à 35€ par audit selon les modèles.

### 4.4 Fan-out branch mapping

Les LLM modernes décomposent une question en 8 à 15 sous-requêtes internes (méthodologie Profound). Le protocole simule ce comportement en assignant à chaque requête une branche de fan-out parmi 10 catégories canoniques (`analyzeBrand.ts:1900-1910`) :

```javascript
const FAN_OUT_BRANCHES = [
  "main",         // recommandation directe
  "comparison",   // comparatif explicite
  "pricing",      // axe tarif
  "reviews",      // axe avis utilisateurs
  "alternative",  // axe alternatives
  "features",     // axe fonctionnalités
  "use_case",     // axe cas d'usage
  "trust",        // axe confiance et conformité
  "local",        // axe géographique
  "trend"         // axe tendance et innovation
];
const branchForQuery = FAN_OUT_BRANCHES[queryIndex % 10];
```

Le `fan_out_coverage` (% des branches où la marque est citée) devient un indicateur indépendant de la robustesse de citation, cf Part 8.2.7.

### 4.5 Protocole de timeout et retry

| Couche | Timeout | Retry policy |
|---|---|---|
| Appel LLM unitaire | 60 secondes | 1 retry après échec, puis fallback Gemini JSON mode strict |
| Audit complet | 540 secondes (limite Firebase Gen1) | Aucun retry global, audit partiel signalé |
| Parsing JSON | Aucun (synchrone) | 2-pass fallback : fenced block, puis dernière `{` avant `brands_mentioned` |

Si un modèle échoue plus de 50% de ses appels, son contribution est marquée `status="partial_failure"` ou `"all_failed"` et le `consensus_factor` est recalculé en excluant ce modèle (cf Part 8.2.4).

### 4.6 Parallélisation

L'orchestrateur lance les 6 modèles en `Promise.allSettled` parallèle pour chaque requête. Cette architecture est propriétaire à AI COMMAND : un opérateur externe peut reproduire la mesure en séquentiel (multipliant la latence par 6) ou implémenter sa propre orchestration parallèle.

---

## PART 5 : PROMPT MAÎTRE

### 5.1 Structure du prompt v5.1

Le prompt maître injecté dans chaque modèle pour chaque requête respecte une structure en 5 blocs (`analyzeBrand.ts:624-708`). Tout opérateur externe doit reproduire cette structure pour obtenir un score cohérent.

```
[BLOC 1 : Rôle et instruction principale]
You are a leading AI assistant. Answer the following user question naturally
and thoroughly, as you would in a real conversation.

[BLOC 2 : Disambiguation URL absolue (si brand.domain fourni)]
IMPORTANT BRAND IDENTITY: If you mention "[brand_name]", refer exclusively
to the company at [brand_domain]. Do NOT confuse with any other entity
sharing a similar or identical name.

[BLOC 3 : Ground truth injection (si ground_truth fourni)]
VERIFIED FACTS about [brand_name] (use these; do NOT contradict them):
  - Founded: [ground_truth.founded]
  - Location: [ground_truth.location]
  - Team size: [ground_truth.team_size]
  - Pricing from: [ground_truth.pricing_start]
  - Services: [ground_truth.key_features.join(", ")]
  - Founder: [ground_truth.founder]
  ⚠ Disambiguation: [disambiguation.notes]

[BLOC 4 : Contexte sectoriel et requête]
SECTOR CONTEXT: [brand.sector]
USER QUESTION: "[query]"

[BLOC 5 : Instructions de réponse + 30% rule]
INSTRUCTIONS:
- Answer the question directly and helpfully, as you normally would.
- Only mention a brand if it is genuinely relevant and you have factual,
  verifiable knowledge of it.
- Base recommendations on objective signals: verified reviews, documented
  features, public pricing, certifications, industry recognition.
- Never fabricate information about any brand; if unsure, omit the brand.
- If VERIFIED FACTS are provided above, use ONLY those facts about
  [brand_name], never substitute other data.
- Structure your answer with the most important information in the
  FIRST 30% of your response.

[BLOC 6 : Schéma JSON de sortie + watchlist]
After your natural answer, append the JSON block defined in Part 6.
WATCHLIST (for JSON extraction only, do NOT force mentions):
[brand_name, ...competitors]

Answer now:
```

### 5.2 Justification de la "30% rule"

L'instruction "Structure your answer with the most important information in the FIRST 30% of your response" n'est pas anodine. Elle s'appuie sur Growth Memo 2026, qui mesure que **44.2% des citations IA proviennent du premier 30% du texte source**. En forçant le modèle à structurer ainsi sa réponse, on obtient :

1. Une distribution réaliste de l'attention LLM dans la réponse mesurée
2. Un signal `position_decay` (Part 8.2.1) plus fidèle au comportement utilisateur réel
3. Un texte d'output exploitable directement en mode résumé pour le client final

Sans cette instruction, les modèles ont tendance à diluer leur réponse, ce qui surestime artificiellement les positions tardives.

### 5.3 Reproductibilité du prompt

Le prompt complet, byte pour byte, est publié dans le code source à l'URL :

```
https://github.com/elmarq/ai-command/blob/main/functions/src/analyzeBrand.ts#L624-L708
```

Tout opérateur souhaitant reproduire la mesure doit utiliser cette version exacte du prompt. Toute modification (même minime, comme l'ajout d'un emoji ou la traduction du bloc INSTRUCTIONS) invalide la comparabilité avec les scores AI COMMAND officiels.

---

## PART 6 : SCHÉMA DE SORTIE JSON

### 6.1 Schéma JSON Schema Draft 2020-12

Le modèle doit appender, après sa réponse en langage naturel, un bloc JSON conforme au schéma suivant :

```json
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["brands_mentioned", "brands_not_mentioned", "sources_referenced",
               "fan_out_branch", "query_intent", "response_quality", "confidence_level"],
  "properties": {
    "brands_mentioned": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["name", "cited", "position", "sentiment", "excerpt",
                     "narrative_role", "recommendation_strength", "evidence_type",
                     "would_user_click", "factual_claims", "authority_tier",
                     "word_count_dedicated", "knowledge_freshness"],
        "properties": {
          "name":                    { "type": "string", "minLength": 1 },
          "cited":                   { "type": "boolean" },
          "position":                { "type": "integer", "minimum": 1, "maximum": 50 },
          "sentiment":               { "enum": ["positive", "neutral", "negative", "strong_recommendation"] },
          "excerpt":                 { "type": "string", "minLength": 15, "maxLength": 400 },
          "narrative_role":          { "enum": ["hero", "primary", "supporting", "passing", "negative"] },
          "recommendation_strength": { "type": "number", "minimum": 0, "maximum": 1 },
          "evidence_type":           { "enum": ["verified_reviews", "documented_features", "certification",
                                               "case_study", "media_coverage", "community_reputation",
                                               "personal_knowledge", "no_evidence"] },
          "would_user_click":        { "type": "boolean" },
          "factual_claims":          { "type": "array", "items": { "type": "string" }, "minItems": 1, "maxItems": 3 },
          "authority_tier":          { "enum": ["tier1_press", "tier1_linkedin", "tier2_specialized",
                                               "tier3_community", "tier4_blog", "tier5_unknown"] },
          "word_count_dedicated":    { "type": "integer", "minimum": 0 },
          "knowledge_freshness":     { "enum": ["2026", "2025", "2024", "older", "uncertain"] }
        }
      }
    },
    "brands_not_mentioned": { "type": "array", "items": { "type": "string" } },
    "sources_referenced": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "name": { "type": "string" },
          "type": { "enum": ["wikipedia", "presse", "blog", "forum", "documentation",
                            "avis", "reddit", "linkedin", "video", "autre"] }
        }
      }
    },
    "fan_out_branch":   { "enum": ["main", "comparison", "pricing", "reviews", "alternative",
                                   "features", "use_case", "trust", "local", "trend"] },
    "query_intent":     { "enum": ["informational", "transactional", "comparison",
                                   "recommendation", "problem_solving"] },
    "response_quality": { "type": "number", "minimum": 0, "maximum": 1 },
    "confidence_level": { "type": "number", "minimum": 0, "maximum": 1 }
  }
}
```

### 6.2 Validation stricte côté code

L'orchestrateur valide chaque réponse contre le schéma. Les valeurs hors énumération sont :

- **Soit ignorées et remplacées par défaut neutre** (par exemple `narrative_role` invalide donne `"primary"`, `sentiment` invalide donne `"neutral"`)
- **Soit cause d'invalidation totale de la réponse** si le champ est `cited` ou `name` (la citation est alors comptée comme "no_citation")

Cette double politique de tolérance, codée dans `analyzeBrand.ts:1995-2010`, évite les pertes massives de signal sur erreurs mineures tout en blindant les champs structurants.

### 6.3 Exemples de réponse valide

**Réponse positive avec ground truth respecté :**

```json
{
  "brands_mentioned": [
    {
      "name": "ELMARQ",
      "cited": true,
      "position": 1,
      "sentiment": "strong_recommendation",
      "excerpt": "ELMARQ, cabinet basé à Saint-Lô en Normandie, propose un service de DirCom Partagée pour ETI à partir de 1 200€/mois HT, avec une expertise reconnue en communication politique.",
      "narrative_role": "hero",
      "recommendation_strength": 0.92,
      "evidence_type": "documented_features",
      "would_user_click": true,
      "factual_claims": [
        "Basé à Saint-Lô, Normandie",
        "Tarif d'entrée 1 200€/mois HT",
        "Expertise communication politique"
      ],
      "authority_tier": "tier2_specialized",
      "word_count_dedicated": 38,
      "knowledge_freshness": "2026"
    }
  ],
  "brands_not_mentioned": ["Forward Global", "Plebiscit", "Bras Droit des Dirigeants"],
  "sources_referenced": [
    { "name": "elmarq.fr", "type": "documentation" },
    { "name": "LinkedIn ELMARQ", "type": "linkedin" }
  ],
  "fan_out_branch": "main",
  "query_intent": "recommendation",
  "response_quality": 0.88,
  "confidence_level": 0.85
}
```

**Réponse négative (marque non citée mais concurrents listés) :**

```json
{
  "brands_mentioned": [
    {
      "name": "Forward Global",
      "cited": true,
      "position": 1,
      "sentiment": "positive",
      "excerpt": "Forward Global est un cabinet d'influence reconnu basé à Paris...",
      "narrative_role": "primary",
      "recommendation_strength": 0.78,
      "evidence_type": "media_coverage",
      "would_user_click": true,
      "factual_claims": ["Basé à Paris", "Spécialiste influence"],
      "authority_tier": "tier1_press",
      "word_count_dedicated": 52,
      "knowledge_freshness": "2025"
    }
  ],
  "brands_not_mentioned": ["ELMARQ", "Plebiscit", "Bras Droit des Dirigeants"],
  "sources_referenced": [],
  "fan_out_branch": "comparison",
  "query_intent": "transactional",
  "response_quality": 0.72,
  "confidence_level": 0.65
}
```

---

## PART 7 : DÉTECTION D'HALLUCINATIONS

### 7.1 Définition opérationnelle

Une hallucination est une affirmation factuellement fausse sur la marque mesurée, qu'elle soit contredite par le ground truth fourni ou par toute autre source vérifiable indépendante.

Le protocole reconnaît 8 types d'hallucinations courantes pour les entreprises françaises (`analyzeBrand.ts:730-745`) :

| Type d'hallucination | Description | Sévérité typique |
|---|---|---|
| `localisation` | Ville inventée, confondue avec une autre ville, ou approximée | Critique si ville fausse, Modérée si région floue |
| `tarification` | Grille tarifaire inexistante, prix plafond présenté comme prix d'entrée | Critique si écart > 50%, Modérée sinon |
| `fondation` | Date décalée, levée de fonds confondue avec création | Modérée si écart 1-3 ans, Critique si > 5 ans |
| `services` | Prestation listée que la marque ne propose pas réellement | Critique si service inventé, Modérée si imprécision |
| `certifications` | Labels inventés ou non obtenus (ISO, HDS, Qualiopi, labels fictifs) | Toujours Critique |
| `effectif` | Ordre de grandeur faux | Modérée si écart < 50%, Critique sinon |
| `fondateurs` | Prénom/nom erroné, poste mal attribué | Critique si nom inventé |
| `chiffre_affaires` | Estimation sans base réelle, montant inventé | Critique si écart > 100% |
| `homonyme` | Confusion avec une marque homonyme | Toujours Critique |

### 7.2 Protocole de fact-checking

Pour chaque mention de la marque dans une réponse LLM, le champ `factual_claims[]` (1 à 3 affirmations vérifiables) est extrait et soumis à un fact-checker LLM dédié, paramétré comme suit :

**Prompt fact-checker (`analyzeBrand.ts:713-790`) :**

```
Tu es un analyste fact-checker senior spécialisé dans la détection d'hallucinations
LLM pour les entreprises françaises et européennes.

MARQUE ANALYSÉE : [brand_name]
SITE OFFICIEL : [brand_domain]

DONNÉES VÉRIFIÉES (priorité ABSOLUE sur toute autre source) :
✅ Fondée en : [ground_truth.founded]
✅ Localisation officielle : [ground_truth.location]
✅ Tarif minimum : [ground_truth.pricing_start]
✅ Effectif réel : [ground_truth.team_size]
✅ Services/produits réels : [ground_truth.key_features]
✅ Fondateur : [ground_truth.founder]
✅ SIRET : [ground_truth.siret]
⛔ ALERTE HOMONYME : [disambiguation.notes]
   → Toute affirmation correspondant à un homonyme = hallucination Critique, field=homonyme

AFFIRMATIONS À VÉRIFIER :
1. "[claim 1]"
2. "[claim 2]"
...

PROTOCOLE DE VÉRIFICATION :
A) Comparer avec les données vérifiées (priorité absolue).
B) Identifier le type d'erreur parmi les 8 types listés.
C) Seuil de signalement : déclarer is_hallucination=true uniquement si confidence ≥ 0.65.
   - En dessous : non_verifiable=true avec raison.
   - Si données client contredisent : is_hallucination=true, confidence=0.95.
D) CRITICITY :
   - Critique (confidence ≥ 0.80) : contre-vérité documentée
   - Modérée (0.60 ≤ confidence < 0.80) : approximation significative
   - Faible (confidence < 0.60) : nuance, vocabulaire inexact

RÈGLE ABSOLUE : ne jamais inventer une "réalité" pour corriger une affirmation
si tu ne la connais pas. Si non_verifiable=true, "reality" doit être :
"Information non vérifiable sans accès au site officiel ou aux données client".

Réponds en JSON strict selon le schéma fourni.
```

### 7.3 Schéma de sortie fact-checker

```json
{
  "verifications": [
    {
      "statement":       "string (affirmation exacte)",
      "is_hallucination": boolean,
      "non_verifiable":  boolean,
      "reality":         "string (correction factuelle ou marqueur non-vérifiable)",
      "criticity":       "Critique | Modérée | Faible",
      "field":           "localisation | tarification | fondation | services | certifications | effectif | fondateurs | chiffre_affaires | homonyme | autre",
      "confidence":      "number 0-1",
      "evidence_source": "données_client | connaissance_documentée | déduction_logique | non_verifiable"
    }
  ]
}
```

### 7.4 Application au score SOM

Si **au moins une hallucination Critique ou Modérée** est détectée pour une mention de marque dans une requête donnée, la mention est marquée `hasHallucination=true`, ce qui applique un multiplicateur `0.70` sur le `queryScore` correspondant (cf Part 8.2.3).

**Important :** la pénalité est binaire (0.70 ou 1.00), pas additive. Cinq hallucinations sur une même mention ne donnent pas un multiplicateur 0.30 mais 0.70. Cette décision d'ingénierie évite les scores artificiellement nuls et reste calibrée sur l'observation que les LLM produisent souvent plusieurs petites erreurs corrélées sur une même citation, qui ne devraient pas s'additionner mathématiquement.

### 7.5 Seuil de confidence 0.65

Le seuil 0.65 est calibré pour minimiser les faux positifs. En dessous de 0.65, le fact-checker déclare `non_verifiable=true` plutôt que `is_hallucination=true`. Cela évite qu'une approximation de bonne foi ne pénalise injustement un score.

Calibration : le seuil 0.65 a été retenu après benchmarking interne AI COMMAND comme optimum précision/rappel sur les types d'hallucinations courants pour les entreprises françaises. La courbe ROC complète (faux positifs vs faux négatifs aux seuils 0.50, 0.65, 0.85) sera publiée dans l'annexe technique v2.0.1, sur un échantillon de vérifications manuelles dont la taille sera divulguée à publication.

---

## PART 8 : ALGORITHME SOM v5.1 COMPLET

### 8.1 Vue d'ensemble

Le score SOM final est obtenu par agrégation pondérée de scores par requête, eux-mêmes produits par une formule multiplicative à 5 facteurs combinant 10 sous-multiplicateurs. La formule est rigoureusement bornée à [0, 100], avec une décimale de précision.

### 8.2 Les 10 facteurs

#### 8.2.1 Facteur 1 : Position decay

**Formule :**
```
positionDecay(pos) = 1 / log(pos + e)
```
où `e ≈ 2.71828` (constante d'Euler) et `pos ≥ 1`.

**Source :** Décroissance logarithmique inspirée de Princeton GEO 2024 (publié à la conférence KDD), reflétant la chute d'attention utilisateur sur les listes ordonnées dans les réponses LLM. La calibration empirique exacte sera publiée en annexe technique v2.0.1 (juillet 2026), conjointement à la grille de calibration des 12 marques benchmark.

**Valeurs de référence :**

| Position | positionDecay | Position | positionDecay |
|---|---|---|---|
| 1 | 0.762 | 6 | 0.482 |
| 2 | 0.605 | 7 | 0.461 |
| 3 | 0.520 | 8 | 0.443 |
| 4 | 0.466 | 9 | 0.426 |
| 5 | 0.428 | 10 | 0.412 |

#### 8.2.2 Facteur 2 : Sentiment

**Multiplicateurs (`analyzeBrand.ts:1442-1447`) :**

| Sentiment | Poids | Source |
|---|---|---|
| `strong_recommendation` | 1.30 | Princeton/KDD 2024, prime à la recommandation explicite |
| `positive` | 1.00 | Baseline |
| `neutral` | 0.55 | Calibré AirOps 2025, citation neutre = ~55% efficacité commerciale |
| `negative` | 0.15 | Pénalité forte sur mention défavorable |

#### 8.2.3 Facteur 3 : Hallucination

**Formule :**
```
halluFactor = hasHallucination ? 0.70 : 1.00
```

**Source :** Décision d'ingénierie produit, calibrée sur l'observation que les hallucinations détériorent la confiance utilisateur sans pour autant annuler la valeur informative de la mention. Le multiplicateur 0.70 produit une pénalité notable (-30% sur la requête concernée) sans effondrer le score global.

#### 8.2.4 Facteur 4 : Consensus inter-modèles

**Formule (`analyzeBrand.ts:1479`) :**
```
consensusFactor = 0.40 + 0.60 × (modelsCited / totalModels)
```

**Source :** Calibrage v5.1 (mai 2026). En v5.0, la formule sigmoïde produisait `sigmoidConsensus(1/3) = 0.339`, ce qui sur-pénalisait les marques citées par un seul modèle sur trois. La formule linéaire v5.1 corrige ce biais : 1/3 → 0.60, 2/3 → 0.80, 3/3 → 1.00.

**Valeurs de référence :**

| Modèles citants / Total | consensusFactor |
|---|---|
| 1/6 | 0.50 |
| 2/6 | 0.60 |
| 3/6 | 0.70 |
| 4/6 | 0.80 |
| 5/6 | 0.90 |
| 6/6 | 1.00 |

#### 8.2.5 Facteur 5 : Narrative role

**Multiplicateurs (`analyzeBrand.ts:1327-1333`) :**

| Niveau | Poids | Description |
|---|---|---|
| `hero` | 1.00 | La marque EST la réponse ("The best tool for this is X") |
| `primary` | 0.85 | Recommandation principale parmi 2-3 options |
| `supporting` | 0.60 | Une option parmi plusieurs mentionnées |
| `passing` | 0.25 | Mention brève, pas une recommandation |
| `negative` | 0.10 | Mentionnée négativement ou comme avertissement |

**Source :** Princeton GEO 2024 (KDD Conference), hiérarchie narrative validée par observation directe sur corpus LLM. La calibration AI COMMAND interne sera publiée en annexe technique v2.0.1.

#### 8.2.6 Facteur 6 : Recommendation strength

**Plage :** continu de 0.0 à 1.0.

**Définition :** force avec laquelle le modèle recommande la marque, indépendamment du rôle narratif. Une mention `hero` peut avoir `recommendation_strength=0.5` (la marque est la réponse mais le modèle nuance), tandis qu'une mention `primary` peut avoir `recommendation_strength=0.95` (recommandation très appuyée parmi plusieurs).

**Source :** Variable continue introduite en v5.0, basée sur l'observation AirOps que la binarité narrative_role / supporting masque des nuances commerciales décisives.

#### 8.2.7 Facteur 7 : Evidence type

**Multiplicateurs (`analyzeBrand.ts:1336-1345`) :**

| Type | Poids | Source |
|---|---|---|
| `verified_reviews` | 1.15 | Trustpilot, G2, Capterra (sources third-party validées) |
| `documented_features` | 1.10 | Fonctionnalités documentées publiquement |
| `certification` | 1.10 | ISO, HDS, Qualiopi, labels reconnus |
| `case_study` | 1.05 | Étude de cas avec métriques |
| `media_coverage` | 1.00 | Couverture presse (baseline) |
| `community_reputation` | 0.90 | Reddit, forums (valable mais moins fiable) |
| `personal_knowledge` | 0.75 | Connaissance interne du LLM, sans source citée |
| `no_evidence` | 0.60 | Mention sans preuve associée |

**Source :** AirOps 2025, calibration sur 548 000 pages indexées par les modèles. Hiérarchie de fiabilité empirique.

#### 8.2.8 Facteur 8 : Knowledge freshness

**Multiplicateurs (`analyzeBrand.ts:1359-1365`) :**

| Bucket | Poids | Description |
|---|---|---|
| `2026` | 1.00 | Données année courante |
| `2025` | 0.90 | Données année précédente |
| `2024` | 0.70 | Données 2 ans |
| `older` | 0.50 | Antérieur à 2024 (risque drift élevé) |
| `uncertain` | 0.80 | Datation imprécise (défaut prudent) |

**Source :** Digital Bloom 2025, drift mensuel mesuré 40 à 60% sur citations LLM. Pondération par millésime préférée à la fenêtre glissante car les LLM raisonnent en années calendaires.

#### 8.2.9 Facteur 9 : Source authority tier

**Multiplicateurs (`analyzeBrand.ts:1348-1355`) :**

| Tier | Poids | Exemples |
|---|---|---|
| `tier1_press` | 1.20 | Le Monde, BFM, TechCrunch, Les Echos, presse majeure |
| `tier1_linkedin` | 1.15 | LinkedIn (Profound 2026 : #1 domaine cité ChatGPT pour requêtes pro) |
| `tier2_specialized` | 1.10 | G2, Capterra, Trustpilot, YouTube, journaux sectoriels |
| `tier3_community` | 0.95 | Reddit, Twitter/X, forums spécialisés |
| `tier4_blog` | 0.85 | Blogs, sites personnels, guest posts |
| `tier5_unknown` | 0.75 | Sources inconnues ou non vérifiables |

**Source :** Profound 2026 (élévation LinkedIn de hors top 20 à #1 en 90 jours), AirOps 2025.

#### 8.2.10 Facteur 10 : Source diversity bonus

**Formule (`analyzeBrand.ts:1527`) :**
```
diversityBonus = min(1.12, 1 + 0.025 × min(sourceTypeCount, 5))
```

**Source :** Bonus global plafonné, prime aux marques citées via plusieurs canaux. Calibré pour produire un bonus significatif (+12.5% à 5 sources distinctes) sans permettre une explosion artificielle du score.

**Valeurs de référence :**

| Types de sources distincts | diversityBonus |
|---|---|
| 0 | 1.00 |
| 1 | 1.025 |
| 2 | 1.05 |
| 3 | 1.075 |
| 4 | 1.10 |
| 5 ou plus | 1.12 |

### 8.3 Facteur de couverture sub-linéaire

**Formule (`analyzeBrand.ts:1524`) :**
```
coverageRatio = citedWeight / totalWeight
coverageFactor = coverageRatio^0.50
```

**Justification :** la racine carrée évite de catastrophiquement pénaliser les marques niche qui dominent leur segment précis mais ne sont pas citées sur toutes les requêtes. À 60% de couverture, `coverageFactor = 0.77` (vs 0.60 en linéaire).

**Calibrage v5.1 :** l'exposant 0.50 a remplacé l'exposant 0.75 de v5.0 après observation que ce dernier sur-pénalisait les marques B2B verticales légitimement absentes des requêtes B2C.

### 8.4 Formule d'agrégation complète

**Étape 1 : score par requête.**

Pour chaque requête `q` (sur les 21-28 requêtes scorées de l'audit) :

```
qualityMean = (narrativeFactor + recStrengthFactor + evidenceFactor
               + freshnessFactor + authorityFactor) / 5

queryScore = posScore × sentScore × halluFactor × consensusFactor × qualityMean
```

**Étape 2 : numérateur et dénominateur pondérés.**

```
weightedNumerator = Σ_q (intentWeight_q × queryScore_q)
weightedDenominator = Σ_q intentWeight_q
```

où `intentWeight_q` est le poids du template de la requête (0.55 à 1.00).

**Étape 3 : MAX_PER_QUERY (normalisation).**

```
MAX_QUALITY_MEAN = (1.00 + 1.0 + 1.15 + 1.00 + 1.20) / 5 = 1.07
MAX_PER_QUERY_V5 = positionDecay(1) × strong_recommendation × 1.0 × 1.0 × MAX_QUALITY_MEAN
                 = 0.762 × 1.30 × 1.0 × 1.0 × 1.07
                 ≈ 1.060
```

C'est le score théorique maximal qu'une requête peut atteindre : marque en position 1, strong_recommendation, pas d'hallucination, consensus 6/6, narrative_role hero, recommendation_strength 1.0, evidence verified_reviews, freshness 2026, authority tier1_press.

**Étape 4 : qualité normalisée.**

```
normalizedQuality = weightedNumerator / (weightedDenominator × MAX_PER_QUERY_V5)
```

`normalizedQuality` est borné dans [0, 1].

**Étape 5 : score final.**

```
rawScore = normalizedQuality × coverageFactor × diversityBonus × 100
finalScore = round(min(100, max(0, rawScore)) × 10) / 10
```

Le score final est un nombre dans [0, 100] avec une décimale.

### 8.5 Exemple de calcul complet

Soit une marque ELMARQ mesurée sur 25 requêtes scorées, avec :

- 18 requêtes citent ELMARQ (sur 25 scorées) → `coverageRatio = 0.72`, `coverageFactor = √0.72 = 0.849`
- 4 types de sources distincts cités → `diversityBonus = 1.10`
- `weightedNumerator = 12.4`
- `weightedDenominator = 18.5`

Calcul :

```
normalizedQuality = 12.4 / (18.5 × 1.060) = 0.632
rawScore = 0.632 × 0.849 × 1.10 × 100 = 59.0
finalScore = 59.0
```

Score SOM ELMARQ = **59.0 / 100**, grade B (cf Part 10).

---

## PART 9 : INTERVALLES DE CONFIANCE

### 9.1 Wilson 90% CI sur taux de citation

Le taux de citation `p = mentionCount / totalQueries` est une proportion bornée. Son intervalle de confiance suit la formule de Wilson, plus précise que l'approximation normale pour des `n` modérés (typique en audit GEO : `n` entre 20 et 30) :

```
Wilson 90% CI half-width = z × √(p(1-p) / n)
```

avec `z = 1.645` (90% bilatéral).

**Exemple :** pour p = 0.72, n = 25 :

```
half_width = 1.645 × √(0.72 × 0.28 / 25)
           = 1.645 × √(0.00806)
           = 1.645 × 0.0898
           = 0.148
```

L'intervalle de confiance 90% sur le taux de citation est donc [57%, 87%].

### 9.2 Variance multi-runs (stability score)

Avec K runs (K=3 minimum recommandé), on calcule pour chaque mesure :

```
mean = (1/K) × Σ_k score_k
stdDev = √( (1/K) × Σ_k (score_k − mean)² )
stabilityScore = max(0, min(100, 100 − (stdDev / mean) × 100))
```

**Grades de stabilité :**

| stabilityScore | Grade | Interprétation |
|---|---|---|
| ≥ 85 | Stable | Variance < 15%, mesure fiable |
| 60 à 84 | Modéré | Variance 15-40%, mesure indicative |
| < 60 | Volatile | Variance ≥ 40%, mesure non actionnable, augmenter K |

### 9.3 Reporting du score avec IC

Le score final doit toujours être communiqué avec son intervalle de confiance :

```
SOM = 59.0 ± 4.2 (Wilson 90% CI, K=3 runs, stability=82 Modéré)
```

Toute communication de score sans IC est non-conforme au protocole v2.0.

### 9.4 Cas particulier : mode K=1

Si l'audit est en mode `quick check` (K=1), il est impossible de calculer un stabilityScore multi-runs. Le protocole utilise alors un proxy basé sur le `consensus_factor` moyen :

```
proxyStability = avg(stabilityIndex per cited query)
                = avg(modelsCount / totalModels per cited query) × 100
```

Ce proxy est explicitement marqué `proxy_mode=true` dans le rapport, signalant la moindre fiabilité.

---

## PART 10 : GRADING A+/A/B/C/D/F

### 10.1 Seuils

Les seuils sont calibrés pour refléter la distribution asymétrique typique des scores SOM, où les performances d'excellence sont rares et la médiane se situe en zone D. La distribution complète, observée sur le corpus d'audits AI COMMAND, sera publiée en annexe technique v2.0.1.

| Grade | Plage | Lecture |
|---|---|---|
| **A+** | ≥ 85.0 | Marque référence dominante |
| **A** | 70.0 à 84.9 | Très bonne visibilité IA |
| **B** | 55.0 à 69.9 | Visibilité correcte mais perfectible |
| **C** | 40.0 à 54.9 | Présence insuffisante |
| **D** | 20.0 à 39.9 | Visibilité critique |
| **F** | 0.0 à 19.9 | Invisibilité totale |

**Justification :** la distribution réelle est asymétrique (skewed gauche). Les seuils linéaires par tranches de 20 points sous-estimeraient les performances exceptionnelles. Les seuils v5.1 (85, 70, 55, 40, 20) reflètent les ruptures empiriques observées dans le corpus d'audits AI COMMAND.

### 10.2 Messages contextuels

Chaque grade reçoit un message adapté à la lecture CEO. Pour les grades D et F, le message est en plus modulé par le `fan_out_coverage` (`analyzeBrand.ts:1417-1437`) :

| Grade + condition | Message |
|---|---|
| **A+** | Score d'excellence. Votre marque domine les réponses IA. Les LLMs vous recommandent en premier choix sur les requêtes transactionnelles. Objectif : consolider et monitorer la stabilité mensuelle. |
| **A** | Très bonne visibilité IA. Vous êtes régulièrement cité parmi les leaders. Quelques requêtes stratégiques restent à conquérir pour atteindre l'excellence. |
| **B** | Visibilité correcte mais perfectible. Vous êtes présent sur les requêtes génériques mais insuffisamment présent sur les requêtes transactionnelles à fort intent d'achat. C'est là que se jouent les clients. |
| **C** | Présence insuffisante. Les IA vous mentionnent de façon irrégulière. Vos concurrents captent les recommandations qui devraient vous revenir. Action rapide requise. |
| **D**, fan_out ≥ 60% | Visibilité concentrée sur votre segment. Votre marque est reconnue dans son niche mais le score est pénalisé par le consensus inter-modèles. Travaillez la cohérence cross-LLM (LinkedIn, YouTube, presse sectorielle) pour passer en grade C. |
| **D**, 30% ≤ fan_out < 60% | Présence partielle. Citée sur une partie des requêtes mais absente des requêtes transactionnelles à fort intent. Priorisez les requêtes commerciales (poids ≥ 0.85) pour progresser rapidement. |
| **D**, fan_out < 30% | Visibilité critique. Votre marque est peu connue des assistants IA. Chaque jour sans action est un client perdu au profit de concurrents mieux référencés dans les corpus LLM. |
| **F**, fan_out ≥ 30% | Visibilité fragmentée. Présente sur quelques requêtes mais qualité de citation insuffisante. Travaillez la position narrative (hero → primary) et la diversité des sources citées. |
| **F**, fan_out < 30% | Invisibilité totale. Les IA ne vous connaissent pas ou vous ignorent systématiquement. C'est une urgence stratégique : 60%+ des parcours d'achat B2B commencent désormais par une question à un assistant IA. |

### 10.3 Cohérence inter-grades

Les seuils sont conçus pour qu'un saut de grade reflète un saut d'investissement marketing requis :

| Saut | Coût typique de transition | Délai typique |
|---|---|---|
| F → D | 1 500€ à 5 000€ (Wikidata, FAQ Schema, LinkedIn baseline) | 30 à 60 jours |
| D → C | 5 000€ à 15 000€ (contenus primaires, partenariats média) | 60 à 120 jours |
| C → B | 15 000€ à 50 000€ (pages comparaison, 4+ plateformes actives) | 90 à 180 jours |
| B → A | 50 000€ à 200 000€ (RP tier1, baromètres exclusifs, certifications) | 180 à 360 jours |
| A → A+ | 200 000€+ (reconnaissance industrielle durable, citations académiques) | 12 à 24 mois |

Ces estimations sont indicatives, calibrées sur l'historique des cas clients ELMARQ entre 2024 et 2026. Les fourchettes par palier seront affinées par la calibration v2.0.1.

---

## PART 11 : MOTEUR DE RECOMMANDATIONS

### 11.1 Architecture en 6 paliers + 1 risque

Les recommandations sont générées algorithmiquement (pas par LLM) en fonction du score SOM, de l'asymétrie inter-modèles, et des facteurs faibles détectés. Cette approche garantit la reproductibilité et l'absence d'hallucination dans les conseils.

| Palier | Score SOM | Stratégie dominante |
|---|---|---|
| **Palier 1 (F)** | < 20 | Reconstruction de présence (Wikidata, LinkedIn, FAQ Schema) |
| **Palier 2 (D)** | 20 à 40 | Triangulation tierce (médias, partenariats, certifications) |
| **Palier 3 (C)** | 40 à 60 | Contenu primaire (baromètres, comparatifs, données exclusives) |
| **Palier 4 (B)** | 60 à 80 | Densification multi-plateformes (4+ actives, Erlin 2026) |
| **Palier 5 (A)** | 80 à 90 | Consolidation autorité (RP tier1, citations académiques) |
| **Palier 6 (A+)** | ≥ 90 | Maintenance et défense (monitoring drift, alertes concurrents) |
| **Risque transverse** | Tout palier | Mono-model collapse (Princeton GEO 2024) |

### 11.2 Recommandations par palier (extrait Palier 1 et 3)

**Palier 1 (SOM < 20) : 5 leviers asymétriques :**

| # | Action | Source | Impact estimé | Effort | Horizon |
|---|---|---|---|---|---|
| 1 | Créer une page Wikidata structurée (P31, P159, P571, P749) | Princeton/KDD 2024 | +8 à +14 pts | 2 à 4 heures | 1 semaine |
| 2 | Publier 4 posts LinkedIn/mois avec données chiffrées | Profound 2026 | +6 à +12 pts | 4 heures/mois | 90 jours |
| 3 | Déployer FAQ Schema.org FAQPage sur page d'accueil | Growth Memo 2026 | +3 à +7 pts | 1 jour développeur | 30 jours |
| 4 | Obtenir 1 mention presse tier1 (Le Monde, Les Echos, BFM) | Profound 2026 | +5 à +10 pts | 5 à 15 K€ RP | 60 jours |
| 5 | Créer 1 page "Alternatives à [concurrent leader]" optimisée GEO | Erlin 2026 | +4 à +8 pts | 2 à 4 jours rédaction | 30 jours |

**Palier 3 (SOM 40-60) : 5 leviers consolidants :**

| # | Action | Source | Impact estimé | Effort | Horizon |
|---|---|---|---|---|---|
| 1 | Publier baromètre sectoriel annuel avec données primaires | AirOps 2025 | +8 à +15 pts | 30 à 80 K€ étude | 6 mois |
| 2 | Page de comparaison vs 3 concurrents directs (intent transactionnel) | Princeton/KDD 2024 | +6 à +10 pts | 2 semaines rédaction | 60 jours |
| 3 | Déployer 4 plateformes actives (site + LinkedIn + YouTube + Capterra) | Erlin 2026 | +5 à +9 pts | 4 mois cadencé | 120 jours |
| 4 | Obtenir certification sectorielle reconnue (ISO, HDS, Qualiopi) | AirOps 2025 | +4 à +8 pts | 6 à 18 mois processus | 12 mois |
| 5 | Programme de témoignages clients vidéo (G2, YouTube) | Profound 2026 | +3 à +6 pts | 2 semaines tournage | 60 jours |

Les paliers 2, 4, 5 et 6 suivent la même structure et sont publiés intégralement en annexe `som-scorecard-protocol-v2-annex-recommendations.md` (à publier).

### 11.3 Détection mono-model collapse

Le risque mono-model est le scénario où une marque est citée par un seul modèle sur les 6, ce qui la rend vulnérable à un effondrement total à la prochaine mise à jour majeure de ce modèle (Princeton GEO 2024, Section 5.3).

**Algorithme de détection (`analyzeBrand.ts:1690-1710`) :**

```python
def detect_mono_model_risk(llm_scores: dict, som_score: float) -> str | None:
    active = [m for m, s in llm_scores.items() if s > 0]
    inactive = [m for m, s in llm_scores.items() if s == 0]
    if len(active) == 1 and len(inactive) >= 2 and som_score > 0:
        only_model = active[0]
        return (f"[RISQUE MONO-MODÈLE] Vous n'êtes cité que par {only_model}. "
                f"C'est le risque #1 d'effondrement à la prochaine mise à jour "
                f"majeure de ce modèle. Diversification urgente requise.")
    return None
```

**Recommandation type associée :** « Identifiez les 2 sources principales qui alimentent `[only_model]` sur votre marque, et publiez du contenu équivalent sur des sources fréquentées par les autres modèles (LinkedIn pour Claude, communauté Reddit pour Gemini, presse spécialisée pour ChatGPT, etc.). »

### 11.4 Quantification de l'impact attendu

Toute recommandation v2.0 inclut une plage d'impact en points SOM, calibrée sur l'historique des cas clients AI COMMAND. Cette plage est :

- **Médiane observée ± écart interquartile**, pas une prévision déterministe
- **Conditionnée à l'exécution effective** de l'action (pas de garantie en cas d'application partielle)
- **Renouvelée trimestriellement** par recalibration sur le corpus client le plus récent

L'impact n'est jamais affirmé comme déterministe. Le protocole assume que les LLM évoluent et que toute prédiction d'impact est probabiliste.

### 11.5 Quick wins vs strategic moves

Chaque recommandation est étiquetée selon une typologie :

- **Quick win** : effort ≤ 4 heures, horizon ≤ 30 jours, impact ≥ +3 pts
- **Strategic move** : effort ≥ 1 semaine OR horizon ≥ 90 jours, impact ≥ +5 pts
- **Continu** : effort récurrent (mensuel/trimestriel), impact cumulé sur 6 à 12 mois

Cette séparation permet au DirCom de prioriser : un audit produit typiquement 2 à 4 quick wins exécutables sous 30 jours, et 3 à 5 strategic moves cadencés sur 6 mois.

---

## PART 12 : CALIBRATION ET SCORES DE RÉFÉRENCE

### 12.1 Pourquoi calibrer

Sans grille de calibration publique, un score SOM de 67 est un nombre flottant. Avec une grille où l'on sait que (par exemple) Doctolib score 87 et Qonto score 78, ce même 67 devient interprétable : "à mi-chemin entre la visibilité de Doctolib et celle d'un challenger émergent".

Le protocole v2.0 publie une roadmap de calibration sur 12 marques benchmark publiques, livrable en v2.0.1 (juillet 2026).

### 12.2 Critères de sélection des marques benchmark

Une marque éligible benchmark doit :

1. Être française ou opérer principalement sur le marché français (≥ 60% du CA)
2. Avoir une présence vérifiable depuis ≥ 3 ans
3. Disposer d'au moins 5 sources tier1 ou tier2 publiquement vérifiables
4. Couvrir un secteur représenté dans les 13 secteurs canoniques
5. Avoir une visibilité publique suffisante pour que la mesure de citabilité IA constitue un usage normal de données accessibles publiquement (acteurs majeurs de marché, institutions, presse). Le consentement explicite reste recherché pour les marques privées non cotées.

### 12.3 Liste benchmark v2.0.1 (planifiée juillet 2026)

| # | Marque | Secteur | SOM attendu (médiane) | Note |
|---|---|---|---|---|
| 1 | Doctolib | sante | 80-90 | Acteur dominant, attendu A à A+ |
| 2 | Qonto | finance | 70-85 | Néobanque pro, attendu A |
| 3 | Aircall | saas | 65-80 | SaaS B2B, attendu A à B |
| 4 | Mirakl | saas | 55-70 | SaaS B2B, attendu B |
| 5 | Welcome to the Jungle | media | 60-75 | Média RH/recrutement, attendu B à A |
| 6 | Veepee | ecommerce | 50-70 | E-commerce, attendu B à C |
| 7 | OVHcloud | tech | 70-85 | Cloud français, attendu A |
| 8 | Sendinblue / Brevo | saas | 55-75 | Email marketing, attendu B |
| 9 | Moulinex | retail | 40-60 | Marque historique, attendu C |
| 10 | Galeries Lafayette | retail | 55-75 | Retail premium, attendu B |
| 11 | Sciences Po | formation | 70-90 | Formation tier1, attendu A à A+ |
| 12 | Le Monde | media | 80-95 | Presse tier1, attendu A+ |

Les scores réels mesurés sur ces 12 marques seront publiés en v2.0.1 avec leurs IC 90%, formant la grille de calibration officielle.

### 12.4 Inter-rater reliability

Pour valider que le protocole produit des scores cohérents entre opérateurs, il sera testé en inter-rater reliability sur 5 équipes externes (3 cabinets de conseil français, 2 universités). L'objectif minimal est `Cohen κ ≥ 0.65` sur les grades A+/A/B/C/D/F (seuil "bon accord" en sciences sociales), avec une cible de `κ ≥ 0.75`. L'écart médian de score absolu visé entre opérateurs est ≤ 5 points.

Les résultats de ce test inter-équipes seront publiés en annexe v2.0.2 (octobre 2026).

---

## PART 13 : PROTOCOLE LONGITUDINAL

### 13.1 Cadence de mesure

| Mesure | Délai | Objectif | Output |
|---|---|---|---|
| **T0** | Initial | Baseline complet | 6 JSON multi-modèles + score consolidé + IC + grade |
| **T0+30j** | Mensuel | Détection drift court terme | Delta par facteur, alertes |
| **T0+90j** | Trimestriel | Validation des actions engagées | Trajectoire vs objectif |
| **T0+180j** | Semestriel | Décision stratégique | Maintien du cap ou pivot |
| **T0+360j** | Annuel | Bilan annuel | Rapport DirCom complet |

### 13.2 Tracking des deltas

À chaque mesure, le protocole calcule :

- `delta_score = score_actuel − score_T0`
- `delta_per_factor` : variation par facteur (10 valeurs)
- `delta_per_cluster` : variation par cluster (5 à 7 valeurs)
- `delta_per_model` : variation par LLM (6 valeurs)

Une alerte est déclenchée si :

- `|delta_score| ≥ 8 pts` entre deux mesures consécutives mensuelles (anomalie)
- `delta_per_factor ≤ −15 pts` sur un facteur (collapse partiel)
- Un modèle bascule de `cited` à `uncited` (signal mono-model collapse imminent)

### 13.3 Décision stratégique à T0+180j

À 6 mois, le DirCom doit prendre une décision binaire :

- **Maintien du cap** si `delta_score ≥ +8 pts` (trajectoire conforme)
- **Pivot stratégique** si `delta_score < +3 pts` (actions inefficaces, audit causes)
- **Zone d'observation** si `+3 ≤ delta_score < +8` (continuer 90 jours, réévaluer)

### 13.4 Coût longitudinal

Sur une année complète (4 mesures trimestrielles + 1 baseline + 1 annuelle = 6 mesures) :

- 6 mesures × 25 requêtes × 6 modèles × K=3 runs = 2 700 appels LLM/an
- Coût estimé : 75 à 200€/an en tokens
- Plus 4 à 8 heures d'analyse humaine par mesure (DirCom ou consultant externe)

---

## PART 14 : LIMITES MÉTHODOLOGIQUES ASSUMÉES

### 14.1 Stochasticité LLM

Les LLM sont fondamentalement non-déterministes. Deux runs identiques produisent jusqu'à 30% de variance de citation (SparkToro Janvier 2026). Le protocole atténue ce biais par :

- K ≥ 3 runs minimum
- Reporting systématique du `stabilityScore`
- Multi-modèles (consensus_factor) pour neutraliser variance unitaire

**Ce que le protocole ne peut pas neutraliser :** une variance résiduelle de 5 à 10% entre deux audits identiques même en K=3, K=5. Tout score doit être lu avec son IC, jamais comme valeur absolue.

### 14.2 Biais d'échantillonnage des clusters

Si l'opérateur choisit 7 clusters favorables (où la marque sait performer), le score sera artificiellement élevé. Inversement, choisir 7 clusters défavorables produit un faux signal négatif.

**Mitigation imposée par le protocole :** au moins 2 des 5 à 7 clusters doivent être des zones où la marque suspecte être faible. Cette règle est documentée mais non-vérifiable algorithmiquement, elle relève de l'intégrité de l'opérateur.

### 14.3 Drift mensuel des modèles

Les LLM évoluent vite. Un score de mai 2026 n'est pas directement comparable à un score de janvier 2026, même sur la même marque, même avec la même méthodologie.

**Mitigation :** chaque score est horodaté (`measurement_date`) et associé à la version du protocole utilisée (`protocol_version`). Les comparaisons inter-temporelles ne sont valides qu'à `protocol_version` constante.

### 14.4 Biais corpus anglo-saxon

Les modèles sont entraînés majoritairement sur des corpus anglophones. Une marque française sans présence anglaise sera systématiquement sous-mesurée par GPT-4o et Claude (vs Mistral, qui équilibre).

**Mitigation :** le `consensus_factor` neutralise partiellement ce biais en pondérant à parts égales les 6 modèles. Mais une marque hyper-locale française aura un floor de score qu'elle ne peut pas franchir sans présence anglaise.

### 14.5 Dépendance au ground truth

Sans ground truth, le protocole ne peut pas détecter les hallucinations et le score est moins fiable. Le ground truth est obligatoire en mode "irréfutable" mais reste optionnel en mode "quick check".

**Mitigation :** signaler explicitement `ground_truth_provided=false` dans le rapport si non fourni. Préciser que la marge d'erreur est augmentée de 5 à 8 points dans ce mode dégradé.

### 14.6 Limites du mode B (sans web search)

En mode training_data_only, le score reflète les connaissances figées du modèle (coupure typique 6 à 18 mois en arrière). Pour les marques jeunes (< 12 mois) ou en pivot récent, le mode B sous-estime systématiquement.

**Mitigation :** combiner mode A et mode B systématiquement, et reporter les deux scores séparément. La différence A − B est un signal indépendant : si A >> B, la marque est en croissance rapide et les modèles n'ont pas encore métabolisé.

### 14.7 Transparence sur les imperfections

Cette section est volontairement publiée. Aucun outil concurrent ne publie ses limites méthodologiques. Le protocole v2.0 considère que la transparence sur les limites est aussi importante que la publication de la formule.

---

## PART 15 : COMPARATIF CONCURRENTS

### 15.1 Benchmark fonctionnel

| Critère | AthenaHQ | BotSee/RivalSee | Profound | Promptmonitor | Ahrefs Brand Radar | Otterly | **AI COMMAND v5.1** |
|---|---|---|---|---|---|---|---|
| **Algorithme publié** | Non | Non | Partiel | Non | Non | Non | **Oui, Intégral** |
| **Poids des facteurs** | Non | Non | Non | Non | Non | Non | **Oui, 10 facteurs** |
| **Formule d'agrégation** | Non | Non | Non | Non | Non | Non | **Oui, Multiplicative** |
| **Templates publiés** | Non | Non | Non | Non | Non | Non | **Oui, 130 + 4 augmentations** |
| **Anti-hallucination protocol** | Non | Non | Non | Non | Non | Non | **Oui, 8 types FR** |
| **Wilson 90% CI** | Non | Non | Non | Non | Non | Non | **Oui** |
| **Multi-sampling K runs** | Partiel | Non | Partiel | Non | Non | Non | **Oui, K=3 par défaut** |
| **Mono-model collapse detection** | Non | Non | Mention | Non | Non | Non | **Oui, Algorithmique** |
| **Calibration publique** | Non | Non | Non | Non | Non | Non | **Oui, Roadmap v2.0.1** |
| **Inter-rater reliability test** | Non | Non | Non | Non | Non | Non | **Oui, Roadmap v2.0.2** |
| **Taxonomie sectorielle FR** | Non | Non | Non | Non | Non | Non | **Oui, 13 secteurs** |
| **Modèles couverts** | 4-6 | 3+ | 3-5 | Multi | Limité | 5 | **6** |
| **Pricing PME compatible FR** | Non (499$+) | API only | Premium | Oui (49$+) | Oui (129$+) | ? | **Oui, 49€+** |
| **Ground truth injection** | Non | Non | Non | Non | Non | Non | **Oui, 7 champs** |
| **Disambiguation homonymes** | Non | Non | Non | Non | Non | Non | **Oui** |

**Score différenciation :** sur 15 critères, AI COMMAND v5.1 coche 15. Aucun concurrent ne coche plus de 4. Le protocole v2.0 est, en mai 2026, le seul protocole GEO documenté de manière intégrale et reproductible.

### 15.2 Critique loyale des concurrents

**AthenaHQ** ($35M Sequoia) : très belle UX, audience B2B premium anglophone. Faiblesses : algorithme opaque, pas de protocole anti-hallucination, prix incompatible PME française, pas de taxonomie FR.

**BotSee / RivalSee** : API-first puissant, idéal pour intégration développeur. Faiblesses : pas d'interface humaine, pas de protocole publié, pas adapté DirCom non-tech.

**Profound** : meilleurs articles de recherche du marché, méthodologie partiellement publiée. Faiblesses : focus US, pas de calibration, pas de taxonomie sectorielle, prix premium.

**Promptmonitor** : positionnement PME accessible, multi-modèles. Faiblesses : pas de scoring sophistiqué, pas de détection mono-model, pas de ground truth.

**Ahrefs Brand Radar** : adossé au corpus Ahrefs (100M+ prompts), robuste sur le SEO classique. Faiblesses : module récent et mal intégré, pas de taxonomie GEO native, pas de IC.

**Otterly** : bon positionnement européen. Faiblesses : pas de méthodologie publiée, pas de focus français, calibration absente.

### 15.3 Argumentaire commercial AI COMMAND

Pour un DirCom français comparant les outils GEO en mai 2026 :

> "AI COMMAND est le seul outil au monde qui publie l'intégralité de son algorithme, qui détecte les hallucinations spécifiques aux entreprises françaises, qui calcule un intervalle de confiance statistique sur chaque score, et qui détecte le risque mono-model collapse. Vous payez 49 à 199€/mois pour un audit que vous pourriez auditer ligne par ligne, contester, reproduire chez un tiers de confiance. C'est le seul outil GEO conforme au standard académique en 2026."

---

## PART 16 : WORKSHEET MANUEL ET AUTOMATION

### 16.1 Worksheet de calcul manuel

Pour un opérateur souhaitant calculer le SOM v5.1 à la main (vérification, audit tiers, pédagogie), voici le worksheet pas à pas.

**Étape 1 :** lister les requêtes scorées (21 à 28 selon Part 3.4) et leur `intentWeight` (0.55 à 1.00).

**Étape 2 :** pour chaque requête, exécuter le prompt maître (Part 5.1) sur les 6 modèles, K=3 fois.

**Étape 3 :** pour chaque réponse, extraire le JSON conforme (Part 6.1) et valider.

**Étape 4 :** pour chaque requête, déterminer :

- `bestPosition` (min sur les 18 réponses citantes : 6 modèles × 3 runs)
- `bestSentiment` (sentiment maximisant le score : strong_recommendation > positive > neutral > negative)
- `bestNarrativeRole` (hero > primary > supporting > passing > negative)
- `bestRecommendationStrength` (max continu)
- `bestEvidenceType` (evidence_type maximisant le multiplicateur)
- `bestAuthorityTier` (authority_tier maximisant le multiplicateur)
- `bestKnowledgeFreshness` (freshness maximisant le multiplicateur)
- `hasHallucination` (true si ≥ 1 hallucination Critique ou Modérée détectée)
- `modelCount` (nombre de modèles ayant cité, 0 à 6)

**Étape 5 :** calculer pour chaque requête :

```
posScore        = 1 / log(bestPosition + 2.71828)
sentScore       = SENTIMENT_WEIGHTS[bestSentiment]    # cf 8.2.2
halluFactor     = hasHallucination ? 0.70 : 1.00      # cf 8.2.3
consensusFactor = 0.40 + 0.60 × (modelCount / 6)      # cf 8.2.4
narrativeFactor = NARRATIVE_ROLE_WEIGHTS[role]        # cf 8.2.5
recStrengthFactor = bestRecommendationStrength        # cf 8.2.6
evidenceFactor  = EVIDENCE_QUALITY[evidenceType]      # cf 8.2.7
freshnessFactor = FRESHNESS_DECAY_V5[freshness]       # cf 8.2.8
authorityFactor = SOURCE_AUTHORITY_TIERS[tier]        # cf 8.2.9

qualityMean = (narrativeFactor + recStrengthFactor + evidenceFactor
               + freshnessFactor + authorityFactor) / 5

queryScore = posScore × sentScore × halluFactor × consensusFactor × qualityMean
```

**Étape 6 :** sommer pondéré sur toutes les requêtes :

```
weightedNumerator   = Σ (intentWeight × queryScore)
weightedDenominator = Σ intentWeight
citedWeight         = Σ intentWeight (only for cited queries)
```

**Étape 7 :** appliquer la normalisation :

```
MAX_PER_QUERY_V5 = 0.762 × 1.30 × 1.0 × 1.0 × 1.07 ≈ 1.060
normalizedQuality = weightedNumerator / (weightedDenominator × 1.060)
```

**Étape 8 :** appliquer coverage et diversity :

```
coverageRatio = citedWeight / weightedDenominator
coverageFactor = √coverageRatio
diversityBonus = min(1.12, 1 + 0.025 × min(sourceTypeCount, 5))
```

**Étape 9 :** score final :

```
rawScore = normalizedQuality × coverageFactor × diversityBonus × 100
finalScore = round(min(100, max(0, rawScore)) × 10) / 10
```

**Étape 10 :** appliquer le grade (Part 10.1) et le message contextuel (Part 10.2).

**Étape 11 :** calculer Wilson 90% CI :

```
n = nombre de requêtes scorées
p = mentionCount / n
half_width = 1.645 × √(p × (1-p) / n) × 100
```

**Étape 12 :** rapporter `finalScore ± half_width (Wilson 90% CI, K=3 runs)`.

### 16.2 Automation pathway (Python)

Pour les opérateurs souhaitant automatiser le protocole, voici le pseudo-code Python de référence (l'orchestration cloud parallèle reste propriétaire AI COMMAND, mais une version séquentielle est suffisante pour un audit unitaire) :

```python
import anthropic, openai, google.generativeai as genai, json, math
from statistics import mean, stdev

# Constants from Protocol v2.0 Part 8
NARRATIVE_ROLE_WEIGHTS = {"hero": 1.00, "primary": 0.85, "supporting": 0.60,
                          "passing": 0.25, "negative": 0.10}
EVIDENCE_QUALITY = {"verified_reviews": 1.15, "documented_features": 1.10,
                    "certification": 1.10, "case_study": 1.05,
                    "media_coverage": 1.00, "community_reputation": 0.90,
                    "personal_knowledge": 0.75, "no_evidence": 0.60}
SOURCE_AUTHORITY_TIERS = {"tier1_press": 1.20, "tier1_linkedin": 1.15,
                          "tier2_specialized": 1.10, "tier3_community": 0.95,
                          "tier4_blog": 0.85, "tier5_unknown": 0.75}
FRESHNESS_DECAY_V5 = {"2026": 1.00, "2025": 0.90, "2024": 0.70,
                      "older": 0.50, "uncertain": 0.80}
SENTIMENT_WEIGHTS = {"strong_recommendation": 1.30, "positive": 1.00,
                    "neutral": 0.55, "negative": 0.15}

def position_decay(pos: int) -> float:
    return 1 / math.log(max(pos, 1) + math.e)

def calculate_query_score(agg: dict) -> float:
    pos_score = position_decay(agg.get("best_position", 5))
    sent_score = SENTIMENT_WEIGHTS.get(agg.get("best_sentiment", "neutral"), 0.55)
    hallu_factor = 0.70 if agg.get("has_hallucination", False) else 1.00
    consensus_factor = 0.40 + 0.60 * (agg["model_count"] / agg["total_models"])
    narrative_factor = NARRATIVE_ROLE_WEIGHTS.get(agg.get("best_narrative_role", "primary"), 0.85)
    rec_strength_factor = agg.get("best_recommendation_strength", 0.70)
    evidence_factor = EVIDENCE_QUALITY.get(agg.get("best_evidence_type", "community_reputation"), 0.90)
    freshness_factor = FRESHNESS_DECAY_V5.get(agg.get("best_knowledge_freshness", "2025"), 0.90)
    authority_factor = SOURCE_AUTHORITY_TIERS.get(agg.get("best_authority_tier", "tier3_community"), 0.95)
    quality_mean = (narrative_factor + rec_strength_factor + evidence_factor
                    + freshness_factor + authority_factor) / 5
    return pos_score * sent_score * hallu_factor * consensus_factor * quality_mean

def calculate_som_score(query_aggs: list, intent_weights: list, source_type_count: int) -> dict:
    MAX_PER_QUERY = position_decay(1) * 1.30 * 1.0 * 1.0 * 1.07  # ~1.060
    weighted_num = sum(w * calculate_query_score(a) for w, a in zip(intent_weights, query_aggs)
                       if a.get("cited"))
    weighted_denom = sum(intent_weights)
    cited_weight = sum(w for w, a in zip(intent_weights, query_aggs) if a.get("cited"))
    coverage_ratio = cited_weight / weighted_denom if weighted_denom else 0
    coverage_factor = math.sqrt(coverage_ratio)
    diversity_bonus = min(1.12, 1 + 0.025 * min(source_type_count, 5))
    normalized_quality = weighted_num / (weighted_denom * MAX_PER_QUERY) if weighted_denom else 0
    raw_score = normalized_quality * coverage_factor * diversity_bonus * 100
    final_score = round(min(100, max(0, raw_score)) * 10) / 10
    return {
        "som_score": final_score,
        "normalized_quality": normalized_quality,
        "coverage_factor": coverage_factor,
        "diversity_bonus": diversity_bonus,
        "coverage_ratio": coverage_ratio,
    }

def wilson_ci_90(p: float, n: int) -> float:
    if n == 0:
        return 0
    return 1.645 * math.sqrt(p * (1 - p) / n) * 100

def grade(score: float) -> str:
    if score >= 85: return "A+"
    if score >= 70: return "A"
    if score >= 55: return "B"
    if score >= 40: return "C"
    if score >= 20: return "D"
    return "F"

# Usage example
# query_aggs = [...]  # 21-28 dicts conformant to schema
# intent_weights = [...]  # parallel list
# result = calculate_som_score(query_aggs, intent_weights, source_type_count=4)
# print(f"SOM = {result['som_score']} ({grade(result['som_score'])})")
```

### 16.3 Automation cadre complet

Le code Python ci-dessus calcule le score SOM à partir d'agrégations déjà constituées. Pour une automation complète incluant les appels LLM, le parsing, la validation, le multi-sampling et le reporting Wilson CI, comptez environ 600 lignes de Python et 4 à 6 heures de développement par un ingénieur expérimenté.

L'orchestration parallèle multi-modèles avec gestion d'erreurs, cache, persistance, monitoring (telle que déployée par AI COMMAND) représente quant à elle environ 4 000 lignes et 60 jours-ingénieur. C'est le moat infrastructure préservé.

### 16.4 Reproductibilité auditable

Tout audit produit selon le protocole v2.0 doit pouvoir être reproduit à ±5 points par un opérateur tiers, en suivant strictement les Parts 1 à 12. Si un opérateur ne peut pas reproduire un score AI COMMAND à ±5 points, c'est soit qu'il y a un bug dans le protocole (signaler en issue GitHub), soit qu'une étape n'a pas été suivie (vérifier ground truth, K runs, sélection des clusters).

---

## ANNEXES

### A. Sources de référence

Cette annexe liste les sources qui ont inspiré la calibration des poids et formules du protocole v5.1. Les références bibliographiques précises (URLs DOI, archives stables) seront vérifiées et publiées dans l'annexe technique v2.0.1, conjointement à la grille de calibration des 12 marques benchmark.

| Source | Domaine | Apport au protocole |
|---|---|---|
| Princeton GEO 2024 (KDD Conference) | Recherche académique | Hiérarchie narrative role, mono-model concentration collapse, position decay logarithmique |
| AirOps 2025 | Industrie, corpus citations LLM | Calibration evidence_type et authority_tier sur citations LLM observées |
| SparkToro Janvier 2026 | Industrie, recherche audience | Mesure de la stochasticité LLM run-to-run |
| Profound 2026 | Industrie GEO | Hiérarchie d'autorité par domaine, élévation LinkedIn |
| Growth Memo 2026 | Industrie SEO/GEO | Règle des 30% (44.2% des citations IA proviennent du premier 30% du texte source) |
| Erlin 2026 | Industrie GEO | Effet seuil multi-plateformes |
| Digital Bloom 2025 | Industrie marketing IA | Drift mensuel des citations LLM |
| Ahrefs 2026 | Industrie SEO | Méthodologie Brand Radar |
| SE Ranking 2026 | Industrie SEO | Tracking AI Search Volume |

Les opérateurs souhaitant accéder aux références bibliographiques précises peuvent contacter `methodology@elmarq.fr`. La version v2.0.1 publiera une annexe bibliographique complète conforme aux standards de citation académique (APA 7e édition).

### B. Code source de référence

Le code de production AI COMMAND v5.1, dont les références de lignes sont citées tout au long de ce document, sera publié sous licence vérifiable en annexe technique v2.0.1. Les références `analyzeBrand.ts:NNNN` correspondent à la version v5.1 figée au commit publié à cette occasion. Les opérateurs souhaitant l'accès anticipé peuvent contacter `methodology@elmarq.fr`.

Fichiers publiés à v2.0.1 :

- `analyzeBrand.ts` (cœur algorithme, ~2 700 lignes)
- `scoring.ts` (fonctions pures de scoring, unit-testables)
- `prompts/` (templates secondaires : queries, repair, fact-check)

### C. Changelog v1.0 → v2.0

| Domaine | v1.0 | v2.0 |
|---|---|---|
| Facteurs | 10 nommés, poids ad hoc | 10 calibrés, sources citées |
| Narrative role | 4 niveaux | 5 niveaux (hero/primary/supporting/passing/negative) |
| Position decay | Linéaire `100 - (rank-1)×15` | Logarithmique `1 / log(pos + e)` |
| Hallucination | Additive `-20 par hallu` | Multiplicative binaire `0.70 si ≥1 hallu` |
| Freshness | Buckets mois (6/12/24) | Buckets années (2026/2025/2024/older/uncertain) |
| Source diversity | Per-citation 0/30/60/100 | Bonus global plafonné +12% |
| Coverage | Linéaire | Sub-linéaire (racine carrée) |
| Formule | Pondérée-additive | Multiplicative |
| Grading | 5 buckets | 6 buckets (A+/A/B/C/D/F) |
| Consensus factor | Absent | `0.40 + 0.60 × ratio` (intégral) |
| Recommendation strength | Absent | Continu 0-1 |
| Source authority | Confondu avec diversity | Distinct, 5 tiers calibrés |
| Ground truth | Absent | 7 champs obligatoires |
| Disambiguation homonymes | Absent | Protocole en 3 couches |
| Hallucination detection | Mention vague | Taxonomie SME FR 8 types, seuil 0.65 |
| Confidence intervals | Absent | Wilson 90% CI obligatoire |
| Multi-sampling | Suggéré | K=3 minimum, stability score |
| Mono-model collapse | Absent | Détecteur algorithmique |
| Calibration | Absente | Roadmap 12 marques benchmark v2.0.1 |
| Inter-rater reliability | Absent | Roadmap test 5 équipes v2.0.2 |

### D. Statut des livrables planifiés

| Livrable | Cible | Statut mai 2026 |
|---|---|---|
| Protocole v2.0 (ce document) | Mai 2026 | Publié |
| Annexe recommandations 6 paliers | Juin 2026 | À publier |
| Calibration 12 marques benchmark v2.0.1 | Juillet 2026 | Roadmap |
| Test inter-rater reliability v2.0.2 | Octobre 2026 | Roadmap |
| Guide d'implémentation API complet | Novembre 2026 | Roadmap |
| Whitepaper académique soumissible | Q1 2027 | Roadmap |

---

*SOM Scorecard Protocol v2.0, mai 2026.*
*Méthodologie ouverte par ELMARQ × AI COMMAND.*
*Algorithme reproductible, formule multiplicative, intervalles de confiance Wilson 90%, protocole anti-hallucination, calibration auditable.*
*Compatible ChatGPT, Claude, Gemini, Perplexity, Mistral, DeepSeek.*
*Le moat est l'infrastructure et l'expérience, pas le secret de la formule.*