J'ai migré mon 47e site WordPress la semaine dernière

J'ai migré mon 47e site WordPress hors de WordPress la semaine dernière. La règle de décision qui ne m'a jamais échouée : si vous passez plus de temps à combattre WordPress qu'à construire des fonctionnalités, partez.

Je sais que ça semble réducteur. Mais après des années de construction sur WordPress — et des années à retirer des projets de WordPress — j'ai réduit la question « devrais-je rester ou devrais-je partir » en quelque chose de plus structuré. Un cadre à cinq questions qui vous donne une réponse honnête et quantifiable. Pas de vibes. Pas de fidélité tribale envers PHP ou React. Juste une checklist qui correspond aux vrais points de friction.

Laissez-moi vous le présenter, puis nous parlerons de où aller, ce que ça coûte, et les erreurs qui saboteront votre migration si vous ne faites pas attention.

Table des matières

Le cadre à 5 questions : devrais-je quitter WordPress ?

J'ai utilisé ce cadre avec des clients, avec mes propres projets, et avec des équipes de développement évaluant leur pile. Cinq questions oui ou non. Chacune cible une catégorie spécifique de problèmes WordPress — surcharge de plugins, coût, sécurité, performance et vélocité.

1. Avez-vous plus de 20 plugins actifs ?

Vingt est le nombre magique. Pas parce qu'il y a quelque chose de magique là-dedans, mais parce que c'est le seuil où WordPress cesse d'être un CMS et devient un monstre de Frankenstein tenu ensemble par des crochets add_filter et la prière.

Chaque plugin est une dépendance que vous ne contrôlez pas. Chaque mise à jour de plugin est un changement potentiellement cassant. Et en 2026, l'écosystème de plugins WordPress a un problème de sécurité difficile à ignorer : Patchstack a signalé plus de 11 300 CVE de plugins en 2025 seul, une augmentation de 42% par rapport à l'année précédente. Plus de plugins signifie plus de surface d'attaque.

Allez compter vos plugins actifs maintenant. Je peux attendre.

Si vous êtes à 30+, vous exécutez presque certainement des plugins qui dupliquent les fonctionnalités, qui entrent en conflit les uns avec les autres, ou qui existent uniquement parce que WordPress ne fait pas nativement quelque chose que les frameworks modernes gèrent directement — des choses comme l'optimisation des images, la mise en cache, les balises SEO méta, ou la gestion des formulaires.

2. Payez-vous plus de 100 $/mois pour l'hébergement géré ?

WordPress est un logiciel « gratuit » qui coûte miraculeusement une fortune à héberger correctement. Si vous êtes sur WP Engine, Kinsta ou Flywheel, vous payez probablement 30-115 $/mois pour un seul site. Mettez cela à l'échelle de 5-10 sites et vous regardez 300-600 $/mois.

Pendant ce temps, un site généré statiquement sur Vercel ou Netlify ? Le plan gratuit gère la plupart des sites marketing. Même une configuration CMS headless + Next.js sur Vercel Pro est 20 $/mois. Ce n'est pas une comparaison pommes-à-pommes (WordPress inclut une base de données, une interface d'administration, etc.), mais c'est justement le point — vous payez pour une infrastructure dont vous n'avez peut-être pas besoin.

Si votre facture d'hébergement vous fait grimper, c'est un signal.

3. Avez-vous été piraté ou avez-vous eu un temps d'arrêt au cours des 12 derniers mois ?

C'est une question binaire et elle compte plus que la plupart des développeurs ne l'admettent. WordPress alimente ~40% du web, ce qui en fait la cible unique la plus importante pour les attaques automatisées. Tentatives de connexion par force brute, injection SQL via des plugins obsolètes, logiciels malveillants injectés via des thèmes nullifiés — j'ai tout vu.

Si vous avez été piraté, vous connaissez la procédure : scan Sucuri, nettoyage de base de données, rotations de mot de passe, panique des clients. Si vous avez eu un temps d'arrêt parce qu'une mise à jour de plugin a cassé votre site à 2 h du matin, vous connaissez aussi ce sentiment.

Les sites statiques modernes et les applications rendues côté serveur sans panneau d'administration public n'ont tout simplement pas cette surface d'attaque. Il n'y a pas de /wp-admin à forcer brutalement. Il n'y a pas de xmlrpc.php à exploiter. Le modèle de sécurité est fondamentalement différent.

4. Vos Core Web Vitals échouent-ils sur mobile ?

Les Core Web Vitals de Google sont des enjeux pour le SEO en 2026. Et les sites WordPress luttent constamment ici. Une analyse HTTP Archive 2025 a montré qu'environ 71 % des origines WordPress n'ont pas réussi l'évaluation du CWV mobile — par rapport à des taux de réussite significativement meilleurs pour les sites construits sur des frameworks comme Next.js et Astro.

Le coupable ? CSS bloquant le rendu depuis les thèmes et les plugins. Images non optimisées servies sans formats modernes. Taille DOM excessive depuis les page builders. JavaScript qui n'était pas nécessaire en premier lieu. Vous pouvez jeter des plugins de mise en cache sur le problème, mais vous traitez les symptômes, pas les causes.

Exécutez votre site via PageSpeed Insights. Si votre LCP mobile est au-dessus de 2,5 secondes et votre CLS échoue, WordPress lui-même pourrait être le goulot d'étranglement.

5. Votre équipe veut-elle expédier les fonctionnalités plus vite que WP ne le permet ?

C'est la question qui compte le plus pour les équipes d'ingénierie. Le modèle de développement de WordPress — modèles PHP, la boucle, les crochets et les filtres, l'API de bloc Gutenberg — est une façon spécifique de construire. Ce n'est pas mauvais. Mais c'est lent comparé au développement basé sur les composants avec React, Vue ou Svelte.

Si votre équipe passe plus de temps à :

  • Combattre l'architecture React-mais-pas-vraiment de l'éditeur de blocs
  • Écrire du PHP personnalisé pour contourner les limitations du thème
  • Déboguer les conflits de plugins après les mises à jour
  • Attendre l'invalidation du cache de page complète

...que de construire réellement des fonctionnalités que vos utilisateurs veulent, c'est votre réponse.

Les frameworks modernes vous permettent d'expédier plus vite. Ce n'est pas une opinion — c'est la physique. Les architectures basées sur les composants avec rechargement de module à chaud, TypeScript et contenu piloté par API battent la boucle de développement WordPress sur la vitesse d'itération à chaque fois.

Évaluer vos réponses

Voici la matrice de décision. Simple à dessein :

Réponses oui Recommandation Justification
0-1 Restez sur WordPress Vos problèmes sont gérables. Optimisez ce que vous avez.
2 Restez, mais planifiez Commencez à prototyper les alternatives. Vous approchez du point de basculement.
3 Commencez à migrer La douleur est réelle et elle ne disparaîtra pas. Commencez à planifier votre départ.
4-5 Partez maintenant WordPress vous coûte activement du temps, de l'argent et de la sécurité. Priorisez la migration.

J'ai appliqué ceci à probablement 60+ projets à ce stade. Ça ne m'a jamais donné un faux positif. Les clients qui ont marqué 3+ et sont restés sur WordPress ? Ils sont revenus 6-12 mois plus tard, et la migration était plus difficile et plus chère à ce moment-là.

Vers où migrer (mappé par cas d'usage)

C'est où la plupart des articles « quitter WordPress » s'écroulent. Ils vous diront d'utiliser Next.js pour tout, ou ils listeront 15 options de CMS sans vous dire laquelle correspond à votre situation. Soyez précis.

Sites marketing et blogs

Stack recommandée : Astro + un CMS headless (Sanity, Storyblok ou Contentful)

Astro a été essentiellement conçu pour remplacer WordPress pour les sites de contenu. Il expédie zéro JavaScript par défaut, génère du HTML statique et supporte l'hydratation partielle pour les composants interactifs. Vos scores lighthouse passeront de « décevant » à « parfait » du jour au lendemain.

Nous construisons beaucoup de ces sites chez Social Animal — nos capacités de développement Astro sont fortement orientées vers exactement ce chemin de migration. Combinez Astro avec Sanity Studio et vos éditeurs de contenu obtiennent une meilleure expérience de création que WordPress ne les a jamais donnés.

E-commerce

Stack recommandée : Next.js + Shopify (headless) ou Medusa.js

Si vous exécutez WooCommerce, vous connaissez déjà la douleur. WooCommerce est puissant mais fragile sous charge, lent sans une sérieuse infrastructure de mise en cache, et cher à personnaliser. L'API Storefront de Shopify avec un frontend Next.js vous donne la fonctionnalité de panier, la caisse et la gestion de l'inventaire sans exécuter votre propre base de données.

Pour les équipes qui veulent le contrôle total et l'auto-hébergement, Medusa.js a considérablement mûri en 2026 et vaut la peine d'être évalué.

Applications web (tableaux de bord, portails, SaaS)

Stack recommandée : Next.js (App Router) + CMS headless pour les sections de contenu + votre propre API

Si vous avez hackurisé WordPress en une application avec des types de publications personnalisées, ACF et des points d'extrémité API REST... arrêtez. WordPress n'a jamais été destiné à être un framework d'application. Next.js avec les composants serveur, les actions serveur et les middlewares vous donne une véritable architecture d'application.

Sites éditoriaux riche en contenu

Stack recommandée : Next.js ou Astro + Sanity ou Strapi

Les équipes éditoriales ont besoin de modélisation de contenu structurée, d'aperçus de brouillons et d'édition collaborative. C'est là qu'un CMS headless brille. La collaboration en temps réel de Sanity est des années en avance sur l'éditeur Gutenberg de WordPress. Strapi vous donne une option auto-hébergée avec un panneau d'administration clean.

Cas d'usage Frontend recommandé CMS recommandé Hébergement Coût mensuel estimé
Site marketing / blog Astro Sanity ou Contentful Vercel / Netlify $0-$20
E-commerce Next.js API Storefront Shopify Vercel $29-$79 (Shopify) + $20 (Vercel)
Application web Next.js Sanity (pour le contenu) Vercel / AWS $20-$100
Editorial / publication Next.js ou Astro Sanity ou Strapi Vercel $0-$99

Comparez cela à votre facture actuelle d'hébergement WordPress. Pour la plupart des équipes, les coûts d'infrastructure chutent de 30-60%.

Chronologie et coût de migration (vrais chiffres)

Je vais vous donner les chiffres que personne ne veut publier parce qu'ils craignent d'effrayer les clients. Ceux-ci sont basés sur des migrations réelles que nous avons faites et observées en 2025-2026.

Petit site (moins de 50 pages, blog simple)

  • Chronologie : 3-5 semaines
  • Coût : 5 000-12 000 $ (agence) / 40-80 heures (interne)
  • Tâches clés : Exportation et restructuration du contenu, reconstructions de modèles dans Astro/Next.js, configuration du CMS, mappage de redirections, basculement DNS
  • Partie la plus difficile : Extraction du contenu des raccourcis du page builder. Si votre contenu est criblé de [vc_row] ou de blobs JSON d'Elementor, budgétisez du temps supplémentaire pour le nettoyage du contenu.

Site moyen (50-200 pages, plusieurs types de contenu)

  • Chronologie : 6-10 semaines
  • Coût : 15 000-35 000 $ (agence) / 120-250 heures (interne)
  • Tâches clés : Tout ce qui précède, plus la modélisation de contenu dans le CMS headless, le développement de composants personnalisés, les migrations de formulaires, le réfilage de l'intégration tiers (analyse, marketing par email, CRM)
  • Partie la plus difficile : Reconstruction des groupes de champs ACF personnalisés et des relations dans un nouveau modèle de contenu. C'est là que la plupart des estimations de chronologie explosent.

Grand site (200+ pages, e-commerce, fonctionnalité personnalisée)

  • Chronologie : 12-20 semaines
  • Coût : 40 000-80 000 $ + (agence) / 400-800+ heures (interne)
  • Tâches clés : Audit complet du contenu, stratégie de migration par phases, scripts de migration de données, migration de plateforme e-commerce, migration de comptes utilisateur, préservation du SEO (redirections, plan du site, données structurées)
  • Partie la plus difficile : Ne pas casser le SEO. Les grands sites ont accumulé des années de backlinks, de pages indexées et d'autorité de recherche. Un mappage de redirection botché peut faire couler votre trafic organique pendant des mois.

Ces chiffres peuvent sembler élevés, mais comparez-les au coût total de possession de rester sur WordPress pendant 3 années supplémentaires : hébergement géré (100-300 $/mo × 36 = 3 600-10 800 $), licences de plugins premium (500-2 000 $/an × 3 = 1 500-6 000 $), réponse aux incidents de sécurité (2 000-10 000 $ par incident) et temps de développeur dépensé en maintenance au lieu de fonctionnalités.

Si vous voulez discuter des spécificités de votre projet, notre page tarifaire explique comment nous abordons cela, et vous pouvez toujours nous contacter directement.

Les 3 erreurs qui tuent les migrations WordPress

J'ai vu celles-ci tuer les migrations. Pas « causer des retards » — les tuer. Comme dans, l'équipe abandonne et revient à WordPress, ayant gaspillé des mois et des dizaines de milliers de dollars.

Erreur 1 : Migrer le contenu sans le restructurer

La plus grande erreur est de traiter la migration comme un travail de copier-coller. Vous exportez vos articles et pages WordPress, vous les importez dans un nouveau CMS et vous reconstruisez les mêmes modèles. Cela vous donne la même architecture de contenu désordonnée dans une boîte plus brillante.

Tout le point de migrer est de restructurer. WordPress encourage un modèle de contenu plat : articles, pages et types de publications personnalisés avec des champs ACF collés dessus. Un CMS headless vous permet de définir des modèles de contenu appropriés avec des champs typés, des références et la validation.

Passez du temps à auditer votre contenu avant d'écrire une seule ligne de code. Quels types de contenu vous avez-vous vraiment besoin ? Quels champs ont de l'importance ? Quelles pages peuvent être consolidées ou supprimées ? J'ai vu des sites WordPress de 200 pages réduits à 60 pages de contenu bien structuré lors de la migration — sans aucune perte de valeur.

Erreur 2 : Ignorer la carte de redirection

Les URLs WordPress suivent un modèle spécifique (/2024/03/post-title/, /category/uncategorized/, etc.). Votre nouveau site aura des modèles d'URL différents. Chaque ancienne URL doit rediriger vers son équivalent nouveau, ou vous perdez la valeur SEO que ces pages ont accumulée.

C'est un travail fastidieux et sans éclat. C'est aussi la tâche technique la plus importante de l'ensemble de la migration. Utilisez un outil de crawling comme Screaming Frog pour exporter chaque URL indexée, mappez chacune à sa nouvelle destination et implémentez les redirections 301.

// next.config.js — exemple de mappage de redirection
const nextConfig = {
  async redirects() {
    return [
      {
        source: '/2024/03/old-post-slug/',
        destination: '/blog/new-post-slug',
        permanent: true,
      },
      {
        source: '/category/:slug',
        destination: '/topics/:slug',
        permanent: true,
      },
      // ... potentiellement des centaines de ceux-ci
    ];
  },
};

Pour les grands sites, vous voudrez générer ceux-ci programmatiquement à partir de votre exportation de contenu plutôt que de les mapper à la main.

Erreur 3 : Ne pas donner aux éditeurs un CMS avant le lancement

Les développeurs adorent les migrations. Les éditeurs de contenu les détestent. Vous retirez l'outil qu'ils connaissent (WordPress) et vous leur en donnez un qui leur est unfamilier. Si vous n'impliquez pas vos éditeurs tôt — en les formant sur le nouveau CMS, en obtenant leurs commentaires sur le flux de travail d'édition de contenu, en vous assurant qu'ils peuvent réellement publier sans aide du développeur — ils se révolteront.

J'ai vu une migration être annulée deux semaines avant le lancement parce que l'équipe marketing a dit « nous ne pouvons pas travailler avec cela ». L'équipe de dev avait construit un beau site Astro avec Sanity Studio, mais personne n'avait montré aux éditeurs comment Sanity fonctionnait jusqu'à la semaine du lancement.

Impliquez votre équipe de contenu à la semaine 2, pas à la semaine 10. Laissez-les créer du contenu de test dans le nouveau CMS. Écoutez leurs plaintes. Ajustez la configuration du studio. C'est ce qui fait ou défait l'adoption.

FAQ

Comment sais-je qu'il est temps de quitter WordPress ?

Utilisez le cadre à cinq questions ci-dessus. Si vous répondez « oui » à trois ou plus des questions — plus de 20 plugins, hébergement au-dessus de 100 $/mois, incidents de sécurité, échecs des Core Web Vitals, ou votre équipe ne peut pas expédier assez vite — c'est le moment. Le cadre ne concerne pas la haine de WordPress. C'est évaluer honnêtement si la plateforme vous aide ou vous retient. Deux ou moins ? WordPress est probablement toujours bien pour vos besoins, et vous devriez vous concentrer sur l'optimisation de ce que vous avez.

Quelle est l'alternative WordPress la moins chère ?

Astro avec un CMS headless gratuit (Sanity supporte 3 utilisateurs sur le plan gratuit, Contentful supporte 5 utilisateurs sur le plan gratuit) déployé sur le plan gratuit Netlify ou Vercel. Coût total : 0 $/mois. Sérieusement. Pour un site marketing ou un blog, cette pile est prête pour la production et performe mieux qu'une configuration WordPress gérée à 100 $/mois. La contrainte est que vous avez besoin d'un développeur à l'aise avec Astro et le CMS au choix — mais si vous lisez cet article, c'est probablement vous.

Combien de temps faut-il pour migrer hors de WordPress ?

Pour un site typique petit (moins de 50 pages), attendez 3-5 semaines. Les sites moyens avec 50-200 pages et plusieurs types de contenu fonctionnent 6-10 semaines. Les grands sites avec e-commerce ou une fonctionnalité personnalisée complexe peuvent prendre 12-20 semaines. La plus grande variable n'est pas le code — c'est le contenu. Si votre contenu est propre et bien structuré, la migration se fait rapidement. S'il est piégé dans les raccourcis du page builder et profondément imbriqué dans les groupes de champs ACF, budgétisez du temps supplémentaire pour l'extraction et la restructuration.

Vais-je perdre le SEO si je migre de WordPress ?

Vous pourriez, mais vous ne le ferez pas si vous le faites correctement. L'étape critique est l'implémentation d'une carte de redirection 301 complète à partir de chaque ancienne URL vers son équivalent nouveau. Vous devez également préserver vos titres méta, descriptions et données structurées (balisage schéma). Explorez votre site existant avec Screaming Frog avant la migration, exportez toutes les URLs indexées et vérifiez que chaque redirection fonctionne après le lancement. La plupart des migrations bien exécutées voient une fluctuation temporaire de 2-4 semaines du classement, suivie d'une amélioration grâce à de meilleurs Core Web Vitals.

Puis-je utiliser WordPress comme CMS headless au lieu de migrer complètement ?

Oui, et c'est une étape intermédiaire valable. L'API REST de WordPress (ou WPGraphQL) vous permet d'utiliser WordPress comme backend de contenu tout en construisant un frontend moderne dans Next.js ou Astro. Cette approche permet à vos éditeurs de continuer à utiliser l'administrateur WordPress qu'ils connaissent tandis que votre équipe de dev construit un frontend plus rapide. Les inconvénients : vous maintenez toujours une installation WordPress (avec toute sa surcharge de sécurité et de mise à jour), et l'API REST peut être lente sans mise en cache. Je recommande cela comme une étape transitoire, pas comme une destination.

Que se passe-t-il avec mes plugins WordPress quand je migre ?

Ils disparaissent — et c'est le point. La plupart des plugins existent pour combler les lacunes dans WordPress (SEO, mise en cache, formulaires, optimisation d'images, sécurité). Dans une pile moderne, ceux-ci sont gérés par le framework ou les outils de build. Next.js a l'optimisation d'image intégrée. Astro expédie zéro JS par défaut. Les formulaires de contact peuvent utiliser des services comme Formspree ou Resend. L'analyse passe à Plausible ou Vercel Analytics. Vous devrez auditer votre liste de plugins et mapper chacun à son remplacement dans la nouvelle pile.

Dois-je migrer tout d'un coup ou par phases ?

Pour les sites de moins de 100 pages, migrez tout d'un coup. La surcharge de coordination d'exécuter deux systèmes simultanément n'en vaut pas la peine. Pour les grands sites (200+ pages), envisagez une approche par phases : migrez d'abord les pages marketing et le blog, gardez les sections complexes (e-commerce, portails utilisateurs) temporairement sur WordPress et utilisez les règles de proxy inverse pour servir les deux depuis le même domaine. Cela réduit le risque mais augmente la complexité architecturale.

Ai-je besoin d'une agence pour migrer hors de WordPress, ou puis-je le faire moi-même ?

Cela dépend du site. Un développeur à l'aise avec Next.js ou Astro peut migrer un blog simple en quelques fins de semaine. Mais pour les sites avec des modèles de contenu complexes, l'e-commerce, la fonctionnalité personnalisée ou des enjeux SEO élevés, travailler avec une équipe qui a fait cela avant économise réellement du temps et de l'argent. Nous avons fait des dizaines de ces migrations — les modèles sont prévisibles et les pièges sont bien connus. Consultez nos capacités ou contactez-nous si vous voulez discuter de votre situation spécifique.