Fin de vie

Une version que l’éditeur ne corrige plus n’aura jamais de CVE pour vous prévenir : sa fin de vie est son échéance. TechWatchAlert tient un catalogue des calendriers de fin de support et de fin de vie des produits courants (source : endoflife.date) et vous aide à suivre ceux de la stack du projet.

Deux écrans s’en occupent :

• Surveillance › Fin de vie : le catalogue, les versions de la stack du projet, et les abonnements qui préviennent avant une échéance ou à la sortie d’une nouvelle version ;
• Conformité NIS2 › Échéances, vue Fin de vie : pour les projets sous NIS2, les versions de la stack hors support ou bientôt hors support, et leur plan de sortie.

La page Fin de vie

L’écran s’ouvre par Surveillance › Fin de vie. Le nom du projet actif est rappelé à côté du titre Fin de vie (EOL).

En haut, la barre de filtres, la même que sur les pages CVE et Alertes (voir Chercher et filtrer) :

1. la recherche d’un produit, le périmètre (Ma stack, Suivis, Tout le catalogue), les Vues rapides et le tri ;
2. les statuts, avec le nombre de versions de chacun, puis LTS, Sécurité seulement et l’échéance ;
3. le nombre de produits et de versions trouvés, les puces des filtres actifs et Tout effacer.

Dessous, le tableau des produits : un clic sur une ligne de produit la déplie ou la replie, le badge STACK signale un produit de la stack du projet, et la cloche de la colonne Suivi abonne le projet.

Produits et versions

Le tableau est groupé par produit ; la pagination porte sur les produits (Lignes par page : 25 ou 50, en bas à droite).

Sur la ligne de produit :

Colonne	Contenu
Produit	Nom, identifiant du catalogue (postgresql, django…), badge STACK.
Version / Cycle	Nombre de versions du produit.
Dernière version	Dernière version publiée de la branche la plus récente, avec le nom de cette branche dessous.
Date de sortie, Fin de support	Celles de la branche la plus récente.
Fin de vie (EOL)	La fin de vie la plus proche parmi les versions du produit : en rouge si elle est passée, en ambre si elle tombe dans les 180 jours.
Statut	Résumé : Support Actif si au moins une version est supportée, sinon Bientôt obsolète si l’une approche de sa fin, sinon Obsolète si toutes sont dépassées, sinon Sans date. Au survol : la répartition par statut.
Suivi	Cloche Suivre les nouvelles versions.

Sur une ligne de version, dépliée sous son produit : la dernière version publiée du cycle, le cycle (badge LTS pour une version à support long), ses dates, la fin de vie avec « dans N j » (dans l’année qui vient) ou « il y a N j », le statut de la version et la cloche Suivre (fin de vie / support). Les versions sont rangées de la plus récente à la plus ancienne.

Les statuts d’une version :

Statut	Règle
Obsolète	La fin de vie est passée, ou l’éditeur l’a déclarée sans date.
Bientôt obsolète	La fin de vie tombe dans les 180 jours.
Support Actif	La fin de vie est plus lointaine.
Sans date	Le catalogue ne connaît pas de date de fin de vie.

Chercher et filtrer

Chercher

Le champ Rechercher un produit filtre sur le nom ou l’identifiant du catalogue (« postgres » trouve PostgreSQL). La liste suit la frappe après une courte pause ; Entrée applique la recherche tout de suite, Échap vide le champ, et la touche / y place le curseur depuis n’importe où dans la page. Un produit que la recherche désigne exactement (« postgresql », « PHP ») se déplie de lui-même.

Filtrer

Les filtres s’appliquent aussitôt et se cumulent ; tout changement de filtre revient à la première page.

• Périmètre, à droite de la recherche : Tout le catalogue (par défaut) montre tous les produits connus ; Ma stack ne garde que les produits de la stack du projet actif ; Suivis, ceux pour lesquels le projet a au moins un abonnement (produit ou version). Pour Ma stack, le rapprochement se fait sur le nom exact : l’élément de stack doit porter l’identifiant du catalogue (postgresql, nginx, php…). Sans projet actif, le périmètre n’apparaît pas et la page montre tout le catalogue.
• Statut : Obsolète, Bientôt obsolète, Support Actif, Sans date, cumulables. Chacun affiche son nombre de versions, compté avec la recherche, le périmètre et les autres filtres, mais sans le filtre de statut : on lit ce qu’un clic donnerait.
• LTS : les versions à support long de l’éditeur.
• Sécurité seulement : le support actif est terminé mais la fin de vie n’est pas atteinte ; l’éditeur ne publie plus que des correctifs de sécurité. C’est le moment de planifier la montée de version.
• Échéance : Toute échéance (par défaut), ou une fin de vie qui tombe d’ici 30 jours, 90 jours, 12 mois ou 2 ans, à partir d’aujourd’hui. Les versions déjà en fin de vie n’en font pas partie : le statut Obsolète les montre.

Le détail de LTS et de Sécurité seulement s’affiche au survol de leur bouton. Cette page n’a pas de panneau « Filtres avancés » : tous ses filtres sont dans la barre.

Vues rapides

Vues rapides, à droite du périmètre, pose en un clic une combinaison courante :

• Ma stack hors support : Ma stack, statut Obsolète ;
• Ma stack : bientôt obsolète : Ma stack, statut Bientôt obsolète ;
• Suivis : fin de vie sous 90 jours : Suivis, échéance 90 jours ;
• Sécurité seulement ;
• Versions LTS supportées : LTS, statut Support Actif.

Les trois premières demandent un projet actif. Une vue remplace la recherche et les filtres posés ; l’ordre et le nombre de lignes par page restent. Quand les filtres reproduisent exactement une vue, le bouton affiche son nom.

Filtres actifs

Sous la barre, une ligne donne le nombre de produits et de versions trouvés (« 8 produits · 16 versions »), puis une puce par filtre posé : « Périmètre : Ma stack », « Obsolète », « LTS », « Fin de vie sous 90 jours »… La croix d’une puce retire son filtre. Tout effacer retire la recherche et tous les filtres, périmètre compris, en gardant l’ordre et le nombre de lignes par page.

Trier

Le tri, à droite des vues rapides : Produit (ordre alphabétique, par défaut) ou Échéance, qui range les produits selon la fin de vie la plus proche parmi leurs versions retenues, les plus anciennes d’abord ; les produits sans date viennent en dernier.

Partager une liste filtrée

La recherche, les filtres, l’ordre, la page et le nombre de lignes par page s’inscrivent dans l’adresse de la page, sans entrée d’historique à chaque clic : un lien copié rouvre exactement la même liste. Seuls les écarts au réglage par défaut y figurent.

Paramètre	Sens
q	recherche (product est lu de la même façon)
scope	périmètre : stack ou followed (absent : tout le catalogue)
status=eol,ending_soon	statuts (eol, ending_soon, active, unknown)
lts=1, securite=1	LTS, sécurité seulement
echeance	échéance : 30j, 90j, 1a (12 mois) ou 2a (2 ans)
sort=eol	tri par échéance (absent : Produit)
page, page_size	page, lignes par page (25 ou 50)

Les liens de l’application en profitent : le compteur EOL < 30 jours du tableau de bord ouvre la page sur Suivis, échéance 30 jours ; une ligne du widget des échéances, d’un e-mail de fin de vie ou d’une fiche produit de la Vigie ouvre le produit concerné, déplié. Un lien reçu par e-mail active aussi le projet de l’avis.

Sur téléphone

La recherche occupe toute la largeur ; dessous, une barre d’outils reste visible au défilement : Filtres (avec le nombre de filtres posés), Tri et la plage affichée (« 1–25 sur 44 »). Les puces des filtres actifs défilent en une rangée, suivie de Tout effacer. Filtres ouvre une feuille avec les vues rapides, le périmètre, les statuts, LTS, Sécurité seulement et l’échéance ; les filtres s’appliquent aussitôt, et le bouton du bas annonce le nombre de produits obtenus.

S’abonner : versions et nouvelles versions

Deux abonnements, deux usages :

Une version

La cloche d’une ligne de version : « préviens-moi avant la fin de support et avant la fin de vie de PostgreSQL 15 ». À suivre pour chaque version que vous faites tourner.

Le produit

La cloche d’une ligne de produit : « préviens-moi quand une nouvelle version de Django sort ». Utile pour préparer les montées de version.

Un clic sur la cloche abonne le projet ; la cloche devient pleine et encadrée. Un second clic désabonne. Une version déjà obsolète reste suivable : sa fin de support peut être encore à venir. Sans projet actif, les cloches sont désactivées (« Sélectionnez un projet pour activer les abonnements EOL »).

Les abonnements appartiennent au projet : tous ses membres les voient. Ils peuvent aussi être créés au moment d’ajouter un produit à la stack, par la fenêtre Suivre les fins de vie ? (voir Stack).

Quand êtes-vous prévenu ?

Une vérification tourne toutes les heures :

• abonnement à une version : avant la fin de vie, puis avant la fin du support actif, une seule fois chacune. Le délai est celui de l’abonnement s’il en fixe un, sinon celui du projet (réglages du projet, onglet Général, carte Notifications de l’équipe : Prévenir avant la fin du support et Prévenir avant la fin de vie, de 1 à 365 jours, communs à toute l’équipe et modifiables avec le droit « Modifier un abonnement EOL »), sinon 60 jours. Si la date de fin change dans le catalogue, ou si le délai change, l’avis repart pour la nouvelle échéance ;
• abonnement à un produit : dès qu’une version absente du catalogue au moment de l’abonnement apparaît.

La notification passe par les workflows du projet, créés avec lui : Workflow par défaut fins de vie (fin de vie qui approche), Fin de support actif et Nouvelles versions, qui envoient une notification dans l’application à chaque membre du projet. Un workflow désactivé ne prévient personne ; voir Workflows.

S'abonner tôt

L’avis part quand l’échéance est dans le délai (60 jours ou moins par défaut). Un abonnement créé alors que la date est déjà passée déclenche donc un avis dès la vérification suivante, une seule fois. Tant qu’aucun workflow actif ne traite l’événement, rien n’est marqué comme envoyé : l’avis partira dès qu’un workflow l’écoutera.

Fin de vie dans l’espace NIS2 : la vue Échéances

Pour les projets où NIS2 est activée, Conformité NIS2 › Échéances, vue Fin de vie, traite les versions hors support comme des échéances de correction : un état, un délai, une escalade, un responsable. Le chiffre sur l’onglet Fin de vie compte les composants hors support (dépassés et escaladés).

1. Vulnérabilités / Fin de vie : les deux vues de la page Échéances (la première est décrite dans Registres NIS2).
2. Indicateurs par état ; un clic filtre la liste sur cet état, un second clic retire le filtre. Sous Fin de vie sous 180 j, le nombre de composants sans plan de sortie.
3. Projet : tous les projets, ou un seul.
4. Comment l’échéance est-elle calculée ?
5. Catalogue des fins de vie : ouvre la page Fin de vie.
6. Un composant : produit, cycle, versions en service, projet, dernière version du cycle.
7. Planifier : ouvre le plan de sortie.

Quels composants ?

Un composant est un couple produit-cycle d’un projet, déduit à chaque affichage :

• des stacks du projet (celles de tous ses membres) : un élément de type produit dont le nom est un identifiant du catalogue, rattaché à son cycle par sa version (« 1.1.1t » appartient au cycle « 1.1.1 », « 8.9p1 » au cycle « 8.9 », mais « 3.12 » n’appartient pas à « 3.1 ») ;
• des abonnements à une version du projet.

Un élément de stack sans version, ou dont la version ne correspond à aucun cycle, ne peut pas être jugé : il est compté, et un bandeau le signale (« … n’ont pas de version exploitable ») avec un lien Compléter la stack. Une version sans date de fin de vie connue n’apparaît pas.

Les états

État	Règle
Supporté	Fin de vie à plus de 180 jours.
Fin de vie proche	Fin de vie dans les 180 jours : c’est le moment de planifier.
Sortie planifiée	Fin de vie passée, mais un plan de sortie daté dans le futur couvre le composant.
Hors support	Fin de vie passée (ou plan de sortie lui-même dépassé).
Escaladé	Hors support depuis plus que le délai d’escalade de la politique de correction du projet.

La colonne Reste donne l’écart en jours : J-47 signifie 47 jours avant la fin de vie, J+19 19 jours de retard. La liste est triée par état (escaladés d’abord), puis par écart, puis par criticité. La Criticité est la plus haute des éléments de stack concernés, à défaut celle du projet.

Planifier la sortie

Un clic sur une ligne (ou sur Planifier) ouvre le panneau du composant :

• Calendrier de l’éditeur : fin de vie, fin du support actif, dernière version du cycle et source (Note de l’éditeur quand un lien existe, sinon endoflife.date) ;
• Plan de sortie : quand cette version sera remplacée, par qui et comment.

1. Choisissez la date Sortie prévue le (au plus tôt aujourd’hui), ou un raccourci 1 mois, 3 mois, 6 mois. Le texte dessous dit dans combien de jours, et ce que la date implique : remplacement avant la fin de vie, période hors support couverte par le plan, ou suspension du retard pour un composant déjà hors support.
2. Choisissez le Porteur, un membre du projet, prévenu si la date est dépassée.
3. Ajoutez une Note (2 000 caractères au plus), par exemple la version cible et les tests prévus.
4. Cliquez sur Enregistrer le plan.

Effacer le plan supprime la date, le porteur et la note. Le panneau indique qui a modifié le plan en dernier, et quand.

Un plan daté après la fin de vie repousse l’échéance jusqu’à sa date : le composant passe en Sortie planifiée et n’est plus compté en retard. La date passée, il redevient Hors support et l’escalade reprend. Un plan daté avant la fin de vie n’avance pas l’échéance. Chaque plan est journalisé et figure dans le rapport à la direction.

Avis automatiques

• Un composant qui passe hors support est annoncé au porteur de son plan s’il est membre du projet, sinon aux administrateurs et au propriétaire du projet.
• Un composant escaladé est annoncé au responsable de la sécurité (fonction RSSI).
• Les avis sont regroupés par projet (« 3 composants hors support — … »), envoyés une fois par étape ; un plan de sortie qui glisse réarme l’étape. Il n’y a pas d’avis « fin de vie proche » ici : les abonnements de la page Fin de vie s’en chargent.

Dans la posture NIS2

La vue d’ensemble de Conformité NIS2 a un bloc Fin de vie (« Les versions que l’éditeur ne corrige plus sont remplacées selon un plan daté. ») : en retard s’il y a des composants hors support ou escaladés, à faire s’il y a des fins de vie proches sans plan, sinon conforme. Ses actions mènent aux filtres correspondants de cette vue, et à la stack pour les versions à renseigner. Les composants hors support ou proches figurent en annexe du rapport à la direction.

Qui peut faire quoi

Action	Utilisateur	Analyste	Admin	Propriétaire
Consulter la page Fin de vie	✓	✓	✓	✓
S’abonner (cloche)		✓	✓	✓
Se désabonner		✓	✓	✓
Régler les délais de prévenance du projet (carte Notifications de l’équipe)		✓	✓	✓

Ce sont les droits par défaut ; ils se règlent membre par membre ou par groupe (droits « S’abonner aux EOL », « Se désabonner d’un EOL » et « Modifier un abonnement EOL »), et le serveur applique le résultat.

Dans la vue Fin de vie des Échéances, la lecture suit l’accès à l’espace NIS2, et planifier une sortie demande le droit Attester une revue d’inventaire (accordé par défaut aux Analystes, Admin et au Propriétaire du projet).

Dans la vue Échéances, chaque ligne sait si vous pouvez planifier : sans le droit, le panneau montre le plan en lecture seule, ou « Aucun plan de sortie. Il se planifie par un membre du projet autorisé à attester les revues d’inventaire. ». Les propriétaires et administrateurs de l’organisation et les titulaires d’une fonction NIS2 voient tous les projets sous NIS2 de l’organisation.

Ce qui dépend de l’offre

• La page Fin de vie doit être comprise dans l’offre ; sinon son entrée de menu est verrouillée.
• Le nombre d’abonnements est plafonné pour toute l’organisation. Avec les réglages par défaut de l’instance : 5 en Free, 50 en Team, illimité en Pro et Business. Au-delà, le choix des offres s’ouvre.
• La vue Fin de vie des Échéances demande l’espace conformité NIS2 et son module Échéances (offres Pro et Business), et un projet où NIS2 est activée.

Questions fréquentes

Mon produit est dans la stack, mais « Ma stack » ne le montre pas. Le rapprochement se fait sur l’identifiant exact du catalogue. Un élément nommé autrement (par exemple node.js au lieu de nodejs) n’est pas reconnu. Abonnez-vous alors à la version depuis Tout le catalogue : l’abonnement compte aussi dans la vue Échéances.

Pourquoi ma version n’apparaît-elle pas dans les Échéances ? Il faut une version dans la stack (ou un abonnement à la version), un cycle correspondant au catalogue, une date de fin de vie connue, et NIS2 activée pour le projet.

StackRenseigner les versions exactes.

Registres NIS2Échéances de correction, revues d'inventaire.

WorkflowsLes notifications de fin de vie.

GET …/eol (API)Lire les abonnements par l'API.