transfert et migration d'un site statique vers un site dynamique • Ali Kinaze

Ces deux dernières semaines ont été assez intenses. Il a fallu que je termine le débogage du nouveau site de l’UQAR et que je prépare la migration de l’ancien site statique vers le nouveau site dynamique. Je reparlerai éventuellement de ce projet, car j’en suis bien fier. Pour l’instant, je veux partager le processus de migration de l’ancien site vers le nouveau gestionnaire de contenu, que j’ai débuté, en bon québécois, pendant la fête du Canada et dans lequel je serai encore pendant quelque temps. L’ensemble du portail universitaire que j’ai déménagé comportait environ 10 000 pages. Ce n’est pas si gros que ça, mais c’est assez pour m’avoir permis d’apprendre plein de notions intéressantes sur le SEO et sur les bonnes pratiques à mettre en place pour migrer un site Web. Si jamais vous êtes aux prises avec un mandat similaire, voici quelques considérations à ne pas oublier pour vous assurer que la gestion du changement soit la plus fluide possible.

Comprendre les enjeux de la migration

Dans le cas de la migration du site de l’UQAR, j’ai dû faire face à quelques enjeux principaux.

De nouvelles adresses dans une nouvelle architecture informationnelle

Premièrement, j’ai restructuré l’architecture informationnelle du site de fond en comble afin de favoriser l’expérience des utilisateurs et pour maximiser la visibilité du site sur les moteurs de recherche. Il faudra sincèrement que je trouve du temps pour reparler de ce processus et de faire quelques études de cas comparant l’avant du après, car il y a beaucoup de travail qui restera invisible et qui tombera dans l’habitude. Pour l’instant, il faut retenir que j’ai raccourci la plupart des URL afin qu’ils soient le plus accessibles possible et qu’ils ne soient pas enfouis dans des niveaux trop éloignés de la racine du site. En bon français, ça veut dire que www.uqar.ca/programmesFormation/campus/levis/index.asp est devenu www.uqar.ca/etudes/levis/ ou que www.uqar.uquebec.ca/programmesFormation/description/prg/7705.asp est devenu http://www.uqar.ca/programmes/description/7705.htm.

Un site sur de multiples domaines

Le site de l’UQAR est en fait plus de huit sites. Le domaine uqar.ca est différent du domaine uqar.qc.ca est différent du domaine uqar.uquebec.ca est différent du domaine wer.uqar.qc.ca est différent du domaine w3.uqar.ca est différent du domaine uqar.uquebec.qc.ca, etc. Même si les internautes voient la même chose lorsqu’ils accèdent à www.uqar.ca/communications et www.uqar.qc.ca/communications, Google et tous les autres moteurs de recherche pensent en fait que ce sont 2 sites, ce qui est très problématique, car ça dilue la notoriété de la marque sur le Web. Il fallait donc choisir une seule porte d’entrée pour le site et tout rediriger le trafic des autres portes d’entrée vers celle-ci.

uqar.ca, uqar.qc.ca et uqar.uquebec.ca

Pages introuvables et redirections

Puisque ça fait des années que le site de l’UQAR possède la même architecture informationnelle et qu’il comporte plusieurs portes d’entrée, Google et les autres engins de recherche sont habitués de le trouver le site de l’UQAR à ces adresses précises. Or un site est sur le Web comme une maison est dans une ville. Si vous déménagez du jour au lendemain et que vous changez d’adresses, plus personne ne pourra vous trouver, à mois que vous leur dites que vous avez changez d’adresse. Il était d’autant plus important que le changement d’architecture informationnelle soit imperceptible pour les utilisateurs du site, qu’il soit perceptible pour les moteurs de recherche. D’une part, il faut éviter que des internautes arrivent à l’ancienne adresse et qu’ils se fassent dire que la page n’existe plus (erreur 404). D’autre part, il ne faut pas oublier de dire aux moteurs de recherche qu’une ancienne page a été déplacée de façon permanente à une autre adresse (redirection 301).

Passer d’un site statique à un site dynamique

L’information du site n’était pas contenue dans une base de données. Quand je dis que j’avais 10 000 pages à transférer, c’est que j’avais véritablement 10 000 fichiers physiques à déplacer. Je ne pouvais pas injecter une ligne de code en passant par le gestionnaire de contenu ou, mieux encore, directement par la base de données.

Un nouveau serveur

L’ancien site était hébergé sur un serveur IIS et le nouveau site est hébergé sur un serveur Apache. L’ancien langage de programmation était du asp et le nouveau langage est du PHP. Pour compliquer les choses, plus de 3000 des pages à relocaliser étaient des fichiers .html sur lesquelles il serait impossible d’injecter du code PHP ou asp.

Mettre la switch à off

Avant d’aller plus loin, il faut mettre une chose au clair. Bien sûr vous pouvez éviter de vous casser la tête, et tout simplement fermer l’interrupteur du jour au lendemain et espérer que les gens ne vous appelleront pas et qu’avec le temps, l’inertie retombera et les habitudes reprendront le dessus. Le problème avec cette solution qui a la beauté d’être toute simple, est qu’elle vous fait perdre toute la notoriété que vous aviez difficilement acquise avec le temps. Le temps est en effet un des facteurs clés dans l’indexation d’un site sur les moteurs de recherche. Si ça fait 15 ans qu’un site existe à une adresse précise sur un domaine spécifique et que vous purgez cette adresse du jour au lendemain, c’est aussi problématique que si vous décidiez de faire un feu de joie avec des milliers de dollars en guise de papier d’allumage. D’autant plus que vous perdez du même coup tout les liens entrants vers votre site (backlinks).

Trop peu d’entreprises comprennent la valeur de leurs actifs digitaux. Encore moins, savent comment utiliser ces actifs pour maximiser en maximiser les retombées. Too bad.

Concevoir une stratégie

Une fois que les enjeux sont bien définis, il faut concevoir une stratégie de transfert de site. Dans mon cas, après avoir pris le temps de réfléchir – il faut toujours prendre le temps de réfléchir – j’ai décidé d’y aller pour une stratégie toute simple.

L’adresse principale du site serait uqar.ca. Plus court. Plus facile à retenir. Plus rapide à écrire.
Les 10 000 pages du nouveau site de l’UQAR seraient déployées sur le domaine uqar.ca pendant que les anciennes pages du site seraient toujours accessibles sur les anciens domaines du site, le temps de faire toutes les redirections permanentes.
De façon graduelle, des redirections permanentes seraient faites sur toutes les pages de l’ancien site sur l’ancien serveur de façon à ce que les internautes se voient proposer les nouvelles pages du site sur le nouveau serveur et que les moteurs de recherche comprennent que les adresses des pages ont été déplacées de façon permanente vers une nouvelle adresse. Cette étape est très importante et elle nécessite le déploiement d’une tactique particulière.
Pendant que toutes les pages sont redirigées, il faudra s’assurer qu’il n’y a pas trop de pages introuvables et faire les redirections nécessaires quand il y a lieu. Cette étape est très intéressante et elle permet de poser un nouveau regard sur l’utilisation de Google Analytics ou de tout autre solution de Web Analytics (dans mon cas Majestic SEO).
Préparer les règles de redirection particulières sur le nouveau serveur afin de s’assurer que les internautes ne tombent pas dans le vide lorsqu’assez de temps se serait écoulé pour déconnecter définitivement l’ancien serveur.
Communiquer avec les responsables des sites d’ou proviennent les principales sources de trafic référent afin de s’assurer que leurs liens pointent désormais sur les nouvelles adresses.

J’en suis encore rendu à l’étape 4 de cette stratégie. Ce qui veut dire que j’ai encore 2 sites qui roulent en même temps et que je dois m’efforcer de rediriger tout le jus de notoriété de l’ancien site vers le nouveau site.

Préparer la communauté

S’il y a une chose que j’ai retenue de mon cours de Système d’information organisationnel est l’importance de préparer une communauté à un changement des technologies de l’information. Si, avec recul, je pense que j’aurais dû impliquer davantage les édimestres du site dans le processus de mise en place du nouveau gestionnaire de contenu du site de l’UQAR, je pense que j’ai fait un bon travail pour préparer la communauté universitaire à la migration et au changement de la plateforme technologique pour gérer l’information de son portail institutionnel.

Mais il ne faut pas oublier que dans la vie, comme au hockey, il y aura toujours des insatisfaits qui verront le verre à moitié vide plutôt que de le voir à moitié plein lorsque surviennent les problèmes techniques. C’est la vie, comme diraient les Anglais. Deal with it.

Concevoir une tactique

Une stratégie de migration de site Web, c’est bien. Mais la mise en place d’une tactique de migration c’est encore mieux. Dans mon cas, quelques petits détails à retenir qui pourraient peut-être vous être utiles un de ces jours – surtout si vous êtes arrivé ici en cherchant des termes comme « comment migrer un site Web », « bonnes pratiques pour la relocalisation d’un site Web », « processus de transfert d’un site Web », etc. En fait, c’est peut-être tout ce qui vous intéresse. Le fameux copier/coller. Un teaser pour vous satisfaire.

Le script de redirection à mettre sur toutes les pages du serveur IIS

Ce script sert à dire aux robots des moteurs de recherche que votre site à été déménagé de façon permanente à une nouvelle adresse. De plus, les internautes qui arrivent sur votre site à partir de l’ancienne adresse se verront proposer automatiquement la nouvelle page.

< %@ Language=VBScript%>
< %Response.Status="301 Moved Permanently" Response.AddHeader "Location" , "http://www.uqar.ca/" %>

La génération automatique du script pour toutes les pages du site

Ce script est bien pratique, mais il faut quand même créer des milliers de pages qui le contiennent, dont le nom des fichiers est exactement le même que celui des anciennes pages et qui sont localisées dans la même architecture informationnelle que l’ancien site. Ce processus est assez long. Et même si un programmeur peut créer un script pour automatiser une partie du processus, il faut quand même prendre le temps de répertorier toutes les anciennes adresses du site et leur équivalence sur le nouveau site. Cet exercice peut être réalisé sur un simple fichier Excel, mais je préfère de loin Google Docs pour le travail d’équipe. Voici un exemple d’un tel fichier.

Veuiller noter que plus vous vous appliquez à standardiser la saisie de ces adresses (toujours mettre l’extension finale, ne pas ajouter de commentaires, etc.) et plus vous vous assurez de minimiser les bogues dans la réécriture des adresses et ainsi minimiser les erreurs 404 des pages introuvables.

Le remplacement des anciennes pages par des nouvelles pages

Deux philosophies pour ce processus. Le remplacement automatique ou bien le remplacement manuel. J’ai opté pour le remplacement semi-automatique. J’ai décidé de remplacer les fichiers en passant d’un répertoire à l’autre. C’est beaucoup plus long que de tout remplacer en même temps, mais ça me permettait de faire un dernier contrôle des fichiers qui étaient remplacés. Y avait-il exactement le même nombre d’anciens fichiers que de nouveaux fichiers? Si oui, tant mieux. Sinon, pourquoi? Des fichiers importants avaient-ils été oubliés? Le script d’automatisation avait-il manqué quelques lignes? Avait-on oublié de répertorier certains répertoires?

La redirection des fichiers html sur IIS

Le script de redirection à mettre sur toutes les anciennes pages du site pour signifier à Google qu’une page a été déplacée de façon permanente à une autre adresse fonctionne seulement sur des pages qui comporte l’extension .asp. Que faire avec les anciens fichiers .html qu’il faut aussi rediriger?

Plusieurs tactiques peuvent être envisagées. Dans mon cas, j’aurais pu utiliser un meta refresh sur chaque page HTML, mais ce n’était pas l’idéal car j’avais au moins 3000 pages HTML et ça m’aurait pris trop de temps à réaliser ce mandat.

<META<br /> HTTP-EQUIV="Refresh"<br /> CONTENT="5; URL=redirige-vers-nouveau-url.html">

J’aurais bien pu analyser quels sont les pages qui sont les plus importantes pour mon SEO, c’est-à-dire quelles sont les pages qui m’amènent les meilleurs liens et me concentrer sur celle-ci, mais selon les recommandations de Terry Van Horne, j’ai décidé d’opter pour une autre tactique. En gros, nous avons concocté un code pour la page d’erreur 404 par défaut du serveur IIS afin de transformer l’erreur 404 sur les fichiers html, en redirection 301 vers des centres stratégiques (hubs) du nouveau site.

Simple, mais il fallait y penser, d’autant plus que nous étions aux prises avec l’infrastructure dont nous avions hérité.

Le script .htaccess à mettre sur les pages du serveur Apache

Je n’ai pas encore terminé cette phase. N’hésitez pas à communiquez avec moi (kinaze @ gmail.com) afin de recevoir ce fichier dès qu’il sera complété.

Migrer le site

En terminant, un petit mot pour dire que le transfert d’un site Web, ce n’est pas sorcier. Mais, pour reprendre l’expression d’un bon ami, « It’s one hell of a ride », surtout lorsque vous êtes peu familier avec l’exercice et que vous vous apercevez que du jour au lendemain, vous avez perdu tout le trafic et la notoriété que vous aviez accumulée pendant de longues années. Ne sous-estimez pas l’importance de parler à un professionnel afin de vous éviter bien des problèmes que vous ne pensiez même pas que vous pouviez avoir. Pour mieux comprendre comment transférer votre site Web en toute tranquillité, n’hésitez pas à communiquer avec moi. Je ne suis pas un expert dans ce domaine, mais je ne suis pas non plus un vendeur d’huile à serpent. Et je sais m’entourer des bonnes personnes.