site-consistency — QA copy alignée offre

Audit de cohérence du site — Vérification textuelle alignée sur l'offre

Objectif : chaque texte du site raconte la même histoire — celle de l’offre présentée sur la page d’accueil — au même client, avec la même promesse, les mêmes noms et les mêmes termes. Auditez d’abord ; ne corrigez que ce que l’utilisateur approuve.

Deux limites strictes :

1. Audit avant correction. L’audit est en lecture seule. Aucun fichier n’est modifié tant que l’utilisateur n’a pas approuvé des lignes spécifiques du tableau d’audit.
2. Texte uniquement. Cette compétence modifie les mots — jamais la mise en page, les styles, les composants, les images, les itinéraires ou la structure de la page. Voir « Règles d’édition de texte uniquement ».

Langues

• Parlez à l’utilisateur dans la langue qu’il utilise dans la conversation. Le rapport, les en-têtes de tableau, les libellés de gravité et la colonne « pourquoi » sont dans cette langue.
• Les citations du texte actuel sont textuelles, dans leur langue d’origine.
• Le texte de site proposé est écrit dans la langue du texte qu’il remplace, de manière native et idiomatique (jamais une traduction littérale), en conservant la forme d’adresse du site (par exemple « tu »/« vous », « du »/« Sie ») et le ton.
• Détectez la ou les langues du site à partir de <html lang>, de la configuration i18n, des fichiers de paramètres régionaux et du texte visible. Sur les sites multilingues, identifiez la langue principale ; s’il n’est pas clair quelles langues auditer, demandez.

Flux de travail

Suivez les étapes dans l’ordre. Les étapes 1 à 6 ne modifient jamais les fichiers.

Étape 1 — Reconnaissance

Lisez references/text-inventory.md. Établissez :

• la pile et le routage (comment les URL correspondent aux fichiers),
• où se trouve le texte : composants/modèles, fichiers i18n, collections de contenu Markdown/MDX, métadonnées, modèles d’e-mails, CMS externe,
• les langues et la langue principale du site,
• les documents d’offre existants : docs/offer/offer-brief.md (rédigé par la compétence grand-slam-offer) ou tout document bref/positionnement dans docs/.

Si la majeure partie du texte se trouve dans un CMS externe et qu’il n’y a ni exportation ni URL pour lire le site rendu, dites à l’utilisateur ce qui peut et ne peut pas être audité avant de continuer.

Étape 2 — Extraire l’offre de la page d’accueil

Lisez la page d’accueil comme le ferait un visiteur pour la première fois : d’abord le héros, puis chaque section dans l’ordre, ainsi que <title>, la méta-description, l’en-tête et le pied de page. Remplissez le Tableau de l’offre :

Champ	Ce qu’il indique
Ce qui est vendu	produit/service et son format
Pour qui	le client/avatar, le segment, le marché
Promesse principale	le résultat obtenu par le client (+ délai, si indiqué)
Mécanisme / différenciateur	comment c’est livré, pourquoi ceci plutôt que les alternatives
Noms	orthographe exacte du nom de l’offre, du produit, de la méthode et des packages
Termes clés	prix/packages, garantie, rareté/délais, délai de livraison — uniquement ceux indiqués
Conversion principale	l’appel à l’action principal et ce qui se passe après avoir cliqué dessus
Ton	ton, forme d’adresse, positionnement (premium, économique, expert, convivial…)

Pour chaque champ, enregistrez la valeur et la source (citation + emplacement). Si un champ n’est pas sur la page d’accueil, écrivez « non indiqué ». Si un document d’offre existe, comparez-le champ par champ avec la page d’accueil.

Sur un site avec plusieurs offres distinctes (par exemple des services séparés pour différents publics), enregistrez l’offre globale de la page d’accueil et listez les sous-offres ; chaque page de sous-offre sera vérifiée par rapport à sa propre offre et par rapport à l’offre globale.

Étape 3 — Porte de clarté de l’offre

L’offre est claire lorsque toutes ces conditions sont remplies :

1. « Ce qui est vendu », « Pour qui », « Promesse principale » et « Conversion principale » peuvent être répondus à partir de la seule page d’accueil.
2. La page d’accueil présente une offre principale (ou une offre globale claire avec des sous-offres) — pas d’offres concurrentes.
3. La page d’accueil ne se contredit pas (deux prix, deux publics, deux promesses différentes).
4. La page d’accueil ne contredit pas le document d’offre, s’il existe.

Claire → continuez. Le Tableau de l’offre est la référence ; il se trouve en haut du rapport pour que l’utilisateur puisse le corriger.

Pas claire → arrêtez-vous et demandez à l’utilisateur des informations sur l’offre avant d’auditer quoi que ce soit d’autre. Ne devinez jamais l’offre pour franchir cette porte.

• Utilisez l’outil AskUserQuestion s’il est disponible (max 4 questions par tour), avec des options construites à partir des candidats que vous avez réellement trouvés sur le site, plus un espace pour une réponse personnalisée. Sinon, demandez dans le chat.
• Demandez uniquement sur les champs manquants ou contradictoires, par exemple « La page d’accueil vend à la fois X et Y — quelle est l’offre principale ? », « Le client principal est-il A (héros) ou B (section services) ? », « Le brief indique une garantie de 30 jours, la page d’accueil de 14 jours — laquelle est actuelle ? ». Pour plusieurs offres, confirmez la hiérarchie (offre principale vs sous-offres).
• Enregistrez les réponses dans le Tableau de l’offre avec la source « confirmé par l’utilisateur ». Le texte peu clair ou contradictoire de la page d’accueil devient alors des constatations — la page d’accueil est auditée par rapport à l’offre confirmée comme toutes les autres pages.

Étape 4 — Inventaire des pages et du texte

Listez tout ce qu’un visiteur peut lire (détails dans references/text-inventory.md) :

• chaque itinéraire/page, y compris les itinéraires dynamiques et les collections de contenu,
• texte partagé : en-tête, navigation, pied de page, bannières, modaux/popups, formulaires (étiquettes, espaces réservés, validation, messages de succès/erreur), états 404/500 et vides,
• texte que les visiteurs voient indirectement : <title>, méta-description, balises Open Graph/Twitter, champs de texte JSON-LD, alt, aria-label, nom/description du manifeste web,
• e-mails transactionnels et notifications, si leurs modèles sont dans le dépôt.

Attribuez à chaque page son rôle narratif (voir references/consistency-checklist.md) — le rôle détermine ce que « cohérent » signifie pour cette page.

Grands sites : auditez chaque page principale en entier. Pour les grandes collections du même type (par exemple plus de 20 articles de blog ou produits), auditez le modèle partagé plus le titre, la description, l’intro et l’appel à l’action de chaque élément ; dites dans le rapport exactement ce qui a été couvert de cette manière et proposez un passage complet. Si l’outil Agent est disponible, vous pouvez répartir l’inventaire entre sous-agents — donnez à chacun le Tableau de l’offre confirmé, la liste de contrôle et sa liste de pages, puis fusionnez leurs constatations dans un seul tableau.

Étape 5 — Audit

Lisez references/consistency-checklist.md. Vérifiez chaque unité de texte par rapport au Tableau de l’offre sur toutes les dimensions (D1–D10), dans le contexte du rôle de sa page. Pour chaque constatation, enregistrez : emplacement, citation textuelle, dimension, gravité, pourquoi c’est un problème (lié à un champ spécifique du Tableau de l’offre), type de correction et texte proposé.

• Construisez d’abord la matrice des faits (chaque mention du prix, de la garantie, des délais, des places, du délai de livraison, des noms — côte à côte) afin que les contradictions entre les pages soient détectées systématiquement, et non par hasard.
• Le texte proposé suit les Règles d’édition de texte uniquement et n’invente jamais de faits. Un fait manquant devient un espace réservé dans la langue du site (par exemple [À COMPLÉTER : …], [DO UZUPEŁNIENIA : …]).
• Faits contradictoires dont la vérité n’est pas établie → type de correction Décision : listez les options, n’en choisissez pas une.
• Problèmes que le texte ne peut pas résoudre (image montrant un produit différent, section ou bouton d’appel à l’action manquant, page qui ne devrait pas exister, cible de lien incorrect, slug d’URL) → « Hors du champ du texte » — signalés, jamais corrigés par cette compétence.

Étape 6 — Rapport d’audit, puis arrêtez-vous

Présentez le rapport exactement comme dans « Format de sortie ». Le rapport se termine toujours par le tableau des constatations. La seule chose autorisée après le tableau est la question d’approbation. Arrêtez-vous ensuite et attendez — ne modifiez aucun fichier à ce tour.

Question d’approbation (utilisez AskUserQuestion si disponible) :

• Tout appliquer
• Appliquer uniquement les critiques et majeures
• Appliquer les lignes sélectionnées (l’utilisateur liste les # et peut modifier toute proposition)
• Ne pas appliquer — audit uniquement

Chaque ligne Décision que l’utilisateur souhaite appliquer nécessite une réponse ; demandez-les dans le même tour si possible.

Étape 7 — Appliquer les correctifs approuvés

• Appliquez uniquement les lignes approuvées, avec les modifications de l’utilisateur, en suivant les Règles d’édition de texte uniquement.
• Avant de modifier une chaîne, vérifiez où elle est également rendue (clé i18n partagée, composant partagé, partiel Markdown réutilisé). Si le nouveau texte ne correspond pas à l’un de ces contextes, arrêtez-vous et demandez.
• Si un correctif approuvé s’avère nécessiter une modification non textuelle, ou ne peut pas être appliqué comme approuvé, ignorez-le et signalez-le. N’improvisez pas un correctif différent.
• Texte stocké dans un CMS externe : n’essayez pas de le modifier ; préparez une liste de copier-coller (entrée/champ CMS | texte actuel | nouveau texte).

Étape 8 — Vérifier et signaler

• Relisez chaque passage modifié avec le texte qui l’entoure — il doit se lire naturellement dans son contexte.
• Recherchez les restes des anciennes variantes (anciens noms, anciens termes, ancienne promesse) dans le champ approuvé.
• Validez les fichiers modifiés : analyse JSON/YAML, les fichiers de paramètres régionaux conservent les mêmes clés, les variables d’interpolation sont intactes. Exécutez lint/typecheck/build du projet s’il est disponible et rapide.
• Multilingue : listez les autres langues dont les chaînes nécessitent une mise à jour correspondante, sauf si l’utilisateur a approuvé leur mise à jour également.
• Terminez par le tableau récapitulatif : # | Où | Statut (Appliqué / Ignoré — raison / Nécessite une mise à jour CMS) | Changement (court). Ne validez pas sauf demande.

Règles d’édition de texte uniquement

Autorisé :

• contenu de chaîne visible par l’utilisateur : nœuds de texte dans JSX/modèles, littéraux de chaîne rendus aux utilisateurs, valeurs i18n, prose Markdown/MDX, champs de texte frontmatter (titre, description), fichiers CMS/contenu dans le dépôt,
• attributs de texte et métadonnées : alt, title, aria-label, placeholder, <title>, méta-description, texte OG/Twitter, valeurs de texte JSON-LD, nom/description du manifeste,
• messages de formulaire, système et modèle d’e-mail,
• réécriture, raccourcissement ou suppression de phrases dans un élément de texte existant.

Non autorisé (signalez plutôt sous « Hors du champ du texte ») :

• ajout, suppression, réorganisation ou restylage d’éléments, de sections ou de composants ; modification du balisage, des classes, du CSS ou des propriétés non textuelles,
• vider un élément — un élément vide est un changement de mise en page ; réécrivez-le à la place,
• clés i18n, noms de variables, noms de fichiers, itinéraires, slugs d’URL, ancres (les slugs sont du texte, mais les changer brise les liens et le référencement),
• cibles de lien (href) — seul le texte du lien peut changer,
• images, icônes, vidéos et autres médias,
• logique de code, conditions, récupération de données.

Pendant l’édition :

• Préservez l’interpolation et la syntaxe : {name}, {{count}}, %s, :attribute, ICU plural/select, les entités HTML, les balises en ligne dans les chaînes (<strong>, <br>, <0>…</0>), le formatage Markdown et l’échappement (guillemets dans JSX/JSON, apostrophes dans les chaînes PHP).
• Gardez la longueur proche de l’originale (environ ±30 %) car la mise en page ne change pas. Si une correction nécessite beaucoup plus de texte, dites-le dans la proposition.
• Respectez les conventions typographiques du site (guillemets, tirets, espaces insécables).

Règles obligatoires

• R1. Audit en lecture seule. Aucune modification et aucune écriture de fichier (y compris les fichiers de rapport, sauf si l’utilisateur en demande un) avant approbation explicite. L’approbation ne couvre que les lignes approuvées.
• R2. Texte uniquement. Tout ce qui est en dehors des Règles d’édition de texte uniquement est signalé, jamais modifié.
• R3. Référence d’abord. N’auditez jamais par rapport à une offre devinée : le Tableau de l’offre est soit clair depuis la page d’accueil, soit confirmé par l’utilisateur.
• R4. Preuve. Chaque constatation cite le texte actuel textuellement et donne un emplacement précis (fichier:ligne ou clé i18n).
• R5. Le tableau vient toujours en dernier. Chaque rapport d’audit se termine par le tableau des constatations, également lorsqu’il n’y a aucune constatation — dans ce cas, il se termine par un tableau de couverture (Page | Rôle | Verdict).
• R6. Aucun fait inventé. Les propositions n’ajoutent jamais de chiffres, de résultats, de témoignages, de garanties ou de termes que l’utilisateur n’a pas fournis ou que le site n’indique pas déjà de manière cohérente. Conflit → Décision. Manquant → espace réservé.
• R7. Cohérence, pas uniformité. Ne collez pas la promesse du héros partout et n’imposez pas un discours de vente sur chaque page. Signalez uniquement le texte qui contredit, dilue, s’écarte ou détourne de l’offre, compte tenu du rôle de la page. Les pages légales ne sont jamais réécrites pour le récit — seuls leurs conflits factuels avec le texte marketing sont signalés, avec une recommandation de faire réviser le texte légal.
• R8. Alignez sur l’offre, ne la reconcevez pas. Cette compétence aligne le site sur l’offre confirmée. Si l’offre elle-même est faible (promesse vague, aucune preuve, axée sur le prix), dites-le en une ligne du résumé et suggérez la compétence grand-slam-offer ; ne reconstruisez pas l’offre ici.
• R9. Langue. Communication dans la langue de la conversation ; texte de site proposé dans la langue du texte qu’il remplace.

Format de sortie

Rapport d’audit

Sections dans cet ordre, rédigées dans la langue de la conversation :

1. Offre de référence — le Tableau de l’offre (tableau compact) + sa source (page d’accueil / document d’offre / confirmé par l’utilisateur).
2. Périmètre — pages et sources de texte auditées (nombre + liste ou regroupement), langues, ce qui a été couvert par échantillonnage, ce qui se trouve en dehors du dépôt et n’a pas été audité.
3. Résumé — nombre de constatations par gravité ; les 2-3 plus gros problèmes narratifs, une phrase chacun ; éventuellement une ligne sur l’offre elle-même (R8).
4. Réécritures complètes (uniquement si nécessaire) — propositions de plus de ~40 mots, en entier, étiquetées avec le numéro de constatation.
5. Hors du champ du texte (uniquement s’il y en a) — courtes puces ; cette compétence ne les corrigera pas.
6. Tableau des constatations — le dernier élément du rapport.

Tableau des constatations — les en-têtes sont traduits dans la langue de la conversation :

#	Où	Gravité	Aujourd’hui	Pourquoi cela ne devrait pas être comme ça	Correctif proposé

• # — ID stable utilisé pour l’approbation.
• Où — page · section · fichier:ligne ou clé i18n.
• Gravité — Critique / Majeure / Mineure (voir la liste de contrôle).
• Aujourd’hui — citation textuelle du fragment pertinent ; raccourcissez avec « … » au-delà de ~25 mots.
• Pourquoi cela ne devrait pas être comme ça — le conflit concret avec la référence, par exemple « page d’accueil : pour les cliniques dentaires ; ici : pour toute entreprise ».
• Correctif proposé — le nouveau texte exact dans la langue du site, « voir Réécritures complètes #N », ou DÉCISION : A) … / B) ….

Triez par gravité, puis par ordre de page de l’inventaire.

Par exemple, dans une conversation en polonais, les trois en-têtes principaux deviennent « Jak jest dziś », « Dlaczego tak nie powinno być », « Jak to poprawię ».

Exemple de lignes (site anglais, conversation anglaise) :

| # | Where | Severity | Today | Why it shouldn't be like this | Proposed fix | |---|---|---|---|

…

[abrégé pour la traduction]