TYPO3 Mode Headless vs Next.js + Supabase : Une Comparaison Réelle
TYPO3 Headless vs Next.js + Supabase : Quel est le bon choix ?
J'ai passé les deux dernières années à migrer des installations TYPO3 d'entreprise vers des architectures headless. Et vous savez quelle question revient tout le temps ? Devrions-nous conserver TYPO3 et passer en headless avec EXT:headless ou l'abandonner pour Next.js avec quelque chose comme Supabase ? C'est un peu déconcertant, n'est-ce pas ? Comme la plupart des décisions d'architecture, la réponse se résume à « ça dépend ». Mais décomposons exactement de quoi ça dépend.
Ce n'est pas académique pour moi. J'ai lancé des sites en production avec les deux approches, transpiré à cause de ces vilains cas particuliers, et j'ai vu des équipes réussir ou échouer—parfois spectaculairement—avec chaque stack. Parlons de ce que j'ai appris en chemin.
Comprendre les deux approches
D'abord, qu'est-ce qu'on compare exactement ici ? Ces deux approches sont complètement différentes.
TYPO3 + EXT:headless (Découplé)
Avec ceci, TYPO3 reste votre CMS, gérant toutes les tâches du backend de gestion de contenu. Le twist, c'est que vous remplacez l'ancien rendu Fluid/TypoScript par une API JSON. Votre nouveau frontend brillant ? Ce pourrait être React, Vue, ce que vous voulez, en consommant cette API. TYPO3 continue de gérer tous les bons trucs comme les modèles, les permissions et les workflows.
L'extension EXT:headless ? C'est le pass VIP en coulisses qui s'insère dans le processus de rendu de TYPO3 et génère du JSON au lieu du HTML. Ce n'est pas une API en add-on non plus—c'est du vrai travail fonctionnant directement avec les tripes du contenu de TYPO3.
Next.js + Supabase (Complètement headless)
De l'autre côté, vous avez Next.js gérant votre frontend et votre logique côté serveur. Supabase (une belle combinaison de PostgreSQL, authentification, stockage de fichiers et bonnes choses en temps réel) s'occupe de votre backend. Plus de TYPO3 ici, les gens. Vous abandonnez l'ancien CMS pour la flexibilité pure et une configuration moderne native en JS.
Comment EXT:headless fonctionne réellement
Quand vous mettez ext:headless sur TYPO3, il enregistre un nouveau type de page qui change tout. Plus de passage du contenu via les templates Fluid ; à la place, il génère du JSON.
Voici un aperçu de ce que vous obtiendrez :
{
"id": 42,
"type": "textmedia",
"content": {
"header": "Bienvenue sur notre site",
"headerLayout": 2,
"bodytext": "<p>Du contenu texte enrichi ici</p>",
"media": [
{
"publicUrl": "/fileadmin/images/hero.webp",
"properties": {
"width": 1920,
"height": 1080,
"alt": "Image héros"
}
}
]
},
"appearance": {
"layout": "default",
"frameClass": "default",
"spaceAfter": "medium"
}
}
Le frontend connecte ensuite ces éléments aux composants React/Vue. Si vous avez bricolé avec un CMS basé sur des composants, cela vous semblera comme votre ancien pull préféré.
Configurer EXT:headless
Une configuration typique commence comme ceci :
composer require friendsoftypo3/headless
Et dans votre TypoScript :
plugin.tx_headless {
settings {
debug = 0
}
}
page = PAGE
page {
typeNum = 0
10 = USER
10.userFunc = FriendsOfTYPO3\Headless\ContentObject\JsonContentObject->render
}
Voici le truc : Pour chaque élément de contenu personnalisé dans TYPO3, vous avez besoin de sérialiseurs JSON. Pour un site avec, disons, une poignée d'éléments personnalisés ? Vous regardez quelques jours de travail. Une énorme configuration d'entreprise avec des dizaines d'éléments ? Préparez-vous—cela pourrait prendre des semaines.
Ce que TYPO3 Headless fait bien
- L'expérience d'édition reste intacte. Le backend familier de TYPO3 signifie pas de recyclage pour les éditeurs de contenu.
- Préserver le contenu existant. Vos configurations ne disparaissent pas. Tout votre contenu, traductions et médias ? Ils restent là.
- Le support multi-langues fonctionne bien. TYPO3 a l'une des meilleures gestions de langue que j'ai vues.
- Fonctionnalités prêtes pour l'entreprise. Tout, des espaces de travail à la publication programmée, est prêt à l'emploi.
Le piège avec EXT:headless
- TYPO3 ne disparaîtra pas. Vous aurez besoin de gens compétents en PHP qui comprennent TYPO3, et ils ne sont pas exactement partout.
- Hébergement complexe. Vous jongler PHP (TYPO3) et Node.js (votre frontend). Double le plaisir, double la complexité.
- Interface API limitée. C'est du JSON, pas du GraphQL. La personnalisation signifie plonger dans le développement d'extensions TYPO3.
- Cauchemar d'aperçu. Intégrer un aperçu en temps réel avec TYPO3 et Next.js ? Pas pour les âmes sensibles.
Next.js + Supabase : Le stack complètement headless
La mise en page
Avec cette configuration, Next.js s'occupe de votre couche application, et Supabase s'occupe de toutes les tâches de base de données et de backend.
┌─────────────┐ ┌──────────────┐ ┌─────────────┐
│ Next.js │────▶│ Supabase │────▶│ PostgreSQL │
│ (App Router)│ │ (BaaS) │ │ (Base de données)│
└─────────────┘ └──────────────┘ └─────────────┘
Gestion de contenu sans TYPO3
C'est là que ça devient délicat. Comment les éditeurs gèrent le contenu ?
- Panneau d'administration personnalisé. C'est plus de travail que vous ne le pensez.
- Supabase Studio. Excellent pour les devs, les éditeurs pourraient le détester.
- Ajouter un CMS. Maintenant vous gérez trois services.
- Utiliser Payload avec sa propre base de données. Plutôt élégant à mon avis.
Juste pour vous montrer, voici une implémentation basique de récupération de contenu avec Supabase :
import { createClient } from '@supabase/supabase-js'
const supabase = createClient(
process.env.NEXT_PUBLIC_SUPABASE_URL!,
process.env.SUPABASE_SERVICE_ROLE_KEY!
)
export async function getPage(slug: string) {
const { data, error } = await supabase
.from('pages')
.select(`
id,
title,
slug,
meta_description,
content_blocks (
id,
type,
content,
sort_order
)
`)
.eq('slug', slug)
.eq('status', 'published')
.single()
if (error) throw error
return data
}
Ce que Next.js + Supabase excelle à faire
- Performance exceptionnelle. Génération statique, ISR, rendu edge — votre terrain de jeu pour la vitesse.
- Plein de développeurs. Les gens JavaScript/TypeScript sont partout.
- Row Level Security de Supabase. Sérieusement cool quand vous voulez un contrôle strict.
- Fonctionnalités en temps réel. Intégrez les mises à jour en direct comme une brise.
- Déploiement facile. Utilisez Vercel pour Next.js et Supabase Cloud pour le backend ou auto-hébergez si nécessaire.
Les luttes ici
- CMS DIY. À moins que vous n'ajoutiez un autre CMS headless au mélange, vous créez essentiellement le vôtre.
- Trou noir éditorial. Pas de workflows intégrés. Des états de brouillon, une publication programmée ? Vous devez les faire vous-même.
- Gestion des langues. Support du contenu multi-langue ? Vous transpirerez en construisant cela en interne.
- Problèmes de gestion des médias. Le stockage Supabase n'est pas conçu pour les actifs numériques. Gardez ça en tête.
Comparaison directe
Regardez comment ils se comparent :
| Fonctionnalité | TYPO3 + EXT:headless | Next.js + Supabase |
|---|---|---|
| UX d'édition | Excellent | CMS personnalisé ou ajouté |
| Multi-langue | Natif | Implémentation DIY |
| Workflows | Intégré | Construction personnalisée requise |
| Performance | Bonne | Excellente |
| API | Limitée | Contrôle total |
| Temps réel | Absent | Supporté |
| Authentification | Hérité | Moderne et flexible |
| Complexité | Élevée | Moyenne |
| Bassin de talents | Rare | Abondant |
| Migration de contenu | Inutile | Migration complète |
| Fonctionnalités | Intégrées | Construire ou acheter |
| Temps de configuration | 2-4 semaines | 4-8 semaines |
| Coût (hébergement) | €150-500 | €45-200 |
Points de repère de performance
Voyons quelques chiffres d'un site que j'ai testé—site d'entreprise, 200 pages, support multilingue :
| Métrique | TYPO3 Headless + Next.js | Next.js + Supabase (SSG) |
|---|---|---|
| TTFB (non mis en cache) | 280ms | 45ms |
| TTFB (CDN en cache) | 35ms | 32ms |
| LCP | 1.8s | 1.2s |
| CLS | 0.02 | 0.01 |
| Score Lighthouse | 92 | 98 |
| Temps de build (complet) | 4m 20s | 1m 45s |
| Réponse API (p95) | 180ms | 22ms |
En résumé ? Bien que le TTFB non mis en cache soit meilleur avec Supabase, la mise en cache du CDN nivelle à peu près le terrain. Les deux, s'ils sont bien configurés, fonctionnent assez vite pour l'utilisateur final.
Expérience développeur et considérations d'équipe
Plonger dans TYPO3
Vous aurez toujours besoin de pros TYPO3 pour les projets headless. Pensez aux sérialiseurs PHP, aux tests de mises à jour et à la gestion des problèmes de compatibilité. En 2025, ces experts pourraient vous coûter €80-120/heure. Et certains développeurs ne sont pas ravis des configurations headless—cela enlève la joie du templating Fluid.
Le club Next.js + Supabase
Les développeurs JavaScript sont nombreux, mais n'oubliez pas que concevoir des systèmes de gestion de contenu n'est pas facile pour tout le monde. L'expérience de développement de Supabase est plutôt élégante : types TypeScript auto-générés, abonnements en temps réel et assistants d'authentification solides. Mais toute la modélisation de données et les décisions architecturales ? C'est entièrement sur vous.
Réfléchissez à cet itinéraire ? Notre équipe a affiné son expertise dans le développement Next.js pour vous aider à éviter les mauvaises surprises.
Stratégies de migration
De TYPO3 traditionnel à TYPO3 Headless
Risque plus faible, le contenu reste intact. Principalement une réécriture front-end.
- Lancer EXT:headless
- Mapper les éléments de contenu au JSON
- Créer le frontend Next.js/Nuxt
- Résoudre l'intégration d'aperçu
- Aller en direct !
Calendrier : 8-16 semaines pour un site d'entreprise de taille décente.
De TYPO3 à Next.js + Supabase
Tenez-vous bien, celui-ci est une reconstruction complète.
- Auditer les configurations de contenu actuelles
- Esquisser votre schéma PostgreSQL
- Écrire des scripts de migration
- Déplacer les médias et les références de fichiers
- Construire les outils éditoriaux ou intégrer un autre CMS
- Reconstruire le frontend
- Gérer les redirections d'URL
- Propager le contenu multi-langue
Calendrier : 16-32 semaines. Développement headless complexe ? Faites appel à des pros pour faciliter la vie.
Analyse des coûts
Comptons-le pour une configuration d'entreprise de taille moyenne : 200 pages, 3 langues, 5 éditeurs, 50 000 visiteurs mensuels.
Coûts Year 1 de TYPO3 Headless
| Élément | Coût |
|---|---|
| Hébergement TYPO3 (Géré) | €3 600/an |
| Hébergement Next.js (Vercel Pro) | €240/an |
| Développement Frontend | €25 000-45 000 |
| Intégration EXT:headless | €8 000-15 000 |
| Total Year 1 | €36 840-63 840 |
| Annuel continue | €5 000-8 000 |
Coûts Year 1 de Next.js + Supabase
| Élément | Coût |
|---|---|
| Supabase Pro | €300/an |
| Vercel Pro | €240/an |
| Ajouter un CMS (si nécessaire) | €0-3 600/an |
| Migration de contenu | €10 000-20 000 |
| Développement Frontend + Backend | €40 000-70 000 |
| Outils éditoriaux | €10 000-25 000 |
| Total Year 1 | €60 540-119 140 |
| Annuel continue | €2 000-6 000 |
Devenir complètement headless coûte cher au départ, mais réduit les dépenses mensuelles puisque vous abandonnez l'hébergement TYPO3. Juste n'oubliez pas de ne pas sous-estimer la construction CMS supplémentaire.
Quand choisir lequel
TYPO3 + EXT:headless
- Rester avec le contenu hérité et les workflows établis.
- Garder les paramètres éditoriaux familiers et les fonctionnalités riches.
- Bénéficier du support multi-langue natif sophistiqué.
- Conserver les développeurs TYPO3.
Next.js + Supabase
- Quand commencer de zéro.
- L'application a besoin de nombreuses fonctionnalités interactives.
- Votre équipe de développement est déjà axée sur JavaScript.
- Garder les performances au premier plan est un objectif clé.
- À l'aise d'ajouter un CMS headless.
Considérez un troisième angle
Peut-être que le mélanger vous a traversé l'esprit ? Next.js, un CMS headless, plus Supabase pour les données d'application pourraient combiner le meilleur. Cela offre des outils éditoriaux bien arrondis sans les bagages de TYPO3. Si vous explorez également des options comme le développement Astro pour les sites légers riches en contenu, c'est worth un regard.
Vous voulez discuter de vos besoins spécifiques ? Nous sommes là pour vous aider à évaluer ce qui a du sens pour votre scénario unique—contactez-nous, et nous promettons une évaluation honnête, même si c'est « restez avec ce que vous savez ».
FAQ
EXT:headless TYPO3 est-il prêt pour la production en 2025 ? Yep, absolument. EXT:headless a été stable depuis la version 3.x et est activement supporté. La version 4.x couvre TYPO3 v12 et v13 avec une sérialisation de contenu solide, une génération de menus et une gestion des formulaires. Un tas de sites d'entreprise énormes l'exécutent dans les configurations de production, y compris les secteurs comme le gouvernement et la banque en Allemagne et en Autriche.
Puis-je utiliser Next.js pour un frontend TYPO3 headless ? Bien sûr, c'est un combo classique. Vous utiliserez Next.js App Router avec des composants serveur pour récupérer des informations de l'API JSON de TYPO3. L'intégration d'aperçu est la partie la plus délicate : configurer le mode brouillon et diriger TYPO3 pour l'appeler via des URLs d'aperçu. Heureusement, la documentation d'aide communautaire vous guide tout au long de l'appairage Next.js.
Comment Supabase se compare-t-il à la configuration de base de données de TYPO3 ? Oh, ce sont des pommes et des oranges. TYPO3 s'exécute sur Doctrine DBAL avec un schéma plus strict géré par TCA. Supabase offre cette douce liberté PostgreSQL avec Row Level Security. Supabase fournit une capacité de requête flexible et puissante, mais TYPO3 est soigneusement structuré pour prévenir les erreurs que les éditeurs pourraient accidentellement introduire. C'est tout une question de contrôle versus sécurité.
Préoccupations SEO avec TYPO3 headless ? Gérer les métabalises et les données structurées ?
EXT:headless sérialise bien les propriétés de page comme les métabalises et les données Open Graph. Votre frontend doit les rendre comme des balises HTML. Utilisez l'API Metadata de Next.js dans les layouts. Tant que votre configuration TYPO3 est solide, les données SEO devraient suivre. Intégrez des extensions comme EXT:yoast_seo et elle jouera bien avec les configurations headless.
Supabase est-il prêt pour la livraison de contenu au niveau de l'entreprise ? Absolument. Supabase Cloud, fonctionnant sur AWS, offre 99,9% de disponibilité sur les plans Pro et atteint 99,95% sur les plans Team (vérifiez les tarifs 2025). Pour la mise en cache CDN (Réseau Edge de Vercel, Cloudflare), Supabase assure principalement la fiabilité des écritures et des fonctionnalités en temps réel. Pour une utilisation critique en entreprise, auto-hébergez Supabase pour un contrôle maximum.
Comment abordons-nous le traitement des images sans TYPO3 ? TYPO3 traite nativement les images—recadrer, redimensionner, retourner le format. Sans cela, mettez en place votre workflow d'images. Les meilleurs prétendants de 2025 sont : Next.js Image Optimization (intégré, supportif pour Vercel), Cloudinary (gratuit pour débuter, l'utilisation sérieuse demande des plans payants), ou imgix (à partir de $100+/mois). Supabase Storage gère les originaux mais pas les transformations.
Pouvons-nous migrer progressivement de TYPO3 Headless vers complètement headless ? Absolument, pensez à ça comme un plan en douceur. Commencer avec TYPO3 headless, isolant votre frontend. Transférer lentement le contenu de TYPO3 vers Supabase ou votre CMS choisi — commencer avec des types plus simples. Pendant cette phase, votre frontend Next.js fonctionne avec des données des deux sources.
Quelle est la courbe d'apprentissage pour une équipe TYPO3 passant à Next.js + Supabase ? Une montée en puissance réaliste est d'environ trois à six mois. Cela dit, le défi n'est pas JavaScript ou TypeScript—c'est le changement de paradigme. Les développeurs TYPO3 sont habitués à la structure de cadre dirigeant les structures de contenu, la mise en cache et les routes. Dans le modèle Next.js + Supabase, ces appels vous appartiennent. C'est libérateur mais écrasant au début. La programmation en paires avec des pros Next.js chevronnés rend ce saut beaucoup plus fluide.