Blocs Gutenberg WordPress : créer des composants sur mesure pour votre site
Vous avez un site WordPress et vous en avez marre des mises en page figées ? Des thèmes où il faut se contorsionner pour afficher un simple témoignage client correctement ? Bienvenue dans le monde merveilleux des blocs Gutenberg sur mesure 🎨
Depuis que WordPress a basculé sur l’éditeur Gutenberg (ça remonte déjà à WordPress 5.0, fin 2018 !), la façon de construire des pages a radicalement changé. Fini le gros champ texte unique : maintenant, chaque élément est un bloc. Un paragraphe, une image, une galerie, un bouton… tout est bloc. Et le truc génial, c’est qu’on peut créer ses propres blocs, taillés exactement pour les besoins du projet 🔧
En tant que développeur freelance WordPress, c’est clairement l’un des aspects les plus excitants de mon métier aujourd’hui. Quand un client me dit « j’aimerais pouvoir modifier facilement cette section de ma page d’accueil », ma réponse est quasi systématiquement : un bloc Gutenberg custom. Et franchement, la tête qu’ils font quand ils voient la simplicité d’utilisation côté back-office… 😊
Gutenberg, c’est quoi exactement ?
Pour ceux qui débarquent (pas de jugement, on a tous commencé quelque part 😅), Gutenberg c’est l’éditeur de contenu natif de WordPress. Avant lui, on avait l’éditeur « classique » — un gros textarea façon Word où on tapait tout en vrac. C’était fonctionnel, mais dès qu’on voulait une mise en page un peu travaillée, il fallait soit du HTML brut, soit un page builder externe.
Gutenberg a changé la donne en introduisant le concept de blocs. Chaque élément de contenu est un bloc indépendant qu’on peut :
- Déplacer librement dans la page (drag & drop)
- Configurer individuellement (couleurs, alignement, espacement…)
- Réutiliser sur d’autres pages (blocs réutilisables)
- Grouper pour créer des mises en page complexes
C’est un peu comme des LEGO® pour votre site web. Sauf qu’au lieu de briques standard rouge et bleu, vous pouvez fabriquer vos propres pièces sur mesure. Et c’est là que ça devient vraiment intéressant.
Pourquoi les blocs natifs ne suffisent pas toujours
WordPress propose une cinquantaine de blocs de base : paragraphe, titre, image, liste, citation, bouton, colonnes… C’est déjà pas mal pour un blog ou un site simple. Mais dès qu’on monte en gamme, les limites apparaissent vite.
Prenons un exemple concret. Un de mes clients dans le secteur du bien-être avait besoin d’afficher ses différentes formules d’abonnement sur sa page d’accueil. Chaque formule devait montrer : un titre, un prix, une liste d’avantages, un bouton d’inscription, et un petit badge « populaire » sur la formule recommandée. Essayez de faire ça proprement avec les blocs natifs… vous allez vite tourner en rond 🔄
Les solutions classiques dans ce cas :
- Un page builder (Elementor, Divi, WPBakery…) → lourd, lent, crée une dépendance technique monstre
- Du HTML/CSS codé en dur dans l’éditeur → le client ne peut rien modifier sans casser la mise en page
- Un shortcode → fonctionnel mais l’expérience d’édition est zéro (le client voit juste
[formule titre="Premium" prix="49"])
Le bloc Gutenberg custom, lui, offre le meilleur des deux mondes : un rendu parfait côté visiteur ET une interface d’édition intuitive côté admin. Le client a ses champs bien organisés dans l’éditeur, il remplit, il déplace les blocs dans l’ordre qu’il veut, et le rendu suit côté front. Zéro ligne de code à toucher. C’est le graal 🏆
ACF Pro + Gutenberg : la combinaison qui change tout
Il existe plusieurs façons de créer des blocs Gutenberg custom. La méthode « pure » en React/JavaScript est puissante mais complexe — il faut maîtriser JSX, les hooks WordPress, le système de build… Pour un développeur front-end JavaScript, c’est dans ses cordes. Mais pour un développeur WordPress PHP, c’est un changement de paradigme assez brutal.
C’est là qu’ACF Pro (Advanced Custom Fields) entre en scène. Ce plugin — que j’utilise sur absolument tous mes projets — permet de créer des blocs Gutenberg custom en PHP. Oui, en PHP ! Pas besoin de compiler du JSX ni de configurer Webpack juste pour un bloc 💪
Le principe est limpide :
- On déclare le bloc dans le thème (une fonction PHP, quelques lignes)
- On définit les champs dans l’interface ACF (texte, image, sélecteur de couleur, répéteur…)
- On crée le template PHP du bloc (le HTML/CSS de rendu)
Et voilà. Vous avez un bloc personnalisé fonctionnel qui apparaît dans l’éditeur Gutenberg, avec des champs configurables directement dans la sidebar. Pas de rendu live à proprement parler — on voit le bloc avec ses champs à remplir, qu’on peut déplacer librement dans la page. Le rendu final, lui, s’affiche côté visiteur. Pour ma part, c’est la méthode que je privilégie systématiquement.
Exemple concret : un bloc « Témoignage client »
Pour vous montrer à quel point c’est accessible, voici comment je crée un bloc témoignage client sur un projet type. C’est l’un des blocs que je développe le plus souvent — quasiment chaque site en a besoin.
Côté champs ACF, je configure :
- Un champ texte pour le nom du client
- Un champ texte pour sa fonction/entreprise
- Un champ textarea pour le témoignage
- Un champ image pour la photo (optionnelle)
- Un champ nombre pour la note (1 à 5 étoiles)
Côté template PHP, le code récupère ces valeurs et les affiche dans une structure HTML propre, stylée en CSS BEM — ma méthode préférée pour les gros projets où la maintenabilité est cruciale. Chaque classe suit une convention stricte (.testimonial__author, .testimonial__content, .testimonial__rating), ce qui rend le code lisible même des mois plus tard.
Le résultat côté back-office ? Le client clique sur « Ajouter un bloc », cherche « Témoignage », et il voit un formulaire clair avec les champs à remplir. Il tape le texte, uploade la photo, sélectionne la note. Pas de rendu visuel en live dans l’éditeur — c’est le compromis des blocs ACF — mais l’interface est tellement intuitive que le client sait exactement ce qui va s’afficher. Et il peut réorganiser ses blocs en drag & drop. Zéro formation nécessaire, zéro appel au développeur pour « changer un témoignage ». Autonomie totale 🙌
Blocs Gutenberg vs page builders : le match
Je sais que beaucoup de gens utilisent encore Elementor ou Divi pour construire leurs pages. Et je comprends l’attrait : c’est visuel, intuitif, on voit le résultat en temps réel. Mais quand on creuse un peu, les blocs Gutenberg custom gagnent sur presque tous les plans.
Les performances d’abord. Un page builder charge des tonnes de CSS et JavaScript sur chaque page — même si vous n’utilisez que 3 widgets sur 200. J’ai déjà audité des sites où Elementor ajoutait 2 Mo de ressources supplémentaires à chaque chargement de page. Côté Core Web Vitals, c’est un massacre 😬 Un bloc Gutenberg custom, lui, ne charge que le CSS strictement nécessaire.
La dépendance technique ensuite. Si demain vous décidez de quitter Elementor, toute votre mise en page explose. Vos pages deviennent un champ de shortcodes incompréhensibles. Avec Gutenberg, vous restez dans l’écosystème natif de WordPress — c’est du HTML propre stocké en base, pas du shortcode propriétaire.
La maintenabilité enfin. Un thème WordPress avec des blocs custom en ACF + CSS BEM, c’est un codebase propre, versionné sur Git, déployable en CI/CD. J’ai travaillé sur des projets d’envergure — comme mes collaborations avec des groupes médias et des grandes enseignes — où cette rigueur technique fait la différence entre un site qui tient 5 ans et un site qu’il faut refondre tous les 18 mois.
Attention, je ne dis pas que les page builders sont mauvais dans l’absolu. Pour un petit site vitrine rapide avec budget serré, Elementor peut avoir du sens. Mais pour un projet professionnel qui vise la performance et la durabilité, les blocs Gutenberg custom sont objectivement supérieurs.
Quand utiliser CSS BEM et quand opter pour Tailwind
C’est une question qui revient souvent quand on parle d’intégration de blocs Gutenberg. Deux approches CSS dominent le paysage aujourd’hui, et elles ont chacune leur terrain de prédilection.
CSS BEM custom (Block Element Modifier), c’est ce que je privilégie sur les projets d’envergure. Chaque composant a sa feuille de style dédiée, les classes sont explicites et prévisibles. Sur un site avec 20+ blocs custom, c’est la garantie d’un code CSS maintenable, sans conflits, facile à débuguer même quand un autre développeur reprend le projet. C’est la Rolls-Royce de l’intégration WordPress 💎
Tailwind CSS, de son côté, brille sur les projets où la rapidité de développement prime. Les classes utilitaires directement dans le HTML permettent de prototyper et intégrer très vite. Pour un site vitrine avec un budget serré et des délais courts, c’est redoutablement efficace.
Les deux approches sont parfaitement compatibles avec Gutenberg. Le choix dépend du contexte du projet : complexité, budget, nombre de développeurs impliqués, durée de vie prévue du site. Quand un client me demande mon avis, je pose ces questions et j’oriente vers la solution la plus adaptée — pas de dogmatisme, juste du pragmatisme 🎯
Et le Full Site Editing alors ?
Vous avez peut-être entendu parler du Full Site Editing (FSE), la nouvelle approche de WordPress qui permet d’éditer l’intégralité du site via des blocs — header, footer, templates inclus. Sur le papier, c’est séduisant. En pratique… c’est une autre histoire 😬
Le FSE repose sur des « block themes » développés en React/JavaScript. Et c’est là que ça coince pour moi. D’abord, ça ne se combine pas bien avec ACF Pro — qui reste pourtant l’outil le plus flexible pour créer des champs custom en PHP. Ensuite, le FSE impose des classes WordPress natives partout dans le DOM. Pour les surcharger proprement en CSS, il faut soit réécrire les styles natifs, soit les supprimer un par un. Dans les deux cas, on se retrouve avec un DOM surchargé de classes WordPress qu’on n’a pas demandées 🤦
Pour ma part, je préfère garder le contrôle total sur le markup HTML et le CSS. Avec des blocs Gutenberg via ACF Pro, chaque composant a exactement le HTML que je décide, avec mes classes BEM ou Tailwind — pas de pollution de classes WordPress. Le rendu est plus propre, plus léger, et surtout plus performant côté Core Web Vitals.
Le FSE évoluera sûrement et deviendra peut-être incontournable un jour. Mais aujourd’hui, pour un site professionnel où la performance et la maintenabilité sont prioritaires, les blocs ACF restent la solution la plus solide à mon sens 💪
Mon workflow pour créer un bloc Gutenberg sur mesure
Pour les curieux (et les développeurs qui lisent cet article 👋), voici le workflow que j’ai affiné au fil de mes projets :
- Brief client — Je liste avec le client les sections dynamiques du site. Quels contenus doivent être modifiables ? À quelle fréquence ? Par qui ?
- Identification des blocs — Chaque section modifiable = un bloc custom potentiel. Je regroupe les éléments similaires (ex : un bloc « carte service » réutilisable plutôt que 5 sections hardcodées).
- Création des champs ACF — Je configure les champs dans ACF Pro : types de champs, validations, valeurs par défaut, messages d’aide pour le client.
- Intégration du template — Je code le rendu PHP/HTML/CSS du bloc, en m’appuyant sur les maquettes fournies.
- Tests éditeur — Je vérifie que le bloc fonctionne correctement dans l’éditeur Gutenberg : bon affichage des champs, drag & drop fluide, comportement responsive côté front.
- Documentation — Un petit guide pour le client expliquant comment utiliser chaque bloc. Capture d’écran à l’appui, parce qu’une image vaut mille mots.
Ce processus, je l’ai rodé sur des dizaines de projets. Que ce soit pour une PME lilloise ou un groupe national en full remote, le principe reste le même. L’avantage de travailler avec un développeur freelance WordPress, c’est d’avoir un interlocuteur unique qui maîtrise toute la chaîne — de la conception technique à la livraison du bloc fonctionnel.
Les erreurs à éviter avec les blocs Gutenberg custom
Après des années à développer des blocs custom, j’ai vu (et parfois commis 😅) quelques erreurs classiques. Petit florilège pour vous éviter les pièges :
Créer trop de blocs. C’est tentant de tout transformer en bloc custom. Mais un client qui doit choisir parmi 40 blocs dans l’éditeur, c’est un client perdu. Je recommande de garder entre 8 et 15 blocs custom max, bien organisés par catégorie.
Négliger le responsive. Un bloc qui rend bien sur desktop mais qui explose sur mobile, c’est un classique. Chaque bloc doit être testé sur mobile dès le développement — pas « après, quand on aura le temps ».
Oublier les états vides. Que se passe-t-il si le client ne remplit pas le champ image ? Si le texte est très court… ou très long ? Un bon bloc gère gracieusement tous les cas de figure, même les plus improbables.
Ne pas documenter. Un bloc sans documentation, c’est un bloc que le client n’utilisera pas (ou utilisera mal). Un minimum de guide d’utilisation est indispensable — et ça fait partie de ma prestation standard.
Ignorer l’accessibilité. Les blocs custom doivent être accessibles : contraste des couleurs, navigation clavier, attributs ARIA… C’est un sujet que j’ai détaillé dans mon article sur l’accessibilité web et WordPress, et ça s’applique aussi à 100% aux blocs Gutenberg.
Pourquoi un développeur WordPress pour vos blocs sur mesure
Créer des blocs Gutenberg custom, c’est un métier à part entière. Ça demande de maîtriser PHP, CSS, les API WordPress, ACF Pro, et de comprendre l’UX côté éditeur. Ce n’est pas quelque chose qu’on improvise avec un tuto YouTube et un après-midi libre.
En tant que développeur freelance basé à Lille et travaillant en full remote avec des clients dans toute la France, j’ai intégré les blocs Gutenberg custom dans quasiment tous mes projets depuis 3 ans. Que ce soit pour :
- Des sites vitrines avec des sections d’accueil dynamiques
- Des sites e-commerce WooCommerce avec des fiches produit personnalisées
- Des plateformes éditoriales avec des templates d’article enrichis
- Des intranets avec des dashboards et formulaires internes
Le résultat est toujours le même : un site performant, un client autonome, et un code propre qui ne vieillit pas. C’est ça, la promesse d’un développement WordPress sur mesure bien exécuté. Et les blocs Gutenberg custom en sont la pierre angulaire 💪
Vous avez un projet WordPress et vous voulez des blocs sur mesure qui correspondent vraiment à vos besoins ? Contactez-moi via le formulaire, on en discute et je vous propose une solution adaptée — que vous soyez à Lille, dans les Hauts-de-France, ou n’importe où en France 🇫🇷
FAQ — Blocs Gutenberg WordPress sur mesure
Un bloc Gutenberg custom est un composant d'édition personnalisé créé spécifiquement pour votre site WordPress. Contrairement aux blocs natifs (paragraphe, image, bouton…), un bloc custom est développé sur mesure pour répondre à un besoin précis : afficher des témoignages, des cartes de services, des grilles tarifaires, etc. Il offre une interface d'édition intuitive côté back-office tout en garantissant un rendu parfait côté visiteur.
Pas obligatoirement, mais ACF Pro (Advanced Custom Fields) facilite énormément le processus. Il permet de créer des blocs custom en PHP sans avoir besoin de coder en React/JavaScript. C'est la méthode que je privilégie sur mes projets car elle est plus rapide à mettre en place et plus accessible pour la maintenance future.
Au contraire ! Contrairement aux page builders qui chargent des tonnes de CSS et JavaScript inutiles, un bloc Gutenberg custom ne charge que les ressources strictement nécessaires. C'est l'une des raisons principales pour lesquelles je recommande cette approche plutôt qu'Elementor ou Divi pour les projets professionnels.
Ça dépend de la complexité. Un bloc simple (témoignage, call-to-action) prend entre 1 et 3 heures. Un bloc plus complexe avec des champs conditionnels, des animations ou du responsive avancé peut prendre une demi-journée à une journée. L'avantage, c'est que c'est un investissement one-shot : une fois créé, le bloc est réutilisable à l'infini.
Absolument ! C'est tout l'intérêt. Les blocs custom sont conçus pour être utilisés facilement côté back-office. Vous remplissez les champs (texte, image, couleur…), vous organisez vos blocs dans l'ordre souhaité, et vous publiez. Aucune compétence technique nécessaire pour le contenu. En revanche, modifier la structure ou le design du bloc lui-même nécessite l'intervention d'un développeur.
Pour un projet professionnel qui vise la performance, la maintenabilité et l'indépendance technique, les blocs Gutenberg custom sont la meilleure option. Les page builders (Elementor, Divi) peuvent convenir pour un site simple avec budget très serré, mais ils créent une dépendance technique et impactent les performances. Mon conseil : investir dans des blocs custom dès le départ, c'est économiser sur les refontes futures.