CMS headless
Le headless, sans perdre la page.
Forrit CMS est un CMS headless qui garde la page. Les équipes modélisent du contenu réutilisable avec des types de contenu et des entrées, puis l’organisent en pages dotées de leurs propres routes, SEO et métadonnées. Forrit publie le tout via son canal JSON, et votre front-end garde la maîtrise totale de la présentation.
Le compromis du headless
Que perdent les équipes de contenu avec un CMS headless ?
Le CMS headless résout de vrais problèmes pour les développeurs. Le contenu est séparé de la présentation et diffusé par API vers tout front-end, ce qui permet aux équipes de choisir leurs propres frameworks et de réutiliser le contenu sur le web, les applications et d’autres canaux.
Mais une configuration purement headless renvoie souvent du travail à tous les autres. Voici les compromis que les équipes de contenu évoquent le plus souvent.
Où atterrit le travail
Les développeurs modélisent le contenu et créent le front-end
Les rédacteurs remplissent des formulaires, souvent sans voir la page
Les nouvelles mises en page repartent dans le backlog de développement
Le SEO et les paramètres de page sont assemblés à partir d’autres outils
Ce que les équipes de contenu perdent souvent
Voir le contenu en contexte
Le contenu est stocké séparément de son affichage, si bien que les rédacteurs remplissent souvent des formulaires sans voir la page. L’aperçu en direct devient du travail supplémentaire pour l’équipe de développement.
Créer des pages sans développeur
Une nouvelle page d’atterrissage, section ou mise en page nécessite souvent un développeur et un déploiement : le marketing perd l’autonomie dont il disposait avec un CMS traditionnel.
Une façon de travailler centrée sur la page
Les rédacteurs travaillent avec des types de contenu, des champs et des références plutôt qu’avec des pages. C’est puissant, mais de nombreux utilisateurs non techniques ont du mal à s’y retrouver.
SEO et paramètres de page au même endroit
Les fonctionnalités au niveau de la page, comme les réglages SEO et la navigation, ne sont souvent pas intégrées : les équipes les assemblent à partir d’autres outils.
Comment ça marche
Comment Forrit garde-t-il la page dans un CMS headless ?
Dans Forrit, headless ne veut pas dire sans page. Le contenu reste structuré et réutilisable, et la page apporte le contexte que les entrées individuelles n’ont pas à porter : l’endroit où se trouve le contenu, la façon dont il est décrit aux moteurs de recherche et sa place dans le site.
Les développeurs obtiennent du contenu structuré. Les rédacteurs obtiennent des pages.
Du type de contenu au front-end
Définissez des types de contenu pour ce que vous publiez
Créez chaque entrée une fois et réutilisez-la partout
Organisez les entrées en pages avec une route, du SEO et des métadonnées
Approuvez et publiez via votre workflow
Votre front-end demande la page en JSON et l’affiche à sa manière
Le rôle de chaque élément
Contenu structuré
Les types de contenu et les entrées rendent le contenu réutilisable entre pages, canaux et projets.
Des pages avec du contexte
Une page ajoute la route, le titre SEO, la description et les métadonnées que les entrées individuelles n’ont pas à porter.
Diffusé en JSON
Le canal JSON publie la page sans balisage : votre front-end garde la maîtrise totale de la présentation.
Pour les développeurs
Une page headless peut-elle être diffusée en une seule requête ?
Oui. Une page Forrit peut combiner des entrées issues de nombreux types de contenu. Le canal JSON renvoie la page entière en une seule réponse : sa route, ses métadonnées SEO et chaque composant, dans l’ordre défini par les rédacteurs.
Votre front-end effectue une requête par page. Vous n’avez pas besoin d’écrire des requêtes qui récupèrent chaque type de contenu puis d’assembler les résultats. Si une application n’a besoin que d’une entrée ou d’un type de contenu, elle peut ne demander que celui-ci.
De la requête à la page affichée
Demandez la page par sa route, par exemple /savings/easy-saver
Recevez la route, les métadonnées SEO et chaque composant, dans l’ordre, en une seule réponse
Associez chaque type de composant à votre propre composant d’interface et affichez la page
Pourquoi les développeurs l’apprécient
Moins d’allers-retours
Une requête par route garde le rendu côté serveur et les applications mobiles rapides.
Moins de code d’assemblage
Aucune logique de résolution des références ou d’ordonnancement à écrire et à maintenir.
Façonné par les modèles
Le modèle JSON de chaque composant définit les champs restitués : les payloads ne contiennent que ce dont le front-end a besoin.
Toujours à jour
Publiez une entrée partagée une fois et chaque réponse de page qui l’utilise se met à jour automatiquement.
01 · Aperçu
Les rédacteurs peuvent-ils prévisualiser le contenu headless avant sa mise en ligne ?
Dans de nombreuses plateformes headless, les rédacteurs remplissent des formulaires sans voir le résultat, et l’aperçu en direct représente du travail supplémentaire pour l’équipe de développement.
Dans Forrit, les modifications sont faites dans une branche de tâche, et les rédacteurs prévisualisent la page avant de l’envoyer en approbation, sans build supplémentaire pour vos développeurs. Les équipes qui veulent prévisualiser dans leur propre front-end peuvent aussi afficher le JSON brouillon depuis la branche de tâche.
De la modification à la mise en ligne
Modifiez le contenu dans une branche de tâche, à l’écart du contenu en ligne
Prévisualisez la page avec la modification en place
Vérifiez ce qui change grâce à une vue avant/après
Approuvez et publiez
Fonctionnalités d’aperçu
Aperçu dans Forrit
Les rédacteurs prévisualisent les pages dès l’installation, sans build d’aperçu à maintenir pour vos développeurs.
Aperçu dans votre propre front-end
Les équipes qui le souhaitent peuvent afficher le JSON brouillon de la branche de tâche dans leur propre front-end.
À l’abri du contenu en ligne
Les modifications restent dans une branche de tâche jusqu’à leur approbation et leur publication.
02 · Autonomie
Les rédacteurs ont-ils besoin d’un développeur pour chaque nouvelle page ?
Non. Les développeurs créent les composants et les modèles de page une seule fois. Les équipes de contenu créent ensuite des pages à partir de ces briques approuvées, sans cycle de développement pour chaque nouvelle page.
Les développeurs gardent la maîtrise du design system et de l’architecture de diffusion. Les équipes de contenu ont la liberté de lancer des pages, des campagnes et des variantes quand elles en ont besoin.
Qui fait quoi
Les développeurs créent des composants qui mettent en forme vos types de contenu
Les développeurs configurent des modèles de page avec les bons composants en place
Les rédacteurs créent des pages à partir de modèles et de composants approuvés
Aperçu, approbation et publication, sans cycle de développement
Fonctionnalités des composants et modèles
Composants réutilisables
Créés une fois et réutilisés sur plusieurs pages et sites : les changements d’identité visuelle, les campagnes et les lancements prennent moins de temps.
Modèles de page
Les nouvelles pages partent de modèles où les bons composants sont déjà en place.
Marque et règles cohérentes
Des briques et des workflows approuvés assurent la cohérence des mises en page et de l’identité visuelle, quel que soit le nombre de sites que vous gérez.
03 · Édition familière
Les rédacteurs doivent-ils penser en types de contenu et en références ?
Seulement s’ils le souhaitent. Les utilisateurs avancés et les développeurs peuvent travailler directement avec le modèle de contenu. Tous les autres peuvent partir de la page : ouvrir Home, trouver le hero, modifier le contenu.
La structure sous-jacente reste réutilisable, et les informations d’usage indiquent où une entrée apparaît ailleurs avant que quiconque ne la modifie.
Modifier une page
Ouvrez la page à modifier
Sélectionnez la section et son contenu
Vérifiez où l’entrée est utilisée ailleurs
Modifiez, prévisualisez et envoyez en approbation
Fonctionnalités d’édition
Partir de la page
Ouvrez la page, trouvez la section et modifiez le contenu, sans fouiller dans le modèle de contenu.
Voir où le contenu est utilisé
Les informations d’usage indiquent les pages et les entrées qui font référence à un élément avant que quiconque ne le modifie.
Le modèle complet pour les utilisateurs avancés
Les développeurs et les utilisateurs avancés peuvent toujours travailler directement avec les types de contenu et les entrées.
04 · Fonctionnalités de page
Où se trouvent le SEO et les autres fonctionnalités de page dans un CMS headless ?
Dans Forrit, sur la page. Les pages portent la route, le titre SEO, la description et les métadonnées pour tous les types de page : la visibilité dans la recherche et auprès des IA est donc gérée à un seul endroit et diffusée avec le contenu.
Pour les fonctionnalités qui dépassent la page, Forrit est composable. Connectez les services spécialisés sur lesquels vous vous appuyez déjà, au lieu de les remplacer. Découvrez comment Forrit se connecte aux services qui l’entourent.
Gérer une page
Définissez la route de la page et sa place dans la navigation
Ajoutez le titre SEO, la description et les métadonnées
Ajoutez des variantes d’audience là où elles sont nécessaires
Publiez : les métadonnées sont diffusées avec la page
Fonctionnalités au niveau de la page
- Intégré
SEO et métadonnées
Les titres, descriptions et métadonnées sont gérés page par page, pour tous les types de page, et diffusés avec le contenu.
- Intégré
Routes et navigation
Les routes des pages et la navigation sont diffusées dans le JSON : votre front-end construit les URL et les menus à partir du CMS.
- Intégré
Variantes d’audience
Créez des variantes de contenu pour différentes audiences et choisissez les composants de page affichés pour chaque variante.
- Connecté
Formulaires, personnalisation et analytics
Forrit est composable. Connectez les services de formulaires, de personnalisation, de test et d’analytics que vous utilisez déjà.
Headless hybride
Besoin que Forrit génère aussi les pages web ?
Les mêmes types de contenu, entrées et pages peuvent aussi être publiés sous forme de pages web complètes via le canal HTML. Utilisez un canal, l’autre ou les deux, depuis un seul CMS et un seul processus d’approbation.
- Forrit CMS
Headless hybride
Comparez les canaux HTML et JSON, voyez comment une page fonctionne dans chacun et découvrez celui qui convient à votre site web, votre application ou votre parc.
- Produit
Forrit CMS
Créez, gouvernez et réutilisez le contenu sur tout votre patrimoine numérique, avec contenu structuré, création visuelle de pages et diffusion headless dans un seul CMS.
- Avantage clé
Sécurité
Sept couches de protection, de la sécurité en périphérie et d’Airlock Publishing au développement sécurisé et à l’assurance ISO 27001.
Utilisez la touche Tab pour parcourir chaque lien « Lire la suite » du témoignage. Chaque fois que vous appuyez sur la touche de tabulation,
L'équipe de Forrit a été remarquable en aidant notre organisation à transférer un site web existant de son locataire vers la plateforme Forrit dans un délai très court. De la migration, aux activités avant et jour du lancement, ils ont exécuté tous les détails comme prévu, rendant la transition fluide et sans tracas. Après le lancement, l'équipe a continué à se rendre disponible pour résoudre les problèmes et répondre aux questions lorsqu'elles se posent, ce qui a été d'une aide précieuse. Nous sommes très heureux d'avoir effectué la transition vers Forrit !
Vos questions sur le CMS headless
Un CMS headless stocke et gère le contenu séparément de sa présentation, et le diffuse via une API, généralement en JSON. Les développeurs choisissent le front-end, et le même contenu peut alimenter des sites web, des applications et d’autres canaux.
Les configurations purement headless laissent souvent les équipes de contenu sans aperçu des pages, exigent un développeur pour les nouvelles pages ou mises en page, demandent aux rédacteurs de travailler avec des types de contenu et des références plutôt qu’avec des pages, et obligent à assembler les fonctionnalités au niveau de la page, comme le SEO, à partir d’autres outils. Forrit est conçu pour supprimer ces compromis.
Oui. Dans Forrit, headless ne veut pas dire sans page. Les types de contenu et les entrées restent structurés et réutilisables, et les pages les organisent avec une route, du SEO et des métadonnées. Le canal JSON diffuse chaque page sous forme de données : votre front-end garde la maîtrise de la présentation.
Le canal JSON publie le contenu en JSON pur, sans balisage, depuis une couche de diffusion séparée du CMS. Les front-ends peuvent demander une page entière, avec sa route, ses métadonnées SEO, sa navigation et ses composants, ou demander des entrées et des types de contenu individuels.
Oui. Une page Forrit peut combiner des entrées issues de nombreux types de contenu, et le canal JSON renvoie la page entière en une seule réponse, avec les composants dans l’ordre défini par les rédacteurs. Le modèle JSON de chaque composant détermine les champs restitués, et lorsqu’une entrée partagée est publiée, chaque page qui l’utilise est mise à jour automatiquement.
Oui. Les modifications sont faites dans une branche de tâche, et les rédacteurs peuvent prévisualiser la page dans Forrit avant de l’envoyer en approbation, sans build d’aperçu à prévoir par vos développeurs. Les équipes peuvent aussi afficher le JSON brouillon de la branche de tâche dans leur propre front-end.
Dans de nombreuses plateformes headless, les champs SEO sont ajoutés à chaque type de contenu ou gérés dans le front-end. Dans Forrit, les pages portent le titre SEO, la description et les métadonnées pour tous les types de page, et ces métadonnées sont diffusées dans le JSON avec le contenu.
Forrit inclut les variantes d’audience : vous pouvez créer du contenu pour différentes audiences et choisir les composants affichés pour chacune. La personnalisation complète et l’A/B testing sont assurés par des services spécialisés que vous connectez à Forrit, composable par conception.