Prometheus sort une version mineure toutes les six semaines. Si tu suis ce rythme à la lettre sur ton cluster de prod, tu passes ton temps à mettre à jour un composant qui, en théorie, ne devrait pas te réveiller la nuit. La 3.14 est sortie le 17 août 2026 ; elle a cessé de recevoir des correctifs le 30 septembre, soit six semaines plus tard quasiment au jour près. La 3.15, sortie le 24 septembre, sera à son tour en fin de vie le 6 novembre. Pendant ce temps, la 3.13 — sortie le 1er juillet — reste supportée jusqu’au 31 juillet 2027. Ce n’est pas un hasard de calendrier : c’est le modèle LTS de Prometheus, et la plupart des équipes qui tournent en prod devraient s’en servir plutôt que de courir après la dernière mineure.
Comment fonctionne le support LTS chez Prometheus
Le projet documente son cycle de release sans ambiguïté : une mineure classique sort toutes les six semaines, et passé ce délai, elle ne reçoit en général plus aucun correctif. Si un bug te touche sur une version qui n’est plus maintenue, la seule réponse officielle est de migrer vers la dernière mineure — pas vers un patch rétroporté.
Les versions LTS cassent cette règle pour une poignée de releases choisies : un an de support au lieu de six semaines. Mais ce support a un périmètre précis, pas un blanc-seing :
- seules les failles de sécurité avec un score CVSS supérieur ou égal à 7.0 sont corrigées sur une LTS ;
- d’autres correctifs de bugs ou de documentation peuvent s’ajouter, à la discrétion des mainteneurs ;
- la chaîne de compilation est maintenue à jour sur toute la durée du support ;
- deux LTS successives se chevauchent d’au moins un mois, pour laisser le temps de migrer sans courir.
Et c’est un effort communautaire assumé comme tel : « best effort », sans garantie contractuelle, sans SLA. Les fonctionnalités expérimentales (tout ce qui vit derrière un feature flag) et le support OpenBSD sont explicitement exclus du périmètre LTS, quelle que soit la version.
L’historique dit tout
Cinq versions ont porté l’étiquette LTS depuis que le modèle existe :
- 2.37 — sortie le 14/07/2022, fin de support le 31/07/2023
- 2.45 — sortie le 23/06/2023, fin de support le 31/07/2024
- 2.53 — sortie le 16/06/2024, fin de support le 31/07/2025
- 3.5 — sortie le 14/07/2025, fin de support le 31/07/2026
- 3.13 — sortie le 01/07/2026, fin de support le 31/07/2027 (en cours)
Le rythme est régulier : une nouvelle LTS environ chaque année, avec le chevauchement d’un mois prévu par la doc. La prochaine est attendue autour de juin 2027, pour une fin de support en juillet 2028. Si ton infra tourne encore en 3.5 aujourd’hui, tu es dans la fenêtre de chevauchement — mais plus pour longtemps vu l’échéance du 31 juillet 2026, déjà passée au moment où tu lis cet article.
Ce que tu rates en restant sur la 3.13 plutôt que la 3.15
La 3.15.0, sortie le 24 septembre, apporte des choses utiles mais rarement critiques pour un cluster déjà stable : scraping via sockets Unix, implémentation du format OpenMetrics 2.0, compression zstd des réponses de scrape derrière le flag zstd-scrape, et un --auto-gomemlimit.refresh-interval qui redétecte à chaud la limite mémoire du conteneur. Côté dépréciation, --log.level cède la place à runtime.log_level, rechargeable sans redémarrer le process — pratique, mais pas une raison de migrer en urgence.
Il y a aussi un paquet de corrections sur les histogrammes natifs (détection de reset manquée qui sous-estimait rate() et increase(), erreurs d’index dans Compact) et sur le mode Agent, où une écriture WAL échouée pouvait corrompre le fichier. Si tu exploites activement les histogrammes natifs ou le mode Agent, ces correctifs valent une mise à jour ciblée — même en dehors du calendrier LTS. Pour le reste, ça peut attendre la prochaine LTS.
Notre avis : arrête de courir après chaque mineure
Sauf si une fonctionnalité précise de la 3.14 ou de la 3.15 te manque vraiment, reste sur la 3.13 jusqu’à l’approche de juillet 2027. Tu gagnes un an de stabilité réelle, un correctif de sécurité garanti pour tout CVSS ≥ 7.0, et tu évites le cycle de mise à jour toutes les six semaines qui n’apporte, la plupart du temps, que du bruit opérationnel. À l’inverse, si tu es du genre à vouloir tester chaque nouveauté avant tout le monde — ou si tu fais tourner Prometheus sur un environnement de test plutôt qu’en prod critique — suivre les mineures reste parfaitement défendable. Ce n’est pas un mauvais choix dans l’absolu, juste un choix qui demande d’accepter le rythme qui va avec.
FAQ
Une faille CVSS 6.x découverte sur la 3.13 sera-t-elle corrigée ?
Pas via le canal LTS officiel : seul un CVSS ≥ 7.0 déclenche un correctif de sécurité garanti sur une LTS. Une faille moins sévère peut être corrigée si un mainteneur s’en occupe bénévolement, mais sans aucune garantie.
Peut-on sauter une LTS, par exemple passer directement de la 2.53 à la 3.13 ?
Oui techniquement, mais vérifie les guides de migration de chaque version majeure traversée (le passage 2.x → 3.x a changé pas mal de comportements par défaut) avant de sauter plusieurs cycles d’un coup.
Le mode Agent et les histogrammes natifs sont-ils couverts par le support LTS ?
Oui s’ils sont considérés stables selon les garanties de l’API Prometheus ; les fonctionnalités encore derrière un feature flag restent explicitement exclues du périmètre LTS, même sur une version LTS.
Ce qu’il faut retenir
Le choix de version Prometheus n’a rien d’arbitraire : c’est une question de politique de support documentée, avec des dates précises et un périmètre de sécurité clair. Pour la très grande majorité des clusters en prod, la bonne réponse en octobre 2026 est 3.13, pas 3.15 — et ça restera vrai jusqu’à l’été 2027. On avait déjà couvert l’arrivée de Prometheus 3 face à Grafana 13 et OpenTelemetry, et plus récemment les Saved Queries de Grafana 13.2 — la question de la version Prometheus sous-jacente, elle, se pose indépendamment de ce qui tourne par-dessus.
Laisser un commentaire