Pourquoi les utilisateurs MODX devraient migrer vers Next.js en 2026 : Un avis honnête
Contenu traduit en français
J'ai construit des sites sur MODX depuis l'époque d'Evolution. J'ai écrit des snippets personnalisés, j'ai dompté les TV (template variables, pas les téléviseurs), et j'ai défendu MODX dans d'innombrables débats CMS. Croyez-moi quand je dis que ce n'est pas un réquisitoire. C'est un appel à la vigilance de quelqu'un qui a réellement adoré cette plateforme.
Mais voilà : le monde du développement web a progressé, et MODX ne s'est pas adapté. La communauté rétrécit, le cycle de publication a ralenti à un rythme d'escargot, et le vivier de talents s'assèche plus vite qu'une flaque en juillet. Si vous faites tourner des sites en production sur MODX en 2026, vous devez sérieusement envisager votre stratégie de sortie. Et pour la plupart des équipes, cette sortie mène à Next.js.
Laissez-moi vous expliquer pourquoi — honnêtement, sans le battage médiatique.
Table des matières
- L'état de MODX en 2026
- Ce que MODX a réussi (et réussit toujours)
- Les problèmes que vous ne pouvez plus ignorer
- Pourquoi Next.js est la cible de migration naturelle
- Le chemin de migration : MODX vers Next.js
- Choisir un CMS headless pour remplacer MODX
- Gains de performance réels : avant et après
- Ce qui vous manquera (et ce qui ne vous manquera pas)
- Comparaison des coûts : MODX vs Next.js
- FAQ
L'état de MODX en 2026
Examinons les chiffres honnêtement. MODX 3.x existe depuis un certain temps, mais l'adoption a été... tiède. Les forums MODX, autrefois pleins d'activité, reçoivent maintenant peut-être une poignée de messages par semaine. Le référentiel GitHub officiel montre une activité de commit de plus en plus clairsemée. Comparez cela à 2018 ou 2019 quand la communauté poussait encore fort.
Les données BuiltWith du début 2026 estiment que MODX alimente environ 0,3% des sites CMS détectés, en baisse par rapport à environ 0,7% en 2021. WordPress domine toujours avec environ 62%, et les nouveaux acteurs comme les sites basés sur Next.js (souvent associés à des CMS headless) croissent à environ 40% année après année.
La marketplace MODX (anciennement le référentiel Extras) n'a pas vu de nouvelle extension vraiment pertinente depuis des mois. De nombreux extras populaires ne sont pas maintenus ou seulement partiellement compatibles avec MODX 3.x. Quand l'écosystème cesse de produire, ce n'est pas un signal d'alerte — c'est un drapeau blanc.
Je ne dis pas que MODX est mort. Il fonctionne toujours. Vos sites tournent toujours. Mais « fonctionne encore » est un endroit dangereux dans le développement web.
Ce que MODX a réussi (et réussit toujours)
Avant d'empiler les reproches, à chacun son dû. MODX a bien réussi plusieurs choses que la plupart des CMS obtiennent mal :
Véritable flexibilité du contenu
MODX ne vous a jamais forcé dans un paradigme « article et page ». Les template variables, chunks et snippets vous ont donné une véritable liberté de modélisation de contenu des années avant que « contenu structuré » devienne un buzzword. Vous pouviez construire n'importe quoi.
Sortie propre
MODX n'injectait pas son propre markup. Pas de classes CSS mystérieuses, pas de divs supplémentaires que vous ne demandiez pas. Votre HTML était votre HTML. Pour les développeurs front-end qui se souciaient de l'artisanat, c'était une révélation.
Theming convivial pour les développeurs
Pas de système de thème à apprendre, pas de hiérarchie de modèles à mémoriser. Vous aviez écrit des modèles. C'était tout. Les chunks étaient des partials réutilisables. Les snippets étaient une logique PHP. Un modèle mental simple, des résultats puissants.
La syntaxe des balises
Dites ce que vous voulez de [[*pagetitle]] et [[!MySnippet]] — une fois que vous l'aviez appris, vous pouviez construire des pages complexes rapidement. La couche de cache avec le drapeau uncached ! était élégante.
Ces forces rendent en fait les développeurs MODX excellents candidats pour les architectures headless modernes. Si vous pensez déjà en contenu structuré et modèles basés sur les composants, vous êtes déjà à mi-chemin de Next.js.
Les problèmes que vous ne pouvez plus ignorer
C'est ici que je dois être franc.
Préoccupations de sécurité
MODX 3.x a résolu de nombreuses vulnérabilités historiques, mais exécuter tout monolithe PHP avec un panneau d'administration public est un vecteur de risque inhérent. En 2025, nous avons vu au moins deux CVE critiques affectant les installations MODX, et les correctifs ont pris des semaines à arriver. Avec une équipe de sécurité qui rétrécit, les temps de réponse ne s'améliorent pas.
Comparez cela avec un site Next.js déployé sur Vercel ou Netlify — il n'y a littéralement pas de serveur à attaquer. Pas de panneau d'administration à forcer brutalement. Pas de PHP à exploiter. La surface d'attaque est fondamentalement plus petite.
La crise des talents
Essayez d'embaucher un développeur MODX en 2026. Allez-y. Publiez l'offre d'emploi et écoutez les grillons. Le vivier de développeurs a migré vers React, Next.js et les frameworks JavaScript modernes. Même le talent PHP va vers Laravel, pas MODX.
Ce n'est pas une préoccupation théorique. J'ai parlé à des agences qui ont des sites MODX qu'elles ne peuvent littéralement pas trouver de développeurs pour maintenir. Quand le développeur original part, le site devient un passif.
Problèmes de compatibilité PHP 8.x
MODX 3.x fonctionne sur PHP 8, mais de nombreux extras ne le font pas. Si vous avez construit un site qui dépend de snippets ou de plugins tiers, la mise à niveau de PHP casse souvent les choses. Vous finissez par être épinglé à des versions PHP plus anciennes, ce qui ramène au problème de sécurité.
Pas d'expérience développeur moderne
Pas de rechargement de module à chaud. Pas d'architecture basée sur les composants. Pas de support TypeScript. Pas d'optimisation d'image intégrée. Pas de rendu edge. Pas d'ISR. Je pourrais continuer.
Le flux de travail de développement MODX est essentiellement : éditer un fichier ou un chunk dans le gestionnaire (ou dans votre IDE via un outil de synchronisation), vider le cache, rafraîchir le navigateur. Ça fonctionne, mais c'est lent comparé au DX moderne.
Plafond de performance
MODX peut être rapide — j'ai construit des sites sub-2 secondes dessus. Mais y arriver nécessite une optimisation significative : cache de page complète, configuration CDN, réglage de base de données et architecture snippet minutieuse. Next.js vous donne une performance sub-seconde essentiellement directement. Vous vous battez pour la performance sur MODX ; sur Next.js, vous vous battez pour la saborder.
Pourquoi Next.js est la cible de migration naturelle
Vous pourriez vous demander : pourquoi pas WordPress ? Pourquoi pas Astro ? Pourquoi pas juste un générateur de site statique ?
Toutes les options valides, mais Next.js frappe le point doux pour la plupart des migrations MODX. Voici pourquoi :
La flexibilité de rendu reflète la pensée MODX
Les développeurs MODX comprennent déjà que différentes pages ont besoin de différentes stratégies de cache. Dans MODX, vous marqueriez les snippets comme cachés ou uncached. Dans Next.js, vous choisissez entre Static Site Generation (SSG), Incremental Static Regeneration (ISR), et Server-Side Rendering (SSR) par page. Même concept, meilleure exécution.
L'architecture des composants remplace les chunks
Les chunks MODX sont des partials HTML réutilisables. Les composants React sont des partials UI réutilisables avec logique intégrée. Si vous avez écrit des chunks comme [[!$header]] et [[!$footer]], vous pensez déjà en composants. Vous aviez juste pas les props.
Les routes API remplacent les snippets
Les snippets MODX gèrent la logique côté serveur — traitement des formulaires, appels API, requêtes personnalisées. Les routes API Next.js (ou les Server Actions dans Next.js 14+) font la même chose mais en JavaScript/TypeScript avec un meilleur support des outils et des tests.
Pour les équipes envisageant des alternatives, Astro vaut la peine d'être évalué pour les sites riches en contenu qui n'ont pas besoin de beaucoup d'interactivité. Mais si vous avez besoin de fonctionnalités dynamiques, d'expériences authentifiées ou de récupération de données complexe, Next.js est le choix plus fort.
Le chemin de migration : MODX vers Next.js
Soyons pratiques. Voici comment fonctionne réellement une migration MODX vers Next.js.
Étape 1 : Auditer votre modèle de contenu
Mappez chaque modèle MODX, variable template et type de ressource. Cela devient votre modèle de contenu dans le CMS headless que vous choisissez. Documentez tout :
## Ressource : Article de blog
- pagetitle → title (texte)
- longtitle → seo_title (texte)
- content → body (texte riche)
- TV: hero_image → hero_image (média)
- TV: author → author (référence)
- TV: category → category (taxonomie)
Étape 2 : Exporter votre contenu
MODX n'a pas d'outil d'export vraiment génial. Vous aurez probablement besoin d'écrire un snippet personnalisé ou un script qui interroge modx_site_content et vos tables TV, puis sort JSON :
<?php
// Export de contenu MODX rapide et sale
$resources = $modx->getCollection('modResource', [
'published' => 1,
'deleted' => 0
]);
$output = [];
foreach ($resources as $resource) {
$output[] = [
'id' => $resource->get('id'),
'title' => $resource->get('pagetitle'),
'slug' => $resource->get('alias'),
'content' => $resource->get('content'),
'template' => $resource->get('template'),
'tvs' => $resource->getTemplateVars(),
'parent' => $resource->get('parent'),
'publishedon' => $resource->get('publishedon'),
];
}
header('Content-Type: application/json');
echo json_encode($output, JSON_PRETTY_PRINT);
Puis écrivez des scripts d'import pour votre CMS cible. C'est un travail peu glamour, mais c'est un effort unique.
Étape 3 : Construire votre front-end Next.js
Commencez avec create-next-app et construisez vos modèles en tant que composants de page. Votre mappage de modèle MODX → page layout pourrait ressembler à :
| Concept MODX | Équivalent Next.js |
|---|---|
| Modèle | Composant layout |
| Chunk | Composant React |
| Snippet | Server Action / route API |
| Variable template | Champ CMS |
| Ressource | Page / entrée de contenu |
[[*field]] balise |
Props / récupération de données |
| Plugin (crochet événement) | Middleware |
[[!uncached]] |
SSR / rendu dynamique |
[[cached]] |
SSG / ISR |
Étape 4 : Gérer les redirections d'URL
C'est là que les gens se trompent. Chaque ancienne URL MODX a besoin d'une redirection 301 vers son équivalent Next.js. Construisez une carte de redirection et ajoutez-la à next.config.js :
// next.config.js
module.exports = {
async redirects() {
return [
{
source: '/old-modx-path.html',
destination: '/new-path',
permanent: true,
},
// ... des centaines de plus, générées de votre export
]
},
}
Ne passez pas cette étape. Votre SEO en dépend.
Étape 5 : Exécuter en parallèle pendant 2-4 semaines
Déployez Next.js aux côtés de votre site MODX existant. Testez tout. Vérifiez les analyses. Vérifiez que les formulaires fonctionnent. Puis retournez le DNS.
Choisir un CMS headless pour remplacer MODX
Next.js est votre front-end, mais vous avez toujours besoin d'un endroit pour gérer le contenu. Voici comment les options populaires se comparent pour les réfugiés MODX :
| CMS | Courbe d'apprentissage pour les devs MODX | Modélisation de contenu | Tarification (2026) | Option auto-hébergée |
|---|---|---|---|---|
| Sanity | Moyen | Excellente (schémas définis par le code) | Niveau gratuit, puis 15$/utilisateur/mo | Non (cloud uniquement) |
| Strapi | Faible | Bon (basé sur l'interface) | Gratuit (auto-hébergé), Cloud à partir de 29$/mo | Oui |
| Contentful | Moyen | Bon | Niveau gratuit, puis 300$/mo | Non |
| Payload CMS | Faible | Excellente (schémas définis par le code) | Gratuit (auto-hébergé), Cloud à partir de 50$/mo | Oui |
| Directus | Faible | Flexible | Gratuit (auto-hébergé), Cloud à partir de 99$/mo | Oui |
Si vous adorez la flexibilité de MODX et la capacité d'auto-hébergement, Payload CMS ou Strapi vous sembleront les plus familiers. Si vous voulez la meilleure expérience développeur et n'avez pas d'objection au cloud uniquement, Sanity est difficile à battre.
Nous avons fait un travail extensive avec tous ceux-ci à travers notre pratique de développement CMS headless, et le bon choix dépend vraiment du niveau de confort de votre équipe et de votre budget.
Gains de performance réels : avant et après
J'ai migré un site MODX de taille moyenne (environ 400 pages, blog + services + portfolio) vers Next.js avec Sanity fin 2025. Voici les chiffres réels :
| Métrique | MODX (optimisé) | Next.js sur Vercel | Amélioration |
|---|---|---|---|
| Lighthouse Performance | 72 | 98 | +36% |
| Largest Contentful Paint | 2,8s | 0,9s | -68% |
| Time to First Byte | 680ms | 45ms | -93% |
| Core Web Vitals Pass | Partiel | Passage complet | ✅ |
| Temps de build/déploiement | FTP manuel | Déploiement auto 42s | Nuit et jour |
| Coût d'hébergement mensuel | 45$/mo (VPS) | 0$ (niveau gratuit Vercel) | -100% |
L'amélioration TTFB seule est stupéfiante. MODX doit démarrer PHP, se connecter à MySQL, exécuter des snippets, assembler des chunks et servir la réponse — même avec le cache. Une page Next.js générée statiquement est servie depuis un nœud CDN edge en millisecondes.
Ce qui vous manquera (et ce qui ne vous manquera pas)
Ce qui vous manquera
- L'interface du gestionnaire : Le panneau d'administration de MODX est vraiment intuitif pour les éditeurs de contenu. La plupart des interfaces CMS headless ont une courbe d'apprentissage.
- L'édition en contexte : Éditer du contenu où vous le voyez rendu. La plupart des configurations headless nécessitent de basculer entre le CMS et l'aperçu. (L'outil Presentation de Sanity et Live Preview de Payload comblent cet écart.)
- Simplicité : Un serveur, une base de données, une codebase. Il y a une beauté à cela. Une pile headless a plus de pièces mobiles.
- L'ambiance de la communauté : La communauté MODX, bien que petite, était soudée et vraiment serviable.
Ce qui ne vous manquera pas
- Vider le cache : Le cycle interminable vider-cache-rafraîchir-navigateur.
- Gestion des TV : Créer et gérer les variables templates via l'interface pour chaque champ.
- Anxiété de base de données : Ce sentiment de malaise quand votre connexion MySQL maxe sur une pic de trafic.
- Déploiements FTP : Ou tout autre processus manuel que vous utilisiez pour pousser les modifications.
- Débogage d'événements de plugin : Essayer de comprendre quel plugin s'est déclenché quand, dans quel ordre.
Comparaison des coûts : MODX vs Next.js
Soyons réalistes sur le coût total de propriété, pas juste l'hébergement.
| Catégorie de coût | MODX (Annuel) | Next.js + CMS Headless (Annuel) |
|---|---|---|
| Hébergement | 540-1 200$ (VPS/partagé) | 0-240$ (Vercel/Netlify) |
| Licence CMS | 0$ (open source) | 0-3 600$ (varie selon le CMS) |
| Certificat SSL | 0-100$ | 0$ (inclus) |
| CDN | 0-600$ | 0$ (inclus) |
| Surveillance de sécurité | 200-500$ | Minimale (pas de serveur) |
| Maintenance du serveur | 500-2 000$ (temps ou externalisé) | 0$ |
| Taux horaire développeur | 75-120$ (talent rare) | 100-175$ (talent abondant) |
| Total (hors temps dev) | 1 240-4 400$ | 0-3 840$ |
Le wildcard est les taux de développeur. Les développeurs MODX sont moins chers de l'heure si vous les trouvez. Mais la rareté fait monter les taux avec le temps, et vous êtes souvent bloqué avec celui qui est disponible plutôt que de choisir le meilleur ajustement.
Si vous évaluez les coûts de migration pour votre situation spécifique, nous détaillons notre approche tarifaire ici — nous sommes transparents sur ce que ces projets coûtent réellement.
FAQ
Combien de temps prend typiquement une migration MODX vers Next.js ?
Pour un site avec 100-500 pages, attendez-vous à 6-10 semaines avec une équipe dédiée. La modélisation et la migration du contenu prennent environ 2 semaines, la construction du front-end Next.js prend 3-5 semaines, et l'assurance qualité/tests/redirections remplit le reste. Les sites plus grands avec une logique PHP personnalisée complexe ou une intégration lourde de e-commerce peuvent prendre 12-16 semaines. La plus grande variable est la quantité de logique PHP personnalisée qui doit être réécrite.
Puis-je garder mon panneau d'administration MODX et utiliser juste Next.js pour le front-end ?
Techniquement, oui — vous pourriez construire une couche API REST dans MODX et la consommer avec Next.js. Mais cela vous donne le pire des deux mondes : vous maintenez toujours le serveur PHP, la base de données MySQL et tous les problèmes de sécurité, tout en maintenant aussi un front-end séparé. À moins que vous ayez une raison très spécifique, il vaut mieux migrer le contenu vers un CMS headless spécialisé.
Vais-je perdre mon classement SEO pendant la migration ?
Non si vous gérez correctement les redirections. Les étapes critiques sont : maintenir la même structure d'URL où possible, mettre en place des redirections 301 pour toutes les URL qui changent, garder vos métadonnées intactes et soumettre un sitemap mis à jour à Google Search Console après le lancement. La plupart des sites que nous avons migrés voient des améliorations de classement dans les 4-8 semaines suivantes en raison de meilleurs scores Core Web Vitals.
Qu'en est-il des sites MODX avec des formulaires FormIt et des flux de travail complexes ?
Les formulaires sont l'une des parties les plus délicates de la migration. FormIt gère la validation, l'envoi d'email, les hooks et la prévention du spam, tout dans un package. Dans Next.js, vous allez généralement combiner les Server Actions pour le traitement, Zod pour la validation et un service comme Resend ou SendGrid pour la livraison d'email. C'est plus explicite mais aussi plus testable et fiable.
Est-ce que Next.js est une surpuissance pour un simple site brochure ?
Peut-être. Si votre site MODX est littéralement 10 pages statiques avec un formulaire de contact, Astro pourrait être un meilleur ajustement — il expédie zéro JavaScript par défaut et est plus simple à configurer. Mais s'il y a une chance que vous ayez besoin de fonctionnalités dynamiques, d'authentification ou de récupération de données complexe plus tard, commencer avec Next.js vous sauve d'une autre migration plus tard.
Que se passe-t-il avec mes extras et snippets personnalisés MODX ?
Ils doivent être reconstruits. Il n'y a pas de conversion automatisée. Les snippets personnalisés deviennent des routes API ou des Server Actions dans Next.js. Les extras comme Gallery, Articles ou MIGX sont remplacés par les fonctionnalités natives de votre CMS headless (qui sont généralement meilleures). Les extras e-commerce comme Foxy ou SimpleCart seraient remplacés par l'API Storefront Shopify, Snipcart ou Medusa. Planifiez explicitement cet effort dans votre ligne du temps de migration.
Comment je convaincs mes parties prenantes non techniques d'approuver cette migration ?
Concentrez-vous sur trois choses qui les intéressent : risque, coût et résultats. Risque : la communauté rétrécissante de MODX signifie que trouver des développeurs pour les urgences devient de plus en plus difficile chaque année. Coût : la maintenance du serveur et les patchs de sécurité ne sont pas gratuits, même si la licence CMS l'est. Résultats : montrez-leur la comparaison Core Web Vitals et expliquez comment Google utilise la vitesse de page comme facteur de classement. Si leurs concurrents se chargent en moins d'une seconde et qu'ils sont à 3 secondes, c'est un problème commercial.
Puis-je migrer progressivement ou doit-ce être tout d'un coup ?
La migration progressive est possible en utilisant une configuration reverse proxy — vous serviriez des nouvelles pages depuis Next.js et routeriez les pages héritées vers votre serveur MODX. Nous avons fait cela avec des configurations nginx où les chemins spécifiques sont proxifiés vers l'ancien serveur tandis que tout le reste va au déploiement Next.js. Cela ajoute de la complexité, mais pour les sites avec des centaines de pages, cela vous permet de migrer par phases sur des semaines ou des mois plutôt que de faire un basculement risqué et brutal.
Si vous utilisez un site MODX et ressentez les points douloureux que j'ai décrits, le meilleur moment pour commencer à planifier est maintenant. Pas parce que le ciel tombe, mais parce que les migrations faites sous pression — après une violation de sécurité, après que votre développeur démissionne, après qu'une version PHP atteigne la fin de vie — sont toujours plus coûteuses et plus stressantes que les migrations planifiées. Contactez-nous si vous voulez discuter de votre situation spécifique. Nous avons traversé cela assez de fois pour savoir où se trouvent les pièges.