Ce projet correspond à ma mission principale de mise en conformité au RGAA (Référentiel Général d'Amélioration de l'Accessibilité) sur la plateforme Grand Mémorial du Ministère de la Culture, réalisée dans le cadre de mon alternance chez Almavia CX au sein de l'équipe Lignes de Produits Grand Public.
Grand Mémorial est une plateforme mémorielle donnant accès aux registres matricules des soldats de la Première Guerre mondiale, fréquentée à la fois par le grand public, les chercheurs et les généalogistes. En tant que site de service public, il est soumis à une obligation légale de conformité au RGAA — norme française d'accessibilité numérique qui décline en 106 critères organisés en 13 thématiques les exigences issues du standard international WCAG.
Mon intervention s'est étalée de janvier à avril 2026 et a représenté 93,30 heures de production sur 22 tickets. Elle a couvert plusieurs critères du référentiel sur les thématiques images, couleur, structure, navigation et formulaires, ainsi qu'une refonte complète du formulaire de contact pour intégrer les attributs d'autocomplétion sémantique (autocomplete, <fieldset>, <legend>, gestion accessible des erreurs).
DÉVELOPPER — Développer une application Web interactive (BUT2)
AC24.01 — Produire des pages et applications Web responsives
Contexte : La mise en accessibilité d'un site public implique de garantir que toutes les pages restent utilisables et lisibles quels que soient le support (desktop, mobile, tablette) et les conditions d'utilisation (zoom, lecteur d'écran, navigation clavier).
Démarche et réalisations : J'ai retravaillé plusieurs composants du site pour qu'ils respectent les critères RGAA liés à l'adaptation : ajustement des marges et espacements sur les webforms, basic pages et articles (#135558), augmentation du margin-top du H1 sur la page de recherche (#135559), passage des champs de formulaire sur deux colonnes responsives (#135663). J'ai également veillé à ce que les corrections n'introduisent pas de régression sur les viewports mobiles.
Bilan critique : Cette mission m'a appris que le responsive ne se limite pas à l'apparence : un site « beau » sur mobile peut être inutilisable au clavier ou avec un lecteur d'écran. La pratique du RGAA m'a forcée à élargir ma définition du « responsive » à l'ensemble des contextes d'utilisation, et pas seulement aux tailles d'écran.
AC24.02 — Mettre en place ou développer un back office
Contexte : Les correctifs RGAA sur Grand Mémorial ont nécessité d'intervenir non seulement sur le front-end visible mais aussi sur la configuration du back-office Drupal, notamment pour les formulaires et l'éditeur de contenu.
Démarche et réalisations : Je suis intervenue sur la configuration du WYSIWYG (#134768) pour qu'il génère un HTML accessible côté front, j'ai paramétré le module Webform pour produire des formulaires conformes au RGAA, et j'ai ajusté les options éditeur permettant aux contributeurs du Ministère de produire du contenu accessible sans connaissance technique du référentiel.
Bilan critique : Travailler sur le back-office m'a permis de comprendre qu'une démarche d'accessibilité durable ne peut pas reposer uniquement sur le code : il faut aussi outiller les contributeurs pour qu'ils produisent du contenu accessible par défaut. Cette mission m'a sensibilisée à la dimension organisationnelle de l'accessibilité.
AC24.03 — Intégrer, produire ou développer des interactions riches ou des dispositifs interactifs
Contexte : Le formulaire de contact du Grand Mémorial était au cœur d'un critère RGAA exigeant (le critère 11.13 — Identification de la finalité d'un champ de saisie), qui demandait une refonte de l'interaction utilisateur pour la rendre accessible.
Démarche et réalisations : J'ai mené la refonte complète du formulaire de contact (#134163, 11h) en intégrant l'attribut autocomplete avec les bonnes valeurs sémantiques (name, email, etc.), en réorganisant l'ordre des champs pour suivre la logique de saisie attendue, et en remplaçant les messages d'erreur génériques par des messages explicites annoncés correctement aux lecteurs d'écran. J'ai également résolu une anomalie sur le composant captcha (#135702, 11h) qui empêchait la validation pour certains utilisateurs.
Bilan critique : Cette mission m'a fait découvrir une dimension de l'interaction web que j'ignorais : la « finalité » d'un champ pour les technologies d'assistance. Au-delà de la conformité, j'ai compris qu'une bonne UX accessible bénéficie à tous les utilisateurs — un formulaire avec autocomplétion est plus rapide à remplir pour tout le monde.
AC24.05 — Optimiser une application web en termes de référencement et de temps de chargement
Contexte : Plusieurs critères du RGAA ont un effet direct sur le référencement naturel (SEO) du site, notamment ceux relatifs à la structure sémantique des pages.
Démarche et réalisations : Le traitement du critère 8.6 — Titres de pages (#134151, 12h) m'a amenée à auditer l'ensemble des balises <title> du site pour garantir qu'elles soient uniques, descriptives et hiérarchisées. J'ai également retravaillé les intitulés de liens (critère 6.1, #134153, 10h) pour qu'ils soient explicites en dehors de leur contexte — un facteur clé pour les lecteurs d'écran mais aussi pour les moteurs de recherche.
Bilan critique : Cette mission m'a permis de constater empiriquement qu'accessibilité et SEO se renforcent mutuellement. Une page bien structurée pour un lecteur d'écran est aussi une page bien structurée pour Google. C'est un argument que je pourrai réutiliser dans tout projet futur pour défendre les investissements en accessibilité.
ENTREPRENDRE — Entreprendre un projet au sein d'un écosystème numérique (BUT2)
AC25.01 — Gérer un projet avec une méthode d'amélioration continue (méthode agile)
Contexte : L'équipe Lignes de Produits Grand Public du Ministère fonctionne sur une méthode agile adaptée : tickets pilotés par les chefs de projet via l'outil EasyRedmine, points quotidiens (daily) avec le lead développeur, et workflow GitLab structuré.
Démarche et réalisations : J'ai pris en main la mécanique de l'équipe en participant aux daily et réunions hebdomadaires (#134989), en estimant moi-même mes tickets, et en signalant rapidement les blocages au lead développeur. Le workflow imposé (branche dédiée ? MR sur develop ? relecture par un pair ? staging ? recette ? prod) m'a appris à découper mes interventions en livrables vérifiables.
Bilan critique : Au début, j'avais du mal à estimer correctement le temps nécessaire à un ticket — certains critères RGAA paraissaient simples mais cachaient une refonte de composant entière. Avec l'expérience, mes estimations sont devenues de plus en plus justes, ce qui m'a rendue plus fiable aux yeux de l'équipe.
AC25.04 — Collaborer au sein des organisations
Contexte : Mon poste d'apprentie présente une particularité forte : je collabore simultanément avec deux organisations — Almavia CX (mon employeur) et le Ministère de la Culture (le commanditaire au sein duquel je travaille au quotidien).
Démarche et réalisations : Au sein de l'équipe du Ministère, j'ai travaillé directement avec trois développeurs, un lead développeur et cinq chefs de projet. J'ai dû apprendre à formuler des demandes claires aux chefs de projet quand les tickets étaient ambigus, à solliciter le lead développeur sur les arbitrages techniques, et à soumettre mon code à la relecture de mes pairs sans le prendre personnellement quand des retours étaient faits. Côté Almavia CX, je maintiens un suivi régulier avec ma manager Lucie MOINEAU pour les bilans d'apprentissage.
Bilan critique : Cette double appartenance m'a appris à adapter ma communication selon l'interlocuteur : précision technique avec le lead développeur, vulgarisation avec les chefs de projet, recul stratégique avec ma manager Almavia. C'est une compétence relationnelle qui me servira dans toute la suite de ma carrière.
AC25.06 — Prendre en compte les contraintes juridiques
Contexte : La conformité au RGAA n'est pas une option esthétique : c'est une obligation légale pour tous les sites publics en France, encadrée par l'article 47 de la loi du 11 février 2005 et le décret du 24 juillet 2019. Le non-respect expose les organismes publics à des sanctions financières et à une obligation de publication d'un schéma pluriannuel d'accessibilité.
Démarche et réalisations : J'ai dû comprendre le cadre réglementaire avant de pouvoir agir : lecture du référentiel officiel publié par la DINUM, compréhension de la méthode d'audit, distinction entre les niveaux de conformité (totale, partielle, non-conforme). Chaque ticket que j'ai traité correspondait à un critère précis du référentiel, et mon travail consistait à faire passer ce critère du statut « non conforme » au statut « conforme » avec preuves à l'appui.
Bilan critique : Cette mission m'a fait découvrir que le développement web dans le secteur public est encadré par un corpus réglementaire dense (RGAA, RGS, RGPD, eIDAS…). Ce cadre, loin d'être un frein, donne du sens au travail technique : je ne corrigeais pas un bug d'affichage, je faisais respecter un droit d'accès à l'information pour les personnes en situation de handicap.
Découverte d'un référentiel normatif inconnu
Problème : Le RGAA était un domaine que je découvrais en arrivant sur Grand Mémorial. Le référentiel décline 106 critères organisés en 13 thématiques, avec pour chacun des méthodes de test précises. La première difficulté a été de comprendre ce qu'on me demandait concrètement quand un ticket disait simplement « [RGAA] Critère 11.5 ».
Solution : J'ai pris le temps de lire la documentation officielle du référentiel sur accessibilite.numerique.gouv.fr pour chaque thématique sur laquelle j'intervenais. J'ai aussi appris à utiliser les outils d'audit (Wave, Lighthouse, et la navigation au clavier en mode "test rapide") pour vérifier moi-même la conformité avant de soumettre mes corrections. Au bout de quelques tickets, je n'avais plus besoin de relire la documentation pour les thématiques fréquentes (images, formulaires, structure).
Refonte du formulaire de contact avec autocomplete et messages d'erreur accessibles
Problème : Le critère 11.13 (Identification de la finalité d'un champ de saisie) ne pouvait pas être résolu par une petite modification : il exigeait une refonte complète de la structure du formulaire de contact. Il fallait coordonner plusieurs changements simultanément — valeurs autocomplete correctes, ordre des champs cohérent avec la logique de saisie, messages d'erreur explicites et annoncés aux lecteurs d'écran, regroupement sémantique avec <fieldset> et <legend>.
Solution : Plutôt que d'attaquer les corrections en parallèle, j'ai pris le parti d'une refonte structurée : j'ai d'abord cartographié les champs du formulaire et la valeur autocomplete HTML5 correspondante pour chacun (name, email, given-name, etc.), puis j'ai retravaillé le balisage HTML via le module Webform de Drupal, et seulement à la fin j'ai traité les messages d'erreur. Cette approche méthodique m'a évité d'introduire des régressions sur les autres critères déjà conformes.
Anomalie persistante sur le captcha
Problème : Le ticket #135702 (Captcha en erreur, 11h) m'a beaucoup plus pris de temps que prévu. Le captcha bloquait certains utilisateurs de manière apparemment aléatoire et le problème n'était pas reproductible dans mon environnement local.
Solution : J'ai mis en place une stratégie de debug par logs : j'ai ajouté du logging applicatif côté Drupal pour tracer le contexte exact des échecs de validation (user-agent, IP, timing, état de la session). En analysant les logs collectés sur staging pendant quelques jours, j'ai pu identifier que le problème venait d'un conflit entre le cache Varnish et la durée de vie des tokens captcha. La solution a consisté à exclure les routes du formulaire du cache Varnish, ce qui a réglé l'anomalie sans dégrader les performances du reste du site.
Coordination de composants partagés entre plusieurs sites
Problème : Le composant formulaire de Grand Mémorial est en réalité partagé avec d'autres sites du Ministère, dont Fontopensearch. Mes corrections RGAA sur Grand Mémorial avaient donc des répercussions sur ces autres sites — et inversement, les évolutions faites par d'autres développeurs sur Fontopensearch pouvaient impacter ce que je venais de corriger.
Solution : J'ai appris à vérifier systématiquement l'impact de mes changements sur les autres sites du Ministère avant de soumettre une merge request, et à coordonner mes interventions avec le développeur en charge de Fontopensearch (cf. section dédiée FOPS) via des commentaires de MR explicites mentionnant les sites impactés. Cette discipline m'a évité plusieurs régressions inter-projets.
