Le système de QA scriptée d’un cocon sémantique, environ 30 familles de règles

Vérifier un cocon sémantique page par page, à l’oeil nu, ne suffit plus à l’échelle de production que requiert un cocon de plusieurs centaines de pages. Un système de QA scriptée répond à cette limite en transformant chaque correction ponctuelle en une règle automatisée, capable de rechercher le même problème sur l’ensemble du cocon plutôt que sur la seule page où il a été repéré. Cette page détaille le principe directeur de ce système, la logique derrière le nombre de familles de règles qui le composent, et 2 exemples concrets de biais que seule une règle automatisée a permis de détecter. Cette page complète Étape 7 d’un cocon sémantique : valider les contenus avant publication.

Le principe : une correction n’est finie que cherchée partout

Le système de QA scriptée appliqué à la production d’un cocon sémantique repose sur un principe qui tranche avec la relecture traditionnelle : une correction n’est considérée comme terminée que lorsqu’une règle automatisée la recherche sur l’ensemble des pages concernées, pas seulement sur la page où l’erreur a été repérée la première fois. Ce principe, formalisé dans le skill de production cocon-semantique utilisé en interne, part d’un constat simple : une erreur repérée une fois sur une page a statistiquement de bonnes chances de se répéter ailleurs dans le même cocon, surtout quand la production s’appuie sur un pipeline en partie automatisé où le même gabarit, le même brief type ou le même modèle IA génère plusieurs pages selon des règles similaires. Corriger la seule page où l’erreur a été vue, sans vérifier si elle existe ailleurs, laisse donc un résidu invisible dans le reste du cocon.

La règle inverse tient en une phrase devenue le principe directeur de cette méthode de contrôle : un contrôle qui ne trouve rien n’est pas un contrôle qui passe. Autrement dit, l’absence de résultat à un contrôle ne prouve rien tant que ce contrôle n’a pas été conçu et exécuté pour chercher spécifiquement ce type d’erreur sur l’ensemble du périmètre concerné. Cette exigence transforme la nature même de la correction dans la production d’un cocon.

Corriger une page ne suffit jamais, il faut aussi transformer cette correction ponctuelle en une règle recherchable, capable de balayer automatiquement toutes les pages existantes et toutes les pages à venir du même cocon. Ce principe s’applique aussi bien à une erreur de contenu, un chiffre mal sourcé par exemple, qu’à une erreur strictement technique, un lien cassé ou une balise manquante. La nature de l’erreur importe moins que la discipline de recherche qui lui est appliquée une fois détectée : transformer l’observation ponctuelle en règle vérifiable sur l’ensemble du corpus, pour que la même erreur ne resurgisse plus, ni sur les pages déjà publiées, ni sur celles encore à venir dans le même cocon.

Pourquoi une trentaine de familles de règles, ni plus ni moins

Le système compte, à ce jour, environ 30 familles de règles bloquantes. Une famille de règles regroupe plusieurs vérifications automatisées qui portent sur un même type de problème : cohérence du maillage interne, respect du gabarit de Title et d’URL selon la typologie de page, absence de chiffres non sourcés, standards de lisibilité, présence des éléments attendus sur chaque brief de page, et bien d’autres catégories propres à la méthode. Ce nombre d’une trentaine n’est pas figé de façon arbitraire.

Il résulte de l’accumulation progressive de règles, chacune née d’une erreur réellement rencontrée sur un cocon livré, puis transformée en contrôle systématique pour ne plus jamais avoir à la détecter une seconde fois à l’oeil nu. La liste grandit donc naturellement au fil des livraisons, chaque nouvelle famille de règles correspondant à une leçon tirée d’un cas réel plutôt qu’à une anticipation théorique d’un problème qui ne s’est jamais produit. Qualifier une règle de bloquante implique une conséquence concrète : tant qu’une page ne passe pas ce contrôle, elle ne peut pas être considérée comme prête à publier, quelle que soit la qualité apparente du texte par ailleurs.

Cette discipline évite qu’une règle de contrôle ne devienne une simple suggestion ignorée sous la pression d’un délai de livraison serré, un risque réel sur une méthode de production qui déploie 1 à 2 cocons par jour à l’échelle de Hi-Commerce. Documenter chaque famille de règles au fil de son ajout évite qu’elle ne se perde dans la mémoire d’une seule personne de l’équipe. Le skill de production cocon-semantique conserve cette liste comme une ressource partagée, consultée et enrichie à chaque nouvelle livraison, plutôt que comme une liste figée rédigée une fois pour toutes.

Cette traçabilité importe d’autant plus que la méthode déploie plusieurs cocons par jour : sans elle, 2 projets différents risqueraient de découvrir, séparément et à des mois d’intervalle, la même erreur déjà résolue ailleurs.

2 exemples concrets de ce que ces règles détectent

2 exemples concrets, issus de livraisons réelles, illustrent ce que ces familles de règles détectent quand elles cherchent vraiment partout plutôt que ponctuellement. Le premier concerne la relecture à l’aveugle d’un quiz, appliquée sur le cocon siège ergonomique livré pour adopte un bureau le 18 octobre 2026 : une règle de contrôle a révélé que 68 % des bonnes réponses du quiz se trouvaient en première position dans la liste des choix, et que 47 % étaient la réponse la plus longue, 2 biais de construction qui rendaient le quiz devinable sans connaissance réelle du sujet. Le second exemple vient d’un document interne intitulé « Faits à valider », chez un client désigné MCF : 1289 affirmations chiffrées repérées dans le corpus de contenu se sont ramenées, une fois regroupées par une règle de détection systématique, à 135 faits distincts.

Chaque fait a ensuite été validé une seule fois avec le client, puis cette validation a été répercutée automatiquement sur toutes les pages qui mentionnaient ce même fait. Ces 2 exemples partagent un point commun : aucun des 2 biais, ni le biais de position du quiz, ni la redondance des affirmations chiffrées, n’aurait été visible à une relecture page par page classique. Il a fallu une règle conçue pour chercher spécifiquement ce type de régularité sur l’ensemble du corpus pour la faire apparaître, confirmant le principe fondateur du système : chercher partout, pas seulement là où l’erreur a déjà été vue une fois.

Ce que change une QA scriptée face à une relecture classique

Face à une relecture classique, qui dépend de la vigilance et de la mémoire d’un relecteur humain page après page, la QA scriptée change l’échelle du contrôle possible sur un cocon sémantique. Une règle automatisée ne se fatigue pas au bout de la cinquantième page, elle applique exactement le même niveau d’exigence sur la première page du cocon comme sur la dernière. Cette approche rejoint directement l’étape 7 de la méthode, valider les contenus, et son principe de check de tous les éléments.

La QA scriptée en est la version industrialisée, celle qui permet à l’équipe de passer d’une vérification ponctuelle, forcément partielle sur un cocon de plusieurs centaines de pages, à un contrôle exhaustif réellement applicable à cette échelle. La liste des 30 familles de règles continuera de grandir tant que la production de cocons continuera de révéler de nouveaux types d’erreurs. C’est précisément ce que signifie le principe directeur du système : une règle automatisée qui ne trouve rien aujourd’hui n’est pas une garantie de qualité en soi, elle n’est qu’une des 30 familles qui cherchent activement un problème précis.

La vraie garantie vient de l’accumulation de ces familles au fil des livraisons, pas d’une seule d’entre elles prise isolément.

Questions fréquentes

Testez vos connaissances

Stéphane Jambu LinkedIn ↗

Consultant e-commerce / visibilité / IA, fondateur de Hi-Commerce. Praticien du cocon sémantique depuis 2012, auteur de cette page dans le cadre du méta-cocon de référence Hi-Commerce sur le sujet.

Sources :

• skill cocon-semantique (documentation interne)
• Recette qualité, adopte un bureau, 18/10/2026
• Faits à valider, MCF