Résumé rapide :
Ce case study raconte comment l’équipe Réfugiés.info, un produit public incubé par Beta.gouv, a amélioré son accessibilité numérique tout en migrant vers le DSFR (Design System de l’État).
L’objectif : concilier dettes techniques, contraintes humaines et exigences du RGAA, pour faire évoluer un service essentiel sans interrompre sa mission.
1. Contexte et rôle — Reprendre un produit public en pleine mue
Qu’est-ce que Réfugiés.info ?
Réfugiés.info est un service public français qui aide les personnes réfugiées, demandeurs d’asile et accompagnants à trouver des informations fiables sur leurs droits et démarches.
Un produit utile, humain et déjà bien installé dans l’écosystème Beta.gouv.
D’où partait-on ?
Quand je suis arrivé, le site fonctionnait mais portait les traces de plusieurs générations de développeurs.
Chaque phase avait laissé son empreinte : frameworks différents, conventions CSS variables, composants réécrits au fil du temps.
Rien de bloquant, mais un ensemble hétérogène et difficile à faire évoluer sans tout casser.
Le produit disposait d’un design system maison, cohérent visuellement mais dépourvu d’outillage robuste et de stratégie d’accessibilité claire.
C’est là que l’équipe a voulu passer un cap :
👉 renforcer l’accessibilité numérique,
👉 migrer vers le DSFR,
👉 et maintenir la cadence d’évolution du produit.
Mon rôle et mon niveau de départ
J’ai rejoint l’équipe comme développeur front-end senior, spécialisé en design system et standards web, mais pas encore expert RGAA.
Je connaissais les bonnes pratiques d’accessibilité sans maîtriser tous les critères du référentiel.
J’ai donc commencé par observer : navigation au clavier, vocalisation, structure des titres, focus visuels.
Résultat : beaucoup de marge de progression.
🧩 DSFR : le Design System de l’État français, bibliothèque de composants et règles graphiques pour harmoniser les services publics numériques.
♿ RGAA : le Référentiel Général d’Amélioration de l’Accessibilité, qui définit les critères à respecter pour garantir l’accès à tous les usagers.
🏛️ Beta.gouv : l’incubateur des startups d’État, qui accompagne les produits publics dans une approche agile et itérative.
Comment s’est enclenchée la démarche ?
La team accessibilité de Beta.gouv est intervenue dès le démarrage :
une session d’onboarding individuelle pour se mettre à niveau, comprendre les outils de test et cadrer les priorités.
Pas un audit formel, mais un vrai coup de pouce pédagogique qui a permis de transformer le sujet “accessibilité” en feuille de route concrète.
Parallèlement, la migration vers le DSFR s’est imposée comme levier logique :
le DSFR intègre déjà de nombreuses bonnes pratiques d’accessibilité.
👉 Travailler sur les deux sujets en parallèle avait donc du sens : chaque composant migré gagnait en cohérence et en inclusion.
Chronophage, certes, mais beaucoup plus vertueux :
refaire moins, mieux, et plus durablement.
2. Quels problèmes techniques et d’accessibilité fallait-il résoudre ?
Un produit public solide… mais à réaligner
Réfugiés.info fonctionnait bien : les utilisateurs trouvaient ce dont ils avaient besoin.
Mais sous le capot, le produit n’était pas encore aligné avec les standards du RGAA ni avec la logique du DSFR.
Et aujourd’hui encore, une partie du travail se poursuit pour consolider ces bases.
Dette front-end et hétérogénéité du code
Le site portait l’héritage de plusieurs générations de développeurs.
Certaines parties utilisaient des technologies anciennes, d’autres du React plus moderne, avec encore beaucoup de SCSS au lieu d’un système utilitaire type Tailwind CSS.
Rien de dramatique, mais un ensemble disparate : des conventions de code variables, des composants structurés différemment, et une cohérence difficile à maintenir.
Les composants étaient rangés correctement dans l’arborescence, mais pas conçus avec le RGAA en tête ; leur logique interne changeait d’un bloc à l’autre.
Résultat : des comportements légèrement incohérents et une maintenance laborieuse.
Une documentation technique existait bien, mais reflétait surtout les façons de faire successives des différentes équipes plutôt qu’un cadre commun.
Où en était l’accessibilité web ?
Il n’y avait pas encore d’audit RGAA formel.
L’équipe faisait “attention”, mais sans démarche structurée : quelques labels posés à la main, des contrastes ajustés au cas par cas, et beaucoup de bonne volonté.
En pratique, cela donnait :
- des titres hiérarchiquement incohérents,
- des focus invisibles dans certaines modales,
- des composants dynamiques non vocalisés,
- et parfois des icônes sans alternative textuelle.
Pour les utilisateurs n’ayant aucun handicap, tout semblait fluide.
Mais pour ceux naviguant au clavier ou avec un lecteur d’écran, l’expérience devenait vite complexe.
En clair : le produit n’était pas excluant, mais il n’était pas encore inclusif par conception.
Et côté design system ?
Le design system maison assurait une cohérence visuelle, mais il restait hors des standards publics.
Avec le Design System de l’État (DSFR), il fallait désormais :
- unifier les styles et composants,
- adopter les tokens DSFR (couleurs, typos, espacements),
- et revoir la logique CSS pour éviter les conflits.
📘 Rappel : le DSFR vise à homogénéiser l’expérience utilisateur des services publics français tout en intégrant les bonnes pratiques d’accessibilité et de performance.
Nous avons choisi de basculer progressivement vers le React-DSFR, plus modulaire, et de profiter de cette migration pour introduire Tailwind.
L’idée : simplifier les futurs développements, réduire la dette front, et rapprocher les styles du langage DSFR.
Quelles contraintes d’équipe ?
L’équipe était motivée, mais réduite.
En un an, trois cheffes de projet se sont succédé, chacune avec sa vision et ses priorités.
Côté technique, Luis (CTO) n’était là qu’à mi-temps, et j’étais le seul développeur à quatre jours par semaine.
En parallèle du chantier accessibilité, il fallait continuer la maintenance et livrer de nouvelles fonctionnalités.
Les aléas budgétaires ont entraîné plusieurs pauses ; le travail avançait par à-coups, au gré des financements et des urgences produit.
Cette réalité a rendu le suivi plus complexe et le chantier plus long que prévu, mais elle nous a forcés à trouver une méthode réaliste.
En résumé
Le produit restait solide mais fragmenté :
- un front-end vieillissant,
- des composants hétérogènes,
- une dette RGAA visible,
- et une petite équipe contrainte par le temps et les budgets.
🎯 Défi principal : réaligner la base technique et accessibilité sans interrompre la vie du service public.
3. Comment avons-nous structuré la démarche accessibilité + DSFR ?
Une méthode pensée pour avancer malgré les contraintes
Avec un seul dev à temps quasi plein, un CTO à mi-temps et des priorités produits mouvantes, impossible de lancer un grand plan d’accessibilité d’un bloc.
Il fallait une méthode progressive, concrète et réaliste.
L’objectif : avancer sur l’accessibilité et la migration DSFR en même temps, sans bloquer la production ni multiplier les chantiers parallèles.
Plutôt qu’une refonte complète, on a opté pour une approche itérative : améliorer à chaque passe, sans jamais régresser.
Quel rôle a joué la team accessibilité de Beta.gouv ?
Dès le début du projet, la team accessibilité Beta.gouv a joué un rôle clé.
Elle m’a accompagné lors d’un atelier d’onboarding individuel : une vraie mise à niveau sur les outils, les tests et les réflexes à adopter.
Pas une formation collective, mais un coaching ciblé :
- comprendre la logique du RGAA,
- découvrir les outils d’audit et de vocalisation,
- et poser les bonnes bases pour les tests manuels.
Leur accompagnement s’est poursuivi dans le temps :
- réponses à nos questions métaphysiques sur la vocalisation (les cas tordus de lecteurs d’écran),
- conseils sur le focus clavier ou l’usage des ARIA,
- et un audit surprise en milieu de projet, qui a fait office de piqûre de rappel bienvenue.
Cet audit informel nous a aidés à reprioriser les correctifs critiques et à garder la dynamique.
Comment avons-nous suivi les chantiers d’accessibilité ?
Plutôt que de tout mélanger à la roadmap produit, on a créé un backlog dédié à l’accessibilité.
Les tickets étaient organisés par page (et non par composant), pour faciliter les tests et le recettage.
Chaque ticket faisait référence à un ou plusieurs critères RGAA, avec une priorité claire :
- Critique : bloqueur ou incompréhensible sans assistance,
- Important : gêne modérée mais impact UX,
- Confort : amélioration souhaitable.
Cette méthode simple mais rigoureuse nous a permis de garder le cap malgré les interruptions de budget et les changements d’équipe.
Même après une pause de plusieurs semaines, on pouvait reprendre le chantier sans perte de contexte.
Comment avons-nous combiné accessibilité et migration DSFR ?
Le choix a été clair : intégrer le DSFR tout en corrigeant l’accessibilité, composant par composant.
Le DSFR, par nature, apporte déjà une structure HTML et ARIA cohérente ; chaque migration devenait donc une opportunité d’amélioration.
À chaque refactor, on testait :
- la navigation clavier complète,
- le comportement des lecteurs d’écran,
- la cohérence des titres et rôles,
- et la compatibilité visuelle (contrast ratio, focus visible, responsive).
L’idée n’était pas d’être parfait, mais de laisser chaque page plus accessible qu’avant.
Une philosophie simple, mais efficace.
Une approche très Beta.gouv : pragmatique, artisanale, durable
Pas de plan Excel géant, pas de comité d’audit hebdo.
Juste une boucle continue :
tester → corriger → migrer → tester à nouveau.
C’est ce rythme — lent mais régulier — qui a permis au projet de gagner en qualité sans s’arrêter.
L’accessibilité n’était plus un “chantier spécial”, mais une habitude de développement.
En résumé
- On a intégré l’accessibilité à la migration DSFR, pas à côté.
- La team accessibilité Beta.gouv a joué un rôle d’appui précieux.
- Le backlog dédié a servi de boussole et permis d’avancer malgré les interruptions.
- Et surtout : on a prouvé qu’une petite équipe peut améliorer un produit public sans refonte totale.
4. Quels défis techniques avons-nous rencontrés ?
D’où venait la complexité du projet ?
Travailler sur l’accessibilité et le DSFR en parallèle semblait logique sur le papier.
Mais dans la réalité, cela a vite ressemblé à un Rubik’s Cube technique :
il fallait faire cohabiter un ancien design system maison, un DSFR partiellement intégré, et une stack front-end en transition.
Notre mission : réaligner tout ça sans exploser la dette technique —
tout en modernisant la stack (coucou Tailwind 👋) et en maintenant la production active.
Où en était le design system au départ ?
Quand je suis arrivé, le design system de Réfugiés.info avait déjà commencé à migrer vers le DSFR.
Certains composants utilisaient les classes officielles du Design System de l’État,
mais sans réel travail d’accessibilité derrière.
Les styles étaient présents, les comportements beaucoup moins.
Les composants critiques — formulaires, recherche, navigation, fiches démarches —
étaient encore hors des standards RGAA, avec des rôles ARIA manquants ou mal gérés.
Il fallait donc reprendre chaque bloc, un à un, pour le réaligner sur les deux axes :
visuel (DSFR) et fonctionnel (accessibilité).
Comment avons-nous fait cohabiter DSFR et ancien système ?
Le DSFR et notre design system maison ne parlaient pas le même langage.
Structure de balises, classes CSS, logique d’initialisation : tout différait.
On a choisi la voie la plus réaliste :
migrer composant par composant, en testant à chaque fois la compatibilité avec nos besoins réels.
Cette cohabitation temporaire a demandé quelques “ninja hacks” :
notamment sur la navigation principale, qui possède plusieurs niveaux de menus dynamiques.
Le composant DSFR d’origine était trop rigide pour notre UX.
On a donc dû le réécrire partiellement pour adapter le focus clavier, la vocalisation et la gestion des états actifs.
🧠 Résultat : un menu accessible, mais un code un peu migraineux à relire — preuve qu’il n’y a pas toujours de solution magique.
Pourquoi avons-nous ajouté Tailwind CSS à l’équation ?
Nous avons profité de cette migration pour moderniser la stack front.
Le SCSS hérité du design system maison devenait difficile à maintenir.
En introduisant Tailwind CSS, on gagnait :
- en cohérence (utilisation systématique des tokens DSFR),
- en légèreté (CSS factorisé),
- et en rapidité de développement.
Mais faire cohabiter Tailwind et DSFR n’était pas trivial.
Les deux reposent sur des logiques différentes :
l’un utility-first, l’autre basé sur une charte de composants CSS.
Pour éviter les collisions, on a développé un petit outil interne qui :
- mappe les tokens DSFR (couleurs, espacements, typos) dans la config Tailwind,
- génère des classes cohérentes avec la nomenclature officielle.
💡 Grâce à ça, on peut désormais coder des interfaces DSFR directement avec la logique Tailwind, sans casser la charte de l’État.
Quels étaient les points sensibles côté accessibilité ?
Les défis les plus complexes venaient des composants dynamiques et réactifs :
- la recherche en temps réel, qui devait signaler les résultats sans noyer la vocalisation,
- les modales, dont la gestion du focus clavier devait être repensée,
- les listes imbriquées issues de l’éditeur de texte riche, souvent mal vocalisées.
Chaque correctif nécessitait des tests manuels répétés : navigation clavier, VoiceOver, NVDA, tests visuels.
Un travail patient, souvent invisible, mais essentiel.
Comment avons-nous gardé l’équilibre entre ambition et réalité ?
On savait qu’on ne viserait pas le 100 % RGAA tout de suite.
L’objectif était de progresser continuellement sans bloquer la roadmap.
La règle d’or :
chaque refactor devait laisser le code plus accessible qu’avant.
Cette approche incrémentale a permis de faire avancer le chantier tout en continuant à livrer de nouvelles fonctionnalités.
En résumé
- Le design system maison et le DSFR ont dû cohabiter temporairement.
- La migration a été progressive, testée composant par composant.
- L’introduction de Tailwind CSS a permis de moderniser la stack et d’améliorer la cohérence.
- Certains composants, comme la navigation principale, ont nécessité des adaptations lourdes.
- Et l’équipe a tenu le cap : chaque sprint rendait le produit un peu plus accessible et maintenable.
5. Quels progrès concrets et apprentissages en tirer ?
Quels résultats visibles après plusieurs mois de travail ?
Techniquement, le site n’a plus grand-chose à voir avec celui d’il y a un an.
L’intégration du DSFR et la modernisation du front ont permis de poser un socle solide pour la suite.
✅ Des avancées mesurables
- La base DSFR est désormais stabilisée : les composants principaux ont été refondus ou migrés.
- Tailwind CSS est intégré, allégeant le code et facilitant la cohérence visuelle.
- Les parcours critiques sont maintenant navigables au clavier et correctement vocalisés.
- Les comportements bloquants ont disparu sur les formulaires, modales et recherche dynamique.
- Et surtout : la dette technique front a été largement réduite, rendant le projet plus maintenable.
🎯 Le résultat n’est pas un “100 % RGAA”, mais un socle beaucoup plus robuste et testable.
Quel rôle a joué la team accessibilité de Beta.gouv ?
La team accessibilité Beta.gouv a agi comme un filet de sécurité.
Leur accompagnement régulier — puis un audit surprise en milieu de projet — ont rythmé notre progression.
Cet audit nous a aidés à :
- repérer des oublis dans les composants dynamiques,
- corriger des incohérences de vocalisation,
- et surtout, valider les bons réflexes déjà acquis.
Ce suivi en continu a transformé la démarche :
l’accessibilité n’était plus un “gros chantier ponctuel”, mais une conversation constante entre produit, design et technique.
Qu’est-ce que ce projet a changé dans la culture technique ?
Même avec une petite équipe, le chantier a été une vraie montée en compétence collective.
Les discussions produit abordent désormais systématiquement :
- la compatibilité DSFR,
- la conformité RGAA,
- et les comportements utilisateur réels.
Le DSFR est devenu notre référence commune,
Tailwind un outil de cohérence,
et l’accessibilité, un réflexe intégré à chaque refactor.
Cette évolution lente mais profonde a solidifié la culture technique du projet :
on ne parle plus seulement de “ce qui marche”, mais de “pour qui ça marche”.
Qu’avons-nous appris au passage ?
-
Ne jamais sous-estimer la complexité d’une migration DSFR.
Même si la librairie simplifie beaucoup de choses, chaque composant a ses subtilités et sa dette implicite. -
Avoir un budget dédié change tout — mais pas d’un coup.
Nous avons obtenu un financement spécifique pour l’accessibilité,
et l’enjeu a été de l’utiliser intelligemment dans le temps, pas en “one shot RGAA”. -
Tailwind + DSFR, c’est possible.
Avec méthode et rigueur sur les tokens, la cohabitation fonctionne sans sacrifier la charte. -
L’humain reste central.
Les pauses budgétaires, le turnover et la pression du quotidien imposent de la souplesse et une bonne dose d’humour.
Qu’est-ce que cela prouve ?
Ce chantier a transformé Réfugiés.info bien au-delà du code :
- le site est plus robuste,
- plus accessible,
- et surtout plus durable.
L’équipe a prouvé qu’il est possible d’améliorer un service public sans refonte totale,
et qu’une amélioration continue bien pilotée vaut mieux qu’un grand plan inaccessible.
Passer d’une mise en conformité subie à une amélioration maîtrisée. C’est la philosophie sur laquelle nous avons abouti.
6. Quelles sont les prochaines étapes ?
Ce qu’il reste à améliorer sur le plan accessibilité
Le chantier accessibilité n’est pas terminé — et c’est très bien ainsi.
L’objectif n’a jamais été d’obtenir un tampon RGAA, mais de faire progresser le produit en continu.
Les prochaines priorités sont claires :
- Finaliser la vocalisation à 100 %, notamment sur les contenus dynamiques et les retours utilisateurs.
- Boucler les sous-pages du footer, encore partiellement conformes.
- Attendre les résultats du prochain audit RGAA, programmé très prochainement, pour prioriser les derniers correctifs.
Ces points de finition permettront de passer un vrai cap vers une accessibilité complète et durable, sans retomber dans la dette.
Et côté technique, quelles évolutions ?
Le gros du travail côté front est fait, mais il reste du nettoyage et du réalignement technique à effectuer.
Prochaine étape majeure :
réduire la dette technique sur les écrans du back-office, encore en partie basés sur d’anciennes conventions.
L’objectif est de ramener tout l’écosystème du produit sous une même base DSFR + Tailwind,
avec des composants unifiés, des tokens homogènes, et une documentation simplifiée.
Cette phase permettra aussi de renforcer la maintenabilité et d’assurer la cohérence visuelle entre l’interface usager et l’espace contributeur.
Quelles pistes d’amélioration au niveau produit ?
L’idée est désormais de capitaliser sur ce travail pour en faire un levier produit, pas juste technique.
Quelques axes concrets :
- Mieux valoriser les indicateurs d’accessibilité dans le pilotage du produit.
- Sensibiliser les nouveaux contributeurs aux bonnes pratiques RGAA.
- Continuer à documenter les choix de conception pour faciliter la reprise par d’autres équipes Beta.gouv.
L’enjeu n’est plus seulement de rendre le produit accessible,
mais de rendre l’accessibilité accessible — pour l’équipe, les partenaires, et les futurs projets publics.
En quoi cette démarche est-elle réutilisable ailleurs ?
Ce retour d’expérience n’a rien d’un cas isolé.
La plupart des produits publics connaissent la même réalité :
des équipes réduites, des stacks vieillissantes, des besoins urgents.
Ce projet montre qu’il est possible de :
- faire cohabiter DSFR, RGAA et contraintes réelles,
- avancer sans tout casser,
- et construire une dynamique de progression durable.
🧠 L’accessibilité et la dette technique ne sont pas des ennemies : ce sont deux faces d’un même effort de qualité.
Points clés à retenir
- L’accessibilité n’est pas un sprint, c’est une pratique continue.
- Le DSFR peut servir de levier technique et non de contrainte.
- Tailwind + DSFR, c’est viable avec une bonne gestion des tokens.
- Une petite équipe peut améliorer un produit public, pas à pas, avec rigueur et pragmatisme.
- Et surtout : chaque refactor compte — laisser le code un peu plus accessible qu’avant, c’est déjà une victoire.
FAQ — accessibilité et DSFR
Comment intégrer le DSFR dans un produit existant ?
Progressivement, composant par composant, en testant à chaque étape la compatibilité accessibilité et design.
Peut-on combiner DSFR et Tailwind CSS ?
Oui : il suffit de mapper les tokens DSFR dans la configuration Tailwind pour garder la cohérence graphique.
Comment rendre un service public plus accessible sans refonte complète ?
En travaillant par itérations : chaque mise à jour doit rendre le produit un peu plus inclusif qu’avant.
✍️ Case study rédigé par Jérémie Gisserot — designer & développeur front-end (Beta.gouv), spécialisé en accessibilité, design system et stratégie produit.