Votre CTO transfère le message Slack à 9h47 : « Pouvons-nous passer en headless avec TYPO3, ou devons-nous reconstruire en Next.js ? » Vous maintenez le même monolithe TYPO3 depuis 2018—templates TypoScript, partials Fluid, un dossier extensions avec plus de 40 modules personnalisés. Maintenant quelqu'un a lu un article de blog sur les architectures découplées, et votre feuille de route vient de s'évaporer. Au cours des deux dernières années, j'ai migré six sites TYPO3 d'entreprise vers des stacks headless—trois ont conservé TYPO3 via EXT:headless, trois ont migré vers Next.js + Supabase. La décision dépend de trois variables que la plupart des agences ignorent, et la première n'a rien à voir avec la performance.

Ce n'est pas académique pour moi. J'ai lancé des sites en production avec les deux approches, transpiré sur ces cas limites délicats, et vu des équipes soit triompher soit lutter—parfois spectaculairement—avec chaque stack. Discutons de ce que j'ai appris en chemin.

Comprendre les deux approches

D'abord les choses d'abord, que comparons-nous ici ? Ces deux sont complètement des bêtes différentes.

TYPO3 + EXT:headless (Découplé)

Avec cela, TYPO3 reste votre CMS, gérant toutes vos tâches de backend de gestion de contenu. Le twist est que vous échangez l'ancienne représentation Fluid/TypoScript pour une API JSON. Votre nouveau frontend brillant ? Ce pourrait être React, Vue, tout ce que vous voulez, 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 laissez-passer VIP backstage qui entre dans le processus de rendu de TYPO3 et sort JSON au lieu de HTML. Ce n'est pas une simple API ajoutée—c'est la vraie affaire travaillant directement avec les contenus de TYPO3.

Next.js + Supabase (Entièrement Headless)

De l'autre côté, vous avez Next.js gérant votre frontend et votre logique côté serveur. Supabase (une combinaison folle de PostgreSQL, auth, stockage de fichiers et des trucs en temps réel) gère votre backend. Pas de TYPO3 ici du tout, les gens. Vous abandonnez l'ancien CMS pour une flexibilité pure et une configuration native JS moderne.

Comment EXT:headless fonctionne réellement

Quand vous collez ext:headless sur TYPO3, il enregistre un nouveau type de page qui change tout. Plus de passage de contenu via des templates Fluid ; à la place, il sort 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>Un contenu texte enrichi ici</p>",
    "media": [
      {
        "publicUrl": "/fileadmin/images/hero.webp",
        "properties": {
          "width": 1920,
          "height": 1080,
          "alt": "Image héroïque"
        }
      }
    ]
  },
  "appearance": {
    "layout": "default",
    "frameClass": "default",
    "spaceAfter": "medium"
  }
}

Le frontend relie ensuite ces points aux composants React/Vue. Si vous avez bricolé un CMS basé sur des composants, cela vous semblera comme votre vieux pull préféré.

Configuration d'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 massive 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 de l'éditeur reste intacte. Le backend familier de TYPO3 signifie aucune reconversion pour les éditeurs de contenu.
  • Préserver le contenu existant. Vos configurations ne disparaissent pas. Tout votre contenu, vos traductions et vos médias ? Ils restent.
  • Le support multilingue fonctionne bien. TYPO3 a l'un des meilleurs gestion de langue que j'ai vus.
  • Fonctionnalités prêtes pour l'entreprise. Tout, des espaces de travail à la publication programmée, est prêt.

Le piège avec EXT:headless

  • TYPO3 ne disparaît nulle part. Vous aurez besoin de gens qui savent PHP qui comprennent TYPO3, et ils ne sont pas exactement partout.
  • Hébergement complexe. Vous jongler avec PHP (TYPO3) et Node.js (votre frontend). Double le plaisir, double la complexité.
  • Interface API limitée. C'est du JSON, pas GraphQL. La personnalisation signifie replonger 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 timides.

Mode TYPO3 Headless vs Next.js + Supabase : Une vraie comparaison

Next.js + Supabase : La Stack Entièrement Headless

La disposition

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 backend.

┌─────────────┐     ┌──────────────┐     ┌─────────────┐
│   Next.js   │────▶│   Supabase   │────▶│ PostgreSQL  │
│  (App Router)│     │   (BaaS)     │     │  (Base de   │
└─────────────┘     └──────────────┘     │   données)   │
                                         └─────────────┘

Gestion de contenu sans TYPO3

C'est là que les choses deviennent délicates. Comment les éditeurs gèrent-ils le contenu ?

  1. Panneau d'administration personnalisé. C'est plus de travail que vous ne le penseriez.
  2. Supabase Studio. Génial pour les développeurs, les éditeurs pourraient le détester.
  3. Ajouter un CMS. Maintenant vous gérez trois services.
  4. Utiliser Payload avec sa propre base de données. Plutôt élégant à mon avis.

Juste pour que vous voyiez, voici une implémentation d'extraction de contenu basique 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

  • Performance très élevée. Génération statique, ISR, rendu edge—votre terrain de jeu pour la vitesse.
  • Développeurs en abondance. Les gens JavaScript/TypeScript sont partout.
  • Row Level Security de Supabase. Sérieusement cool pour quand vous voulez un contrôle strict.
  • Fonctionnalités en temps réel. Intégrer 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 vous le souhaitez.

Les luttes ici

  • CMS DIY. À moins que vous lanciez un autre CMS headless dans le mélange, vous roulez essentiellement le vôtre.
  • Trou noir éditorial. Pas de workflows intégrés. États de brouillon, publication programmée ? Vous devez les faire arriver.
  • Gestion des langues. Support de contenu multilingue ? Vous transpirerez de construire cela en interne.
  • Problèmes de gestion des médias. Le stockage Supabase n'est pas adapté aux actifs numériques. Gardez cela à l'esprit.

Comparaison côte à côte

Voyez 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és Construction personnalisée nécessaire
Performance Bonne Excellente
API Limitée Contrôle total
Temps réel Absent Supporté
Auth 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

Références 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 construction (complet) 4m 20s 1m 45s
Réponse API (p95) 180ms 22ms

Le résultat net ? Tandis que le TTFB non mis en cache est meilleur avec Supabase, la mise en cache du CDN égalise à peu près le terrain. Les deux, quand ils sont configurés correctement, vont assez vite pour l'utilisateur final.

Mode TYPO3 Headless vs Next.js + Supabase : Une vraie comparaison - architecture

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 à niveau et à la gestion des problèmes de compatibilité. En 2026, 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 de la création de templates Fluid.

Le club Next.js + Supabase

Les développeurs JavaScript sont abondants, mais n'oubliez pas que concevoir des systèmes de gestion de contenu n'est pas facile pour tout le monde. L'expérience développeur de Supabase est plutôt fluide : types TypeScript générés automatiquement, abonnements en temps réel et d'excellents assistants d'authentification. Mais toute modélisation de données et décision architecturale ? Tout est sur vous.

Pontifiez cette route ? Notre équipe a affiné l'expertise en développement Next.js pour vous aider à éviter les mauvaises surprises.

Stratégies de migration

Du TYPO3 traditionnel au TYPO3 Headless

Risque plus bas, le contenu reste intact. Principalement une réécriture frontale.

  1. Déployer EXT:headless
  2. Mapper les éléments de contenu au JSON
  3. Créer le frontend Next.js/Nuxt
  4. Trier l'intégration d'aperçu
  5. Mise en ligne !

Cadre temporel : 8-16 semaines pour un site d'entreprise de taille décente.

Du TYPO3 au Next.js + Supabase

Accrochage-vous à votre siège, celle-ci est une reconstruction complète.

  1. Auditer les configurations de contenu actuelles
  2. Esquisser votre schéma PostgreSQL
  3. Écrire des scripts de migration
  4. Déplacer les références médias et fichiers
  5. Construire des outils éditoriaux ou intégrer un autre CMS
  6. Construire à nouveau pour le frontend
  7. Gérer les redirections d'URL
  8. Propager le contenu multilingue

Cadre temporel : 16-32 semaines. Développement headless complexe ? Apportez des pros pour faciliter la vie.

Analyse des coûts

Comptabilisons-le pour une configuration d'entreprise de taille moyenne : 200 pages, 3 langues, 5 éditeurs, 50K visiteurs mensuels.

Coûts TYPO3 Headless — Année 1

Article 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 Année 1 €36,840-63,840
Annuel continu €5,000-8,000

Coûts Next.js + Supabase — Année 1

Article Coût
Supabase Pro €300/an
Vercel Pro €240/an
Ajouter CMS (si nécessaire) €0-3,600/an
Migration de contenu €10,000-20,000
Développement Frontend + Backend €40,000-70,000
Outils d'édition €10,000-25,000
Total Année 1 €60,540-119,140
Annuel continu €2,000-6,000

Passer entièrement headless coûte gros à l'avance, mais réduit les dépenses mensuelles puisque vous abandonnez l'hébergement TYPO3. Juste ne sous-estimez pas le CMS supplémentaire construit par-dessus.

Quand choisir quoi

TYPO3 + EXT:headless

  • Restez avec le contenu hérité et les workflows établis.
  • Gardez les paramètres éditoriaux familiers et les fonctionnalités riches.
  • Bénéficiez du support multilingue natif sophistiqué.
  • Conservez les développeurs TYPO3.

Next.js + Supabase

  • Quand vous commencez à zéro.
  • L'application a besoin de nombreuses fonctionnalités interactives.
  • Votre équipe de développement se concentre déjà sur JavaScript.
  • Garder la performance en tête est une préoccupation majeure.
  • À l'aise pour ajouter un CMS headless.

Considérez un troisième angle

Mélanger a-t-il traversé votre esprit ? Next.js, un CMS headless, plus Supabase pour les données d'application peuvent se combiner le meilleur. Il offre des outils éditoriaux équilibrés sans les bagages TYPO3. Si vous envisagez également des options comme développement Astro pour les sites légers riches en contenu, cela vaut le coup de regarder.

Voulez-vous 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 promis une évaluation honnête, même si c'est « restez avec ce que vous savez ».

FAQ

EXT:headless de TYPO3 est-il prêt pour la production en 2026 ?

Oui, absolument. EXT:headless est 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 grands sites d'entreprise l'exécutent dans des configurations de production, y compris les secteurs gouvernementaux et bancaires en Allemagne et en Autriche.

Puis-je utiliser Next.js pour un frontend TYPO3 headless ?

Bien sûr, c'est une combo classique. Vous utiliserez Next.js App Router avec des composants côté serveur pour rassembler les 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 à l'appeler via les URL d'aperçu. Heureusement, la documentation utile de la communauté vous guide à travers l'appariement de 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 donne cette douceur de 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 un contrôle par rapport à la sécurité.

Préoccupations SEO avec TYPO3 headless ? Gestion des méta-tags et des données structurées ?

EXT:headless sérialise bien les propriétés de page comme les méta-tags et les données Open Graph. Votre frontend doit les rendre comme des balises HTML. Utilisez l'API Metadata de Next.js dans les dispositions. Tant que votre configuration TYPO3 est solide, les données SEO devraient suivre. Intégrez des extensions comme EXT:yoast_seo et cela jouera bien avec les configurations headless.

Supabase est-il à la hauteur de la livraison de contenu au niveau de l'entreprise ?

Bien sûr que oui. Supabase Cloud, s'exécutant sur AWS, offre une disponibilité de 99,9% sur les plans Pro et améliore jusqu'à 99,95% sur les plans Team (consultez les tarifs 2026). Pour la mise en cache du CDN (Vercel Edge Network, Cloudflare), Supabase assure principalement la fiabilité des écritures et des fonctionnalités en temps réel. Pour une utilisation d'entreprise critique, auto-hébergez Supabase pour un contrôle maximal.

Comment gérons-nous le traitement d'image sans TYPO3 ?

TYPO3 traite nativement les images—recadrer, redimensionner, format basculer. Sans elle, configurez votre workflow d'image. Les principaux prétendants 2026 sont : Next.js Image Optimization (intégré, favorable à Vercel), Cloudinary (donnant libre au départ, l'utilisation sérieuse demande des plans payés), ou imgix (à partir de €100+/mois). Supabase Storage gère les originaux mais pas les transformations.

Pouvons-nous migrer progressivement du TYPO3 Headless vers le headless complet ?

Absolument, pensez-y comme un plan fluide. Commencez avec TYPO3 headless, isolant votre frontend. Transition lentement le contenu de TYPO3 vers Supabase ou votre CMS choisi—commencez par les types plus simples. Pendant la phase, votre frontend Next.js opère avec les données des deux sources.

Quelle est la courbe d'apprentissage pour une équipe TYPO3 qui passe à Next.js + Supabase ?

Une montée en puissance réaliste est 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 au framework guidant les structures de contenu, la mise en cache et les routes. Dans le modèle Next.js + Supabase, ces appels sont vôtres. C'est libérateur mais accablant au début. La programmation en paire avec des gens Next.js chevronnés rend ce saut beaucoup plus fluide.