Une refonte est en ligne, le nouveau formulaire fonctionne et les premiers retours semblent positifs. Pour savoir si l’expérience s’améliore vraiment, il reste à vérifier ce qui change pour les personnes qui utilisent le site : peuvent-elles terminer leur démarche, dans quels délais et sans nouveaux obstacles d’accessibilité ?
La comparaison se prépare avant le déploiement. Le protocole suivant aide à conserver une référence, détecter les régressions et prendre une décision documentée. Il s’applique à une refonte comme à la modification d’un menu, d’un formulaire ou d’une étape de commande.
Définir une amélioration que l’on pourra vérifier
Remplacez « améliorer l’UX » par une attente précise : « permettre d’envoyer une demande de devis sans perdre la saisie » ou « rendre la sélection d’un créneau plus réactive ». Choisissez un parcours et les pages qui le composent.
Associez ensuite trois familles de preuves :
- La réussite : une demande enregistrée, une inscription confirmée ou une autre action métier définie.
- Les conditions d’usage : les temps et erreurs pertinents pour ce parcours, ainsi que les signalements reçus.
- L’accessibilité : les résultats des contrôles applicables aux composants et aux pages concernés.
La mesure de réussite nécessite une instrumentation adaptée. Définissez son événement de départ, sa confirmation finale et le traitement des tentatives répétées. Une confirmation affichée doit correspondre au résultat métier attendu. Notre article sur le choix des indicateurs d’expérience digitale complète cette préparation.
Conserver une référence avant de modifier le site
Enregistrez le périmètre, les définitions des indicateurs, les filtres et les volumes observés. Fixez une période de référence adaptée au rythme du service : comparer un lundi à un dimanche peut décrire deux usages différents. Une semaine n’est pas automatiquement suffisante si les confirmations sont rares.
Notez les campagnes, changements d’offre, incidents et autres événements susceptibles d’influencer les visites. Prévoyez comment retrouver la version réellement utilisée après le déploiement, lorsque cette information est disponible. L’heure de mise en ligne seule peut être insuffisante si plusieurs versions coexistent.
Enfin, rejouez un parcours complet avec la mesure activée. Vérifiez que les événements attendus arrivent, sans doublon, et que leurs définitions resteront identiques. Une refonte du marquage peut produire une rupture dans les chiffres qui ressemble à un changement d’usage.
Une fiche de contrôle pour chaque déploiement
Attribuez un responsable à chaque vérification et une date de bilan. Définissez à l’avance les incidents qui exigent une correction immédiate ou l’arrêt d’un déploiement progressif. Les seuils dépendent du service ; une impossibilité de terminer un parcours essentiel demande une attention immédiate.
| Moment | Vérification | Preuve à conserver |
|---|---|---|
| Avant la modification | Définir le parcours, la réussite attendue et les conditions de comparaison. | Référence datée, indicateurs, volumes et état des contrôles. |
| Avant la mise en ligne | Rejouer les actions, les erreurs et les usages au clavier. | Résultats des scénarios et points restant à corriger ou valider. |
| Dès la mise en ligne | Vérifier les fonctions essentielles et la continuité de la collecte. | Version, heure, confirmation métier et éventuelles anomalies. |
| Pendant l’observation | Comparer des groupes et des périodes pertinents. | Évolutions, volumes, incidents et changements de contexte. |
| Au bilan | Décider de poursuivre, corriger ou prolonger l’observation. | Décision motivée, incertitudes, responsable et prochain contrôle. |
Recontrôler l’accessibilité des éléments modifiés
Un nouveau composant appelle de nouvelles vérifications : ordre du focus, utilisation au clavier, libellés, erreurs et restitution des changements d’état, selon ce qui a évolué. Le W3C recommande d’évaluer l’accessibilité tout au long du développement et rappelle qu’un outil seul ne suffit pas à établir le respect des exigences.
Pour une évaluation RGAA, le périmètre doit rester représentatif. La méthode officielle prévoit notamment l’ensemble des pages d’un processus retenu. Une étape peu visitée peut être indispensable. Ne limitez donc pas les recontrôles aux pages les plus fréquentées.
Comparez les résultats à périmètre explicite : conserver, ajouter ou retirer une page change ce que décrit le bilan. Un meilleur taux ne prouve pas une amélioration si les pages difficiles ont disparu de l’évaluation. appYaccess peut servir à relancer les contrôles et à suivre les points restant à valider. Les validations humaines nécessaires restent à organiser.
Comparer les visites après la mise en ligne
Examinez les évolutions par parcours, appareil et navigateur lorsque les effectifs le permettent. Une moyenne globale peut changer parce que la composition du trafic a changé. Gardez les volumes et les périodes visibles, et distinguez une absence de mesure d’une absence de problème.
Si une interaction se dégrade, utilisez les observations terrain pour orienter un test reproductible. C’est la démarche décrite dans le guide Google d’optimisation de l’INP. Notre grille explique aussi comment diagnostiquer un site rapide en test mais lent pour certains visiteurs.
Un avant/après décrit une évolution ; il ne suffit pas à en établir la cause. Saisonnalité, acquisition, disponibilité d’un produit ou modification simultanée du contenu peuvent peser sur les résultats. Consignez ces explications possibles. Une évolution cohérente, un problème reproduit et un recontrôle réussi renforcent le diagnostic, sans justifier une promesse universelle de gain.
Cas pédagogique : une demande de devis en plusieurs étapes
Cet exemple est fictif. Une équipe remplace un long formulaire par plusieurs écrans. Elle prévoit de suivre les démarrages, les demandes confirmées et les erreurs rencontrées, avec des définitions identiques avant et après la modification.
Supposons qu’un test de production révèle que le message d’erreur d’une étape n’est pas correctement restitué. Le parcours demande une correction, même si les temps d’affichage sont satisfaisants. Après correction, l’équipe rejoue le scénario concerné et poursuit l’observation des confirmations.
À l’inverse, si le volume de demandes est trop faible pour interpréter son évolution, elle peut conclure que les contrôles ont réussi sur le périmètre testé et que l’effet sur la réussite métier reste à confirmer. Cette conclusion précise est plus utile qu’un bilan général fondé sur quelques visites.
Terminer par une décision traçable
Le bilan doit répondre à trois questions : qu’avons-nous vérifié, qu’avons-nous observé et que décidons-nous ? Conservez les régressions à traiter, les points validés et les incertitudes, avec une prochaine échéance.
Une solution de RUM comme appYuser aide à suivre l’expérience dans les contextes de navigation observés. Rapprochez ces informations des actions métier effectivement instrumentées et des recontrôles d’accessibilité. Les données de navigation ne permettent pas, à elles seules, d’identifier le handicap d’une personne.
Si la réussite du parcours recule, la méthode pour identifier les blocages derrière une baisse des conversions aide à poursuivre l’enquête. Le dossier accessibilité RGAA, expérience utilisateur et conversions donne le cadre commun à ce travail dans la durée.
Sources et repères
- W3C/WAI — Evaluating Web Accessibility Overview : évaluation au cours du développement et rôle de l’expertise humaine.
- DINUM — Évaluation de la conformité à la norme de référence : échantillon représentatif, processus et critères applicables. Référentiel consulté : RGAA 4.1.2.
- Google, web.dev — Optimize Interaction to Next Paint, mis à jour le 2 septembre 2025 : passage des observations terrain au diagnostic en laboratoire.
