Recette continue : automatiser les tests d’accessibilité

Résumer le contenu avec l’IA :

Une collectivité vient de mettre en ligne son nouveau site internet. Les principales non-conformités d’accessibilité relevées pendant la recette ont été corrigées. Les formulaires sont utilisables au clavier, les composants interactifs possèdent un nom accessible et les parcours prioritaires ont été vérifiés.

Quelques mois plus tard, une mise à jour du système de gestion de contenu modifie le comportement du menu. Une nouvelle fenêtre modale est ajoutée sans gestion correcte du focus. Un contributeur publie plusieurs images sans alternative pertinente. Le site n’a pas été volontairement rendu moins accessible. Il a simplement subi des évolutions ordinaires.

Cette situation concerne autant les sites de collectivités que ceux des offices de tourisme, agences d’attractivité et autres organismes de gestion de destination. Un site internet évolue en permanence : nouveaux contenus, campagnes saisonnières, fonctionnalités supplémentaires, mises à jour techniques, changements de prestataires ou intégration de services tiers.

La recette continue vise à mieux contrôler ces évolutions. Elle consiste à intégrer des vérifications régulières dans le cycle de développement et de maintenance du service numérique. Une partie de ces contrôles peut être automatisée afin de détecter rapidement certaines régressions.

Cette automatisation reste néanmoins limitée. Elle peut signaler des erreurs techniques répétitives, mais elle ne peut ni interpréter tous les critères du Référentiel général d’amélioration de l’accessibilité, ni évaluer seule la qualité réelle d’un parcours utilisateur.

L’enjeu n’est donc pas d’automatiser toute la recette. Il est de déterminer quels contrôles peuvent être confiés à des outils, lesquels exigent une intervention humaine et comment organiser leur complémentarité.

Qu’est-ce qu’une recette continue ?

Une recette continue est une démarche de contrôle intégrée au développement, au déploiement et à la maintenance d’un service numérique. Elle combine des tests automatisés, des vérifications manuelles et un suivi des anomalies afin de détecter les régressions le plus tôt possible.

Dans une organisation traditionnelle, la recette intervient souvent à la fin du projet. Les équipes terminent le développement, livrent une version supposée stable, puis exécutent une série de tests avant la mise en production.

Ce fonctionnement peut convenir à un projet peu évolutif. Il devient plus fragile lorsque le site fait l’objet de mises à jour fréquentes. Une anomalie peut être introduite quelques jours après la validation de la recette initiale.

La recette continue déplace donc une partie des contrôles vers l’amont. Les vérifications ne sont plus concentrées dans une phase unique. Elles accompagnent les différentes étapes du cycle de vie du service :

pendant la conception et le développement des composants ;
lors de l’intégration d’une nouvelle évolution ;
avant chaque mise en production ;
après le déploiement ;
puis régulièrement pendant l’exploitation du site.

Cette démarche ne signifie pas que tous les contrôles sont exécutés en permanence. Le terme « continu » décrit surtout une organisation dans laquelle la qualité est vérifiée régulièrement, selon des règles définies et reproductibles.

Pourquoi une recette réalisée avant la mise en ligne ne suffit-elle pas ?

Un site accessible à une date donnée ne le reste pas automatiquement.

La conformité peut être dégradée par une évolution apparemment mineure. Le remplacement d’un bouton, l’ajout d’un filtre de recherche, la modification d’un formulaire ou l’intégration d’une nouvelle bannière de consentement peuvent introduire des obstacles importants.

Sur un site de collectivité, une régression peut empêcher un citoyen de prendre rendez-vous, de déposer une demande ou de signaler un problème. Sur un site touristique, elle peut bloquer la recherche d’un hébergement, la consultation d’une fiche ou la réservation d’une activité.

Les régressions proviennent généralement de trois sources.

La première est technique. Une mise à jour du CMS, d’un thème, d’une bibliothèque JavaScript ou d’une extension modifie le comportement d’un composant.

La deuxième est fonctionnelle. Une nouvelle fonctionnalité est ajoutée sans reprendre toutes les exigences définies lors de la conception initiale.

La troisième est éditoriale. Les contributeurs publient des images, des tableaux, des liens, des vidéos ou des documents sans appliquer les règles d’accessibilité prévues.

Un audit ou une recette finale reste nécessaire pour évaluer un périmètre à un moment précis. Mais cette photographie ne constitue pas une garantie durable. La prévention des régressions suppose un dispositif de contrôle adapté au rythme réel des évolutions.

Pourquoi automatiser une partie de la recette d’accessibilité ?

L’automatisation est particulièrement utile pour les vérifications techniques répétitives. Elle permet d’exécuter les mêmes contrôles sur chaque nouvelle version sans demander à une personne de reprendre manuellement l’ensemble du processus.

Les outils peuvent notamment détecter certaines absences d’attributs, des erreurs de structure, des noms accessibles manquants, des identifiants dupliqués ou certains problèmes de contraste.

Cette automatisation apporte trois bénéfices principaux.

Détecter les erreurs plus tôt

Une anomalie identifiée pendant le développement est généralement plus simple à corriger qu’un défaut découvert après la mise en production.

Le développeur possède encore le contexte de son intervention. Il peut comprendre rapidement l’origine du problème et modifier le composant avant qu’il soit utilisé ailleurs.

À l’inverse, une régression détectée plusieurs semaines plus tard nécessite souvent de reconstituer l’historique de la modification, d’identifier le responsable et de vérifier les conséquences de la correction.

Sécuriser les composants réutilisés

Les sites institutionnels et touristiques reposent de plus en plus sur des bibliothèques de composants : boutons, accordéons, menus, fenêtres modales, carrousels, moteurs de recherche ou formulaires.

Une erreur intégrée dans un composant partagé peut se retrouver sur des dizaines de pages. Tester ce composant avant son déploiement permet de limiter la diffusion du défaut.

Cette approche est particulièrement importante pour les design systems. Un composant correctement conçu, documenté et testé constitue une base plus fiable pour les futurs projets. Il ne garantit pas que toutes ses utilisations seront accessibles, mais il réduit le risque de reproduire les mêmes erreurs techniques.

Produire des résultats traçables

Un test automatisé peut produire un rapport daté, associé à une version précise du code. Cette traçabilité facilite le suivi des régressions et la répartition des responsabilités.

L’équipe peut savoir :

quelle version a été testée ;
quelles règles ont été exécutées ;
quelle anomalie a été détectée ;
depuis quelle modification elle apparaît ;
si elle a été corrigée avant la mise en production.

La valeur de cette automatisation ne réside donc pas uniquement dans le nombre d’erreurs détectées. Elle contribue également à structurer le processus de qualité.

Ce que les tests automatisés peuvent réellement vérifier

Un outil d’analyse automatique applique des règles programmées à une page, à un composant ou à un parcours. Il compare les éléments détectés avec des conditions techniques précises.

Des bibliothèques comme axe-core peuvent par exemple contrôler différentes règles liées aux WCAG et à certaines bonnes pratiques. Elles peuvent être intégrées à des outils de tests fonctionnels tels que Playwright afin de lancer une analyse pendant l’exécution d’un scénario.

Les contrôles automatisables concernent principalement les éléments objectivement mesurables.

Un outil peut vérifier qu’un bouton possède un nom accessible. Il peut détecter qu’une image informative n’a pas d’attribut alt. Il peut signaler qu’un champ de formulaire n’est pas associé à une étiquette. Il peut également relever certaines incohérences dans l’usage des attributs ARIA.

L’automatisation peut aussi servir à exécuter des parcours fonctionnels. Un script peut ouvrir un menu, remplir un formulaire, activer un filtre ou vérifier qu’un message apparaît après une action.

Ces scénarios ne constituent pas, à eux seuls, des tests complets d’accessibilité. Ils permettent cependant de contrôler qu’une fonctionnalité essentielle continue de fonctionner selon des conditions déterminées.

Des mécanismes de comparaison peuvent également être utilisés. Les instantanés de l’arbre d’accessibilité proposés dans certains outils permettent, par exemple, de conserver une représentation de la structure accessible d’une page et de repérer certaines modifications ultérieures.

Pourquoi l’automatisation ne peut-elle pas garantir la conformité RGAA ?

Le RGAA 4.1.2 comprend 106 critères répartis dans 13 thématiques. Sa méthode technique permet de vérifier la conformité d’une page avec les critères de succès de niveaux A et AA des WCAG 2.1 retenus dans le cadre réglementaire français.

Or, une grande partie de ces critères demande une interprétation humaine.

Le W3C précise que certains contrôles d’accessibilité ne peuvent pas être automatisés et nécessitent une intervention manuelle. Les outils peuvent aider à identifier des problèmes, mais ils ne remplacent pas une évaluation complète.

La présence d’un attribut ne suffit notamment pas à établir sa pertinence.

Un outil peut vérifier qu’une image possède un texte alternatif. Il ne peut pas toujours déterminer si ce texte transmet correctement l’information utile dans le contexte de la page. Le W3C distingue explicitement la détection de l’absence d’alternative et l’évaluation humaine de sa pertinence.

Le même problème se pose pour de nombreux éléments :

un lien peut posséder un intitulé techniquement détectable, mais rester incompréhensible ;
une page peut contenir des titres, mais présenter une hiérarchie incohérente ;
un message d’erreur peut être affiché, sans expliquer comment corriger la saisie ;
une fenêtre modale peut recevoir le focus, tout en restant difficile à utiliser ;
un parcours peut fonctionner au clavier, mais imposer un ordre de navigation illogique ;
une vidéo peut comporter des sous-titres, mais ceux-ci peuvent être incomplets ou incorrects.

L’absence d’erreur détectée par un outil signifie uniquement que celui-ci n’a relevé aucune anomalie correspondant aux règles qu’il sait exécuter. Elle ne signifie pas que la page est conforme au RGAA.

De la même manière, un score automatique ne constitue pas un taux de conformité réglementaire. Le taux de conformité résulte de l’application de la méthodologie du RGAA à un échantillon défini, avec des vérifications techniques et humaines. La méthodologie officielle précise d’ailleurs qu’elle doit être utilisée avec le référentiel technique et qu’elle ne dispense ni d’une lecture approfondie ni d’une formation au RGAA.

Quels niveaux d’automatisation mettre en place ?

La recette continue peut être organisée progressivement. Une collectivité ou une destination touristique n’a pas nécessairement besoin de déployer immédiatement une infrastructure complexe.

Contrôler les composants pendant leur développement

Le premier niveau consiste à analyser les composants au moment de leur création.

Le développeur ou l’intégrateur peut utiliser une extension de navigateur, une bibliothèque de tests ou un environnement de démonstration du design system. Les erreurs les plus simples sont ainsi détectées avant que le composant soit intégré dans plusieurs gabarits.

Cette étape peut être complétée par des tests manuels : navigation au clavier, restitution par un lecteur d’écran, zoom du texte et vérification des différents états du composant.

Exécuter des tests avant l’intégration du code

Lorsqu’une équipe utilise un système de gestion de versions, les tests peuvent être déclenchés à chaque demande de fusion.

Une modification proposée est alors analysée avant son intégration dans la branche principale du projet. Si une erreur certaine est détectée sur un composant critique, la fusion peut être bloquée jusqu’à sa correction.

Cette règle doit toutefois être appliquée avec discernement. Un dispositif générant trop de faux positifs finit généralement par être ignoré ou désactivé. Les contrôles bloquants doivent donc reposer sur des règles fiables, comprises par l’équipe et documentées.

Intégrer les contrôles dans la chaîne CI/CD

La CI/CD désigne les mécanismes d’intégration et de déploiement continus. Ils permettent de tester, assembler et publier les évolutions d’un service numérique selon un processus automatisé.

Dans cette chaîne, les contrôles d’accessibilité peuvent être exécutés sur plusieurs gabarits ou parcours. Les résultats sont ensuite intégrés au rapport général de validation.

Par exemple, une chaîne peut vérifier qu’aucune nouvelle erreur critique n’apparaît sur la page d’accueil, le moteur de recherche, le formulaire de contact et la page de réservation.

Elle peut également exécuter un scénario plus complet : ouvrir le moteur de recherche, saisir une requête, activer un filtre, consulter une fiche puis vérifier les principaux éléments de la page obtenue.

Surveiller le site après sa mise en production

La recette continue ne s’arrête pas au déploiement. Des analyses régulières peuvent être planifiées sur le site en ligne.

Cette surveillance permet notamment de repérer les défauts introduits par les contributions éditoriales, les contenus saisonniers ou les services tiers.

Pour une collectivité, le périmètre peut comprendre les formulaires, les démarches les plus utilisées, les informations d’urgence et les pages de contact.

Pour une destination touristique, il peut couvrir le moteur de recherche, les fiches d’hébergement, les pages événementielles, les informations pratiques et les systèmes de réservation.

Comment choisir les contrôles à automatiser ?

L’objectif n’est pas de transformer chaque critère du RGAA en test automatique. Une telle promesse serait irréaliste.

La sélection doit partir des risques réels du service numérique.

Un contrôle constitue un bon candidat à l’automatisation lorsqu’il répond à plusieurs conditions : l’erreur est fréquente, la règle est objectivement mesurable, le test peut être reproduit et le résultat est suffisamment fiable.

La fréquence d’utilisation du composant doit également être prise en compte. Une erreur sur un bouton présent dans tout le site représente un risque plus important qu’un défaut isolé sur une page peu consultée.

La criticité du parcours constitue un autre critère. Une collectivité doit prioriser les démarches administratives, la prise de rendez-vous ou les formulaires de signalement. Une destination touristique doit accorder une attention particulière à la recherche d’offres, aux informations d’accès et aux processus de réservation.

Enfin, l’équipe doit vérifier que le coût de maintenance du test reste proportionné à sa valeur. Un scénario complexe qui casse à chaque évolution de l’interface peut mobiliser davantage de ressources qu’il n’en économise.

Automatisation et contrôle humain : comment répartir les vérifications ?

Une stratégie réaliste distingue ce que l’outil peut détecter et ce qu’une personne doit interpréter.

Élément contrôlé	Apport de l’automatisation	Vérification humaine nécessaire
Nom accessible d’un bouton	Détecter son absence	Vérifier sa pertinence et sa compréhension
Texte alternatif d’une image	Détecter un attribut manquant	Évaluer la qualité de l’alternative
Contraste des couleurs	Mesurer de nombreux cas simples	Vérifier les images, dégradés et états complexes
Structure des titres	Repérer certaines incohérences	Contrôler la logique éditoriale
Navigation au clavier	Exécuter certains scénarios	Évaluer l’ordre, la visibilité et le confort d’usage
Message d’erreur	Vérifier sa présence	Évaluer sa clarté et son utilité
Fenêtre modale	Contrôler certains états techniques	Tester le focus, la restitution et la compréhension
Parcours complet	Rejouer un scénario fonctionnel	Évaluer l’utilisabilité réelle

Cette répartition évite deux erreurs opposées.

La première consiste à rejeter l’automatisation au motif qu’elle ne couvre pas tout. Même partiels, les contrôles automatiques peuvent empêcher la réapparition de défauts courants.

La seconde consiste à leur accorder une confiance excessive. Un outil peut accélérer la détection, mais il ne comprend pas l’intention du service, la qualité du contenu ou les difficultés rencontrées par un utilisateur.

Comment construire une stratégie de recette continue réaliste ?

La mise en place d’une recette continue peut suivre une progression en six étapes.

Définir un périmètre prioritaire

Il faut d’abord identifier les composants, gabarits et parcours dont la dégradation aurait le plus d’impact.

Il est rarement utile de commencer par scanner indistinctement plusieurs milliers de pages. Une sélection représentative et fondée sur les usages apporte généralement des résultats plus exploitables.

Le périmètre peut comprendre :

les composants du design system ;
les gabarits les plus utilisés ;
les formulaires ;
le moteur de recherche ;
les pages transactionnelles ;
les principaux services tiers.

Établir une base de référence

Avant de détecter des régressions, l’équipe doit connaître l’état initial du périmètre.

Cette référence peut provenir d’une version validée, d’un audit, d’une recette ou d’un état des lieux ciblé. Elle permet de distinguer les anomalies historiques des nouveaux défauts introduits par une évolution.

Sans cette base, le premier test automatisé risque de produire une longue liste d’erreurs déjà connues. L’équipe ne saura pas nécessairement lesquelles sont nouvelles ni lesquelles doivent bloquer la livraison.

Choisir des règles compréhensibles

Chaque contrôle doit être associé à un objectif précis.

L’équipe doit savoir ce qui est testé, pourquoi cette règle est importante, quelles sont ses limites et quelle action entreprendre en cas d’échec.

Une règle obscure, imposée sans accompagnement, produit rarement une amélioration durable. La recette continue doit rester un outil de dialogue entre les métiers, et non une simple barrière technique.

Fixer des seuils de décision

Les seuils doivent porter sur des éléments opérationnels plutôt que sur un score global.

Une organisation peut décider qu’aucune nouvelle erreur critique n’est autorisée sur les composants partagés. Elle peut également imposer qu’aucun parcours prioritaire ne soit bloqué au clavier ou qu’une anomalie majeure soit corrigée avant le déploiement.

Les exceptions doivent être documentées. Une mise en production peut parfois être maintenue malgré une anomalie, notamment lorsqu’un correctif immédiat créerait un risque plus important. Cette décision doit alors être argumentée, attribuée et associée à une échéance.

Organiser le traitement des résultats

Produire des rapports ne suffit pas. Les anomalies doivent entrer dans un processus de qualification et de correction.

Chaque résultat devrait être associé à un responsable, un niveau de gravité, une échéance et un statut.

Il faut également distinguer :

les erreurs certaines ;
les alertes qui nécessitent une vérification ;
les faux positifs ;
les défauts acceptés temporairement ;
les anomalies déjà connues.

Sans cette qualification, les rapports s’accumulent et perdent progressivement leur utilité.

Maintenir les tests dans le temps

Les tests automatisés sont eux-mêmes des éléments du projet. Ils doivent être relus, corrigés et adaptés.

Un changement d’architecture, de composant ou de parcours peut rendre un scénario obsolète. Un test qui échoue pour de mauvaises raisons finit par ralentir le projet.

La maintenance doit donc être prévue dans la charge du prestataire ou de l’équipe interne. Elle ne peut pas être considérée comme une opération ponctuelle réalisée lors de la mise en place initiale.

Quels outils utiliser ?

Le choix d’un outil dépend du niveau de maturité de l’équipe, de l’architecture du site et des objectifs de contrôle.

Les extensions de navigateur permettent de réaliser des vérifications rapides sur une page. Elles conviennent aux développeurs, aux intégrateurs et aux chefs de projet qui souhaitent examiner un composant pendant la recette.

Les bibliothèques telles qu’axe-core peuvent être intégrées dans une infrastructure de tests. Elles exécutent des règles automatiques sur le contenu rendu dans le navigateur.

Les outils de tests fonctionnels comme Playwright permettent de simuler des actions, d’exécuter des parcours et de lancer une analyse sur les pages rencontrées. Ils peuvent aussi produire des rapports intégrés au système de validation du projet.

Les plateformes de surveillance analysent régulièrement un ensemble de pages et centralisent les résultats. Elles sont utiles pour suivre un parc de sites ou détecter des évolutions en production.

En France, les outils officiels comme Ara, l’Assistant RGAA et la grille d’audit facilitent la réalisation et la documentation d’un audit selon la méthodologie du référentiel. Ils ne doivent pas être confondus avec des scanners garantissant automatiquement la conformité.

Le Diagnostic flash peut, quant à lui, fournir une estimation rapide et partielle de l’accessibilité d’un service. Son positionnement officiel rappelle précisément qu’il ne s’agit pas d’un audit complet.

Avant de sélectionner une solution, il convient d’évaluer la transparence des règles, la gestion des faux positifs, les possibilités d’intégration, la protection des données, la qualité des rapports et la capacité à tester des parcours authentifiés.

Comment intégrer la recette continue dans un marché public ?

Dans un marché public, la recette continue ne doit pas être décrite uniquement par le nom d’un outil.

Le cahier des charges doit préciser les résultats attendus, les composants concernés, les parcours à sécuriser et les preuves qui devront être fournies.

Il peut notamment prévoir :

l’exécution de tests sur le design system ;
l’analyse des gabarits prioritaires avant chaque livraison ;
des scénarios sur les principaux services en ligne ;
la production de rapports versionnés ;
la documentation des limites de couverture ;
le transfert des scripts et de leur documentation ;
la formation des équipes chargées de leur maintenance.

Les responsabilités doivent également être définies. Le prestataire peut développer et maintenir les tests techniques, tandis que la collectivité conserve le pilotage du périmètre et des priorités. Le référent accessibilité intervient pour interpréter les résultats et organiser les contrôles manuels complémentaires.

Une offre affirmant garantir la conformité RGAA grâce à un outil automatique doit être examinée avec prudence. La conformité suppose l’application d’une méthodologie complète, et non la seule absence d’erreurs dans un scanner.

Quelles erreurs faut-il éviter ?

La première erreur consiste à confondre le score fourni par un outil avec le taux de conformité au RGAA. Ces deux indicateurs ne reposent ni sur le même périmètre ni sur la même méthode.

La deuxième consiste à tester uniquement la page d’accueil. Celle-ci ne représente généralement ni les formulaires, ni les résultats de recherche, ni les pages éditoriales, ni les espaces transactionnels.

La troisième consiste à accumuler des alertes sans organiser leur correction. Un tableau de bord rempli d’anomalies non qualifiées ne protège pas les utilisateurs.

La quatrième consiste à bloquer toutes les mises en production sur des règles instables. Une politique trop rigide peut conduire les équipes à contourner le dispositif.

La cinquième consiste à oublier les contenus éditoriaux. Une chaîne d’intégration performante ne garantit pas que les images, liens, tableaux, vidéos ou documents ajoutés dans le CMS seront accessibles.

Enfin, la recette continue ne doit pas devenir une justification pour espacer indéfiniment les audits et les tests manuels. Elle réduit le risque entre deux évaluations plus complètes ; elle ne les remplace pas.

Exemple de dispositif pour une collectivité ou une destination touristique

Une organisation disposant de ressources limitées peut commencer avec un dispositif simple.

Les composants les plus utilisés sont testés dans le design system. Avant chaque mise en production, une analyse automatique est exécutée sur cinq à dix gabarits représentatifs. Deux ou trois parcours critiques sont rejoués par un outil de test fonctionnel.

Les contributeurs disposent parallèlement d’une procédure de contrôle avant publication. Elle couvre les titres, les liens, les alternatives textuelles, les tableaux, les vidéos et les documents téléchargeables.

Une revue manuelle ciblée est organisée après chaque évolution importante. Une vérification plus large est réalisée à intervalles réguliers, en fonction du rythme des développements et du niveau de risque.

L’organisation suit quelques indicateurs simples :

le nombre de nouvelles régressions ;
les anomalies détectées avant la production ;
les anomalies découvertes après la production ;
le délai moyen de correction ;
le nombre de composants couverts ;
la proportion de parcours prioritaires testés.

Ce dispositif ne garantit pas une conformité permanente. Il permet cependant de réduire les régressions, de les détecter plus rapidement et de mieux répartir les responsabilités.

Quelle place conserver pour les tests manuels et les tests utilisateurs ?

Les tests manuels restent indispensables pour vérifier les aspects que l’automatisation ne sait pas interpréter.

Ils permettent d’évaluer la navigation au clavier, la cohérence du focus, la restitution par les technologies d’assistance, l’ordre de lecture, les changements de contexte et la compréhension des messages.

Les tests utilisateurs apportent une information différente. Ils ne visent pas uniquement à vérifier un référentiel. Ils permettent d’observer l’usage réel du service par des personnes aux profils et aux stratégies de navigation variés.

Un formulaire peut respecter de nombreux critères techniques tout en restant difficile à comprendre. Un moteur de recherche peut être utilisable au clavier, mais demander trop d’actions pour atteindre un résultat. Une carte touristique peut proposer une alternative, mais celle-ci peut ne pas répondre au besoin de préparation du séjour.

Une démarche robuste articule donc trois niveaux :

l’automatisation pour détecter rapidement les erreurs répétitives ;
l’expertise humaine pour interpréter la conformité ;
les tests utilisateurs pour évaluer l’expérience réelle.

Pour conclure : automatiser pour mieux contrôler, pas pour se rassurer

La recette continue constitue un levier utile pour maintenir la qualité d’un service numérique dans le temps. Elle permet de rapprocher les contrôles des phases de développement, d’identifier certaines régressions avant leur mise en production et de produire des résultats traçables.

Son efficacité dépend toutefois de la manière dont elle est cadrée.

Automatiser tous les critères du RGAA est impossible. Garantir la conformité d’un site avec un scanner l’est également. Les outils ne comprennent ni la pertinence d’un contenu, ni la logique complète d’un parcours, ni les difficultés concrètes rencontrées par les utilisateurs.

Une stratégie réaliste commence donc par les composants et les parcours les plus critiques. Elle automatise les règles stables et répétitives, conserve des vérifications humaines pour les critères interprétatifs et prévoit un processus clair de correction.

La bonne question n’est pas : « Comment automatiser toute notre recette ? »

Elle est plutôt : « Quelles régressions pouvons-nous détecter plus tôt, de façon fiable, sans créer une fausse impression de conformité ? »

FAQ

Qu’est-ce qu’une recette continue ?

La recette continue est une démarche dans laquelle des contrôles sont exécutés régulièrement pendant le développement, le déploiement et la maintenance d’un service numérique. Elle associe des tests automatisés, des vérifications manuelles et un suivi des anomalies.

Peut-on automatiser tous les tests du RGAA ?

Non. Certaines règles techniques peuvent être automatisées, mais de nombreux critères nécessitent une interprétation humaine. La pertinence d’un texte alternatif, la logique d’un ordre de lecture ou la clarté d’un message d’erreur ne peuvent pas être validées uniquement par un outil.

Un outil automatique peut-il garantir la conformité RGAA ?

Non. Un outil peut détecter une partie des erreurs, mais il ne peut pas établir seul la conformité globale d’un site. Celle-ci nécessite l’application de la méthodologie du RGAA, des tests manuels et une analyse experte.

Quelle différence existe-t-il entre un audit et un test automatisé ?

Un test automatisé applique un ensemble limité de règles programmées. Un audit analyse un échantillon représentatif selon une méthodologie définie et associe des contrôles techniques, manuels et contextuels.

À quel moment faut-il exécuter les tests automatisés ?

Les tests peuvent être exécutés pendant le développement, avant la fusion du code, avant chaque mise en production et régulièrement sur le site en ligne. Leur fréquence doit dépendre du rythme des évolutions et de la criticité du service.

Quelles pages faut-il tester en priorité ?

Il faut prioriser les pages et parcours essentiels : formulaires, moteurs de recherche, démarches administratives, fiches pratiques, systèmes de réservation, pages de contact et contenus les plus consultés.

Les tests automatisés conviennent-ils aux petits budgets ?

Oui, à condition de limiter le périmètre aux composants et parcours les plus importants. Quelques tests bien choisis et réellement maintenus sont plus utiles qu’un dispositif étendu qui produit des alertes sans traitement.

Qui doit maintenir les tests automatisés ?

La maintenance est généralement assurée par les développeurs ou le prestataire technique. Le chef de projet et le référent accessibilité doivent cependant piloter le périmètre, les priorités et l’interprétation des résultats.

Faut-il bloquer une mise en production lorsqu’un test échoue ?

Le blocage est pertinent lorsqu’une erreur critique, certaine et reproductible est détectée. Une alerte ambiguë ou susceptible d’être un faux positif doit plutôt déclencher une vérification humaine.

À quelle fréquence faut-il réaliser des tests manuels ?

La fréquence dépend du rythme des évolutions et des risques associés au service. Des contrôles manuels doivent être prévus après les modifications importantes, complétés par des revues périodiques et des audits plus structurés.

Recette continue : automatisation utile sans promettre l’impossible