Le dernier vendredi avant une livraison, j’ai pris l’habitude de dérouler la même liste sur chaque projet en éditeur de site. Pas parce que je manque de mémoire, mais parce qu’un détail oublié ici se traduit, six mois plus tard, par un appel client affolé après une mise à jour de thème qui a « effacé le site ».
Un site bloc vit dans deux endroits à la fois : les fichiers du thème et la base de données. Tant que les deux ne sont pas synchronisés au moment de la livraison, n’importe quelle opération de maintenance future peut révéler un écart resté invisible. Voici la liste que je déroule, dans l’ordre, avant de rendre la main.
1. Exporter les templates personnalisés vers le thème
Tout template ou template part modifié dans l’éditeur de site depuis sa version du thème est stocké en base (post types wp_template et wp_template_part), en surcouche du fichier original. Avant livraison, j’exporte systématiquement via Outils > Exporter de l’éditeur de site (ou l’extension Create Block Theme, plus fine sur le contrôle des fichiers générés), pour que les fichiers templates/*.html et parts/*.html du thème reflètent l’état réel du site.
2. Vérifier la cohérence entre theme.json et les styles utilisateur enregistrés
Les réglages faits dans le panneau Styles de l’éditeur sont stockés séparément, dans un article du type wp_global_styles, et prennent le pas sur theme.json. Si ce post est perdu ou désactivé (changement de thème, restauration de sauvegarde partielle), le site retombe brutalement sur les valeurs par défaut du thème — souvent très différentes de ce que le client a validé. Réintégrer manuellement les réglages clés dans theme.json avant livraison sécurise ce point.
3. Verrouiller les patterns et blocs qui ne doivent pas bouger
Le verrouillage de bloc (menu à trois points, Verrouiller) empêche la suppression ou le déplacement d’un élément par un utilisateur non averti. Sur un en-tête, un logo ou un bloc de navigation légale, ce verrouillage évite qu’un contenu essentiel disparaisse par un clic malheureux lors d’une future mise à jour de page.
Points à verrouiller en priorité
- Le logo et le bloc de navigation principale.
- Les mentions légales et liens obligatoires du pied de page.
- Les blocs contenant du code de suivi ou d’intégration tierce.
4. Contrôler les droits d’accès à l’éditeur de site
L’accès à l’éditeur de site et aux styles globaux dépend de la capacité edit_theme_options. Sur un site géré au quotidien par un rédacteur ou un chargé de contenu, je vérifie que son rôle ne dispose pas de cette capacité par défaut — sans quoi rien n’empêche une modification malheureuse de la structure du site depuis un compte destiné à la publication d’articles.
5. Nettoyer les patterns et templates de test
Les brouillons de mise en page créés pendant la phase de conception traînent souvent dans la bibliothèque de patterns ou dans la liste des templates personnalisés. Un client qui tombe dessus en explorant l’éditeur s’interroge, à raison, sur ce qu’il peut ou non supprimer. Un passage dans Apparence > Éditeur > Patterns et dans la liste des templates permet de faire le ménage avant remise.
6. Vérifier le comportement de repli de la hiérarchie de templates
Je teste systématiquement les cas limites : une page sans template spécifique tombe-t-elle sur un page.html cohérent ? Un article d’un type de contenu personnalisé retombe-t-il sur single.html ou reste-t-il sur l’index.html générique, souvent trop nu ? Ces trous ne se voient qu’en testant activement chaque type de contenu, pas en naviguant sur les pages déjà créées.
7. Conserver une archive de l’état livré
Un export complet du thème (fichiers + JSON des styles et patterns) archivé à part, hors du dépôt de développement courant, sert de point de référence en cas de litige ou de régression constatée des mois plus tard. C’est aussi ce qui permet de répondre vite à la question « est-ce que c’est nous qui avons cassé ça, ou quelqu’un côté client ? ».
Un site livré sans cette dernière archive, c’est un diagnostic à l’aveugle le jour où quelque chose casse. Cinq minutes à la livraison en évitent des heures six mois plus tard.
Pour aller plus loin
Cette liste ne remplace pas un plan de recette fonctionnelle classique (formulaires, performance, accessibilité) : elle cible spécifiquement les risques propres à l’éditeur de site, là où la frontière entre fichiers et base de données introduit des pièges qui n’existaient pas avec un thème classique entièrement piloté par PHP. Sur un projet récurrent, je la garde sous forme de modèle de ticket, coché point par point avant chaque livraison.
