La fin de vie de Helm 3, expliquée

La fin de vie de Helm 3 est la date après laquelle le projet Helm ne publie plus aucune version de Helm 3, correctifs de sécurité compris. Cette date est le 10 février 2027, selon l'annonce de fin de vie du projet Helm. Beaucoup de guides donnent encore novembre 2026, la date du plan initial. Les équipes qui utilisent Helm 3 dans des scripts et des pipelines ont encore environ trois mois pour passer à Helm 4.

Helm est le gestionnaire de paquets de Kubernetes, le système qui fait tourner des conteneurs sur de nombreux serveurs. Un chart Helm est un paquet de modèles pour une application. Installer un chart crée une release, et chaque mise à niveau ajoute une révision numérotée à l'historique de cette release.

Ce guide couvre le calendrier, ce que change Helm 4, et un test pratique de Helm 4.3.1 sur des releases créées par Helm 3.22.1.

Comment fonctionne la fin de vie de Helm 3

Helm 3 s'arrête en deux étapes, selon l'annonce de fin de vie que George Jenkins a écrite pour le projet le 2 juin 2026.

• Les corrections de bugs ont pris fin le 9 septembre 2026. La version de ce jour était la dernière version fonctionnelle de Helm 3. Elle n'apportait que des bibliothèques clientes Kubernetes à jour. Helm 3 pouvait ainsi dialoguer avec des versions plus récentes de Kubernetes.
• Les correctifs de sécurité s'arrêtent le 10 février 2027. Si une faille est trouvée d'ici là, le projet publie encore un correctif. Après cette date, Helm 3 ne reçoit plus aucune mise à jour, « y compris la bibliothèque cliente Kubernetes et les correctifs de sécurité », selon l'annonce.

Les notes de version de v3.22.0 confirment que 3.22 est la dernière version mineure de Helm 3. Le correctif le plus récent, 3.22.1, est sorti le 15 octobre 2026.

La fin de vie n'éteint rien. Un binaire Helm 3 continue de tourner après le 10 février 2027, comme le rappelle Private DevOps dans son guide de migration. Il ne reçoit simplement plus de correctifs de sécurité ni de prise en charge des nouvelles versions de Kubernetes.

Ce qui a changé et quand

Le calendrier initial venait de HIP-0012, une proposition d'amélioration de Helm. Elle promettait des correctifs de sécurité pour Helm 3 pendant un an après Helm 4.0.0, soit jusqu'en novembre 2026. En juin, les mainteneurs ont ajouté trois mois.

Date	Ce qui s'est passé
12 novembre 2025	Sortie de Helm 4.0.0 à la KubeCon, la première nouvelle version majeure de Helm en six ans
2 juin 2026	Helm prolonge de trois mois les correctifs de sécurité de Helm 3
9 septembre 2026	Dernière version fonctionnelle de Helm 3 (3.22) ; fin des corrections de bugs
15 octobre 2026	Sortie de Helm 3.22.1 et Helm 4.3.1, les versions les plus récentes au 8 novembre
13 janvier 2027	Helm 4.4.0 prévu, selon la page des versions
10 février 2027	Fin des correctifs de sécurité de Helm 3 ; plus aucune version de Helm 3

Le conseil de l'annonce est direct : « Nous encourageons vivement tous les utilisateurs à migrer vers Helm 4 avant cette date. »

Ce que Helm 4 change pour les utilisateurs de Helm 3

Selon le projet Helm, Helm 4 « devrait être compatible avec la majorité des charts, releases et workflows Helm 3 existants ». Les charts au format v2 actuel fonctionnent sans changement, et un nouveau format de chart v3 reste expérimental. La présentation de Helm 4 liste les changements qui comptent :

• Des flags renommés. --atomic devient --rollback-on-failure, et --force devient --force-replace. Les anciens noms marchent encore, mais affichent un avertissement.
• Les post-renderers sont des plugins. Un post-renderer modifie la sortie de Helm avant qu'elle n'atteigne le cluster. --post-renderer attend désormais le nom d'un plugin installé, pas le chemin d'un script.
• La connexion au registre prend un nom d'hôte. helm registry login n'accepte qu'un domaine, pas une URL.
• Server-side apply pour les nouvelles installations. Avec le server-side apply, Kubernetes fusionne lui-même chaque changement et note quel outil possède chaque champ. Les mises à niveau et les retours arrière gardent la méthode qu'une release utilise déjà. Les releases créées par Helm 3 restent donc sur l'ancienne méthode côté client. Le flag --server-side change cela.
• Un nouveau système de plugins. Les plugins existants continuent de marcher. Ils peuvent aussi tourner sur un runtime WebAssembly optionnel, que le projet recommande pour la sécurité.

Testé : Helm 4.3.1 sur des releases créées par Helm 3

Lors d'un test de Tech AI Wire le 8 novembre 2026, un cluster k3s sous Kubernetes 1.36.6 tournait dans Docker 28.4.0 sur macOS 26.6.2. Les deux binaires Helm venaient de get.helm.sh, et leurs sommes de contrôle SHA-256 correspondaient. Helm 3.22.1 a installé le chart d'exemple que crée helm create. Helm 4.3.1 a ensuite travaillé sur la même release. Les deux binaires s'appellent helm3 et helm4 ci-dessous.

helm3 install web ./demo --wait
helm4 upgrade web ./demo --atomic --set replicaCount=2
helm4 registry login https://ghcr.io -u test -p test
helm4 template web ./demo --post-renderer ./pr.sh
helm4 get metadata web

Test	Résultat
Helm 4 lit la release de Helm 3	Oui : helm list et helm history l'affichaient
upgrade --atomic	A marché, avec « Flag --atomic has been deprecated, use --rollback-on-failure instead »
upgrade --force	A marché, avec « Flag --force has been deprecated, use --force-replace instead »
registry login https://ghcr.io	Échec : invalid reference: invalid registry "https://ghcr.io"
--post-renderer ./pr.sh, un script shell	Échec : plugin introuvable ; Helm 3.22.1 exécutait le même script
Méthode d'application de la release Helm 3 après des mises à niveau par Helm 4	« client-side apply (defaulted) »
Méthode d'application d'une nouvelle installation par Helm 4	« server-side apply »
Helm 3 après les mises à niveau par Helm 4	A lu les quatre révisions et est revenu à la révision 1

Les propres registres de Kubernetes concordaient. Le Deployment de la release Helm 3 avait été écrit par une opération « Update », et la nouvelle release Helm 4 par un « Apply ».

Un résultat ne figure pas dans la documentation. --server-side=true a fait passer la release Helm 3 en server-side apply. Une mise à niveau ultérieure avec Helm 3.22.1 a ensuite poussé Helm 4 à la signaler de nouveau côté client, avec la mention « (defaulted) ». Quand l'ancien et le nouveau binaire alternent sur une release, une migration peut s'annuler sans bruit.

Ce que cela signifie pour les développeurs

• Corriger d'abord les deux échecs francs. Chercher dans les scripts CI helm registry login avec https://, et --post-renderer qui pointe vers un script. Les deux arrêtent un pipeline Helm 4, alors que les flags renommés n'affichent que des avertissements.
• Renommer --atomic et --force dès maintenant. Ils marchent encore, mais Helm 4 les marque comme obsolètes et affiche un avertissement à chaque exécution.
• Un seul binaire par release. Pendant la migration, une release que Helm 4 a touchée ne doit plus être mise à niveau que par Helm 4. Sinon, la méthode d'application peut revenir en arrière.
• Choisir le server-side apply en connaissance de cause. Les releases créées par Helm 3 restent côté client tant que personne ne passe --server-side. Tester la bascule sur un cluster de préproduction avant la production.
• Figer la version de Helm dans la CI et tester les retours arrière. Private DevOps conseille de recenser chaque appel à Helm et de tester Helm 4 hors production d'abord.
• Ne pas attendre le 10 février. Après cette date, une faille de sécurité de Helm 3 reste sans correctif, et les nouvelles versions de Kubernetes n'ont plus de prise en charge dans le client Helm 3.