Migrer un site Drupal vers WordPress avec un freelance

Comment migrer un site Drupal vers WordPress avec un freelance : plan de transition des contenus et des fonctionnalités

Migrer un site de Drupal vers WordPress ne consiste pas simplement à transférer des pages. Les sites Drupal s’appuient souvent sur des types de contenu, des taxonomies, des champs, des permissions et des modules qui n’ont pas d’équivalent direct dans WordPress. Si ces éléments sont négligés, le nouveau site peut sembler terminé alors que les filtres de recherche ne fonctionnent plus, que les crédits des auteurs ont disparu ou que les fichiers multimédias ne sont plus associés à leur contenu.

Un freelance peut prendre en charge le travail, mais le projet exige aussi que le propriétaire du site prenne des décisions claires. Pour préparer la migration d’un site Drupal vers WordPress, dressez l’inventaire des contenus, repérez les fonctionnalités réellement utilisées et convenez des différences entre les deux systèmes après la mise en ligne. Si vous faites appel à un freelance pour migration Drupal vers WordPress, fournissez-lui ces éléments afin qu’il puisse établir un plan de migration vérifiable, plutôt qu’une consigne vague du type « tout transférer ».

1. Associer les types de contenu Drupal aux structures WordPress

Commencez par répertorier les types de contenu Drupal et les champs associés à chacun. Un article d’actualité peut comprendre un titre, un résumé, un corps de texte, un auteur, une date de publication, un sujet et une image principale. Une fiche produit peut comporter d’autres champs et être liée à une catégorie ou à un fournisseur. Le freelance a besoin de cet inventaire avant de choisir les structures WordPress.

Les nœuds Drupal peuvent être convertis en articles ou en pages WordPress classiques, mais certains contenus méritent un type de publication personnalisé. Par exemple, un répertoire d’organisations doté de ses propres archives et champs de profil sera généralement plus clair sous la forme d’un type de publication « Organisation » que d’un ensemble de pages ordinaires. Selon leur utilisation, les taxonomies peuvent devenir des catégories WordPress ou des taxonomies personnalisées. Un tableau de correspondance champ par champ permet de visualiser ces décisions.

Ne partez pas du principe que des champs portant le même nom ont le même comportement. Un champ Drupal qui accepte plusieurs valeurs peut nécessiter une configuration WordPress différente de celle d’un champ ne stockant qu’une seule valeur. De même, une date enregistrée avec un fuseau horaire peut nécessiter une règle de conversion explicite. Fournissez des exemples de valeurs inhabituelles pour que le freelance puisse les tester au lieu de faire des suppositions.

Intégrez également les URL au tableau de correspondance. Si un article Drupal se trouve actuellement à l’adresse /news/community-update, décidez si WordPress conservera ce chemin ou le redirigera vers une nouvelle adresse. Un tableur indiquant le type de contenu source, la structure de destination, les champs, les règles de taxonomie et le traitement des URL servira de référence aux deux parties pendant les tests.

2. Décider quoi reconstruire, remplacer ou abandonner

Les modules Drupal répondent souvent à des besoins précis. Reproduire une fonctionnalité visible ne suffit pas si le processus qui la sous-tend est important. Dressez la liste des modules et fonctions personnalisées utilisés par le site, puis indiquez qui dépend de chacun. Un espace de connexion pour les membres, un circuit d’approbation éditoriale et une recherche à facettes peuvent nécessiter trois solutions WordPress différentes.

Répartissez chaque élément dans l’une de ces trois catégories : à reconstruire dans WordPress, à remplacer par un outil disponible ou à abandonner. Par exemple, un ancien calendrier d’événements sans événements à venir n’a peut-être pas besoin d’être transféré. Un répertoire public encore consulté quotidiennement peut nécessiter une solution de remplacement avec des champs de recherche. Un processus d’approbation personnalisé peut demander du développement si la nouvelle configuration éditoriale ne permet pas de reproduire les étapes requises.

Demandez au freelance de décrire la solution envisagée et ses limites pour chaque fonctionnalité conservée. Si une solution de remplacement modifie les personnes autorisées à modifier le contenu ou la façon dont les visiteurs le trouvent, consignez ce changement avant le début du développement. « Fonctionne comme Drupal » ne constitue pas un critère de validation utile ; « les rédacteurs peuvent soumettre un article pour révision sans le publier » en est un.

Distinguez les fonctions indispensables des préférences. Cela aide à maîtriser le périmètre lorsqu’un module Drupal n’a pas d’équivalent direct et permet au propriétaire d’approuver un processus plus simple. Pour des conseils plus généraux sur le choix entre un prestataire indépendant et une équipe, consultez faut-il engager un freelance.

3. Préparer un échantillon représentatif pour la migration

Avant de transférer l’ensemble de la base de données, demandez au freelance de migrer un petit échantillon comprenant différents types de contenu. Une page simple permet de tester les champs élémentaires et les URL. Un article utilisant de nombreuses taxonomies permet de vérifier les affectations de termes et leur hiérarchie. Un contenu riche en médias permet de tester les fichiers image, les légendes et les contenus intégrés. Si le site comporte un type de contenu particulier, incluez-en au moins un exemple.

L’échantillon doit être assez important pour révéler différents cas, mais suffisamment réduit pour que le propriétaire ou le rédacteur puisse examiner chaque élément. Convenez des contenus sources à utiliser et de ce qui constitue un résultat « correct » pour chacun. Par exemple, l’article choisi peut devoir conserver son auteur d’origine, deux sujets, une date de mise à jour et une pièce jointe téléchargeable.

Comparez le résultat dans WordPress à la source Drupal, et pas seulement à une maquette. Vérifiez que le contenu peut être modifié, que les filtres de taxonomie renvoient les éléments attendus et que les médias apparaissent au bon endroit. Une page peut sembler correcte alors que ses termes sont absents de la base de données. Corriger la correspondance après un échantillon coûte bien moins cher que de découvrir la même erreur sur des milliers d’entrées.

Demandez au freelance de consigner les problèmes rencontrés pendant le test et les modifications apportées en conséquence au tableau de correspondance. Ce document constituera la première version des notes de migration et évitera qu’une passation ultérieure repose uniquement sur des souvenirs.

4. Définir des règles pour le nettoyage des contenus et la passation éditoriale

La migration est un mauvais moment pour prendre des décisions éditoriales sans les consigner. Convenez à l’avance du sort des brouillons obsolètes, des pages en double, des valeurs de champ non prises en charge et des contenus à réviser. Une règle pratique pourrait consister à migrer par défaut les contenus publiés tout en conservant les brouillons dans une liste de révision distincte ; le choix dépend du processus de publication du site.

Il faut désigner clairement la personne responsable des doublons. Le freelance peut signaler les entrées dont les titres ou les URL sont identiques, mais c’est à un rédacteur de décider s’il faut les fusionner, les supprimer ou les conserver. Deux pages Drupal aux titres similaires peuvent contenir des informations différentes ; un nettoyage automatique risquerait alors de supprimer des éléments utiles. Tenez un registre des décisions indiquant l’URL source, l’action retenue et le rédacteur responsable.

Définissez également une règle pour les médias intégrés. Certains contenus Drupal peuvent renvoyer vers des fichiers stockés à un ancien emplacement ou intégrer une vidéo au moyen d’un code obsolète. Décidez si le freelance doit copier le fichier, remplacer l’intégration ou signaler le contenu pour révision éditoriale. Les valeurs de champ non prises en charge doivent être signalées, et non supprimées sans avertissement : une valeur manquante peut avoir des conséquences sur un produit, un profil ou une mention légale.

Convenez de qui vérifiera la copie migrée et de la manière dont les exceptions lui seront transmises. Par exemple, le freelance peut fournir un tableur recensant les contenus auxquels il manque une image, puis le rédacteur peut fournir des remplacements avant la mise en ligne. Une passation bien définie sépare le travail technique de migration de la validation éditoriale.

5. Valider les données migrées au-delà des contrôles visuels

Un examen visuel permet de repérer les problèmes de mise en page, mais ne peut pas confirmer que tous les champs et toutes les relations ont été correctement transférés. Comparez les entrées Drupal et WordPress pour les titres, le corps du texte, les valeurs des champs, les affectations de taxonomie, les auteurs, les horodatages et les associations avec les médias. Choisissez des vérifications adaptées au modèle de contenu du site au lieu de vous limiter à la page d’accueil.

Dans la mesure du possible, utilisez des exports ou des requêtes de base de données pour comparer le nombre d’entrées et certains champs. Si 240 événements Drupal doivent être transférés, le rapport de migration doit rendre compte des entrées correspondantes dans WordPress ou préciser les exclusions. Ne partez pas du principe que le nombre est identique sans le vérifier. Si le total final n’est pas encore connu, indiquez qu’il reste à vérifier au lieu d’inventer un chiffre cible.

Testez également les relations dans l’interface WordPress en ligne. Ouvrez une archive de taxonomie et vérifiez qu’un article associé à un terme y apparaît bien. Consultez une archive d’auteur si les auteurs interviennent dans la navigation. Ouvrez plusieurs contenus riches en médias et vérifiez que les images ou les pièces jointes sont associées aux bonnes entrées, et pas seulement que les fichiers existent quelque part dans la médiathèque.

Décrivez les exceptions avec suffisamment de détails pour pouvoir les traiter : identifiant source, URL de destination, problème, responsable et statut. Une note comme « certaines images ne sont pas les bonnes » est difficile à résoudre. En indiquant l’article concerné et l’image manquante, vous donnez au freelance et au rédacteur une tâche concrète.

6. Planifier la bascule en tenant compte des changements de contenu

Les contenus peuvent continuer à évoluer pendant que le freelance prépare WordPress. Avant le début de la migration, choisissez entre un gel des publications et une procédure de transfert des dernières modifications. Avec un gel, les rédacteurs cessent de publier dans Drupal pendant une période convenue, le temps d’effectuer le transfert final et les vérifications. Avec une procédure de mise à jour différentielle, le freelance importe d’abord les contenus, puis transfère les entrées créées ou modifiées depuis cette première importation.

Un gel est plus simple à expliquer, mais il peut perturber une rédaction ou une organisation très active. Un transfert des dernières modifications permet de continuer à publier, mais nécessite un moyen fiable d’identifier les entrées modifiées et d’éviter les doublons. Demandez qui suivra les changements, quand aura lieu la dernière importation et comment seront vérifiées les mises à jour effectuées pendant la bascule.

Préparez une liste de contrôle de mise en ligne comprenant des étapes précises : importation finale terminée, pages prioritaires vérifiées, redirections testées, formulaires soumis avec succès et responsables des contenus informés. Si un élément critique échoue, définissez s’il faut retarder la mise en ligne ou si une solution de contournement a été approuvée. Cette décision doit être prise avant la pression du jour du lancement.

7. Finaliser les accès, la documentation et la préparation au retour arrière

Au moment de la passation, vérifiez que le freelance a livré les scripts de migration, le tableau de correspondance des champs, le registre des exceptions et les instructions nécessaires à l’exécution d’une éventuelle importation finale. Demandez des notes sur les types de publication personnalisés, les taxonomies, les tâches planifiées et toute étape manuelle dont une personne chargée de la maintenance aura besoin. Sans instructions, un script peut être difficile à réutiliser si le site nécessite une correction plusieurs mois plus tard.

Vérifiez également les accès aux comptes. Supprimez les comptes temporaires ou réduisez les permissions qui ne sont plus nécessaires, et changez les identifiants s’ils ont été partagés pour la migration. Désignez une personne responsable de l’administration WordPress afin que le site ne dépende pas de l’ancien identifiant personnel d’un prestataire.

Être prêt à revenir en arrière signifie disposer d’une copie restaurable du site Drupal et savoir qui peut la restaurer si le nouveau site rencontre un problème grave lors de son lancement. Convenez de l’emplacement de la sauvegarde, de la personne chargée de la restauration et des conditions qui déclencheraient un retour arrière. Ne supprimez pas l’ancien site dès que WordPress est en ligne : conservez-le jusqu’à ce que les vérifications convenues soient réussies et que l’équipe ait confirmé que les contenus importants et les processus fonctionnent comme prévu.