Les articles sur HTMX se divisent en deux camps : « la fin des SPA » et « un jouet ». Les retours de production, eux, sont rares. En voici un.
TL;DR : mon cockpit de prospection tourne en production avec HTMX, Go,
html/template, Postgres et Redis. Ce qui a tenu : un endpoint par fragment, des templates éclatés par composant, Redis en cache optionnel. Ce que j'ai retiré : le push SSE, qui gelait la page en HTTP/1.1. Et htmx 4.0 vient de sortir, ce qui dit quelque chose sur la maturité de l'approche.
Cet article est pour les devs backend qui veulent une vraie interface sans embarquer un framework front complet.
Le contexte
Le cockpit est mon outil de prospection freelance. Suivi des conversations, veille, analyse de leads. Je l'utilise tous les jours, il tourne en production chez moi.
La stack est courte. Go avec net/http. Des templates html/template. HTMX côté navigateur. Postgres pour les données, Redis en cache.
HTMX est une petite bibliothèque JavaScript. Elle lit des attributs HTML et remplace des morceaux de page par du HTML renvoyé par le serveur. Pas de build front, pas de npm, pas d'état côté client.
Le pari : toute la logique reste en Go, le navigateur ne fait qu'afficher.
La règle qui a émergé : un endpoint, un fragment
Au début, mes templates étaient des monolithes. Le template de base pesait 102 Ko. Deux pages dépassaient 70 Ko chacune.
Ça marche, mais plus personne n'ose y toucher. Le refactor a imposé une règle simple : un endpoint HTMX renvoie un fragment, et chaque fragment vit dans son fichier.
Un dossier fragments/ dédié. Des pages éclatées par composant. Le CSS de base est passé de 1256 lignes à 192, avec un fichier par page inclus automatiquement.
html/template tient très bien la charge, à une condition : le découper comme tu découperais ton code.
Ce que j'ai retiré : le push SSE
J'avais construit du temps réel. Un canal pub/sub dans Redis, un endpoint d'événements, un toast dans la page quand une analyse se terminait. Sur le papier, élégant.
En pratique, la page affichait un chargement sans fin. Un flux SSE est une requête HTTP qui ne se termine jamais. En HTTP/1.1, ce flux permanent occupe un des rares slots de connexion du navigateur vers ton origine.
J'ai déjà raconté cette famille de pièges dans mon article sur les timeouts Go et le SSE. Cette fois, c'était chez moi.
La vraie question n'était pas « comment réparer ». C'était « qui a besoin de ce temps réel ». Réponse honnête : personne. Un rafraîchissement HTMX au clic donne la même information.
Le SSE est parti en un commit. Le temps réel est un coût permanent, pas un cadeau. Paye-le seulement quand le besoin existe.
Ce que j'ai gardé côté serveur
Redis est resté, mais en cache seulement. Les embeddings du matching sont mis en cache avec un TTL. Pareil pour les données de compte les plus relues.
Le point important : tout est optionnel. L'adapter Redis est nil-safe, le cockpit démarre et fonctionne sans Redis, juste plus lentement. Une dépendance optionnelle est une panne en moins.
La file de jobs, elle, est restée dans Postgres. Durable, transactionnelle, déjà là. Le duo Postgres pour l'état, Redis pour l'accélération, couvre tout ce dont une app comme ça a besoin.
htmx 4.0 vient de sortir, et ça compte
Le 28 août 2026, htmx 4.0 est sorti. Le moteur passe de XMLHttpRequest à fetch, l'API moderne du navigateur pour les requêtes. Le projet a sauté la version 3, comme annoncé.
Ce que j'en retiens n'est pas la nouveauté technique. C'est le signal : l'approche hypermedia est entretenue, financée, et pensée pour durer.
Je n'ai pas encore migré. Mon usage est volontairement simple, des attributs de base et des fragments. La migration attendra un créneau calme, et c'est exactement ce que je veux d'une dépendance front.
À qui je recommande ce stack, et à qui non
Fonce si tu es un petit effectif backend, avec un outil interne, un back-office ou une app CRUD. Le gain est énorme : une seule base de code, un seul déploiement, zéro pipeline front.
Réfléchis à deux fois si ton produit vit d'interactions riches côté client. Édition collaborative, offline, animations complexes : là, un framework front se justifie.
Et si tu as déjà une équipe front qui maîtrise son framework, HTMX n'est pas un progrès. C'est un autre compromis.
La checklist si tu tentes HTMX
Les règles que j'appliquerais dès le premier jour, dans l'ordre.
- Un endpoint HTMX renvoie un fragment, et chaque fragment vit dans son fichier
- Éclate tes templates par composant avant qu'ils ne pèsent 100 Ko
- Extrais le CSS par page, chargé automatiquement par convention
- N'ajoute pas de temps réel sans besoin réel : un refresh au clic suffit souvent
- Si tu fais du SSE, lis d'abord comment il se comporte en HTTP/1.1
- Rends tes dépendances optionnelles : l'app doit démarrer sans le cache
- Garde l'état durable dans Postgres, le cache dans Redis, pas l'inverse
Ce qu'il faut retenir
HTMX en production, c'est surtout de la discipline de templates et des choix serveur assumés. La bibliothèque, elle, se fait oublier.
Mon bilan après des mois d'usage quotidien : je garde le stack, j'ai retiré le superflu, et htmx 4 me conforte.
Tu veux une interface solide sans usine front, ou un avis sur ton stack web Go ? Parlons-en.