HYPOTHÈSES A MOYEN & LONG TERME

Introduction

Après avoir optimisé le site de l’entreprise dans l’immédiat, je vais détailler dans un premier temps mon test d’isolation du site et de migration de serveur. En effet, ce sont des hypothèses d’optimisation sur le moyen et long terme. Et dans un deuxième temps, je présenterai la refonte du site.

1.        Isolation et Migration d’hébergeur

a. Multisite WordPress

Une des solutions envisagées pour améliorer les performances du site est de l’isoler des autres sites et de le migrer sur un autre serveur* chez un autre hébergeur*.

En effet, la plupart des sites créés avec WordPress* sont des sites uniques mais WordPress* propose également de créer des sites multiples en ajoutant quelques lignes de code. Cela permet de gérer un réseau de sites à partir d’une seule interface. Tous les plugins* et leur gestion sont également accessibles dans une interface unique de réseau et aussi pour chaque site. Un seul thème* peut aussi être déployé pour tous les sites du réseau et être géré sur une seule interface. Au niveau de la base de données*, des tables de données* communes sont créées et des tables* uniques sont conçues pour chacun des sites.

De plus, un superadministrateur gère l’ensemble du réseau de site et peut créer des comptes administrateurs isolés pour chacun des sites. Etant donné que le développeur est le seul à gérer et maintenir à jour l’ensemble des sites du réseau, le multisite* lui a grandement facilité son travail grâce à son interface unique. Cependant, un réseau multisite* comme celui que nous utilisons, comporte aussi des inconvénients importants. Comme tous les sites sont hébergés sur le même serveur*, ils partagent tous la même bande passante*, ce qui peut avoir un impact important sur le temps de chargement des pages si le débit de la bande passante* n’est pas adapté. Si un des sites du réseau créé un bug qui fait crasher le serveur* ou si le serveur* tombe en panne lui-même, tous les sites du réseau tombent en panne.

b. Isolation

L’isolation d’un site parmi un multisite* WordPress* se déroule en plusieurs étapes. En premier, je dois récupérer uniquement les fichiers liés au site. Ensuite, je dois récupérer les tables de la base de données* : celles du site et celles des utilisateurs.

Les fichiers liés au site à récupérer sont les thèmes* (le thème parent* et le thème enfant*), les extensions, les fichiers du dossier « mu-plugins » et les fichiers du dossier « uploads » correspondants au site. Le dossier « mu-plugins » contient des fonctionnalités développées pour un site qui doivent être chargées avant tous les plugins* et conservées en cas de changement de thème*.⁴¹ Le dossier « uploads » contient tous les médias téléversés sur le site qui apparaissent dans la médiathèque.

Dans le cas d’un multisite*, chaque site à son dossier nommé par son identifiant dans le dossier « uploads ».

Les tables de la base de données* se divisent en deux parties. La première partie regroupe les tables* génériques à l’ensemble des sites du multisite*. On y trouve entre autres, les options avec la configuration générale du multisite*, la liste des sites et les utilisateurs. Les deux tables* dans cette partie à récupérer sont les tables* relatives aux utilisateurs : _user et _usermeta. La deuxième partie regroupe les tables* liées au site à isoler. Ces dernières concernent toutes les données du site tel que les pages, les textes, les commentaires, les liens internes et les liens des fichiers médias. 

Avant de faire le moindre changement, j’ai effectué une sauvegarde du serveur*. Puis, je me suis connectée au serveur* en FTP* grâce à l’outil Filezilla* pour créer une copie en local des fichiers. Ensuite, je me suis identifiée sur l’outil MySQL* WorkBench* pour obtenir les tables* de la base de données* que je souhaitais. MySQL* WorkBench* est un outil de gestion et d’administration de base de données* MySQL*. J’avais à ma disposition les fichiers et les données du site de L’entreprise isolés des autres sites et prêt à être utilisés pour la migration*.

c. Migration

Pour réaliser la migration*, nous avons loué un serveur* dédié chez PlanetHoster*^[2]. Sur ce serveur*, je me suis connecté au WHM*, le panneau d’administration du serveur* et j’ai créé un nouvel utilisateur. Ce nouvel utilisateur a accès au cPanel*, le panneau de configuration pour l’hébergement web compris dans notre serveur*. J’ai relié ce compte à un nom de domaine* : turcos-kebab.com que nous avons dans notre stock de nom de domaine* chez Gandi* qui est un bureau d’enregistrement de noms de domaine*. J’ai également créé un certificat SSL*^[3] autosigné pour celui-ci. Le certificat SSL* est un certificat électronique qui sécurise les communications entre les serveurs* web et les navigateurs* grâce au protocole https.

Ensuite, j’ai installé un WordPress* vierge à l’aide du cPanel*. J’ai ouvert tous les fichiers que j’avais exporté du site de l’entreprise avec mon éditeur de code*. J’ai réécrit tous les liens de www.l’entreprise.com en www.turcos-kebab.com. Je me suis connectée au serveur* de fichier du nouveau site turcos-kebab.com via FTP*. Puis, j’ai importé les dossiers et les fichiers avec les nouveaux liens. 

Avant d’utiliser les tables* de la base de données*, j’ai dû réécrire tous les liens www.l’entreprise.com en www.turcos-kebab.com. Pour cela, j’ai voulu utiliser l’outil Search Replace DB* qui automatise la réécriture de données dans un fichier. Mais la spécificité des tables* m’en a empêché. J’ai donc utilisé un simple bloc note et la fonction rechercher et remplacer pour faire cela.

Je me suis connectée à la base de données* du nouveau site turcos-kebab.com avec le gestionnaire de base de données* PhpMyAdmin. J’ai importé les tables* de L’entreprise.com et supprimé les anciennes tables* créés automatiquement par WordPress. J’ai aussi renommé le préfixe des tables* afin qu’il corresponde à celui du site turcos-kebab.

Cela étant fait, je suis retournée sur le site de L’entreprise lister tous les plugins* actifs. J’ai activé sur le site de turcos-kebab le même thème* et les mêmes plugins* que l’entreprise. J’ai ainsi obtenu une première version du site de L’entreprise isolé et migré sur le nouveau serveur*. 

Évidemment, j’ai eu des erreurs qui provenait surtout des liens vers les médias. En effet, dans un multisite*, les médias sont enregistrés dans un dossier uploads puis dans un sous dossier sites et dans un sous dossier avec l’identifiant du site :  www.turcos-kebab.com/wp-content/uploads/sites/3/. J’ai dû réécrire tous les liens en www.turcos-kebab.com/wp-content/uploads. Cela m’a demandé de réexporter les tables*, d’utiliser la fonction rechercher et remplacer du bloc note et de réimporter les tables* dans la base de données*.

J’ai obtenu la même erreur dans les fichiers du thème*. J’ai ouvert les fichiers avec mon éditeur de code* et réécrit les liens de www.turcos-kebab.com/wpcontent/uploads/sites/3/ en www.turcos-kebab.com/wp-content/uploads.

Finalement, j’ai obtenu sur le lien www.turcos-kebab.com une copie exacte du site de www.l’entreprise.com isolée des autres sites et migrée sur un nouveau serveur*. 

d. Résultats

Les résultats n’ont pas été concluants en termes de performances. En effet, de nombreuses variables existent : 

• Le trafic. Je n’avais pas accès à l’époque aux chiffres liés au trafic du site. De plus, je n’avais pas d’outil à ma disposition pour simuler le trafic. 
• Les réseaux sociaux. Les liaisons avec les comptes des différents réseaux sociaux de l’entreprise impliquent un délai de connexion. Je n’avais pas la possibilité de tester ces liens pour deux raisons : Je n’avais pas les accès et cela risquait d’impacter négativement l’image de l’entreprise.
• Les outils d’analyses. Les liaisons avec les comptes des différents outils d’analyses du site de l’entreprise engagent aussi un délai de connexion. Je n’avais pas la possibilité de tester ces liens pour deux raisons : Je n’avais pas les accès et cela risquait de fausser les chiffres du site officiel.

De ce fait, les données liées à la performance du site étant faussées, ils n’ont pas été éloquents. Cependant, j’ai pu établir avec certitude la faisabilité technique de l’isolation et de la migration* du site de L’entreprise.

2.       Refonte du site

À la suite des problématiques de performances du site de L’entreprise, une refonte en gardant le CMS* WordPress* avait été prévue. En effet, les différents intervenants du site sont habitués à l’utilisation de ce CMS* ce qui permet une prise en main rapide du nouveau site. De plus, notre hébergeur* AlterWay* a déjà paramétré le serveur* pour des sites WordPress*. 

Cependant, des changements dans le choix du thème* et du constructeur de page* étaient prévus pour améliorer les performances du site. Nous prévoyions d’utiliser le thème* GeneratePress et le constructeur de page* Elementor. GeneratePress est un thème* créé dans un souci d’optimisation, il est très léger (4,92 Mo) et est considéré comme le plus rapide du marché. Elementor est un constructeur de page* léger (4,82 Mo) avec des modèles déjà prêts et un glisser-déposer du contenu avec un rendu en temps réel. L’ensemble est plus léger (9,74 Mo) et plus performant que l’utilisation du thème* et du constructeur de page* Kleo (53,3 Mo) sans demander beaucoup de temps de prise en main.

Finalement, une refonte fonctionnelle et technique du site www.l’entreprise.com a été décidée et sera effectuée par un prestataire externe. En effet, avant la crise, l’entreprise était composée d’agences en nom propre et de franchises*. La décision de franchiser toutes les agences et d’ouvrir de nouvelles franchises* a été prise. Cela implique de nouvelles fonctionnalités à incrémenter comme un générateur de minisites, site multilingues, marketing automation*, recrutement, live chat, agenda en ligne, intranet* d’animation des franchises*, etc. Nous allons également porter une attention particulière à l’UX et l’UI du nouveau site.

En vue aussi de l’augmentation du nombre d’utilisateurs du site à venir et des problèmes de performance actuels, une refonte du site a été décidée en changeant de technologie. Nous allons profiter de l’opportunité de la refonte pour passer du CMS* WordPress* au Framework* Laravel* toujours basé sur le langage PHP*. 

Pour trouver un prestataire, l’entreprise a rédigé un cahier des charges en collaboration entre l’expression des besoins du service marketing – communication et les possibilités techniques du service informatique. Celui-ci s’est basé sur l’objectif de génération de leads* grâce à un meilleur référencement naturel avec un site optimisé dès sa construction. Aujourd’hui, le nouveau site est en cours de développement par un prestataire extérieur. 

Conclusion

Sur le moyen-terme, l’isolation et la migration* du site de L’entreprise est envisageable mais l’efficacité n’est pas véritablement prouvée à cause des multiples dépendances du site aux autres outils. La refonte du site en changeant de technologie semble la meilleure solution sur le long-terme.