Qu'est-ce qu'un bloc de contenu ?

Qu'est-ce qu'un bloc de contenu ?

Un bloc de contenu est une unité de contenu réutilisable et structurée dans un système de gestion de contenu (CMS) ou un constructeur de pages : un hero, un tableau de tarifs, une FAQ, une galerie ou un appel à l'action. Chaque bloc a des champs définis et une seule manière cohérente de s'afficher. Les rédacteurs construisent une page en empilant des blocs au lieu de mettre en forme un grand champ de texte libre, ce qui sépare le contenu de sa présentation.

Comment fonctionnent les blocs de contenu

Un bloc comporte généralement trois parties :

• Schéma : les champs et les règles, par exemple un hero avec un titre obligatoire, un libellé de bouton et un lien.
• Formulaire d'édition : les champs que remplit le rédacteur, générés à partir du schéma.
• Rendu : le gabarit ou le composant front-end qui transforme les données du bloc en HTML.

Une page est alors une liste ordonnée d'instances de blocs. Dans Sanity, par exemple, un constructeur de pages est un tableau de types d'objets, et chaque élément enregistré porte son type dans _type et une clé unique _key (documentation Sanity). L'éditeur de blocs de WordPress repose sur la même idée : la FAQ de Gutenberg décrit la rédaction et la mise en page des articles et des pages avec des blocs, enregistrés dans le contenu de l'article (documentation WordPress).

Exemple

Une équipe marketing a besoin d'une page de destination. Elle ajoute un bloc hero, un bloc de fonctionnalités sur trois colonnes, un bloc de témoignages et un bloc FAQ, puis remplit les champs. Le développeur a construit chaque bloc une seule fois. Quand l'équipe crée une seconde page de destination, elle réutilise les mêmes quatre blocs, et la mise en page, les niveaux de titres et les espacements concordent sans nouveau code.

Pourquoi les blocs valent mieux qu'un grand champ de texte

• Cohérence. Deux rédacteurs ne peuvent pas styliser la même section différemment.
• Réutilisation. Un bloc peut apparaître sur de nombreuses pages, et une instance partagée se modifie une seule fois.
• Balisage plus propre. Les champs remplacent le HTML collé qui traîne des styles parasites.
• SEO et accessibilité facilités. Les niveaux de titres et les champs de texte alternatif peuvent être exigés dans le schéma.
• Contenu structuré. Le CMS peut répondre à des questions comme : quelles pages utilisent un tableau de tarifs ?

Erreurs courantes

• Trop de types de blocs. Commencez par les quelques-uns que vous utilisez vraiment et ajoutez-en quand un besoin réel apparaît.
• Schémas surdimensionnés. Un hero de trente champs facultatifs submerge les rédacteurs. Découpez-le en variantes.
• Aucune limite de design. Si chaque bloc permet de changer couleurs et espacements, vous retrouvez des pages incohérentes.
• Plusieurs H1 sur une page. Cinq blocs hero peuvent donner cinq H1. Fixez le niveau de titre dans le schéma.
• Oublier la localisation. Chaque champ de texte a besoin d'une valeur par langue.
• Modifier un schéma sans migrer. Renommer un champ rend les instances de blocs existantes invalides tant qu'elles ne sont pas migrées.
• Ignorer le poids. Chaque type de bloc que rend votre front-end ajoute du balisage, des scripts et des images. Chargez en différé les blocs lourds situés sous la ligne de flottaison.

Blocs de contenu et performance du site

Les blocs rendent les pages faciles à assembler, donc faciles à surcharger. Beaucoup de blocs sur une page peuvent s'additionner en scripts et requêtes, ce qui se voit dans les Core Web Vitals. La façon dont la page est construite compte aussi : voir génération de sites statiques et rendu côté serveur. Un contenu qui passe par le brouillon, la relecture et la publication demande en outre un processus clair : cycle de vie du contenu.

Testez le résultat au lieu de deviner. Le test de vitesse de site LoadFocus montre comment se comporte une page riche en blocs, et le suivi de la vitesse des pages la surveille après chaque changement de contenu. Si votre CMS expose une API REST ou GraphQL, un test de charge d'API montre si elle tient lors d'un pic de trafic. Les guides du blog sur la surveillance des Core Web Vitals et l'amélioration du score de performance WordPress détaillent la suite.

Questions fréquentes : blocs de contenu

Quelle est la différence entre un bloc de contenu et un composant ?

Les deux mots sont souvent employés l'un pour l'autre. À proprement parler, le bloc est le côté CMS (schéma, formulaire d'édition et contenu) et le composant est le code front-end qui le rend. Dans beaucoup de configurations, ils vont par paires.

Les blocs de contenu sont-ils la même chose qu'un constructeur de pages ?

Non. Les blocs sont les unités de contenu. Un constructeur de pages est l'interface d'édition qui permet de les agencer.

Les blocs de contenu aident-ils le SEO ?

Ils peuvent aider, car les niveaux de titres, les textes alternatifs et les données structurées peuvent être imposés dans le schéma. Ils peuvent aussi nuire, par exemple quand plusieurs blocs produisent chacun un H1 ou quand des blocs lourds ralentissent la page.

Faut-il un CMS headless pour utiliser des blocs ?

Non. Les CMS traditionnels comme WordPress utilisent aussi des blocs. Un CMS headless stocke les blocs sous forme de données et laisse plusieurs front-ends les afficher, ce qui convient à la publication multicanale.

Combien de types de blocs un site doit-il avoir ?

Aussi peu que nécessaire pour couvrir vos pages réelles. Un nouveau type de bloc se justifie quand le même motif apparaît sur plusieurs pages et qu'aucun bloc existant ne convient.