Vanilla web en 2026 : comprendre la plateforme avant d’empiler les frameworks

Quand on parle de développement web en 2026, les premiers mots qui viennent sont souvent React, Vue, Angular, framework, stack, build, composants, ou désormais IA générative. À force d’empiler les outils, on pourrait presque oublier une évidence : avant tout cela, il y a le navigateur, les standards du web, et cette plateforme native que l’on appelle souvent le vanilla web.

Dans cet article, l’objectif n’est pas d’opposer frontalement frameworks et développement natif, mais de prendre un temps de recul : comprendre ce que recouvre réellement le vanilla web aujourd’hui, mesurer ce que la plateforme permet déjà sans surcouche, et identifier dans quels cas il reste pertinent, voire préférable, de s’appuyer directement sur ces fondations.

Pour comprendre cela, regardons d’abord qui publie réellement sur le web, quels sont les besoins les plus courants, et avec quelles solutions ces besoins sont aujourd’hui couverts. À partir de cette réalité, il sera alors possible de situer plus précisément la place du vanilla web en 2026, sans présupposer de sa pertinence ni de ses limites.

Qui publie réellement sur le web ?

Lorsque l’on parle du web, on pense souvent aux grands sites, aux plateformes, aux médias, aux réseaux sociaux ou aux applications en ligne les plus visibles. Pourtant, le web est aussi alimenté par une multitude d’acteurs beaucoup plus ordinaires : entreprises locales, indépendants, collectivités, associations, établissements de formation, artisans, commerçants, professions libérales, clubs, projets personnels ou collectifs. Autrement dit, le web n’est pas seulement l’affaire des grands comptes ou d’équipes techniques structurées. Il est aussi un espace de présence, de publication et de service pour des organisations qui n’ont ni les moyens, ni toujours le besoin, de construire une application complexe.

Comme le montre l’Insee dans son étude sur le tissu productif français par catégorie d’entreprises en 2023, la France comptait en 2023 5,2 millions d’entreprises dans les secteurs marchands non agricoles et non financiers. Parmi elles, près de 5 millions étaient des microentreprises, contre environ 175 000 PME hors microentreprises, 7 442 entreprises de taille intermédiaire et seulement 333 grandes entreprises.

En volume, la très grande majorité des acteurs susceptibles d’avoir besoin d’un site, d’une page, d’un formulaire, d’un catalogue ou d’un espace de contact relève donc de petites structures, même si la valeur ajoutée et l’emploi restent davantage concentrés dans les ETI et les grandes entreprises.

Ce périmètre exclut toutefois l’agriculture, alors même que les exploitations agricoles ont elles aussi des besoins croissants de présence en ligne, notamment avec le développement des circuits courts, de la vente directe et de la relation locale entre producteurs et consommateurs. L’enquête sur le structure des exploitations agricoles 2023 d’Agreste comptabilise ainsi 349 600 exploitations agricoles en France métropolitaine, un volume d’acteurs à ne pas négliger lorsque l’on s’interroge sur les besoins web ordinaires.

Par ailleurs, le Baromètre France Num 2025 montre que 84 % des TPE-PME disposent d’au moins une solution de visibilité en ligne ; 65 % possèdent un site internet présentant leur activité, 66 % ont au moins un compte sur un réseau social, et 37 % proposent une solution de vente ou de paiement en ligne. Ces données illustrent bien que, pour beaucoup d’acteurs, le besoin premier n’est pas nécessairement de développer une application riche, mais d’être visible, joignable, crédible, identifiable et parfois capable de vendre ou de recevoir une demande.

À ces entreprises s’ajoute le monde associatif, lui aussi grand producteur de contenus, d’actualités, d’événements, d’appels à bénévoles, de formulaires d’inscription et de pages d’information. Comme le rappelle le bilan annuel publié sur La France associative en mouvement 2025, plus de 74 000 associations ont été créées entre juillet 2024 et juin 2025. Même lorsqu’elles ne disposent pas de moyens techniques importants, ces structures ont besoin de publier, d’expliquer, de mobiliser, de documenter leurs actions.

C’est ici que la question du vanilla web commence à devenir concrète : face à ces besoins nombreux, souvent modestes mais essentiels, faut-il systématiquement mobiliser une pile technique lourde, ou bien commencer par regarder ce que la plateforme web native permet déjà de faire ?

Quels sont les besoins les plus courants ?

Une fois les acteurs identifiés, la question devient plus simple : que demandent-ils réellement au web ? Dans la majorité des cas, les besoins restent très concrets et relativement stables. Il s’agit d’abord d’être visible, de présenter une activité, d’expliquer une offre, d’afficher des informations pratiques comme des horaires, des tarifs ou une localisation. Le web joue ici un rôle de vitrine et de point d’entrée, parfois même de première prise de contact.

À cela s’ajoutent des besoins d’échange et de relation : permettre à un visiteur de contacter, de poser une question, de demander un devis, de s’inscrire, de réserver ou de commander. Ces usages sont aujourd’hui devenus courants, presque attendus, mais ils restent fondamentalement simples dans leur logique : un utilisateur, une action, une réponse.

Enfin, certains sites doivent aller un peu plus loin en proposant des fonctionnalités complémentaires : afficher une carte, présenter un catalogue, filtrer des informations, ou intégrer un service externe. Là encore, il ne s’agit pas nécessairement de construire une application complexe, mais d’ajouter des briques utiles pour améliorer l’expérience ou répondre à un besoin précis.

On voit ainsi que les besoins les plus courants restent simples, lisibles et pragmatiques. Ils ne disparaissent pas avec le temps, mais s’enrichissent progressivement au fil des usages. Cette lecture rejoint d’ailleurs les priorités mises en avant par France Num dans son espace Ma priorité pour numériser ma TPE PME, où les entreprises sont orientées vers des besoins très concrets : être visible sur internet, développer leurs ventes, protéger leur activité, piloter leur entreprise, gérer leurs ressources humaines ou simplement savoir par où commencer.

Elle rejoint aussi l’approche défendue par Pem’s Projects notamment dans Répondre à un besoin, pas créer une dépendance : partir d’un besoin réel, construire avec les personnes concernées, limiter les dépendances et garder des outils compréhensibles, transmissibles et capables d’évoluer.

Dans ce contexte, une question s’impose naturellement : faut-il systématiquement mobiliser des outils complexes pour répondre à ces besoins, ou peut-on, dans certains cas, s’appuyer sur les capacités natives du web ?

Avec quoi publie-t-on aujourd’hui ?

Pour couvrir ces besoins, le web réel s’appuie d’abord sur des outils de publication. Les CMS et les plateformes prêtes à l’emploi occupent une place majeure, car ils permettent de publier sans reconstruire toute l’architecture technique à chaque projet.

D’après les données de W3Techs sur les CMS, en juillet 2026, WordPress est utilisé par 41,5 % de l’ensemble des sites web, soit 59,2 % du marché des CMS identifiés. Derrière lui viennent notamment Shopify avec 5,2 % de tous les sites, Wix avec 4,3 %, Squarespace avec 2,5 %, puis Joomla, Webflow ou Drupal à des niveaux plus modestes.

Cette photographie confirme une chose importante : une grande partie du web n’est pas produite comme une application front-end construite de zéro. Elle passe par des CMS, des plateformes e-commerce, des constructeurs de sites, des thèmes, des extensions et des back-offices déjà prêts. Pour une petite entreprise, une association ou un indépendant, ce choix est logique : il répond rapidement à des besoins de contenu, de visibilité, de catalogue, de formulaire ou de vente, sans imposer immédiatement une équipe de développement complète.

Côté serveur, le paysage reste lui aussi moins “moderne” qu’on ne l’imagine parfois. Les statistiques de W3Techs sur les langages serveur indiquent que PHP est utilisé par 70,8 % des sites dont le langage serveur est connu, très loin devant Ruby, JavaScript côté serveur, Java, Scala ou ASP.NET. Ce chiffre s’explique notamment par le poids historique et actuel de WordPress, mais aussi par la présence durable de nombreux sites, CMS, hébergements mutualisés et applications web bâties sur cet écosystème.

Les frameworks JavaScript modernes sont, eux, très visibles dans les discussions professionnelles, la formation et les offres d’emploi. Le Stack Overflow Developer Survey 2025 montre par exemple que React, Node.js, Next.js, Vue.js ou Angular font partie des technologies web les plus utilisées ou désirées par les développeurs. Mais leur visibilité dans l’écosystème développeur ne signifie pas qu’ils structurent à eux seuls la majorité des sites publiés sur le web. W3Techs mesure par exemple React à 6,1 % de l’ensemble des sites web, et Vue.js à 0,7 %, même si ces chiffres ne reflètent pas toute la richesse des usages applicatifs internes, SaaS ou métiers.

On obtient donc un paysage à plusieurs couches : des CMS pour publier, des plateformes pour vendre, des outils no-code ou low-code pour assembler, des langages serveur pour traiter, des frameworks pour industrialiser certaines interfaces, et des standards natifs qui restent présents partout en dessous.

C’est précisément à cet endroit que la question du vanilla web devient intéressante : non pas comme concurrent direct de WordPress, Shopify, React ou Angular, mais comme le socle commun que tous ces outils finissent, d’une manière ou d’une autre, par produire dans le navigateur.

Définir vanilla web en 2026

Nous venons de regarder qui publie réellement sur le web, quels sont les besoins les plus courants, et avec quels outils ces besoins sont généralement couverts : CMS, plateformes, constructeurs de sites, développements sur mesure ou frameworks. Reste maintenant une question essentielle : derrière ces solutions, que retrouve-t-on toujours au moment où la page arrive dans le navigateur ? Du HTML, du CSS, du JavaScript, des échanges réseau, des APIs, des événements, des formulaires, des données à afficher. Autrement dit : ce que l’on appelle souvent le vanilla web.

Mais alors, c’est quoi, le vanilla web ? Par vanilla web, on désigne l’usage direct des standards natifs du web, tels qu’ils sont compris par le navigateur, sans dépendre d’un framework applicatif pour produire l’interface et l’interaction. Dit autrement, il s’agit de construire avec les briques que le navigateur sait déjà interpréter : HTML, CSS, JavaScript, mais aussi les APIs et mécanismes qui composent aujourd’hui la plateforme web. Le terme peut sembler modeste, voire un peu artisanal, mais il ne désigne pas un web pauvre ou archaïque.

Cette approche rejoint aussi celle défendue par Maximiliano Firtman dans sa session Vanilla Web, consacrée à l’usage des technologies cœur du web sans frameworks. L’intérêt n’est pas de refuser toute bibliothèque par principe, mais de rappeler que HTML, CSS, JavaScript, les APIs du navigateur et les protocoles du web forment déjà une plateforme cohérente, puissante et directement exploitable.

Réduire le vanilla web à trois fichiers, index.html, style.css, script.js, serait donc trop court. En 2026, il faut aussi y inclure le HTML sémantique, le CSS moderne, le JavaScript natif, le DOM, les événements, les formulaires, les modules ES, fetch(), JSON, les APIs natives, les APIs d’URL, d’historique, de stockage ou de géolocalisation, les Web Components, les Service Workers, le Web App Manifest, l’accessibilité native, le responsive design, HTTP/HTTPS, la sécurité côté navigateur et le progressive enhancement.

Dans « Technologies web pour développeurs », MDN rappelle d’ailleurs que les technologies du web ouvert couvrent bien plus que le trio HTML, CSS et JavaScript : elles englobent aussi les APIs du navigateur, HTTP, l’accessibilité, la sécurité et les Progressive Web Apps.

Cette évolution est aussi rendue plus lisible par le projet Baseline, porté notamment par MDN et web.dev. Son objectif est d’indiquer quelles fonctionnalités de la plateforme web sont désormais suffisamment disponibles dans les navigateurs courants pour être utilisées avec davantage de confiance dans les projets.

Can I use permet, de son côté, de vérifier plus précisément la compatibilité d’une API, d’une propriété CSS ou d’une fonctionnalité HTML selon les navigateurs et leurs versions. Autrement dit, le navigateur moderne n’est plus seulement un lecteur de documents : c’est un environnement d’exécution riche, capable de gérer des interactions, des données, du stockage, du réseau, des composants et parfois même une partie de l’expérience hors ligne.

Pour aller plus loin, les standards eux-mêmes sont documentés par des organismes comme le W3C et le WHATWG.

On peut ainsi résumer cette idée de manière simple : vanilla web n’est pas un web pauvre ; c’est le web avant l’ajout des surcouches. Cela ne signifie pas qu’il faille refuser les frameworks, les CMS ou les plateformes. Cela signifie simplement qu’avant de les choisir, il faut savoir ce que la plateforme native permet déjà. C’est seulement à partir de cette connaissance que l’on peut décider si une surcouche apporte une vraie valeur, ou si elle ajoute surtout de la complexité.

Quand vanilla web suffit largement

Une fois le vanilla web replacé dans son périmètre réel, une question devient plus facile à poser : dans quels cas suffit-il largement ? La réponse concerne tous les projets où l’interface reste lisible, où les interactions sont limitées, et où le besoin consiste surtout à présenter, saisir, afficher, filtrer, envoyer ou récupérer quelques données. Pages éditoriales, sites vitrines sobres, formulaires simples, prototypes, démonstrateurs pédagogiques, widgets, petites interfaces d’administration ou connexions API modérées entrent souvent dans ce cadre.

Le vanilla web est particulièrement pertinent lorsque la sobriété technique devient un avantage : moins de dépendances, moins de compilation, moins de couches à maintenir, moins de rupture entre ce que l’on écrit et ce que le navigateur exécute. Pour une petite application métier, une interface interne, une page enrichie ou une PWA simple, les standards natifs peuvent déjà couvrir beaucoup de besoins : structure HTML, styles CSS, événements JavaScript, requête fetch(), réponse JSON, stockage local, mise à jour du DOM, voire fonctionnement partiel hors ligne avec un service worker.

Les articles Puce & Média consacrés aux distances illustrent bien cette logique. Dans Rechercher des utilisateurs dans un rayon géographique avec PHP et SQL, le besoin initial reste très concret : saisir un code postal, choisir une commune, définir un rayon, puis afficher une liste de résultats. Dans Comparer distance à vol d’oiseau et distance routière avec PHP, SQL et OpenRouteService, ce même besoin est enrichi par une API externe. Pourtant, côté interface, la logique reste accessible : formulaire, événement, appel, réponse, affichage. Le sujet n’est pas de tout faire en vanilla, mais de constater qu’une partie importante du dialogue avec l’utilisateur peut rester simple, lisible et native.

C’est aussi ce que montrera l’article suivant, « Vanilla web en pratique : créer une interface météo sans framework » avec une petite interface météo. Une ville saisie dans un formulaire, un événement JavaScript, une requête HTTP vers une API, une réponse JSON, puis une mise à jour de l’affichage : cette chaîne suffit déjà à mobiliser une grande partie de la plateforme web native. Pour ce type de besoin, commencer par le vanilla web n’est pas un retour en arrière. C’est souvent une manière de vérifier, avant toute surcouche, ce que le navigateur permet déjà de faire correctement.

Quand vanilla web ne suffit plus

Pour rester juste, il faut aussi reconnaître les limites du vanilla web. Plus une interface devient riche, plus elle doit gérer d’états, de vues, de composants dynamiques, de permissions, de synchronisations ou de parcours utilisateurs complexes. Dans ces situations, écrire uniquement du JavaScript natif peut rester possible, mais devenir moins confortable, moins lisible, voire plus coûteux à maintenir.

Le problème n’est alors pas que le navigateur serait incapable de faire le travail, mais que l’organisation du code devient plus difficile à maîtriser dans la durée.

Les frameworks front-end se sont justement imposés pour répondre à ces difficultés : structurer les composants, organiser l’état applicatif, gérer le routage, faciliter les tests, industrialiser la construction, partager des conventions entre développeurs et accompagner des équipes nombreuses. Une application métier utilisée chaque jour par plusieurs services, un tableau de bord riche, un produit SaaS, un back-office complexe ou une interface fortement interactive peuvent avoir besoin de cette discipline supplémentaire. Dans ces cas, React, Vue, Angular, Svelte ou d’autres outils ne sont pas des surcouches inutiles : ils deviennent des cadres de travail.

Il faut aussi tenir compte du contexte professionnel. Une entreprise peut déjà disposer d’un design system, d’une stack imposée, d’une chaîne de déploiement, de tests automatisés, de composants partagés ou de compétences internes orientées vers un framework donné. Dans ce cas, choisir vanilla web uniquement par principe n’aurait pas forcément de sens. La bonne question n’est pas : quel outil est le plus pur ? Elle est plutôt : quel outil permet à l’équipe de produire, maintenir et faire évoluer correctement le service attendu ?

Le choix n’est donc pas moral. Il est architectural. Vanilla web suffit largement lorsque le besoin reste simple, lisible et maîtrisable avec les standards natifs. Un framework devient pertinent lorsqu’il apporte une structure, une cohérence d’équipe ou une capacité d’évolution que le code natif seul ne garantit plus assez facilement. L’enjeu n’est pas de choisir un camp, mais de choisir le bon niveau de complexité.

Ce que vanilla web apprend au développeur

Travailler avec le vanilla web oblige à revenir aux fondations : comprendre le rôle de chaque brique du navigateur et la manière dont elles s’assemblent pour construire une interface. Cette approche prolonge directement l’article Développeur web : comprendre les briques pour construire, qui rappelait déjà qu’un développeur ne progresse pas seulement en accumulant des outils, mais en comprenant ce que chacun rend possible. Le HTML ne sert pas seulement à “poser des blocs” : il décrit la structure, le sens, les formulaires, les liens, les titres, les contenus et une partie de l’accessibilité. Le CSS ne se limite pas à décorer : il organise la mise en page, l’adaptation aux écrans, les états visuels, les transitions et la lisibilité. Le JavaScript, lui, déclenche les interactions, écoute les événements, manipule le DOM, prépare les requêtes et met à jour l’interface.

Cette proximité avec la plateforme rend visibles des notions que les surcouches peuvent parfois masquer. Une requête fetch() rappelle qu’un navigateur échange avec un serveur au moyen de HTTP ou HTTPS. Une API n’est pas une formule magique, mais un point d’accès organisé à des données ou à des services. Une réponse JSON n’est pas encore une interface : c’est une donnée qu’il faut lire, vérifier, transformer, puis afficher. Le développeur doit donc comprendre ce qui circule entre l’utilisateur, le navigateur, le réseau, le serveur et la page affichée.

Cette compréhension est également précieuse pour savoir où placer les limites. Certaines vérifications peuvent être faites côté navigateur pour améliorer l’expérience utilisateur : champ vide, format attendu, message d’erreur immédiat. Mais d’autres responsabilités ne doivent jamais être confiées uniquement au client : sécurité, droits d’accès, validation définitive des données, secrets d’API, calculs sensibles ou règles métier critiques. Le vanilla web apprend ainsi une chose essentielle : le navigateur est puissant, mais il n’est pas un coffre-fort.

Les exemples déjà publiés sur Puce & Média, notamment dans l’article Comparer distance à vol d’oiseau et distance routière avec PHP, SQL et OpenRouteService, montrent cette circulation entre interface, serveur, base de données et API externe. Dans ces articles, le besoin part d’un formulaire et d’une demande utilisateur, puis traverse plusieurs couches avant de revenir sous forme de résultat exploitable. Cette approche est également détaillée dans les articles Concevoir nos applications depuis le terrain : écouter les besoins, construire par le code et Tracer des solutions : du code à l’usage, qui insistent sur l’importance de partir des usages réels avant de choisir les outils. L’article actuel élargit cette logique au navigateur lui-même : comprendre le vanilla web, c’est apprendre à lire le trajet complet d’une donnée, depuis l’action de l’utilisateur jusqu’à son affichage dans la page.

Conclusion

Le vanilla web n’est ni une nostalgie, ni une opposition de principe aux frameworks. Il rappelle simplement une évidence parfois oubliée : avant les surcouches, les outils de build, les bibliothèques de composants ou les architectures applicatives, il existe une plateforme native, comprise par le navigateur, capable de structurer une page, de réagir à une action, d’interroger une API, de recevoir des données et de mettre à jour une interface.

Cette plateforme ne répond pas à tous les besoins. Dès que l’état applicatif se complexifie, que les équipes s’élargissent, que les composants se multiplient ou que l’industrialisation devient centrale, un framework peut devenir un choix parfaitement justifié. Mais l’inverse est tout aussi vrai : pour de nombreux besoins de publication, d’interaction simple, de formulaire, d’affichage de données, de prototype ou de petite interface métier, commencer par le web natif permet souvent de rester plus sobre, plus lisible et plus proche du besoin réel.

Le véritable enjeu n’est donc pas de choisir un camp entre vanilla web et frameworks. Il est de savoir lire une situation : quel est le besoin ? quelles données circulent ? quelles interactions sont nécessaires ? quelle complexité faut-il réellement porter ? C’est seulement à partir de ces questions que l’on peut choisir lucidement entre CMS, plateforme, framework, développement sur mesure ou usage direct des standards du web.

Dans le prochain article, nous mettrons cette réflexion à l’épreuve avec un exemple volontairement simple : une petite interface météo construite sans framework. Elle nous permettra d’observer, concrètement, le trajet d’une donnée depuis un formulaire jusqu’à l’affichage dans la page : événement JavaScript, requête HTTP, API, réponse JSON, mise à jour du DOM et gestion des erreurs. Autrement dit, nous quitterons l’état des lieux pour retourner à l’établi.