Deux minutes contre deux jours : c’est l’écart de délai entre la détection d’une image sans texte alternatif par un lint automatisé au moment du commit, et sa détection par une revue de code manuelle qui n’intervient qu’après l’ouverture de la pull request, parfois plusieurs jours plus tard selon la disponibilité des relecteurs. Pour une équipe qui développe des blocs Gutenberg personnalisés à un rythme soutenu, cet écart de délai a un impact direct sur le coût de correction : plus une erreur est détectée tôt, moins son contexte a été oublié par le développeur qui l’a introduite.
eslint-plugin-jsx-a11y est un plugin ESLint qui analyse le JSX utilisé dans le développement de blocs pour l’éditeur, et signale un ensemble de motifs syntaxiques connus pour poser des problèmes d’accessibilité : attribut alt manquant, gestionnaire onClick posé sur un élément non interactif sans rôle ni gestion clavier associée, libellé de formulaire absent. Sa configuration recommandée active 27 règles par défaut, exécutables en quelques secondes sur l’ensemble d’un projet.
Ce que le lint automatisé détecte bien
Le lint excelle sur les motifs syntaxiques stricts, indépendants du sens réel du contenu : un <img> sans attribut alt, un <div onClick={...}> sans role ni gestionnaire clavier, un champ de formulaire sans htmlFor associé à un <label>. Ces règles s’appliquent de façon identique quel que soit le contexte métier du bloc développé, et ne nécessitent aucune connaissance du contenu réel qui sera affiché une fois le bloc publié.
L’exécution s’intègre naturellement dans un hook de pré-commit via husky et lint-staged, ce qui bloque littéralement la création du commit tant que la violation n’est pas corrigée — un niveau de rigueur qu’aucune revue manuelle, dépendante de la disponibilité humaine, ne peut égaler en termes de délai.
Ce que la revue manuelle capte que le lint ignore
Le lint ne peut évaluer aucune question de pertinence sémantique. Un attribut alt="image" passe la totalité des règles automatisées sans déclencher la moindre alerte, alors qu’il constitue une description parfaitement inutile pour un utilisateur de lecteur d’écran. De même, un ordre de tabulation illogique entre plusieurs champs positionnés côte à côte par CSS Grid échappe totalement à l’analyse statique du JSX, puisque l’ordre visuel et l’ordre du DOM peuvent diverger sans qu’aucune règle syntaxique ne soit techniquement violée.
Comparatif synthétique
| Aspect | eslint-plugin-jsx-a11y | Revue manuelle |
|---|---|---|
| Délai de détection | Avant le commit | Après ouverture de la pull request |
| Pertinence sémantique du contenu | Non évaluée | Évaluée par le relecteur |
| Ordre de tabulation logique | Non détecté | Détectable à l’usage |
| Coût humain récurrent | Négligeable | Temps de relecteur à chaque PR |
| Reproductibilité | Totale | Dépend du relecteur assigné |
Un exemple qui illustre la complémentarité
Sur un projet de bloc de témoignages clients pour une plateforme de formation en ligne, le lint automatisé a bloqué à lui seul quarante-trois commits en six mois pour des attributs alt manquants sur les photos de profil — un travail répétitif que personne ne souhaitait continuer à faire manuellement. La revue humaine, elle, a identifié un problème que le lint ne pouvait pas voir : l’ordre de lecture au clavier des étoiles de notation ne correspondait pas à l’ordre visuel affiché, un défaut invisible dans le code JSX pris isolément mais flagrant lors d’un test clavier réel.
Configurer le plugin sans excès
L’écueil à éviter consiste à activer d’emblée l’intégralité des règles disponibles sans phase d’adaptation, au risque de bloquer des commits sur des règles trop strictes pour le contexte réel du projet. Une progression raisonnable consiste à démarrer avec la configuration recommandée du plugin, puis à ajuster au cas par cas les règles qui génèrent des faux positifs répétés, en documentant chaque exception dans le fichier de configuration plutôt que dans des commentaires disséminés dans le code.
- Démarrer avec la configuration recommandée officielle du plugin.
- Intégrer le lint dans un hook de pré-commit, pas seulement dans la CI, pour un retour immédiat au développeur.
- Conserver une étape de revue humaine ciblée sur les questions de sens et d’usage réel au clavier.
Notre verdict
Opposer les deux approches n’a pas de sens : le lint automatisé élimine la charge répétitive des erreurs syntaxiques évidentes, libérant le temps de relecture humaine pour les questions de pertinence et d’usage réel que ni ESLint ni aucun outil statique ne pourra jamais évaluer à la place d’une personne.
