/* Feuille de style principale du thème Uptoo Digital. Ordre imposé : les tokens d'abord (tout le reste les consomme), puis reset, objets, éléments, composants, utilitaires. */ /* Tokens — design system 3 couches. tokens-primitives.css est le SEUL fichier qui lit les theme settings (CONVENTIONS §6) ; tout le reste est en var() pur. */ /* ============================================================================= tokens-primitives.css — COUCHE 1 (primitives) ----------------------------------------------------------------------------- SEUL fichier du thème qui consomme les champs de thème (règle CONVENTIONS §6 : « consommation des theme settings dans UN seul fichier ; tout le reste en var() pur »). Le HubL des fichiers CSS est évalué UNE FOIS à la publication du thème. Source des valeurs : charte Figma « Uptoo Digital » (fcV1mdU8PPHxyKkt8FnxZK), ⚠️ Cette ligne citait `bhHkBW4TJMDCCKSQwlCEYx` jusqu'au 2026-08-09 — clé que CONVENTIONS §8ter interdit nommément depuis l'arbitrage du 05/08. La piste écrite dans le code menait donc au mauvais fichier. Corrigé. page « Styleguide - Composants », frame charte-uptoo-digital — extraites des remplissages réels de l'export SVG et recoupées avec le panneau Properties de Figma. Voir docs/TOKENS-FIGMA-EXTRACTION.md (méthode, preuves, écarts relevés). ⚠️ Ne jamais écrire un hex dans un module : uniquement var(--token) sémantique. ============================================================================= */ :root { /* Purple */ --c-purple-50: #EFF0FE; --c-purple-100: #E2E3FD; --c-purple-200: #CBCCFA; --c-purple-300: #ACABF6; --c-purple-400: #9289F0; --c-purple-500: #7A65E6; --c-purple-600: #7251DA; --c-purple-700: #6342C0; --c-purple-800: #50389B; --c-purple-900: #44347B; --c-purple-950: #281E48; /* Blue */ --c-blue-50: #F1F6FD; --c-blue-100: #E0EAF9; --c-blue-200: #C9DAF4; --c-blue-300: #A3C3ED; --c-blue-400: #6C9BE0; --c-blue-500: #5883D9; --c-blue-600: #4368CD; --c-blue-700: #3A56BB; --c-blue-800: #344799; --c-blue-900: #2F3F79; --c-blue-950: #20284B; /* Green */ --c-green-50: #F4FBF2; --c-green-100: #E4F8E0; --c-green-200: #C9F0C2; --c-green-300: #9DE293; --c-green-400: #83D477; --c-green-500: #45B136; --c-green-600: #359128; --c-green-700: #2C7322; --c-green-800: #275B20; --c-green-900: #214B1C; --c-green-950: #0C290A; /* Beige */ --c-beige-50: #FCF8F0; --c-beige-100: #F8F0DC; --c-beige-200: #F0DEB8; --c-beige-300: #EACE9A; --c-beige-400: #DCA75B; --c-beige-500: #D48F3B; --c-beige-600: #C67830; --c-beige-700: #A45E2A; --c-beige-800: #844C28; --c-beige-900: #6B3F23; --c-beige-950: #391F11; /* Neutral */ --c-neutral-50: #F8F9FB; --c-neutral-100: #F0F2F5; --c-neutral-200: #E2E6EC; --c-neutral-300: #CDD3DD; --c-neutral-400: #ADB7C6; --c-neutral-500: #8E9BAF; --c-neutral-600: #65758B; --c-neutral-700: #4F5C6E; --c-neutral-800: #3A4455; --c-neutral-900: #272F3D; --c-neutral-950: #161B26; /* --- Rouge — PROVISOIRE, en attente de la charte --------------------------- La charte ne comporte aucune gamme rouge, alors que les formulaires en ont besoin (trois hex en dur dans _forms.css avant le 2026-08-05, mesurés à 2,72 / 3,05 / 3,41 contre un seuil de 4,5). Valeur relevée sur uptoo.fr, qui emploie #EF4444 comme couleur « destructive » sur les champs invalides. Deux nuances, parce qu'une seule ne peut pas tenir les deux seuils : #EF4444 donne 3,57 sur --bg et 3,36 sur --surface, ce qui passe les 3:1 exigés pour la limite d'un composant (WCAG 1.4.11) mais PAS les 4,5 d'un texte. Le 700 est le même rouge assombri à 80 % : 5,25 et 4,93, même teinte, seuil tenu. À confirmer par l'équipe design (ligne D-09) — c'est la seule couleur du thème qui ne vienne pas de la charte. */ --c-red-200: #F69898; --c-red-500: #EF4444; --c-red-700: #BF3636; /* Base */ --c-base-white: #FFFFFF; --c-base-black: #000000; } /* ============================================================================= Primitives non-couleur — typographie, espacements, rayons, mouvement. ============================================================================= */ :root { /* --- Familles (charte : DM Sans + DM Mono, 2 Google Fonts) ---------------- */ --font-sans: DM Sans, "Helvetica Neue", Arial, sans-serif; --font-mono: DM Mono, ui-monospace, "SF Mono", Menlo, monospace; --fw-regular: 400; --fw-medium: 500; /* --- Échelle typographique DESKTOP (charte « Échelle Typographique Desktop ») Chaque style est un couple taille + letter-spacing : le tracking négatif fait partie de l'identité, il ne se dissocie pas de la taille. ⚠ CORRECTION DU 2026-08-06 — les interlettrages étaient en PIXELS. La charte Figma les donne en POURCENTAGE de la taille de police ; le socle avait repris les nombres tels quels en px, sur les 13 styles. L'écart allait jusqu'à ×8 : l'eyebrow était espacé de 6px pour une police de 12px, là où la maquette mesure 0,72px. Trois valeurs vérifiées dans les relevés Figma (docs/contenu-maquettes/) : · eyebrow 12px → 0,72px = 6 % (relevé à ~10 endroits, constant) · display-xl 56px → -1,12px = -2 % · body-s 14px → -0,14px = -1 % Les 10 autres suivent la même règle de conversion (le nombre en px de la charte EST le pourcentage) — cohérent avec les 3 mesures, mais non vérifié nœud par nœud : à confirmer si un doute apparaît au rendu. Unité retenue : `em`, pas des px résolus. L'em suit la taille de police, donc l'échelle mobile ci-dessous n'a plus à redéclarer d'interlettrage — et un changement de taille ne désaccorde plus le tracking. ------------- */ --fs-display-xl: 56px; --ls-display-xl: -0.02em; --fs-display-l: 48px; --ls-display-l: -0.02em; --fs-display-m: 40px; --ls-display-m: -0.02em; --fs-heading-l: 32px; --ls-heading-l: -0.02em; --fs-heading-m: 24px; --ls-heading-m: -0.01em; --fs-heading-s: 20px; --ls-heading-s: -0.01em; --fs-body-l: 18px; --ls-body-l: -0.015em; --fs-body-m: 16px; --ls-body-m: -0.015em; --fs-body-s: 14px; --ls-body-s: -0.01em; --fs-label-m: 15px; --ls-label-m: -0.0125em; --fs-label-s: 13px; --ls-label-s: -0.01em; --fs-eyebrow: 12px; --ls-eyebrow: 0.06em; /* DM Mono, uppercase, tracking POSITIF */ --fs-caption: 12px; --ls-caption: -0.01em; /* --- Interlignages : UN TOKEN PAR STYLE, comme --fs-* et --ls-* ----------- Corrigé le 2026-08-08. Le socle posait quatre tokens (`--lh-display`, `--lh-heading`, `--lh-body`, `--lh-label`) pour douze styles, en les annonçant « non spécifiés par la charte Figma — valeurs de travail ». Les deux moitiés de cette phrase étaient fausses : la charte les spécifie (relevés `docs/contenu-maquettes/solutions-audit-crm.md`, section « Tokens Figma relevés », constants sur les 4 frames desktop), et les valeurs de travail étaient servies en préprod depuis le 06/08. Un token ne peut pas servir deux styles qui n'ont pas la même valeur : `--lh-body` couvrait Body/L (1,6), Body/M (1,5) et Body/S (1,5), donc deux des trois étaient faux quoi qu'on choisisse. Sept des huit styles mesurés étaient hors référence. Détail chiffré : DECISIONS-DESIGN §5.2, fiche N-01. Le grain est désormais celui de --fs-* : un style, un token. */ --lh-display-xl: 1.1; --lh-display-l: 1.1; --lh-display-m: 1.12; --lh-heading-l: 1.15; --lh-heading-m: 1.25; --lh-heading-s: 1.3; --lh-body-l: 1.6; --lh-body-m: 1.5; --lh-body-s: 1.5; --lh-label-m: 1.35; --lh-label-s: 1.4; --lh-eyebrow: 1.4; /* ⚠ Caption n'a PAS de style Figma nommé : la charte ne relève pas de `Desktop/Caption`. 1,3 est donc la seule valeur de cette table qui reste une valeur de travail — reprise telle quelle de l'ancien `--lh-label`, et signalée comme non vérifiée plutôt que présentée comme relevée. */ --lh-caption: 1.3; /* --- Espacements (base 8) ------------------------------------------------ */ --sp-1: 4px; --sp-2: 8px; --sp-3: 12px; --sp-4: 16px; --sp-5: 24px; --sp-6: 32px; --sp-7: 48px; --sp-8: 64px; --sp-9: 80px; --sp-10: 120px; /* --- Rythme vertical de section — TROIS PALIERS (arbitrage Antoine, 2026-08-08) -------------------------------------------------------------- Le socle posait `--sp-9` (80px) sur toutes les sections. Aucune section de la maquette n'est à 80. Le relevé du 07/08 (DECISIONS-DESIGN §4.4) donne trois familles — 89/96, 104/104, 120/120 — et une amplitude de 89 à 128px. Le seuil ERROR de V6 étant à 12px, AUCUNE valeur unique ne peut être juste : c'est ce qui a écarté l'option « une valeur, et on fait corriger la maquette ». Ces valeurs sont des relevés, pas des multiples de la base 8 : 89/96 n'est pas arrondi à 88/96, et c'est délibéré — l'écart de 1px resterait sous le seuil OK, mais rien n'oblige à s'éloigner de la maquette pour faire joli. La syntaxe à deux valeurs (`89px 96px`) est un raccourci `padding-block` haut/bas : la maquette est asymétrique sur ce palier, pas le socle. */ --section-y-xs: 64px; /* Preuves (listing HubSpot) — relevé le 2026-08-09 */ --section-y-sm: 89px 96px; /* Expertises, Méthode — et toute la famille 86→96, ci-dessous */ --section-y-md: 104px; /* Intégrations, Cas clients */ --section-y-lg: 120px; /* Hero, Problème, Offres, Nos différences, FAQ */ /* `--section-y-sm` EST LE PALIER DE LA FAMILLE 86→96, pas seulement des deux sections qui lui donnent son nom. Arbitrage M-14 du 2026-08-11 : les quatre sections de `offre-audit-crm` qui manquaient d'un palier se câblent ICI, aucun 5e palier n'est ajouté. Le relevé ne donne pas une valeur mais une famille, dont les trois hauts mesurés tiennent dans 10 px — et dont le BAS ne varie pas : · 96 haut / 96 bas — `solutions-audit-crm.md:70` (Pour qui), `:91` (Le bon moment), `:173` (Votre livrable) ; · 89 haut / 96 bas — DECISIONS-DESIGN §4.4 (Expertises, Méthode) ; · 86 haut / 96 bas — `solutions-audit-crm.md:27` (hero de cette page), `a-propos.md:101`, et `mesures-manquantes-2026-08-10.md:174-177` qui le retrouve par soustraction (632 − 86 − 450 = 96). 89 est donc à 7 px de la borne haute et à 3 px de la borne basse, bas exact dans les trois cas : sous le seuil ERROR de 12 px de la gate. ⚠️ Les deux sections relevées « 86 haut » de `offre-audit-crm` (`solutions-audit-crm.md:196` et `:232`) N'ONT PAS de padding bas mesuré — le relevé s'arrête au haut. Les 96 du palier leur sont servis par la famille ci-dessus, pas par une mesure de ces deux sections-là. Écart déclaré. Pourquoi PAS un 5e palier à 96/96, qui aurait pourtant été exact sur deux des quatre sections : ① il n'existerait qu'en desktop — sous 768 px toute la page est à 56/56 (`mobile-solutions-audit-crm.md:41`, « gabarit constant de la page »), donc il se replierait exactement sur `sm` dans le bloc mobile ; ② il COUPERAIT la famille en deux SUR UNE MÊME PAGE : « Pour qui cet audit est-il fait ? » est relevée 96/96 elle aussi et rendue par `texte-highlight`, qui câble `section--rhythm-sm` en dur (`texte-highlight.module/module.html:53`). La section 2 resterait à 89 pendant que la section 3, au relevé identique, passerait à 96. Deux relevés égaux servis différemment est un défaut pire que 7 px uniformes ; ③ six sites du dépôt mappent DÉJÀ 96/96 ou 86/96 sur `sm` en déclarant le résidu (`hero-page.module/module.css:173`, `texte-highlight.module/module.html:53`, `cards-hubs-stack.module/module.html:39`, `page-offre.html:203` et `:620`, `page-libre.html:426`). Un 5e palier les rendrait tous faux d'un coup, sans qu'aucun ait bougé. */ /* --- Hauteurs de bloc FIGÉES PAR LA MAQUETTE (ajout du 2026-08-10) --------- Trois cotes que la maquette impose et que l'échelle `--sp-*` ne peut pas porter : elle décrit des ESPACEMENTS, s'arrête à 120, et aucune combinaison n'y vaut 208, 256 ni 444. Elles sont ici pour exactement la même raison que `--section-y-*` juste au-dessus — ce sont des relevés, pas des multiples de la base 8 — et parce qu'un module n'a pas le droit d'écrire une longueur en dur (CONTRAT-SOCLE §1 et §8). ⚠️ ELLES NE VALENT QU'EN DESKTOP, et c'est une donnée de maquette, pas une précaution : le mobile relève d'autres valeurs pour les mêmes blocs — panneau de badges 350 × **301** (`mobile-a-propos.md:176`) et cards de « Notre appartenance » en **hauteur libre** (`mobile-a-propos.md:204`). Les deux modules qui les consomment le font donc sous `@media (min-width: 64em)` et jamais en règle inconditionnelle. Aucune valeur mobile n'est servie à ce jour ; ces deux-là restent des écarts ouverts. */ --panel-h-badges: 444px; /* Panneau d'accréditations — a-propos.md:111, nœud 2201:10424 */ /* Hauteurs de card, NOMMÉES PAR LEUR COTE (renommage du 2026-08-10, M-12). Elles s'appelaient `--card-h-sm` / `--card-h-md`, ce qui tenait tant qu'il n'y en avait que deux. Le relevé en donne CINQ, et elles ne s'ordonnent pas en tailles de tee-shirt : 240 s'intercale entre 208 et 256. Un nom de cote ne ment pas et n'a pas à être renuméroté au relevé suivant. */ --card-h-208: 208px; /* « Notre appartenance » — a-propos.md:137, nœuds 2198:14250 / 14256 */ --card-h-240: 240px; /* « Ce que nous faisons » — a-propos.md:86 */ --card-h-256: 256px; /* « Notre façon de travailler » — a-propos.md:155, nœuds 2198:9750 / 9756 / 9762 */ --card-h-320: 320px; /* « Une offre par secteur » — solutions-listing.md:105 · « Votre livrable » — solutions-audit-crm.md */ --card-h-380: 380px; /* « Nos différences » — accueil, 4 colonnes */ /* En-tête latéral de `cards-grid` (M-15). Relevés : 462 px sur hub-solutions (`solutions-listing.md:99`, recoupé au nœud `1297:22848` — 462 × 198) et 440 px sur page-libre (`a-propos.md:79`). Une seule valeur pour les deux, à 22 px près : la gouttière de 120 et la largeur de grille qui suit sont, elles, exactes des deux côtés (1200 − 462 − 120 = 618 = 2 cards de 301 + 16 ; 1200 − 440 − 120 = 640 = 2 cards de 312 + 16). L'écart de 22 px sur page-libre est déclaré, pas masqué. */ --cards-head-aside-w: 462px; /* --- Panneau encarté du CTA final (ajout du 2026-08-10, punch list M-01/M-02) Le CTA final n'est PAS un bandeau sombre pleine largeur : la maquette pose une carte encartée dans une section claire, sur les 4 gabarits et aux 2 viewports. Relevés concordants : `faq-accordeon---cta-final.md:108` (« pleine largeur 1200 px, radius 12px, dégradé 147.12deg #281e48 13,871 % → #50389b 96,042 %, padding 56px 56px 56px 80px, overflow hidden »), `solutions-listing.md:43` et `:168`, `solutions-audit-crm.md:291`, `a-propos.md:167`. Aucune de ces quatre cotes n'existe dans `--sp-*` : 56, 80 en asymétrie, 40 et l'angle. Elles sont ici pour la même raison que les trois hauteurs ci-dessus — ce sont des relevés, et un module n'a pas le droit d'écrire une longueur en dur (CONTRAT-SOCLE §1 et §8). Les mettre au socle plutôt qu'une media query dans le module préserve la promesse du fichier : `cta-final/module.css` reste sans aucun point de rupture, la bascule est portée par les tokens. ⚠️ Les deux relevés mobiles DIVERGENT sur le padding du panneau : `mobile-solutions-listing.md:57` donne 32/24, `mobile-a-propos.md:240` donne 56 vertical / 20 latéral. La valeur retenue est celle du premier (la page qui porte deux instances) ; l'écart d'À propos reste ouvert, non masqué. */ --panel-cta-pad-block: 56px; /* haut et bas */ --panel-cta-pad-inline: 56px; /* droite */ --panel-cta-pad-start: 80px; /* gauche — l'asymétrie est au relevé */ --panel-cta-angle: 147deg; /* relevé 147,12° — l'arrondi est un écart assumé */ --card-quiz-pad: 40px; /* carte quiz blanche, `faq-accordeon---cta-final.md:110` */ /* --- Grille & containers (relevés charte : frame 1440, padding latéral 120, donc largeur de contenu 1200) ------------------------------------------- */ --container-max: 1200px; /* ⚠ CORRECTION DU 2026-08-06 — la gouttière était figée à 120px de 768px à l'infini, et ne retombait à 20px qu'en dessous de 768px. Deux conséquences mesurées en préprod : à 1024px le contenu tombait à 784px utiles (les 120px de la charte valent 8,3 % d'un cadre de 1440, pas 11,7 % d'un cadre de 1024), et le passage de 768 à 767px élargissait le contenu de 199px d'un seul coup — une rupture visible au redimensionnement. La gouttière n'est pas une simple proportion : la charte pose 120px sur un cadre de 1440 (8,3 %) et 20px sur un cadre de 390 (5,1 %). Une seule valeur en vw ne peut pas satisfaire les deux. D'où une interpolation LINÉAIRE entre les deux points relevés, bornée aux extrémités : elle passe exactement par 120px à 1440 et par 20px à 390, sans aucun palier — donc sans le saut de 199px qu'on observait en franchissant 768px. Le pas : (120-20)/(1440-390) = 0,0952 px par px de viewport. */ --container-pad: min(120px, max(16px, calc(20px + (100vw - 390px) * 0.0952))); /* Gouttière de `.grid--2|3|4`, c'est-à-dire celle des cards. Mesurée à 16px sur deux frames Figma indépendantes le 2026-08-05 ; les 32px d'origine n'avaient jamais été relevés sur la maquette. Les autres gouttières du site ne passent PAS par ce token : la maquette en emploie quatre (16 cards · 24 rangées · 120 colonnes de hero · 0 section problème), aucune variable unique ne peut les porter, et chacune existe déjà dans l'échelle --sp-*. */ --grid-gap: var(--sp-4); /* --- Rayons (charte : boutons et icon-buttons mesurés à 6px) ------------- */ --radius-sm: 6px; --radius-md: 8px; --radius-lg: 12px; --radius-xl: 16px; --radius-pill: 999px; /* --- Mouvement — SPEC-ANIMATIONS-V1 §1 (tokens imposés, zéro valeur en dur dans les modules) -------------------------------------------------------- */ --ease-brand: cubic-bezier(0.2, 0.8, 0.2, 1); --ease-out: ease-out; --dur-fast: 150ms; /* hovers boutons / options / tabs */ --dur-med: 300ms; /* toggles, swaps de couleur, progress bars */ --dur-slow: 500ms; /* barres de graphe, transitions de visuel */ --dur-enter: 600ms; /* entrée hero (upfade) */ --dur-menu: 200ms; /* ouverture mega-menu (fourchette charte 180-220) */ --stagger-hero: 150ms; /* cascade des colonnes / cards du hero */ --stagger-reveal: 70ms; /* cascade des scroll reveals (fourchette 60-80) */ --dur-pulse: 2.4s; /* dot « live » des eyebrows/badges */ --dur-countup: 1200ms; /* compteurs stats */ /* Décalage vertical de l'upfade — la SEULE distance de mouvement de la charte. Elle sert à l'entrée des heros ET à la révélation au scroll : c'est pour qu'elle ne soit pas réécrite dans chaque module qu'elle est un token. */ --shift-upfade: 14px; /* Durée d'un tour de piste de marquee. Ajoutée le 2026-08-05 : sans elle, les modules fabriquaient une vitesse de défilement en multipliant --dur-slow (un timing de hover) par 72 ou 80 — un détournement qui rendait les deux bandes solidaires d'un token qui n'a rien à voir. */ --dur-marquee: 40s; } /* --- Échelle typographique MOBILE — styles Figma SÉPARÉS, pas un simple ratio : seuls Display XL/L/M, Heading L/M et Caption changent. ------------ */ @media (max-width: 767px) { :root { /* Seules les TAILLES changent. Les interlettrages ne sont plus redéclarés : depuis leur passage en `em` (2026-08-06), ils suivent la taille de police automatiquement — les redéclarer en px réintroduirait précisément le défaut qu'on vient de corriger. `--container-pad` n'est plus redéclaré non plus : l'interpolation posée en :root passe déjà par 20px à 390px, et le palier qui existait ici provoquait un saut de 199px au franchissement de 768px. */ --fs-display-xl: 30px; --fs-display-l: 28px; --fs-display-m: 26px; --fs-heading-l: 24px; --fs-heading-m: 22px; --fs-caption: 11px; /* Rythme vertical mobile : UN SEUL palier, 56/56 — c'est la valeur relevée sur les deux sections mobiles mesurées le 07/08 (`1979:9740` Section/Run et `1979:9784` Section/Offres), et la maquette mobile n'en montre pas d'autre. Les trois paliers desktop s'y replient donc tous les trois : le rythme à trois niveaux est une composition d'écran large. Le socle servait 48/48 (`--sp-7`), soit 8px de moins sur chaque bord — point 20 du reste-à-faire, même arbitrage que le point 7. */ --section-y-xs: 56px; --section-y-sm: 56px; --section-y-md: 56px; --section-y-lg: 56px; /* Panneau du CTA final en mobile — `mobile-solutions-listing.md:57` : « carte 350 × 882,5, padding 32px 24px, radius 12, dégradé 104,53° ». L'angle passe de 147° à ~105° : la carte est presque carrée en desktop et très haute en mobile, un même angle n'y donne pas la même diagonale. Le padding gauche perd son asymétrie : 24 des deux côtés. */ --panel-cta-pad-block: 32px; --panel-cta-pad-inline: 24px; --panel-cta-pad-start: 24px; --panel-cta-angle: 105deg; /* relevé 104,53° (listing) / 106,15° (À propos) */ --card-quiz-pad: 24px; /* `mobile-solutions-listing.md:75` */ } } /* --- Accessibilité : le mouvement est une amélioration, jamais une condition d'affichage (SPEC-ANIMATIONS-V1 §4). Neutralise les durées à la source. --- */ @media (prefers-reduced-motion: reduce) { :root { --dur-fast: 1ms; --dur-med: 1ms; --dur-slow: 1ms; --dur-enter: 1ms; --dur-menu: 1ms; --stagger-hero: 0ms; --stagger-reveal: 0ms; --dur-countup: 1ms; } } /* ============================================================================= tokens-semantic.css — COUCHE 2 (rôles) + COUCHE 3 (contexte sombre) ----------------------------------------------------------------------------- Aucune valeur littérale, aucun champ de thème : uniquement des références à la couche 1. Le mapping rôle → primitive est le contrat de design DÉCLARÉ PAR LA CHARTE elle-même (section « Couleurs sémantiques & Tokens », qui nomme la primitive cible sous chaque rôle : « bg/page → Neutral 50 », etc.). Les modules ne consomment QUE ces tokens (gate MODULE : zéro hex en dur). ============================================================================= */ /* Les rôles clairs sont déclarés pour la racine ET pour `.section--light` : UNE seule liste, deux sélecteurs, donc aucune valeur recopiée et aucune dérive possible entre les deux. `.section--light` est l'inverse manquant de `.section--dark` (ajouté le 2026-08-05) : il repose les rôles clairs sur son sous-arbre, à n'importe quelle profondeur d'une section sombre. C'est ce qui permet une carte blanche dans une section sombre — la maquette en pose au moins trois (carte du CTA final, 4 cards de Section/Couvre, pile hubs). `.section--white` (M-08, 2026-08-11) rejoint la même liste, et pour la même raison : posée dans un contexte sombre elle doit d'abord reposer les rôles clairs, avant de repointer `--bg` sur le blanc juste sous le bloc `.section--light` ci-dessous. Elle n'ajoute AUCUN rôle à cette liste. */ :root, .section--light, .section--white { /* Fonds — charte « Background (Arrière-plans) » */ --bg-white: var(--c-base-white); --bg: var(--c-neutral-50); --surface: var(--c-neutral-100); --bg-purple-light: var(--c-purple-50); /* `bg/purple-dark` vaut #50389B dans la charte, c'est-à-dire purple-800 — pas purple-900 (#44347B), servi ici jusqu'au 2026-08-08. ⚠️ Corriger cette ligne ne change RIEN au rendu : `--bg-purple-dark` n'a aucun consommateur dans le thème. C'est `.section--dark { --surface }`, en bas de ce fichier, qui peint réellement le panneau CTA — et c'est là que l'écart se voyait. Les deux sont corrigés ; celui-ci l'est pour que le token ne mente pas le jour où quelqu'un s'en servira. */ --bg-purple-dark: var(--c-purple-800); --bg-purple-darker: var(--c-purple-950); --bg-green-light: var(--c-green-50); --bg-blue-light: var(--c-blue-50); --bg-beige-light: var(--c-beige-50); /* Texte — charte « Text on Light (Texte sur fond clair) » */ --text-title: var(--c-purple-950); --text: var(--c-neutral-900); --text-secondary: var(--c-neutral-700); --text-disabled: var(--c-neutral-500); --text-placeholder: var(--c-neutral-500); /* Rôles ajoutés le 2026-10-05 (blog, phase 4 — ECARTS-BLOG §3 et §5 B). Chacun traduit un token que la maquette nomme, et qu'aucun rôle ne portait : · `text/on-light/secondary` #65758b = neutral-600. N'est AA que sur fond BLANC (4,70:1) ; sur --bg #f8f9fb il tombe à 4,46 → ne le poser que sur --bg-white. --text-secondary (neutral-700) reste le défaut partout ailleurs (arbitrage 3.3 : deux rôles, pas de remappage global) ; · `purple/800` posé sur du TEXTE (lien « Retours aux articles ») : le seul rôle qui pointait purple-800 était un fond. */ --text-secondary-on-white: var(--c-neutral-600); --accent-text-strong: var(--c-purple-800); /* Bordures — charte « Borders (Bordures & Séparateurs) » */ --border: var(--c-neutral-200); --border-strong: var(--c-neutral-500); /* `border-1` #f1f2f5 (carte Sommaire, relevé blog-article.md §3b) : aucune primitive ne vaut #f1f2f5, neutral-100 #f0f2f5 est à 1 unité sur le canal rouge. Ajouté le 2026-10-05. */ --border-subtle: var(--c-neutral-100); /* Halo de décor (hero d'article, ellipses « Jaune » `beige/200` du relevé blog-article.md §2) — rôle de décor, jamais de texte. Ajouté le 2026-10-05. */ --decor-halo-beige: var(--c-beige-200); /* Accents — charte « Accents », variantes claires (posées SUR fond clair) */ --accent-purple: var(--c-purple-600); --accent-blue: var(--c-blue-500); /* green_600 / beige_600, et non 500 : ce sont les valeurs que la maquette pose (`accent/on-light/green` #359128, `accent/on-light/beige` #c67830), et ce sont les seules qui passent AA-large sur le fond réel des sections. Mesuré le 2026-08-09 sur `--bg-purple-light` #EFF0FE : green_500 sort à 2,44:1 (échec), green_600 à 3,55:1 (passe). Le violet était déjà juste (purple_600). */ --accent-green: var(--c-green-600); --accent-beige: var(--c-beige-600); /* Accent courant d'une rubrique — réassigné par .section--accent-* */ --accent: var(--accent-purple); /* --- Accent LISIBLE et accent DOUX (D6, mesuré le 2026-08-05) ------------- Les accents ci-dessus sont des couleurs de MARQUE : elles sont calibrées pour un aplat, pas pour du texte. Mesuré sur --bg (#F8F9FB) : violet 5,11 ✓ mais bleu 3,52 ✗, vert 2,62 ✗, beige 2,56 ✗ contre le seuil AA de 4,5. D'où deux rôles de plus, et une règle simple : · un TEXTE ou une icône porteuse de sens → --accent-text · un aplat, un trait, un pictogramme décoratif → --accent Nuances retenues, chacune vérifiée sur les TROIS fonds qu'elle rencontre (--bg / --surface / --accent-soft) : violet 600 5,11 · 4,80 · 4,75 bleu 600 4,86 · 4,57 · 4,72 vert 700 5,56 · 5,23 · 5,56 beige 800 6,55 · 6,15 · 6,51 Le beige est en 800 et non en 700 comme proposé initialement : 700 tient sur --bg (4,73) mais tombe à 4,44 sur --surface, donc sous le seuil dès qu'on le pose sur une card. */ --accent-text-purple: var(--c-purple-600); --accent-text-blue: var(--c-blue-600); --accent-text-green: var(--c-green-700); --accent-text-beige: var(--c-beige-800); --accent-text: var(--accent-text-purple); /* Fond doux de la rubrique — pastilles, puces, aplats légers. Ce sont les rôles de fond clair qui existent déjà : aucune nouvelle couleur, juste leur version « suit la rubrique courante ». Remplace le color-mix() à 14 % que hero-home fabriquait, et qui plafonnait le contraste à 4,21 même avec un texte corrigé — un fond teinté à l'accent mange le contraste de l'accent. */ --accent-soft-purple: var(--bg-purple-light); --accent-soft-blue: var(--bg-blue-light); --accent-soft-green: var(--bg-green-light); --accent-soft-beige: var(--bg-beige-light); --accent-soft: var(--accent-soft-purple); /* Boutons — charte « Bibliothèque de composants UI » (dégradés relevés dans Button.svg : primaire Purple 500 → 600, secondaire White → Neutral 100) */ --btn-primary-from: var(--c-purple-500); --btn-primary-to: var(--c-purple-600); --btn-primary-border: var(--c-purple-500); --btn-primary-text: var(--c-base-white); --btn-secondary-from: var(--c-base-white); --btn-secondary-to: var(--c-neutral-100); --btn-secondary-border: var(--c-neutral-200); --btn-secondary-text: var(--c-purple-950); /* Élévation « flottante » — rôle ajouté le 2026-08-03. Existait déjà en dur dans components/_navbar.css:80 et réinventé par hero-home : un seul token désormais. La variante sombre est plus opaque, sinon l'ombre disparaît sur --bg (purple-950) et l'élévation ne se lit plus. */ --shadow-card: 0 12px 32px rgb(0 0 0 / 8%); /* Style d'effet Figma `shadow/card` (relevé blog-listing.md §4, survol de la carte d'article) — rôle ajouté le 2026-10-05. Cinq couches dans la charte ; les deux dernières sont à 0 % d'opacité et ne peignent rien, elles sont omises. Distinct de --shadow-card, élévation « flottante » du socle. */ --shadow-card-hover: 0 1px 3px rgb(0 0 0 / 2%), 0 5px 5px rgb(0 0 0 / 2%), 0 11px 7px rgb(0 0 0 / 1%); /* Limite d'un composant d'interface — rôle ajouté le 2026-08-03. WCAG 1.4.11 exige 3:1 pour le trait qui DIT où commence et finit une zone cliquable. Mesuré sur --bg clair (#F8F9FB) : --border 1,19 ✗ · --border-strong 2,67 ✗ · accent vert 2,62 ✗ · accent beige 2,56 ✗. Seul neutral-600 (4,46) tient. N'utiliser --border/--border-strong que pour des séparations décoratives. */ --border-interactive: var(--c-neutral-600); /* Erreur — rôle ajouté le 2026-08-05, PROVISOIRE (cf. tokens-primitives). Deux rôles et pas un seul, parce que les deux seuils WCAG diffèrent : · --danger bordure de champ invalide, anneau, pictogramme (≥ 3:1) · --danger-text message d'erreur, astérisque de champ requis (≥ 4,5:1) Ne jamais poser --danger sur du texte : 3,36 sur --surface. */ --danger: var(--c-red-500); --danger-text: var(--c-red-700); /* Halo — le « dégradé » du panneau CTA de la maquette. Relevé à la source le 2026-08-05 : ce n'est pas un dégradé linéaire mais une composition de 4 formes floutées, et sa couleur est #7251DA, soit exactement --c-purple-600 — la charte n'a donc AUCUNE couleur à fournir, elle en avait déjà une. */ --halo: var(--c-purple-600); --halo-light: var(--c-base-white); } /* `.section--light` doit PEINDRE, exactement comme `.section--dark` le fait. Le bloc ci-dessus ne peut pas s'en charger : il porte aussi `:root`, et y mettre un `background-color` peindrait la racine du document. Sans cette règle, la classe était asymétrique et le cas d'usage pour lequel elle a été ajoutée ne marchait pas : posée seule dans une section sombre, elle réassignait bien les rôles clairs — donc du texte foncé — mais laissait le fond sombre du parent. Texte foncé sur fond sombre. Mesuré le 2026-08-05 : `.section--dark` seule peint rgb(40,30,72), `.section--light` seule ne peignait rien (transparent). Relevé par la session « décisions design ». */ .section--light { background-color: var(--bg); color: var(--text); } /* --- Fond BLANC PUR — M-08 (2026-08-11) -------------------------------------- Il n'existait aucune classe de fond blanc. La maquette pose pourtant `bg/white` #FFFFFF sur des SECTIONS entières, pas seulement sur des cartes, et le thème servait #F8F9FB partout : `.section` peint `--bg` (objects/_layout.css:81) et `.section--light` peint `--bg` lui aussi (juste au-dessus), donc la valeur `background: "light"` des modules n'émettait rien de distinct. Sources, vérifiées à la ligne : · `contenu-maquettes/solutions-listing.md:43,136,168,186` — « section blanche », quatre fois, dont la section Méthode (:136) ; · `contenu-maquettes/a-propos.md:193` — FAQ, « Fond blanc (`bg/white`, seule section sur fond blanc pur) » ; · `contenu-maquettes/faq-accordeon---cta-final.md:99` — « Section 1440 px, fond blanc », et `:143` qui lie le token `bg/white` #ffffff ; · `contenu-maquettes/slider-temoignages.md:5,93,126` — Cas clients, « Fond `bg/white` (#ffffff) », le token servant à la fois la section et les cartes. Le rôle existait déjà (`--bg-white`, ligne 22) ; il ne manquait que la classe qui le peint. Aucune couleur littérale, aucune longueur, aucun rôle nouveau : cette règle repointe le seul `--bg`. Conséquence — le `background-color` de `.section` résout DÉJÀ le blanc, sans règle de plus, parce qu'une custom property se résout à sa déclaration gagnante et non à l'ordre des règles qui la lisent. Le `background-color` déclaré ici sert l'autre cas : un élément qui porte la classe sans porter `.section` — une carte blanche dans une section sombre, exactement l'usage de `.section--light` au-dessus. ACCESSIBILITÉ — le blanc est plus clair que `--bg` (#F8F9FB), donc aucun plancher ne baisse. Recalculé le 2026-08-11 (WCAG 2.1), #F8F9FB → #FFFFFF : --text 12,78 → 13,46 · --text-secondary 6,45 → 6,80 --text-title 14,56 → 15,33 · --border-interactive 4,46 → 4,70 accents-texte : violet 5,11 → 5,38 · bleu 4,86 → 5,12 · vert 5,56 → 5,86 · beige 6,55 → 6,90 Tous montent. Cette classe ne peut donc pas dégrader un contraste existant. ⚠️ CE QU'ELLE NE RÈGLE PAS : `--surface` reste neutral-100 (#F0F2F5), soit 1,12 sur blanc (contre 1,06 sur `--bg`). Une carte peinte en `--surface` dans une section blanche reste quasi invisible sans bordure — ce n'est pas une régression (c'était déjà vrai sur `--bg`), mais la maquette délimite ces cartes par `border/on-light/default`, pas par leur fond. Un module qui veut une carte lisible sur blanc doit porter son bord, pas compter sur son fond. ⚠️ ORDRE — déclarée ICI, avant `.section--dark`, et ce n'est pas indifférent : les deux ont la même spécificité (une classe), donc sur un élément qui porterait les deux, c'est le contexte sombre qui gagne. C'est le repli sûr. Le bloc `.section--accent-*` reste, lui, APRÈS `.section--dark` : rien n'a bougé de cet ordre-là, qui est ce qui résout D5 (avertissement plus bas). */ .section--white { --bg: var(--bg-white); background-color: var(--bg); color: var(--text); } /* ----------------------------------------------------------------------------- COUCHE 3 — contexte sombre. Posée sur un conteneur de section (jamais globalement) : les rôles sont réassignés, les modules à l'intérieur n'ont rien à savoir du contexte. Charte : « Composants sur Fond Sombre (Inversés) », fond bg/purple-darker. -------------------------------------------------------------------------- */ .section--dark { /* Fonds */ --bg: var(--c-purple-950); /* purple-800 (#50389B) = le rôle `bg/purple-dark` de la charte. Servait purple-900 (#44347B) jusqu'au 2026-08-08 — l'écart d'une nuance relevé en V8 sur le panneau CTA. C'EST CETTE LIGNE qui peignait le défaut, pas le `--bg-purple-dark` du haut de fichier que le rapport de gate désignait : ce dernier n'a aucun consommateur. La sonde du 07/08 l'avait attrapée en mobile — `inner[#44347B@350]` sur les 4 instances de cta-final et sur la grille sombre de hub-solutions (`preuves/…/sonde-mobile-390.txt`) — et pas en desktop, où la carte ne couvre pas les 60 % de largeur qui déclenchent la remontée des fonds peints par un enfant. */ --surface: var(--c-purple-800); /* Texte — charte « Text on Dark (Texte sur fond sombre) » */ --text-title: var(--c-purple-50); --text: var(--c-base-white); /* Rôles du 2026-10-05 : en contexte sombre, ils retombent sur les rôles du contexte (aucune teinte claire spécifique n'est dessinée). */ --text-secondary-on-white: var(--text-secondary); --accent-text-strong: var(--accent-text); --border-subtle: var(--border); /* M-06 (2026-08-10) — le chapô sur fond sombre virait au mauve. La charte pose `text/on-dark/secondary` = #CDD3DD, c'est-à-dire NEUTRAL-300, pas purple-200 (#CBCCFA) : deux couleurs proches à l'œil, l'une neutre et l'autre teintée. Relevé sur 9 chapôs (`solutions-listing.md:47`, `a-propos.md`, les deux mobiles). Le rôle existait déjà au socle, il n'était simplement pas pointé. Contraste recalculé avant application, méthode WCAG 2.1 : #CDD3DD sur --bg #281E48 → 10,19 · sur --surface #50389B → 5,86 soit MIEUX que le purple-200 qu'il remplace (9,90 / 5,70). Le plancher du contexte sombre monte de 5,70 à 5,86 — cette correction ne coûte rien à l'accessibilité, elle lui rapporte. */ --text-secondary: var(--c-neutral-300); --text-disabled: var(--c-purple-400); --text-placeholder: var(--c-purple-400); /* Bordures — CONSÉQUENCE OBLIGÉE du passage de --surface à purple-800. `--border` valait purple-800 lui aussi : laisser les deux sur la même nuance aurait fait disparaître purement et simplement le bord des cartes posées sur une surface sombre (contraste 1,00 — la carte du CTA final, les cards-grid sombres, la carte FAQ, les cartes du hero). Le correctif de couleur aurait alors introduit un défaut de rendu. purple-700 rétablit la séparation et l'améliore des deux côtés : bord/surface 1,18 → 1,29, bord/fond 1,74 → 2,24 (mesures du 2026-08-08). ⚠️ La charte ne nomme AUCUN rôle `border/on-dark` — les bordures sombres sont une invention du socle depuis l'origine, et cette valeur reste donc à faire valider par Quentin/Costel au même titre que la précédente. */ --border: var(--c-purple-700); --border-strong: var(--c-purple-600); /* Accents — variantes sombres (posées SUR fond sombre) ⚠️ M-05 APPLIQUÉE LE 2026-08-10 — ET ELLE OUVRE UNE DETTE D'ACCESSIBILITÉ, ASSUMÉE, À ARBITRER PAR L'ÉQUIPE DESIGN. La charte pose `accent/on-dark/purple` = #ACABF6, soit PURPLE-300, sur ~19 sur-titres de fond sombre ; le socle servait purple-200 (#CBCCFA). Contrastes calculés (WCAG 2.1) AVANT écriture, pour que la décision se prenne sur des chiffres et non sur une impression : sur --bg #281E48 sur --surface #50389B purple-200 (avant) 9,90 5,70 ✓ purple-300 (charte) 7,24 4,16 ✗ sous le seuil AA de 4,5 La nuance de la charte est donc juste au pixel et insuffisante au contraste sur `--surface`. Arbitrage d'Antoine, 2026-08-10 : la phase en cours est la VALIDATION DES MAQUETTES — la conformité au pixel est la règle, l'écart d'accessibilité se note et part à l'équipe design. Il est consigné à `docs/ARBITRAGES-EQUIPE-DESIGN-2026-08-10.md`. Le cas dimensionnant, pour la décision à venir : depuis M-01 le panneau du CTA final est un dégradé qui FINIT sur `--surface` et porte un sur-titre accentué sur 4 gabarits — c'est là que se lisent les 4,16. Trois issues possibles, aucune du ressort d'un module : revenir à la 200 ; remonter `--surface`, ce qui touche tout le contexte sombre ; ou dédoubler le rôle (300 sur `--bg`, 200 sur `--surface`), ce qui suppose un rôle `accent-on-surface` que le socle n'a pas. */ --accent-purple: var(--c-purple-300); --accent-blue: var(--c-blue-200); --accent-green: var(--c-green-200); --accent-beige: var(--c-beige-200); --accent: var(--accent-purple); /* En sombre, les accents de marque passent LARGEMENT le seuil de texte — mesuré le 2026-08-05 sur --bg (#281E48) : violet 9,90 · bleu 10,82 · vert 12,21 · beige 11,57. Les valeurs sur --surface ont été RECALCULÉES le 2026-08-08, la surface étant passée de #44347B à #50389B : violet 5,70 (était 6,70) · bleu 6,23 · vert 7,03 · beige 6,66. La surface est plus claire, donc les ratios baissent — ils restent tous au-dessus de 4,5, et le plancher de tout le contexte sombre est désormais ce 5,70. Aucune nuance de rattrapage n'est donc nécessaire : --accent-text pointe simplement l'accent lui-même. */ --accent-text-purple: var(--accent-purple); --accent-text-blue: var(--accent-blue); --accent-text-green: var(--accent-green); --accent-text-beige: var(--accent-beige); --accent-text: var(--accent-text-purple); /* Le fond doux perd sa teinte de rubrique en contexte sombre : une pastille violet clair sur fond violet foncé ne se lit plus. --surface est le seul fond de composant réassigné en sombre, et les accents ci-dessus y tiennent tous (6,70 au pire). À revoir avec l'équipe design si la rubrique doit rester lisible sur la pastille en sombre. */ --accent-soft-purple: var(--surface); --accent-soft-blue: var(--surface); --accent-soft-green: var(--surface); --accent-soft-beige: var(--surface); --accent-soft: var(--surface); /* Erreur sur fond sombre. Les nuances claires ne tiennent PAS ici, et je ne l'avais mesuré qu'en contexte clair en les posant : #BF3636 donne 2,77 sur --bg sombre et 1,88 sur --surface sombre, contre 4,5. Même #EF4444 tombe à 2,76 sur --surface — sous le seuil de 3:1 d'une simple bordure. #F69898 (red 200) tient les deux : 7,20 et 4,88. Mesuré le 2026-08-05. */ --danger: var(--c-red-200); --danger-text: var(--c-red-200); /* Le bouton secondaire reste clair sur fond sombre (charte) : seule la bordure change pour ne pas trancher avec le fond. */ --btn-secondary-border: var(--c-purple-800); /* Élévation sur fond sombre : 8 % de noir sur purple-950 est imperceptible. */ --shadow-card: 0 12px 32px rgb(0 0 0 / 40%); --shadow-card-hover: var(--shadow-card); /* Limite d'un composant d'interface sur fond sombre : neutral-500 = 5,45 sur --bg (#281E48). neutral-600 n'y ferait que 3,26 — trop juste. */ --border-interactive: var(--c-neutral-500); /* Maquettes Claude Design 2026-08-18 : TOUTES les surfaces sombres sont des dégradés purple-950 → purple-800, jamais des aplats. Angles relevés dans les bundles : −38,1° (Problème), −33,7° (Expertises), −30,7° (Méthode), −34,6° (Secteurs), −40° (À propos), −45,8° (en 4 temps) — on fige −38°, la borne de fin à 118 % reproduit la douceur du relevé (le 800 n'est jamais atteint plein cadre). Le panneau du CTA final garde son angle propre (M-01). Ceci tranche de fait le B-07 « tokens de dégradé ». */ --gradient-dark: linear-gradient(-38deg, var(--c-purple-950) 0%, var(--c-purple-800) 118%); background-color: var(--bg); background-image: var(--gradient-dark); color: var(--text); } /* ----------------------------------------------------------------------------- Accent par rubrique — réassigne les trois rôles d'accent, consommés par les eyebrows, les liens d'accent, les pastilles et les icon-buttons. Fonctionne en clair comme en sombre puisqu'il pointe le rôle, jamais la primitive. ⚠️ CES RÈGLES SONT DÉCLARÉES APRÈS `.section--dark`, ET CE N'EST PAS UN HASARD. C'est ce qui résout D5 (vérifié par la mesure le 2026-08-05, cf. §2 du contrat socle) : sur un élément qui porte les DEUX classes, `.section--accent-blue` gagne à spécificité égale par l'ordre du fichier, et comme `.section--dark` a déjà réassigné `--accent-blue` à sa variante sombre juste au-dessus, `--accent` y résout la bonne nuance. Mesuré : `.section--dark.section--accent-blue` rend #C9DAF4, la variante bleue sombre exacte. Ne jamais remonter ce bloc. -------------------------------------------------------------------------- */ .section--accent-purple { --accent: var(--accent-purple); --accent-text: var(--accent-text-purple); --accent-soft: var(--accent-soft-purple); } .section--accent-blue { --accent: var(--accent-blue); --accent-text: var(--accent-text-blue); --accent-soft: var(--accent-soft-blue); } .section--accent-green { --accent: var(--accent-green); --accent-text: var(--accent-text-green); --accent-soft: var(--accent-soft-green); } .section--accent-beige { --accent: var(--accent-beige); --accent-text: var(--accent-text-beige); --accent-soft: var(--accent-soft-beige); } /* Generic This is where reset, normalize & box-sizing styles go. */ *, *:before, *:after { box-sizing: border-box; } /*! normalize.css v8.0.1 | MIT License | github.com/necolas/normalize.css */ /* Document ========================================================================== */ /** * 1. Correct the line height in all browsers. * 2. Prevent adjustments of font size after orientation changes in iOS. */ html { line-height: 1.15; /* 1 */ -webkit-text-size-adjust: 100%; /* 2 */ } /* Sections ========================================================================== */ /** * Remove the margin in all browsers. */ body { margin: 0; } /** * Correct the font size and margin on `h1` elements within `section` and * `article` contexts in Chrome, Firefox, and Safari. */ h1 { font-size: 2em; margin: 0.67em 0; } /* Grouping content ========================================================================== */ /** * Add the correct box sizing in Firefox. */ hr { box-sizing: content-box; height: 0; } /** * 1. Correct the inheritance and scaling of font size in all browsers. * 2. Correct the odd `em` font sizing in all browsers. */ pre { font-family: monospace, monospace; /* 1 */ font-size: 1em; /* 2 */ } /* Text-level semantics ========================================================================== */ /** * 1. Remove the bottom border in Chrome 57- * 2. Add the correct text decoration in Chrome, Edge, Opera, and Safari. */ abbr[title] { border-bottom: none; /* 1 */ text-decoration: underline; /* 2 */ text-decoration: underline dotted; /* 2 */ } /** * Add the correct font weight in Chrome, Edge, and Safari. */ b, strong { font-weight: bolder; } /** * 1. Correct the inheritance and scaling of font size in all browsers. * 2. Correct the odd `em` font sizing in all browsers. */ code, kbd, samp { font-family: monospace, monospace; /* 1 */ font-size: 1em; /* 2 */ } /** * Add the correct font size in all browsers. */ small { font-size: 80%; } /** * Prevent `sub` and `sup` elements from affecting the line height in * all browsers. */ sub, sup { font-size: 75%; line-height: 0; position: relative; vertical-align: baseline; } sub { bottom: -0.25em; } sup { top: -0.5em; } /* Forms ========================================================================== */ /** * 1. Change the font styles in all browsers. * 2. Remove the margin in Firefox and Safari. */ button, input, optgroup, select, textarea { font-family: inherit; /* 1 */ font-size: 100%; /* 1 */ line-height: 1.15; /* 1 */ margin: 0; /* 2 */ } /** * Remove the inheritance of text transform in Edge and Firefox. * 1. Remove the inheritance of text transform in Firefox. */ button, select { /* 1 */ text-transform: none; } /** * Correct the inability to style clickable types in iOS and Safari. */ button, [type="button"], [type="reset"], [type="submit"] { -webkit-appearance: button; } /** * Remove the inner border and padding in Firefox. */ button::-moz-focus-inner, [type="button"]::-moz-focus-inner, [type="reset"]::-moz-focus-inner, [type="submit"]::-moz-focus-inner { border-style: none; padding: 0; } /** * Restore the focus styles unset by the previous rule. */ button:-moz-focusring, [type="button"]:-moz-focusring, [type="reset"]:-moz-focusring, [type="submit"]:-moz-focusring { outline: 1px dotted ButtonText; } /** * Correct the padding in Firefox. */ fieldset { padding: 0.35em 0.75em 0.625em; } /** * Remove the padding so developers are not caught out when they zero out `fieldset` elements in all browsers. */ legend { padding: 0; } /** * Add the correct vertical alignment in Chrome, Firefox, and Opera. */ progress { vertical-align: baseline; } /** * Correct the cursor style of increment and decrement buttons in Chrome. */ [type="number"]::-webkit-inner-spin-button, [type="number"]::-webkit-outer-spin-button { height: auto; } /** * 1. Correct the odd appearance in Chrome and Safari. * 2. Correct the outline style in Safari. */ [type="search"] { -webkit-appearance: textfield; /* 1 */ outline-offset: -2px; /* 2 */ } /** * Remove the inner padding in Chrome and Safari on macOS. */ [type="search"]::-webkit-search-decoration { -webkit-appearance: none; } /** * 1. Correct the inability to style clickable types in iOS and Safari. * 2. Change font properties to `inherit` in Safari. */ ::-webkit-file-upload-button { -webkit-appearance: button; /* 1 */ font: inherit; /* 2 */ } /* Interactive ========================================================================== */ /* * Add the correct display in Edge and Firefox. */ details { display: block; } /* * Add the correct display in all browsers. */ summary { display: list-item; } /* Objects Non-cosmetic design patterns including grid and layout classes) */ /* CSS variables */ :root { --column-gap: 2.13%; --column-width-multiplier: 8.333; } /* Mobile layout */ .row-fluid { display: flex; flex-wrap: wrap; width: 100%; } .row-fluid .span1, .row-fluid .span2, .row-fluid .span3, .row-fluid .span4, .row-fluid .span5, .row-fluid .span6, .row-fluid .span7, .row-fluid .span8, .row-fluid .span9, .row-fluid .span10, .row-fluid .span11, .row-fluid .span12{ min-height: 1px; width: 100%; } /* Desktop layout */ @media (min-width: 768px) { .row-fluid { flex-wrap: nowrap; justify-content: space-between; } .row-fluid .span1 { width: calc(var(--column-width-multiplier) * 1% * 1 - var(--column-gap) * (11 * var(--column-width-multiplier) / 100)); } .row-fluid .span2 { width: calc(var(--column-width-multiplier) * 1% * 2 - var(--column-gap) * (10 * var(--column-width-multiplier) / 100)); } .row-fluid .span3 { width: calc(var(--column-width-multiplier) * 1% * 3 - var(--column-gap) * (9 * var(--column-width-multiplier) / 100)); } .row-fluid .span4 { width: calc(var(--column-width-multiplier) * 1% * 4 - var(--column-gap) * (8 * var(--column-width-multiplier) / 100)); } .row-fluid .span5 { width: calc(var(--column-width-multiplier) * 1% * 5 - var(--column-gap) * (7 * var(--column-width-multiplier) / 100)); } .row-fluid .span6 { width: calc(var(--column-width-multiplier) * 1% * 6 - var(--column-gap) * (6 * var(--column-width-multiplier) / 100)); } .row-fluid .span7 { width: calc(var(--column-width-multiplier) * 1% * 7 - var(--column-gap) * (5 * var(--column-width-multiplier) / 100)); } .row-fluid .span8 { width: calc(var(--column-width-multiplier) * 1% * 8 - var(--column-gap) * (4 * var(--column-width-multiplier) / 100)); } .row-fluid .span9 { width: calc(var(--column-width-multiplier) * 1% * 9 - var(--column-gap) * (3 * var(--column-width-multiplier) / 100)); } .row-fluid .span10 { width: calc(var(--column-width-multiplier) * 1% * 10 - var(--column-gap) * (2 * var(--column-width-multiplier) / 100)); } .row-fluid .span11 { width: calc(var(--column-width-multiplier) * 1% * 11 - var(--column-gap) * (1 * var(--column-width-multiplier) / 100)); } } /* ============================================================================= Containers & sections — Uptoo Digital ----------------------------------------------------------------------------- Relevés de la charte : frame 1440 avec 120px de gouttière latérale, donc une largeur de contenu de 1200px. Le container ne dépasse jamais cette valeur ; sur mobile la gouttière tombe à 20px (token --container-pad). ============================================================================= */ .container { width: 100%; max-width: calc(var(--container-max) + 2 * var(--container-pad)); margin-inline: auto; padding-inline: var(--container-pad); } /* Gabarit de hero — 598px. Ajouté le 2026-08-09 (REVUE-MODULES §M-A, arbitrage 2). 598 est la largeur de TOUS les heros desktop du fichier Figma, mesurée sur les 7 pages Solutions et les 6 pages Intégrations. `.container--narrow` (800px) n'était le gabarit d'AUCUN hero relevé — et il n'avait qu'un seul consommateur dans tout le dépôt : la variante A de `hero-page`, qui pointe désormais ici. */ .container--hero { max-width: calc(598px + 2 * var(--container-pad)); } /* Conservé : plus aucun consommateur au 2026-08-09, mais la classe reste disponible pour un gabarit large intermédiaire. Ne pas la reprendre pour un hero — voir ci-dessus. */ .container--narrow { max-width: calc(800px + 2 * var(--container-pad)); } .container--full { max-width: none; } /* Le wrapper de contenu du boilerplate suit la même règle, pour que les zones dnd et nos partials s'alignent sur la même gouttière. */ .content-wrapper { width: 100%; max-width: calc(var(--container-max) + 2 * var(--container-pad)); margin-inline: auto; padding-inline: var(--container-pad); } /* --- Section : l'unité de rythme vertical. Porte aussi la couche 3 quand on lui ajoute .section--dark. ------------------------------------------------ */ .section { padding-block: var(--section-y-lg); background-color: var(--bg); color: var(--text); } /* Il n'y a plus de bascule mobile ICI : depuis le 2026-08-08, ce sont les TOKENS qui changent sous 768px (`tokens-primitives.css`, bloc mobile), pas la règle. Les trois paliers s'y replient sur 56/56, donc `.section` et ses paliers deviennent égaux en mobile sans qu'aucune règle ait à le redire. La règle `@media (max-width:767px) { .section { padding-block: var(--sp-7) } }` qui vivait ici est donc supprimée, pas déplacée. */ /* --- Paliers de rythme (arbitrage du 2026-08-08 ; palier `xs` ajouté le 2026-08-09 par D14) ------------------------------------------------------ `.section` sert le palier LARGE, qui couvre 5 des 9 sections de la maquette. Les trois autres paliers sont des modificateurs, posés par les modules qui rendent une section relevée à 64/64, à 104/104 ou dans la famille 86→96 — le mappage complet est dans DECISIONS-DESIGN §4.4. `--rhythm-sm` est le palier de TOUTE la famille 86→96, pas seulement des deux sections qui nomment le token : arbitrage M-14 du 2026-08-11, justifié au point de définition (`tokens-primitives.css`, bloc `--section-y-*`). Les quatre sections de `offre-audit-crm` relevées 96/96 et 86 en haut se câblent donc ici, et aucun 5e palier n'a été ajouté. ⚠️ ORDRE DE DÉCLARATION — ces quatre règles sont AVANT `--tight` et `--flush`, et l'inverse serait un défaut : les six modificateurs ont la même spécificité (une classe), donc c'est la dernière déclarée qui gagne. Un module qui porte `section section--rhythm-md section--flush` doit sortir à 0, pas à 104. C'est le même piège que celui corrigé le 2026-08-05 sur la bascule mobile, décrit juste en dessous. */ .section--rhythm-xs { padding-block: var(--section-y-xs); } .section--rhythm-sm { padding-block: var(--section-y-sm); } .section--rhythm-md { padding-block: var(--section-y-md); } .section--rhythm-lg { padding-block: var(--section-y-lg); } /* Les modificateurs d'espacement de l'éditeur sont déclarés EN DERNIER, et c'est le seul ordre qui marche : une media query n'ajoute AUCUNE spécificité, donc à spécificité égale c'est la dernière règle du fichier qui gagne. Déclarés avant (l'ordre d'origine, corrigé le 2026-08-05), `.section--flush` se faisait réappliquer les 48px de `.section` sous 768px — un espacement réglé sur « Aucun » par le marketeur restait donc visible sur mobile. */ .section--tight { padding-block: var(--sp-7); } /* REPLI MOBILE DE `--tight` — M-09, posé le 2026-08-11. `--tight` était le SEUL palier de rythme sans repli : câblé en dur sur `--sp-7` (48), il sortait 48/48 à 390px pendant que les quatre `--section-y-*` se replient déjà à 56 dans le bloc mobile de `tokens-primitives.css`. Le relevé mobile ne connaît qu'un gabarit, `padding 56px 20px`, et il est explicitement donné pour constant sur toute la page (`mobile-solutions-audit-crm.md:41`, recoupé section par section dans `mobile-solutions-listing.md:27,57,82,110,131,147,175,190,226,255,287,317`). `--tight` n'a donc pas de valeur propre en mobile : il se confond avec `.section`, et sert le même token qu'elle. ⚠️ CETTE MEDIA QUERY EST UN PALLIATIF, ET LE FICHIER DIT POURQUOI douze lignes plus haut : depuis le 2026-08-08 la doctrine est que ce sont les TOKENS qui basculent sous 768px, pas les règles. Le correctif conforme serait un token `--section-y-tight` (48 en :root, 56 dans le bloc mobile) consommé sans media query, exactement comme les quatre autres paliers. Il n'est pas posé ici parce que `tokens-primitives.css` n'est pas le fichier de ce lot — le token est DEMANDÉ. Le jour où il arrive, cette media query se supprime et la règle au-dessus devient `padding-block: var(--section-y-tight)`. Tant que ce palliatif vit : si le rythme mobile cesse d'être unique, cette règle est à revisiter en même temps que le bloc mobile des tokens. ⚠️ PLACÉE AVANT `--flush`, et c'est la même raison qu'en dessous : une media query n'ajoute aucune spécificité. Déclarée APRÈS, elle rendrait 56px de padding à une section réglée sur « Aucun » par le marketeur — le défaut exact corrigé le 2026-08-05, réintroduit par l'autre bout. EFFET MESURÉ AVANT ÉCRITURE — la classe est émise par 15 modules et par `templates/blog-post.html:217`, mais elle n'est SERVIE que par `cta-final` sur les gabarits mesurés : 4 occurrences, les mêmes aux quatre viewports (`dom-390-v3.json` hub-solutions ×2, offre-audit-crm, page-libre ; `dom-1440-final.json` et `tablette-2026-08-11/dom-*.json` idem). Les 14 autres modules peuvent porter `--tight` mais aucune instance en service ne le fait — le champ « espacement » est resté sur sa valeur par défaut. · à 390 : padding 48/48 → 56/56 sur ces 4 sections, +16px de hauteur chacune ; · à 768, 900, 1023, 1024, 1100 et 1440 : AUCUN effet, la règle ne s'applique pas. Le tablette 768→1023 garde donc 48/48 — non relevé, écart inchangé. · Non mesuré : les pages de blog (`blog-post.html` câble `--tight` en dur), absentes du jeu de sondes. Elles gagnent le même +8px haut et bas. */ @media (max-width: 767px) { .section--tight { padding-block: var(--section-y-lg); } } .section--flush { padding-block: 0; } /* --- Grille utilitaire (cards, listes) ------------------------------------ */ .grid { display: grid; gap: var(--grid-gap); } .grid--2 { grid-template-columns: repeat(2, minmax(0, 1fr)); } .grid--3 { grid-template-columns: repeat(3, minmax(0, 1fr)); } .grid--4 { grid-template-columns: repeat(4, minmax(0, 1fr)); } @media (max-width: 1023px) { .grid--3, .grid--4 { grid-template-columns: repeat(2, minmax(0, 1fr)); } } @media (max-width: 767px) { .grid--2, .grid--3, .grid--4 { grid-template-columns: minmax(0, 1fr); } } /* --- Lien d'évitement (skip-link) ----------------------------------------- */ .skip-link { position: absolute; left: var(--sp-4); top: var(--sp-4); z-index: 1000; padding: var(--sp-3) var(--sp-4); border-radius: var(--radius-sm); background: var(--bg-white); color: var(--text-title); font-weight: var(--fw-medium); transform: translateY(-200%); transition: transform var(--dur-fast) var(--ease-out); } .skip-link:focus { transform: translateY(0); } /* Masquage visuel sans retirer du flux accessible. */ .u-visually-hidden { position: absolute; width: 1px; height: 1px; margin: -1px; padding: 0; overflow: hidden; clip: rect(0 0 0 0); clip-path: inset(50%); white-space: nowrap; border: 0; } /* La règle `.content-wrapper` du boilerplate HubSpot a été SUPPRIMÉE le 2026-08-05. Elle redéclarait `padding: 0 1rem` puis `padding: 0` au-dessus de 1380px, à spécificité égale avec `_layout.css` et APRÈS lui dans main.css : elle écrasait donc silencieusement la gouttière du socle, ce qui collait le logo de la navbar au bord de l'écran au-delà de 1380px là où la maquette pose 80px. `_layout.css` définit déjà `.content-wrapper` avec les bons tokens. */ .dnd-section > .row-fluid { margin: 0 auto; } .dnd-section .dnd-column { padding: 0 1rem; } @media (max-width: 767px) { .dnd-section .dnd-column { padding: 0; } } /* Elements Base HTML elements are styled in this section (,

, ,

,

…contenu…
L'état ouvert est porté par `data-ud-open="true"` sur l'ITEM, écrit par le `module.js` du module concerné — c'est le seul hook, il était déjà commun aux deux modules avant la remontée. Deux règles de fond, héritées des deux modules et conservées telles quelles : · l'ouverture anime `grid-template-rows` de 0fr à 1fr — jamais `display: none`, qui ne s'anime pas et retire le contenu du flux. Le panneau replié reste dans le HTML (indexable) mais sort de l'arbre d'accessibilité via `visibility` ; · aucune couleur, aucune taille, aucune durée littérale : uniquement des rôles et des tokens du socle. La primitive fonctionne donc telle quelle dans une `.section--dark`. Cette feuille vit dans main.css, donc chargée dans le `` et jamais différée : c'est elle qui replie les panneaux. Différée, la page afficherait d'abord tous les panneaux ouverts puis les replierait. ============================================================================= */ /* --- Item ------------------------------------------------------------------ Les séparateurs dessinent la liste : une bordure haute sur le premier item, une bordure basse sur chacun — d'où un trait unique entre deux items. ----- */ .ud-disclosure__item { border-bottom: 1px solid var(--border); } .ud-disclosure__item:first-child { border-top: 1px solid var(--border); } /* Le titre porte le style typographique (classe utilitaire du socle) ; sa marge basse n'a pas de sens ici, le rythme vient du padding du bouton. À spécificité égale avec `.u-heading-s`, c'est l'ordre d'inclusion dans main.css qui tranche — et les composants y passent après les éléments. */ .ud-disclosure__heading { margin: 0; } /* --- Trigger --------------------------------------------------------------- Un vrai