Migration TYPO3 vers Drupal : Guide pratique pour développeurs
Migrer de TYPO3 vers Drupal : Guide pratique pour développeurs
Si vous avez déjà fixé un backend TYPO3 en vous demandant « il doit y avoir une meilleure façon », croyez-moi, vous êtes loin d'être seul. TYPO3 a sa puissance – je ne vais pas le contester. C'est le CMS préféré des grandes entreprises et des sites gouvernementaux européens depuis plus de vingt ans. Mais soyons honnête, le paysage des développeurs a énormément changé. De nombreuses organisations découvrent que Drupal offre une configuration plus moderne, une communauté plus forte et un chemin plus facile vers des architectures headless/découplées.
J'ai été au cœur de quelques migrations TYPO3 vers Drupal au cours des deux dernières années, et cela a été toute une aventure de démêler les modèles de contenu du monde réel. C'est généralement un fouillis inextricable. Ce guide est ce que j'aurais aimé qu'on me remette avant ma première migration. Je vais couvrir tous les détails techniques importants, les étapes essentielles de la planification, et ces maudits pièges qui peuvent torpiller votre calendrier si vous n'êtes pas vigilant.
Table des matières
- Pourquoi les organisations quittent TYPO3
- TYPO3 vs Drupal : Une comparaison honnête
- Audit et planification préalables à la migration
- Modélisation du contenu : Mapper TYPO3 à Drupal
- Outils de migration et approche technique
- Gestion de TypoScript TYPO3 et des extensions
- Structure d'URL et préservation du SEO
- Passer à Headless après migration
- Estimations de calendrier, de coûts et d'effectifs
- Liste de contrôle post-migration
- FAQ
Pourquoi les organisations quittent TYPO3
Soyons clairs : TYPO3 n'est pas un mauvais CMS. Il est extrêmement flexible, gère nativement les configurations multi-sites et multilingues, vantant 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 communautaire 2024 de Drupal.org. TYPO3 ? Pas vraiment. Si vos développeurs TYPO3 seniors décident de partir, remplir ces postes pourrait prendre une éternité.
Momentum de l'écosystème. Avec la sortie de Drupal 11 fin 2024, il y a eu d'énormes avancées dans l'interface administrateur, un nouveau système de recettes, et des capacités API-first remarquables. Bien sûr, TYPO3 v13 est solide, mais le taux d'innovation dans Drupal, particulièrement autour des configurations headless, est clairement plus rapide.
Architecture headless/découplée. Prévoyez-vous de servir du contenu à une élégante interface frontend Next.js ou Astro ? Les plugins JSON:API et GraphQL de Drupal sont des vétérans. TYPO3 a sa propre extension headless, mais elle est moins mature avec un soutien plus faible.
Coût total de propriété. L'hébergement de TYPO3 pèse généralement plus lourd sur le portefeuille. Son infrastructure spécialisée signifie que vous pourriez finir par dépenser davantage. Drupal est heureux à peu près n'importe où de Pantheon à Acquia, même une simple pile LAMP le maintient en bon état.
TYPO3 vs Drupal : Une comparaison honnête
Avant de vous lancer tête baissée dans une migration, assurez-vous que Drupal va vraiment résoudre vos problèmes. Voici les détails en 2025 :
| Fonctionnalité | TYPO3 v13 | Drupal 11 |
|---|---|---|
| Modélisation du contenu | Flexible mais s'appuie sur TCA | Système Entity/Field avec interface de gestion des champs |
| Multilingue | Support natif stellaire | Support natif tout aussi stellaire |
| Multi-sites | Multi-sites standard avec arborescences de contenu | Possible, souvent mieux avec Domain Access ou installations séparées |
| Headless/API | Dispose d'une extension headless | JSON:API core, GraphQL contrib |
| Templating | Modèles Fluid + TypoScript | S'exécute sur les modèles Twig |
| Écosystème Extension/Module | ~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 |
| Exigence PHP | PHP 8.2+ | PHP 8.3+ |
| Tarif d'agence typique | €100-180/h (région DACH) | $80-200/h (global) |
Le modèle d'arborescence de pages de TYPO3 est un joyau rare. Les éditeurs accrochés à la gestion d'arborescences de pages élaborées dans TYPO3 pourraient trouver le style de Drupal — la combinaison de types de contenu et de taxonomies — nécessite un certain ajustement. Planifiez une formation d'éditeur pour faciliter cette transition.
Audit et planification préalables à la migration
Cette étape détermine le sort de la plupart des migrations. Tout est dans la planification, pas dans les timeboxes techniques.
Inventaire du contenu
Commencez par auditer tout dans votre configuration TYPO3 :
- Pages : Extrayez cette arborescence de pages, en documentant chaque
doktype(type de page) que vous avez en jeu. - Éléments de contenu : Chaque
CType(type de contenu) nécessite attention — que ce soit du texte, du texte avec image, du HTML, ou des éléments personnalisés viamaskoucontent_defender. - Extensions : Notez chaque extension que vous avez. Découvrez s'il y a un équivalent Drupal.
- Références de fichiers : La FAL (File Abstraction Layer) de TYPO3 gère les médias. Mappez-les vers les emplacements média de Drupal.
- Utilisateurs backend et permissions : Les groupes d'utilisateurs backend sophistiqués de TYPO3 avec accès au niveau des pages et des champs doivent être correctement traduits vers les rôles et permissions Drupal.
Voici une requête SQL pratique pour une analyse des éléments de contenu depuis 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 aux prises. Dans un cas, j'ai découvert une instance TYPO3 vantant 40+ types d'éléments de contenu personnalisés, où seulement une douzaine étaient activement utilisés. Ne traînez pas du poids mort.
Ce qu'il faut garder, ce qu'il faut éliminer
C'est votre chance de nettoyer la maison. Utilisez un outil d'audit de contenu comme Screaming Frog ou Sitebulb pour détecter :
- Pages ne recevant aucun trafic au cours de la dernière année
- Contenu dupliqué ou quasi-identique
- Liens internes cassés
- Fichiers médias orphelins
Généralement, il y a une réduction de contenu de 30-50% dans les grandes migrations TYPO3. Moins de pages signifie des migrations plus rapides.
Modélisation du contenu : Mapper TYPO3 à Drupal
Retroussez vos manches. C'est le gros travail intellectuel. TYPO3 et Drupal gèrent le contenu très différemment.
Modèle de TYPO3
TYPO3 tourne autour des pages. Tout est niché dans une arborescence de pages. Les éléments de contenu (enregistrements dans tt_content) se placent sur les pages en colonnes (colPos). Les enregistrements personnalisés définis via les modèles Extbase ou TCA se situent dans des tableaux séparés mais sont généralement liés à partir des pages.
Modèle de Drupal
Drupal s'agit d'entités. Vous créez des types de contenu (bundles de nœuds), chacun avec des champs dédiés. Les pages ne sont qu'une parmi beaucoup d'autres types de contenu. Taxonomie, paragraphes (utilisant le module Paragraphs), et Layout Builder maîtrisent la composition du contenu structuré.
Le mappage
Voici un tableau de mappage 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 Body |
| Élément de contenu (CType : image) | Référence d'entité média |
| É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é média |
| sys_category | Terme de taxonomie |
| fe_users | Entité utilisateur Drupal |
| be_users | Entité utilisateur Drupal avec rôle admin |
| Modèle TypoScript | Modèle 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 des paragraphes. TYPO3 empile les éléments de contenu dans les colonnes de page, ce qui correspond bien au module Paragraphs de Drupal. Les éditeurs assemblent les pages à partir de types de paragraphes réutilisables — c'est étonnamment transparent.
Outils de migration et approche technique
L'API Migrate de Drupal roule. Mais attention, elle n'a pas de plugin de source TYPO3 natif. Vous devrez créer des plugins source personnalisés pour extraire la base de données 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('ID de page'),
'title' => $this->t('Titre de page'),
'slug' => $this->t('Slug d\'URL'),
'abstract' => $this->t('Résumé/abrégé'),
];
}
public function getIds() {
return ['uid' => ['type' => 'integer']];
}
public function prepareRow(Row $row) {
// Charger 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 avoir un contrôle total et vous permet de gérer les particularités de TYPO3 (comme les suppressions partielles et les superpositions d'espace de travail) dans votre base de code.
Approche 2 : Export/Import 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 couche supplémentaire mais s'avère pratique si vous êtes prudent concernant le maintien des connexions directes à la base de données pendant la migration.
Approche 3 : Hybride avec examen manuel
Vous avez un plus petit site (moins de 500 pages) ? Faire une migration de données structurées automatiquement tout en façonnant manuellement les pages clés de destination peut fonctionner comme un charme. Cela peut sembler rudimentaire, mais lorsque le contenu est entrelacé avec la logique de rendu spécifique à TYPO3, la migration automatisée entraîne souvent du charabia.
Gestion de TypoScript TYPO3 et des extensions
TypoScript
Soyons honnête : TypoScript ne migre pas. C'est un langage de configuration spécifique à TYPO3, sans véritable homologue ailleurs. Votre travail consiste à documenter ce que chaque modèle TypoScript fait en termes simples, puis à le reconstruire en tant que modèles Twig et configuration Drupal. C'est fastidieux mais nécessaire.
Extensions
Voici une comparaison pratique des extensions TYPO3 courantes et de leurs homologues Drupal :
| Extension TYPO3 | Équivalent Drupal |
|---|---|
| news | Type de contenu core + Views |
| powermail | Module Webform |
| solr (ext:solr) | Search API + Solr |
| realurl / routing | Pathauto + routage core |
| gridelements | Layout Builder ou Paragraphs |
| mask | Paragraphs |
| tt_address | Type de contenu personnalisé ou CiviCRM |
| ke_search | Search API |
| femanager | Module utilisateur + personnalisé |
| cal/events | Type de contenu personnalisé + Views |
Les extensions Extbase personnalisées nécessitent une réécriture en tant que modules Drupal. Aucun raccourci — veillez à le budgétiser.
Structure d'URL et préservation du SEO
Gâchez cela, et vous perdrez du trafic organique. J'ai vu des organisations perdre jusqu'à 40% de leur trafic de recherche après la migration en raison de redirections mal gérées.
Étapes
- Exportez tous les URL de TYPO3. Utilisez un outil CLI ou un crawler pour chaque URL indexée.
- Mappez-les aux URL Drupal. Utilisez Pathauto de Drupal pour la génération d'alias d'URL, en restant proche des URL existantes.
- Créez des redirections pour tout ce qui change. Déployez le module Redirect dans Drupal. Pour une montagne de redirections, importez via CSV.
- 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. - Soumettez les plans du site mis à jour à Google Search Console immédiatement.
# Exemple de format d'importation de redirection CSV 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 qu'en lecture seule, pendant un minimum de trois mois après la migration. Vous découvrirez des URL manquées.
Passer à Headless après migration
Drupal brille dans son chemin vers un frontend découplé. Avec Drupal 11, le module JSON:API est solide comme un roc, et l'écosystème Drupal headless prospère.
Si vous réfléchissez à une approche headless — et en 2025, pour la plupart des sites pilotés par le contenu, cela vaut la peine d'être envisagé — nous avons exploré cela en détail dans /solutions/headless-cms-development.
Association des interfaces frontales populaires avec Drupal :
- Next.js — Le chef de file.
next-drupalpar Chapter Three facilite les choses. Nous en parlons longuement à /capabilities/nextjs-development. - Astro — Parfait pour les sites riches en contenu qui ne sont pas trop lourds côté client. Voir /capabilities/astro-development.
- Nuxt — Si Vue est votre terrain de jeu.
La beauté de migrer d'abord vers Drupal est de lancer avec l'interface Twig par défaut de Drupal. Plus tard, vous pouvez basculer vers une interface découplée. N'essayez pas de faire les deux mouvements à la fois — c'est demander le chaos du projet.
Estimations de calendrier, de coûts et d'effectifs
Des chiffres réels provenant de projets auxquels j'ai participé, ou dont j'ai des données exactes (2024-2025) :
| Taille du site | Pages | Calendrier | Fourchette de budget | É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 |
| Large | 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 du contenu, la migration, le thème frontal, l'assurance qualité et la formation des éditeurs. 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 qu'un simple site de 10 000 pages.
Envisageant des spécificités pour 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 redirections. Assurez-vous que ce sont des 301.
- Mettez à jour Google Search Console avec votre nouveau plan du site.
- Testez tous les formulaires : contact, abonnement à la newsletter, connexion.
- Assurez la précision du contenu multilingue pour chaque langue.
- Migrez les fichiers médias correctement avec le texte alternatif et les métadonnées.
- Vérifiez les permissions des éditeurs 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 d'urgence.
- Complétez la formation des éditeurs et livrez la documentation.
- Gardez l'ancienne instance TYPO3 disponible en mode lecture seule.
FAQ
Combien de temps dure 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ébut au lancement. Le premier mois ? Purement découverte et modélisation du contenu. Les scripts de migration signifient généralement 6-8 semaines de travail. Assurance qualité et formation des éditeurs ? Comptez sur un autre mois. Si c'est une configuration complexe multi-langue, multi-sites avec des extensions personnalisées, vous regardez 9-12 mois.
Puis-je migrer le contenu TYPO3 automatiquement, ou est-ce manuel ?
Contenu structuré comme les pages, les enregistrements 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 de TLC manuel. La plupart des migrations ? Environ 70-80% automatiques, 20-30% manuels.
Vais-je perdre mes classements Google lors de la migration ?
Pas si vous êtes diligent avec vos redirections. Définissez ces 301 pour tous les changements d'URL, restez fidèle à votre structure d'URL autant que possible, soumettez ces plans du site mis à jour immédiatement. Vous verrez probablement une baisse, disons 2-6 semaines. Mais un rebond est typique — les sites se rétablissent généralement à des niveaux de pré-migration en 4-8 semaines et voient souvent des améliorations en trois mois en raison de meilleures performances.
Drupal est-il plus difficile à apprendre que TYPO3 pour les éditeurs de contenu ?
Différent, pas plus difficile. Ceux habitués au modèle d'arborescence 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 création de contenu quelque peu similaire. N'oubliez pas de budgétiser environ 2-3 jours de formation pour les éditeurs et de leur fournir une documentation spécifique au type de contenu et au flux de travail.
Qu'advient-il de mes extensions TYPO3 lors de 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é + Views, ext:solr → Search API + 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 migration est motivée par des préoccupations concernant le développeur ou la maintenabilité, commencez simplement par la thématisation 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ébut. Rappelez-vous simplement : faire à la fois des migrations et des changements frontaux à la fois ? C'est un territoire à haut risque.
Comment gérer le contenu multilingue dans la migration ?
La configuration linguistique de TYPO3 (sys_language_uid, l10n_parent) s'aligne bien avec le module Content Translation de Drupal. L'astuce ? Clouer le mappage langue par langue dans vos scripts et assurer que la solution de secours correspond à vos attentes. Soyez prudent avec le contenu partiellement traduit — les modes de superposition linguistique de TYPO3 (libre, connecté, strict) n'ont pas d'homologues 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ù se trouve le ROI ? Principalement en réduisant les dépenses de développement et en accélérant le déploiement des fonctionnalités. Historiquement, les équipes que j'ai guidées constatent une réduction d'environ 20-40% des coûts de développement la première année, grâce principalement à la facilité de recrutement de talents et à un plus grand pool de modules qui réduit le besoin de développement personnalisé. Les coûts initiaux de migration peuvent être importants, mais la plupart devraient atteindre l'équilibre au cours de 18-24 mois.