Pages agents : passe de finition (pixel, mouvement, copy, avis)

2026-09-26, pilier growth-web. Périmètre : les six pages /agents/[slug] (atlas, maya, marco, otis, faye, sam) dans les six langues. Gabarit src/components/patterns/marketing/agent-page/**, chargeur src/app/(marketing)/agents/[slug]/_components/**, copy messages/*.json → marketingPages.agents.page, vérité produit src/features/ai/agents/identity-registry.ts et src/features/ai/agents/agents/specialists.ts.

Référence : la page Atlas approuvée (standalone.html du paquet atlas-page, hors dépôt), mesurée par le harnais de comparaison (texte par texte, boîte par boîte, puis diff pixel par section). Aucun code ni asset du paquet n'est repris : les valeurs relevées (durées, courbes, rayons, bordures) sont réécrites dans nos modules CSS.

1. Ce qui manquait, page par page et section par section

Constat avant la passe, sur les six pages :

Exceptions acceptées et documentées (décision de gouvernance, 2026-09-26), gardées en minimisant leur impact :

• Pastilles de statut : toujours visibles, jamais cachées. Elles ne vivent plus dans le hero ni dans les scénarios (un scénario non livré est un item de roadmap, copy.md §7), et elles ne font plus grandir la ligne qui les porte (marges verticales négatives, §3). Elles restent sur une ligne de capacité, une carte du mur et une réponse de FAQ par agent, là où le produit n'est pas encore livré, avec la phrase qui le dit.
• Lien vers l'équipe : conservé sous les CTA, sans hauteur ajoutée.
• Ligne Trustpilot du hero : rendue seulement depuis un résumé réel (readTrustpilotSummary), jamais par défaut. En son absence le harnais masque aussi la ligne côté référence.

2. Écarts pixel, par largeur

Mesure : compare-uw (notre /fr/agents/atlas rendu à la largeur V, référence rendue à la largeur du panneau P, puisque la page vit dans le panneau du shell marketing). Boîtes en px relatifs à la racine [data-agent-page] ; « Δh » = hauteur de section, nous moins référence ; « diff » = part des pixels qui diffèrent (seuil 48 sur la somme RGB).

Lecture importante. Le texte d'Atlas a été réécrit dans cette passe : à partir de là, le diff pixel mesure aussi un texte différent, et les hauteurs d'une section qui suit le contenu (cartes de scénario, mur, FAQ) suivent la longueur du texte. Les réponses de scénario et le corps de la carte signée ont été resserrés à la longueur de la référence (cinq lignes, environ 170 caractères) pour que la grille reste celle qui a été approuvée. Le fond du hero de la référence charge deux assets externes (anneau SVG, masque de points PNG) que le harnais bloque : notre anneau et notre trame, dessinés en CSS/SVG, comptent donc comme des différences alors que la référence rend un fond vide à cet endroit.

Avant (copy approuvée, gabarit d'avant la passe)

À 1440, 92 textes sur 97 appariés étaient décalés de plus de 2 px, tous en aval de la pastille du hero (Δy −14,5 / +14,6), puis de la pastille de la carte (+22,3), puis du lien d'équipe (+64,6 sur les CTA de clôture).

Après (copy réécrite, gabarit corrigé)

À 1920 et 1440, les six sections ont exactement la hauteur de la référence, et seulement 19 textes appariés sur 43 bougent de plus de 2 px, tous à cause de leur propre texte (signatures du mur qui suivent la longueur d'une carte, largeur du mot « Découvrez » et du libellé « Scénario », déjà présentes avant la passe). Les écarts restants sous 991 px ont tous été vérifiés côte à côte (cmp-final5/sbs-<largeur>-<section>.png) et viennent tous du texte, jamais de la grille : les promesses du hero de la référence passent sur deux lignes à 586 et 750 px, pas les nôtres (hero plus court) ; une réponse de scénario prend une ligne de plus dans le carrousel à 1,1 carte (+18 / +23) ; le titre du mur tient sur une ligne au lieu de deux à 750 px (−36) ; le titre de la carte signée et une question de FAQ tiennent sur une ligne de moins à 372 px (−21, −19).

Deux corrections de gabarit sont venues de cette mesure sous 991 px :

• le titre de clôture de la référence est une seule chaîne équilibrée, qui casse au point sur desktop par hasard de largeur. Notre <br> forcé donnait quatre lignes au lieu de trois à 372 px (+47 px, 28,47 % de pixels différents). Il est masqué sous 991 px ;
• l'espacement entre le texte et les boutons de clôture passe de 3em à 2,25em sous 991 px (le pas « 48 » de la référence vaut 36 px nominaux en tablette, mesuré : 49,1 px sur une base de 21,8 px). Clôture : +12,8 / +16,4 / +11,5 px → 0 à 1024 / 768 / 390.

Contrôle structurel sur les 36 pages (6 agents × 6 langues) × 5 largeurs (shots/final.mjs, 180 rendus, puis 66 rendus de contre-vérification après les derniers titres) : statut 200, aucune clé brute ni {placeholder} visible, aucun tiret, aucun débordement horizontal, et aucune pastille renvoyée seule sur une ligne. Le premier passage en trouvait 15 (surtout en portugais, dont le libellé « Em desenvolvimento » est le plus long) : les titres porteurs d'une pastille ont été raccourcis langue par langue.

2.1 Harnais

Le harnais compare-uw pendait à 1024, 768 et 390 : à une fenêtre de 1024 px, le panneau ne fait que 586 px, et à cette largeur le document.fonts.ready de la référence ne se résout jamais (requêtes de police bloquées). La variante compare-uw2 borne l'attente des polices et des images à 4 s et ouvre la référence dans son propre contexte ; les chiffres « après » ci-dessus en sortent.

3. Corrections du gabarit

4. Parité des animations

Jetons relevés sur la référence : --smooth-ease: cubic-bezier(0.5, 0, 0, 1), --duration-s: 0.45s (toutes les transitions d'interface), rotation des anneaux 10s linear infinite avec pause hors écran, entrée de la ligne d'avis (0.58s cubic-bezier(.22,1,.36,1) à 0,10 s, étoiles 0.42s décalées de 0,085 s à partir de 0,22 s), entrée d'un onglet de FAQ (translateX(1em) → 0 et opacité, 0,45 s). La référence n'a aucune animation d'entrée au défilement sur les sections : nous n'en ajoutons pas (la loi 8 du skill cède ici à la parité, décision du 2026-09-26).

Mesure : shots/motion.mjs déclenche chaque interaction sur les deux pages et relit la propriété animée à t = 0, 150, 300, 450, 800 ms et 2 s. Les deux pages n'ont pas la même largeur (notre panneau de 1002 px contre la référence à 1440 px), donc on compare la fraction du trajet parcourue, pas des pixels.

Captures du hero à t = 0 / 300 / 800 / 2000 ms, nous et référence : scratchpad/shots/motion-{ours,ref}-hero-t{0,300,800,2000}.png. La référence y rend un fond sans anneau : son SVG d'anneau et son masque de points sont des assets distants que le banc bloque. La parité de ce fond se vérifie donc sur ses paramètres (anneau de 62,5em flouté de 1,5em, halo 1440 × 868 flouté de 2em et remonté de 60 %, recouvrement à 6 %, rotation 10 s), pas au pixel.

5. Le mur devient un mur d'avis réels

Demande : réutiliser la source et la logique du mur de la home. Constat : la home (home-sections/testimonials-section.tsx sur TestimonialWall) ne rend aucun avis aujourd'hui. Ses huit cartes sont des exemples de première partie, signés « BoostEcom Demo » et badgés « Demo », tirés du catalogue home.testimonials, et le docblock de TestimonialWall annonce une « seconde branche » pour les vrais avis. Les reprendre sur une page agent aurait présenté des exemples comme des avis.

Ce qui est livré :

• src/lib/content/reviews.ts : la source des avis publics (PUBLIC_REVIEWS, vide à ce jour). Une ligne n'y entre qu'avec le consentement de son auteur (consentAt), dans la langue où il l'a écrite (jamais traduite en une citation qu'il n'a pas écrite). C'est cette liste que la seconde branche de TestimonialWall devra lire, pour que les deux murs ne se contredisent jamais (à faire côté app-shell, qui possède la home).
• reviewsForAgentWall(slug, prénom) : les avis qui nomment l'agent d'abord (tag agents ou @Prénom dans le texte), puis tous les autres, neuf au plus. Sous REVIEW_WALL_MIN (six : la fenêtre repliée montre deux rangées de trois ; la home n'a pas de seuil, elle rend des exemples), la fonction rend null.
• Le mur de la page agent garde son motif (maçonnerie, fondu, pastille « voir plus », accent) et affiche alors étoiles, citation, initiale, nom et rôle ; null : il garde les neuf cartes signées par l'agent. Jamais un mur vide, jamais un exemple présenté comme un avis.
• Tests : src/lib/content/reviews.test.ts (seuil, priorité, plafond, consentement) et agent-page-content.test.ts (repli sans avis, ordre et libellés avec six avis).

6. Bandeau d'intégrations : non ajouté

Le registre (identity-registry.ts → connectors) nomme Shopify, Klaviyo, Meta Ads et Google, et les connexions OAuth existent dans les réglages de la boutique. Mais aucun outil d'agent ne lit Klaviyo, Meta ou Google aujourd'hui (specialists.ts) : un bandeau de logos promettrait une intégration que l'agent n'utilise pas. La FAQ Intégrations le dit en toutes lettres (« Pas encore directement… en développement »). Le bandeau vaudra la peine le jour où un outil d'agent lira ces sources ; il devra alors dériver ses logos du registre des connecteurs, pas d'une liste.

7. Copy : ce qui a changé et pourquoi

Source : le français, voix de marque. Anglais américain, allemand (vouvoiement, comme le catalogue), espagnol et italien (tutoiement), portugais du Brésil (« você », montants en R$ recalculés pour que la marge de l'exemple de @Marco reste juste). Inspiration de structure : des pages agent de référence (scénario → réponse chiffrée → étape à valider, items QUOI + OUTIL + BÉNÉFICE, FAQ en trois onglets) ; aucun texte, avis ou chiffre repris.

Règles tenues :

• Vrai d'abord. Chaque promesse a été vérifiée contre le toolset du runtime : @Atlas délègue (delegateTo_*), lit la fiche (searchStoreIntelligence), la base de connaissances (knowledgeSearch) et l'Activité (listStoreActivity, createTask, addNote) ; son cycle quotidien (proactive-cycle.ts) est test ; @Marco écrit via shopifyAdminGraphQL mais ne modifie pas le thème (edit.theme refusé) ; @Otis rédige webhooks et Flow en brouillon mais ne connecte pas lui-même Klaviyo ou Stripe (dev) ; @Faye lit le graphe et prédit, sans lire vos commandes (dev) ; @Sam rédige depuis la base de connaissances, sans lire les commandes Shopify (dev) ni se brancher sur un helpdesk (dit tel quel).
• Scénarios : chiffres illustratifs, exemple de boutique (bougies, sweats, coffret), dernière phrase = une étape à valider. La légende partagée le dit : « boutiques et chiffres fictifs ». Aucun avis inventé, aucun compteur d'utilisateurs.
• FAQ : les quatre questions demandées, avec des réponses vérifiables (Activité de la boutique et journal d'audit, niveau d'autonomie lu du registre via {level} / {levelName}, règles de la boutique, connexions OAuth).
• Forme : aucun tiret cadratin ou demi-cadratin, aucune tournure interdite, aucun CTA « Découvrir / En savoir plus » (gardes copy:dashes, copy:case, copy:cta vertes), personas toujours préfixés @, @Atlas au masculin.
• Chiffres : la garde marketing-proof-is-placed.test.ts exige qu'un chiffre de marketingPages.* soit un placeholder dérivé du code, ou qu'il vive sous un plafond motivé. Les 22 chaînes chiffrées des scénarios sont des données d'exemple sur des boutiques fictives, pas des affirmations sur le produit : elles ne peuvent pas dériver du code. Elles sont donc sous un plafond agents: 22 avec cette raison. Alternative écartée pour l'instant : sortir chaque chiffre dans une fixture ICU comme agent-scenarios.ts, ce qui multiplierait les valeurs par six langues et deux devises sans rien rendre plus vrai. Point à trancher par le propriétaire s'il préfère la fixture.
• Parité pixel : réponses de scénario ramenées à la longueur de la référence (≈ 170 caractères en français), promesses du hero ≤ 32 caractères, titres portant une pastille courts (≤ 22 caractères).

Carte des statuts (feature-status-map.ts, graine du PlatformConfig) : réécrite pour la nouvelle copy. À faire côté admin après déploiement : une ligne featureStatus déjà enregistrée dans /admin/content/agent-status s'applique par chemin, donc un statut saisi sur l'ancienne copy (par exemple hero.features.b d'Atlas) s'accrocherait à la nouvelle phrase au même chemin. Réinitialiser la section, ou la relire, au premier passage.

8. Vérifications

Fichiers de mesure (hors dépôt, scratchpad/) : cmp-base.log (avant), cmp-final3-{1920,1440}.log et cmp-final5-{1024,768,390}.log (après), sbs-* et diff-* par section, motion.log et shots/motion-report.json, final*.log et shots/final-report.json, captures shots/final-<agent>-<langue>-<largeur>.png.