Ce qui tombe entre novembre 2026 et fin 2027
Huit échéances structurent le calendrier d'un parc de sites clients. Deux sont déjà passées : Node.js 20 (30 avril 2026) et Debian 11 LTS (31 août 2026). Elles ne se planifient plus, elles se rattrapent. Quatre tombent dans les douze mois : PostgreSQL 14, PHP 8.2, Node.js 22 et Ubuntu 22.04. Deux closent l'année 2027 : PostgreSQL 15 et PHP 8.3.
Le tableau ci-dessous les range par date, avec la source primaire et l'action à inscrire au plan. Une règle de lecture : la date est celle que publie l'éditeur, au jour près quand il la donne, au mois quand il ne publie que le mois. Rien n'y est tiré d'un site tiers sans confirmation à la source. Pour le détail d'une migration, suivez le guide indiqué dans la première colonne : cet article ordonne, il ne refait pas les tutoriels.
Calendrier des fins de vie, par ordre de date
Faites défiler le tableau
| Composant et guide détaillé | Fin de support et source | Action à planifier |
|---|---|---|
| Node.js 20 — guide : Node.js 20 en fin de vie, migrer votre VPS | 30 avril 2026, échu — dépôt nodejs/Release, schedule.json | Dette : migrer vers Node.js 22 ou 24 sans attendre |
| Debian 11 — guide : Debian 11 en fin de vie, Plesk, dist-upgrade ou migration | 31 août 2026, échu — wiki.debian.org/LTS | Dette : dist-upgrade vers Debian 13 ou migration |
| PostgreSQL 14 — guide : PostgreSQL en fin de vie, planifier la montée de version | 12 novembre 2026, dernière version — postgresql.org/support/versioning | Dump et restauration ou pg_upgrade vers une majeure supportée |
| PHP 8.2 — guide : PHP 8.2 fin de vie, checklist de migration | 31 décembre 2026, support de sécurité — php.net/supported-versions | Passer en PHP 8.4 sur tous les sites, PHP 8.3 s'éteignant un an plus tard |
| Node.js 22 | 30 avril 2027 — dépôt nodejs/Release, schedule.json | Passer en Node.js 24, supporté jusqu'au 30 avril 2028 |
| Ubuntu 22.04 LTS — procédure : Ubuntu 24.04 vers 26.04, do-release-upgrade | mai 2027, maintenance de sécurité standard — ubuntu.com/about/release-cycle | Monter vers Ubuntu 24.04 avant le début du mois |
| PostgreSQL 15 | 11 novembre 2027, dernière version — postgresql.org/support/versioning | Prévoir la majeure suivante, PostgreSQL 16 allant jusqu'au 9 novembre 2028 |
| PHP 8.3 | 31 décembre 2027, support de sécurité — php.net/supported-versions | Rien à faire pour les sites déjà en PHP 8.4 (sécurité jusqu'au 31 décembre 2028) ; les autres y passent |
Support actif, support de sécurité, dernière version : trois sens du mot fin
Les éditeurs ne parlent pas tous de la même fin. PHP distingue deux phases : le support actif, qui apporte corrections de bogues et de sécurité, puis le support de sécurité, qui ne livre plus que les correctifs critiques. PHP 8.2 a quitté le support actif le 31 décembre 2024, PHP 8.3 le 31 décembre 2025. Les dates du tableau sont donc celles du support de sécurité : 31 décembre 2026 pour PHP 8.2, 31 décembre 2027 pour PHP 8.3. PHP 8.4 reste en support actif jusqu'au 31 décembre 2026 et en sécurité jusqu'au 31 décembre 2028.
PostgreSQL parle de dernière version : passé la date, plus aucune version mineure ne sort pour cette majeure. Node.js parle de fin de vie de la ligne, Debian et Ubuntu de fin de maintenance de sécurité standard. Dans tous les cas, après la date, une faille découverte n'est plus corrigée par le support standard de l'éditeur : c'est cette date, et non l'arrêt du site, qui définit le risque.
Comment ordonner le parc : six règles de priorité
- Les dettes d'abord — Node.js 20 et Debian 11 ont dépassé leur date de fin ; ils passent avant toute échéance à venir, même si le site ne montre aucun symptôme.
- Ensuite, la date la plus proche — l'ordre du tableau est l'ordre de travail, sauf contrainte client contraire.
- Le chantier le plus long avant le plus court — une majeure PostgreSQL exige une restauration testée ; un changement de version PHP se valide site par site. Le premier se lance plus tôt.
- Le système porte le reste — la version de Debian ou d'Ubuntu conditionne souvent les versions de PHP et de bases proposées par ses dépôts ; la montée du système se planifie avec elles.
- Le client à plusieurs échéances passe en premier — un site qui cumule PHP 8.2, Node.js 20 et PostgreSQL 14 coûte trois interventions s'il est traité composant par composant, une seule s'il est traité par fenêtre.
- La date incertaine se traite à son début — quand l'éditeur ne publie que le mois, on planifie avant le mois, pas au dernier jour.
Les dettes déjà échues : Node.js 20 et Debian 11
Deux lignes du tableau ne sont plus des prévisions. Node.js 20 a atteint sa fin le 30 avril 2026, Debian 11 la fin de son support LTS le 31 août 2026. L'erreur classique consiste à les inscrire au budget de l'année suivante alors qu'elles sont déjà hors support. Une dette se chiffre et se rembourse ; elle ne se planifie pas au rythme d'une fin de vie future.
Pour Node.js, la cible est la ligne 22 ou la ligne 24. La 22 se termine le 30 avril 2027 et la 24 le 30 avril 2028 : choisir la 24 évite de revenir sur le même chantier dans six mois. Pour Debian, la cible est Debian 13, dont le support LTS s'achève le 30 juin 2030. Debian 12 n'est qu'une étape : son support LTS court du 11 juin 2026 au 30 juin 2028. Les procédures complètes sont dans nos guides sur Node.js 20 et sur Debian 11 ; elles ne sont pas refaites ici.
PostgreSQL : l'échéance qui ne se rattrape pas en place
PostgreSQL 14 publie sa dernière version le 12 novembre 2026, PostgreSQL 15 le 11 novembre 2027 et PostgreSQL 16 le 9 novembre 2028. Le rythme est annuel, et c'est la seule famille du tableau où changer de version n'est pas une simple mise à jour : une majeure ne s'installe pas par-dessus la précédente, car le format de stockage change d'une majeure à l'autre.
Il reste deux voies : la sauvegarde logique restaurée dans la nouvelle version (pg_dump puis pg_restore), ou pg_upgrade, qui convertit le répertoire de données. Dans les deux cas, prévoyez un arrêt proportionnel à la taille de la base et une restauration testée avant la bascule. Pour un parc, cela place PostgreSQL en tête de file dès que sa date approche, même quand le site qui l'utilise est simple. Les deux méthodes sont détaillées dans notre guide sur la montée de version PostgreSQL.
MySQL : une absence volontaire du tableau
MySQL ne figure pas dans le tableau, volontairement. Une date d'échéance pour MySQL 8.0 circule sur endoflife.date, mais nous ne l'avons pas retrouvée dans la documentation d'Oracle que nous avons lue : sans source primaire, elle reste dehors. Ce qui est établi, c'est le modèle des séries LTS : cinq ans de support premier, trois ans de support étendu, et un passage de LTS en LTS sans sauter de série. MySQL 8.4 est une série LTS. Si certains clients sont encore en 8.0, le guide de migration vers MySQL 8.4 reste la référence ; ajoutez la ligne au tableau dès que vous avez relevé la date chez l'éditeur.
Regrouper par client et par fenêtre : la méthode en sept étapes
Relever les versions de chaque serveur client
Sur Debian ou Ubuntu :
lsb_release -d. Sur RHEL ou AlmaLinux :cat /etc/os-release. Puis pour chaque pile :php -v,node -v,psql --version. Une ligne par serveur et par composant dans un tableur.Ne pas oublier les conteneurs
Un serveur à jour peut héberger une image ancienne. Listez-les avec
docker image ls, puis interrogez chaque image :docker run --rm <image> php -voudocker run --rm <image> node -v.Poser sa date de fin sur chaque ligne
Reportez la date du tableau de cet article en face de chaque composant relevé. La colonne obtenue est la seule dont vous aurez besoin pour trier.
Calculer la première échéance de chaque client
Pour chaque client, gardez la date la plus proche, tous serveurs confondus. Elle fixe la fenêtre du client : tout ce qui échoit dans les mois suivants rejoint la même intervention.
Choisir une fenêtre unique par client
PHP, Node.js et système dans la même intervention, avec une seule sauvegarde préalable et un seul plan de retour. Le tableau des fenêtres, plus bas, donne un découpage par échéance.
Répéter sur une copie avant de toucher la production
Restaurez la sauvegarde sur une machine de test, jouez la montée de version, puis contrôlez le site. Pour PostgreSQL, restaurez le dump et lancez les requêtes de l'application avant de basculer.
Consigner et recalculer
Après chaque intervention, mettez la ligne à jour avec la nouvelle version et sa date de fin. Le calendrier se recalcule seul, et le tableur devient le registre de l'agence.
Fenêtres d'intervention proposées
Faites défiler le tableau
| Fenêtre | Échéances couvertes | Regroupement conseillé |
|---|---|---|
| Fenêtre 1 : avant le 12 novembre 2026 | PostgreSQL 14 seul | Seule la montée PostgreSQL tient dans ces quinze jours ; les dettes Node.js 20 et Debian 11 se traitent en parallèle, sans attendre cette date |
| Fenêtre 2 : avant le 31 décembre 2026 | PHP 8.2 | Passage de tous les sites directement en PHP 8.4, pour éviter un second chantier dans l'année ; fenêtre à caler avant la période de gel de fin d'année |
| Fenêtre 3 : deux mois avant le 30 avril 2027 | Node.js 22 et Ubuntu 22.04 (mai 2027) | Une seule intervention : runtime et système, calée deux mois avant la première date : attendre le 30 avril 2027 ne laisserait aucune marge |
| Fenêtre 4 : avant le 11 novembre 2027 | PostgreSQL 15 | Majeure suivante en dump et restauration ou pg_upgrade, répétée sur copie |
| Fenêtre 5 : avant le 31 décembre 2027 | PHP 8.3 | Ne concerne que les sites restés en PHP 8.3, à passer en PHP 8.4 ; peut fusionner avec la fenêtre 4 pour les clients qui cumulent |
Ubuntu 22.04 : pourquoi « mai 2027 » sans jour
Pour Ubuntu 22.04 LTS, Canonical annonce la fin de la maintenance de sécurité standard en mai 2027, sans publier de jour. Le site endoflife.date affiche le 1er juin 2027. Les deux lectures sont compatibles avec une fin de mois, mais seule la formulation de Canonical est une source primaire ; le jour de l'autre est une lecture. Nous écrivons donc « mai 2027 » et planifions la montée avant le début du mois.
La version suivante, Ubuntu 24.04 LTS, est annoncée en maintenance standard jusqu'en mai 2029. La procédure do-release-upgrade est décrite dans notre guide Ubuntu 24.04 vers 26.04 ; elle s'applique de la même façon d'une LTS à la suivante, avec une sauvegarde complète avant chaque saut.
Un calendrier se décide, il ne se délègue pas
Les dates de cet article sont celles de la rédaction : revérifiez-les à la source avant de planifier, un éditeur peut les modifier. ServOrbit fournit les guides ; l'administration de vos serveurs et la conduite des migrations restent de votre ressort, guide fourni, pas de prise en charge. Testez toujours sur une copie.
Voir tout le parc dans un seul tableau
Un calendrier de fins de vie n'a de valeur que si l'on voit tout le parc au même endroit. La plateforme agence de ServOrbit.com centralise les domaines, les hébergements et les VPS de vos clients, avec leurs échéances de renouvellement : c'est le point de départ de l'étape 1, une liste de clients et de machines à jour plutôt qu'un tableur reconstitué à chaque trimestre. Les fins de vie logicielles, elles, ne sont pas suivies par la plateforme : les versions installées sur chaque serveur se relèvent sur les machines, avec les commandes ci-dessus, et se rapprochent de ce tableau.
La documentation officielle
Versions de PHP prises en charge: https://www.php.net/supported-versions.php
Politique de versions de PostgreSQL: https://www.postgresql.org/support/versioning/
Calendrier des versions de Node.js: https://github.com/nodejs/Release/blob/main/schedule.json
Debian LTS: https://wiki.debian.org/LTS
Cycle de publication d'Ubuntu: https://ubuntu.com/about/release-cycle
Versions de MySQL et séries LTS: https://dev.mysql.com/doc/refman/8.4/en/mysql-releases.html
Dates d'Ubuntu sur endoflife.date: https://endoflife.date/ubuntu
