Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- C'est justement cette longévité qui a posé le problème du cycle de vie. Les versions 1.x et 2.x de jQuery sont en fin de vie (EOL) et ne bénéficient plus de correctifs en amont, et chaque version de jQuery antérieure à la 3.5.0 comporte au moins une vulnérabilité XSS répertoriée dans la base CVE qui n'a été corrigée que dans une version ultérieure.
- Cette bibliothèque figure généralement dans votre graphe de dépendances. jQuery n'a pas de dépendances propres, mais les plugins, les thèmes et les bundles de fournisseurs l'intègrent dans des versions que vous n'avez jamais choisies.
- Une migration vers une nouvelle version majeure ne se résume pas à un simple remplacement de fichiers. La suppression d'API, les problèmes de compatibilité des plugins et les changements de comportement génèrent des bogues qui apparaissent lors d'une utilisation réelle par les utilisateurs plutôt que lors des tests d'intégration (CI).
- Le choix entre « mise à niveau » et « réécriture » est un faux dilemme. OpenJS gère un programme non exclusif d'assistance commerciale pour les versions de projets qui ne bénéficient plus d'un support officiel, et TuxCare fait partie de ses partenaires.
En janvier 2006, John Resig a présenté jQuery lors du BarCamp de New York avec un objectif modeste : rendre l'écriture de code JavaScript moins fastidieuse. Vingt ans et trois jours plus tard, le projet a publié la version 4.0.0. À un moment donné entre ces deux dates, votre application a intégré jQuery 1.11.3, et cette version figure toujours dans le package que vous avez déployé mardi dernier.
C'est précisément cette lacune qui constitue le véritable problème lié à la fin de vie (EOL) de jQuery. La bibliothèque en elle-même n'est pas en cause. Le problème réside dans le fait que jQuery a été déployé à une telle échelle, si tôt et de manière si profondément intégrée au code d'autres développeurs, que des versions entières se sont retrouvées sans support technique alors qu'elles continuaient de fonctionner en production à très grande échelle. Les versions 1.x et 2.x de jQuery sont en fin de vie depuis 2016. La plupart des sites qui les utilisaient ne s'en sont même pas rendu compte.
Voici l’argument qui mérite d’être avancé, car il devrait vous amener à réévaluer vos options : il ne s’agit pas ici d’équipes négligentes. Il s’agit d’un projet fondé par des bénévoles qui a survécu à l’hypothèse selon laquelle tout le monde effectuerait la mise à jour. La Fondation OpenJS, qui héberge aujourd’hui jQuery, l’a d’ailleurs clairement exprimé publiquement et a mis en place un programme spécialement conçu pour y remédier. Cette histoire vous indique quelles sont les options légitimes et lesquelles ne sont qu’une forme de procrastination impliquant des étapes supplémentaires.
Pourquoi l'ancienne version de jQuery est-elle encore si répandue ?
Pour comprendre pourquoi ces versions persistent, rappelez-vous quel problème jQuery avait pour but de résoudre. Au milieu des années 2000, les navigateurs implémentaient JavaScript et le DOM de manière suffisamment différente pour que la recherche d’un élément, l’ajout d’un gestionnaire d’événements ou l’envoi d’une requête asynchrone puissent nécessiter des branches spécifiques à chaque navigateur. Un code qui fonctionnait sous Firefox ne fonctionnait pas sous Internet Explorer.
jQuery a su intégrer toute cette complexité au sein d’une API concise. Cela n’était pas seulement pratique. Cela a permis aux équipes de disposer d’une couche de compatibilité fiable à une époque où la plateforme n’était pas en mesure d’en fournir une, et a rendu le développement front-end interactif accessible à un nombre bien plus important de développeurs.
Chaque gamme de produits marque une étape de cette histoire :
jQuery 1.x (2006) prenait en charge les navigateurs jusqu'à IE 6, ce qui en faisait un choix incontournable pour les applications d'entreprise et administratives soumises à des exigences client très variées. La version 1.12.4, sortie en mai 2016, fut la dernière de la série.
jQuery 2.x (2013) a abandonné IE 6 à 8 pour réduire la taille de la version tout en conservant une API familière. La version 2.2.4, également sortie en mai 2016, a marqué la fin de cette série.
jQuery 3.x (2016) a unifié les deux branches. La version 3.7.1 (août 2023) est la dernière version riche en fonctionnalités, et la politique de support du projet stipule désormais que la version 3.x ne bénéficie plus que de correctifs de sécurité critiques et de corrections de bogues, tous les utilisateurs étant encouragés à passer à la version 4.x. Utiliser la version 3.7.1 n'équivaut pas à utiliser une branche bénéficiant d'un support complet.
jQuery 4.0.0 est sorti le 17 janvier 2026 ; il s'agit de la première version majeure depuis près d'une décennie. Elle abandonne IE 10 et les versions antérieures, la suppression d'IE 11 étant prévue pour la version 5.0, ajoute la prise en charge de Trusted Types et cesse de convertir silencieusement les requêtes JSON inter-domaines en JSONP. Ces deux dernières modifications constituent de réelles améliorations en matière de sécurité.
Il y a une chose qui échappe souvent aux équipes : jQuery UI, jQuery Mobile et Sizzle sont désormais des projets « émérites » chez OpenJS, ce qui signifie qu’ils ont été officiellement retirés. Si votre plan de migration prévoit de « mettre à jour jQuery UI », sachez qu’il n’existe aucune version prise en charge à l’issue de ce processus.
Ce que change réellement la fin de vie
Une fois la maintenance en amont terminée, rien ne plante. Les formulaires s'envoient. Les menus s'ouvrent. Ajax fonctionne. L'application se comporte exactement comme la veille.
Ce qui change, c'est le modèle de sécurité. Le projet ne devrait plus publier de correctifs pour cette branche ; ainsi, la prochaine vulnérabilité affectant votre version apparaîtra sans qu'aucun correctif en amont ne soit disponible. Vous en prendrez connaissance via un scanner plutôt que par le biais d'une note de mise à jour.
Pour une analyse plus approfondie des risques de sécurité courants et des CVE, vous pouvez consulter notre guide détaillé sur les vulnérabilités de jQuery.
L'historique des vulnérabilités CVE concerne précisément les fonctionnalités pour lesquelles les utilisateurs recourent à jQuery :
CVE-2020-11023: XSS in HTML parsing. Passing HTML containing <option> elements from an untrusted source into .html(), .append(), or similar can execute untrusted code even after sanitization. Affects 1.0.3 through 3.4.1, fixed in 3.5.0. CISA added it to the Known Exploited Vulnerabilities catalog on January 23, 2025, giving federal civilian agencies until February 13 to remediate. Published CVSS scores for this one range from 6.1 to 6.9 depending on which scoring source you consult, which is a fair reminder that the KEV listing rather than the number is what carries the deadline.
CVE-2020-11022 : Une faille similaire dans la même logique d'analyse, avec le même score de segmentation. Elle affecte les versions 1.2 à 3.4.1 ; sa plage commence donc un peu plus tard que celle de la faille CVE-2020-11023.
CVE-2019-11358 (CVSS 6.1) : Pollution de prototype dans jQuery.extend(). Un attaquant capable d'influencer l'objet fusionné peut modifier Object.prototype. Concerné toutes les versions antérieures à la 3.4.0, c'est-à-dire l'ensemble des versions 1.x et 2.x.
CVE-2015-9251 : Vulnérabilité XSS dans la gestion Ajax inter-domaines. Envoi d'une requête sans dataType et un serveur malveillant peut répondre avec text/javascript, que jQuery exécute. Concerné : toutes les versions antérieures à la 3.0.0.
CVE-2012-6708 (CVSS 6.1): jQuery(strInput) decides whether input is HTML by looking for < anywhere in the string, which gives an attacker more room to build a payload. Affects versions before 1.9.0.
Précisons toutefois qu’une version affectée ne signifie pas automatiquement que l’application est exploitable. Le niveau réel d’exposition dépend de la manière dont votre code utilise jQuery, du fait que des données non fiables parviennent ou non au chemin vulnérable, et des mesures de protection que vous avez mises en place. Ce que ces CVE démontrent, c’est que « l’application fonctionne toujours » et « l’application est toujours maintenue de manière sécurisée » sont deux affirmations différentes.
C’est là que les audits entrent en jeu. Pour un organisme public gérant un portail de délivrance de permis sous la version 1.11.3, la conséquence concrète n’est pas un scénario de faille spectaculaire. Il s’agit d’une vulnérabilité CVE répertoriée par le KEV avec un délai imposé par le gouvernement fédéral, d’un constat au titre de la norme PCI DSS 6.3.3 si des paiements sont concernés, et d’un auditeur qui vous demandera quelle est votre stratégie de correction. Répondre « Upstream a cessé d’appliquer les correctifs » ne suffit pas à clore ce constat.
L'exposition se trouve dans votre graphe de dépendances
jQuery est autonome et ne présente aucune dépendance d'exécution, ce qui le rend plus simple que la plupart des bibliothèques modernes.
Inversez la perspective et vous comprendrez le problème. jQuery est l'une des bibliothèques les plus utilisées de l'histoire du Web, et votre propre code n'en représente qu'une infime partie. Le reste est constitué de plugins qui supposent une version majeure, de thèmes WordPress, de widgets d'interface utilisateur, de composants commerciaux dont plus personne n'assure la maintenance, de scripts de fournisseurs, ainsi que d'anciennes plateformes de CMS ou de commerce électronique.
Un cas de figure courant : une équipe a migré son code hors de jQuery il y a des années, tout le monde considère que jQuery a disparu, puis vous ouvrez l’onglet « Réseau » en environnement de production et vous constatez que la version 1.11.3 se charge à partir d’un chemin que personne ne reconnaît, car un widget de reporting sous licence intègre sa propre copie. Deux versions sur la page, dont une en fin de vie, aucune des deux n’apparaissant dans le fichier package.json que personne ne vérifie. Dans certains environnements, le fichier a été copié dans l’arborescence source il y a des années et n’est absolument pas géré par un gestionnaire de paquets.
Les scanners en détecteront un grand nombre. Trouver la bibliothèque est la partie la plus facile. L'équipe doit encore déterminer pourquoi cette version est présente, quels éléments en dépendent et si son remplacement modifie le comportement du système.
C'est justement ce graphique qui rend la mise à niveau difficile. Le plugin A est destiné à la version 1.x. Le plugin B appelle la fonction .live(), qui a été supprimée dans la version 1.9. Le plugin C est un composant commercial dont le fournisseur a cessé la distribution en 2019 et dont la licence n’inclut pas le code source.
Pourquoi OpenJS a développé un programme à cet effet
jQuery est un projet « Impact » au sein de la Fondation OpenJS, l'organisme indépendant de tout fournisseur qui l'a accueilli au terme d'un long parcours en matière de gouvernance : la Software Freedom Conservancy en 2009, la Fondation jQuery en 2012, puis la fusion en 2019 avec la Fondation Node.js, qui a donné naissance à OpenJS.
La Fondation travaille depuis des années sur le problème de sécurité lié à jQuery. Le projet Alpha-Omega de l’OpenSSF a alloué 350 000 dollars en 2022 afin de réduire les incidents de sécurité liés à jQuery en modernisant à la fois son code et ses utilisateurs. OpenJS a transféré le CDN de jQuery vers Fastly, qui, fin 2024, traitait environ 70 milliards de requêtes par mois pour ce dernier. La Fondation a développé « Healthy Web Checkup », un outil qui, en cinq secondes, se contente de vous indiquer quelle version de jQuery votre site charge. Elle a commandé l’étude IDC sur laquelle repose sa propre estimation selon laquelle, sur environ 1,9 milliard de sites web, près de 90 % utilisent jQuery et environ un tiers d’entre eux ont besoin d’une mise à jour.
Ce financement ne permet toutefois pas d'assurer la maintenance à durée indéterminée de jQuery 1.8.2. Il existe une limite stricte au temps que les mainteneurs peuvent consacrer bénévolement à la correction de versions commercialisées à l'époque où Windows 7 était encore d'actualité, et prétendre le contraire ne fait que mener les mainteneurs au burn-out.
OpenJS a lancé le programme « Ecosystem Sustainability » en mai 2024 afin de combler cette lacune. Les partenaires fournissent des correctifs de sécurité commerciaux pour les projets hébergés par OpenJS qui sont archivés, en fin de vie ou qui correspondent à d’anciennes versions de projets actuels, et une partie des revenus générés par ces services d’entreprise est reversée aux projets participants. HeroDevs a été le premier partenaire, suivi par NodeSource, puis TuxCare a rejoint la Fondation en tant que membre « Gold » en 2026 et figure désormais parmi les partenaires de l’ESP sur la page des partenaires d’OpenJS.
Il convient de noter que le projet jQuery lui-même considère cette approche comme une option valable. Sa politique de prise en charge des versions propose trois options à toute personne utilisant une version antérieure : effectuer une mise à jour, conserver l'ancienne version et bénéficier de correctifs de sécurité via un support commercial, ou la conserver sans aucun correctif, ce que le projet signale comme comportant un risque réel.
Ces limites restent importantes, car le marketing des fournisseurs a tendance à les brouiller :
- Ce programme n'est pas exclusif. OpenJS ne vous impose pas de fournisseur auprès duquel effectuer vos achats, et trois d'entre eux sont actuellement répertoriés au niveau « Foundation ».
- Les partenaires ESP doivent être membres Gold ou Platinum et détenir une licence d'utilisation de la marque à des fins de co-marketing, avec l'aval au niveau du projet de la TSC ou de l'équipe centrale concernée, le cas échéant. Le partenariat au niveau « Foundation » et la liste des fournisseurs agréés pour un projet spécifique sont deux choses différentes ; veuillez donc consulter la page du projet que vous gérez effectivement.
- Un correctif proposé par un partenaire pour jQuery 1.12.4 reste le correctif de ce partenaire. Il ne s'agit pas d'une version officielle et cela ne signifie pas qu'une ancienne version bénéficie à nouveau d'un support officiel.
- Le programme n'interdit en aucun cas aux responsables de soutenir publiquement la version de leur choix.
Les responsables de jQuery sont propriétaires du projet et de ses versions actuelles. OpenJS offre un hébergement neutre. Les prestataires de support étendu prennent en charge certaines anciennes versions une fois que le support en amont a pris fin. Il s'agit d'une répartition plus durable que d'attendre des bénévoles qu'ils assurent indéfiniment la maintenance de toutes les versions historiques, ou que chaque organisation achève une migration complexe dès que la date limite de support est dépassée.
Vos trois options
Passez à une version prise en charge
Dans la mesure du possible, c'est la bonne solution à long terme. La version actuelle de jQuery est un logiciel plus performant, et la prise en charge des « Trusted Types » ainsi que la modification apportée à JSONP dans la version 4.0 réduisent considérablement votre surface d'attaque XSS.
Mais passer de la version 1.x ne correspond pas à un simple saut de version. Le système d'événements a été réécrit. Ajax et les Deferreds ont été modifiés. .bind(), .delegate(), .live()et .error() ont disparu ou ont changé. Les cas limites des sélecteurs ont évolué. Le plugin jQuery Migrate mettra en évidence la plupart des comportements obsolètes ; c’est donc le premier outil à utiliser. Il ne vous indiquera toutefois pas lesquels de vos plugins n’ont pas de successeur maintenu.
Pour une équipe SaaS de 40 personnes travaillant sur une seule application, avec les plugins actuels et une couverture de test réelle, cela prendra quelques sprints. Pour la suite administrative interne d’une banque comptant 200 plugins cumulés et dont les exigences client mentionnent encore IE 11, cela prendra des mois, et les bugs qui passeront inaperçus seront de ceux qui dépendent des interactions et qui n’apparaîtront qu’en production.
Supprimer complètement jQuery
querySelector(), fetch(), addEventListener()et classList couvrent la plupart des cas d'utilisation réels de jQuery par les équipes. Si votre utilisation est limitée, supprimer cette dépendance est la solution la plus propre, et le faire de manière progressive est préférable à une réécriture complète.
S'il n'est pas léger, évaluez-le à sa juste valeur. Vous réécrivez chaque opération DOM, vous réimplémentez les fonctions d'aide, vous renoncez à la couche de normalisation de jQuery et vous faites fonctionner l'ancien système en parallèle pendant que vous développez le nouveau.
Une assistance prolongée pendant votre processus de modernisation
Certaines applications ne peuvent pas être mises à jour selon le calendrier imposé par une divulgation, mais ne peuvent pas non plus rester sans maintenance. Le support à cycle de vie illimité de TuxCare pour jQuery couvre les versions non prises en charge , notamment les versions 1.8.2, 1.11.3, 1.12.4, 2.2.4, 3.1.1, 3.2.1, 3.3.1 et 3.4.1, fournies via npm.
Le but n'est pas de vous obliger à rester sur une ancienne version. Il s'agit plutôt de dissocier la date limite de mise à jour de sécurité de la date limite de migration.
Trois questions suffisent généralement à trancher :
- Un graphe de dépendances épuré, une couverture de test réelle, aucun plugin commercial abandonné ? Passez à la version 4.0.0 et le tour est joué.
- jQuery ne fait que $() et .on() dans une poignée de fichiers ? Supprimez-le. Ne payez pas pour prendre en charge du code dont vous n'avez pas besoin.
- Des extensions non mises à jour, l'obligation de geler la version du navigateur, ou une migration qui, en réalité, n'aura lieu que dans deux trimestres ? Optez pour une assistance prolongée et planifiez correctement la mise à niveau.
Le coût de la précipitation
Lorsqu'une inscription au programme KEV ou un audit infructueux contraint à réaliser une migration d'envergure dans un délai irréaliste, les causes d'échec sont suffisamment prévisibles pour être identifiées à l'avance.
La charge liée au support vient en premier : des formulaires qui ne s'envoient pas, des menus déroulants qui ne s'ouvrent pas, des requêtes Ajax qui échouent sans message d'erreur, la plupart de ces problèmes étant dus à des différences de comportement entre les versions plutôt qu'à des modifications spécifiques de votre diff. Vient ensuite la stabilité, généralement un cas de bord d'un plugin qui n'apparaît qu'en conditions de production avec une forte concurrence. Puis la dette technique, car sous la pression des délais, la refactorisation est reportée et la phrase « on va nettoyer ça au prochain trimestre » devient une habitude permanente. Vient ensuite le budget : les heures des prestataires, le retard pris sur la feuille de route, et vos meilleurs ingénieurs front-end qui passent des semaines à travailler sur la compatibilité.
Les mises à niveau planifiées sont une bonne chose. Les mises à niveau effectuées dans la précipitation constituent en revanche une activité distincte, avec une structure de coûts différente, et les équipes ont souvent tendance à sous-estimer leur coût d'au moins deux fois.
Comment TuxCare corrige les versions de jQuery en fin de vie
Le support prolongé ne se limite pas à la simple republication d’un ancien paquet ; le plus difficile réside dans le portage lui-même. Un correctif écrit pour une branche actuelle dépend souvent d’une refactorisation ultérieure, de tests différents ou d’hypothèses relatives aux navigateurs qui n’existent pas dans la version cible. Le correctif doit préserver l’objectif de sécurité de la modification en amont sans introduire de comportements non liés ni rompre la compatibilité qui vous a incité à rester sur l’ancienne version.
Surveillance et analyse. TuxCare suit les informations de la base de données NVD, les avis des éditeurs, les flux de sécurité GitHub et le catalogue KEV de la CISA, puis détermine si un problème signalé affecte réellement une version couverte. Les plages de versions publiées ne suffisent pas à elles seules ; le chemin d'accès au code vulnérable doit être examiné.
Portage en amont et validation. Les correctifs en amont sont adaptés à l’ancienne base de code à l’aide d’outils automatisés, puis validés par des ingénieurs en sécurité. Ils font ensuite l’objet de tests d’intégrité, de fonctionnalité et de régression avant leur publication. Les paquets sont signés et distribués à partir des dépôts hébergés par TuxCare. Si vous préférez les détails techniques plutôt que le résumé, consultez le livre blanc technique de TuxCare sur son processus de correction open source est plus accessible que la plupart des documents de ce type.
Documentation. Chaque version répertorie les CVE qui ont été corrigées et les composants qui ont été modifiés, avec le contexte SBOM et VEX, afin que vous puissiez montrer quelles non-conformités ont déjà été corrigées. C'est l'élément que recherche un auditeur, et c'est ce qui fait la différence entre une non-conformité clôturée et une non-conformité en cours.
À titre de comparaison : en près de 15 ans, TuxCare a fourni plus de 220 000 correctifs et résolu plus de 5 000 vulnérabilités (CVE) sur divers systèmes d'exploitation, environnements d'exécution, bibliothèques et applications.
Commencez par dresser un inventaire
Avant d'évaluer une option, vérifiez ce que vous utilisez réellement. Vérifiez les arborescences de code source, les bundles compilés, les manifestes de paquets, les références CDN, les plugins CMS, les bibliothèques des fournisseurs et les pages de production rendues. Ne partez pas du principe que la version déclarée par votre application est la seule à être accessible aux utilisateurs.
Pour chaque cas, notez la version exacte, le composant qui l'utilise, s'il se charge directement ou via un autre produit, ce qui en dépend, quels environnements clients doivent continuer à fonctionner, et l'ampleur des tests de régression qu'une modification nécessiterait. Une fois ces informations disponibles, il est facile de distinguer clairement les mises à jour simples de celles présentant un risque élevé.
Vérifiez ensuite la prise en charge de vos versions spécifiques à l'aide du suivi CVE en temps réel, qui répertorie les vulnérabilités déjà corrigées. Pour connaître les versions prises en charge, les tarifs et les détails de mise en œuvre, consultez la page de TuxCare intitulée « Assistance à vie pour jQuery » de TuxCare.
Le prochain chapitre
La longévité de jQuery ne signifie pas pour autant que cette bibliothèque a fait son temps. Elle témoigne au contraire de la manière dont elle a su résoudre un problème fondamental, à tel point que la plateforme a fini par intégrer une grande partie de ses fonctionnalités. La version 4.0.0 montre que le projet continue d'évoluer.
Des millions de lignes de code de production ont toutefois été écrites au cours des premières étapes de cette évolution, et celles-ci évoluent à des rythmes différents. Certaines peuvent être mises à niveau dès ce trimestre. D’autres sont liées à des applications stratégiques pour l’entreprise, à des plugins obsolètes, à des navigateurs de bornes interactives et embarqués, ou à des programmes de modernisation s’étalant sur plusieurs années.
Passez à des logiciels pris en charge dès que vous le pouvez. Si vous ne pouvez pas le faire immédiatement, identifiez précisément les versions que vous utilisez et mettez en place un véritable plan de maintenance pour celles-ci. Le programme « Ecosystem Sustainability » a été créé pour que ce plan ne se résume pas à demander à des bénévoles d’appliquer indéfiniment des correctifs aux versions de 2016.
Découvrez le site de TuxCare « Assistance à vie pour les logiciels open source » de TuxCare pour découvrir comment une assistance étendue peut couvrir l'ensemble de votre pile open source aussi longtemps que vous en avez besoin.
