Le RGAA (référentiel général d’amélioration de l’accessibilité) ne se limite pas à la structure sémantique du HTML ou au contraste des couleurs : plusieurs de ses critères, souvent négligés dans les audits centrés sur le code front, concernent directement l’infrastructure serveur. Une collectivité qui prépare l’ouverture d’un site public soumis à cette obligation réglementaire doit intégrer ces exigences dès la phase de choix d’hébergement, pas en correction tardive après un audit qui les révèle.
Cette checklist se concentre exclusivement sur le volet serveur de la conformité, sans revenir sur l’accessibilité du code front lui-même, largement traitée par ailleurs dans sa propre catégorie sur ce blog.
Pourquoi le temps de réponse est un critère d’accessibilité, pas seulement de performance
Une personne utilisant un lecteur d’écran ou une technologie d’assistance perçoit un temps de chargement long différemment d’un visiteur standard : l’absence de retour visuel immédiat, couplée à une lecture séquentielle du contenu par synthèse vocale, rend l’attente plus difficile à interpréter. Au-delà d’environ trois secondes de latence sans indication claire de chargement en cours, de nombreux utilisateurs de technologies d’assistance interrompent leur navigation, considérant la page comme défaillante.
- Temps de réponse serveur cohérent et prévisible, pas seulement rapide en moyenne
- Indicateurs de chargement accessibles pendant les opérations asynchrones
- Absence de délais d’attente imprévisibles sur les formulaires de contact ou de saisie
La disponibilité, critère souvent absent des audits classiques
Un site public inaccessible pendant une maintenance non planifiée, ou victime d’une panne récurrente, pénalise structurellement les personnes qui dépendent de ce canal pour accéder à un service public sans alternative simple. Le RGAA ne fixe pas de taux de disponibilité chiffré universel, mais l’esprit du référentiel implique une continuité de service cohérente avec la mission d’accès universel du site concerné.
Checklist serveur avant ouverture
- Choisir un hébergement dimensionné pour absorber les pics de consultation prévisibles (annonces officielles, échéances administratives)
- Mettre en place une supervision de disponibilité avec alerte, pas uniquement un suivi a posteriori
- Vérifier le temps de réponse moyen et le temps de réponse au 95e percentile, pas seulement la moyenne
- Planifier les fenêtres de maintenance en dehors des horaires de forte consultation connus
- Prévoir une page de maintenance elle-même accessible, avec message clair et alternative de contact
- Documenter un plan de continuité en cas d’incident majeur affectant la disponibilité
Le cas particulier de la page de maintenance
Une page de maintenance mal conçue peut, à elle seule, créer une rupture d’accessibilité : image statique sans texte alternatif, absence de structure sémantique, ou simple redirection vers une page blanche sans explication. Cette page doit respecter les mêmes exigences RGAA que le reste du site, un point que beaucoup d’hébergeurs gèrent par défaut avec un gabarit générique non conforme.
<!-- Exemple minimal de structure accessible pour une page de maintenance -->
<h1>Site temporairement indisponible</h1>
<p>Une opération de maintenance est en cours. Le site sera de nouveau disponible avant 22 heures.</p>
<p>Pour une urgence, contactez le service au 01 23 45 67 89.</p>
Vérifier avant de signer avec l’hébergeur
| Point à vérifier | Pourquoi c’est important pour le RGAA |
|---|---|
| Engagement contractuel de disponibilité (SLA) | Continuité d’accès au service public |
| Historique de temps de réponse mesurable | Impact direct sur les technologies d’assistance |
| Gabarit de page de maintenance personnalisable | Éviter une rupture d’accessibilité pendant les interventions |
Un audit RGAA qui s’arrête au code source sans jamais interroger le temps de réponse réel ni la politique de disponibilité de l’hébergeur passe à côté d’une part entière de ce que vivent réellement les usagers concernés.
Checklist finale avant mise en ligne publique
- Temps de réponse testé sous charge réaliste, pas seulement en environnement de développement
- Supervision active de la disponibilité mise en place avant l’ouverture, pas après un premier incident
- Page de maintenance conforme aux mêmes exigences que le reste du site
- Plan de continuité documenté et partagé avec les équipes de la collectivité
En résumé
La conformité RGAA d’un site de collectivité ne s’arrête pas à la structure du code affiché : le temps de réponse serveur et la disponibilité réelle du service font partie intégrante de l’accessibilité vécue par les usagers, en particulier ceux qui dépendent de technologies d’assistance. Intégrer ces critères dès le choix de l’hébergement évite des corrections coûteuses une fois le site ouvert au public.
