En 2014, HTML 5 est devenu un standard officiel du W3C, tout comme son pendant pour l’affichage des données : CSS 3. En parallèle de l’émergence de ce Web moderne, sont arrivés les frameworks modernes (Angular en 2010, React en 2013, Vue en 2014, etc.). Ces derniers étaient nécessaires pour combler un certain nombre de besoins qui n’étaient pas couverts à l’époque par le triptyque HTML – CSS – Vanilla JS dans les navigateurs.

Le paradoxe de cette histoire, c’est que le développement de ces frameworks s’est fait en parallèle de l’évolution des standards du Web. Car depuis 2014, HTML, CSS et les API JS associées évoluent en permanence, non pas de manière monolithique, mais par modules. Et malgré le nombre et la fréquence de ces nouveautés, leur support est de plus en plus rapide dans nos navigateurs web.

Et c’est là que je m’insurge, que je m’outre, ou que j’utilise un autre verbe datant du Moyen Âge pour rester poli. Nous sommes en 2026, le navigateur est devenu une véritable machine de guerre. Nous installons de moins en moins de logiciels pour utiliser des applications web tout aussi performants. Le navigateur est même devenu la plateforme principale du Web mobile et de facto est un sujet de souveraineté ou de conquête. En effet, toutes les firmes d’IA veulent le leur : Perplexity AI avec Comet, OpenAI avec ChatGPT Atlas. Pourtant l’industrie du Web continue de court-circuiter les fonctionnalités natives du navigateur et les standards du Web avec scripts JavaScript inutiles. Voici ce que ça vous coûte, et comment l’arrêter.

Douze ans de progrès que vos projets ignorent

Entre 2014 et 2026, le navigateur a résolu la quasi-totalité des problèmes pour lesquels les frameworks JS avaient été créés. Côté JavaScript natif d’abord, côté CSS ensuite. L’écart entre ce que le navigateur sait faire et ce que l’industrie lui demande de faire n’a jamais été aussi grand.

Combien de ces fonctions votre projet réimplémente-t-il ?

Frameworks JS vs standards natifs : deux évolutions parallèles. © artwaï

Voici une liste des fonctionnalités que les frameworks JS réimplémentent alors que le navigateur les gère nativement :

• Routing / Navigation. Le navigateur gère nativement l’historique de navigation avec l’API History (pushState, popState), les boutons précédent/suivant, les ancres, les URLs. React Router, Vue Router, Angular Router réécrivent tout cela par-dessus, en ajoutant des couches de complexité pour reproduire ce que le navigateur fait depuis toujours.
• Fetch / Requêtes HTTP. L’API fetch est native depuis 2015 dans tous les navigateurs, capable de gérer nativement les requêtes JSON sans bibliothèque tierce. Axios, jQuery Ajax, et des dizaines de bibliothèques similaires existent uniquement pour envelopper ce que le navigateur fait déjà nativement.
• Gestion de l’état du formulaire. Le navigateur mémorise nativement l’état des formulaires, l’autocomplétion, la restauration après navigation. React Hook Form, Formik et consorts réinventent cette gestion d’état from scratch.
• Observateurs d’intersection et de mutation. IntersectionObserver et MutationObserver sont natifs. Pourtant des bibliothèques entières existent pour détecter quand un élément entre dans le viewport, cas classique du lazy loading ou des animations au scroll.
• Gestion des événements. Le système d’événements natif du DOM (addEventListener, CustomEvent, dispatchEvent) est complet et puissant. Les frameworks abstraient intégralement ce mécanisme avec leurs propres systèmes de binding et d’événements synthétiques pour gérer les interfaces utilisateur. React a même son propre système d’événements synthétiques qui émule ce que le navigateur fait déjà.
• Stockage local. localStorage, sessionStorage, IndexedDB sont natifs. Des bibliothèques comme Dexie.js ou des stores Redux persistés réinventent des couches par-dessus.
• Web Components / Custom Elements. Le navigateur supporte nativement les Web Components depuis 2018 : des composants encapsulés, réutilisables, sans dépendance. React, Vue et Angular réimplémentent ce concept de composants dans leur propre écosystème fermé, incompatible entre eux.
• Géolocalisation, notifications, clipboard. APIs natives complètes, systématiquement réenveloppées dans des bibliothèques tierces « plus simples ».
• Animations via Web Animations API. L’API animate() native permet de piloter des animations complexes, qu’elles soient CSS, SVG ou JavaScript, de façon performante. GSAP, Anime.js et consorts existent en grande partie pour combler un manque qui n’existe plus depuis 2016.
• Lazy loading des images et iframes. L’attribut loading=”lazy” est natif depuis 2019. Des bibliothèques de lazy loading JS continuent d’être installées sur des milliers de projets.

Mais cela ne s’arrête pas là…

L’incroyable évolution du CSS depuis 2014

Car depuis 2014, le CSS a résolu un certain nombre de problèmes pour lesquels l’industrie maintenait une dépendance JavaScript. En voici une liste non exhaustive :

• Custom Properties / Variables CSS (2015). Des variables natives dans le navigateur, sans préprocesseur. Contrairement aux variables Sass, elles sont dynamiques : elles réagissent au DOM en temps réel. Massivement sous-exploitées ; beaucoup de projets maintiennent Sass uniquement pour les variables, sans savoir que CSS les gère nativement depuis dix ans.
• CSS Grid (2017). La vraie révolution de mise en page. Des grilles en deux dimensions, natives, sans framework. Universellement supporté depuis 2017 et encore massivement sous-utilisé au profit de Bootstrap ou de grids JS. C’est probablement l’avancée CSS la plus puissante de la décennie, et la plus ignorée.
• position: sticky (2017). Un élément qui reste fixe dans son conteneur au scroll, sans une ligne de JavaScript. Pourtant des bibliothèques JS de « sticky header » continuent d’être installées quotidiennement.
• Scroll Behavior smooth (2017). scroll-behavior: smooth : le défilement doux vers une ancre en une ligne de CSS. Des plugins jQuery de smooth scroll existent encore sur des milliers de projets.
• aspect-ratio (2021). Maintenir un ratio sans padding hack. Le fameux hack du padding-top: 56.25% pour les vidéos 16:9 est enfin mort, mais beaucoup de projets ne le savent pas encore.
• clamp() (2020). Typographie et sizing fluides et responsives en une seule fonction, sans media query. font-size: clamp(1rem, 2.5vw, 2rem) : une ligne qui remplace des dizaines de lignes de media queries. Quasi inconnu des équipes qui n’ont pas suivi l’évolution du CSS.
• Container Queries (2022). La plus grande demande de la communauté CSS pendant dix ans. Un composant qui s’adapte à la taille de son conteneur plutôt qu’à celle du viewport. Cela change radicalement l’architecture des composants réutilisables et rend caduques des dizaines de bibliothèques de composants JS censées gérer le responsive design. Encore très peu utilisé.
• :has() — le sélecteur parent (2023). Après 25 ans d’attente, CSS peut enfin cibler un élément en fonction de ses enfants. form:has(input:invalid) pour styler un formulaire en erreur, sans JavaScript. L’une des avancées les plus puissantes de CSS, et l’une des moins enseignées.
• CSS Nesting natif (2023). La syntaxe imbriquée que tout le monde faisait avec Sass, maintenant native dans le navigateur. La principale raison d’utiliser Sass disparaît.
• @layer – Cascade Layers (2022). Un contrôle fin de la cascade CSS, sans guerre de spécificité ni !important en pagaille. Révolutionnaire pour les grandes bases de code. Méconnu même des développeurs seniors.

Dix fonctionnalités JS natives. Dix avancées CSS. 20 raisons de désinstaller une bibliothèque.

Comment je le constate, et pourquoi ça m’énerve

Depuis 25 ans, je fais du front-end. Depuis 2005, je dirige une agence web. Et depuis que j’ai conçu l’outil d’analyse de web performance MilleCheck.ai, je consulte chaque jour des rapports d’analyse sur des centaines d’URLs différentes.

Ce que je vois ne me réjouit pas.

Des sites d’entreprises sérieuses, portés par des équipes compétentes, qui embarquent React ou Angular pour afficher trois pages web de contenu éditorial et un formulaire de contact. Des projets WordPress ou autres CMS qui chargent Vue.js en plus du thème pour gérer un menu déroulant. Des refontes livrées avec fierté par chaque designer et développeur, et des scores de performance qui feraient rougir un développeur de 2005.

Ce n’est pas une question de mauvaise volonté. C’est une question de culture et de formation.

Quand je passe une URL dans MilleCheck, l’outil ne ment pas. Il ne teste pas dans les conditions idéales d’un MacBook Pro sur fibre, en desktop. Il mesure ce que vit réellement l’utilisateur médian : celui qui consulte votre site sur le web mobile, depuis des terminaux variés comme sur un smartphone de milieu de gamme, avec une connexion 4G moyenne, dans le train ou dans une salle d’attente. Et ce que j’y vois régulièrement, c’est le même pattern : des mégaoctets de JavaScript pour des fonctionnalités que le navigateur aurait gérées nativement en quelques lignes de code HTML et CSS.

Ce qui m’énerve, ce n’est pas JavaScript. JavaScript est un outil formidable quand il est utilisé à bon escient. Ce qui m’énerve, c’est le réflexe. Ce réflexe pavlovien qui fait qu’à la moindre interaction, à la moindre mise en page un peu complexe, le premier mouvement est d’installer une bibliothèque. Sans se poser la question de savoir si c’est nécessaire. Sans savoir ce que le navigateur sait déjà faire.

Moi, je le vois dans les données. Chaque jour.

Comment en est-on arrivé là ?

Les frameworks modernes ont résolu de vrais problèmes. En 2010-2013, quand Angular puis React arrivent, les navigateurs sont effectivement limités et fragmentés. Internet Explorer règne encore. Les APIs natives sont pauvres. JavaScript est le seul moyen de combler les lacunes. Les frameworks sont une réponse légitime à un contexte réel.

Le problème, c’est que le contexte a changé, mais pas les habitudes.

Depuis 2014, le web natif n’a cessé de s’enrichir. CSS Grid en 2017, les Custom Properties, l’API Fetch, IntersectionObserver, les Web Components, Container Queries, :has()… Le navigateur et son moteur de rendu sont devenus une plateforme d’une puissance considérable. Mais pendant que les standards web natifs progressaient discrètement, les frameworks, eux, faisaient du bruit. Des conférences, des stars GitHub, des offres d’emploi par milliers. L’écosystème JavaScript est devenu une industrie, avec ses certifications, ses extensions, ses influenceurs, ses entreprises dont le modèle économique repose sur la complexité qu’ils génèrent.

Résultat : une formation initiale au développement web, qu’elle soit front-end ou full stack, qui enseigne React avant d’enseigner le DOM. Des recruteurs qui listent Angular et Vue avant même les langages fondamentaux du web dans les prérequis d’un poste junior. Des appels d’offres qui spécifient le framework avant même de définir le besoin. La question n’est plus « de quoi ce projet a-t-il besoin ? » mais « avec quel framework allons-nous le construire ? »

Et quelque part dans cette dérive, on a opéré un glissement silencieux mais fondamental : on a optimisé le web pour celui qui le construit, pas pour celui qui l’utilise. Le framework qui plaît au développeur, sa syntaxe élégante, son écosystème riche, sa courbe d’apprentissage valorisante, est devenu le critère de choix principal. L’expérience de l’utilisateur final, elle, est passée au second plan.

On a sacrifié le user-friendly sur l’autel du developer-friendly. Un composant bien architecturé dans le code peut très bien se traduire par trois secondes de chargement supplémentaires sur le téléphone de l’utilisateur. Personne dans la réunion de sprint ne le voit. L’utilisateur, lui, n’aura pas la patience d’attendre.

C’est ce que Jeffrey Zeldman appelait dès 2018 le « culte de la complexité » : la tendance de notre industrie à confondre sophistication technique et valeur réelle. À préférer l’outil impressionnant à l’outil juste. À mesurer la qualité d’un projet au nombre de ses dépendances plutôt qu’à l’expérience qu’il délivre.

Vingt-cinq ans de métier m’ont appris une chose : la complexité est rarement le signe d’une maîtrise. C’est souvent le signe de son absence. Identifier un framework JS inutile devient alors une réelle compétence.

Pourquoi cela coûte cher à votre entreprise et à votre performance web ?

Le coût de la dépendance

Chaque bibliothèque JS qui réimplémente une fonction native est une dépendance à maintenir dans le temps. Elle a des versions, des failles, des incompatibilités.

Et qui sait quel mal se cache dans le code de quelqu’un d’autre ?

L’attaque supply chain sur Axios en mars 2026, 100 millions de téléchargements hebdomadaires compromis pendant 3 heures par un seul compte hacké, est l’illustration parfaite : vous payez un risque de sécurité permanent pour une fonctionnalité que le navigateur offre gratuitement et nativement depuis 2015.

Coût réel d’une dépendance JavaScript. © artwaï

Le coût caché de l’obsolescence programmée

Un projet construit sur un framework JS a une date de péremption : celle du jour où le framework sera abandonné, remplacé, ou trop coûteux à migrer.

• AngularJS en est l’exemple le plus brutal. Angular a été réécrit de zéro en 2016. Résultat : des centaines de milliers de projets à migrer de force, à partir de zéro, pour des sites qui auraient pu continuer à fonctionner sans rien changer.
• React a changé de paradigme fondamental au moins deux fois en dix ans : des class components aux Hooks en 2019, puis vers les Server Components en 2023. Chaque transition a représenté des projets à migrer, des équipes à reformer, des heures facturées.

Les standards du web, eux, ne cassent jamais la compatibilité ascendante. Ce que vous avez appris en HTML et CSS en 2015 fonctionne encore parfaitement en 2026. Un projet construit sur des standards web natifs a une durée de vie quasi illimitée.

Le coût de la lenteur

C’est le plus mesurable et le plus direct, notamment sur les Core Web Vitals de Google. Chaque kilooctet de JavaScript inutile est du temps de chargement en plus et du trafic en moins. Alex Russell a documenté le cas d’un site qui perdait du trafic mobile de façon corrélée à l’ajout de 100 Ko de JS par mois pendant six mois. La dette technique de web performance ne génère pas d’alerte dans votre backlog. Elle se manifeste dans vos analytics silencieusement, progressivement.

Ci-dessus, exemple d’un rapport MilleCheck nous montre (en bleu) l’impact WebPerf de l’infrastructure d’un site Next.js presque 48 %. © Artwaï

En comparaison ci-dessus, le même site après refonte avec une architecture plus simple et moderne, on passe à 6 %. © artwaï

Le coût de la complexité ingérable

Jono Alderson le formule brutalement : « Il faut désormais quatre ingénieurs, trois frameworks et un pipeline CI/CD rien que pour modifier un titre. » Ce n’est pas de la provocation (à peine) : c’est une réalité que vivent vos équipes. La complexité accumulée ralentit tout : les nouvelles recrues mettent plus de temps à monter en compétence, les corrections de bugs prennent plus longtemps, les nouvelles fonctionnalités coûtent plus cher à chaque sprint.

Les bonnes questions à se poser

Votre nouveau projet a-t-il besoin d’un framework JS ?

La question devrait être systématique. Elle ne l’est presque jamais.

Avant de vous demander quel framework Javascript choisir, posez-vous trois questions simples. Est-ce que l’application web gère un état complexe qui évolue en temps réel, tableau de bord, interface de messagerie, éditeur collaboratif ? Est-ce que les interactions entre composants sont nombreuses et interdépendantes ? Est-ce que l’équipe va maintenir ce projet sur le long terme avec des ressources dédiées ?

Si vous répondez oui aux trois : un framework JS se justifie probablement.

Si vous hésitez sur l’une d’elles : la réponse est non.

Un site vitrine, un blog, un portail de contenu éditorial, un site e-commerce standard, une landing page responsive web : ces cas représentent l’écrasante majorité des projets web produits chaque année. Aucun n’a besoin d’un framework JS pour exister, performer et durer. Alex Russell le démontre avec une brutalité désarmante : en croisant les données statistiques de navigation, il établit que le nombre moyen de navigations « profondes » dans une SPA, celles qui justifient le chargement initial lourd, est en moyenne égal à un. Soit exactement zéro bénéfice pour un coût considérable.

La bonne architecture est celle qui répond au besoin réel, pas celle qui impressionne en réunion de lancement.

Votre projet actuel doit-il se passer de son framework JS ?

Là, la question est différente, et plus délicate.

Il ne s’agit pas de tout réécrire du jour au lendemain. Une migration complète peut coûter plus cher que le problème qu’elle résout, et introduire de nouveaux risques. Ce n’est pas le conseil que je donne.

Ce que je conseille, c’est d’abord de mesurer. Pas dans les conditions de votre poste de développement : dans les conditions réelles de vos utilisateurs. Quelle est la part de JavaScript que votre projet embarque inutilement ? Quelles bibliothèques réimplémentent des fonctionnalités natives ? Quelle est votre dette de performance aujourd’hui, concrètement, sur un appareil médian ?

C’est exactement ce que MilleCheck.ai permet de faire en quelques minutes. Pas pour vous donner une note à encadrer, pour vous donner une réalité à affronter.

Ensuite, les décisions s’imposent d’elles-mêmes. Certaines dépendances tombent en quelques lignes. Certains composants JS se remplacent par du CSS natif sans toucher à l’architecture globale. Ce sont des victoires rapides, mesurables, qui réduisent le poids, améliorent les métriques, et commencent à rembourser la dette silencieuse.

La question n’est pas « faut-il tout changer ? » La question est : « Savez-vous où vous en êtes ? »

Votre IA code-t-elle avec les standards du Web ou contre eux ?

C’est la question que personne ne pose encore, et qui va devenir centrale dans les prochaines années.

Les outils d’IA générative, GitHub Copilot, Cursor, Claude, ChatGPT, sont devenus en quelques mois des membres à part entière des équipes de développement. Leur promesse est réelle : ils accélèrent, ils débloquent, ils suggèrent. Mais ils ont un biais structurel que peu de décideurs ont mesuré.

Une IA générative est un outil statistique. Elle produit la réponse la plus probable en fonction des données sur lesquelles elle a été entraînée. Or, l’état du Web tel qu’il existe dans ces données d’entraînement reflète exactement le problème décrit dans cet article : une majorité de code basé sur des frameworks JS, peu de code exploitant les standards natifs récents. Demandez à n’importe quelle IA de coder un composant d’onglets pour Chrome ou tout autre navigateur : elle vous proposera une solution React ou Vue avant de vous proposer une solution en HTML et CSS natifs.

Le résultat est pervers : l’IA amplifie les mauvaises habitudes au lieu de les corriger. Elle installe le réflexe framework chez des développeurs juniors qui n’ont jamais eu l’occasion d’apprendre autrement. Et elle le fait à une vitesse et une échelle qu’aucun formateur, aucun pair, aucun code review ne peut contrebalancer.

Ce n’est pas la faute de l’IA. C’est la faute du corpus. Et le corpus, c’est nous qui l’avons écrit.

La solution n’est pas de rejeter ces outils, ils sont trop utiles pour ça. C’est d’apprendre à les briefer correctement. Un prompt précis, qui spécifie explicitement « sans framework JS », « en HTML natif », « avec les APIs navigateur », change radicalement le code produit. Mais pour formuler ce prompt, encore faut-il savoir que ces alternatives existent. Ce qui nous ramène, une fois de plus, à la même conclusion : c’est une question de culture et de formation.

NB : Même Google s’intéresse au sujet et propose un outil qui s’intègre à vos agents pour « développer avec les conseils sur le Web moderne ».

2026 : le navigateur attend toujours

En 1999, Jeffrey Zeldman se battait pour que les développeurs utilisent HTML correctement, pour qu’ils arrêtent de contourner le navigateur avec des tableaux de mise en page et des tags font obsolètes. Vingt-cinq ans plus tard, le combat est le même. Les outils ont changé, le réflexe non.

À chaque génération, l’industrie web invente de nouvelles façons de ne pas faire confiance au navigateur. Et à chaque génération, le navigateur finit par avoir eu raison.

Nous sommes en 2026. Le web natif n’a jamais été aussi puissant, aussi responsive. Les standards n’ont jamais été aussi bien supportés. Et la preuve la plus éloquente : depuis 2022, Apple, Google, Microsoft et Mozilla, des concurrents pourtant acharnés, collaborent chaque année dans le cadre du projet Interop pour s’assurer que les standards web sont implémentés de façon cohérente dans tous les navigateurs. En 2026, ce projet en est à sa cinquième édition consécutive, avec vingt domaines d’intervention prioritaires. Même les géants de la tech ont décidé de faire confiance aux standards. L’industrie du Web, elle, installe encore des bibliothèques pour faire du smooth scroll.

Et pourtant, la majorité des projets continue de tourner le dos à tout ce travail pour empiler des couches de JavaScript qui reproduisent, moins bien, ce qui existe déjà.

Ce n’est pas une fatalité. C’est une habitude. Et les habitudes, ça se change. Pas en réécrivant tout du jour au lendemain, pas en bannissant les frameworks par décret, mais en posant pour chaque projet, pour chaque dépendance, pour chaque npm install, la question que l’industrie a collectivement arrêté de poser : est-ce vraiment nécessaire ?

Si vous ne savez pas y répondre pour votre projet actuel, commencez par mesurer. Une URL, quelques minutes, et MilleCheck.ai vous dira ce que vos utilisateurs vivent réellement.

Le navigateur attend votre confiance. Vos utilisateurs attendent surtout que ça charge.