Migration de Movable Type vers Next.js pour les entreprises japonaises

Si vous avez travaillé avec des sites Web d'entreprises japonaises pendant un certain temps, vous avez presque certainement rencontré Movable Type. Le CMS de Six Apart a eu une emprise remarquablement forte sur le marché japonais depuis le milieu des années 2000, alimentant tout, des sites d'entreprises des grands fabricants aux portails gouvernementaux et aux sites Web universitaires. Mais voilà -- nous sommes en 2026, et le Web a progressé. Votre installation Movable Type n'a probablement pas suivi.

J'ai aidé à migrer plusieurs sites d'entreprises japonaises hors de Movable Type au cours des deux dernières années, et je vais être honnête : ce n'est pas un projet trivial. Il y a des particularités autour de l'encodage des caractères, des structures de contenu uniques aux sites d'entreprises japonaises, et des préoccupations organisationnelles qui rendent ces migrations différentes de votre migration WordPress-vers-Next.js typique. Ce guide couvre tout ce que j'ai appris à la dure.

Movable Type to Next.js Migration Guide for Japanese Companies

Table des matières

Pourquoi les entreprises japonaises abandonnent Movable Type

Soyons clairs : Movable Type n'est pas mort. Six Apart Japan le maintient toujours, et Movable Type 8 (lancé fin 2024) a ajouté des fonctionnalités modernes. Mais les signes sont clairs pour plusieurs raisons.

Problèmes de performance

Movable Type utilise un modèle de publication statique -- il reconstruit les fichiers HTML lorsque le contenu change. Cela semble formidable jusqu'à ce que vous ayez un site avec 15 000 pages et un éditeur de contenu attendant 20 minutes que la reconstruction se termine. J'ai vu des sites d'entreprises japonaises où les éditeurs programmaient des reconstructions la nuit car le processus était si lent.

Next.js avec ISR (Incremental Static Regeneration) ou la revalidation à la demande résout ce problème complètement. Les pages se régénèrent individuellement en millisecondes.

Coût de possession

Les licences Movable Type au Japon coûtent environ ¥600 000-¥1 200 000 par an pour les licences d'entreprise à partir de 2026. C'est ¥4 000-¥8 000 USD annuels juste pour la licence CMS, avant l'hébergement, les plugins ou le développement personnalisé. Comparez cela à un CMS sans tête comme microCMS (populaire au Japon, à partir de ¥4 900/mois pour les plans professionnels) associé à Next.js sur Vercel, et les mathématiques commencent à se présenter très différemment.

Pénurie de développeurs

C'est le grand sujet que personne n'aborde publiquement. Trouver des développeurs qui connaissent Perl (le langage de Movable Type) et qui sont disposés à travailler sur les modèles MT devient vraiment difficile au Japon. L'âge médian des développeurs expérimentés en MT que j'ai rencontrés dépasse 45 ans. Pendant ce temps, les développeurs Next.js sont partout -- c'est le framework pour lequel les entreprises technologiques japonaises embauchent en 2026.

Sécurité et conformité

Movable Type a eu plusieurs CVE graves au fil des ans, notamment la fameuse vulnérabilité XMLRPC (CVE-2021-20837) qui a été activement exploitée contre les sites japonais. Avec les exigences de l'APPI modifié (Loi sur la protection des informations personnelles) au Japon se resserrant en 2025-2026, les entreprises réévaluent leur posture de sécurité.

Comprendre l'architecture de Movable Type

Avant de pouvoir migrer, vous devez comprendre ce que vous migrez. Le modèle de données de Movable Type est différent de WordPress ou de la plupart des CMS modernes.

Structures de données principales

Concept MT Description Équivalent Next.js/Sans tête
Blog Conteneur de contenu de niveau supérieur Site ou espace de travail
Entry Article de blog ou article Élément de contenu (type blog)
Page Page statique Élément de contenu (type page)
Category Taxonomie hiérarchique Système de catégories/étiquettes
Template Modèles HTML avec balises MT Composants React + dispositions
Custom Field Champs d'entrée étendus Champs du modèle de contenu
Asset Fichiers multimédias téléchargés Bibliothèque de médias/actifs
Website Conteneur parent pour les blogs Configuration multi-sites

Le langage de modèle de Movable Type utilise des balises comme <mt:EntryTitle> et <mt:Entries>. Ces balises ne correspondent pas 1:1 à quoi que ce soit dans la pile moderne -- vous reconstruirez complètement la couche de présentation.

La couche base de données

MT prend en charge MySQL, PostgreSQL et SQLite. La plupart des installations d'entreprises japonaises utilisent MySQL. Le schéma de base de données est bien documenté mais... excentrique. Les champs personnalisés sont stockés dans une table mt_entry_meta séparée utilisant un modèle clé-valeur, ce qui rend l'extraction non triviale.

Voici à quoi ressemble la table d'entrée :

SELECT 
  entry_id,
  entry_title,
  entry_text,
  entry_text_more,
  entry_excerpt,
  entry_created_on,
  entry_modified_on,
  entry_basename,
  entry_status
FROM mt_entry
WHERE entry_blog_id = 1
  AND entry_status = 2  -- 2 = published
ORDER BY entry_created_on DESC;

Notez la division entry_text et entry_text_more. MT divise le contenu du corps en deux champs -- un modèle de l'ère du blogage précoce que vous devrez concaténer lors de la migration.

Movable Type to Next.js Migration Guide for Japanese Companies - architecture

Choisir votre backend CMS sans tête

Next.js est votre framework frontend. Mais vous devez quelque part gérer le contenu. Pour les entreprises japonaises, je l'ai réduit à quatre options réalistes.

microCMS

C'est le choix par défaut pour les entreprises japonaises, et pour une bonne raison. C'est construit par une entreprise japonaise, a une interface utilisateur japonaise native, un support client japonais, et une résidence de données au Japon. Le prix commence à ¥4 900/mois (Hobby est gratuit pour les petits projets). L'API est propre, le support webhook fonctionne bien avec Next.js ISR, et vos éditeurs de contenu n'auront pas besoin de compétences en anglais.

Newt

Un autre CMS sans tête fait au Japon qui gagne du terrain. C'est légèrement plus convivial pour les développeurs que microCMS et a une meilleure flexibilité de modélisation de contenu. Bonne option si votre site a des structures de contenu complexes.

Contentful

Le choix d'entreprise global. Support de localisation solide, excellent API, et un écosystème mature. L'inconvénient pour les entreprises japonaises : le support est en anglais, l'interface utilisateur est en anglais, et les prix sont en USD. À environ $300/mois pour le plan Team (prix 2026), c'est considérablement plus cher que les alternatives japonaises.

Sanity

Je mentionne Sanity parce qu'il est techniquement excellent, et son Studio personnalisable peut être configuré avec des étiquettes japonaises. Mais la courbe d'apprentissage est plus raide, et vous ne trouverez pas autant de développeurs japonais ayant l'expérience de Sanity.

CMS Interface utilisateur japonaise Résidence de données au Japon Prix de départ Meilleur pour
microCMS ✅ ✅ ¥4 900/mo La plupart des sites d'entreprises japonaises
Newt ✅ ✅ ¥3 300/mo Modèles de contenu complexes
Contentful ❌ ❌ (EU/US) ~$300/mo Entreprises globales
Sanity Partiel ❌ $99/mo (Team) Équipes axées sur les développeurs

Pour la plupart des entreprises japonaises migrant de Movable Type, je recommande microCMS ou Newt. La réduction de friction d'avoir tout en japonais vaut plus que vous ne le penseriez. Nous avons travaillé en détail avec tous ceux-ci par le biais de notre pratique de développement CMS sans tête.

Audit de contenu et extraction de données

C'est là que le vrai travail commence. Ne sautez pas la phase d'audit -- j'ai vu des migrations échouer parce que les équipes ont sauté directement à l'extraction sans comprendre ce qu'elles avaient réellement.

Étape 1 : Inventorier tout

Connectez-vous à votre base de données MT et exécutez les comptages :

-- Count entries by blog
SELECT 
  b.blog_name,
  COUNT(e.entry_id) as entry_count
FROM mt_entry e
JOIN mt_blog b ON e.entry_blog_id = b.blog_id
WHERE e.entry_status = 2
GROUP BY b.blog_name;

-- Count custom fields per blog
SELECT 
  b.blog_name,
  em.entry_meta_type,
  COUNT(*) as field_count
FROM mt_entry_meta em
JOIN mt_entry e ON em.entry_meta_entry_id = e.entry_id
JOIN mt_blog b ON e.entry_blog_id = b.blog_id
GROUP BY b.blog_name, em.entry_meta_type;

Étape 2 : Exporter le contenu

MT a un format d'exportation intégré, mais il est limité. Je préfère l'extraction directe de base de données avec un script Python :

import mysql.connector
import json
import html

def extract_mt_entries(config):
    conn = mysql.connector.connect(**config)
    cursor = conn.cursor(dictionary=True)
    
    cursor.execute("""
        SELECT 
            e.entry_id,
            e.entry_title,
            e.entry_text,
            e.entry_text_more,
            e.entry_excerpt,
            e.entry_basename,
            e.entry_created_on,
            e.entry_modified_on,
            GROUP_CONCAT(c.category_label) as categories
        FROM mt_entry e
        LEFT JOIN mt_placement p ON e.entry_id = p.placement_entry_id
        LEFT JOIN mt_category c ON p.placement_category_id = c.category_id
        WHERE e.entry_status = 2
        GROUP BY e.entry_id
    """)
    
    entries = cursor.fetchall()
    
    for entry in entries:
        # Combine text and text_more
        body = (entry['entry_text'] or '') + (entry['entry_text_more'] or '')
        entry['full_body'] = body
        # Handle encoding
        entry['entry_title'] = entry['entry_title']
    
    with open('mt_export.json', 'w', encoding='utf-8') as f:
        json.dump(entries, f, ensure_ascii=False, default=str, indent=2)
    
    return entries

Étape 3 : Migration d'actifs médias

MT stocke les actifs sur le système de fichiers, généralement sous /path/to/mt/support/uploads/. Vous devrez :

  1. Inventorier tous les fichiers et les faire correspondre aux enregistrements de base de données dans mt_asset
  2. Réuploadé vers votre nouveau CMS ou un CDN (Cloudinary, imgix, ou le stockage intégré de votre CMS)
  3. Mettre à jour toutes les références dans votre HTML de corps de contenu

C'est fastidieux. Prévoyez du temps pour cela.

Gestion des spécificités du contenu japonais

Cette section est la raison pour laquelle j'ai écrit cet article. Les guides de migration génériques ne couvrent pas ces problèmes.

Encodage des caractères

Les installations Movable Type plus anciennes (pré-MT5) stockaient parfois le contenu en encodage EUC-JP ou Shift_JIS, même si la base de données était nominalement UTF-8. Vérifiez vos données réelles :

# Detect encoding issues
import chardet

def check_encoding(text_bytes):
    result = chardet.detect(text_bytes)
    if result['encoding'] != 'utf-8':
        print(f"Warning: detected {result['encoding']} "
              f"with {result['confidence']:.0%} confidence")
    return result

Si vous trouvez des anomalies d'encodage, convertissez tout en UTF-8 avant d'importer dans votre nouveau CMS. Du mojibake cassé (文字化け) sur un site d'entreprise est un événement qui limite les carrières.

Texte Ruby (Furigana)

Les sites d'entreprises japonaises utilisent fréquemment des annotations ruby -- de petites aides à la lecture au-dessus des caractères kanji. Les modèles MT traitent souvent ceux-ci avec des balises personnalisées. Dans Next.js, vous utiliserez des éléments HTML <ruby> standard :

// components/RubyText.tsx
export function RubyText({ base, reading }: { base: string; reading: string }) {
  return (
    <ruby>
      {base}
      <rp>(</rp>
      <rt>{reading}</rt>
      <rp>)</rp>
    </ruby>
  );
}

Assurez-vous que votre script de migration de contenu préserve tout balisage ruby existant.

Formatage des dates japonaises

Les sites d'entreprises japonaises affichent souvent les dates au format 和暦 (format d'ère japonaise) : 令和8年1月15日 au lieu de 2026-01-15. Gérez cela dans vos composants Next.js :

function formatJapaneseDate(dateString: string): string {
  const date = new Date(dateString);
  return date.toLocaleDateString('ja-JP-u-ca-japanese', {
    era: 'long',
    year: 'numeric',
    month: 'long',
    day: 'numeric',
  });
}

Dispositions de texte vertical

Certains sites japonais, en particulier dans l'édition ou les industries traditionnelles, utilisent du texte vertical (縦書き). CSS gère cela :

.vertical-text {
  writing-mode: vertical-rl;
  text-orientation: mixed;
}

Next.js gère cela bien, mais testez à fond sur les navigateurs.

Construction du frontend Next.js

Avec votre contenu extrait et votre CMS choisi, il est temps de construire. Voici l'architecture que je recommande pour les sites d'entreprises japonaises.

App Router avec génération statique

Utilisez App Router de Next.js 15 avec la génération statique pour la plupart des pages. Les sites d'entreprises japonais sont généralement chargés en contenu avec des mises à jour peu fréquentes -- parfait pour la génération statique avec revalidation à la demande.

// app/news/[slug]/page.tsx
import { getArticle, getAllArticleSlugs } from '@/lib/cms';

export async function generateStaticParams() {
  const slugs = await getAllArticleSlugs();
  return slugs.map((slug) => ({ slug }));
}

export default async function NewsArticle({ 
  params 
}: { 
  params: Promise<{ slug: string }> 
}) {
  const { slug } = await params;
  const article = await getArticle(slug);
  
  return (
    <article>
      <h1>{article.title}</h1>
      <time dateTime={article.publishedAt}>
        {formatJapaneseDate(article.publishedAt)}
      </time>
      <div dangerouslySetInnerHTML={{ __html: article.body }} />
    </article>
  );
}

Configuration i18n

De nombreux sites d'entreprises japonaises ont besoin à la fois de versions japonaises et anglaises. Next.js App Router gère cela avec des groupes de routes ou la détection de locale basée sur les middlewares :

// middleware.ts
import { NextRequest, NextResponse } from 'next/server';

export function middleware(request: NextRequest) {
  const pathname = request.nextUrl.pathname;
  const locale = pathname.startsWith('/en') ? 'en' : 'ja';
  
  request.headers.set('x-locale', locale);
  return NextResponse.next();
}

Nous avons construit des dizaines de sites d'entreprises japonais bilingues utilisant Next.js -- notre équipe de développement Next.js peut vous guider à travers les nuances.

Stratégie de migration SEO pour la recherche japonaise

C'est non-négociable. Les entreprises japonaises vivent et meurent par leurs classements de recherche Google (Yahoo! Japan utilise le moteur de recherche de Google, donc c'est vraiment juste Google). Une migration mal exécutée peut détruire le trafic organique pendant des mois.

Mappage des URL

Movable Type génère des URL avec des modèles configurables. Les modèles courants que j'observe sur les sites japonais :

  • /blog/2024/01/entry-basename.html
  • /news/category/entry_basename.html
  • /archives/000123.html (le modèle le plus ancien)

Créez un mappage d'URL complet avant de construire quoi que ce soit :

// scripts/generate-redirects.ts
interface RedirectMap {
  source: string;
  destination: string;
  permanent: boolean;
}

function generateRedirects(mtEntries: MTEntry[]): RedirectMap[] {
  return mtEntries.map(entry => ({
    source: buildMTUrl(entry),  // Old MT URL pattern
    destination: `/news/${entry.entry_basename}`,  // New Next.js URL
    permanent: true,  // 301 redirect
  }));
}

Mettez-les dans votre next.config.ts :

const nextConfig = {
  async redirects() {
    const redirects = await import('./redirects.json');
    return redirects.default;
  },
};

Pour les sites avec des milliers de redirections, utilisez plutôt les middlewares -- les redirections next.config.ts ont une limite pratique.

Données structurées

Les résultats Google japonais mettent en vedette fortement les extraits enrichis. Ajoutez JSON-LD pour les articles, les FAQ et les informations organisationnelles :

function ArticleJsonLd({ article }: { article: Article }) {
  const jsonLd = {
    '@context': 'https://schema.org',
    '@type': 'Article',
    headline: article.title,
    datePublished: article.publishedAt,
    dateModified: article.updatedAt,
    author: {
      '@type': 'Organization',
      name: article.companyName,
    },
    inLanguage: 'ja',
  };

  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(jsonLd) }}
    />
  );
}

Déploiement et infrastructure

Pour les audiences japonaises, la latence compte. Voici ce qui fonctionne :

Plateforme Nœuds Edge au Japon Meilleur pour Coût mensuel typique
Vercel Tokyo La plupart des sites Next.js $20-150/mo
AWS (CloudFront + Lambda@Edge) Tokyo, Osaka Conformité d'entreprise $100-500/mo
Google Cloud Run + Cloud CDN Tokyo Équipes natives GCP $50-200/mo
Cloudflare Pages Tokyo + beaucoup Sites statiques simples Free-$25/mo

Vercel est ma recommandation par défaut. C'est construit pour Next.js, a un nœud edge à Tokyo, et l'UX est inégalée. Pour les entreprises avec des exigences strictes de résidence de données (gouvernement, finance), AWS dans ap-northeast-1 (Tokyo) est le choix sûr.

Si vous envisagez Astro au lieu de Next.js pour un site riche en contenu avec une interactivité minimale, c'est un choix valide aussi -- vérifiez nos capacités de développement Astro.

Planification de la chronologie et du budget

Basé sur les migrations réelles que j'ai complétées, voici à quoi s'attendre :

Phase Durée Activités clés
Découverte et audit 2-3 semaines Inventaire de contenu, entretiens avec les parties prenantes, mappage d'URL
Configuration CMS et modélisation de contenu 2-4 semaines Conception de schéma, scripts de migration de contenu
Migration de contenu 3-6 semaines Transfert de données, migration de médias, assurance qualité
Développement du frontend 6-10 semaines Construction Next.js, bibliothèque de composants, i18n
SEO et assurance qualité 2-3 semaines Test de redirection, optimisation des performances, assurance qualité multi-navigateurs
Déploiement échelonné 1-2 semaines Changement de DNS, surveillance, correctifs d'urgence

Total : 16-28 semaines pour un site d'entreprise japonais typique avec 1 000-10 000 pages.

En termes de budget, vous envisagez ¥5 000 000-¥15 000 000 ($33 000-$100 000 USD) selon la complexité. Cela peut sembler beaucoup, mais considérez : vous payez probablement plus de ¥1 000 000 annuels pour les licences MT et le développement spécialisé déjà. La migration se paie d'elle-même dans les 2-3 ans grâce à la réduction des coûts opérationnels et à l'amélioration de la vélocité des développeurs.

Besoin d'une estimation détaillée pour votre situation spécifique ? Contactez-nous ou vérifiez notre page de tarification pour les modèles d'engagement.

FAQ

Pouvons-nous continuer à utiliser Movable Type comme CMS sans tête avec Next.js ?

Techniquement oui -- Movable Type 7+ a une Data API qui peut servir le contenu à un frontend. Mais c'est lent, mal documenté, et manque de webhooks pour la revalidation. J'ai essayé cette approche sur un projet et je ne la recommanderais pas. Vous passerez plus de temps à contourner les limitations de l'API MT que vous le feriez à migrer vers un vrai CMS sans tête.

Comment gérons-nous le modèle de reconstruction MT par rapport à Next.js ISR ?

Ils sont fondamentalement différents. MT reconstruit les sections de site entières à la fois (génération statique batch). Next.js ISR régénère les pages individuelles à la demande. Cela signifie que vos éditeurs obtiennent des temps de publication instantanés au lieu d'attendre les reconstructions. Le changement de modèle mental est en fait plus facile pour les éditeurs -- ils appuient juste sur publier et la page est active en quelques secondes.

Que se passe-t-il avec nos plugins MT pendant la migration ?

Chaque plugin MT a besoin d'un remplacement ou d'une réimplémentation. Les plugins courants comme les formulaires de contact (plugins de formulaire basés sur MT) sont remplacés par la gestion de formulaires Next.js ou des services comme Formspree. Les plugins de recherche sont remplacés par Algolia ou la recherche intégrée du CMS. Faites un inventaire complet des plugins pendant la phase d'audit.

Nos classements Google baisseront-ils pendant la migration ?

Ils peuvent, mais ce n'est pas obligatoire. Les facteurs critiques sont : les redirections 301 pour chaque URL, le maintien des titres et des métadescriptions identiques ou améliorés, la préservation de la structure des liens internes, et la soumission d'un plan du site mis à jour. J'ai vu des migrations où les classements se sont réellement améliorés parce que le nouveau site était plus rapide et avait de meilleurs scores Core Web Vitals.

Comment gérons-nous les éléments SEO spécifiques au Japon comme Yahoo! Japan ?

Yahoo! Japan a utilisé le moteur de recherche de Google depuis 2010, donc votre stratégie SEO Google couvre Yahoo! aussi. La seule exception est celle des propres propriétés de Yahoo! Japan (Yahoo! News, etc.) qui ont des processus de soumission séparés. Pour la recherche organique générale, concentrez-vous sur Google et vous êtes couvert.

Devrions-nous migrer tout le contenu ou utiliser ceci comme une opportunité de nettoyage ?

Toujours nettoyer. Dans chaque migration de site d'entreprise japonais que j'ai faite, 30-50% du contenu était périmé, redondant, ou avait zéro trafic. Migrer du contenu mort gaspille du temps et dilue l'autorité topique de votre site. Utilisez les données d'analyse pour identifier les pages qui valent la peine d'être migrées et laissez le reste aller (avec des réponses 410 Gone appropriées, pas 404s).

Pouvons-nous exécuter Movable Type et Next.js en parallèle pendant la migration ?

Oui, et je le recommande. Utilisez un sous-domaine ou le routage basé sur les chemins pour servir le nouveau site Next.js pour les sections migrées tandis que MT gère le reste. Cela vous permet de migrer par phases plutôt que de faire un cutover risqué en big-bang. Les configurations de proxy inverse avec nginx ou Cloudflare Workers rendent cela simple.

Qu'en est-il du contrôle d'accès intégré de Movable Type et des fonctionnalités de membres ?

Si votre site MT utilise la connexion de membres, le contenu verrouillé ou le contrôle d'accès basé sur les rôles, vous devrez implémenter l'authentification dans Next.js. NextAuth.js (maintenant Auth.js) fonctionne bien pour cela, ou vous pouvez utiliser un service comme Clerk ou Auth0. Cela ajoute de la complexité et des coûts -- intégrez-les dans votre planification dès le départ.