Le ratio de tokens uniques, votre seuil de dilution
Le volume de mots d'une page pSEO est un vanity metric. La véritable valeur d'un gabarit se mesure à son ratio de tokens uniques face au boilerplate.
On mesure trop souvent la « richesse » d'une page programmatique au nombre de mots. Mais 1 200 mots dont 1 050 identiques sur toutes les URL générées par le gabarit, ce n'est pas du contenu — c'est du boilerplate déguisé. La véritable métrique d'évaluation est le rapport entre la partie variable et la partie fixe, calculé paritairement sur chaque template.
Le compteur de mots est un vanity metric
L'industrie s'est habituée à évaluer la qualité d'une page à sa longueur. Dans une logique de production à l'échelle, cette approche masque la duplication systémique. Un gabarit textuel massif donne l'illusion d'une couverture sémantique exhaustive, mais si 90 % du texte reste statique sur dix mille URL, la valeur marginale de chaque nouvelle page tend vers zéro. Les moteurs de recherche traditionnels désindexent ou ignorent ces variations mineures, et les LLMs effondrent cette redondance lors de la phase de vectorisation.
La longueur brute dissimule l'information spécifique. Si l'entité cible est noyée dans un océan de formulations génériques, le signal se perd. Les collisions vectorielles se multiplient : les pages deviennent indiscernables les unes des autres dans l'espace d'embedding. C'est la raison principale pour laquelle le pSEO pourrit en silence : l'architecture technique fonctionne, les pages sont générées, mais la dilution extrême du signal empêche toute performance organique durable.
Remplacer le comptage de mots par l'analyse de la variance textuelle permet d'éliminer l'illusion de profondeur pour auditer la valeur réelle de l'inventaire.
Définir le ratio de tokens uniques par template
La méthode LIMEN/Sonar impose une bascule vers une mesure stricte : le ratio de tokens uniques. La formule est directe : le nombre de tokens variables distincts divisé par le nombre de tokens totaux de la page. Cette métrique ne s'évalue pas sur une URL isolée, mais sur un échantillon représentatif d'un même template. On isole le dénominateur commun — le boilerplate — pour extraire le delta sémantique réel.
Concrètement, l'analyse requiert de parser le DOM, d'exclure la navigation et les footers, puis de tokeniser le contenu principal. En comparant les empreintes textuelles via des algorithmes de shingling sur cinquante pages issues du même gabarit, on identifie immédiatement la part de texte injectée dynamiquement. Puisque vos pages valent votre base de données, ce ratio reflète l'exacte granularité de votre modèle de données sous-jacent.
L'application de cette formule offre une mesure mathématique et indiscutable de la singularité d'un gabarit.
Fixer un seuil de dilution acceptable
Il n'existe pas de seuil universel. Exiger 40 % de tokens uniques sur une page annuaire locale n'a pas le même sens que sur un comparateur de logiciels B2B. Le seuil de dilution doit être calibré par verticale et par type d'intention. Une page transactionnelle courte peut tolérer un ratio plus bas si la donnée variable — prix, stock, spécifications techniques — est hautement discriminante.
À l'inverse, un template éditorial programmatique nécessite un ratio élevé pour justifier son existence. Si la dilution est trop forte, la page n'est plus extractible. Or, pour exister dans les interfaces génératives, il faut concevoir un template pensé pour être cité, pas juste indexé. Un LLM ne citera pas une page dont la charge utile est noyée dans un discours générique préfabriqué.
Une page trop diluée n'est ni citable par un LLM, ni indexable proprement par un moteur classique.
Définir des seuils spécifiques permet d'aligner l'exigence technique sur la réalité concurrentielle de la verticale visée.
Intégrer le ratio à la grille QA scorée
Le ratio de tokens uniques n'est pas un simple indicateur de reporting, c'est un critère de « gate » dans le processus d'Assurance Qualité. Au même titre que le Core Web Vitals ou le temps de réponse serveur, il intègre la grille QA scorée du projet pSEO. Tout nouveau template, ou toute évolution d'un gabarit existant, doit valider ce seuil en environnement de staging avant déploiement.
Ce contrôle continu prévient la dégradation silencieuse de l'inventaire. Lorsqu'une équipe marketing décide d'ajouter un paragraphe explicatif fixe sur toutes les pages d'une catégorie, le ratio de tokens uniques chute mécaniquement. Le QA bloque alors la mise en production, forçant les équipes à reconsidérer l'ajout de texte statique au profit d'une véritable ingénierie de la donnée.
L'automatisation de cette mesure sécurise les déploiements en bloquant les régressions qualitatives avant la mise en production.
Remonter la dilution vers le template, pas vers la page
Face à un ratio de tokens uniques insuffisant, le mauvais réflexe consiste à vouloir étoffer manuellement certaines pages pour passer le seuil. Cette approche détruit la scalabilité du pSEO. La dilution est un symptôme structurel ; sa résolution doit l'être tout autant. Il faut remonter le problème au niveau du brief type et de la source de données.
Si le ratio est trop bas, la solution consiste à enrichir le modèle de données. Ajoutez de nouveaux champs variables, intégrez des requêtes d'API tierces pour contextualiser l'entité, ou créez des modules dynamiques conditionnels. L'objectif est de corriger le brief, pas les 500 pages. En augmentant la densité de la donnée brute injectée, on élève mécaniquement le ratio sur l'ensemble du cluster.
Traiter la dilution à la racine garantit une scalabilité saine de l'architecture et maintient la rentabilité du modèle programmatique.