TYPO3 est de niveau entreprise, éprouvé au combat, et conçu pour une autre époque du web.

L’approche headless est ajoutée après coup

TYPO3 a été conçu comme un CMS traditionnel côté serveur. Son rendu natif est du HTML généré par des templates Fluid. L’extension EXT:headless — maintenue par la communauté TYPO3 Headless, et non par TYPO3 GmbH — transforme cela en API JSON.

Cela fonctionne, et pour les équipes qui ont investi dans TYPO3 et doivent exposer du contenu via une API, c’est une voie raisonnable. Mais il s’agit d’une extension communautaire avec son propre cycle de publication, sa propre surface de compatibilité vis-à-vis des versions du cœur TYPO3, et sa propre documentation. Il n’y a pas de SLA, pas de contrat d’API versionnée de la part de TYPO3 GmbH, et pas de SDK TypeScript.

b10cks a été conçu comme un CMS headless dès le premier jour. L’API est le produit. Chaque décision de conception — architecture en blocs, localisation, versioning, webhooks — a été prise pour servir les consommateurs de l’API, pas les moteurs de rendu de templates.

L’interface éditoriale

L’interface backend de TYPO3 (le « Backend ») est puissante et hautement configurable, mais elle a une courbe d’apprentissage que la plupart des équipes reconnaissent honnêtement. Le paradigme des éléments de contenu (tt_content, configuration TypoScript, FlexForms pour le contenu structuré) n’est pas intuitif pour les éditeurs non techniques. L’onboarding nécessite généralement une formation structurée.

TYPO3 v12 et v13 ont introduit des améliorations du backend et une UI rafraîchie — les progrès sont réels. Mais le modèle mental fondamental — arborescence de pages, colonnes de contenu, TypoScript — reste différent de la manière dont les équipes de contenu modernes travaillent.

L’éditeur visuel de b10cks s’intègre dans le site web réel de l’équipe. Les éditeurs cliquent sur les éléments qu’ils veulent modifier et les éditent directement sur place. L’onboarding est minime, car l’interface est le produit que les éditeurs utilisent tous les jours.

Localisation : la vraie force de TYPO3

C’est là que TYPO3 prend réellement l’avantage. Son système de localisation — traduction au niveau des champs, chaînes de repli selon les locales, arborescences de pages par langue, suivi du statut des traductions — est parmi les plus matures de tous les CMS. Des organisations gérant plus de 20 langues sur des structures de sites complexes s’y fient depuis des décennies.

La localisation de b10cks est robuste pour la plupart des besoins réels : traduction au niveau des champs, héritage des locales, workflows de publication par locale, intégration avec des outils de traduction professionnels (Lokalise, Phrase, DeepL). Pour les équipes qui partent de zéro, elle couvre tout le périmètre fonctionnel sans la complexité héritée.

Pour les organisations qui gèrent déjà des workflows de traduction TYPO3 très complexes, l’écart de maturité mérite d’être évalué honnêtement.

Workspaces : l’autre point fort de TYPO3

Le module Workspaces de TYPO3 est l’un des systèmes de prépublication de contenu les plus puissants du marché des CMS. Les éditeurs peuvent préparer des versions entières d’un site dans un espace de travail isolé, les comparer au contenu en production, les prévisualiser et les publier en lot — sur plusieurs pages, éléments de contenu et locales à la fois.

b10cks propose un historique de versions à la Git, des branches et des mises en production atomiques : tu peux regrouper plusieurs changements de contenu dans un seul déploiement planifié. Pour la plupart des équipes produit, c’est largement suffisant.

Pour les grandes organisations éditoriales qui gèrent des mises en ligne complètes comme des événements atomiques — pense aux portails gouvernementaux, aux grands sites médias en période électorale — le système Workspaces de TYPO3 est un outil spécialisé que b10cks n’égale pas en profondeur.

L’expérience développeur

Mettre en place une pile TYPO3 headless moderne demande un investissement réel : le cœur TYPO3, la configuration EXT:headless, TypoScript pour le mapping des champs API, l’intégration d’un framework frontend (Nuxt-TYPO3 est l’option principale), ainsi que la configuration de FAL (File Abstraction Layer), du caching et du CDN.

Déploiement auto-hébergé de b10cks :

git clone https://github.com/b10cks/cms
cd cms && docker compose up

Et voilà un CMS en fonctionnement. Ajoute un domaine. Connecte ton frontend via le SDK TypeScript.

L’API est documentée avec une spécification OpenAPI. Des adaptateurs de framework existent pour Next.js, Nuxt, Astro et Vue. Le modèle de contenu est défini sur le canvas infini et répercuté immédiatement dans l’API.

Modélisation du contenu : arborescences de pages vs blocs

TYPO3 organise le contenu en arborescence de pages : les pages sont l’entité principale, et les éléments de contenu vivent dans les régions de colonnes des pages. Ce modèle fonctionne bien pour les sites web traditionnels, mais il exige des choix architecturaux supplémentaires pour les scénarios de content-as-a-service (contenu partagé sur plusieurs pages ou canaux).

b10cks organise le contenu en blocs : chaque type de contenu est un bloc composable et réutilisable. Les blocs peuvent être référencés sur plusieurs pages et canaux sans duplication. Le modèle de contenu est défini visuellement et reflète une logique API-first : le contenu n’est pas lié à un emplacement sur une page, c’est une ressource.