Cela fait plusieurs années que je travaille en tant que développeur freelance. Avec le temps, j’ai eu l’occasion d’expérimenter de nombreux langages et frameworks. Certains sont restés dans ma boîte à outils, d’autres non. Voici un état des lieux de mes choix technologiques aujourd’hui.
Feuilles de style : retour au CSS Vanilla
Après avoir testé SCSS, Tailwind CSS et d’autres outils moins mémorables, je reviens cette année encore au CSS Vanilla. Mon objectif n’est pas de rejeter les frameworks, mais de maîtriser les bases et d’éviter de construire des styles sur une technologie qui pourrait disparaître.
Au final, tout se compile en CSS, et je préfère un contrôle total plutôt que de dépendre d’outils supplémentaires dont je ne vois pas toujours l’intérêt, surtout sur des projets front peu complexes.
Gestion de contenu : pourquoi WordPress reste incontournable
J’ai testé de nombreux CMS et solutions headless : Strapi, Storyblok, Directus, Cockpit, KirbyCMS, GravCMS, CraftCMS… Mais je reviens toujours à WordPress.
Même si j’ai longtemps été critique vis-à-vis de cet outil, il reste extrêmement polyvalent :
- Gratuit et sans licence restrictive pour les petits projets
- Large écosystème de plugins permettant d’ajouter des fonctionnalités rapidement
- Gutenberg, un éditeur de blocs qui, finalement, est plutôt efficace
Pour des sites web classiques, les CMS headless me paraissent moins pertinents : ils demandent souvent un serveur supplémentaire et une expertise DevOps que je n’ai pas envie de gérer. WordPress, en PHP, s’héberge facilement sur un serveur mutualisé ou Apache, ce qui simplifie énormément mon workflow.
Aujourd’hui, je développe principalement des thèmes classiques intégrant des blocs Gutenberg natifs. J’envisage d’expérimenter le Full Site Editing (FSE) en 2026, principalement parce que c’est présenté comme l’avenir de WordPress et que je n’ai pas trouvé d’alternative offrant un éditeur de blocs simple, un bel écosystème de plugins et la compatibilité PHP.
Sites statiques : Hugo en première ligne
Côté générateurs de sites statiques (SSG), j’ai exploré Nuxt, Next, Astro, 11ty, Vike…
J’étais récemment sur 11ty, un excellent outil Node.js, mais trop “unopinionated” : il demande de configurer beaucoup de fonctionnalités basiques comme :
- Sitemap / SEO
- Multilingue
Aujourd’hui, mon choix se porte sur Hugo, qui propose un écosystème complet par défaut, tout en restant léger. Même si je ne connais pas Go, Hugo répond parfaitement à mes besoins sans configurations supplémentaires.
Backend : Laravel, un classique fiable
Pour le backend, j’utilise Laravel. Performant, facile à héberger, il offre également des solutions rapides pour créer des back-offices (coucou FilamentPHP). Laravel reste un choix sûr pour des projets robustes et évolutifs.
Interactivité : JavaScript Vanilla
Comme pour le CSS, je privilégie JavaScript Vanilla, sans TypeScript. Mon usage se concentre sur :
- Manipulation du DOM
- Animations avec GSAP
- JavaScript orienté objet et, potentiellement, des Web Components
L’objectif reste de garder la stack légère et efficace.
Tooling : minimal et efficace
Mes outils de build sont simples :
- ESbuild pour mes thèmes WordPress
- Vite avec Laravel (configuration par défaut satisfaisante)
- Hugo gère le build de mon CSS et JS
L’idée est de ne pas complexifier inutilement la stack.
Hébergement : pragmatique et fiable
Après avoir testé Netlify, Vercel, Cloudflare Pages et des VPS, je reviens sur des serveurs PHP managés/mutualisés. Cela reste le meilleur compromis entre :
- Simplicité d’usage
- Coût maîtrisé
- Portabilité
Je n’ai pas la prétention d’être DevOps, donc je privilégie les solutions qui permettent de livrer rapidement des sites fiables sans me compliquer la vie.
En résumé, ma stack aujourd’hui est une combinaison de simplicité, robustesse et maîtrise : CSS et JS Vanilla, WordPress pour les sites dynamiques, Hugo pour les sites statiques, Laravel pour le backend, et un hébergement PHP facile à gérer. Une approche pragmatique, pensée pour durer.
