De Figma à Gutenberg (WP Meetup Nice, 2026)

Le jeudi 16 avril puis le mardi 26 mai 2026, j’ai eu le plaisir de co-animer deux soirées du WordPress Meetup de Nice avec Amine Atia Atia, autour d’un même fil rouge : « De Figma à Gutenberg : anatomie d’une refonte WordPress performante ». Amine a ouvert le bal côté design avec la partie Figma, et j’ai pris le relais sur l’intégration WordPress. Les deux rendez-vous se sont déroulés dans une atmosphère très conviviale, au Mitwit (ex-Startway), face à la gare Thiers. Un grand merci à Valérie Galassi pour l’organisation, à o2switch pour le sponsoring qui permet de louer la salle, et à toutes les personnes présentes pour leur intérêt et leurs questions pointues autour de Figma, de Gutenberg et de la web performance.

Contexte du Meetup

Le rendez-vous est porté par le groupe WordPress In Nice (WiNi), communauté locale dédiée aux utilisateurs, développeurs et passionnés de WordPress :

• Organisation : événement animé par Valérie Galassi pour le groupe WordPress In Nice, dans une logique de partage technique et de montée en compétences ;
• Un fil rouge en deux volets : une première soirée consacrée à Figma, une seconde entièrement dédiée à la traduction des maquettes en site WordPress fonctionnel ;
• Un report assumé : lors de la première soirée, les échanges autour de Figma ont été si riches que la partie WordPress n’a pas pu tenir dans le créneau, d’où une partie 2 dédiée ;
• Format pratique : ordinateurs sous le bras pour la seconde session, avec une étude de cas concrète de refonte, de la maquette Figma jusqu’au rendu final dans l’éditeur de blocs.

L’objectif tenait en une idée simple : montrer qu’intégrer une maquette Figma est possible avec n’importe quel page builder, mais que le résultat est loin d’être équivalent en matière de performance, de maintenabilité et de pérennité.

Plan des sujets abordés

La partie Figma, animée par Amine Atia Atia

Amine a posé les fondations du sujet côté conception, en montrant comment Figma s’intègre réellement dans un workflow de refonte :

• Fondamentaux de Figma : principes de l’outil, contextes d’utilisation et place dans un processus de conception structuré ;
• Fondations du design : mise en place des bases (grilles, styles, composants) avant la production des écrans ;
• Maquettes et itérations : construction des pages et cycles d’allers-retours jusqu’à validation ;
• Démonstration sur un cas réel : visualisation du process de bout en bout, qui a nourri de nombreuses questions de la salle.

Choisir son page builder

La première brique d’une intégration durable, c’est le choix de l’outil. Mon parti pris reste Gutenberg comme socle natif, complété au besoin par des librairies de blocs ciblées :

• Pourquoi Gutenberg : éditeur natif, donc léger (pas de surcouche tierce qui alourdit l’interface), compatibilité et support optimaux, mises à jour qui suivent voire devancent le cœur via l’extension Gutenberg ;
• Évolutivité garantie : aucune dépendance à un plugin tiers pour les fonctions de base, là où Elementor v4 (Atomic Editor) ou Divi 5 imposent de tout reconstruire derrière un marketing séduisant ;
• Librairies de blocs complémentaires : on peut mixer Spectra, GenerateBlocks, Kadence Blocks, Ultimate Blocks, Greenshift ou Unblock, avec un surcoût de performance minime ;
• Le duo GenerateBlocks + GeneratePress : cohérent du thème à la mise en page, et pensé autour du CSS (ciblage des enfants, pseudo-éléments, interactions avancées) ;
• L’angle mort du mobile-first : aucun outil ne l’est vraiment aujourd’hui ; l’idéal serait de partir d’une maquette Figma mobile, alors qu’en pratique on simplifie du desktop vers le mobile. Unblock, français, est le premier à permettre véritablement l’inverse.

Centraliser les styles et maîtriser l’architecture CSS

Une intégration performante repose sur des styles centralisés et une dette CSS contenue. L’idée est de styliser une fois, proprement, puis de réutiliser :

• Variables et classes globales : couleurs gérées via le thème GeneratePress (changement global en un clic), et classe unique pour la colonne centrale afin de garantir une largeur cohérente sur le header, le footer et les composants ;
• Global Styles de GenerateBlocks : très puissants pour les composants récurrents comme les post cards ou les hero banners ;
• CSS maîtrisé côté thème : on limite le volume de CSS du thème enfant, et plus encore du Customizer, qu’on réserve aux fonctionnalités non gérées comme les animations à base de @keyframes ;
• Réduire la profondeur du DOM : viser toujours le volume de DOM minimum, CSS Grid évitant l’empilement de wrappers propre à Flexbox, et les pseudo-éléments ::before / ::after décorant sans div supplémentaire ;
• Un exemple concret : le composant « target-quote » en 2 div + pseudo-éléments, contre environ 8 div en Flexbox pur.

Composants et fonctionnalités avancées

Passé les fondations, certains composants méritent d’être repensés plutôt que reproduits tels quels depuis la maquette :

• Sliders à éviter : même SwiperJS, retenu par GenerateBlocks, n’est pas optimal ; le scroll horizontal natif en CSS est plus léger et plus performant ;
• Overlay panels : méga menu et modale de recherche implémentés proprement, avec une comparaison du volume de ressources entre le natif GeneratePress et les Overlay Panels de GenerateBlocks ;
• Gutenberg avancé : copier/coller de blocs (une base souvent sous-estimée), compositions synchronisées ou non pour le gain de temps et la cohérence, et Block Patterns & Elements pour les zones dynamiques (hooks, conditions d’affichage).

Ces choix ne sont pas anecdotiques : c’est précisément là que se joue l’écart entre une refonte fidèle à la maquette et une refonte réellement performante.

Optimiser la gestion des ressources

Dernier maillon, et non des moindres : les ressources chargées par la page, qui pèsent directement sur les Core Web Vitals :

• Images : jamais en background-image CSS, toujours en <img> pour le LCP et l’accessibilité, en particulier sur les bannières hero qui conditionnent le ressenti de chargement ;
• Polices : trois familles maximum au-delà desquelles le coût réseau et l’incohérence visuelle s’installent, recours aux variable fonts (un seul fichier pour toutes les graisses), et exemple de la police mono comme élément d’identité à coût réduit ;
• Icônes SVG : SVG inline avec sprites pour zéro requête HTTP supplémentaire, et bannissement des webfonts d’icônes type Font Awesome.

Mis bout à bout, ces réflexes dessinent une équation simple : du natif, du CSS maîtrisé et des ressources optimisées donnent l’intégration Figma vers WordPress la plus solide et la plus maintenable dans le temps.

Ce que cette double soirée a confirmé

Que la partie Figma ait suffi à remplir une soirée entière en dit long : le pont entre design et intégration suscite un vrai appétit dans la communauté niçoise. Côté WordPress, les échanges ont confirmé que la performance d’une refonte ne se décide pas à la fin, au moment d’optimiser, mais bien dès l’intégration, dans le choix du page builder et dans la discipline appliquée au DOM, au CSS et aux ressources.

Un grand merci encore à Valérie Galassi pour l’organisation, à o2switch pour le sponsoring qui rend ces rencontres possibles, à Amine Atia Atia pour la co-animation et la partie Figma, ainsi qu’à toutes les personnes présentes pour leurs retours, leurs questions et leurs idées, qui donneront sans doute lieu à d’autres rendez-vous WordPress à Nice.

Plus d’infos : De Figma à Gutenberg (16 avril), De Figma à Gutenberg — Partie 2 (26 mai) et le groupe WordPress In Nice.

Dernière mise à jour le le 19 juin 2026