Une stack, pas un empilement
Une stack, ce n'est pas une liste d'outils à la mode collés ensemble. C'est un ensemble de choix qui doivent tenir ensemble — partager une philosophie, se compléter sans se marcher dessus.
On a parlé des briques une par une dans ce journal : HTMX, CodeIgniter 4, la performance, le builder. Voici la vue d'ensemble — comment tout s'emboîte, et pourquoi cet assemblage forme un tout cohérent.
Le fil conducteur tient en une phrase : le serveur reste maître, le client reste léger.
Le principe : le serveur reste la source de vérité
Au centre, une conviction architecturale : le serveur est la source de vérité. Il rend du HTML — pas du JSON qu'un front devrait re-transformer en interface. Le navigateur affiche, déclenche des requêtes, et reçoit en retour des fragments de HTML déjà prêts.
<input type="search" name="q"
hx-get="/recherche"
hx-trigger="input changed delay:300ms"
hx-target="#resultats">
<div id="resultats"></div>public function results()
{
$q = $this->request->getGet('q');
$posts = $this->postModel->search($q);
// On renvoie un FRAGMENT Blade, pas une page entière
return view('partials/results', ['posts' => $posts]);
}Cette boucle — un attribut HTMX déclenche une requête, le contrôleur renvoie un fragment Blade, HTMX l'insère — c'est le cœur battant de toute la stack. Pas de duplication de logique entre back et front, pas d'état client à synchroniser.
Tout le reste découle de ce principe : chaque outil est choisi parce qu'il sert cette boucle, légèrement.
Le socle : CodeIgniter 4 + MariaDB
Le socle, c'est CodeIgniter 4 sur PHP 8.2+ : léger, explicite, qu'on maîtrise de bout en bout (on lui a consacré un article entier). Il gère le routing, les modèles, les migrations, et l'authentification via Shield.
Côté données, MariaDB — un SGBD relationnel éprouvé, fiable, parfaitement à l'aise sur un hébergement OVH/Plesk classique. Rien d'exotique : du solide.
Ce socle ne cherche pas à impressionner. Il cherche à durer.
Le rendu : BladeOne
Le rendu HTML passe par BladeOne, une implémentation autonome du moteur Blade. On écrit des templates lisibles, on découpe en partials — et ces partials sont exactement les fragments que HTMX vient chercher.
C'est un détail qui compte : le même partial sert au rendu initial de la page et aux mises à jour partielles. Une seule source pour un même morceau d'interface.
Le builder, lui, génère des fichiers Blade sur disque (encore un sujet qu'on a creusé). Tout converge vers du Blade.
L'interactivité : HTMX v2
Pour l'interactivité, HTMX v2 : ~10 ko, zéro dépendance, qui transforme n'importe quel élément en déclencheur de requête et ne remplace qu'un fragment. C'est lui qui donne la sensation « application » sans le poids ni la complexité d'un SPA.
Recherche live, pagination, édition inline, dashboards rafraîchis, modales : l'essentiel de l'interactivité d'un site de contenu ou d'un back-office tient là-dedans.
Et comme c'est du HTML déclaratif, ça se lit dans le markup et ça se débogue à l'œil.
Le micro-interactif : Alpine.js
Tout n'a pas besoin d'un aller-retour serveur. Un dropdown qui s'ouvre, un onglet qui bascule, un toggle : c'est du purement local. Pour ça, Alpine.js — un soupçon de réactivité directement dans le HTML.
<div x-data="{ open: false }">
<button @click="open = !open">Menu</button>
<ul x-show="open" @click.outside="open = false">
<li>…</li>
</ul>
</div>HTMX et Alpine se partagent le travail proprement : HTMX pour ce qui touche au serveur (les données), Alpine pour ce qui reste dans le navigateur (l'état d'affichage). Aucun des deux ne marche sur les plates-bandes de l'autre.
Deux petites bibliothèques déclaratives plutôt qu'un gros framework impératif : la même logique de sobriété, appliquée au front.
Le style : Tailwind CSS
Le style, c'est Tailwind CSS : utility-first, on compose l'apparence directement dans le markup, sans aller-retour vers des fichiers CSS éparpillés. Le purge ne garde que les classes réellement utilisées — la feuille finale est minuscule.
C'est aussi le support de notre direction artistique : bordures franches (border-2), ombres dures (.hard), aplats — le brutalisme dont on a fait l'éloge ailleurs. Des tokens cohérents, réutilisés partout.
Deux configs séparées (front et admin), deux univers visuels, un seul outil.
Le build : Vite
Pour l'outillage front, Vite : démarrage instantané, HMR (rechargement à chaud), build optimisé. En dev, on tourne sur deux serveurs Vite (front et admin) derrière un proxy.
L'avantage concret : on code, on voit le résultat immédiatement, sans attendre un bundler poussif. En production, on sert des assets compressés et versionnés.
Vite lit même nos variables d'environnement (le thème actif, par exemple) pour adapter le build — la configuration suit le contenu.
La performance : un réflexe, pas un add-on
La performance n'est pas une option qu'on ajoute à la fin. Redis met en cache ce qui est coûteux mais stable (configs, menus, agrégats), sert les sessions et les files de jobs. AVIF divise le poids des images, le lazy-load ne charge que le visible.
On a détaillé ces recettes dans un article dédié. L'idée : payer le coût une fois (à l'upload, au build, à l'enregistrement) et servir vite ensuite.
Sur un hébergement modeste, cette discipline fait la différence entre une page nerveuse et une page qui rame.
Pourquoi cet assemblage tient ensemble
Ce qui rend cette stack cohérente, ce n'est pas la liste des outils — c'est leur philosophie commune. Tous sont légers, explicites, tournés vers le serveur. Aucun n'impose une cathédrale d'abstractions. On peut lire toute la chaîne, d'un attribut HTMX jusqu'à une requête SQL.
| Couche | Techno | Rôle |
|---|---|---|
| Langage | PHP 8.2+ | le socle d'exécution |
| Framework | CodeIgniter 4 | routing, modèles, sécurité (Shield) |
| Base de données | MariaDB | persistance relationnelle |
| Cache / files | Redis | cache, sessions, queue |
| Templates | BladeOne | rendu HTML serveur + fragments |
| Hypermedia | HTMX v2 | fragments interactifs, sans SPA |
| Micro-interactif | Alpine.js | état local léger |
| Style | Tailwind CSS | utility-first + direction artistique |
| Build | Vite | bundling, HMR, assets versionnés |
| Médias | ImageProcessor (WebP/AVIF) | optimisation des images |
| Hébergement | OVH / Plesk | production |
Comparez avec une stack SPA classique (front en framework JS + API + gestion d'état + build complexe) : deux applications à maintenir, deux fois la logique métier, un état à synchroniser entre les deux. Ici, une seule application, une seule source de vérité. Moins de pièces mobiles, moins de pannes.
Ce n'est pas le bon choix pour tout — une app très stateful côté client justifie encore un framework JS. Mais pour l'immense majorité des sites et back-offices qu'on construit, c'est l'équilibre idéal.
Comprendre toute la chaîne
Une stack cohérente, c'est une stack qu'on comprend en entier, qu'on maintient sans crise, et qu'on fait évoluer brique par brique. C'est moins spectaculaire qu'une démo SPA flashy — mais ça tient des années, et c'est exactement ce qu'on vend à nos clients : de la durée.
La meilleure stack n'est pas la plus impressionnante : c'est celle qu'on comprend de bout en bout.