[automated]: crowdin sync

apps/site/pages/fr/about/previous-releases.mdx

@@ -0,0 +1,51 @@
+---
+title: Versions de Node.js
+layout: about
+---
+
+# Versions de Node.js
+
+<EOLAlertBox />
+
+Les versions majeures de Node.js passent au statut de version _Current_ pendant six mois, ce qui donne aux auteurs de bibliothèques le temps de les prendre en charge.
+Après six mois, les versions impaires (9, 11, etc.) ne sont plus supportées, et les versions paires (10, 12, etc.) passent au statut _Active LTS_ et sont prêtes pour une utilisation générale.
+Le statut de la version _LTS_ correspond à un "support à long terme", qui garantit généralement que les bogues critiques seront corrigés pendant une durée totale de 30 mois.
+Les applications de production ne doivent utiliser que les versions _Active LTS_ ou _Maintenance LTS_.
+
+## Calendrier de version
+
+![Versions](https://raw.githubusercontent.com/nodejs/Release/main/schedule.svg?sanitize=true)
+
+Tous les détails concernant le calendrier des versions de Node.js sont disponibles [sur GitHub](https://github.com/nodejs/release#release-schedule).
+
+## Vous cherchez la dernière version d'une branche de version ?
+
+<PreviousReleasesTable />
+
+## Méthodes d'installation officielles ou communautaires
+
+Le site web de Node.js propose plusieurs méthodes d'installation non interactives, notamment des interfaces en ligne de commande (CLI), des gestionnaires de paquets de systèmes d'exploitation (par exemple, `brew`) et des gestionnaires de versions de Node.js (par exemple, `nvm`).
+
+Pour mettre en valeur et promouvoir les contributions de la communauté, le projet Node.js a introduit une page de téléchargement révisée classant les méthodes d'installation en deux catégories : "Officielle" et "Communautaire". Les utilisateurs bénéficient ainsi d'une plus grande flexibilité et d'un plus grand choix. Pour plus de clarté, nous avons défini des critères pour chaque catégorie.
+
+### Méthodes d'installation officielles
+
+Les méthodes d'installation désignées comme "Officielles" doivent satisfaire aux exigences suivantes :
+
+| Exigences (Méthodes d'installation officielles)                                                                                                                                     |
+| :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Les nouvelles versions de Node.js doivent être disponibles en même temps que la version officielle.                                                                                 |
+| Les responsables de projet doivent avoir une relation étroite avec le projet Node.js, y compris des canaux de communication directs.                                                |
+| La méthode d'installation doit télécharger les binaires officiels fournis par le projet Node.js.                                                                                    |
+| La méthode d'installation ne doit pas construire à partir des sources lorsque des binaires préconstruits sont disponibles, et ne doit pas non plus modifier les binaires officiels. |
+
+### Méthodes d'installation de la communauté
+
+Les méthodes d'installation communautaires incluses dans la page de téléchargement en libre-service (/download) doivent également respecter un ensemble minimum de critères :
+
+- _Prise en charge des versions :_\* Doit prendre en charge toutes les versions de Node.js actuellement prises en charge et qui ne sont pas en fin de vie.
+- **Compatibilité avec les systèmes d'exploitation :** Doit fonctionner sur au moins un système d'exploitation officiellement pris en charge.
+- **Prise en charge étendue du système d'exploitation :** Ne peut être limité à un sous-ensemble de distributions ou de versions du système d'exploitation.
+  - Par exemple, une méthode d'installation revendiquant la compatibilité avec "Windows" doit fonctionner sur "Windows 10", "Windows 11", et toutes leurs éditions (y compris les versions serveur).
+  - De même, une méthode d'installation revendiquant la compatibilité avec "Linux" doit pouvoir être installée sur toutes les distributions Linux majeures, et pas seulement sur un sous-ensemble spécifique. Elle ne peut pas s'appuyer sur des gestionnaires de paquets spécifiques à une distribution comme `apt` ou `dnf`.
+- **Libre et Open Source:** Doit être libre d'utilisation et open source, ne doit pas être vendu comme un produit commercial, et ne doit pas être un service payant.

apps/site/pages/fr/about/security-reporting.mdx

@@ -11,9 +11,10 @@ Pour plus de détails sur les politiques de sécurité active, consultez [cette
 
 Signalez les bogues de sécurité dans Node.js via [HackerOne](https://hackerone.com/nodejs).
 
-Vous recevrez un accusé de réception de votre rapport dans les 5 jours, et vous recevrez une réponse plus détaillée dans les 10 jours, indiquant les prochaines étapes.
-une réponse plus détaillée à votre rapport dans les 10 jours, indiquant les prochaines étapes du traitement de votre demande.
-traitement de votre demande.
+Normalement, votre signalement de bug sera pris en compte dans les 5 jours, et vous recevrez
+une réponse plus détaillée à votre soumission dans les 10 jours, indiquant les
+prochaines étapes du traitement de votre signalement. Ces délais peuvent être prolongés lorsque
+nos bénévoles chargés du triage sont en vacances, en particulier en fin d'année.
 
 Après la réponse initiale à votre rapport, l'équipe de sécurité s'efforcera de vous tenir informé des progrès réalisés en vue d'un correctif et d'une annonce complète.
 vous tenir informé des progrès réalisés en vue d'une correction et d'une annonce complète,
@@ -34,30 +35,25 @@ Les bogues de sécurité dans les modules tiers doivent être signalés à leurs
 
 Voici la politique de divulgation de la sécurité pour Node.js
 
-- Le rapport de sécurité est reçu et un gestionnaire principal lui est attribué. Cette personne
-  Cette personne coordonnera le processus de correction et de libération. Le problème est confirmé
-  et une liste de toutes les versions affectées est établie. Le code est audité pour trouver
-  tout problème similaire potentiel. Des correctifs sont préparés pour toutes les versions qui sont
-  toujours en cours de maintenance. Ces correctifs ne sont pas déposés dans le
-  mais sont plutôt conservés localement dans l'attente de l'annonce.
+- Le rapport de sécurité est reçu et attribué à un responsable principal. Cette
+  personne coordonnera le processus de correction et de publication. Le problème est validé
+  pour toutes les versions Node.js prises en charge. Une fois confirmé, une liste de toutes les versions concernées
+  est établie. Le code est audité afin de détecter tout problème similaire potentiel.
+  Des correctifs sont préparés pour toutes les versions prises en charge.
+  Ces correctifs ne sont pas enregistrés dans le référentiel public, mais conservés localement
+  en attendant l'annonce.
 
 - Une date d'embargo est proposée pour cette vulnérabilité et un CVE (Common Vulnerabilities and Exposures (CVE®)) est demandé pour cette vulnérabilité.
   Vulnérabilités et expositions communes (CVE®) est demandé pour la vulnérabilité.
 
-- À la date d'embargo, la liste de diffusion sur la sécurité de Node.js reçoit une copie de l'annonce.
-  annonce. Les changements sont poussés vers le dépôt public et de nouvelles versions
-  sont déployées sur nodejs.org. Dans les 6 heures suivant la notification de la liste de diffusion
-  une copie de l'avis sera publiée sur le blog de Node.js.
+- À la date d'embargo, une copie de l'annonce est envoyée à la liste de diffusion de sécurité Node.js.
+  Les modifications sont poussées vers le référentiel public et de nouvelles
+  versions sont déployées sur nodejs.org. Dans les 6 heures suivant la notification de la liste de diffusion, une copie de l'avis sera publiée sur le blog Node.js.
 
-- En règle générale, la date d'embargo est fixée à 72 heures à compter de l'émission du CVE.
-  est publié. Toutefois, cela peut varier en fonction de la gravité du bogue ou de la
-  de la difficulté à appliquer un correctif.
+- En règle générale, la date d'embargo est fixée à 72 heures à compter de la publication du CVE.
+  Toutefois, cela peut varier en fonction de la gravité du bug ou de la difficulté à appliquer un correctif.
 
-- Ce processus peut prendre un certain temps, en particulier lorsqu'une coordination est nécessaire avec les responsables d'autres projets.
-  avec les responsables d'autres projets. Tous les efforts seront faits pour traiter le
-  bogue le plus rapidement possible ; cependant, il est important que nous suivions la
-  processus de publication ci-dessus pour s'assurer que la divulgation est traitée de manière
-  de manière cohérente.
+- Ce processus peut prendre un certain temps, en particulier lorsque nous devons nous coordonner avec les responsables d'autres projets. Nous nous efforcerons de traiter le bogue aussi rapidement que possible ; toutefois, nous devons suivre le processus de publication ci-dessus afin de garantir une gestion cohérente de la divulgation.
 
 ## Recevoir les alertes de sécurité
 
@@ -68,9 +64,8 @@ Les notifications de sécurité seront diffusées par les méthodes suivantes.
 
 ## Commentaires sur cette politique
 
-Si vous avez des suggestions sur la façon dont ce processus pourrait être amélioré, veuillez soumettre une
-[pull request](https://github.com/nodejs/nodejs.org) ou
-[file an issue](https://github.com/nodejs/security-wg/issues/new) pour en discuter.
+Si vous avez des suggestions pour améliorer ce processus, veuillez consulter
+le référentiel [nodejs/security-wg](https://github.com/nodejs/security-wg).
 
 ## OpenSSF Best Practices
 
@@ -85,4 +80,4 @@ Si vous avez des suggestions sur la façon dont ce processus pourrait être amé
   />
 </a>
 
-Le badge des meilleures pratiques de l'Open Source Security Foundation (OpenSSF) (https://github.com/coreinfrastructure/best-practices-badge) est un moyen pour les projets de logiciels libres et open source (FLOSS) de montrer qu'ils suivent les meilleures pratiques. Les projets peuvent volontairement auto-certifier la manière dont ils suivent chaque meilleure pratique. Les utilisateurs du badge peuvent rapidement déterminer quels sont les projets FLOSS qui suivent les meilleures pratiques et qui sont donc plus susceptibles de produire des logiciels sécurisés de meilleure qualité.
+Le [badge des meilleures pratiques] de l'Open Source Security Foundation (OpenSSF) (https://github.com/coreinfrastructure/best-practices-badge) est un moyen pour les projets de logiciels libres et open source (FLOSS) de montrer qu'ils suivent les meilleures pratiques. Les projets peuvent volontairement auto-certifier la manière dont ils suivent chaque meilleure pratique. Les utilisateurs du badge peuvent rapidement déterminer quels sont les projets FLOSS qui suivent les meilleures pratiques et qui sont donc plus susceptibles de produire des logiciels sécurisés de meilleure qualité.

apps/site/pages/fr/eol.mdx

@@ -0,0 +1,45 @@
+---
+title: Fin de vie (EOL)
+layout: article
+---
+
+# Fin de vie (EOL)
+
+## Pourquoi et comment les versions de Node.js arrivent en fin de vie
+
+Les versions majeures de Node.js sont publiées, corrigées et déclarées en fin de vie selon un calendrier prévisible. Comme il n'est pas possible de maintenir toutes les versions à perpétuité, après une période de maintenance planifiée, une version majeure de Node.js ne sera plus prise en charge par le projet.
+
+<div className="flex flex-col items-start gap-4 xl:flex-row xl:items-center">
+  <Button kind="primary" href="/download" className="flex-1">
+    <span>Mettez à niveau vers la dernière version LTS de Node.js®.</span>
+  </Button>
+
+<span>ou</span>
+
+  <Button as="a" kind="warning" href="/esp/herodevs" className="flex-1">
+    <span>Obtenez une assistance en matière de sécurité pour les versions en fin de vie (EOL)</span>
+  </Button>
+</div>
+
+[Consultez le calendrier des versions de Node.js](/about/releases/).
+
+## Que se passe-t-il lorsqu'une ligne de versions arrive en fin de vie ?
+
+Lorsqu'une version arrive en fin de vie, cela signifie qu'elle ne recevra plus de mises à jour, y compris les correctifs de sécurité. Cela peut rendre les applications fonctionnant sur ces versions vulnérables à des problèmes de sécurité et à des bogues qui ne seront jamais corrigés.
+
+- **Plus aucune correction de vulnérabilité** : lorsque de nouvelles versions de sécurité révèlent des problèmes et des correctifs dans les versions majeures plus récentes, même si la même vulnérabilité affecte les versions en fin de vie (EOL), aucune nouvelle version ne sera publiée pour celles-ci. Les utilisateurs qui continuent à utiliser les versions EOL et les chemins d'accès au code affectés seront immédiatement exposés aux attaques exploitant ces vulnérabilités divulguées.
+- **Rupture de la chaîne d'outils** : les versions en fin de vie (EOL) peuvent ne plus être liées dynamiquement aux versions plus récentes des bibliothèques partagées dont elles dépendent, ce qui bloque ou interrompt les mises à jour du système.
+- **Dérive de l'écosystème** : de nombreux paquets populaires destinés aux utilisateurs cessent progressivement de prendre en charge les versions EOL de Node.js. Lorsqu'une application continue d'utiliser des paquets obsolètes, elle peut souffrir d'un nombre encore plus important de vulnérabilités et de bogues non corrigés, s'éloignant ainsi davantage de la norme de l'écosystème.
+- **Signaux d'alerte en matière de conformité** : de nombreux audits sectoriels interdisent les environnements d'exécution non maintenus.
+
+## Versions en fin de vie
+
+<EOLReleaseTable />
+
+## Support Commercial
+
+Malgré les inconvénients évidents liés à l'utilisation des versions en fin de vie, dans la pratique, les organisations sont confrontées à des contraintes qui les empêchent de procéder à des mises à niveau immédiates, telles que les bases de code héritées, les exigences de conformité ou les chaînes de dépendances complexes. Pour les utilisateurs qui ne peuvent pas procéder à une mise à niveau immédiate mais qui ont besoin d'une assistance continue en matière de sécurité pour les versions en fin de vie de Node.js, une assistance commerciale est disponible dans le cadre du partenariat [OpenJS Ecosystem Sustainability Program](https://openjsf.org/blog/ecosystem-sustainability-program).
+
+Node.js s'est associé à HeroDevs pour fournir une assistance permanente (NES) pour les versions de Node.js qui ont dépassé leur phase de maintenance officielle. Cela comprend des correctifs de sécurité, une aide à la conformité et une assistance technique pour vous aider à combler le fossé pendant que vous planifiez votre stratégie de mise à niveau. Pour plus d'informations, consultez la [**page HeroDevs Node.js NES**](https://nodejs.org/esp/herodevs).
+
+L'utilisation des versions EOL(fin de vie) via NES doit être considérée comme une solution temporaire. L'objectif doit toujours être de passer à des versions activement prises en charge.

apps/site/pages/fr/index.mdx

@@ -19,12 +19,12 @@ layout: home
 
       <Button kind="primary" className="!block dark:!hidden" href="/download">Obtenir Node.js®</Button>
 
-      <Button kind="secondary" className="!block" href="/blog/announcements/node-18-eol-support">
+      <Button kind="secondary" className="!block" href="/eol">
         <span>Obtenir une aide à la sécurité</span>
 
         <br />
 
-        <small className="!text-xs">pour Node.js 18 et moins</small>
+        <small className="!text-xs">pour les versions Node.js en fin de vie</small>
       </Button>
     </div>