Refondre l'architecture complexe d'un WordPress sans perte de données
Comment refondre l'architecture d'un WordPress multilingue devenu ingérable (trois moteurs CPT, ACF, JetEngine et Toolset, plus doublons, liaisons croisées et modules tampon) en un modèle unique ACF Pro, sans perdre une donnée et avec un site enfin plus rapide.
Contexte : trois moteurs CPT sur un même WordPress
ACF, JetEngine et Toolset en parallèle : trois façons de décrire les mêmes contenus, et plus personne n'osait y toucher.
Le site WordPress cumulait ACF, JetEngine et Toolset comme gestionnaires de types de contenu. Chacun définissait ses propres CPT, taxonomies et champs, parfois des champs rattachés à un CPT créé sur un autre moteur que celui qui hébergeait les posts.
Le multilingue ajoutait une couche de complexité : traductions, meta dupliquées, relations difficiles à tracer. Des dizaines de modules et du code custom tentaient de colmater les fuites, sans jamais stabiliser l'ensemble.
L'objectif : purger, centraliser et accélérer. Pas un simple nettoyage cosmétique, mais une refonte structurelle du modèle de données.
Les trois objectifs
✓Un seul moteur pour tout le modèle
✓Aucune donnée perdue en route
✓Un site plus rapide et plus simple à faire évoluer
Diagnostic
Diagnostic : doublons, liaisons croisées et dette technique
L'audit a révélé un modèle de données ingérable : CPT et taxonomies en doublon, champs répétés sous plusieurs formats, relations implicites entre entités créées sur des moteurs différents. Exemple récurrent : un CPT institution relié à un utilisateur WordPress via une taxonomie de liaison, alors que les mêmes informations existaient aussi en meta utilisateur. Trois endroits pour une même donnée.
CPT et taxonomies redondants (même concept, plusieurs implémentations)
Champs liés à des CPT déclarés ailleurs (ACF vs JetEngine vs Toolset)
Relations post ↔ user ↔ taxo non documentées
Modules « tampon » qui masquent les incohérences sans les résoudre
Impact performance et maintenabilité sur tout le back-office
Trois moteurs CPT
Cas concret
Cas institution : utilisateurs, taxonomies et données en double
Les institutions éditaient du contenu via une interface front custom devenue inutile. Il fallait conserver les données institution, pas les ~200 comptes restés sans accès éditorial. La migration a extrait et consolidé les données utiles vers le nouveau modèle ACF Pro, puis a purgé les utilisateurs orphelins sans casser le contenu public.
Fusion des données institution CPT + taxo + user meta
Suppression des ~200 utilisateurs restés sans droit de publication
Conservation des institutions et de leur contenu affiché
Abandon de l'interface d'édition front devenue obsolète
Modèle cible : institution en CPT ACF avec liaisons explicites
Stratégie
Stratégie : un seul moteur, ACF Pro
La cible est claire : ACF Pro seul pour gérer CPT, taxonomies, champs et relations entre entités. JetEngine et Toolset sont désactivés une fois les données migrées, et tous les modules tampon et patches custom qui compensaient les incohérences sont retirés. Le site ne dépend plus d'une pile de bricolages empilés au fil des années.
ACF Pro comme unique source de vérité structurelle
Groupes de champs, CPT et relations normalisés dans ACF Pro
Décommissionnement JetEngine et Toolset après vérification
Suppression des plugins et hooks « rustine »
Documentation du modèle cible pour les évolutions futures
ACF Pro seul
Migration
Scripts PHP de migration : zéro perte de données
Chaque script couvre un périmètre (CPT, taxo, traductions, relations) avec logs, dry-run et contrôles de cohérence avant toute bascule définitive.
01
Lire
Des scripts WP-CLI par lot lisent les anciennes tables meta, moteur par moteur.
02
Mapper
Chaque ancien champ a sa correspondance explicite vers un champ ACF, traductions comprises.
03
Consolider
Les données normalisées arrivent dans des CPT temporaires propres, une zone tampon sans risque.
04
Comparer
Un comparatif avant / après sur échantillons valide chaque lot avec le client.
05
Purger
Les anciens CPT, taxonomies et meta couplés sont supprimés : la base ne garde que le modèle final.
Performance
Purge, base allégée et site accéléré
Au-delà du modèle de données, le chantier inclut un nettoyage profond : meta orphelines, options encombrées, autoload inutile, requêtes CPT redondantes. Moins de plugins actifs, moins de hooks, moins de jointures meta : le back-office et le front gagnent en réactivité. Le WordPress « abominablement complexe » devient maintenable.
Suppression CPT / taxonomies / champs obsolètes
Nettoyage meta et options orphelines en base
Retrait des modules tampon et code custom redondant
Réduction du nombre de plugins actifs
Gain mesurable sur temps de chargement admin et public
Bilan
Bilan du projet
Le site repose désormais sur ACF Pro seul pour CPT, taxonomies, champs et liaisons. Les données ont été migrées sans perte, la dette technique purgée, et le WordPress est plus rapide et enfin évolutif.
Un seul moteur : ACF Pro (fin d'ACF + JetEngine + Toolset en parallèle)
Scripts PHP de migration avec CPT temporaires et vérification
Données consolidées sans perte (institutions, multilingue, relations)
