De WordPress à Statamic : comment votre page builder façonne le coût de la migration
La plupart des guides « migrer WordPress vers Statamic » supposent que vous êtes sur Gutenberg seul. Les vrais sites d'entreprise utilisent ACF, Elementor, Divi ou WPBakery — et ce choix façonne le coût de la migration plus que tout autre facteur. Voici comment identifier votre situation et ce qu'il faut demander avant de signer.
Pour mettre des chiffres derrière : Advanced Custom Fields est actif sur plus de 2 millions de sites WordPress, et Elementor sur plus de 10 millions (selon le répertoire de plugins WordPress.org), avec Divi et WPBakery qui complètent la couche page builder en dessous. La couche de plugins que vous ne voyez pas de l'extérieur est ce qui détermine la plus grande partie de la facture de migration.
Cet article explique comment reconnaître ce que vous avez réellement, ce que coûte chaque archétype à migrer, où se cachent les factures, et ce qu'il faut demander avant de signer un cahier des charges. Il s'adresse aux propriétaires et aux décideurs, pas aux développeurs.
D'abord, identifiez ce que vous avez
Vous n'avez pas besoin d'accès au code. Il vous faut dix minutes dans votre admin WordPress et une bonne question pour la personne qui maintient actuellement le site.
Dans la barre latérale d'admin, cherchez :
Un menu « Custom Fields » ou « ACF » → Basé sur ACF
Un menu « Elementor » avec « Templates » ou « My Templates » → Elementor
Un menu « Divi » avec « Theme Options » → Divi
« WPBakery » ou « Visual Composer » → WPBakery
Rien de tout cela, uniquement les Posts/Pages/Apparence standards → Vanilla / Gutenberg
Posez ensuite une seule question à votre développeur : « Quel est le page builder, et la majorité du contenu est-elle gérée via des champs ACF ou directement dans l'éditeur ? » La réponse détermine votre scénario. Sauter cette étape est la façon dont les cahiers des charges de migration doublent en silence.
Les quatre archétypes de départ
Les vrais sites WordPress se répartissent en quatre grandes formes. La plupart sont des mélanges — mais l'élément dominant pilote l'histoire des coûts.
Vanilla / Gutenberg
Le cas le plus simple. Le contenu vit dans les champs WordPress standards, sans markup de mise en page propriétaire intégré. La migration consiste essentiellement en un remappage de contenu plus des redirections. Fourchette la plus basse, calendrier le plus prévisible.
Basé sur ACF
Le cas non-vanilla le plus aimable. Votre contenu est dans des champs structurés (texte, image, repeater, galerie) et les templates le rendent. Un développeur peut mapper les champs ACF vers la modélisation de contenu de Statamic avec une grande fidélité, souvent via un script ponctuel. Fourchette intermédiaire, prévisible.
Builders visuels — Elementor, Divi, WPBakery
Le cas le plus difficile, et le plus courant sur les sites d'entreprise sérieux. Contenu et mise en page sont fusionnés : un paragraphe n'est pas que du texte, c'est du texte à l'intérieur d'un module spécifique au builder avec un style intégré. Extraire « juste le contenu » fonctionne rarement proprement. Fourchette la plus large, inconnue la plus large. Nous développons cela ci-dessous parce que c'est là que se logent la plupart des surprises.
Mixte
La majorité réaliste. ACF pour les types de contenu, Elementor pour les pages d'atterrissage, Gutenberg pour le blog. Le coût atterrit là où votre plus gros composant « difficile » atterrit — généralement la partie builder visuel. Prévoyez une marge.
Pourquoi les builders visuels sont le risque principal
Quand un site utilise Elementor, Divi ou WPBakery, le contenu de la page n'existe pas indépendamment de la mise en page. Un « hero avec trois colonnes et une liste d'icônes » n'est pas trois paragraphes de texte — c'est un blob sérialisé dans la base de données WordPress qui dit « utilise le module de ce builder, avec ces réglages, à cette position ». Retirez le builder et il vous reste du markup brut qu'aucun autre système ne peut lire de manière significative.
C'est pourquoi « exporter juste le contenu » ne fonctionne pas pour ces sites. Vous avez trois options honnêtes :
Reconstruire à partir de zéro. Un binôme designer-développeur recrée chaque page dans Statamic. Coût prévisible, calendrier plus long, qualité maximale — vous en profitez aussi pour corriger la dérive de mise en page accumulée.
Extraction partielle plus nettoyage. Un script extrait le texte visible et les références d'images du markup builder ; une personne réassemble chaque page. Moins cher, mais la fidélité visuelle baisse sensiblement.
Approche parallèle. Construisez le nouveau site Statamic à côté du WordPress en production. Migrez page par page par ordre de priorité. Basculez le trafic quand c'est prêt. Risque ponctuel le plus bas, utile quand la tolérance au downtime est faible.
Le bon choix dépend de la part de votre design visuel existant que vous tenez à préserver, du nombre de pages à déplacer et du temps calendaire dont vous disposez. La plupart des projets que nous voyons finissent par combiner deux de ces options — par exemple, build parallèle pour les pages marketing, extraction partielle pour le contenu d'archive du blog.
Ce que toute migration doit gérer
Quel que soit l'archétype, chaque migration WordPress vers Statamic couvre les cinq mêmes préoccupations universelles :
Redirections — sans une carte de 301 des anciennes URL vers les nouvelles, les classements de recherche chutent en quelques semaines. Non négociable.
Médias — chaque image et PDF doit migrer et rester accessible depuis son ancienne URL.
Position SEO — les métadonnées Yoast ou Rank Math sont mappées vers les équivalents SEO de Statamic.
Formulaires et intégrations — formulaires de contact, CRM, câblage newsletter. Parfois un équivalent Statamic existe à l'identique ; parfois il faut recâbler.
Réentraînement des éditeurs — votre équipe apprend une nouvelle interface d'admin. Prévoyez une à deux heures de transmission accompagnée.
Ce ne sont pas des éléments différenciateurs entre archétypes — ce sont des constantes. Mais elles doivent figurer dans chaque contrat.
Outils de migration automatisés — ce qu'ils peuvent et ne peuvent pas faire
Un addon importer WordPress pour Statamic existe. Il peut récupérer pages, articles, taxonomies et contenu simple. Sur un site WordPress vanilla, il fait un travail utile.
Pour tout le reste — champs personnalisés ACF, contenu builder Elementor, shortcodes Divi, markup WPBakery — l'importer ramène le HTML rendu, pas le contenu structuré. Vous vous retrouvez avec un site Statamic plein de blocs HTML figés, sans structure modifiable en dessous. Les futures modifications de contenu deviennent pénibles.
La règle : toute agence qui propose « on automatise tout » sans d'abord faire un proof of concept sur votre site spécifique vous vend un espoir, pas un plan. Le coût de défaire un mauvais import automatisé dépasse généralement le coût d'une migration manuelle bien cadrée.
Fourchettes budgétaires réalistes par archétype
Pas de chiffre unique — chaque site est différent — mais voici les fourchettes attendues pour un site marketing typique de petite taille (10 à 30 pages, un blog, formulaires de contact ; pas d'e-commerce) :
| Archétype | Temps réaliste | Fourchette budgétaire | Driver principal |
|---|---|---|---|
| Vanilla / Gutenberg | 1 à 2 semaines | Petite | Quantité de contenu |
| Basé sur ACF | 2 à 4 semaines | Moyenne | Complexité des champs |
| Builder visuel unique | 4 à 8 semaines | Plus large | Nombre de pages + fidélité de design requise |
| Mixte | 4 à 10 semaines | La plus large, avec marge | Quel chemin est le plus gros dans votre mix |
Pour le coût de fonctionnement du nouveau site Statamic sur trois ans (séparé de la migration), voir notre modèle de coût et de performance sur 3 ans — la migration se trouve en tête de ces chiffres.
Questions à poser avant de signer le cahier des charges
Utilisez-les lors du call de cadrage. Les réponses séparent les agences soigneuses des agences optimistes :
« Avez-vous regardé notre structure de contenu réelle, pas seulement le nombre de pages ? »
« Quel est votre plan spécifique pour les pages [votre builder] ? »
« Que perdons-nous si nous ne refaisons pas le contenu à partir de zéro ? »
« Comment sont gérées les redirections, et avec quelle couverture ? »
« Quelles intégrations cassent, et qu'est-ce qui les remplace ? »
« Comment gérez-vous nos traductions ou nos autres langues ? »
Si vous n'obtenez pas de réponses spécifiques et cadrées à ces questions, le prix que vous avez signé bougera.
Quand NE PAS migrer
Certains sites ne valent pas le déménagement. Signaux honnêtes :
Le trafic du site décline de toute façon — la migration ne réglera pas un problème marketing.
Le site est édité une fois tous les deux ou trois ans — il n'y a pas de douleur de maintenance à soulager.
Vous êtes verrouillé sur un plugin WordPress-only (LearnDash, BuddyBoss, une configuration WooCommerce complexe) sans équivalent Statamic dans votre roadmap.
Parfois la bonne réponse est « restez, rapiécez, économisez le budget ».
À propos de cet article
Je suis Andrii Trush. Je travaille sur des projets Statamic à travers l'Europe — j'ai migré des sites WordPress de toutes les formes de cette liste, et j'ai aussi dit à des prospects de ne pas se lancer. Les chiffres et les formes ci-dessus viennent de ces projets, pas d'une présentation commerciale. Si vous voulez une vérification de bon sens sur votre propre situation, contactez-moi.
Pouvons-nous garder le site WordPress existant en production pendant que nous construisons la version Statamic ?
Oui — c'est l'approche parallèle mentionnée dans l'article. Vous gardez WordPress sur son domaine actuel et construisez Statamic sur une URL de staging jusqu'à ce que ce soit prêt. La bascule se fait au niveau DNS une fois la carte de redirections en place. Cela coûte un peu plus en temps calendaire mais élimine le downtime, ce qui compte le plus pour les sites à trafic régulier ou avec des campagnes payantes en cours.
Comment protégeons-nous nos classements dans les recherches pendant la migration ?
Trois choses comptent : une carte complète de redirections 301 des anciennes URL vers les nouvelles (y compris pagination, archives de taxonomies et URL de flux), la préservation des meta titles et descriptions, et la soumission du nouveau sitemap à Google Search Console dès que le nouveau site est en ligne. La plupart des chutes de classement que nous voyons lors des migrations viennent de redirections manquantes sur des URL de longue traîne — des articles de blog de plusieurs années en arrière qui captent toujours du trafic de recherche. Un cahier des charges sérieux inclut une passe de QA des redirections, pas seulement les pages principales évidentes.
Que deviennent nos plugins WordPress existants après la migration ?
Chaque plugin demande une décision de remplacement explicite. Certains ont des équivalents Statamic directs (formulaires, SEO, analytics — couverts par des addons Statamic ou des fonctionnalités intégrées). Certains doivent être recâblés via d'autres outils (les intégrations newsletter glissent souvent vers une gestion au niveau de la soumission de formulaire). Une poignée n'aura pas d'équivalent du tout et nécessitera un build sur mesure ou une remise en question. Cartographiez vos plugins actifs avant de chiffrer — les surprises ici sont le deuxième plus gros tueur de budget après les page builders.
Devons-nous redesigner pendant la migration, ou migrer d'abord et redesigner ensuite ?
Faites les deux ensemble quand le design existant est vraiment fatigué, ou quand vous payez de toute façon pour l'extraction de contenu de builder visuel — vous touchez déjà à chaque page. Migrez d'abord quand le design actuel est correct et que l'objectif est juste d'échapper à la douleur opérationnelle de WordPress. Faire les deux simultanément coûte moins au total que deux projets successifs, mais ajoute du risque : le scope creep est réel. Si vous bundlez, verrouillez le nouveau design avant que le code de migration ne commence, pas en parallèle.