Une migration WordPress vers Next.js n'est pas une mise à jour de thème, c'est un changement de modèle de publication. Vous échangez la facilité d'installer une extension pour chaque besoin contre un socle plus sobre et plus prévisible, en échange d'une autonomie éditoriale réduite. Voici les trajectoires possibles, les points qui font échouer ce type de projet, et les cas où rester sur WordPress est la décision la plus raisonnable.
Ce qui pousse vraiment à migrer, et ce qui se corrige sans migrer
Personne ne migre pour la beauté du geste. Les demandes que nous recevons se ressemblent : un thème premium acheté il y a des années, puis une extension pour les formulaires, une pour le cache, une pour le SEO, une pour les sliders, une pour la bannière cookies. Chacune charge ses feuilles de style et ses scripts sur toutes les pages, y compris celles qui n'en font aucun usage. Le temps de réponse se dégrade parce que chaque appel traverse le cœur de WordPress et déclenche des requêtes en base que personne ne surveille. Le cache masque le problème sur les pages statiques, pas sur la recherche interne, le panier, ni sur tout ce qui est généré à la volée.
Vient ensuite la charge de maintenance. Une faille publiée sur une extension populaire impose une mise à jour rapide, parfois incompatible avec le thème. Le back-office accumule des menus et des réglages que plus personne n'ose toucher, et modifier une mise en page revient à contourner un constructeur visuel plutôt qu'à écrire du code.
Reste à distinguer ce qui se corrige sur place. Un hébergement sous-dimensionné, des images jamais compressées, des extensions désactivables sans conséquence, une base gonflée de révisions : tout cela se traite sans changer de technologie. La migration ne se justifie que si le frein tient à l'architecture elle-même, pas à son entretien.
Trois trajectoires de migration, trois niveaux d'engagement
La première garde WordPress en back-office et ne remplace que la partie visible. Next.js consomme le contenu par l'API REST ou par GraphQL, et le rendu se fait en génération statique, avec revalidation, ou côté serveur. Les rédacteurs conservent leur interface, leurs habitudes et leurs champs personnalisés. C'est la voie la plus courte, celle qui rassure une équipe éditoriale, mais vous restez tributaire des mises à jour de WordPress et de sa structure de données.
La deuxième extrait le contenu vers un CMS pensé pour le headless. La reprise se fait par script : lecture des articles, des pages, des taxonomies et des champs, conversion du HTML historique produit par le constructeur de pages, réimport des médias. L'essentiel de l'effort se situe dans le nettoyage du contenu, pas dans le transfert lui-même. Les blocs propriétaires laissés par un constructeur visuel ne se convertissent jamais tout seuls.
La troisième est une refonte assumée : on ne reprend que ce qui mérite de l'être, on réécrit le reste, on ferme les pages qui n'ont jamais généré ni visite ni contact. Elle ne se justifie que si l'existant est daté ou pauvre. Le choix se tranche sur des faits : volume de pages réellement visitées, autorité acquise, nombre de personnes qui publient, dépendances métier branchées sur le site.
Extensions et données : ce qui se reprend, ce qui se réécrit
C'est le sujet le plus sous-estimé. Une extension n'est pas seulement une fonctionnalité, c'est aussi un schéma de données. Les entrées de formulaires vivent dans des tables dédiées, les balises de titre et les méta descriptions produites par une extension SEO sont stockées en métadonnées d'articles, les champs personnalisés suivent la convention de l'outil qui les a créés, les traductions dépendent d'un plugin multilingue qui duplique ou relie les contenus selon sa propre logique.
Avant toute ligne de code, il faut dresser un inventaire : quelle extension fait quoi, quelle donnée elle détient, et ce qui se passe le jour où elle disparaît. Certaines fonctions se réécrivent en quelques composants, un formulaire de contact par exemple, avec envoi transactionnel et enregistrement en base. D'autres exigent un vrai remplacement : espace membre, moteur de recherche à facettes, catalogue produit, réservation en ligne, abonnement récurrent. Cas fréquent : une boutique très outillée, avec des extensions de transport, de fidélité et de liaison comptable, ne se transpose pas ligne à ligne. Il faut arbitrer service par service ce qui est repris, ce qui bascule vers un outil spécialisé, et ce qui est abandonné parce que plus personne ne s'en sert.
L'inventaire des URL décide de la réussite ou de l'échec
Le risque n'est pas la redirection en elle-même, c'est l'exhaustivité de la liste à rediriger. Un site WordPress expose beaucoup plus d'adresses que ce que montre son menu : pages de catégories et d'étiquettes, pagination des archives en /page/2/, archives par auteur et par date, flux RSS en /feed/, pages de pièces jointes générées automatiquement pour chaque image, identifiants bruts du type /?p=123 hérités d'un changement de structure oublié. Un inventaire sérieux croise plusieurs sources : le sitemap, l'export des pages de la Search Console, les journaux du serveur sur plusieurs mois, un crawl complet du site et la liste des liens entrants connus.
Viennent ensuite les détails qui cassent en silence : la barre oblique finale présente ou absente, les majuscules dans les anciennes adresses, les paramètres de suivi, et surtout les fichiers servis depuis wp-content/uploads, souvent cités directement par d'autres sites ou affichés dans les résultats images. Chaque règle se teste en préproduction avant la bascule, puis se contrôle après la mise en ligne, code de réponse par code de réponse. Une redirection en chaîne, une boucle, une cible en 404 : rien de tout cela ne se voit en navigation normale, et c'est pourtant ce qui abîme l'indexation.
Ce que vous perdez, et les cas où rester sur WordPress est la bonne décision
Disons-le franchement : après la migration, vous ne réglerez plus un besoin en installant une extension en trois clics. Chaque évolution passe par un développement, une relecture et un déploiement. C'est exactement ce qui rend le site stable dans la durée, et c'est aussi ce qui frustre une équipe habituée à ajuster elle-même. L'écosystème d'extensions prêtes à l'emploi n'a pas d'équivalent côté Next.js, et le nombre de prestataires capables de reprendre le code est plus restreint que sur WordPress.
Trois situations où migrer serait une erreur. Le site tient la charge, il est à jour, et le vrai frein est ailleurs : contenu pauvre, aucune acquisition, offre illisible. Changer de technologie n'y changera rien. Deuxième cas : une boutique dont l'activité repose sur un empilement d'extensions métier, sans personne en interne pour accompagner le changement. Troisième cas : une équipe qui publie beaucoup et qui n'a aucune envie de modifier ses habitudes de production.
Nous préférons le dire avant le devis plutôt qu'au milieu du projet. Tout se traite par écrit, par email, avec une réponse sous vingt-quatre heures ouvrées, depuis Dijon. Le rendu final se juge sur nos réalisations : Chouchou Ribeyre, Au Petit Detail, LB Athletic, Mediavocats, Vectosolve.
