Depuis plus de 20 ans, je construis des sites web. Et si je devais résumer cette période en une phrase, je dirais que j’ai appris à faire confiance aux standards plutôt qu’aux promesses. J’ai traversé l’époque du code à la main, la transition vers les CMS, l’essor des constructeurs de pages, l’arrivée de Gutenberg, et maintenant les premiers pas du Full Site Editing. À chaque étape, j’ai dû choisir mes outils — non pas pour suivre la tendance, mais pour garantir à mes clients des sites rapides, maintenables et pérennes.
Les débuts : Dreamweaver, le code à la main
Pendant une grande partie de ma carrière, j’ai travaillé en agence. Mon quotidien, c’était la création de sites web — mais aussi la retouche photo — dans un environnement où les projets étaient souvent des intranets sur mesure. Dans ce contexte, les CMS n’avaient pas leur place : chaque projet avait ses propres contraintes, ses propres logiques métier. On codait des solutions maison, et c’était mon environnement de travail, c’était Dreamweaver — un éditeur HTML qui me permettait de concevoir des pages directement dans le code, pixel par pixel.
Cette approche était exigeante, mais elle avait une vertu majeure : je savais exactement ce que générait chaque ligne. Pas de code superflu, pas de dépendance cachée. Un site propre, maîtrisé de bout en bout. C’est cette expérience qui m’a rendu durablement exigeant sur la qualité du code — une exigence que je n’ai jamais abandonnée, même en changeant d’outils.
La transition vers les CMS est venue progressivement, à mesure que les projets de sites publics prenaient de la place. J’ai d’abord travaillé sur Typo3, un système puissant mais complexe, réservé aux projets d’envergure. Puis sur Drupal, plus accessible, mais qui demandait encore une vraie maîtrise technique. C’est finalement WordPress qui m’a convaincu — non pas parce qu’il était le plus simple, mais parce qu’il était le plus évolutif. J’y suis arrivé tardivement, avec le regard critique de quelqu’un qui avait codé à la main pendant des années. Ce regard, je l’ai gardé.
L’ère des constructeurs de pages : l’illusion de la liberté
Entre 2015 et 2020, une vague déferle sur l’écosystème WordPress. C’est aussi l’époque où je commence à travailler régulièrement sous WordPress. Elementor, Divi, WPBakery, Beaver Builder : ces outils promettent de révolutionner la création de sites. Fini le code, place au glisser-déposer. L’idée est séduisante, et le succès fulgurant. Elementor dépasse aujourd’hui les 10 millions d’installations actives, soit près de 13 % de tous les sites WordPress dans le monde.
Je n’ai pas construit de sites avec ces outils. En revanche, j’en assure la maintenance pour plusieurs clients — ce qui m’a donné une vue particulièrement lucide sur leur réalité quotidienne.
Et cette réalité est souvent décevante.
Les mises à jour majeures d’Elementor, par exemple, s’accompagnent régulièrement de correctifs en cascade. Il n’est pas rare de voir deux ou trois versions sortir en quelques jours pour corriger les bugs introduits par la précédente. Pour un développeur en charge de la maintenance, c’est une surveillance permanente. Pour le client, c’est l’inquiétude à chaque notification.
Il m’est arrivé de vivre une situation caractéristique de ces outils : un client ouvre un article dans l’éditeur Gutenberg natif — sans savoir que la page avait été construite avec Elementor. Il l’enregistre. Résultat : la mise en page est détruite. Ce genre d’incident, anodin en apparence, illustre parfaitement le problème fondamental des constructeurs de pages : ils créent une dépendance technique invisible, une coexistence fragile avec le reste de WordPress.
À cela s’ajoutent des performances souvent médiocres. Chaque widget, chaque module injecte son lot de CSS et de JavaScript, qu’il soit utilisé ou non. Les temps de chargement s’allongent, les scores de performance chutent. Dans un contexte où la vitesse est un facteur de référencement direct — Google l’intègre dans ses Core Web Vitals depuis 2021 — c’est un frein réel pour les clients.
La liberté promise par ces outils n’est, en réalité, qu’une liberté sous condition : celle de ne jamais les quitter.
2021 : le tournant GeneratePress et GenerateBlocks
2021 est une année charnière à double titre : je me mets à mon compte en tant que développeur freelance, et je change radicalement d’approche technique. Ces deux décisions sont le fruit d’une transition professionnelle entamée en 2019.
Cette période de transition, je l’ai vécue comme une opportunité de remettre à plat toutes mes compétences. Deux ans à me remettre à niveau sérieusement : HTML, CSS, JavaScript, PHP avec Symfony, une incursion dans React, et bien sûr WordPress dans ses recoins. J’ai aussi profité de cette période pour tester méthodiquement plusieurs thèmes WordPress — des solutions « tout-en-un », des thèmes minimalistes, des frameworks de blocs. Ce travail de comparaison m’a conduit à GeneratePress, non pas par défaut, mais par élimination raisonnée.
En devenant indépendant, je suis pleinement responsable des choix que je fais pour mes clients — et donc de leurs conséquences à long terme. Ce contexte m’a poussé à aller chercher des outils dans lesquels j’avais une confiance totale.
Je découvre GeneratePress, un thème WordPress conçu autour d’un principe simple : ne charger que ce qui est nécessaire. Combiné à GenerateBlocks, une extension de blocs Gutenberg, il offre une flexibilité de mise en page que je n’aurais pas cru possible avec si peu.
Aujourd’hui, j’utilise GP One — l’offre qui regroupe GeneratePress Premium et GenerateBlocks Pro. C’est ma boîte à outils principale pour tous mes projets clients.
Les résultats sont mesurables. Sur un site vitrine dans le secteur bien-être, j’obtiens 97/100 sur mobile et 86/100 sur desktop avec Google PageSpeed Insights. Sur un site pour un cabinet de conseil, les scores atteignent 91/100 sur mobile et 100/100 sur desktop. Ces performances ne sont pas le fruit du hasard : elles sont la conséquence directe d’une architecture allégée et d’un code propre.
Ce qui me convainc le plus dans cet écosystème, c’est la fonctionnalité Éléments de GeneratePress. Elle permet d’insérer du contenu conditionnel — un bandeau, un appel à l’action, un bloc personnalisé — sur certaines pages seulement, sans toucher au code. C’est une flexibilité que les constructeurs de pages promettent, mais que GeneratePress offre de façon beaucoup plus propre et transparente.
La gestion des polices mérite aussi d’être mentionnée. WordPress ne propose une gestion native des polices que depuis la version 6.7. GeneratePress offrait cette fonctionnalité depuis longtemps, via une interface claire, sans dépendance à Google Fonts ou Adobe Fonts.
GenerateBlocks Pro est actuellement en version 2.5, et la version 2.6 est en cours de développement. Elle devrait intégrer un système de formulaires natifs et la possibilité d’écrire du CSS directement sur les blocs — une évolution qui m’intéresse, même si elle m’invite à la vigilance.
Car j’ai une légère inquiétude : plus GenerateBlocks s’enrichit de fonctionnalités, plus le risque de devenir une « usine à gaz » grandit. C’est exactement le chemin qu’ont emprunté les constructeurs de pages. Aujourd’hui, l’outil reste léger et maîtrisable. J’espère que l’équipe saura trouver le bon équilibre — et à voir leur écoute de la communauté et la réactivité de leur support, j’ai des raisons d’y croire.
Le FSE : l’avenir que j’expérimente, sans me précipiter
Depuis 2022, WordPress accélère sa transition vers le Full Site Editing. L’idée est ambitieuse : permettre de concevoir l’intégralité d’un site — en-tête, pied de page, templates de pages — directement dans l’éditeur de blocs, sans toucher à une ligne de PHP.
Mon propre site, bdelanls.fr, est entièrement construit en FSE. C’était une décision délibérée : apprendre par la pratique, tester les limites de la technologie avant de la proposer à des clients.
Honnêtement ? Je pensais être à l’aise rapidement.
Avec GeneratePress, je connais les contraintes du système. Je sais jusqu’où je peux aller visuellement, où sont les limites, et comment les contourner. Cette maîtrise me donne une vraie liberté de conception. En FSE, je n’ai pas encore cette cartographie mentale. Je ne connais pas les limites, et cette incertitude bride la créativité plutôt qu’elle ne la libère. Ce n’est pas un défaut du FSE — c’est la réalité de l’apprentissage.
Pour cette raison, je ne propose pas encore le FSE à mes clients. Ce serait prématuré : je n’ai pas assez de recul pour en garantir la maîtrise sur des projets où les enjeux sont réels. Je préfère consolider mon expérience sur mon propre site avant de franchir ce cap.
Cela dit, je suis convaincu que c’est l’avenir. Automattic investit massivement dans cette direction, les thèmes FSE-ready se multiplient, et le signal est clair. Ignorer le FSE serait une erreur. Le sous-estimer en le proposant trop tôt en serait une autre.
Mon approche avec les clients
Mes clients ne sont pas développeurs. Ils ne savent pas toujours ce que signifie « Elementor » ou « FSE ». Et c’est normal — ce n’est pas leur métier.
Lorsqu’un client me contacte pour une refonte, je commence par un audit technique. Si le site est sous Divi, Elementor ou WPBakery, je lui explique clairement ce que cela implique : les dépendances, les risques lors des mises à jour, les performances souvent en retrait. Et je lui présente ce que je peux lui apporter en passant sur GeneratePress : rapidité, pérennité, autonomie réelle dans l’édition du contenu.
Après l’installation, je propose une formation courte à l’éditeur Gutenberg. L’objectif est simple : que le client soit autonome pour les modifications courantes — ajouter un article, modifier un texte, changer une image — sans dépendre de moi pour chaque petite mise à jour.
Pour les clients dont j’assure uniquement la maintenance d’un site sous constructeur de pages, je gère les mises à jour avec vigilance, je teste après chaque version majeure, et j’informe le client quand une migration devient pertinente. Ce n’est pas une urgence dans tous les cas, mais c’est une conversation à avoir tôt ou tard.
Ce que ça change concrètement pour vous
Si vous lisez cet article en tant que client potentiel ou en réflexion sur une refonte, voici ce qu’il faut retenir.
Un site sous GeneratePress, c’est un site que vous pouvez modifier sans risquer de tout casser. C’est un site qui charge vite — et la vitesse n’est pas un luxe : elle conditionne votre référencement, votre taux de rebond, et l’image que vous renvoyez à vos visiteurs. C’est aussi un site qui vieillira bien, parce qu’il repose sur les standards de WordPress plutôt que sur les choix propriétaires d’un éditeur tiers.
Mon rôle n’est pas de vous imposer un outil. C’est de choisir, pour chaque projet, la solution qui vous servira le mieux — aujourd’hui et dans cinq ans.
Conclusion : pragmatisme et regard vers demain
Après 20 ans dans ce métier, j’ai appris à me méfier des outils qui promettent tout. Les meilleurs outils sont ceux qu’on maîtrise, qu’on fait évoluer avec exigence, et qui restent alignés avec les standards de la plateforme sur laquelle on travaille.
GeneratePress et GenerateBlocks, c’est mon choix actuel — réfléchi, éprouvé, et régulièrement remis en question. Le FSE est sur ma feuille de route, pas encore sur celle de mes clients. Et c’est là toute la nuance d’une approche pragmatique.
WordPress propulse aujourd’hui 42 % des sites dans le monde, loin devant tous ses concurrents. Ce n’est pas une coïncidence : c’est la récompense d’une plateforme capable de se réinventer sans trahir ses fondamentaux. Suivre cette évolution avec discernement, c’est le cœur de mon travail.
Questions fréquentes
Mon site est sous Elementor ou Divi. Faut-il migrer d’urgence ?
Pas nécessairement. Cela dépend de l’état du site, de ses performances actuelles et de vos projets. Je commence toujours par un audit avant de recommander quoi que ce soit. Une migration se justifie souvent lors d’une refonte globale plutôt que comme intervention isolée.
GeneratePress est-il payant ?
GeneratePress existe en version gratuite, suffisante pour des projets simples. J’utilise GP One, qui regroupe GeneratePress Premium et GenerateBlocks Pro. C’est un investissement annuel raisonnable, sans comparaison avec les coûts cumulés d’un constructeur de pages : licence Pro, extensions, templates premium…
Qu’est-ce que le Full Site Editing ?
Le FSE est une fonctionnalité native de WordPress qui permet de concevoir l’ensemble d’un site — y compris l’en-tête et le pied de page — depuis l’éditeur de blocs Gutenberg, sans toucher au code PHP. C’est l’avenir de la plateforme, encore en cours de maturation.
Gutenberg, c’est difficile à utiliser pour un client non technique ?
Non, dès lors qu’on distingue l’édition de contenu (ajouter un article, modifier un texte) et la construction de pages (créer des mises en page complexes). Pour l’édition courante, Gutenberg est intuitif. C’est pourquoi je forme mes clients à ce premier niveau lors de la livraison du site.
Pourquoi ne pas utiliser Elementor si c’est si populaire ?
La popularité n’est pas un gage de qualité technique. Elementor répond à un besoin réel, mais crée une dépendance forte : au constructeur, à ses mises à jour, à son code propriétaire. Pour des sites destinés à durer et à performer, je préfère des solutions qui restent proches des standards WordPress.
GeneratePress convient-il à tous les types de projets ?
Pour la grande majorité : oui. Sites vitrines, blogs, portfolios, sites institutionnels — GeneratePress gère tout cela très bien. Pour des projets e-commerce complexes ou des besoins très spécifiques, l’analyse se fait au cas par cas.On imagine souvent Internet comme quelque chose d’immatériel, mais la réalité est tout autre. Le numérique représente aujourd’hui environ 4 % des émissions mondiales de gaz à effet de serre, soit autant que l’aviation civile. Chaque page web chargée, chaque e-mail envoyé, chaque vidéo visionnée consomme de l’énergie produite en grande partie à partir de sources fossiles.
