Pourquoi je développe (presque) tout en HTML, CSS et JavaScript
Quand je parle de mes projets — calculateurs pour FabLab, outils de gestion, même un jeu RPG en cours de développement — la première question est souvent : « Quel framework tu utilises ? ». Ma réponse déroute : aucun. Juste HTML, CSS et JavaScript. Pas de build step, pas de dépendances npm à rallonge, pas de base de données à configurer. Trois fichiers (ou plus ;) ), un navigateur, et ça tourne.
Ce n'est ni du purisme technologique ni de la nostalgie pour les débuts du web. C'est un choix réfléchi, cohérent avec ma pratique de facilitateur FabLab et formateur. Voici pourquoi.
L'autonomie avant tout
Dans un FabLab, on prône la réappropriation des outils de production. On apprend à réparer, modifier, comprendre ce qu'on utilise. Pourquoi accepterais-je une dépendance totale à un écosystème logiciel qui peut disparaître du jour au lendemain ?
Avec HTML/CSS/JS, je contrôle l'intégralité de la chaîne. Pas de framework qui impose ses conventions, pas de version majeure qui casse tout, pas de CLI mystérieux qui télécharge 300 Mo de node_modules. Le code que j'écris aujourd'hui tournera dans dix ans sans mise à jour forcée.
Cette autonomie, c'est aussi celle que j'offre aux utilisateurs de mes outils : pas de compte à créer, pas de serveur à maintenir, pas d'abonnement caché. Tu télécharges, tu décompresses, tu lances. Point.
La pédagogie par la transparence
Quand un étudiant me demande « Comment ça marche ? », je peux lui montrer le code source immédiatement. Pas de transpilation (processus de conversion du code source d'un langage de programmation en un code source équivalent dans un autre langage ou une version différente du même langage, sans passer par un langage de bas niveau comme le code machine), pas de compilation, pas de magie noire. Clic droit → Inspecter, et tout est là : la structure HTML, les styles CSS, la logique JavaScript.
C'est cette transparence qui permet d'apprendre en bidouillant. Tu veux changer une couleur ? Modifie le CSS. Tu veux ajouter un bouton ? Ajoute une balise et un event listener. Chaque action a une conséquence visible, directe, compréhensible.
Dans mes formations, cette approche est libératrice. Les gens ne sont pas intimidés par une stack complexe : ils voient du texte, ils modifient du texte, ils comprennent. La courbe d'apprentissage est douce, progressive, humaine.
Zéro base de données = zéro friction
Un de mes principes : éviter systématiquement les bases de données pour les applications simples. Pourquoi ? Parce qu'une BDD introduit une barrière technique énorme.
Installer MySQL ou PostgreSQL, configurer un serveur, gérer les migrations, sécuriser les accès... C'est un projet dans le projet. Et surtout, ça tue la portabilité : impossible de simplement « envoyer l'app » à quelqu'un.
D'ailleurs, ce blog lui-même est en PHP... sans base de données. Les articles sont des fichiers Markdown stockés sur le serveur, point. Pas de tables, pas de requêtes SQL, pas de cache à purger. Simple, maintenable, résilient.
Mon alternative : localStorage + JSON. Pour le jeu RPG que je développe actuellement, toute la progression du joueur, l'inventaire, les quêtes sont stockés localement dans le navigateur. Besoin de sauvegarder ? Un bouton exporte tout en fichier JSON téléchargeable. Besoin de charger ? Un simple input file.
Cette approche a ses limites (pas de collaboration temps réel, stockage local fini), mais pour 90 % des outils que je crée — calculateurs de coût d'impression 3D, estimateurs de temps laser, gestionnaires de devis —, c'est largement suffisant. Et surtout, ça reste simple à partager : un zip contenant index.html, style.css et app.js, et n'importe qui peut l'utiliser sans installer quoi que ce soit.
La légèreté comme principe
Mes applications pèsent quelques dizaines de kilo-octets. Elles se chargent instantanément, même sur une connexion pourrie. Elles tournent offline dès la première visite. Elles ne consomment presque rien en CPU ou en RAM.
Cette légèreté n'est pas qu'une question de performance. C'est aussi une question d'accessibilité. Pas besoin d'un ordinateur dernier cri, pas besoin d'une connexion fibre. Un vieux laptop, un smartphone d'entrée de gamme, une tablette récupérée : ça suffit.
Dans le contexte d'un FabLab ouvert à tous, cette inclusivité technique n'est pas anecdotique. Elle garantit que personne n'est exclu par des prérequis matériels artificiels.
Et puis, franchement, il y a quelque chose de profondément satisfaisant à livrer une application complète, fonctionnelle, sans avoir passé une heure à attendre que npm install finisse de télécharger la moitié d'internet.
La résilience du trio magique
HTML5 a été finalisé en 2014. CSS3 est mature depuis plus d'une décennie. JavaScript s'est stabilisé depuis 2015. Ces technologies ont atteint un plateau de maturité.
Contrairement aux frameworks Java qui se succèdent à un rythme épuisant (Angular, React, Vue, Svelte, et le prochain sera là dans six mois), le trio HTML/CSS/JS est pérenne. Les sites créés il y a quinze ans tournent encore. Ceux que je crée aujourd'hui tourneront dans vingt ans.
Cette résilience n'est pas théorique. Elle est garantie par le fonctionnement même du web : la rétrocompatibilité est un principe sacré. Les navigateurs ne casseront jamais intentionnellement du HTML valide. Ton code ne deviendra pas obsolète parce qu'une équipe de développeurs a décidé de pivoter vers une nouvelle architecture.
C'est une forme de souveraineté numérique : je ne dépends d'aucune entreprise, d'aucun écosystème privé, d'aucune mode passagère. Le web ouvert est ma plateforme, et elle ne disparaîtra pas.
Le partage sans friction
Tous mes projets sont sur GitLab. Calculateurs pour l'impression 3D, outils d'estimation laser, gestionnaires de devis... Chacun est téléchargeable, modifiable, réutilisable.
Pas besoin de lire un README de trois pages pour comprendre comment installer les dépendances. Pas de docker-compose up ni de configuration d'environnement. Tu ouvres index.html dans un navigateur, et ça marche.
Cette friction zéro change tout pour le partage. Un collègue formateur veut adapter mon calculateur de filament ? Il copie-colle le dossier, modifie deux lignes de JavaScript, et c'est bon. Un étudiant veut comprendre comment fonctionne l'interface ? Il lit le HTML. Pas de barrière à l'entrée.
C'est exactement l'esprit FabLab appliqué au développement : documentation ouverte, réplication facile, modification encouragée.
Les limites, je les connais
Je ne suis pas naïf. HTML/CSS/JS a ses limites. Pour une application collaborative temps réel avec des milliers d'utilisateurs concurrents, il faudra un backend solide. Pour une interface ultra-complexe avec des centaines de composants, un framework apportera de la structure.
Mais combien de mes projets nécessitent réellement ça ? Très peu. La plupart sont des outils métier, des interfaces de calcul, des tableaux de bord pour des usages locaux ou en petit groupe.
Pour ces cas — qui représentent 90 % de mes besoins —, le trio magique est non seulement suffisant, mais supérieur en termes de simplicité, maintenabilité, partageabilité.
Et quand j'ai vraiment besoin de plus ? Je choisis des outils légers et standards : un peu de PHP côté serveur (comme pour ce blog), des fichiers JSON pour la persistance, du SQLite si une vraie base devient indispensable. Jamais de monolithe, jamais de dépendance lourde.
Un choix assumé, pas un compromis
Développer en HTML/CSS/JS n'est pas un choix par défaut, faute de mieux. C'est un choix délibéré, aligné avec mes valeurs de facilitateur et de formateur.
Autonomie, transparence, légèreté, résilience, partage : ces mots ne sont pas que des "buzzwords". Ils décrivent concrètement ce que j'obtiens en refusant la complexité gratuite.
Alors oui, je continuerai à créer des applications « à l'ancienne ». Parce qu'elles marchent. Parce qu'elles durent. Parce qu'elles s'apprennent. Et parce qu'au final, c'est exactement ça, l'esprit maker : comprendre, maîtriser, transmettre.
Si tu veux jeter un œil à mes projets, tout est sur GitLab. N'hésite pas à forker, modifier, réutiliser. C'est fait pour ça.
