Pourquoi un seed par page plutôt qu’un aléatoire global
Un générateur aléatoire global produit des pages différentes à chaque build, ce qui invalide les caches de contenu et empêche toute comparaison diff entre deux déploiements. Le seed dérivé du slug supprime cette instabilité : le même slug produit toujours exactement le même rendu, quelle que soit la date d’exécution du pipeline.
Le seed contrôle quatre paramètres indépendants : l’ordre des blocs de preuve, la formulation de l’accroche, la densité des données locales dans le corps, et la structure de la FAQ. Ces quatre axes de variation suffisent à faire tomber la similarité cosinus inter-pages sous le seuil de 0,85 mesuré par notre QA automatique.
Implémentation : de SHA-1 à un entier utilisable
Le pipeline extrait les quatre premiers octets du digest SHA-1 du slug normalisé (ASCII lowercase, tirets uniquement), les interprète en big-endian comme un Uint32, puis applique un modulo sur la taille de chaque table de variation. Ce calcul s’exécute en moins d’une microseconde par page et ne dépend d’aucune dépendance externe.
La normalisation du slug est critique : ’Paris-8e’ et ’paris-8e’ doivent produire le même seed, sinon un changement de casse involontaire génère une page structurellement différente. Un test d’intégration vérifie cette invariance à chaque push sur la branche principale.
Mesurer l’efficacité de la rotation
Après génération de chaque lot, le pipeline calcule la matrice de similarité cosinus sur les embeddings TF-IDF des 200 premiers tokens de chaque page. Si un couple dépasse 0,85, le build s’arrête avec un code d’erreur non nul et liste les slugs en cause. Ce seuil a été calibré empiriquement sur 4 000 pages de test.
Les statistiques de distribution sont exportées en JSON à chaque build : moyenne, percentile 95 et maximum de similarité. Un tableau de bord interne trace l’évolution de ces métriques build après build, ce qui permet de détecter une dérive si une nouvelle table de variation est trop restreinte.
Questions fréquentes
Le seed change-t-il si on renomme un slug ?
Oui, tout changement de slug produit un seed différent et donc une structure de page différente. C’est intentionnel : renommer un slug est une opération majeure qui déclenche une revue humaine avant publication.
Peut-on forcer un seed spécifique pour une page donnée ?
Un champ optionnel seed_override dans le manifeste JSON de la page permet de fixer le seed manuellement. Cette surcharge est tracée dans le log de build et signalée dans le rapport QA pour éviter tout oubli.