Baseline Web : faut-il enfin abandonner les polyfills ?

Les polyfills ont longtemps été une assurance tous risques pour le front-end. On ajoute core-js, une implémentation de fetch, quelques correctifs CSS ou un service de transpilation, et l’application semble fonctionner partout. Le coût est rarement visible au moment où la dépendance est ajoutée. Il apparaît plus tard : JavaScript supplémentaire, maintenance, incohérences entre environnements, bugs dans les chemins peu testés et builds plus opaques.

Le repère Baseline Web, porté notamment par les équipes de navigateurs et documenté sur web.dev, apporte un vocabulaire utile pour parler de compatibilité. Il ne dit pas simplement « les navigateurs sont modernes ». Il permet de distinguer les fonctionnalités largement disponibles de celles qui restent récentes ou inégalement implémentées.

Faut-il pour autant supprimer tous les polyfills ? Non. Baseline n’est ni une autorisation automatique de casser les anciens environnements, ni une excuse pour ignorer les besoins réels des utilisateurs. C’est un indicateur à combiner avec les données d’audience, les contraintes métier et une stratégie de dégradation explicite. L’objectif n’est pas de faire disparaître chaque octet de compatibilité : c’est de cesser de payer par défaut pour des navigateurs que votre produit ne sert peut-être plus.

Baseline Web : ce que cet indicateur change vraiment

Baseline est une manière partagée de décrire la disponibilité des fonctionnalités de la plateforme web dans les principaux navigateurs. Son intérêt est avant tout opérationnel : au lieu de parcourir une matrice de compatibilité pour chaque API, une équipe peut savoir si une fonctionnalité appartient à une catégorie largement prise en charge ou si elle doit encore être traitée avec précaution.

Les états utilisés par Baseline sont généralement présentés ainsi :

• Limited availability : une fonctionnalité n’est pas disponible de manière suffisamment homogène dans les navigateurs de référence ;
• Newly available : elle est prise en charge dans les principaux moteurs, mais sa disponibilité est récente ;
• Widely available : elle est disponible de façon stable depuis plus longtemps dans ces navigateurs.

Cette distinction est plus utile qu’une réponse binaire « compatible / incompatible ». Une API nouvellement disponible peut être pertinente pour une application interne où les navigateurs sont maîtrisés, mais trop risquée pour un site public touchant des appareils anciens. À l’inverse, une fonctionnalité largement disponible peut permettre de supprimer un polyfill historique, à condition que les données du site confirment que les versions réellement utilisées entrent dans le périmètre.

Baseline ne remplace donc pas des outils comme Can I use, ni les tables de compatibilité de MDN Web Docs. Il réduit surtout la friction au moment de décider. Pour un développeur, le bon réflexe devient : « quel est le statut Baseline de cette fonctionnalité, et est-ce cohérent avec notre audience ? »

Baseline décrit un état de la plateforme. Votre analytics décrit la réalité de votre produit. Les deux informations sont nécessaires.

Pourquoi les polyfills restent souvent activés par défaut

La plupart des polyfills ne sont pas conservés parce qu’ils répondent encore à un besoin identifié. Ils survivent parce qu’ils ont été ajoutés dans un contexte ancien, puis oubliés. Une configuration Babel, un preset de framework ou une dépendance partagée peut continuer à injecter du code de compatibilité sans que personne ne sache exactement quel navigateur il cible.

Le cas classique est core-js. Cette bibliothèque fournit des implémentations de nombreuses API JavaScript standardisées. Elle peut être pertinente lorsqu’une application doit réellement prendre en charge des navigateurs dépourvus de certaines API utilisées par le code. En revanche, l’importer globalement sans analyse peut charger des correctifs dont l’application n’a pas besoin.

On rencontre aussi régulièrement :

• des polyfills pour fetch alors que les navigateurs effectivement utilisés le prennent déjà en charge ;
• des polyfills pour Promise, URL ou URLSearchParams hérités d’une configuration ancienne ;
• des bibliothèques de formatage de dates chargées pour compenser d’anciennes limites de Intl ;
• des scripts de détection de fonctionnalités devenus inutiles après une évolution des navigateurs cibles ;
• des transformations JavaScript très conservatrices qui augmentent le volume du bundle produit.

Il faut également distinguer polyfill, transpilation et fallback. Un polyfill ajoute une API absente ou en reproduit le comportement. La transpilation transforme une syntaxe récente vers une syntaxe plus ancienne. Un fallback propose une autre expérience lorsque la fonctionnalité n’existe pas. Ces mécanismes ne se décident pas avec les mêmes critères.

Par exemple, remplacer une syntaxe JavaScript peut être nécessaire pour exécuter un bundle sur une cible donnée. En revanche, un fallback CSS peut être préférable à un polyfill JavaScript : une mise en page peut rester lisible sans reproduire intégralement une fonction moderne. Cette nuance est importante si l’on cherche à alléger le front-end sans dégrader l’usage.

Le même principe vaut pour les frameworks. Une application React, Vue, Angular ou Svelte peut embarquer des choix de compatibilité via sa chaîne de build, mais cela ne dispense pas de regarder le résultat livré. Le navigateur ne télécharge pas votre intention : il télécharge les fichiers réellement générés.

Baseline ne définit pas votre politique de support

Une erreur fréquente consiste à transformer Baseline en politique universelle : « largement disponible, donc nous pouvons retirer le support ancien ». Ce raccourci est risqué. Baseline s’appuie sur les principaux navigateurs, mais une politique de support produit doit couvrir des questions plus larges :

• quels navigateurs et quelles versions représentent votre audience réelle ;
• si le site est public, interne, B2B, grand public ou soumis à des contraintes réglementaires ;
• si des postes verrouillés, des appareils industriels ou des navigateurs embarqués sont présents ;
• si l’usage concerne un parcours secondaire ou une action critique comme un paiement, une authentification ou une demande administrative ;
• si une fonctionnalité absente bloque l’accès ou n’affecte qu’un enrichissement visuel.

Un extranet utilisé par quelques grandes entreprises peut avoir une longue traîne de postes Windows gérés par l’IT. Un site média peut recevoir beaucoup de trafic depuis des appareils mobiles plus anciens. Une application métier interne peut, au contraire, maîtriser précisément son parc de navigateurs. Dans ces trois situations, la même fonctionnalité Baseline peut conduire à des décisions différentes.

Le bon livrable n’est pas une promesse vague du type « navigateurs modernes ». Écrivez une politique courte et vérifiable. Par exemple : les deux dernières versions majeures des navigateurs concernés par l’audience, avec une règle spécifique pour les navigateurs représentant une part significative des sessions ou du chiffre d’affaires. Le seuil exact dépend du produit ; il n’existe pas de pourcentage magique applicable à tous les sites.

Cette politique doit être validée avec les équipes produit, support et métier. Le support connaît les navigateurs qui génèrent des tickets. Le produit connaît les parcours où une erreur est inacceptable. Les développeurs peuvent ensuite traduire ces exigences dans les cibles du build, les tests et les règles de dégradation.

Mesurer son audience avant de retirer une dépendance

Avant de supprimer un polyfill, commencez par vérifier qui utilise réellement le site. Google Analytics, Matomo, Plausible ou les logs du serveur peuvent fournir une lecture des navigateurs, systèmes d’exploitation et types d’appareils. Aucun outil n’est parfait, mais un échantillon réel vaut mieux qu’une supposition basée sur le marché global.

Dans Google Analytics 4, les dimensions liées au navigateur et à sa version permettent d’identifier les environnements minoritaires mais potentiellement importants. Matomo propose également des rapports sur les navigateurs et les appareils. Les logs d’un CDN comme Cloudflare, lorsqu’ils sont disponibles, peuvent compléter cette lecture avec les requêtes effectivement reçues.

Ne regardez pas seulement le nombre de sessions. Segmentez les données :

• par parcours : page marketing, recherche, inscription, tunnel d’achat, espace connecté ;
• par pays ou région lorsque le produit est international ;
• par client ou organisation pour un service B2B ;
• par conversion, erreur applicative ou abandon lorsque ces événements sont mesurés ;
• par période suffisamment longue pour éviter de décider à partir d’une semaine atypique.

Une version ancienne peut sembler marginale dans le trafic global et représenter pourtant une clientèle identifiable. À l’inverse, une compatibilité maintenue pour une part infime de visites non engagées peut coûter plus qu’elle ne rapporte. C’est précisément une décision produit, pas seulement une optimisation technique.

Complétez les analytics par la réalité du support. Si un navigateur n’apparaît presque pas dans les rapports mais est connu pour être obligatoire chez un client sous contrat, son poids métier est supérieur à son poids statistique. Documentez cette exception au lieu de laisser un polyfill anonyme l’exprimer implicitement.

Auditer ce qui est réellement livré au navigateur

La suppression des polyfills commence par un inventaire. Cherchez dans le code source, mais surtout dans les artefacts de production. Un import peut être indirect, une dépendance peut embarquer son propre correctif et la configuration de compilation peut injecter du code sans référence visible dans l’application.

Quelques actions simples permettent de rendre le sujet concret :

• inspecter les dépendances avec npm ls, pnpm why ou yarn why ;
• rechercher core-js, regenerator-runtime, whatwg-fetch et les imports de polyfills dans le dépôt ;
• analyser les bundles avec webpack-bundle-analyzer lorsque Webpack est utilisé, ou les outils d’analyse proposés par Vite et Rollup ;
• contrôler le JavaScript chargé dans les DevTools de Chrome, Firefox et Safari ;
• vérifier la configuration browserslist, souvent consommée par Babel, Autoprefixer et d’autres outils de la chaîne front-end.

browserslist mérite une attention particulière. Ce fichier ou cette configuration centralise souvent les navigateurs cibles. Une cible trop large peut produire plus de transformations et de préfixes CSS que nécessaire. Une cible trop restrictive peut exclure silencieusement une partie de l’audience. Elle doit donc être alignée sur la politique de support, puis revue régulièrement.

Mesurez ensuite l’effet réel d’un retrait. Comparez la taille des fichiers compressés, le nombre de requêtes, le code exécuté au démarrage et les résultats de tests. Lighthouse peut aider à observer certains symptômes de surcharge, mais il ne remplace pas une mesure sur appareils réels ni les données de terrain recueillies par les outils de performance.

Sur ce sujet, la même prudence s’applique que pour le choix d’un framework : la simplification est utile lorsqu’elle répond à une contrainte réelle, pas lorsqu’elle suit une tendance. Notre article sur le choix d’un framework JavaScript sans suivre la hype défend cette logique de décision.

Une méthode pragmatique pour retirer un polyfill

La stratégie la plus sûre est incrémentale. Ne lancez pas une grande opération « zéro polyfill » sur une base de code entière. Traitez un correctif à la fois, avec une hypothèse claire et un plan de retour arrière.

1. Identifier l’API et son usage

Pour chaque dépendance, notez l’API concernée, les écrans où elle est utilisée et le type de rupture possible. L’absence de fetch peut empêcher un chargement de données. L’absence d’une propriété CSS peut seulement modifier la présentation. Ces deux cas ne justifient pas le même niveau de précaution.

2. Vérifier Baseline et les données de compatibilité

Consultez le statut de la fonctionnalité sur web.dev et sa documentation MDN. Puis confrontez-le aux versions présentes dans votre audience. Si une version non compatible est encore supportée, le polyfill peut rester justifié. Si elle n’est plus dans la politique définie, son maintien doit être un choix explicite, pas une inertie.

3. Vérifier les dépendances fonctionnelles

Un polyfill peut être utilisé indirectement par une bibliothèque. Retirez-le dans une branche, lancez les tests unitaires et d’intégration, puis testez les parcours critiques. Les tests end-to-end avec Playwright ou Cypress sont utiles pour vérifier une inscription, une recherche, un formulaire ou une étape de paiement.

4. Déployer progressivement

Si votre infrastructure le permet, un déploiement progressif limite le risque. Surveillez les erreurs JavaScript via Sentry, Bugsnag ou un outil équivalent, ainsi que les indicateurs métier du parcours concerné. Conservez une procédure de rollback simple. Le retrait d’un polyfill ne mérite pas une crise de production.

5. Documenter la décision

Ajoutez une note dans le dépôt ou dans la documentation technique : polyfill retiré, API concernée, navigateurs ciblés, date de vérification et solution de repli éventuelle. Cette trace évite qu’un membre de l’équipe le réintroduise six mois plus tard par prudence, sans savoir pourquoi il avait disparu.

Préférer la dégradation maîtrisée au faux support universel

Supprimer un polyfill ne signifie pas forcément abandonner l’utilisateur. Il est souvent possible de proposer une expérience dégradée, claire et utilisable. C’est particulièrement vrai pour les capacités non essentielles.

En CSS, @supports permet d’appliquer une amélioration seulement lorsqu’une propriété est reconnue. L’interface de base reste alors utilisable sans charger de JavaScript destiné à imiter un comportement visuel. En JavaScript, une détection de fonctionnalité ciblée peut éviter un plantage :

if ('share' in navigator) {
  // Afficher une action de partage native
} else {
  // Conserver une option de copie de lien
}

L’idée n’est pas de multiplier les branches de code. Il s’agit de réserver les alternatives aux situations où elles ont une valeur utilisateur réelle. Pour une fonction de partage, copier une URL peut suffire. Pour un paiement ou une authentification, la réponse peut être différente : il faut alors préserver un parcours compatible ou indiquer clairement l’environnement requis.

Les passkeys illustrent bien cette distinction. Elles peuvent améliorer l’expérience d’authentification sur les environnements compatibles, mais un produit ne doit pas rendre un compte inaccessible sans solution de secours adaptée. Nous avons abordé ce compromis dans notre analyse des passkeys.

La dégradation progressive est plus robuste qu’une émulation totale lorsque l’émulation alourdit fortement le code ou reproduit imparfaitement des comportements natifs. Elle oblige aussi à se poser la bonne question : quelle est la fonction indispensable, indépendamment de la technologie utilisée pour l’enrichir ?

Attention aux polyfills chargés à la demande

Entre le maintien global et la suppression totale, il existe une troisième voie : charger un polyfill uniquement lorsque la fonctionnalité manque. Cette approche peut être utile pour une API nécessaire à un parcours précis, mais elle a des contreparties.

Un chargement conditionnel ajoute de la complexité asynchrone. Il faut gérer l’état de chargement, les échecs réseau, l’ordre d’exécution et les tests dans les navigateurs concernés. Il peut aussi retarder l’action de l’utilisateur au moment où elle devient nécessaire. Un polyfill conditionnel n’est donc pas automatiquement une optimisation.

Cette option est raisonnable lorsque trois conditions sont réunies :

• l’API est réellement nécessaire dans un flux donné ;
• les navigateurs qui en ont besoin représentent une audience encore supportée ;
• le coût de maintien de cette branche est inférieur au coût d’un chargement global ou d’une alternative produit.

Dans les autres cas, une expérience de base sans cette fonctionnalité est souvent plus simple. Le front-end gagne alors en lisibilité, ce qui rejoint un principe utile pour éviter la dette : ne pas déléguer à une couche de compatibilité ce qui devrait être décidé dans le produit et explicité dans le code.

Mettre en place une revue de compatibilité durable

Le sujet ne se règle pas une fois pour toutes. Les navigateurs évoluent, l’audience évolue, les dépendances évoluent. Une revue légère, par exemple lors d’une mise à jour importante du front-end ou d’un bilan de performance, suffit généralement à éviter l’accumulation.

Une checklist simple peut encadrer cette revue :

• la politique de navigateurs supportés est-elle encore écrite et validée ;
• la configuration browserslist correspond-elle à cette politique ;
• les polyfills présents ont-ils chacun une justification documentée ;
• les bundles ont-ils été inspectés après les changements majeurs ;
• les parcours critiques sont-ils testés sur les environnements réellement importants ;
• les erreurs front-end montrent-elles un problème de compatibilité émergent.

Cette discipline évite deux excès : conserver indéfiniment une couche de code coûteuse par peur de casser quelque chose, ou supprimer brutalement toute compatibilité au nom de la modernité. Elle s’inscrit dans la même démarche qu’une refonte progressive : réduire le risque par des changements observables et réversibles. À ce sujet, consultez aussi notre méthode pour refondre un site legacy sans tout casser.

Conclusion : abandonner les polyfills par défaut, pas la compatibilité

Baseline Web donne un langage commun pour évaluer la maturité d’une fonctionnalité, mais il ne décide pas à votre place. La bonne décision naît de la rencontre entre cet indicateur, les données d’audience, les contraintes métier et le niveau de criticité de chaque parcours.

Commencez modestement : auditez un polyfill global, identifiez l’API qu’il couvre, vérifiez sa disponibilité et comparez-la aux navigateurs réellement utilisés. Testez son retrait, surveillez la production, puis documentez le résultat. Répétée dans le temps, cette méthode peut réduire le JavaScript inutile sans sacrifier les utilisateurs qui comptent vraiment.

Sur Code Brut, nous défendons ce type de modernisation : moins de compatibilité théorique, davantage de décisions mesurées et de code justifié. Votre prochain audit de bundle est un bon endroit pour commencer.