12 %, 40 %, 100 % : ce sont les paliers de déploiement progressif qu’un lead technique peut choisir avant de pousser une mise à jour de bloc sur l’ensemble d’un parc de sites qui partagent la même extension. Cette liste s’adresse à qui doit éviter de casser plusieurs sites clients en même temps, pas à la publication d’un bloc sur le répertoire WordPress.org, qui obéit à d’autres contraintes de revue.
Un bloc partagé entre plusieurs sites via une extension commune concentre un risque particulier : la moindre régression touche potentiellement tous les clients d’un coup, le même jour. La checklist suivante fige les points à vérifier avant chaque diffusion, dans l’ordre où ils doivent être traités.
1. Verrouiller la compatibilité du contenu existant
Avant toute chose, vérifier que la nouvelle version du bloc lit correctement le contenu déjà enregistré sur les sites en production. Si la structure du save change, même légèrement, un tableau deprecated doit accompagner la modification pour que WordPress puisse toujours reconnaître les blocs existants au chargement de l’éditeur.
const deprecated = [
{
attributes: ancienSchemaAttributs,
save( { attributes } ) {
return ancienRenduSave( attributes );
},
},
];2. Vérifier la version minimale de WordPress ciblée
Un bloc qui s’appuie sur une fonctionnalité récente, comme un composant stabilisé dans une version précise de @wordpress/components, doit préciser sa contrainte de compatibilité dans l’en-tête de l’extension ou dans block.json via requiresWp lorsque ce champ est pertinent pour le projet. Un site client resté sur une version plus ancienne du cœur ne doit jamais recevoir une mise à jour qui suppose une fonctionnalité absente.
3. Isoler un site témoin avant la diffusion large
Diffuser une mise à jour de bloc directement sur l’ensemble du parc revient à parier que les tests locaux ont couvert tous les cas réels. Un site témoin, si possible celui dont le contenu est le plus divers et le plus ancien, permet d’absorber la majorité des régressions avant qu’elles n’atteignent les autres clients.
- Déployer la nouvelle version uniquement sur le site témoin, en dehors des heures de forte fréquentation.
- Comparer le rendu front avant et après sur un échantillon de pages représentatives du contenu réel.
- Ouvrir l’éditeur sur plusieurs articles anciens pour vérifier l’absence de message d’erreur de validation de bloc.
- Attendre un délai raisonnable, au minimum vingt-quatre heures, avant d’étendre la diffusion.
4. Documenter ce qui change pour les intégrateurs suivants
Un changelog technique, distinct du changelog utilisateur, doit lister précisément les attributs renommés, les classes CSS modifiées et les hooks PHP dont la signature évolue. Cette documentation protège le prochain développeur qui interviendra sur un site du parc, souvent des mois plus tard, sans connaître le détail de la migration.
- Attributs ajoutés, renommés ou supprimés, avec leur valeur par défaut.
- Classes CSS générées par le bloc qui changent de nom ou de comportement.
- Hooks PHP (
add_filter,add_action) dont la charge utile évolue.
5. Prévoir un plan de retour arrière réel
Un plan de retour arrière ne se résume pas à « on redéploiera l’ancienne version » : il suppose de savoir précisément quel numéro de version était en production avant la mise à jour, et de conserver ce paquet accessible. Sans cela, un retour arrière en urgence devient une reconstruction improvisée, bien plus risquée que la mise à jour elle-même.
Une règle simple qui a fait ses preuves : ne jamais diffuser une mise à jour de bloc partagé un jour où personne de l’équipe n’est disponible pour surveiller les premiers signalements. Le moment du déploiement compte autant que son contenu.
En résumé
Diffuser une mise à jour de bloc à travers plusieurs sites clients demande de figer, avant tout envoi, la compatibilité du contenu existant, la version minimale de WordPress ciblée, un site témoin isolé, une documentation claire des changements et un plan de retour arrière réellement exécutable. Cette rigueur ne ralentit pas le développement : elle évite qu’un incident isolé ne devienne un incident généralisé sur l’ensemble du parc.
