Revue de code d’un bloc avant production : notre checklist en 20 points

Cette checklist n’est pas théorique : chacun de ses vingt points correspond à un incident réellement rencontré sur un projet client au cours des dernières années — un attribut non échappé qui a permis une injection, une chaîne non traduite livrée en anglais sur un site francophone, un bloc qui cassait silencieusement l’éditeur d’un client après une mise à jour de WordPress. Elle se coche systématiquement en revue de pull request, avant tout passage en production, jamais après.

Elle ne remplace pas les tests automatisés (couverts par un autre article de ce blog), mais couvre ce que des tests, aussi bien écrits soient-ils, ne détectent pas toujours : la cohérence du block.json, l’échappement systématique, l’accessibilité de base, et quelques pièges de performance récurrents.

block.json complet et cohérent

1. Le champ textdomain correspond exactement au domaine de traduction déclaré dans l’en-tête du plugin principal.
2. La version d’apiVersion est explicitement 3 (ou la dernière stable au moment du développement), jamais omise par oubli.
3. Chaque attribut déclare un type et, si pertinent, un default explicite — un attribut sans valeur par défaut peut produire un undefined inattendu au premier rendu.
4. La clé supports ne déclare que les fonctionnalités réellement utilisées dans le rendu ; un support de couleur activé sans classe CSS correspondante dans le template ne sert à rien et perturbe l’utilisateur.
5. Le champ example est renseigné avec des données représentatives, pour un aperçu correct dans l’inserteur de blocs.

Sécurité du rendu côté serveur

1. Chaque attribut affiché dans le HTML passe par une fonction d’échappement adaptée à son contexte : esc_html() pour du texte, esc_attr() pour un attribut HTML, esc_url() pour un lien.
2. Un contenu riche (HTML autorisé) passe par wp_kses_post() plutôt que d’être affiché brut, même si la source semble a priori fiable.
3. Aucune requête SQL directe ne concatène une valeur venant d’un attribut de bloc sans passer par $wpdb->prepare().
4. Le callback de permission d’une route REST associée au bloc ne renvoie jamais true par défaut sans réflexion explicite sur ce que cela autorise réellement.

Internationalisation

1. Toute chaîne affichée à l’utilisateur, côté éditeur comme côté front, passe par __(), _e() ou leur équivalent JavaScript __() de @wordpress/i18n, jamais codée en dur.
2. Les chaînes JavaScript sont bien enregistrées pour la traduction avec wp_set_script_translations(), sans quoi __() côté JS ne trouve simplement aucune traduction chargée.
3. Aucune concaténation de chaînes traduites qui casserait la grammaire dans une autre langue (préférer sprintf() avec des espaces réservés explicites).

Accessibilité

1. Tout élément interactif (bouton, lien, champ) reste accessible au clavier et affiche un focus visible.
2. Les changements d’état dynamiques (ouverture, fermeture, chargement) sont annoncés via aria-live ou un attribut ARIA adapté, pas seulement visuellement.
3. Le contraste des couleurs par défaut du bloc respecte au minimum le niveau AA du WCAG, y compris quand l’utilisateur applique une couleur personnalisée dans les limites raisonnables de la palette du thème.

Performance

1. Un bloc dynamique dont le rendu dépend d’une requête coûteuse ou d’un appel externe utilise une stratégie de cache adaptée, documentée en commentaire.
2. Aucune dépendance JavaScript volumineuse n’est chargée sur des pages qui n’affichent pas le bloc (vérification via has_block() ou l’usage correct de viewScript/viewScriptModule).
3. Le bundle du bloc a été passé une fois dans webpack-bundle-analyzer si une dépendance tierce nouvelle a été ajoutée depuis la dernière revue.

Déprécations et compatibilité

1. Si le bloc a déjà été modifié structurellement en production, une entrée deprecated couvre l’ancienne version d’attributs, testée avec du contenu réel migré depuis l’ancienne structure.
2. Le bloc a été testé sur la dernière version stable de WordPress annoncée par l’équipe core, pas uniquement sur la version utilisée au moment du développement initial.

Le point 6 de cette liste — l’échappement systématique — reste, année après année, celui qui revient le plus souvent en revue de code chez les développeurs pourtant expérimentés. La pression du planning pousse presque toujours à « faire confiance » à une donnée qu’on pense contrôlée, jusqu’au jour où elle ne l’est plus.

Comment cette checklist s’utilise en pratique

Elle se coche dans le gabarit de pull request du dépôt, avec une case à cocher par point, avant toute demande de revue à un pair. Cela ne dispense pas d’une lecture attentive du code par le relecteur, mais élimine les oublis mécaniques qui n’ont rien à voir avec la qualité de conception du bloc lui-même.

En résumé

Une checklist de revue efficace n’est jamais une liste générique copiée d’un article de blog externe sans adaptation : elle se construit à partir des incidents réellement vécus sur des projets réels, et se met à jour à chaque nouvel incident qui ne figurait pas encore dedans. Ces vingt points reflètent ce que l’agence a appris à la dure, projet après projet, depuis plusieurs années de développement de blocs personnalisés.