Les migrations de pages se planifient. Les migrations de documents se découvrent. Quelque part dans la troisième semaine d’une refonte, quelqu’un lance une exploration sérieuse et constate que le site ne fait pas quatre cents pages, mais quatre cents pages et neuf mille PDF, et qu’une part significative de la visibilité de l’organisation en recherche se trouve dans des fichiers que personne n’a regardés depuis leur téléversement.
C’est la norme pour les municipalités, les universités, les établissements de santé, les associations et toute organisation qui publie des rapports. C’est aussi la portion d’une migration la plus susceptible de provoquer une baisse visible de trafic, parce que les documents se positionnent, les documents reçoivent des liens externes, et les documents sont presque toujours déplacés en dernier et avec le moins de soin.
Pourquoi les documents ne se comportent pas comme les pages
Quatre différences commandent tout le reste.
- Ils sont indexés pour eux-mêmes. Un PDF est un document à part entière, avec son propre positionnement, ses propres liens entrants et son propre trafic d’entrée. Déplacer la page qui y mène ne le déplace pas.
- Leurs liens vivent hors de votre site. Les rapports sont cités dans les pages d’autres organisations, dans des articles de presse, dans des références universitaires et sur papier. Ces liens ne peuvent pas être corrigés.
- Personne n’en est responsable. Une page a un auteur qui travaille encore chez vous. Un document d’appel d’offres de 2016, non.
- Ils portent un passif d’accessibilité. Les PDF non balisés sont la raison la plus fréquente pour laquelle un site autrement conforme échoue à un audit, et la migration est le moment où ce passif devient visible.
L’inventaire d’abord, et plus que le nom de fichier
Explorez le site et extrayez la liste des fichiers du serveur, puis réconciliez les deux. Elles vont diverger, et l’écart est instructif : les fichiers présents sur le serveur vers lesquels rien ne pointe sont orphelins, et les fichiers liés mais absents sont déjà brisés.
Pour chaque document, consignez l’URL actuelle, la taille, la date de dernière modification, les pages qui y mènent à l’interne, l’existence de liens entrants externes, les impressions et les clics des douze derniers mois, et si le fichier est balisé. Ce dernier champ est généralement celui que personne ne possède, et c’est celui qui détermine le coût de la phase suivante.
L’inventaire est un livrable, pas une note de travail. C’est contre lui que vous réconcilierez à la fin, et c’est lui qui vous protège quand on vous demande au sixième mois pourquoi tel fichier n’est plus là.
Triez selon des preuves, pas selon l’intuition
Une fois l’inventaire en main, classez chaque document dans l’une de quatre catégories :
- Déplacer tel quel. Actuel, utilisé, et déjà balisé ou inscrit au calendrier de correction.
- Convertir en page. Les documents qui n’auraient jamais dû être des documents. Une grille tarifaire de deux pages, des heures d’ouverture, un formulaire qui pourrait être un formulaire. Ce sont les conversions les plus rentables, parce qu’une page HTML est accessible, indexable, lisible sur mobile et modifiable, et que le PDF n’était rien de tout cela.
- Archiver. Doit rester repérable pour des motifs de conservation, sans devoir figurer dans la navigation ni dans l’index.
- Retirer. Remplacé, dupliqué, ou sans trafic ni lien ni obligation de conservation.
La deuxième catégorie est celle du véritable gain. Il est courant qu’un cinquième d’une bibliothèque documentaire soit du contenu publié en PDF uniquement parce que c’était plus simple pour l’auteur. Convertir ces fichiers fait la différence entre une migration et une amélioration.
La quatrième catégorie exige un approbateur nommé. Retirer du contenu est une décision de gouvernance, et la personne qui l’autorise ne devrait pas être celle qui exécute la migration.
Donnez de vraies URL aux documents
La plupart des bibliothèques documentaires portent des URL façonnées par l’outil qui les a téléversées : un répertoire daté, un chemin d’exportation, un nom de fichier contenant un numéro de version. Une migration est votre seule occasion de corriger cela, et la correction vaut la peine parce qu’une URL de document lisible est un signal de pertinence et de confiance, exactement comme une URL de page lisible.
Quel que soit le schéma retenu, tenez deux règles. Un seul saut de redirection de l’ancienne vers la nouvelle adresse, jamais une chaîne. Et un chemin stable qui n’encode pas l’année du téléversement, pour que la version de l’an prochain du même rapport n’ait pas besoin d’une nouvelle adresse.
Scriptez le déplacement
Neuf mille fichiers ne se déplacent pas à la main, et c’est dans la tentative que les erreurs entrent. Scriptez le transfert, scriptez la génération des redirections à partir de l’inventaire, et scriptez la vérification. Une migration scriptée peut être exécutée sur un environnement de préproduction, vérifiée, corrigée, puis réexécutée. Une migration manuelle ne peut pas être rejouée, ce qui rend chaque erreur permanente et chaque correction manuelle à son tour.
La carte de redirections devrait être générée depuis l’inventaire plutôt qu’écrite séparément. Si les deux sont tenues par des personnes différentes dans des fichiers différents, elles divergeront, et la divergence se manifeste en erreurs 404 après la mise en ligne.
Réécrivez les liens internes
Les redirections maintiennent les liens externes fonctionnels. Elles ne constituent pas une réponse permanente acceptable pour vos propres liens. Un site qui dépend de sa table de redirections pour sa navigation interne est plus lent, plus difficile à auditer, et à une migration de serveur près de perdre la table entièrement.
Réécrivez chaque référence interne pour pointer directement vers la nouvelle adresse, y compris les liens à l’intérieur d’autres documents dont les fichiers sources existent encore. Puis explorez de nouveau et confirmez qu’aucun lien interne ne passe par une redirection.
Réconciliez, puis prouvez-le
Le rapport de réconciliation est ce qui transforme une migration d’une affirmation en un fait. Chaque ligne de l’inventaire initial devrait aboutir à exactement l’une de ces situations : déplacée et vérifiée à une nouvelle URL, convertie en une page nommée, archivée à un emplacement déclaré, ou retirée avec un approbateur nommé. Aucune ligne ne devrait rester sans explication, et le décompte du rapport devrait correspondre à celui de l’inventaire.
Puis exécutez les vérifications qui attrapent ce que la réconciliation laisse passer : appelez chaque ancienne URL et confirmez une redirection en un seul saut vers un fichier vivant, explorez le nouveau site à la recherche de liens brisés et de chaînes de redirections, et confirmez que les nouvelles URL de documents figurent dans votre plan de site.
Surveillez les bons chiffres ensuite
La réindexation des documents est plus lente que celle des pages : résistez donc à l’envie de juger le résultat dès la première semaine. Suivez la baisse des impressions des anciennes URL pendant que montent celles des nouvelles, et confirmez que le total reste à peu près stable. Surveillez les erreurs d’exploration et le nombre de documents indexés. Attendez-vous à un creux. Attendez-vous à ce qu’il se résorbe sur plusieurs semaines.
Ce qui doit inquiéter, ce n’est pas un creux temporaire, mais un total qui ne revient jamais à son point de départ. Cela remonte presque toujours à une chaîne de redirections, à une règle manquante pour un répertoire, ou à un lot de documents qui a discrètement échoué au transfert. Les trois se trouvent dans le rapport de réconciliation, et c’est la raison d’en produire un.
Nous menons les migrations documentaires de cette façon et remettons l’inventaire, la carte de redirections, le rapport de réconciliation et le rapport d’exploration avec le site. Notre page migration de contenu et de données détaille le processus.