D'où vient le score de risque de procédure.

Score d'accessibilité (0–100)

Score unifié affiché en bandeau. Ratio pondéré passes axe vs défauts ouverts — user-status-aware : marquer une issue traitée fait monter le score sans rescan.

weighted_passes   = nodes_passed_total × 3
weighted_failures = Σ count_open(impact) × poids(impact)
  poids : critique=10 / sérieux=5 / modéré=2 / mineur=1
accessibility_score = round(100 × weighted_passes / (weighted_passes + weighted_failures))
Renvoie null si dénominateur = 0 (scan dégénéré).

• Seules les issues ouvertes (statut = open) contribuent aux weighted_failures. Les issues marquées traitées (done) ou ignorées sont exclues — le tri améliore directement le score.
• nodes_passed_total est le total cumulé de nœuds DOM ayant passé une règle axe, capturé au moment du scan.
• Le coefficient passes (×3) approxime le poids moyen de sévérité d'un test passant. Calibré empiriquement sur des scans de référence.
• Score unique exposé. Les scans historiques antérieurs au déploiement affichent null jusqu'au prochain recompute (déclenché par un triage manuel d'issue).

Couverture légale %

Taux de disponibilité moteur — part d'une référence légale pour laquelle une règle automatisée existe. PAS la part de votre site qui passe.

legal_coverage_pct = count(règles_avec_couverture_moteur) / count(règles_dans_référence) × 100

• Une couverture % élevée signifie que le moteur peut tester beaucoup de règles de ce standard — pas que votre site est conforme sur ces règles.
• La couverture est rapportée par standard (WCAG 2.2 AA, RGAA 4.1, Section 508, EN 301 549) puis agrégée pondérée par le nombre de règles testables de chaque standard.
• Les critères manuels uniquement (ex. WCAG 1.2.2 Exactitude des sous-titres) sont par définition exclus de la couverture.

Sous-scores par principe WCAG (Perceptible / Utilisable / Compréhensible / Robuste)

Quatre taux de conformité par principe, dérivés des issues trouvées et mappés via WCAG SC → principe.

sous_score(principe) = 1 − (issues_failed_du_principe / règles_testables_du_principe)
où failed exclut manual_required et needs_review

• Une issue taguée avec plusieurs principes WCAG (ex. une issue mappée à la fois sur 1.3.1 Perceptible et 4.1.2 Robuste) incrémente chaque principe indépendamment. La somme des quatre sous-scores peut donc dépasser 100 % du total d'issues — c'est voulu.
• manual_required et needs_review sont exclus du compte failed pour ne pas pénaliser des critères que le moteur ne peut pas trancher.
• Utilisé pour les radars diagnostiques uniquement — pas pour le score de conformité affiché en bandeau.

Risque de procédure — Score de probabilité (0-100, par issue)

Score de probabilité par issue combinant impact × multiplicateur WCAG × boost jurisprudence quand des données de contentieux existent pour cette règle.

base = impact_base[issue.impact] × max(wcag_multiplier[tag] pour tag dans issue.wcag_tags)
si rule_id dans RULE_JURISPRUDENCE_TABLE :
  settlements_boost = min(SETTLEMENTS_BOOST_CAP, count_settlements / DIVISOR)
  median_boost      = min(MEDIAN_BOOST_CAP, median_usd / DIVISOR)
  score = round(base × (1 + settlements_boost + median_boost))
sinon :
  score = base
score = clamp(score, 0, 100)

• Affiché dans l'application et dans le PDF Defense (colonne priorité par issue).
• Ce n'est PAS une estimation en USD — c'est un classement relatif de probabilité pour trier quelles issues corriger en premier.
• Les règles absentes de la table jurisprudence retombent sur la formule legacy impact × WCAG uniquement.

Source : RULE_JURISPRUDENCE_TABLE issue de UsableNet ADA Web Lawsuit Trends 2025 + Seyfarth ADA Title III FY2024.

Risque de procédure — Estimation en USD (PDF Defense uniquement)

Estimation de l'exposition monétaire. Affichée UNIQUEMENT dans le PDF Defense, jamais en chiffre isolé dans le dashboard, pour éviter qu'elle soit lue comme une prédiction.

raw = sum_issues( litigation_weight(rule) × impact_multiplier × volume_factor(nodes) )
exposure_usd = raw × BASE_SETTLEMENT_USD × jurisdiction_multiplier
exposure_usd = clamp(exposure_usd, LAWSUIT_RISK_MIN_USD, LAWSUIT_RISK_MAX_USD)
# BASE_SETTLEMENT_USD = 55 000 $
# jurisdiction_multiplier vaut 1.0 (US) par défaut
# Caps appliqués : plancher 20 k$ (scan unique), plafond 150 k$ (scan unique)
# Hard cap 500 k$ uniquement sur les bandes de scénarios optimistic/pessimistic

• BASE_SETTLEMENT_USD (55 000 $) = midpoint de la fourchette médiane 25 k$-75 k$ rapportée par le Seyfarth ADA Title III Year-End FY2024 pour les settlements digitaux ADA pre-litigation.
• Les caps ramènent le résultat dans la bande statistique observée en 2024-2025 (plancher 20 k$ et plafond 150 k$ sur l'estimation single-scan ; hard cap 500 k$ sur les bandes de scénarios). Les valeurs aberrantes ne sont PAS extrapolées.
• Le jurisdiction_multiplier est 1.0 (US) par défaut. Les juridictions hors-US ne sont pas encore calibrées — à lire comme US-only.
• Ce chiffre est indicatif, pas un avis juridique. À ré-évaluer chaque année à publication du rapport Seyfarth suivant.

Source : Seyfarth Shaw LLP — ADA Title III Federal Lawsuits Year-End Report FY2024.

Quick wins — gain_points

Liste de triage des issues à fort impact et faible effort. La valeur `gain_points` est un nombre d'unités de templating à corriger, PAS un delta de score.

gain_points = nombre_d_emplacements_template_uniques_à_corriger

• Ne PAS interpréter gain_points comme « points ajoutés au score si je corrige cette issue ». C'est un compte de patches distincts à appliquer sur les templates / composants.
• Un seul fix de template peut résoudre des dizaines d'occurrences au niveau page (ex. un fix image-alt dans un composant fiche produit).

Effort de correction (heures par issue)

Estimation indicative du temps de correction par règle axe-core, utilisée pour classer les quick wins. Estimations internes basées sur l'historique des fixes.

effort = FIX_EFFORT_HOURS.get(rule_id, FIX_EFFORT_HOURS_DEFAULT)
# Plage observée : 0,1 h - 4 h par règle. Défaut = 1,0 h.

• Les estimations sont PAR EMPLACEMENT DE TEMPLATE UNIQUE, pas par occurrence au niveau page.
• Ces valeurs sont des calibrations issues de l'historique du projet. Elles ne couvrent ni la QA, ni le déploiement, ni les tests de régression.

Avertissement écart viewport (desktop vs mobile)

Signale les scans où les scores de densité desktop et mobile divergent significativement, indice de défaillances responsive uniquement.

viewport_gap_warning = abs(desktop_score − mobile_score) > VIEWPORT_GAP_WARNING_THRESHOLD
# VIEWPORT_GAP_WARNING_THRESHOLD = 15 (seuil empirique projet)

• Le seuil de 15 points est empirique (calibration projet). Ce n'est pas une valeur dérivée du WCAG.
• Quand il se déclenche, le rapport ajoute un bloc de recommandation spécifique au viewport — mais ne pénalise pas le score principal.

Détection de régression (vs scan précédent)

Compare le scan courant au scan précédent dont les références légales correspondent, en remontant les règles qui échouent à nouveau.

régression = (delta_failed de la règle ≥ DEFAULT_REGRESSION_MIN_FAILED_DELTA)
# DEFAULT_REGRESSION_MIN_FAILED_DELTA = 1

• Un delta de 1 est volontairement agressif — un seul nouveau nœud en échec déclenche le flag de régression.
• La comparaison est filtrée sur les références légales correspondantes entre scans (fix issue #211). Un scan sur un référentiel différent ne sera pas comparé en régression.

Cohérence multi-page — amplification

Quand la même règle échoue sur plusieurs pages, la pénalité est amplifiée pour refléter le défaut de template récurrent.

penalty += SCORE_WEIGHT_SERIOUS × pages_affected
# Pas de cap aujourd'hui — itération future.

• Une issue affectant 10 pages contribue 10× le poids SERIOUS, indépendamment du niveau d'impact propre de l'issue. Logique : un défaut de template récurrent est par nature sérieux.
• Aucun cap supérieur sur pages_affected pour l'instant — les sites très volumineux avec des défauts de template généralisés peuvent voir le score principal saturer à 0.