PostgreSQL 14 : les correctifs prennent fin le 12 novembre

Ce qui change

PostgreSQL 14, une branche du logiciel de gestion de bases de données, cessera de recevoir les correctifs du projet le 12 novembre 2026. Le projet recommande aux utilisateurs de cette version en production de préparer le passage à une version plus récente et maintenue. Cette échéance figure dans son annonce du 14 mai 2026.

Pour une entreprise concernée, la décision à préparer est le choix de la version cible et du calendrier de migration de ses applications.

Quelles entreprises sont concernées

Le dossier s’adresse aux PME françaises dont les applications utilisent PostgreSQL 14, que leur équipe administre la base ou en confie l’exploitation à un prestataire. Faites confirmer la version réellement utilisée avant de lancer un projet.

L’échéance citée concerne les correctifs du projet PostgreSQL. Pour un service hébergé, demandez séparément au fournisseur son calendrier et les engagements applicables à votre contrat.

PostgreSQL est distribué sous la PostgreSQL License, une licence libre. Sa licence officielle autorise notamment l’utilisation, la copie, la modification et la distribution, sous réserve de conserver les mentions qu’elle impose.

Le calendrier à retenir

La date de fin des correctifs est le 12 novembre 2026. Organisez les essais et la décision de bascule en amont de cette échéance ; il s’agit ici d’une recommandation de préparation.

Le changement de version majeure (passage à une nouvelle branche du logiciel) nécessite une méthode de migration. Parmi les possibilités documentées figurent l’export-restauration (extraction des données puis réintégration dans la nouvelle version) et pg_upgrade (outil de mise à niveau). La documentation officielle avertit que des incompatibilités peuvent nécessiter des adaptations applicatives et recommande de tester les applications avant la bascule complète.

Les décisions à préparer maintenant

• Identifier les installations concernées. Demandez au responsable technique la version du serveur ; la fonction version() (fonction qui indique la version du serveur) permet de la consulter.
• Choisir une cible maintenue. Vérifiez sa durée de support dans la politique de versions et faites examiner sa compatibilité avec vos applications.
• Préparer un essai applicatif. Faites reproduire les usages nécessaires à votre activité sur la version cible avant d’autoriser la bascule.
• Arrêter la méthode de transfert. Comparez notamment export-restauration et pg_upgrade. Si ce dernier est retenu, faites vérifier la compatibilité binaire des modules externes (capacité des composants logiciels ajoutés à fonctionner avec la nouvelle version) : l’outil ne la contrôle pas.
• Fixer le passage en service. Désignez qui réalise la migration et qui accepte les résultats des essais ; demandez au prestataire, s’il intervient, de confirmer son calendrier.

Pour organiser cette migration applicative, le conseil en transformation digitale de VCSTS coordonne cadrage, intégration, migration, recette, déploiement et adoption jusqu’au fonctionnement réel.