---
title: "Cycle de vie : les fins de support de vos composants"
description: "La puce « Support » dit où en est chaque composant de ses correctifs de sécurité — distribution, bases, images, dépendances, exigences des stores — sur une échelle distincte des failles."
lang: fr
canonical: "https://www.stathall.com/docs/cycle-de-vie/"
updated: "2026-09-30"
---

# Cycle de vie : les fins de support de vos composants


## Une échéance, pas une faille

Une **faille** est un défaut connu qu'un correctif répare. Une **fin de support**
est une date : passé ce jour, l'éditeur ne publie plus de correctif de sécurité.
Les failles à venir ne seront donc plus corrigées. C'est grave, mais ça se
**planifie** : une montée de version majeure ne se fait pas dans l'heure.

StatHall suit les deux sur deux échelles séparées. Une fin de support n'est
jamais une alerte critique : elle ne compte pas sur la pastille de l'icône du
téléphone, et elle ne vous réveille pas la nuit.

## Ce qui est daté

| Composant | D'où vient la version |
| --- | --- |
| **Distribution** (Debian, Ubuntu, RHEL, Alpine…) | l'agent StatHall |
| **Paquets d'un dépôt tiers** (PostgreSQL du dépôt PGDG, Node.js de NodeSource, PHP de sury, Docker…) | l'inventaire de l'agent, avec l'origine de chaque paquet (agent 1.3.16 ou plus) |
| **Images Docker en service** (`postgres:13`, `node:20`, `redis:7`…) | la photo des conteneurs prise par l'agent |
| **Langage et framework d'une image construite sur votre machine** (PHP, Node.js, Python, Go, Ruby ; Laravel, Symfony, Drupal, CakePHP) | la photo des conteneurs : la version du langage héritée de l'image de base, et le `composer.lock` du dossier de travail du conteneur (agent 1.3.19 ou plus) |
| **Frameworks et bibliothèques** (Django, React, Angular, Spring…) | les SBOM poussées par votre CI |
| **Exigences des stores** (targetSdk Google Play, SDK iOS) | la configuration de l'application, à renseigner |
| **Agent StatHall** | la version rapportée par l'agent |
| **Base d'un projet Supabase** | le connecteur Supabase |

Les dates viennent du calendrier public [endoflife.date](https://endoflife.date),
synchronisé chaque jour. Le cockpit télécharge le calendrier entier : aucune
information sur votre parc ne lui est envoyée.

### Pourquoi un paquet de la distribution n'est pas daté

Un paquet fourni par votre distribution **suit la distribution**. Debian corrige
son `python3` jusqu'à la fin de Debian, même quand python.org a abandonné cette
version. Seul un paquet venu d'un dépôt tiers suit le calendrier de son éditeur.

### Le support étendu

Si un support étendu est actif (Ubuntu Pro ESM, Debian ELTS), l'échéance de la
distribution devient celle du support étendu. StatHall le détecte à l'origine des
paquets installés, sans rien configurer.

## Les niveaux de la puce

| Niveau | Quand | Alerte |
| --- | --- | --- |
| **Supporté** | échéance lointaine, ou pas encore annoncée | — |
| **Fin annoncée** | moins de 12 mois (distribution, base) ou 6 mois (le reste) | — |
| **À planifier** | moins de 6 mois (distribution, base) ou 3 mois | P2 |
| **Imminent** | moins de 3 mois (distribution, base) ou 1 mois | P2 |
| **Hors support** | échéance passée depuis moins de 6 mois | P1 |
| **Hors support de longue date** | de 6 à 18 mois après | P1 |
| **Abandonné** | plus de 18 mois après | P1 |
| **Non couvert** | date inconnue | — |

Une migration de distribution ou de base de données se prépare plus tôt qu'une
montée de bibliothèque : c'est pourquoi les seuils d'avant l'échéance sont plus
larges pour elles.

**Non couvert** veut dire que StatHall ne sait pas dater le composant : une image
construite sur votre machine dont rien ne dit ce qu'elle contient, un produit
sans calendrier public, une version illisible, ou des exigences de store pas
encore renseignées. Ce n'est jamais présenté comme « à jour » : une cible dont
un composant n'est pas couvert voit son score de santé plafonné à 90, et la
carte dit lequel.

## Où la voir

- **Liste des cibles, vue d'ensemble, en-tête d'une cible** : la puce donne le
  composant le plus en retard.
- **Onglet Sécurité d'un serveur** : la section « Cycle de vie » liste tous ses
  composants, datés ou non.
- **Écran Cycle de vie** : toutes les échéances du parc, triées par gravité puis
  par date, filtrables par niveau et par origine.
- **Boîte de réception** : une seule alerte « Fin de support » par cible, qui
  nomme le composant le plus en retard et liste les autres.
- **Téléphone** : la même puce sur vos cibles, et le même écran Cycle de vie.

## Les notifications

L'alerte s'ouvre en **P2** quand une échéance approche, et passe en **P1** le jour
où un composant sort du support. C'est à ce moment qu'elle vous notifie. Un
passage d'un niveau à l'autre à l'intérieur de la même gravité n'envoie rien : la
puce et la boîte de réception suffisent.

Si vous prenez l'alerte en charge (« Je m'en occupe ») ou la fermez, elle reste fermée jusqu'au prochain
changement de niveau : pas de rappel quotidien pour un chantier que vous
connaissez. Dès que le composant est monté de version, l'alerte se ferme d'elle-même.

## Les applications : exigences des stores

Google Play refuse une mise à jour dont le **targetSdk** est trop ancien. L'App
Store refuse un binaire construit avec un **SDK iOS** dépassé. Aucune de leurs API
ne donne ces valeurs : renseignez-les dans la configuration de l'application,
onglet **Général** (la carte « Support » de son tableau de bord y mène quand elles
manquent). StatHall vous prévient avant l'échéance publiée par chaque store.