Méthodologie

Ce que nous mesurons, par moteur

Le SEO provient de vos propres données Google Search Console et il est déterministe : les mêmes données donnent le même score. Les 28 derniers jours sont comparés aux 28 jours précédents. L’intervalle (80 %) reflète la variation d’une semaine à l’autre par blocs de 7 jours, car les données de Search Console sont un recensement, pas un échantillon.

La préparation AEO provient de contrôles déterministes sur le HTML et les réponses HTTP de vos pages, sans modèle de langage ni grille d’évaluation. Chaque contrôle en échec est accompagné d’une preuve que vous pouvez contester.

La part de citations GEO indique à quelle fréquence un moteur d’IA cite votre domaine parmi ses sources pour un ensemble fixe de prompts. Chacun des 6 moteurs, et chaque langue, est présenté séparément et n’est jamais moyenné avec les autres.

Les trois scores ne sont jamais fusionnés en un seul nombre. Le type de données qui les contient n’a aucun champ pour un score combiné, et un test échoue si quelqu’un en ajoute un.

Taille et cadence du panel

La langue d’une question et le choix des prompts font bouger les citations des IA bien plus que le fait de reposer la même question. 2 exécutions par prompt constituent le minimum qui permet encore d’estimer le bruit d’une exécution à l’autre ; exécuter chaque jour multiplierait le coût sans resserrer l’intervalle. Le compromis est assumé : un changement de citations n’est jamais détecté en moins d’une semaine.

60 réponses par moteur et par langue donnent des intervalles larges, souvent trop larges pour distinguer deux parts proches. Sonar affiche cette largeur au lieu de la cacher.

Comment les intervalles sont calculés

Les intervalles proviennent d’un bootstrap de clusters. L’unité rééchantillonnée est un cluster de prompts, tiré avec remise avec toutes ses exécutions. Les prompts d’un même sujet montent et descendent ensemble : traiter chaque réponse comme indépendante donnerait des intervalles plus étroits qu’ils ne le sont.

Chaque intervalle utilise 2 000 réplications bootstrap à un niveau de 95 %, avec la méthode des percentiles « expanded ». Elle a été retenue parce que sa couverture en simulation était la plus proche de la valeur nominale parmi les méthodes testées.

Un nombre GEO n’est étiqueté mesuré que si chaque prompt a été exécuté au moins 2 fois et s’il existe plus d’un cluster de prompts à rééchantillonner. Sinon, il est étiqueté indicatif, avec la taille de son échantillon, et un cluster unique reçoit l’intervalle le plus large possible.

Les graines aléatoires sont dérivées du moteur et de la langue : les mêmes données reproduisent toujours le même intervalle.

Conception du holdout : pourquoi un avant/après n’est pas une preuve

Le trafic évolue pour des raisons sans rapport avec une modification : saisons, jours fériés, mises à jour des moteurs de recherche, lancement d’un concurrent. Une comparaison avant/après mélange tout cela dans le résultat. C’est pourquoi chaque affirmation d’impact de Sonar compare les pages modifiées à un holdout de pages similaires jamais touchées, sur les mêmes jours.

Au moins 10 % des URL, et au moins 10 % des clusters de prompts, sont mis en holdout. L’appartenance est décidée par un hachage à clé, non par un classement : ajouter des pages ne rebat jamais les membres existants. Les membres du holdout ne sont jamais retirés ni mis à la retraite.

Les pages sont randomisées par cluster de requêtes de recherche, et non une à une : les pages qui partagent leurs requêtes principales sont affectées ensemble, si bien qu’une modification sur une page ne peut pas prendre de clics à une page témoin. Une expérience ne s’ouvre que si le plus grand cluster détient au plus 30 % des clics et qu’au moins 10 clusters ont des clics.

L’estimateur est une double différence avec un modèle saisonnier hebdomadaire et un bootstrap par blocs mobiles (blocs de 7 jours, 2 000 réplications). Un plancher de Poisson empêche les sites à faible trafic d’obtenir des intervalles faussement étroits. Il faut 70 jours d’historique avant la modification et une lecture de 28 jours après.

GOOD exige une probabilité de gain d’au moins 95 % et le franchissement d’une borne séquentielle ; BAD exige une probabilité de préjudice d’au moins 90 % ; NEUTRAL exige qu’au moins 80 % de la probabilité se situe dans ±3 %, la plus petite hausse qui vaille d’être maintenue. La borne séquentielle consomme un budget d’erreur de 5 % dans chaque sens, si bien que vérifier chaque jour n’augmente pas les fausses alertes. Tout le reste demeure RUNNING ou se termine en UNDERPOWERED, affiché en gris et jamais en vert.

Sans holdout, le rapport d’impact refuse de s’afficher. Il n’est pas remplacé par un nombre avant/après.

Résultats des tests A/A

Un test A/A ne change rien : chaque verdict GOOD ou BAD qu’il produit est donc une fausse alerte. L’ensemble du pipeline de verdicts, le même code qui juge les vraies expériences, a été exécuté sur des sites simulés dont la répartition entre bras et le bruit ont été calibrés sur un site réel.

0 faux verdict sur 100 exécutions A/A, réparties sur 5 niveaux de trafic.

Le tableau montre aussi la partie inconfortable : à faible trafic, même une hausse réelle est rarement détectée, car un verdict GOOD exige plus de certitude que ne le suppose la formule classique du MDE. C’est pourquoi Sonar affiche votre MDE avant le début d’une expérience, et pourquoi ce qu’il vend dépend de la puissance mesurée.

Ce sont des simulations, enregistrées le 24 septembre 2026. Un test A/A sur une série de trafic réelle nécessite 98 jours de données définitives et le site de laboratoire en avait alors 69. Les données définitives suffisent depuis le 20 octobre 2026, mais le résultat sur la série réelle n’est pas encore publié : le tableau ci-dessus reste simulé.

Effet minimal détectable par niveau de trafic

L’effet minimal détectable (MDE) est la plus petite hausse qu’une expérience peut distinguer du bruit, avec un seuil de signification bilatéral de 5 % et une puissance de 80 %. Sonar le calcule pour votre site avant le début de toute expérience.

Une affirmation d’impact n’est vendue que si le MDE mesuré est d’au plus 12 %. Entre 12 % et 25 %, les résultats sont présentés comme indicatifs. Au-delà de 25 %, aucune affirmation d’impact n’est faite.

Les chiffres de planification supposent des jours indépendants, une surdispersion prudente et le holdout minimal. Le chiffre qui fait foi est mesuré sur vos propres données avec le bootstrap par blocs. Dans les exécutions A/A ci-dessus, il est ressorti plus petit que le chiffre de planification, mais sur un autre site il peut être plus grand.

Ce que nous refusons d’affirmer

Certains chiffres se vendraient mieux. Sonar ne les affiche pas.

• Un score de visibilité unique et combiné. SEO, AEO et GEO restent trois nombres distincts.
• Un impact tiré d’une comparaison avant/après. Les graphiques avant/après portent la mention « pas une preuve d’impact ».
• Un nombre GEO sans son intervalle, ou l’étiquette mesuré sur des données seulement indicatives.
• Une affirmation d’impact pour un site dont le MDE dépasse 25 %.
• Une tendance qui enjambe un changement de version du modèle d’IA. Une nouvelle version du modèle démarre une nouvelle série.
• Des résultats agrégés d’autres clients avant qu’au moins 3 clients différents et 3 clusters indépendants y contribuent.
• Des notes, avis, prix ou témoignages qui n’existent pas.

Boucle de sécurité

Sonar écrit sur des sites en ligne : chaque écriture est donc limitée, vérifiée et réversible.

Les connexions et ce que chacune peut modifier

La façon dont Sonar applique les corrections dépend de la connexion de votre site. Le tableau est généré à partir de ce que chaque connexion prend réellement en charge aujourd’hui.

• Edge (Cloudflare) : l’éventail de corrections le plus large, appliquées devant votre site. Fonctionne pour tout domaine : faites pointer un nom d’hôte vers Sonar avec un CNAME, quel que soit votre fournisseur DNS.
• WordPress : l’extension Sonar plus un mot de passe d’application. Titres, descriptions, sections FAQ et nouvelles pages.
• GitHub : Sonar ouvre des pull requests sur votre dépôt, pour les sites générés à partir de fichiers.
• Shopify : une app personnalisée dans votre boutique. Balises meta et blocs sur la page.
• Webflow : un jeton d’API. Titres et descriptions de page uniquement.
• Contentful, Sanity, Strapi (correspondance des champs par type de contenu), Wix, Squarespace et HubSpot : un jeton d’API. Titres et descriptions, plus la balise canonical quand l’API a le champ ; le reste passe en mode export.

Ce qu’il vous faut

• Google Search Console : ajoutez le compte de service de Sonar affiché dans l’assistant de configuration comme utilisateur restreint de votre propriété.
• Bing Webmaster Tools : demandez au propriétaire de Sonar d’ajouter votre site au compte Bing de l’équipe.
• Connexion edge : accès à vos réglages DNS pour ajouter un enregistrement CNAME (n’importe quel fournisseur DNS). Si vous ne pouvez pas modifier le DNS, utilisez plutôt WordPress, Shopify, Webflow ou GitHub.
• Une application d’authentification pour le second facteur, requise pour connecter un site.
• Au moins deux langues de contenu pour l’entreprise si vous voulez le panel de citations GEO.