Publiée en mars 2021, WordPress 5.7 a poursuivi la transformation engagée par Gutenberg : l’administration devient plus visuelle, les réglages de contenu sont moins dispersés et certaines opérations techniques, notamment le basculement vers HTTPS, deviennent plus accessibles. La version apporte aussi des améliorations moins visibles pour le référencement, les performances et les développeurs.
Il faut toutefois replacer ces nouveautés dans leur contexte. WordPress 5.7 n’est plus une branche maintenue : un site qui l’utilise encore ne doit pas être « mis à jour vers 5.7 », mais préparé à rejoindre la dernière version stable compatible avec son hébergement, son thème et ses extensions. Connaître ses particularités reste essentiel pour auditer un site ancien ou comprendre l’origine de certains réglages.
WordPress 5.7 : une version charnière, mais désormais ancienne
Le nom de code d’une version WordPress est avant tout un repère ; ce qui compte pour l’administrateur est son périmètre fonctionnel. Avec 5.7, le cœur du CMS reste fondé sur le couple classique : un tableau de bord, des thèmes, des extensions et l’éditeur Gutenberg pour composer pages et articles à partir de blocs. La mise à jour ne bouleverse donc pas l’architecture d’un site, mais affine de nombreuses interactions quotidiennes.
Cette version ne correspond pas encore à l’édition complète du site telle qu’elle s’est développée par la suite. Elle n’offre pas, à elle seule, une liberté totale de conception de l’en-tête, du pied de page ou des modèles de pages. Pour profiter de ses outils, il faut aussi que le thème et les extensions les prennent correctement en charge. C’est une distinction importante : le cœur de WordPress fournit des possibilités, tandis que leur affichage dépend souvent du thème actif.
Un éditeur Gutenberg plus fluide pour produire du contenu
La partie la plus immédiatement perceptible de WordPress 5.7 est l’évolution de l’éditeur de blocs. L’objectif est de réduire les allers-retours entre le panneau latéral, l’inserteur de blocs et la zone de rédaction. Un contributeur peut plus facilement déposer des blocs ou des compositions de blocs dans sa page, réorganiser sa structure et ajuster la présentation sans recourir au code.
Typographie, hauteur et blocs réutilisables
La version étend certains réglages de taille de police, notamment dans les blocs Liste et Code, sous réserve du support proposé par le thème. Les blocs peuvent également exploiter une hauteur pleine dans les contextes compatibles, ce qui aide à construire une section d’introduction occupant l’écran. Ce réglage doit être utilisé avec mesure : une grande zone visuelle peut valoriser une page de campagne, mais ralentit la lecture d’un article informatif sur mobile.
Les blocs réutilisables gagnent en maniabilité. Ils sont utiles pour une signature éditoriale, un encadré légal, un appel à l’action ou une présentation standardisée. Leur intérêt principal est la cohérence : modifier le bloc partagé permet de répercuter le changement partout où il est employé. À l’inverse, il ne faut pas les utiliser pour un contenu qui doit rester différent d’une page à l’autre.
| Fonction | Usage concret | Bénéfice | Point de vigilance |
|---|---|---|---|
| Glisser-déposer de blocs et de compositions | Insérer plus vite une structure de contenu dans la zone d’édition | Moins de manipulations pour les contributeurs | La qualité finale dépend toujours des styles du thème |
| Réglages de taille de texte étendus | Hiérarchiser une liste, une légende ou un extrait de code | Meilleure lisibilité sans CSS manuel | Éviter de multiplier tailles, graisses et couleurs |
| Blocs réutilisables plus accessibles | Partager une mention, une bannière ou un module éditorial | Cohérence sur plusieurs contenus | Une modification peut affecter toutes les occurrences |
| Sections à hauteur pleine | Créer un bandeau d’ouverture ou une page de présentation | Mise en page plus immersive | Contrôler impérativement le rendu mobile |
Le passage à HTTPS simplifié, pas entièrement automatisé
WordPress 5.7 détecte, via l’outil Santé du site, si l’environnement est prêt pour HTTPS. Lorsqu’un certificat SSL valide est déjà installé et que le serveur répond correctement en HTTPS, l’administration peut proposer une action de mise à jour des URL principales du site. C’est une avancée appréciable pour les petites installations qui étaient encore restées en HTTP.
Cette aide ne crée toutefois pas de certificat et ne corrige pas tous les problèmes possibles. Les liens absolus en HTTP présents dans des contenus anciens, les scripts appelés depuis un domaine tiers, les redirections du serveur ou les paramètres d’un outil de mesure peuvent encore générer du contenu mixte. Un cadenas dans le navigateur ne dispense donc pas d’un contrôle complet après bascule.
Avant la fonction de 5.7
- Modification manuelle des adresses WordPress dans les réglages ou dans la base de données.
- Risque plus élevé d’oublier les redirections HTTP vers HTTPS.
- Contrôle technique souvent nécessaire pour identifier les ressources non sécurisées.
Avec l’assistance HTTPS de 5.7
- Détection de la disponibilité HTTPS dans Santé du site.
- Mise à jour guidée des URL principales lorsque le certificat fonctionne.
- Traitement plus simple des références internes, mais vérifications post-migration toujours indispensables.
Performances et référencement : iframes et API robots
Deux améliorations de WordPress 5.7 sont particulièrement intéressantes parce qu’elles agissent en arrière-plan. La première concerne les iframes, couramment utilisés pour intégrer une vidéo, une carte, un formulaire externe ou un contenu social. WordPress peut leur appliquer le chargement différé natif du navigateur, via l’attribut loading="lazy". L’iframe n’est alors chargée qu’à l’approche de sa zone d’affichage.
Le gain est surtout sensible sur une page qui embarque plusieurs contenus externes. Il ne faut cependant pas différer un élément indispensable immédiatement visible, par exemple une vidéo centrale placée en haut d’une page. L’optimisation ne compense pas non plus un lecteur externe très lourd : il faut conserver une politique d’intégration sobre.
La seconde évolution est la Robots API. Elle fournit un cadre unifié pour générer et modifier les directives de la balise meta robots. Les thèmes et extensions peuvent ainsi indiquer de manière plus propre aux moteurs de recherche comment traiter une page : indexation, suivi des liens ou aperçus. Ce mécanisme ne remplace pas une stratégie SEO : il sert à appliquer proprement les décisions éditoriales et techniques.
Ce que WordPress 5.7 apporte aux développeurs
WordPress 5.7 intéresse aussi les équipes techniques, même si ses nouveautés sont moins spectaculaires dans l’interface. Le système de couleurs de l’éditeur s’appuie davantage sur des propriétés personnalisées CSS. Pour un thème, cela facilite la définition d’une palette cohérente et la réutilisation de variables plutôt qu’une succession de codes couleur répétés. La maintenance du design et l’adaptation à un mode sombre éventuel deviennent plus propres.
La version introduit également des méthodes complémentaires autour de l’objet de base de données $wpdb, utiles pour inspecter des tables et leurs colonnes. Elles permettent à une extension de vérifier plus prudemment la structure disponible avant une opération. De nouveaux crochets dynamiques élargissent par ailleurs les possibilités de personnalisation dans certains parcours de l’administration et de l’éditeur.
Enfin, la possibilité de distinguer le type d’environnement, production, préproduction, développement ou local, aide à écrire des comportements plus sûrs. Un script de test, une notification ou un outil de débogage ne doit pas se déclencher de la même manière sur le site public et sur sa copie de travail.
Comment mettre à niveau un ancien site WordPress 5.7 aujourd’hui
La stratégie la plus sûre n’est pas de cliquer immédiatement sur « Mettre à jour ». Un site resté en 5.7 peut dépendre d’un thème abandonné, d’un constructeur de pages ancien ou d’extensions dont les versions récentes exigent un PHP plus moderne. La préparation évite que l’administration reste accessible alors que le formulaire de contact, le paiement ou la mise en page ne fonctionnent plus.
- Inventoriez le thème, les extensions actives, la version de PHP et les services externes : paiement, e-mail, réservation, cache et statistiques.
- Réalisez une sauvegarde restaurable des fichiers et de la base de données, puis créez une préproduction isolée.
- Mettez à jour d’abord PHP si nécessaire, puis les extensions et le thème compatibles ; traitez ou remplacez les composants abandonnés.
- Effectuez la montée de version WordPress sur la préproduction et testez les parcours réels : connexion, recherche, formulaires, panier, paiement et affichage mobile.
- Planifiez le déploiement, gardez un point de restauration et contrôlez les journaux d’erreurs ainsi que les redirections après mise en ligne.
Un site vitrine simple peut souvent être audité et mis à niveau par son propriétaire averti si une sauvegarde testée et un environnement de préproduction sont disponibles. Pour une boutique, un site multilingue, une plateforme de réservation ou un site fortement personnalisé, l’intervention d’un professionnel est généralement plus rationnelle. À titre d’ordre de grandeur, une vérification et une mise à jour basique peuvent représenter quelques heures de travail, souvent autour de 100 à 400 € selon l’état du site ; une migration avec correction de thème, d’extensions et de parcours transactionnels peut aller de 500 € à plusieurs milliers d’euros. Un devis doit détailler les tests, les corrections prévues et le plan de retour arrière.
