---
title: "Refonte accessible : prévoir le RGAA dès le lancement du projet"
description: "Corriger en amont coûte une fraction de ce que coûte corriger après."
url: "https://www.newp.fr/mise-en-conformite-rgaa/refonte-accessible/"
author: ""
date: "2026-09-20T09:27:36+00:00"
modified: "2026-09-21T18:33:48+00:00"
lang: "fr_FR"
---

# Refonte accessible : prévoir le RGAA dès le lancement du projet

Traiter l’accessibilité au départ revient bien moins cher que la rattraper une fois le site livré.

 Ce sujet se rattache à notre dossier sur [la mise en conformité RGAA](/mise-en-conformite-rgaa/).

 

## Agir quand les choix sont encore ouverts

 C’est sur les maquettes que se joue l’accessibilité, pas pendant les tests de fin de projet. Régler un problème de contraste quand on définit les couleurs demande une réunion. Le régler après la mise en ligne oblige à revoir la charte graphique, les composants et chaque page qui les utilise.

 Une refonte offre donc la meilleure chance d’atteindre la conformité, et rater cette chance coûte très cher.

## Les décisions à prendre, phase par phase

### Pendant le cadrage

- l’**objectif de conformité** : totale, ou un taux minimal chiffré (sans minimum, « partiellement conforme » accepte un taux de 51 %) ;
- le **périmètre couvert** : espace client, documents téléchargeables, application mobile ;
- l’**audit de conformité posé comme critère de recette**, et non comme un contrôle réalisé après coup ;
- la technologie retenue, qui vous engage pour longtemps.
 
### Pendant la conception graphique

- des couleurs vérifiées par un calcul de contraste, jamais à vue d’œil ;
- un style de focus dessiné, comme on dessine le survol ;
- des zones cliquables assez grandes ;
- un ordre de lecture indiqué dans les maquettes, mobile compris : c’est à cette étape que l’ordre visuel et l’ordre de tabulation commencent à diverger ;
- aucune information transmise uniquement par une couleur ou un emplacement.
 
### Pendant le développement

- des éléments HTML natifs dès qu’il en existe un adapté ;
- un contenu consultable même si JavaScript ne s’exécute pas ;
- des tests automatiques activés dès le premier lot livré, et non en fin de chantier ;
- des composants décrits dans un [design system accessible](/mise-en-conformite-rgaa/design-system-accessible/).
 
### Pendant la migration des contenus

 Les anciens contenus arrivent sur le nouveau site avec leurs défauts : niveaux de titres incohérents, images sans alternative, liens « en savoir plus », PDF sans structure. Si personne ne s’en charge, ils passent la migration sans une égratignure. C’est la ligne budgétaire que l’on oublie le plus souvent.

 Votre déclaration devient caduque Dès que le site subit une **modification substantielle**, la déclaration d’accessibilité perd sa validité, et une refonte en fait partie. Un nouvel audit s’impose, suivi d’une déclaration actualisée à sa date. Inscrivez-le au planning dès le départ, pour ne pas le découvrir après le lancement.

 

## Protéger le commanditaire par le contrat

 Quand un prestataire réalise la refonte, l’exigence doit figurer noir sur blanc : référentiel et sa version, niveau à atteindre, livrables (grille des 106 critères, déclaration préremplie), date du contrôle et suites en cas d’écart. Nous détaillons ces clauses sur [notre page dédiée à l’accessibilité dans les marchés publics](/obligations-accessibilite-numerique/marches-publics/) ; elles s’appliquent tout autant à un contrat entre entreprises privées.

  [ Sujet précédent Les erreurs RGAA les plus courantes ](/mise-en-conformite-rgaa/non-conformites-frequentes/) [ Sujet suivant Rendre un site WordPress accessible ](/mise-en-conformite-rgaa/wordpress/)

---

*Source : [www.newp.fr](https://www.newp.fr/mise-en-conformite-rgaa/refonte-accessible/)*