Cet article prend 14 minutes à lire et comporte 3292 mots.

Première 'Étude de cas' : la refonte de ce blog. Vous le savez, une refonte ne s'improvise pas. Dans cet article, vous me suivez pas à pas depuis la genèse de la refonte jusqu'à sa mise en ligne.

Vous l’avez certai­ne­ment remar­qué, le blog Tout sur WordPress vient de faire peau neuve. Après une refonte début décembre 2018.

Donc à peine de deux mois entre ces deux refontes. Mais cette fois‐ci, ce n’est pas un simple reloo­king.

Certains articles commen­çaient à dater, leur contenu n’était plus d’actualité. Et j’ai remar­qué certains bugs mineurs sur le thème précé­dent, Voice. Oh, rien de bien méchant, mais je suis plutôt perfec­tion­niste.

Quand je dis rien de bien méchant… je suis quand même gentil. J’ai dû reve­nir à PHP 7.2 parce que certaines exten­sions plan­taient en 7.3 (ce n’est pas drama­tique non plus), et le menu pour mobile plan­tait lamen­ta­ble­ment (c’est déjà plus déran­geant). Et tout un ensemble de petits détails qui me faisaient râler à chaque fois que je passais sur le blog.

D’où ma déci­sion d’une refonte complète. Mais une refonte, ce n’est pas l’affaire de cinq minutes, j’en ai déjà parlé sur ce blog.

Voyons donc comment s’est dérou­lée la refonte, depuis la réflexion jusqu’à la mise en ligne.

Cet article ouvre une nouvelle rubrique, les Études de cas. Des cas pratiques, rencon­trés au fil du temps dans mon acti­vité profes­sion­nelle (ou person­nelle). Il y en aura d’autres, déjà en prépa­ra­tion (je les rédige au fur et à mesure de l’avancée d’un projet).

La réflexion

Pourquoi avais‐je besoin de refondre ou de restructurer mon blog ?

A minima, je voulais chan­ger de thème, en raison des bugs dont je vous ai parlé dans l’intro.

En reli­sant certains articles, je me suis aussi aperçu que certaines exten­sions par exemple n’étaient plus main­te­nues. Ou que certains thèmes n’avaient pas été mis à jour depuis près de deux ans. Voire même suppri­més. Une révi­sion s’imposait donc.

Était‐ce le bon moment pour lancer la refonte ?

Deux mois, c’est peu. Une refonte s’imposait-elle vrai­ment ? La déci­sion a été prise assez rapi­de­ment : je n’allais pas patcher le blog, un simple lifting n’ayant pas un grand inté­rêt. Moment ou pas moment… le blog tel qu’il était ne me conve­nait pas, la refonte précé­dente n’avait pas été une réus­site.

J’allais effec­tuer une refonte complète. Thème, exten­sions, contenu…

Qu’est-ce que j’attendais de cette opération ?

En premier lieu, je voulais un blog à jour et qui ne plante pas, tout simple­ment. Plus rapide, plus simple, plus agréable à parcou­rir.

Je voulais aussi me débar­ras­ser de l’ancien éditeur de WordPress, et passer tous mes articles sous Gutenberg. Pour ne pas avoir des exten­sions pour chaque éditeur, celles de l’éditeur clas­sique de WordPress étant appe­lées à ne plus être main­te­nues, à plus ou moins long terme. Pour ne pas avoir un vrai caphar­naüm à gérer aussi.

Entre les exten­sions indis­pen­sables (SEO, sécu­rité, GPRD, gestion de l’administration…), celles pour Gutenberg et celles pour le construc­teur de page, j’en ai déjà une cinquan­taine à gérer. Si je dois en plus gérer celles qui ne servent qu’à main­te­nir en ligne les articles déjà rédi­gés…

De quelles nouvelles fonctionnalités avais‐je besoin pour atteindre mes objectifs ?

En fait, il ne s’agissait pas à propre­ment parler de nouvelles fonc­tion­na­li­tés, j’avais surtout besoin de retrou­ver pour Gutenberg les fonc­tion­na­li­tés que j’avais avec l’ancien éditeur. Pas si simple. J’ai d’ailleurs dû faire l’impasse sur certaines d’entre elles. Je survi­vrai, le blog aussi 😉 Enfin, j’espère !

Et puis… une petite idée, sortie tout droit de je ne sais où, a fait son bout de chemin : j’ai décidé de profi­ter de la refonte pour mettre en ligne mes pres­ta­tions. Donc une boutique en ligne, des abon­ne­ments et une inter­face de réser­va­tion pour le coaching et le déve­lop­pe­ment.

Et quelles sont les fonctionnalités dont je n’avais plus besoin (inutiles ou contre‐productives) ?

En consul­tant mes statis­tiques, je me suis aperçu que la lecture des articles via les Instant Articles de Facebook et au format AMP ne consti­tuait qu’une infime partie de mon lecto­rat, moins de 0,1%. C’est à dire que j’avais à peine une page sur mille consul­tée dans ces deux formats confon­dus.

Par contre, pour chaque page char­gée, je perdais plus de 250ms en temps de char­ge­ment du pixel Facebook.

Exit donc les formats AMP et Instant Articles, exit égale­ment le pixel.

Je ne suis pas un grand commu­ni­quant, ce qui joue proba­ble­ment dans le peu de lecteurs venant des réseaux sociaux. Mais il faut aussi prendre en compte le contenu des articles de ce blog : ce sont des articles tech­niques. Ce que j’ai remar­qué pour mon blog n’est pas une géné­ra­lité, chaque blog a un lecto­rat qui lui est propre, qui a des habi­tudes de lecture bien à lui, en fonc­tion du contenu, de la présence de leur auteur sur les médias sociaux, etc.

Quels sont les points annexes que je peux changer ou améliorer (autant profiter de la refonte) ?

À effec­tuer cette refonte, je voulais aussi me débar­ras­ser de mon construc­teur de page, WPBakery Page Builder, pendant long­temps fourni à titre de bonus par bien des thèmes sur Themeforest. Et passer à Elementor, que j’avais eu l’occasion de tester et d’apprécier sur quelques sites clients et sur ma page perso.

Je ne voulais plus non plus de l’extension de light­box PhotoSwipe Masonry, dont je me servais pour affi­cher en taille réelle mes captures d’écran. Son rendu n’était pas opti­mal, peut‐être en raison d’une incom­pa­ti­bi­lité avec une autre exten­sion, ou d’une inté­gra­tion impar­faite. Les captures d’écran sont lisibles sans qu’on ait à les agran­dir, tant qu’elles ne sont pas inté­grées dans une gale­rie et donc de taille réduite.

De même, je voulais m’affranchir de Yoast SEO, excellent dans son domaine mais dont l’interface me rebu­tait, et qui de plus était truffé de publi­ci­tés pour les produits et les forma­tions Yoast.

Et pour finir, je voulais tout rassem­bler sur le domaine prin­ci­pal, je ne voulais plus avoir à gérer le blog à part. Ou ma page perso à part du blog, c’est comme vous voulez 😉

La rédaction du cahier des charges

Ayant décidé de tout revoir, thème, exten­sions, articles, struc­ture… j’avais besoin d’un crayon et d’une feuille – en fait, j’ai eu besoin d’un stock de papier assez impres­sion­nant !

Finalement, j’ai décidé de ne pas toucher à la struc­ture géné­rale. De chan­ger la caté­go­rie de quelques articles, de les renom­mer, mais rien de bien impor­tant.

Mais j’ai repensé à la migra­tion précé­dente dans laquelle j’avais perdu en réfé­ren­ce­ment à cause de liens morts. J’ai donc pris en compte la redi­rec­tion de chaque page, de chaque article. Et la page d’erreur 404.

J’en ai d’ailleurs profité pour rédi­ger un article sur ce sujet, Gérer l’erreur 404. Et j’ai créé ma page 404 person­na­li­sée. Plus une page d’erreur 410 pour les articles suppri­més. Et enfin, un article pour les erreurs 406 et 418 (du proto­cole HTCPCP).

Avant de passer à la refonte elle‐même, j’ai égale­ment effec­tué une sauve­garde complète du blog en utili­sant Duplicator Pro.

Sauvegarde qui m’a servi à créer un clone pour la phase de refonte, et de sécu­rité au cas où j’oublierais ulté­rieu­re­ment d’effectuer une dernière sauve­garde avant mise en ligne.

Les points essen­tiels défi­nis, je suis passé à…

La refonte

L’heure des choix

Le choix du thème

Premier élément choisi : le thème. Je voulais un thème compa­tible avec Elementor, j’ai hésité entre deux thèmes du dépôt WordPress : OceanWP et Astra.

J’ai donc testé chacun des thèmes avec le site cloné, pour voir quels étaient les points forts et les points faibles de chacun.

Je me suis décidé pour Astra, qui me corres­pon­dait mieux, qui corres­pon­dait mieux à mon projet, et qui était a priori plus exten­sible. Un choix que je ne regrette pas.

Mais la diffé­rence tenait dans un mouchoir. Enfin, un grand quand même. OceanWP, c’est la berline, la fami­liale incre­vable qui véhi­cule la famille (parents, enfants, et même grands‐parents, tant qu’on y est) à bon port de la côte basque à la Moselle.

Astra, c’est une spor­tive, belle, solide, rapide, fiable, mais pas terrible pour rentrer une famille italienne et faire Paris Nice avec.

OceanWP, on peut tout lui deman­der, de s’occuper du blog, de la boutique, du forum et de la commu­nauté, en étant léger, rapide et respon­sive. Bon, il faut pas pous­ser non plus, sans un serveur ad‐hoc, çà risque de ramer un peu beau­coup.

Astra, c’est pas tout à fait la même philo­so­phie. Si tu veux instal­ler les mêmes fonc­tion­na­li­tés, çà va swin­guer, il n’est pas équipé pour. Mais il a d’autres atouts.

Il veut bien tenir la boutique et le blog, mais c’est tout. Enfin, non. Il veut bien s’occuper de e‐learning. Comme quoi…

Et puis, il supporte EDD. Ce n’est pas rien. Peu le font. En plus de WooCommerce. Je devrais essayer de les instal­ler tous les deux, ensemble, histoire de voir si il arrive à les faire tenir dans la même pièce 😉

Astra est conçu un peu à la manière d’un bon frame­work, il supporte les hooks dans tous les sens. En bas, en haut, à droite, à gauche, au centre et au milieu (le centre et le milieu, faut pas confondre, essayez de faire un <div align="middle" valign="center">, rien que pour le fun).

Avec les modèles person­na­li­sés et les en‐têtes de page, on a déjà de quoi s’occuper. Côté person­na­li­sa­tion j’ai l’impression que c’est un cran au dessus d’OceanWP.

Le choix de l’extension SEO

Pour la gestion SEO, j’ai dans un premier temps porté mon choix sur Math Rank, de My Theme Shop. Malheureusement, une des fonc­tion­na­li­tés pour­tant annon­cée n’est pas portée sous WordPress 5 : le choix d’une caté­go­rie prin­ci­pale quand on affecte un article à plusieurs caté­go­ries.

Et c’est parce qu’il y avait cette fonc­tion­na­lité que j’avais opté pour cette exten­sion.

Je me trou­vais donc avec des articles consi­dé­rés comme dupli­qués, et pour le réfé­ren­ce­ment, ce n’est pas terrible. Après avoir testé All in One SEO, j’ai fina­le­ment opté pour une exten­sion bien plus rustique : The SEO Framework. Gratuite pour l’essentiel, et large­ment suffi­sante pour moi.

Les exten­sions SEO n’améliorent en rien la lisi­bi­lité de votre site ou sa visi­bi­lité sur Google, elles vous proposent des sugges­tions allant dans ce sens. À vous de les appli­quer ou d’en faire fi. Et elles vous proposent en sus des outils annexes, comme la possi­bi­lité de défi­nir une caté­go­rie prin­ci­pale, l’insertion des balises open­graph, la créa­tion d’un plan de site (site­map), d’une descrip­tion person­na­li­sée desti­née aux moteurs de recherche… mais ces annexes se trouvent aussi sous forme d’extensions indé­pen­dantes.

Le choix des extensions

Il me fallait égale­ment trou­ver des exten­sions de substi­tu­tion pour celles qui n’avaient pas été mises à jour, qui n’étaient donc pas compa­tibles avec Gutenberg, et dont j’avais un besoin crucial.

En premier lieu, une exten­sion pour affi­cher le code (PHP, CSS…) que je mets en ligne dans les tuto­riels. Et une exten­sion pour les gale­ries d’images. Je ne voulais pas utili­ser celle de Jetpack, qui n’est pas compa­tible par défaut avec PhotoSwipe. Ça, c’était l’essentiel.

J’avais égale­ment besoin d’une solu­tion pour les télé­char­ge­ments offerts, comme le thème enfant de Twenty Seventeen. Là, j’ai fait un compro­mis : j’ai gardé l’extension, compa­tible avec WordPress 5, et pour les liens, je crée des blocs bouton auxquels j’assigne le lien du fichier à télé­char­ger.

Plus facile en effet de trou­ver une exten­sion pour créer un bloc bouton que de trou­ver une exten­sion qui gère les télé­char­ge­ments de pièces jointes et les présente correc­te­ment via Gutenberg.

L’éditeur est jeune encore, contrai­re­ment à ce que son nom pour­rait lais­ser entendre ?… on ne peut pas s’attendre à trou­ver autant de fonc­tion­na­li­tés que pour l’ancien éditeur dans les semaines ou les mois à venir.

L’audit des articles

J’ai passé chaque article en revue pour véri­fier la compa­ti­bi­lité des exten­sions avec la dernière version de WordPress, la dernière date de mise à jour des thèmes dans le dépôt, la perti­nences des infor­ma­tions déli­vrées (en raison de l’intégration de Gutenberg dans le cœur de WordPress par exemple, j’ai décidé de ne plus promou­voir les exten­sions basées sur l’ancien éditeur, même celles régu­liè­re­ment mises à jour).

Le bilan était assez parlant : sur 63 articles publiés, cinq étaient frap­pés d’obsolescence avérée, une quin­zaine avaient des sections complètes obso­lètes, trois pouvaient être impor­tés dans l’article d’origine, lors d’un rema­nie­ment.

L’article sur Jetpack par exemple, datait de 2016, et entre­temps, l’interface avait consi­dé­ra­ble­ment changé. Même si j’avais présenté une partie de ces chan­ge­ments dans un second article, ce n’était pas très clair pour le lecteur. Et ce deuxième article, daté de 2017, n’était plus lui non plus vrai­ment à jour. D’où une réécri­ture complète du premier article, et la suppres­sion du second.

D’autre part, en consul­tant les stats (WordPress et Analytics), j’ai remar­qué que certains articles n’avaient pas reçu une seule visite au cours des six derniers mois, et moins de cinq depuis leur créa­tion.

La refonte elle‐même

Il y avait un travail de titan, comme nous allons le voir.

Le changement de thème et d’extensions

Le thème utilisé me sortait litté­ra­le­ment par les yeux. J’ai donc commencé par ce point. À tant que faire, autant revoir la présen­ta­tion avant de se lancer dans les grands travaux. D’autant que chaque thème a ses dimen­sions d’images, à tant que lancer Regenerate Thunbnails, autant lui four­nir les bonnes infos.

La mise en place d’Astra s’est dérou­lée sans accroc majeur. À noter que j’ai opté pour la version Pro, c’est à dire la version dispo­nible dans le dépôt WordPress plus l’extension Astra Pro en vente sur le site de l’éditeur.

Je me suis ensuite occupé d’installer et d’activer l’ensemble des exten­sions choi­sies. Là, ce n’était pas une partie de plai­sir. Certaines exten­sions ne fonc­tion­naient pas correc­te­ment, ou le résul­tat n’était pas celui que l’éditeur présen­tait dans sa page de démo, ou elles n’étaient pas 100% compa­tibles avec Gutenberg, et pour finir certaines n’étaient pas compa­tibles entre elles.

Mais quelques maux de crâne et quelques litres de café plus tard, j’en suis fina­le­ment arrivé à bout.

Je pouvais passer au plat de résis­tance…

La réécriture des articles

En tout premier lieu, il fallait conver­tir en bloc article par article. Chaque article que j’avais décidé de conser­ver.

Le relire, et appor­ter les modi­fi­ca­tions néces­saires au niveau du texte et des captures d’écran.

Puis passer dans les blocs pour récu­pé­rer le contenu des short­codes et les trans­for­mer manuel­le­ment en blocs.

J’en ai profité pour chan­ger l’Image à la Une de chaque article. Je voulais un site plus aéré, les images étaient tout sauf aérées. Un exemple d’avant / après :

Je ne prétends pas être un artiste, pas même un graphiste correct, je fais comme je peux avec mes compé­tences tech­niques 😐 Ça y est, c’est dit !

J’ai revu les extraits, les perma­liens, le clas­se­ment dans les caté­go­ries, les étiquettes, créé deux pages (pour les erreurs 404 et 410) avant de m’occuper de…

La correspondance pour les moteurs de recherche

Mon blog est réfé­rencé par Google, il était vital que je conserve au maxi­mum l’avantage acquis en termes de SEO.

Pour éviter que les articles suppri­més, et ceux dont j’avais changé la caté­go­rie prin­ci­pale ou le perma­lien ne se trouvent en erreur 404, j’ai utilisé deux exten­sions, Redirection et WP All Import, que je vous présente dans l’article Gérer l’erreur 404.

Je me suis créé un tableau, avec les anciennes URLs et les nouvelles. Pour les articles suppri­més, deux possi­bi­li­tés :

  • Si l’article a été inté­gré dans un autre article, je redi­rige vers cet article.
  • Si j’ai tout simple­ment supprimé l’article, je redi­rige vers la page erreur 410. J’informe ainsi mon lecteur que l’article n’est plus dispo­nible, il peut ainsi soit cher­cher un article simi­laire, soit parcou­rir le blog.

Voilà, j’avais tout fait (enfin, a priori), il restait quand même quelques étapes, dont…

La création des nouveaux contenus

Vous les avez certai­ne­ment pas manqués : ils sont acces­sibles depuis le menu avec l’entrée Prestations, depuis la page d’accueil ou j’affiche un sublime encart (appel à l’action ou Call to Action en anglais), depuis l’encart en bas de la majo­rité des articles.

Call to Action
Call to Action

J’ai person­na­lisé l’apparence de mes pages produit avec Elementor Pro et quelques exten­sions :

Page Elementor / Produit (WooCommerce)
Page Elementor / Produit (WooCommerce)

J’ai créé une page pour les réser­va­tions (plage horaire pour le coaching et jour­née pour le déve­lop­pe­ment) :

Page de réser­va­tion avec Bookly

Et j’en ai profité pour tester (et adop­ter) bon nombre de fonc­tion­na­li­tés inté­grées dans Astra Pro. Ce thème est un vrai régal !

Créer des modèles d’en-tête pour une page spéci­fique, ou une caté­go­rie, ou un type d’article (Post, Page, Custom Post Type) – pour­quoi ne pas person­na­li­ser chaque recoin de ce blog ?

Insérer des bloc avant, après, dans le contenu, avant l’en-tête, dans le pied de page… sur une page ou une caté­go­rie, mais pas avec telle étiquette – je m’en suis donné à cœur joie !

Et j’ai aussi pensé à vous, j’ai rédigé quelques nouveaux articles pour pallier les conte­nus suppri­més. Un sur l’erreur 404, un sur un duo d’extensions bien sympas pour impor­ter et expor­ter tout ce que vous avez sur votre site, celui‐ci, écrit au fur et à mesure de l’avancée du projet.

Et comme j’ai inté­gré Bookly ainsi que WooCommerce et ses add‐ons (WooCommerce Memberships et WooCommerce Subscriptions) dans quelques projets récents, d’autres articles vont suivre.

Les vérifications

Les articles sont réécrits, les nouvelles URL en place, je reprends chaque article, à tête repo­sée, pour revoir son contenu. Je véri­fie chaque règle de redi­rec­tion, pour limi­ter les erreurs éven­tuelles de saisie ou les oublis.

Une première fois, et une seconde le surlen­de­main.

Il me reste à trans­fé­rer vers le site en produc­tion, mais avant, je vais effec­tuer…

Les sauvegardes de sécurité

En fait, j’ai créé deux sauve­gardes : une du blog dans son état actuel, et une du blog tel qu’il appa­raî­tra après la refonte. Si quelque chose se passe mal, je pour­rais remettre en l’état initial rapi­de­ment, effec­tuer des tests complé­men­taires pour trou­ver la source du problème et corri­ger.

Et main­te­nant, c’est le grand jour, c’est…

Le passage en production

Vu que tout a été véri­fié, revé­ri­fié… tout devrait se passer correc­te­ment. Mais bon, vous le savez vous aussi, en prin­cipe, çà ne veut pas dire grand chose. Ce qui compte, c’est le fait.

Et le fait est que non, ça ne s’est pas bien passé. Mais alors pas du tout ?

J’avais effec­tué une première sauve­garde post‐refonte avec UpdraftPlus. Dans la version Pro, payante, il y a une option pour migrer un site complet. Je l’ai déjà utili­sée, et quand il n’y a pas d’accroc, c’est génial.

Mais là, j’ai tenté à trois reprises. À chaque fois, la migra­tion s’est mal passée. À chaque fois, la base de données n’a pas été impor­tée correc­te­ment. Et bien évidem­ment, une fois le crash consommé, la migra­tion s’est arrê­tée. Donc pas d’extraction des fichiers. Nothing. Nenio. Nic. Nimic. Ничего.

Alors j’ai repris mon exten­sion fétiche pour les sauve­gardes et les migra­tions, savoir Duplicator Pro. Plus lourd, plus lent, mais que voulez‐vous, le trac­teur est parfois utile. Plus lourd, plus lent, mais plus puis­sant.

Bref, une heure et une sauve­garde plus tard, j’avais une archive exploi­table de près de 500Mo. Passage en mode console SSH, je vais dans le réper­toire adéquat, une commande bien brute et lourde elle aussi (il n’y a pas de retour possible) : rm -rf *. Moins de 20 secondes pour un réper­toire aussi vide qu’un porte‐monnaie après les fêtes.

Dans Filezilla, j’ai tout simple­ment déplacé l’archive du réper­toire dans le sous‐domaine de déve­lop­pe­ment vers le réper­toire prin­ci­pal de mon site. 3 secondes. Téléchargé puis télé­versé l’installeur (installer.php), lancé la procé­dure, rensei­gné les champs de saisie. En 5 minutes chrono le site était en ligne.

Après la refonte

Voila, le site est effec­ti­ve­ment en ligne, j’ai véri­fié que chaque article soit bien consul­table, que chaque redi­rec­tion fonc­tionne comme il se doit, et à en croire les stats Google Analytics, tout s’est bien passé, en défi­ni­tive !

Et main­te­nant ? Maintenant, j’attends de voir… la nouvelle version va‐t‐elle autant « plaire » (aux lecteurs, et à Google) que la précé­dente ? Les stats me le diront, mais il est encore trop tôt pour le dire – même si j’ai déjà des retours posi­tifs.

En atten­dant, je veille, au cas où je trou­ve­rais une régres­sion sur un point quel­conque (personne n’est à l’abri, et même en véri­fiant et revé­ri­fiant, un oubli n’est pas impos­sible). Je peau­fine ma page d’accueil. Je termine cet article.

Même si quand on blogue, on n’a jamais (vrai­ment) terminé.

Et vous, avez‐vous une expé­rience de refonte à parta­ger ? Et que pensez‐vous de cette nouvelle version du blog (la cinquième en trois ans) ?

Ces articles vous intéresseront aussi…

2 réflexions sur “Étude de cas : refonte d'un blog”

    1. Merci Charlie ! Visuellement l’ancienne version (la v4) n’était pas très diffé­rente. Les temps de télé­char­ge­ments étaient par contre plus longs, et il y avait tant de bugs dus au thème prin­ci­pa­le­ment, que l’expérience utili­sa­teur en était affec­tée.

      Un exemple : sur mobile, le simple fait de cliquer sur le « hambur­ger » du menu rame­nait en page d’accueil. Autrement dit, pas de navi­ga­tion possible. Plutôt ennuyeux… D’où le choix d’un thème plus léger et plus fiable.

      Ceci‐dit, plus j’avance dans le déve­lop­pe­ment de mon thème enfant (i2019), plus j’ai envie d’en habiller mon blog. La v6 n’est pour­tant pas au programme, mais qui sait ?

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *