HeroDevs annonce le programme « Never-Ending Support (NES) React

React est la bibliothèque front-end la plus répandue au monde. Environ 44 % des développeurs utilisent React, ce qui en fait le framework front-end le plus utilisé selon l’enquête Stack Overflow 2025 auprès des développeurs, et les anciennes versions restent profondément ancrées en production : les données de téléchargement npm montrent que React 16 enregistre encore environ 3,5 millions de téléchargements par semaine, et React 17 environ 3,6 millions, plusieurs années après l’arrêt du développement actif. Ces chiffres sont éloquents. Une part importante des applications front-end d'entreprise fonctionne sur d'anciennes versions de React qui ne bénéficient peut-être que de correctifs de sécurité limités en amont.

HeroDevs annonce aujourd’hui la mise à disposition d’Never-Ending Support (NES) pour React, compatible avec les versions 16.x et 17.x de React. NES pour React assure la correction continue des vulnérabilités de React et React-DOM, tous niveaux de gravité confondus, sous la forme d’un remplacement direct via npm ne nécessitant aucune modification du code de l’application.

‍

Comprendre le déficit d'accompagnement

Contrairement à Node.js ou à Angular, React ne dispose pas de programme officiel de support à long terme (LTS) ni de dates de fin de vie publiées. La politique de gestion des versions du projet stipule que les correctifs de sécurité sont rétroportés vers les versions majeures concernées, mais cet engagement est de portée discrétionnaire, ne couvre aucune plage de gravité définie et n'est assorti d'aucun délai de réponse.

React 19 étant désormais la version majeure actuelle, React 16 et React 17 ne font plus l'objet d'un développement actif. Les applications construites à partir de ces versions continuent de s'afficher et de fonctionner en production. C'est précisément ce qui rend le risque facile à négliger : « ça fonctionne toujours » n'est pas synonyme de « c'est sécurisé et pris en charge ».

‍

Le croisement entre les logiciels libres en fin de vie et la conformité

React étant intégré aux applications basées sur JavaScript, une vulnérabilité non corrigée dans une ancienne version de React est présente dans toutes les applications qui continuent de l'utiliser. Or, les logiciels open source qui ne bénéficient plus d'un support technique ne constituent pas seulement un risque pour la sécurité, mais aussi une lacune en matière de conformité que les auditeurs considèrent de plus en plus souvent comme un constat.

Les normes et réglementations, notamment SOC 2, PCI DSS v4.0, HIPAA, FedRAMP, DORA et la directive NIS2 de l’UE, exigent, directement ou par le biais de leurs dispositions en matière de gestion des risques, que les composants logiciels bénéficient d’un support actif et que les vulnérabilités connues soient corrigées dans des délais définis. Une nomenclature logicielle (SBOM) qui met en évidence une version obsolète de React comportant des CVE non corrigées déclenche des alertes lors des audits automatisés, et une anomalie non résolue, sans plan de correction, est difficile à justifier auprès d’un auditeur, lors d’un examen de sécurité par un client ou face à une autorité de régulation.

‍

HeroDevs NES pour React : combler le fossé

Le service « HeroDevs Never-Ending Support » offre un filet de sécurité pour les logiciels open source en fin de vie. Notre équipe surveille les nouvelles vulnérabilités (CVE) rendues publiques, recherche de manière proactive les failles dans les bases de code que nous prenons en charge, publie ses conclusions dans le répertoire des vulnérabilités HeroDevs et fournit des paquets corrigés via un registre privé sécurisé. En tant qu’autorité de numérotation CVE (CNA) agréée, HeroDevs identifie, résout et divulgue directement les vulnérabilités des logiciels open source.

NES for React étend ce modèle à l'écosystème React :

• Corrections CVE pour React 16.x et 17.x: correction des vulnérabilités de React et React-DOM, tous niveaux de gravité confondus, et pas uniquement les problèmes « critiques ».
• Engagements au titre du SLA: délais de correction contractuels fixés en fonction du niveau de gravité, remplaçant ainsi la bonne volonté de la communauté fondée sur le principe du « meilleur effort ».
• Installation « clé en main »: un simple changement de registre npm, sans modification du code ni refactorisation de l'application.
• Conformité : un fournisseur désigné, des accords de niveau de service (SLA) fermes et un historique documenté des correctifs, qui répondent aux conclusions des outils d'analyse et aux questions des auditeurs concernant les dépendances non prises en charge.

‍

Pourquoi la migration vers React 18 et 19 est-elle si difficile ?

La mise à niveau vers la dernière version de React reste la meilleure pratique à long terme, et NES constitue une passerelle vers cette modernisation, et non un substitut à celle-ci. Cependant, pour les applications d'entreprise, la mise à niveau est rarement immédiate :

• Changements de comportement: React 18 a introduit de nouveaux comportements de rendu, notamment des fonctionnalités simultanées et le regroupement automatique, qui peuvent modifier le comportement des composants existants. La migration en toute sécurité de bases de code volumineuses nécessite souvent plusieurs mois de développement et de tests d'assurance qualité.
• Dépendances de l'écosystème: les anciennes applications React dépendent souvent de bibliothèques de composants et d'outils de build qui ont leurs propres contraintes de mise à jour, et certaines ne disposent d'aucune voie de mise à jour directe.
• Coût et coût d'opportunité: d'après l'expérience de HeroDevs auprès d'équipes d'entreprise, la migration d'une seule base de code coûte généralement entre 50 000 et 250 000 dollars, avec 1 à 3 mois de tests de régression par application. Les organisations qui exploitent des dizaines, voire des centaines d'applications React ne peuvent pas toutes les migrer du jour au lendemain, et chaque sprint de migration mobilise des ressources qui ne peuvent alors plus être affectées à la feuille de route du produit.

NES for React permet de rattraper ce retard. Les équipes corrigent dès à présent les failles de sécurité et de conformité, puis organisent les migrations en fonction des priorités métier.

‍

Risques de sécurité liés à React Legacy

Avant la version 19, React affichait un nombre de CVE particulièrement faible, et il serait trompeur de laisser entendre le contraire. Puis, en décembre 2025, la vulnérabilité CVE-2025-55182, une faille critique (CVSS 10,0) permettant l’exécution de code à distance sans authentification dans les composants serveur de React 19, a donné lieu à des avis d’urgence de la part des principaux fournisseurs de cloud et de CDN, et a été inscrite sur la liste des vulnérabilités connues pour être exploitées de la CISA en moins de 48 heures, démontrant ainsi que même les écosystèmes front-end matures et soumis à une surveillance étroite peuvent présenter de graves vulnérabilités. Nous avons couvert cet incident et ce qu’il révèle sur les risques liés à l’open source dans l’article « Quand la foudre frappe deux fois : ce que la vulnérabilité RCE critique de React/Next.js révèle sur les risques liés à l’open source ». Parallèlement, la détection des vulnérabilités assistée par l’IA accélère le volume de divulgations dans l’ensemble du secteur : un nombre record de 48 185 CVE a été publié en 2025, soit une augmentation de 20,6 % par rapport à 2024, et d’autres sont en cours de découverte en 2026.

Un historique de sécurité sans incident ne garantit pas la sécurité future, surtout aujourd’hui avec les outils d’aide à la détection des vulnérabilités basés sur l’IA. Pour React 16 et 17, la question concrète est simple : lorsque la prochaine vulnérabilité affectant ces versions sera révélée, recevrez-vous un correctif ? Avec NES pour React, la réponse est oui : HeroDevs met à disposition un correctif dans les délais prévus par le contrat de niveau de service (SLA).

‍

Un seul fournisseur pour votre pile JavaScript

NES for React vient compléter le portefeuille JavaScript bien établi de HeroDevs, permettant ainsi aux entreprises de regrouper leurs environnements front-end et back-end existants sous un seul fournisseur, un seul contrat et un seul SLA. Si vos applications React fonctionnent sur des versions en fin de vie d’ Next.js, consultez notre guide complémentaire sur les dates de fin de vie d’Next.js et les calendriers de prise en charge des versions pour comprendre comment ces deux cycles de vie s’articulent.

‍

Passer à l'action

Si votre entreprise utilise React 16 ou React 17 en production et ne peut pas migrer immédiatement, la prochaine vulnérabilité CVE concernant React n’attendra pas votre plan de migration. Vous n’avez pas à choisir entre une migration imprévue et des vulnérabilités non corrigées. NES for React garantit la sécurité, la conformité et le bon fonctionnement de vos applications aussi longtemps que nécessaire, tout en vous permettant de les moderniser selon votre propre calendrier.

Contactez l'équipe HeroDevs pour sécuriser vos applications React, ou demandez un devis personnalisé afin de regrouper React avec Next.js, Node.js et Express dans un seul contrat.

‍

Questions fréquemment posées

1. Quelles versions de React sont prises en charge par NES for React ?

NES for React prend en charge React 16.x et 17.x, y compris les paquets react et react-dom. La couverture inclut la correction des vulnérabilités pour tous les niveaux de gravité CVE, dans le cadre de contrats SLA.

2. React a-t-il des dates officielles de fin de vie ?

Non. Le projet React ne publie pas de dates officielles de fin de vie (EOL) et ne dispose pas de programme de support à long terme (LTS). Le développement actif et les corrections concernent uniquement la dernière version majeure. Les versions plus anciennes peuvent bénéficier de corrections critiques à la discrétion de la communauté, mais il n'y a pas d'engagement officiel, ni de périmètre défini, ni de délai de réponse.

3. L'installation de NES pour React nécessitera-t-elle des modifications du code ?

Non. NES for React est un remplacement direct qui s'installe via votre workflow npm existant. Il vous suffit de configurer votre registre pour qu'il pointe vers le registre sécurisé de NES, de mettre à jour vos entrées de dépendances, puis d'exécuter la commande « npm install ». Le code de votre application, votre pipeline de compilation et vos tests restent inchangés.