Tribulations d’une migration depuis WordPress.com

Depuis quelques temps, la nécessite de renouveler l’infrastructure de mon blog se faisait de plus en plus pressante. Le billet d’aujourd’hui évoque les tribulations autour de cette aventure/galère/pt1cable et la nouvelle infrastructure du blog en espérant que cela puisse servir de leçon à d’autres tentés par l’aventure.

1. Pourquoi

Mon blog était clairement vieillissant. Hébergé chez WordPress.com, il devenait mystérieusement de plus en plus long à charger. Étant un client payant chez WordPress.com, j’étais donc fortement insatisfait du service, mais j’ai mis beaucoup trop de temps à me décider à corriger le problème. Pourquoi ? La raison principale est que j’avais souscrit mon nom de domaine carlchenet.com chez WordPress.com.

Une migration de DNS d’un hébergeur vers un autre ? Rien de plus facile se dit le néophyte. Mais quand tout faire pour compliquer la tâche au client fait qu’il se décourage de partir, c’est donc un outil de monétisation. Et là les ennuis commencent.

2. L’option existe dans l’interface, ça va être simple

Je commence donc à regarder via l’interface d’administration WordPress de mon blog comment transférer ma zone DNS. L’option existe. Cool, ça va être vite réglé. HAHAHA.

Plein de bonnes volontés je suis les différentes étapes indiquées dans leur documentation. À la fin on me signale qu’un e-mail de confirmation va être envoyé à l’adresse de contact de la zone DNS. Ok, envoie.

Une semaine plus tard et tel un poisson rouge, je constate de nouveau la lenteur de mon blog. Je rage de nouveau et je me souviens que j’ai jamais reçu le fameux e-mail. J’enquête donc et constate que j’ai une erreur dans l’adresse e-mail de contact de ma zone DNS. Je corrige via l’interface de WordPress, attend une journée, et redemande l’envoi du fameux e-mail de confirmation de transfert de la zone. Pause pop-corn.

Plusieurs mois plus tard, je pète de nouveau un câble face à la lenteur de mon blog que je commence à délaisser car je n’arrive pas à le faire évoluer. Je plante des couteaux dans une poupée vaudou à l’effigie de WordPress.com et j’ouvre un ticket auprès de leur support. On me recontacte sous 24 ou 48 heures.

24 heures plus tard, la personne du support WordPress.com identifie le problème : il y a une erreur dans l’adresse de contact de ma zone DNS. Merci, c’est en effet l’un des problèmes, mais le principal est que je ne peux pas la changer moi-même. J’en informe cette personne qui me dit qu’elle revient vers moi.

24 heures plus tard, le support m’annonce que l’adresse a été changée. Très bien ! Enfin ! Je me connecte à l’interface pour renvoyer le fameux e-mail contenant le code de transfert.

Plusieurs heures plus tard je reçois l’e-mail en question qui me demande une confirmation de ma volonté d’effectuer cette manoeuvre et le fameux code de transfert. Je commande un transfert de zone chez OVH qui me demande le fameux code et se met en attente du retour du serveur DNS de WordPress.com.

Je reçois un e-mail de WordPress.com qui m’annonce qu’ils sont très tristes de me voir partir (surtout mon abonnement mensuel) et pour me donner un délai de réflexion, vont m’infliger 4 jours d’attente pour annuler au cas où, comme si ça n’était pas déjà suffisamment compliqué comme procédure. Je passe au fusil à pompe sur la poupée vaudou pour prendre mon mal en patience.

4 jours plus tard et la date annoncée dans l’e-mail expirée, j’ouvre une nouvelle demande au support WordPress.com pour leur préciser que, bon, j’ai décidé de me barrer, j’ai confirmé 20 fois, j’en suis à deux demandes de support et ça commence à bien faire, en fait. 24 heures plus tard, sans réponse du support, je reçois enfin la confirmation de transfert de la zone et au même moment la confirmation d’OVH qu’ils ont bien rapatrié ma zone.

L’e-mail final de WordPress.com est hilarant :

Dear Carl Chenet,

We're sorry you transferred your domain name(s) away from WordPress.com.
We are committed to providing quality services and products
and hope that we met your needs.

Tout cela est au final un peu trop long et un peu trop fastidieux.

3. Le nouveau blog WordPress avec un certificat Let’s Encrypt

Sur mon serveur propulsé par une Debian Jessie, j’ai donc installé un blog WordPress en version 4.5.3 avec deux plugins : l’importateur WordPress et WP-Super-Cache. J’ai fait pointer le cache généré par ce plugin vers un tmpfs sur mon serveur afin que le cache du blog soit donc en RAM. Et ça bourrine ! Bien, le principal problème qui a entraîné la migration est donc résolu.

Mon ancien blog WordPress de WordPress.com proposant une fonctionnalité de migration. Migrer les données a donc été un jeu d’enfant. Que ce soit donc bien clair, je n’ai rien à reprocher au moteur de blog WordPress, c’est plutôt avec la société commerciale WordPress.com que j’ai eu du mal.

Niveau certificat SSL et afin d’économiser quelques euros par an, je décidais de mettre en place les certificats Let’s Encrypt avec un renouvellement automatique. Rien de plus facile avec le programme client de Let’s Encrypt certbot présent dans les dépôts officiels backports de Debian. Installer certbot est aussi simple que de taper la commande suivante sur votre serveur :

# apt-get install python-certbot-apache -t jessie-backports

La documentation officielle de Certbot est on ne peut plus limpide et vous est présentée en fonction de votre système d’exploitation et votre serveur Web. Le renouvellement automatique se fait à l’aide d’un cron installé automatiquement et se lançant tous les jours pour vérifier la validité de votre certificat.

4. Les leçons à retenir

Lorsqu’on souscrit à un moteur de blog, la première vérification doit être pour le système d’import/export de vos données. Cela va lourdement vous handicaper si vous souhaitez changer de moteur de blog. Avec WordPress, j’étais tranquille à ce niveau-là.

Ma grande erreur a été de sous-estimer le risque lié à mon nom de domaine. Aveuglé par l’offre faite pour coupler le moteur de blog et le nom de domaine, je me suis retrouvé très dépendant de WordPress.com pour migrer vers un autre système de blog. Il aurait donc fallu souscrire ma zone DNS chez un autre prestataire indépendant de celui gérant le moteur de blog.

Enfin cette aventure a été un grand décrassage pour moi et l’occasion de reprendre sous mon aile une partie de mes données afin de les présenter à l’aide d’un moteur de blog désormais propulsé via mon infrastructure. Et j’espère de vous faire un retour d’expérience avec quelques leçons à en tirer