Votre serveur de staging termine la reconstruction du cache TYPO3 — quarante-trois secondes pour une modification de contenu qui devrait prendre deux secondes. Votre développeur frontend rafraîchit le navigateur, voit la mise à jour, et marmonne quelque chose sur TypoScript que vous ne devriez probablement pas répéter en standup. Cette scène se joue quotidiennement dans les entreprises à travers l'Europe, où TYPO3 a alimenté des portails gouvernementaux et des sites d'entreprise pendant deux décennies. Le CMS fonctionne toujours, techniquement. Mais l'architecture orientée composants de Drupal, sa boîte à outils headless et une base de contributeurs dix fois plus importante rendent la conversation sur la migration inévitable. La question n'est pas de savoir si vous allez migrer — c'est comment migrer 8 000 pages, préserver vingt ans d'équité d'URL et garder vos rédacteurs de contenu sains d'esprit pendant la transition. Nous avons exécuté ce plan six fois au cours des dix-huit derniers mois, et la différence entre une migration propre et une catastrophe se résume à quatre décisions que vous prendrez la première semaine.

Je me suis plongé dans quelques migrations TYPO3 vers Drupal au cours des deux dernières années, et ça a été tout un voyage de démêler les modèles de contenu du monde réel. C'est généralement un fouillis emmêlé. Ce guide est ce que j'aurais aimé qu'on me donne avant ma première migration. Je couvrirai tous les détails techniques épineux, les incontournables de la planification, et ces pièges délicats qui peuvent torpiller votre calendrier si vous ne faites pas attention.

Table des matières

TYPO3 to Drupal Migration: A Practical Developer's Guide

Pourquoi les organisations quittent TYPO3

Soyons clairs : TYPO3 n'est pas un mauvais CMS. C'est extrêmement flexible, gère les configurations multi-sites et multilingues en natif, et jouit d'une base de fans dévouée, particulièrement dans la région DACH. Alors pourquoi les gens abandonnent-ils le navire ?

J'entends à peu près les mêmes raisons chaque fois :

Disponibilité des développeurs. En dehors de l'Europe centrale, trouver des développeurs TYPO3 est aussi difficile que de trouver une aiguille dans une botte de foin. Drupal, en revanche, revendique environ 1,3 million de développeurs mondialement, selon le rapport de la communauté 2024 de Drupal.org. TYPO3 ? Pas vraiment. Si vos développeurs TYPO3 seniors décident de partir, combler ces postes pourrait prendre une éternité.

L'élan de l'écosystème. Avec la sortie de Drupal 11 fin 2024, il y a eu des avancées énormes dans l'interface administrateur, un nouveau système de recettes et d'excellentes capacités API-first. Bien sûr, TYPO3 v13 est solide, mais le taux d'innovation dans Drupal, particulièrement autour des configurations headless, est notablement plus rapide.

Architecture headless/découplée. Prévoyez-vous de servir du contenu à un beau frontend Next.js ou Astro ? Les plugins JSON:API et GraphQL de Drupal sont des professionnels chevronnés. TYPO3 a sa propre extension headless, mais elle est moins mûre avec un soutien plus faible.

Coût total de possession. L'hébergement de TYPO3 frappe généralement au portefeuille plus fort. Son infrastructure spécialisée signifie que vous pourriez finir par dépenser plus. L'infrastructure de Drupal fonctionne pratiquement n'importe où de Pantheon à Acquia, même une simple pile LAMP la garde ronronnante.

TYPO3 vs Drupal : Une comparaison honnête

Avant de plonger tête baissée dans une migration, assurez-vous que Drupal va vraiment résoudre vos points faibles. Voici le résumé à partir de 2026 :

Fonctionnalité TYPO3 v13 Drupal 11
Modélisation de contenu Flexible mais penche sur TCA Système Entité/Champ avec interface de gestion des champs
Multilingue Support natif stellaire Support natif tout aussi stellaire
Multi-site Multi-site standard avec arbres de contenu Possible, souvent mieux avec Domain Access ou installations séparées
Headless/API A une extension headless JSON:API dans le noyau, GraphQL en contrib
Modélisation Modèles de templates Fluid + TypoScript Utilise les templates Twig
Écosystème d'extensions/modules ~1 800 extensions sur TER ~50 000+ modules sur Drupal.org
Interface administrateur Forte, mais datée (refonte en v13) Élégante et moderne dans Drupal 11
Communauté de développeurs ~500 contributeurs actifs 8 000+ contributeurs actifs
Options d'hébergement Auto-hébergé ou spécialisé Auto-hébergé, Pantheon, Acquia, Platform.sh, Lagoon
Prérequis PHP PHP 8.2+ PHP 8.3+
Taux d'agence typique €100-180/hr (région DACH) $80-200/hr (mondial)

Le modèle d'arbre de pages de TYPO3 est un trésor rare. Les rédacteurs habitués à gérer des hiérarchies de pages élaborées dans TYPO3 pourraient trouver le style de Drupal — la combinaison de types de contenu et de taxonomie — nécessite un ajustement. Planifiez une formation des rédacteurs pour faciliter cette transition.

Audit et planification pré-migration

Cette étape détermine le sort de la plupart des migrations. Tout est dans la planification, pas dans les délais techniques.

Inventaire du contenu

Commencez par auditer tout dans votre configuration TYPO3 :

  • Pages : Extrayez cet arbre de pages, en documentant chaque doktype (type de page) en jeu.
  • Éléments de contenu : Chaque CType (type de contenu) a besoin d'attention — qu'il s'agisse de texte, texte avec image, HTML, ou des trucs personnalisés via mask ou content_defender.
  • Extensions : Notez chaque extension que vous avez. Découvrez s'il existe un équivalent Drupal.
  • Références de fichiers : La FAL (File Abstraction Layer) de TYPO3 traite les médias. Cartographiez-les vers les emplacements multimédias de Drupal.
  • Utilisateurs backend et permissions : Les groupes d'utilisateurs backend sophistiqués de TYPO3 avec accès au niveau de la page et du champ doivent être soigneusement traduits en rôles et permissions Drupal.

Voici une requête SQL pratique pour un aperçu des éléments de contenu de votre base de données TYPO3 :

SELECT CType, COUNT(*) as count 
FROM tt_content 
WHERE deleted = 0 AND hidden = 0 
GROUP BY CType 
ORDER BY count DESC;

Avec cela, vous obtenez un aperçu rapide des types de contenu avec lesquels vous êtes emmêlé. Dans un cas, j'ai découvert une instance TYPO3 possédant 40+ types d'éléments de contenu personnalisés, dont seulement une douzaine étaient activement utilisés. Ne traînez pas le poids mort.

Ce qu'il faut garder, ce qu'il faut abandonner

Voici votre chance de nettoyer votre maison. Utilisez un outil d'audit de contenu comme Screaming Frog ou Sitebulb pour rechercher :

  • Pages sans trafic au cours de la dernière année
  • Contenu dupliqué ou presque identique
  • Liens internes cassés
  • Fichiers multimédias orphelins

Typiquement, il y a une réduction de contenu de 30-50% dans les grandes migrations TYPO3. Moins de pages signifie des migrations plus rapides.

TYPO3 to Drupal Migration: A Practical Developer's Guide - architecture

Modélisation de contenu : Cartographier TYPO3 vers Drupal

Roulons les manches. C'est le lourd travail intellectuel. TYPO3 et Drupal gèrent le contenu très différemment.

Le modèle TYPO3

TYPO3 tourne autour des pages. Tout est rangé dans un arbre de pages. Les éléments de contenu (enregistrements dans tt_content) se glissent sur les pages dans les colonnes (colPos). Les enregistrements personnalisés définis via les modèles Extbase ou TCA résident dans des tables séparées mais sont généralement liés à partir des pages.

Le modèle Drupal

Drupal parle d'entités. Vous créez des types de contenu (bundles de nœud), chacun avec des champs dédiés. Les pages ne sont qu'une parmi de nombreuses types de contenu. La taxonomie, les paragraphes (utilisant le module Paragraphs), et Layout Builder maîtrisent la composition de contenu structuré.

La cartographie

Voici un tableau de cartographie typique que j'utilise comme ma boussole :

Concept TYPO3 Équivalent Drupal
Page (doktype : standard) Nœud (type de contenu : Page)
Page (doktype : shortcut) Redirection d'URL
Page (doktype : link) Nœud avec champ de lien ou redirection
Élément de contenu (CType : text) Type de paragraphe ou champ Corps
Élément de contenu (CType : image) Référence d'entité multimédias
Élément de contenu (CType : textpic) Type de paragraphe avec texte + média
Élément de contenu (CType : gridelements) Section Layout Builder
Référence de fichier FAL Entité multimédia
sys_category Terme de taxonomie
fe_users Entité utilisateur Drupal
be_users Entité utilisateur Drupal avec rôle admin
Template TypoScript Template Twig
Plugin Extbase Module Drupal personnalisé
Éléments de contenu Mask/DCE Types de paragraphes

Le plus grand changement ? Déplacer les éléments de contenu vers Paragraphs. TYPO3 empile les éléments de contenu dans les colonnes de pages, ce qui s'adapte bien au module Paragraphs de Drupal. Les rédacteurs empilent les pages à partir de types de paragraphes réutilisables — c'est étonnamment transparent.

Outils de migration et approche technique

L'API Migrate de Drupal rocke. Mais attention, il manque un plugin source TYPO3 natif. Vous devrez créer des plugins source personnalisés pour extraire de la base de données de TYPO3.

Approche 1 : Migration directe de base de données

Branchez l'API Migrate de Drupal directement sur votre base de données MySQL/MariaDB TYPO3 :

// Exemple de plugin de source de migration pour les pages TYPO3
namespace Drupal\typo3_migrate\Plugin\migrate\source;

use Drupal\migrate\Plugin\migrate\source\SqlBase;
use Drupal\migrate\Row;

/**
 * @MigrateSource(id = "typo3_pages")
 */
class Typo3Pages extends SqlBase {

  public function query() {
    return $this->select('pages', 'p')
      ->fields('p', ['uid', 'title', 'slug', 'abstract', 'doktype', 'crdate', 'tstamp'])
      ->condition('p.deleted', 0)
      ->condition('p.hidden', 0)
      ->condition('p.doktype', [1, 4], 'IN');
  }

  public function fields() {
    return [
      'uid' => $this->t('Page ID'),
      'title' => $this->t('Titre de la page'),
      'slug' => $this->t('Slug URL'),
      'abstract' => $this->t('Résumé/abstract'),
    ];
  }

  public function getIds() {
    return ['uid' => ['type' => 'integer']];
  }

  public function prepareRow(Row $row) {
    // Chargez les éléments de contenu associés
    $pid = $row->getSourceProperty('uid');
    $content = $this->select('tt_content', 'tt')
      ->fields('tt')
      ->condition('tt.pid', $pid)
      ->condition('tt.deleted', 0)
      ->orderBy('tt.sorting')
      ->execute()
      ->fetchAll();
    $row->setSourceProperty('content_elements', $content);
    return parent::prepareRow($row);
  }
}

J'aime cette approche. C'est comme avoir le contrôle total et vous permet de traiter les particularités de TYPO3 (comme les suppressions logiques et les recouvrements d'espace de travail) dans votre codebase.

Approche 2 : Exporter/importer via JSON ou XML

Certaines équipes choisissent d'exporter le contenu TYPO3 dans des formats structurés (par exemple, via des extensions TYPO3 personnalisées ou des commandes CLI) puis de les importer dans Drupal. Bien sûr, cela ajoute une autre couche mais s'avère utile si vous êtes méfiant face au maintien de connexions directes à la base de données pendant la migration.

Approche 3 : Hybride avec examen manuel

Vous avez un site plus petit (moins de 500 pages) ? Faire une migration de données structurées automatiquement tout en concevant manuellement les pages d'accueil clés peut fonctionner à merveille. Cela pourrait sembler rudimentaire, mais quand le contenu est entrelacé avec la logique de rendu spécifique à TYPO3, la migration automatisée aboutit souvent à du charabia.

Gestion de TypoScript et des extensions TYPO3

TypoScript

Soyons directs : TypoScript ne migre pas. C'est un langage de configuration spécifique à TYPO3, sans véritable contrepartie ailleurs. Votre travail consiste à documenter ce que chaque template TypoScript fait en termes simples, puis à le reconstruire sous forme de templates Twig et de configuration Drupal. C'est laborieux mais nécessaire.

Extensions

Voici une comparaison pratique des extensions TYPO3 courantes et de leurs équivalents Drupal :

Extension TYPO3 Équivalent Drupal
news Type de contenu du noyau + Vues
powermail Module Webform
solr (ext:solr) API de recherche + Solr
realurl / routing Pathauto + routage du noyau
gridelements Layout Builder ou Paragraphs
mask Paragraphs
tt_address Type de contenu personnalisé ou CiviCRM
ke_search API de recherche
femanager Module utilisateur + personnalisé
cal/events Type de contenu personnalisé + Vues

Les extensions Extbase personnalisées doivent être réécrites en tant que modules Drupal. Pas de raccourcis — assurez-vous de budgétiser pour cela.

Structure d'URL et préservation du référencement

Gâchez cela, et vous perdrez du trafic organique. J'ai vu des organisations perdre jusqu'à 40% de leur trafic de recherche post-migration en raison de redirections mal gérées.

Étapes

  1. Exportez toutes les URLs de TYPO3. Utilisez un outil CLI ou un crawler pour chaque URL indexée.
  2. Cartographiez-les vers les URLs Drupal. Utilisez Pathauto de Drupal pour la génération d'alias d'URL, en restant proche des URLs existantes.
  3. Créez des redirects pour tout ce qui change. Déployez le module Redirect dans Drupal. Pour des montagnes de redirects, importez via CSV.
  4. Gérez les préfixes de langue. TYPO3 utilise /de/, /en/, /fr/ - assurez-vous que les paramètres de langue de Drupal reflètent cela.
  5. Soumettez les sitemaps mis à jour à Google Search Console immédiatement.
# Exemple de format CSV d'import de redirection pour le module Redirect de Drupal
source,redirect,status_code,language
/alte-seite,/new-page,301,de
/old-page/subpage,/new-page/subpage,301,en
/kontakt,/contact,301,de

Conseil de pro : Gardez l'ancienne instance TYPO3 en direct, bien que en lecture seule, pendant au moins trois mois post-migration. Vous découvrirez des URLs manquées.

Aller headless après la migration

Drupal brille dans son chemin vers un frontend découplé. Avec Drupal 11, le module JSON:API est solide comme un rocher, et l'écosystème Drupal headless prospère.

Si vous envisagez une approche headless — et en 2026, pour la plupart des sites orientés contenu, c'est à considérer — nous l'avons abordée en profondeur à /solutions/headless-cms-development.

Appairage des frontends populaires avec Drupal :

La beauté de la migration d'abord vers Drupal est de lancer avec le frontend Twig par défaut de Drupal. Plus tard, vous pouvez basculer vers un découplé. N'essayez pas les deux migrations à la fois — c'est demander le chaos du projet.

Estimations de chronologie, coût et ressources

Des chiffres réels de projets auxquels j'ai participé ou dont j'ai des données précises (années récentes) :

Taille du site Pages Chronologie Fourchette budgétaire Équipe
Petit <500 pages 2-3 mois 30 000-60 000 € 2-3 développeurs
Moyen 500-5 000 pages 4-6 mois 60 000-150 000 € 3-5 développeurs
Grand 5 000-50 000 pages 6-12 mois 150 000-400 000 € 5-8 développeurs
Entreprise 50 000+ pages 12-18 mois 400 000-1 000 000+€ 8-15 développeurs

Ceux-ci incluent tout, de la découverte, la modélisation de contenu, la migration, le thématage frontend, l'assurance qualité et la formation des rédacteurs. La maintenance continue n'est pas couverte ici.

Le grand facteur de coût n'est pas seulement le nombre de pages — c'est la complexité. Un site de 2 000 pages avec 30 types de contenu personnalisés et 4 langues coûtera plus cher qu'un simple site de 10 000 pages.

Considérez les spécificités de votre cas ? Consultez /pricing ou contactez-nous directement.

Liste de contrôle post-migration

Ne sautez pas cette liste de contrôle. Croyez-moi.

  • Vérifiez toutes les redirects. Assurez-vous qu'elles sont des 301s.
  • Mettez à jour Google Search Console avec votre nouveau sitemap.
  • Testez tous les formulaires : contact, infolettre, connexion.
  • Assurez l'exactitude du contenu multilingue pour chaque langue.
  • Migrez les fichiers multimédias avec précision avec le texte alt et les métadonnées.
  • Vérifiez les permissions de l'éditeur pour chaque rôle.
  • Capturez les métriques de performance (Core Web Vitals).
  • Vérifiez le suivi des analyses (événements GA4, objectifs).
  • Configurez et testez le CDN/mise en cache.
  • Activez les en-têtes de sécurité (CSP, HSTS).
  • Testez les systèmes de sauvegarde et de récupération après sinistre.
  • Complétez la formation des rédacteurs et livrez la documentation.
  • Gardez l'ancienne instance TYPO3 disponible en mode lecture seule.

FAQ

Combien de temps prend généralement une migration TYPO3 vers Drupal ?

Pour les sites de taille moyenne (500-5 000 pages), c'est environ 4-6 mois du démarrage au lancement. Le premier mois ? Purement découverte et modélisation de contenu. Les scripts de migration signifient généralement 6-8 semaines de travail. L'assurance qualité et la formation des rédacteurs ? Comptez un autre mois. Si c'est une configuration complexe multi-langue, multi-site avec extensions personnalisées, vous cherchez à 9-12 mois.

Puis-je migrer le contenu TYPO3 automatiquement, ou c'est manuel ?

Contenu structuré comme les pages, les dossiers de nouvelles ou les catégories ? Absolument un travail automatisé avec l'API Migrate de Drupal. Mais la logique de rendu complexe du contenu TYPO3 pourrait avoir besoin d'un peu de soin manuel. La plupart des migrations ? Environ 70-80% automatique, 20-30% manuel.

Vais-je perdre mes classements Google pendant la migration ?

Pas si vous êtes diligent avec vos redirects. Définissez ces 301s pour tout changement d'URL, tenez-vous à votre structure d'URL autant que possible, soumettez immédiatement ces sitemaps mis à jour. Vous verrez probablement une baisse, disons 2-6 semaines. Mais un rebond est typique — les sites rebondissent généralement aux niveaux pré-migration en 4-8 semaines et souvent voir des améliorations en trois mois en raison de meilleures performances.

Drupal est-il plus difficile à apprendre que TYPO3 pour les rédacteurs de contenu ?

Différent, pas plus difficile. Ceux habitués au modèle d'arbre de pages de TYPO3 pourraient avoir besoin de temps avec l'approche centrée sur l'entité de Drupal. Le module Paragraphs offre une expérience de construction de contenu quelque peu similaire. N'oubliez pas de budgétiser environ 2-3 jours de formation pour les rédacteurs et fournissez-leur une documentation spécifique au type de contenu et au flux de travail.

Que se passe-t-il avec mes extensions TYPO3 pendant la migration ?

Chaque extension mérite une évaluation individuelle. Beaucoup ont des équivalents Drupal directs (par exemple, powermail → Webform, ext:news → type de contenu personnalisé + Vues, ext:solr → API de recherche + Solr). Extensions Extbase personnalisées ? Elles devront être complètement réécrites en tant que modules Drupal. Il n'y a pas de convertisseur — vous devrez personnaliser.

Devrais-je aller headless lors de la migration de TYPO3 vers Drupal ?

Cela dépend de vos objectifs et de votre calendrier. Si votre déménagement est motivé par des préoccupations concernant les développeurs ou la maintenabilité, commencez simplement par le thématage Twig de Drupal, visez headless plus tard. Mais si votre équipe frontend adore React ou une configuration similaire, et que vous désirez une architecture de livraison moderne, envisagez de planifier headless dès le départ. Rappelez-vous simplement : faire les deux migrations et des changements de frontend à la fois ? C'est un territoire à haut risque.

Comment puis-je gérer le contenu multilingue dans la migration ?

La configuration de langue TYPO3 (sys_language_uid, l10n_parent) s'aligne bien avec le module Content Translation de Drupal. L'astuce ? Clous la cartographie langue-à-langue dans vos scripts et assurer que les replis correspondent à vos attentes. Soyez prudent avec le contenu partiellement traduit — les modes de recouvrements de langue de TYPO3 (libre, connecté, strict) n'ont pas de parallèles Drupal précis. Des appels éditoriaux sur les traductions incomplètes pourraient être nécessaires.

Quel est le ROI de la migration de TYPO3 vers Drupal ?

Où est le ROI ? Principalement en réduisant les dépenses de développeur et en accélérant le déploiement des fonctionnalités. Historiquement, les équipes que j'ai guidées voient une réduction d'environ 20-40% des coûts de développement en année un, principalement grâce à un recrutement de talents plus facile et à une plus grande réserve de modules qui réduit le besoin de développement personnalisé. Les coûts de migration initiaux peuvent être importants, mais la plupart devraient atteindre le seuil de rentabilité en 18-24 mois.