Pourquoi je code tout sur-mesure, sans page builder
On me demande souvent pourquoi je ne livre pas un site monté sur Elementor ou Webflow : ce serait plus rapide, donc moins cher. C'est vrai au démarrage. Le problème arrive après. Un page builder empile des dizaines de div imbriquées, charge sa propre librairie d'animations et son CSS générique sur chaque page. Vous payez ça à chaque visite, en temps de chargement et en score Core Web Vitals — exactement ce que Google regarde pour le référencement. Le sur-mesure, lui, n'envoie au navigateur que ce dont la page a réellement besoin.
Le vrai sujet, c'est la propriété de votre produit. Avec un builder, vous êtes locataire : si l'outil change ses tarifs, casse une mise à jour ou ferme, vous subissez. Quand j'écris le code en Next.js et que je le pousse sur votre dépôt Git, le projet vous appartient pour de bon. N'importe quel développeur peut le reprendre, l'auditer, le faire évoluer. Il n'y a pas de boîte noire ni d'abonnement caché qui conditionne la survie de votre site.
Le sur-mesure permet aussi de coller exactement à votre métier. Une logique de réservation, un calcul de devis, une synchro avec votre logiciel de caisse : un builder vous force à entrer dans un moule, puis à bricoler avec des plugins qui se marchent dessus. En partant d'une base propre, je modélise vos règles telles qu'elles sont vraiment, sans compromis ni rustine. Le code devient un atout durable, pas une dette qu'on traîne.
Soyons honnêtes : tout ne mérite pas du sur-mesure. Pour une landing page jetable testée sur une semaine, ou un blog purement éditorial sans contrainte particulière, un outil clé en main fait très bien le job — je le dis à mes clients quand c'est le cas. Mais dès qu'un site devient un actif sur lequel vous comptez plusieurs années, qu'il porte du SEO sérieux ou de la logique métier, le code écrit à la main est presque toujours le meilleur investissement.
Ma stack pour des produits qui durent : Next.js + Go