Besoin d’un site WordPress fiable et bien pensé ?
Création, refonte, optimisation, sécurité, performances : je conçois des sites WordPress professionnels, rapides et faciles à administrer.
WordPress 6.9 apporte une grosse vague de nouveautés fonctionnelles (Notes, nouveaux blocs, API Abilities, IA, performances, accessibilité…) et corrige plusieurs centaines de bugs par rapport à la version 6.8.3. C’est une mise à jour majeure qui touche autant l’éditeur que le cœur, les performances, les APIs et le socle IA.
Dans cet article, je fais le tour des évolutions du CMS et vous présente mes recommandations pour une mise à jour en toute sécurité.
1. Collaboration et expérience d’édition

1.1. Notes au niveau des blocs
Il est désormais possible d’ajouter des notes directement sur chaque bloc dans l’éditeur, avec réponses, résolution, modification et suppression des notes. Des notifications sont envoyées par e‑mail à l’auteur de l’article quand une nouvelle note est ajoutée, ce qui structure le workflow de relecture/contenu.
1.2. Palette de commandes partout dans l’admin
La Command Palette devient disponible dans l’ensemble du tableau de bord (éditeur, Site Editor, écran des extensions, etc.). Elle permet de déclencher rapidement des actions fréquentes (navigation, création de contenu, accès aux réglages) via le clavier, améliorant la productivité pour l’édition au quotidien.
1.3. Glisser‑déposer en direct
Le drag‑and‑drop a été amélioré, avec déplacement direct des blocs dans la vue de contenu sans passer par un handle externe. L’objectif est de rendre l’agencement des mises en page plus naturel, notamment pour les utilisateurs non techniques.
2. Nouveaux blocs et évolutions de blocs

2.1. Nouveaux blocs ajoutés
- Bloc Math pour afficher des formules (support MathML et rendu LaTeX), utilisable en bloc dédié ou en inline dans les contenus enrichis.
- Bloc Term Query pour interroger/afficher des termes de taxonomies, afin de construire des listes de catégories, étiquettes, etc. sans code.
- Bloc Comment Link (lien vers les commentaires) et bloc Comment Count (compteur de commentaires) pour mieux contrôler l’affichage des infos de discussion.
2.2. Bloc Accordéon (Accordion)
Un nouveau bloc permettant de créer des contenus repliables, personnalisables en style, a été ajouté, utile pour FAQ et sections d’infos condensées. Il intègre les contrôles de blocs classiques (typographie, couleurs, etc.) et bénéficie des améliorations globales de l’éditeur.
2.3. Améliorations de blocs existants
- Blocs Titre et Temps de lecture enrichis, notamment autour de la personnalisation et du rendu dans les modèles.
- Correction d’un problème de spécificité CSS sur le bloc Titre avec arrière‑plan pour que les réglages de padding n’impactent plus d’autres blocs utilisant des titres.
2.4. Typographie et fitText
Une nouvelle option typographique FitText pour Paragraph et Heading a été ajoutée, qui ajuste automatiquement la taille de police pour remplir son conteneur. Idéal pour bannières, call‑to‑action ou titres très visuels sans devoir gérer manuellement les points de rupture.
3. Visibilité des blocs et iframe de l’éditeur

3.1. Contrôle de visibilité des blocs
Un nouveau système de visibilité a été mis en place, permettant de masquer/afficher un bloc sur le front tout en le conservant dans l’éditeur. Pratique pour préparer des sections non publiées, tester des variantes de mise en page ou stocker du contenu en réserve.
3.2. Préparation de l’éditeur en iframe
- L’éditeur de contenu se prépare à fonctionner entièrement dans une iframe à l’horizon WordPress 7.0.
- Le schéma block.json n’autorise plus que apiVersion 3 pour les nouveaux blocs/modifications, avec avertissement console pour les blocs en apiVersion 1 ou 2 afin de pousser les développeurs à migrer.
3.3. Nouvel outil de traitement de blocs
WP_Block_Processor a été introduit pour scanner des documents HTML, analyser/ajuster la structure de blocs sans toucher au texte. Cela permet de convertir du HTML en arbre de blocs ou en JSON d’attributs, utile pour migrations, imports ou traitements avancés.
4. APIs et cœur (développement)

4.1. API Abilities (nouvelle)
Un nouveau registre unifié a été intégré, pour déclarer des “abilities” (fonctionnalités) de site dans un format standard exploitable par le cœur, les extensions et l’IA. Ces abilities sont accessibles via PHP, REST et des agents IA, ce qui constitue la base pour l’automatisation et l’orchestration par IA.
4.2. API Interactivity
- Gestion standardisée d’identifiants uniques pour les directives d’interactivité afin d’éviter les conflits quand plusieurs directives similaires coexistent.
- Amélioration de la gestion des scripts/styles, support des “router regions” à l’intérieur d’éléments interactifs, et nouveau paramètre attachTo pour cibler le parent à enrichir côté rendu.
4.3. API HTML
WP_HTML_Processor::serialize_token()devient publique, permettant des traitements HTML plus sûrs dans des flux complexes.set_modifiable_text()rejette désormais les contenus d’éléments SCRIPT susceptibles de casser la fermeture normale, renforçant la robustesse.
4.4. API Block Bindings
- UI améliorée pour passer d’une source de binding à une autre, attacher/détacher les attributs de bloc en un clic.
- Nouveau filtre
block_bindings_supported_attributes_{$block_type}pour contrôler précisément quels attributs d’un bloc sont bindables.
5. Données, vues et formulaires dans l’admin

5.1. API Field mise à jour
10 nouveaux types de champs ont été ajoutés, ainsi que 11 contrôleurs de type edit pour la validation, plus de 16 opérateurs de filtre, et une option readOnly. Cela donne davantage de possibilités pour les interfaces de filtres/listings avancés dans le back‑office.
5.2. DataViews et DataForms
Les vues de données (DataViews) bénéficient d’évolutions : amélioration des modales, des actions textuelles, ajout du défilement infini, et construction de layouts avec children. Les vues deviennent persistantes et sont gérées via le paquet @wordpress/views, tandis que le panneau DataForms, les layouts card/row et les validations sont améliorés.
6. Performances, cache, base de données

6.1. Optimisations front & Core Web Vitals
- Amélioration notable du LCP (Largest Contentful Paint) grâce au chargement des styles de blocs “on‑demand” pour les thèmes classiques, à la minification des styles de thèmes de blocs et l’augmentation de la limite de styles inline.
- Le chemin de rendu critique est allégé en dépriorisant des scripts non essentiels (blocs interactifs, détection d’émojis), et la stabilité de mise en page (CLS) est améliorée, notamment via le bloc Vidéo.
6.2. Requêtes & cache
- Optimisation des requêtes SQL et de la gestion du cache, avec une nouvelle logique pour les clés de cache des Query Groups dans
WP_Query. - De nouvelles fonctions liées au cache sont introduites pour que hébergeurs et développeurs tirent parti de ces changements.
6.3. CRON, tampon de rendu et autres
- Améliorations de la gestion du CRON WordPress pour plus de fiabilité des tâches planifiées.
- Nouveau “template enhancement output buffer” qui ouvre la voie à d’autres optimisations de rendu auparavant impossibles.
7. Accessibilité et internationalisation

7.1. Accessibilité (core & éditeur)
- Plus de 30 améliorations/corrections côté accessibilité dans le cœur, et 10 améliorations + 23 corrections côté a11y sont mentionnées dans la field guide.
- Meilleures annonces pour les lecteurs d’écran, meilleure sémantique, focus clavier plus fiable et filtrage du contenu généré via CSS pour ne pas polluer les technologies d’assistance.
A lire : Optimisez l’accessibilité de votre site web pour booster votre SEO
7.2. Modernisation UTF‑8
Un nouveau “fallback” en PHP pour la gestion d’UTF‑8 a vu le jour, rendant le traitement du texte indépendant de l’environnement serveur. Cela apporte plus de cohérence d’encodage entre environnements, utile pour les thèmes et extensions manipulant du contenu internationalisé ou des émojis.
8. E‑mail, URL, HTTPS et admin

8.1. Amélioration de wp_mail() et e‑mails HTML
wp_mail()gère mieux l’adresse d’expédition, renforce la protection des en‑têtes, et s’appuie davantage sur PHPMailer pour les types de contenus.- Support des images inline/embarquées via
cid:dans les e‑mails HTML, ce qui permet d’envoyer des newsletters ou notifications avec images locales sans liens externes.
8.2. Fonctions d’échappement d’URL
esc_url(), esc_url_raw() et sanitize_url() peuvent être configurées pour préfixer automatiquement https:// quand aucun schéma n’est présent et que “https” figure dans $protocols. Cela renforce la cohérence vers HTTPS pour les sites configurés en full‑https.
8.3. Recherche dans le menu d’admin
La requête de recherche du menu d’administration passe de $_SERVER['QUERY_STRING'] à $_GET. Le comportement est ainsi plus prévisible et moins sensible aux query strings complexes, nécessitant une adaptation pour les extensions qui surchargent cette recherche.
8.4. Fin du support IE conditionnel
- Suppression du chargement conditionnel de scripts/styles pour Internet Explorer dans le cœur et les thèmes par défaut.
- Nettoyage du code lié aux commentaires conditionnels IE et ajustements autour de Genericons dans les thèmes qui l’utilisaient.
9. IA, SDK et intégrations avancées

9.1. SDK PHP pour outils IA
- Nouveau client PHP pour intégrer facilement des outils IA dans des extensions ou projets PHP autour de WordPress.
- Le SDK fonctionne avec plusieurs fournisseurs d’IA, permet de déclarer les capacités, de choisir modèles/fournisseurs, et centralise les identifiants d’accès.
9.2. Adaptateur MCP (Model Context Protocol)
WordPress 6.9 intègre un nouvel adaptateur MCP qui normalise les échanges entre WordPress et les LLM via le protocole MCP. WordPress peut agir comme serveur et client, exposer ses abilities à des assistants IA et se connecter à d’autres serveurs MCP pour exploiter leurs outils.
10. Support PHP et compatibilité

10.1. Support PHP 8.5 (beta)
WordPress 6.9 ajoute un support beta pour PHP 8.5, avec correction des incompatibilités connues, avertissements et notices. Les anciennes versions (jusqu’à PHP 7.2) restent supportées, mais les versions peu déployées (moins de 10% des sites) sont considérées comme “beta support”.
10.2. Autres évolutions du cœur
- Divers changements sur les médias, le multisite, de nouveaux hooks/filters/classes/méthodes documentés sur la référence développeur.
- De nombreuses petites améliorations de l’éditeur et du cœur viennent compléter cette version.
11. Corrections de bugs

11.1. Volumétrie globale des corrections
- Plus de 400 tickets Trac cœur résolus, dont environ 125 améliorations/nouvelles fonctionnalités et plus de 250 corrections de bugs dans le core.
- Côté éditeur (projet Gutenberg), environ 440 améliorations et 570 corrections de bugs sont intégrées à WordPress 6.9.
11.2. Types de bugs corrigés
- Éditeur : corrections sur navigation des sous‑menus du bloc Navigation, ajustement de la barre d’outils pour le mode sombre, nouveaux blocs ajoutés, nombreux correctifs d’UI et de comportement.
- Accessibilité : corrections sur les sous‑menus du bloc navigation, remplacement d’anciennes règles CSS speak/aural, notifications et focus améliorés.
- Performance : nombreux tickets sur optimisation des requêtes, cache, template buffer, chargement conditionnel des scripts/styles.E‑mail & wp_mail() : résolutions de bugs anciens liés aux en‑têtes, types de contenus, et meilleure gestion globale des envois.
- Divers : corrections sur l’API HTML, l’API Interactivity, les fonctions d’URL, le multi‑site, et d’autres composants du core.
12. Recommandations avant et après mise à jour vers WordPress 6.9

12.1. Vérifier la configuration serveur
Confirmer la version de PHP
- Viser au minimum la version de PHP officiellement supportée en “non bêta” par WordPress 6.9 (au moment de la sortie, PHP 8.1+ est la base raisonnable, avec un support bêta pour PHP 8.5).
- Vérifier également la version de MySQL/MariaDB, la mémoire allouée à PHP (
memory_limit), le temps d’exécution (max_execution_time) et la taille maximale d’upload, pour éviter les timeouts pendant la mise à jour.
Vérifier les thèmes, extensions et compatibilités
- S’assurer que le thème actif et les plugins critiques (builder, SEO, e‑commerce, cache, sécurité) annoncent explicitement une compatibilité WordPress 6.9 et, idéalement, ont été mis à jour récemment.
- Si possible, tester d’abord la mise à jour sur un environnement de staging/local en reproduisant la configuration de production (mêmes versions de PHP, thème, plugins).
12.2. Sauvegarde complète avant mise à jour
Sauvegarder fichiers et base de données
- Effectuer une sauvegarde intégrale du site : fichiers (core, wp-content, uploads, mu-plugins, wp-config.php, .htaccess/nginx.conf) et base de données complète, même si l’hébergeur fait déjà des backups automatiques.
- Documenter où est stockée la sauvegarde et tester si possible une restauration en staging, pour éviter la mauvaise surprise d’un backup inutilisable en cas de problème.
Utiliser un plugin de sauvegarde si besoin
- Pour les petites structures ou lorsque l’accès serveur est limité, utiliser un plugin de backup tel qu’UpdraftPlus ou WPvivid pour générer un snapshot complet avant de cliquer sur “Mettre à jour”.
- Planifier ce backup juste avant la mise à jour de WordPress, et idéalement figer les contenus (pas de grosses opérations éditoriales) pendant la fenêtre de maintenance.
12.3. Tests approfondis après mise à jour
Vérifier les fonctionnalités critiques
- Tester systématiquement : formulaires de contact, tunnel e‑commerce (commande complète), recherche, espace membre, zones de contenu dynamique, intégrations tierces (CRM, newsletter, paiement, etc.).
- Contrôler le front sur les principaux templates (accueil, archive, article, page, landing clés) pour repérer d’éventuelles régressions de mise en page ou de bloc (notamment avec les nouveaux comportements de blocs de WordPress 6.9).
Surveiller les performances et les erreurs
- Lancer au moins un audit de performance (PageSpeed, WebPageTest…) avant/après la mise à jour pour vérifier que les optimisations de WordPress 6.9 n’ont pas été annulées par un plugin ou un thème.
- Vérifier les logs PHP/serveur et la console navigateur (erreurs JS, 404 de scripts/styles, appels API) pour détecter les soucis discrets qui n’apparaissent pas forcément à l’écran.
12.4. Prévoir et gérer le rollback
Préparer le plan de retour en arrière
- Avant de mettre à jour, définir clairement le scénario de rollback : méthode de restauration (via l’hébergeur, via un plugin de backup, via WP‑CLI), qui s’en charge et dans quels délais acceptables.
- Noter la version exacte de WordPress et des plugins avant mise à jour, afin de pouvoir revenir sur un ensemble cohérent si nécessaire.
Procéder au rollback en cas de problème
- Si une régression majeure est constatée (perte de commandes, formulaires HS, backend inutilisable), restaurer sans attendre la sauvegarde complète la plus récente, plutôt que de “bricoler” en production.
- Après rollback, tester les mises à jour sur un environnement de test pour identifier le conflit (plugin, thème, version PHP) et planifier une nouvelle tentative de mise à jour avec correctifs (patch plugin, changement de thème, ajustement PHP).










0 commentaires