Conformité des modules — méthodologie
Cette partie permet de balayer chaque module composant par composant et de vérifier qu'il respecte les normes de qualité d'Open ENT, telles que définies dans le Guide de contribution OPEN ENT NG.
➡️ Ouvrir le tableau de conformité interactif
Le référentiel
Le guide définit deux ensembles d'exigences, chacune typée Obligatoire (à respecter dès lors qu'elle est applicable) ou Recommandation (dérogation possible, à justifier) :
| Catégorie | Réf | Exemples |
|---|---|---|
| UX/UI | U1–U11 | bonnes pratiques, librairie de composants, thèmes 1D/2D, responsive, accessibilité… |
| Fonctionnel | F1–F13 | notifications, droits, traduction (6 langues), export/import, transition d'année, marquage statistique/DNMA, plan de test… |
| Technique | T1–T8 | timezones, traçabilité, performances, tests de charge, guide d'installation, licence AGPLv3, sécurité… |
| Accessibilité | A1–A23 | navigation clavier, focus visible, hiérarchie des titres, langue par défaut… |
Le référentiel complet est dans
static/conformite-referentiel.json
(transcrit du PDF du guide).
Évaluer un module
La page /conformite permet de :
- sélectionner un module et voir, pour chaque exigence, son statut ;
- filtrer / mettre à l'avant par catégorie (UX/UI, Fonctionnel, Technique, Accessibilité), par type (Obligatoire / Recommandation) et par statut ;
- consulter un score de conformité (part des exigences obligatoires conformes) ;
- ouvrir les tests complémentaires rattachés à une exigence (rapport e2e, recette…).
Statuts d'évaluation
| Statut | Sens |
|---|---|
conforme | exigence respectée |
partiel | partiellement respectée |
non-conforme | non respectée |
derogation | dérogation justifiée (recommandations uniquement) |
na | non applicable au module |
a-faire | à évaluer (valeur par défaut) |
Saisir une évaluation
Les évaluations sont stockées dans
static/conformite-modules.json.
Pour chaque module, on ajoute dans evaluations les réf évaluées :
{
"name": "blog",
"label": "Blog",
"repo": "open-ent/blog",
"evaluations": {
"F6": {
"statut": "partiel",
"note": "Tracking Matomo via proxy ; vérifier resourceType snake_case",
"tests": ["https://doc.tech.fr/open-ent-test/open-ent/#?q=04_blog"]
}
}
}
Une réf non listée est considérée comme a-faire. Le champ tests reçoit des tests
complémentaires (liens vers le dashboard e2e,
un rapport de recette, etc.) — c'est ainsi qu'on ajoute des tests à une exigence.
Lien avec les tests E2E
Le dashboard des tests E2E couvre la vérification de l'exigence F11 (plan de test) : on y rattache, par exigence, les specs Playwright pertinentes. La conformité (ce tableau) et l'exécution des tests (dashboard e2e) sont complémentaires.
Audit d'accessibilité automatisé (RGAA / WCAG 2.1 AA)
En complément de la méthodologie RGAA « manuelle », une base d'audit automatisé mesure les écarts d'accessibilité sur les pages clés du portail. Elle s'appuie sur axe-core (moteur de règles WCAG) piloté depuis Playwright.
- Où — spec
open-ent-mods/tests/rgaa-audit.spec.ts; règles WCAG 2.1 niveau AA. - Ce qu'elle produit — par page auditée, la liste des violations (règle, impact, sélecteur), agrégée en un relevé d'écarts servant de point de départ aux corrections.
- Portée — l'audit automatisé couvre une partie des critères RGAA (contrastes, libellés de champs, attributs ARIA, ordre des titres, alternatives d'images…). Les critères restants (navigation clavier fine, cohérence de lecture, contenus riches) restent vérifiés manuellement selon la méthodologie ci‑dessus.
- Statut — il s'agit d'une base de mesure (relevé initial des écarts) ; les corrections sont traitées ensuite écart par écart.
- Premières corrections — page de connexion ramenée de 5 à 0 règle en échec :
<html lang="fr">(langue par défaut), retrait demaximum-scalesur le viewport (zoom rétabli), labels associés aux champs (for=), contraste du texte (variante foncée AA du thème, identité de marque conservée) et intitulé du bouton d'affichage du mot de passe (aria-labelajouté à la directiveinput-passworddu thème — critèrebutton-name). Deux non‑régressions automatisées (rgaa-connexion-contrast,rgaa-connexion-button-name) verrouillent ce résultat. - Tableau de bord — 100 % conforme (règles auditées) : la règle
list(listes MUI) puiscolor-contrastont été éliminées. Pour le contraste, une nuance foncée (contraste ≥ 4.5:1) a été introduite pour les couleurs de catégorie porteuses de texte (bouton « Ouvrir », puces, en‑têtes), l'identité visuelle (teintes des pastilles/bordures) étant conservée — 87 → 0 violations. Une non‑régression automatisée verrouille ce résultat. - Réservation de ressources (RBS) — la directive
calendar(frameworkinfra-front) a été corrigée : intitulés accessibles sur les boutons icônes (aria-label— critèrebutton-name) etrole="presentation"sur un<ul>de mise en page (critèrelist) → 0 violation. - Modules edifice (React) — contraste : le gris et le vert de marque du bootstrap edifice
(
@open-ent/bootstrap) servaient de couleur de texte en deçà de l'AA. Assombris (gris ≈ 4.7:1, vert e‑primo ≈ 4.9:1) puis publiés dans le paquet et déployés → actualités, blog, wiki, cahier multimédia, réservation, support… = 0 violation de contraste. Non‑régressions automatisées (rgaa-modules-contrast,rgaa-actualites-contrast). - Synthèse — sur l'ensemble des pages clés auditées (connexion, tableau de bord, réservation, actualités et modules edifice), l'audit automatisé ne relève plus aucune violation (contrastes, intitulés, listes, langue). L'audit RGAA officiel par un tiers (déclaration de conformité réglementaire) reste, lui, à commander.
Options de personnalisation & accessibilité (utilisateur)
Au‑delà de la conformité technique, le tableau de bord offre un panneau de personnalisation (bouton Paramètres du thème) qui adresse l'accessibilité des jeunes enfants et des publics spécifiques — répondant à l'exigence d'une interface adaptable en couleurs, police et taille. Chaque réglage est mémorisé par usager.
- Mode clair / sombre.
- Couleur principale — 7 teintes (bleu, violet, magenta, rouge, orange, jaune, vert) ; couleurs de fond, de bandeau et de menu personnalisables.
- Taille du texte — du plus petit au plus grand.
- Police — plusieurs polices dont des polices adaptées : Lexend, Schoolwork, Little Days (cursives « écriture scolaire »), Creativo et OpenDyslexic (dyslexie).
- Pictogrammes au format SVG (redimensionnables sans perte).
