Helm est le gestionnaire de paquets de Kubernetes : vous décrivez un déploiement dans un chart, un ensemble de gabarits YAML pilotés par des values, et Helm génère les manifestes, versionne chaque installation et permet de revenir en arrière en une commande. Cette formation gratuite mène du premier chart installé à la distribution de charts signés : 7 modules, 18 leçons, environ 18 heures de travail. Elle s'adresse aux profils DevOps et aux développeurs qui déploient déjà sur Kubernetes avec kubectl apply et veulent des déploiements reproductibles. Les seize guides ont été rejoués sur Helm v4.3.0 contre un cluster Kubernetes 1.37, et un module reste dédié à la migration depuis Helm v3.
Qu'est-ce que Helm et à quoi sert-il sur Kubernetes ?
Section intitulée « Qu'est-ce que Helm et à quoi sert-il sur Kubernetes ? »Helm remplace un dossier de manifestes YAML copiés d'un environnement à l'autre par un paquet unique et versionné, installé et mis à jour en une commande. Trois notions suffisent à comprendre le modèle, et elles reviennent dans toutes les leçons.
Un chart est le paquet : des gabarits YAML, un fichier values.yaml qui porte les paramètres par défaut, et un Chart.yaml qui le décrit et le versionne. Les values sont les paramètres que vous surchargez pour votre contexte, avec -f values-prod.yaml ou --set replicaCount=3. Une release est le résultat : une instance nommée du chart, déployée avec des values précises, dont Helm conserve l'historique des révisions. C'est cet historique qui rend helm rollback myapp 2 possible, là où un kubectl apply ne laisse aucune trace de l'état précédent.
| Sans Helm | Avec Helm |
|---|---|
| Fichiers YAML éparpillés, copiés-collés | Un chart versionné, un helm install |
| « Quelle version est en prod ? », il faut chercher dans les journaux | helm list donne version, date et statut |
| Rollback : retrouver les anciens fichiers, les réappliquer | helm rollback myapp 2 |
| Config dev/prod : dupliquer tous les YAML | Un chart plus values-dev.yaml et values-prod.yaml |
| Mise à jour : modifier dix fichiers, risque d'oubli | helm upgrade avec les nouvelles values |
Helm n'est pas la seule réponse. Kustomize superpose des patches sur des manifestes existants, sans langage de gabarit ni notion de release. Le choix se joue là : si vous distribuez une application à d'autres équipes, Helm gagne, parce qu'il livre un paquet paramétrable et versionné. Si vous adaptez vos propres manifestes à trois environnements, Kustomize fait le travail avec moins de machinerie.
Que contient la formation Helm et combien de temps demande-t-elle ?
Section intitulée « Que contient la formation Helm et combien de temps demande-t-elle ? »La formation compte 7 modules et 18 leçons, pour environ 18 heures de travail, manipulations sur cluster comprises. Elle est gratuite et accessible sans inscription.
| Ce que vous suivez | Volume |
|---|---|
| Modules pédagogiques | 7 |
| Leçons | 18 |
| Durée estimée | environ 18 heures |
| Version de référence des guides | Helm v4.3.0 |
| Cluster de vérification | Kubernetes 1.37, sur kind |
| Version couverte par le module de migration | depuis Helm v3 |
| Environnement de travail | cluster local kind, image kindest/node:v1.37.0 |
| Coût | gratuit, sans inscription |
Ces heures comptent la lecture et la reproduction des commandes sur un cluster. Un module comme Personnaliser ses déploiements pèse trois heures parce qu'il demande de créer des fichiers de values, de les surcharger et de vérifier le rendu avec helm template ; une leçon lue sans cluster sous la main passe beaucoup plus vite, et laisse beaucoup moins.
Comment suivre sa progression dans le parcours Helm ?
Section intitulée « Comment suivre sa progression dans le parcours Helm ? »Chaque leçon porte une case à cocher, et votre progression est enregistrée dans votre navigateur, sans compte ni inscription. Aucune donnée ne part sur un serveur.
La page Mon parcours affiche le programme complet, module par module, avec le pourcentage d'avancement. En haut de chaque leçon, un bandeau rappelle où vous en êtes ; en bas, un bouton la marque comme lue et vous emmène à la suivante. Vous pouvez donc étaler les 18 heures sur plusieurs semaines et reprendre exactement où vous vous étiez arrêté.
Le programme, module par module
Section intitulée « Le programme, module par module »Les modules se suivent dans l'ordre : chacun réutilise ce que le précédent a posé. On installe des charts écrits par d'autres avant d'en écrire, et on n'automatise en CI/CD qu'un chart dont on sait déjà vérifier la qualité.
Module 1, Découvrir Helm
Section intitulée « Module 1, Découvrir Helm »Installer Helm, comprendre ce qu'est un chart et déployer une première release. À la fin du module, vous savez chercher un chart public, l'inspecter avant de l'installer, et gérer les releases déjà en place.
Module 2, Personnaliser ses déploiements
Section intitulée « Module 2, Personnaliser ses déploiements »Adapter un chart à son contexte sans le forker. C'est le module qui sépare l'usage naïf de l'usage professionnel : on surcharge par values, on comprend la structure interne d'un chart, et on applique des gabarits éprouvés en production.
Module 3, Exploiter au quotidien
Section intitulée « Module 3, Exploiter au quotidien »Faire vivre une release dans la durée : montées de version, retours arrière, et diagnostic quand le rendu ne donne pas ce qu'on attendait.
Module 4, Composer et fiabiliser ses charts
Section intitulée « Module 4, Composer et fiabiliser ses charts »Passer du chart unique à un ensemble cohérent, et se donner les moyens de vérifier sa qualité avant publication.
Module 5, Sécuriser et distribuer
Section intitulée « Module 5, Sécuriser et distribuer »Publier des charts auxquels on peut faire confiance. C'est le module le plus proche des enjeux de chaîne d'approvisionnement logicielle : un chart non signé installé depuis un registre public est du code arbitraire appliqué à votre cluster.
Module 6, Industrialiser
Section intitulée « Module 6, Industrialiser »Automatiser le packaging dans une chaîne CI/CD, du chart validé au registre OCI.
Vous exploitez encore Helm 3 ?
Section intitulée « Vous exploitez encore Helm 3 ? »Cette formation enseigne Helm 4 sans condition : la migration n'est donc pas une étape à traverser pour finir le parcours, c'est un détour pour qui arrive de Helm 3. Elle reste à portée, à part.
Que pratique-t-on dans chaque module ?
Section intitulée « Que pratique-t-on dans chaque module ? »Chaque module se travaille sur un cluster local jetable, monté en une commande avec kind. Rien n'exige de cluster managé ni de compte cloud : le tableau ci-dessous indique ce que vous manipulez réellement module par module, et le temps à y consacrer.
| Module | Ce que vous manipulez | Durée |
|---|---|---|
| Découvrir Helm | Installer Helm, chercher un chart public, déployer puis supprimer une release | 3 h 05 |
| Personnaliser ses déploiements | Fichiers de values par environnement, structure d'un chart, gabarits de production | 3 h |
| Exploiter au quotidien | upgrade, history, rollback, puis lint, template et --debug | 1 h 45 |
| Composer et fiabiliser | Subcharts, chart umbrella, conception de l'API de values, values.schema.json | 2 h 55 |
| Sécuriser et distribuer | Droits RBAC et secrets de release, signature .prov, publication OCI | 2 h |
| Industrialiser | Chaîne lint, package, publish, deploy, puis migration vers Helm v4 | 1 h 40 |
Montez le cluster avant de commencer le module 1, et gardez-le pour toute la durée de la formation. Toute cette formation est rejouée sur kind, avec l'image kindest/node:v1.37.0 : c'est la combinaison sur laquelle les sorties publiées ont été mesurées, et la seule que les attestations de lab couvrent.
kind create cluster --name helm-lab --image kindest/node:v1.37.0Un autre outil de cluster local fonctionne, mais vous constaterez des écarts sur les sorties, les versions d'API servies et le comportement des LoadBalancer. Si vous en utilisez un, gardez en tête que les différences viennent de là, pas de Helm.
Vérifiez ensuite que kubectl cluster-info répond avant d'installer quoi que ce soit. Un helm install lancé sur un contexte pointant vers un cluster éteint échoue sur un message de connexion qui n'a rien à voir avec Helm, et fait chercher au mauvais endroit.
Quels prérequis avant de commencer Helm ?
Section intitulée « Quels prérequis avant de commencer Helm ? »Trois prérequis suffisent : connaître les objets Kubernetes de base, savoir lire du YAML, et disposer d'un cluster. Helm ne remplace pas la compréhension de Kubernetes, il l'exige : un chart produit des Deployments, des Services et des ConfigMaps, et si vous ne savez pas les lire, vous ne saurez pas diagnostiquer ce que le chart a produit.
- Kubernetes : Pods, Deployments, Services et namespaces.
- YAML : syntaxe, indentation, listes et dictionnaires.
- Un cluster :
kinden local, sur l'imagekindest/node:v1.37.0.
Helm v3 ou Helm v4 : quelle version apprendre ?
Section intitulée « Helm v3 ou Helm v4 : quelle version apprendre ? »Apprenez sur Helm v4, la version que documentent ces guides : Helm v3 a reçu sa dernière version de fonctionnalités le 9 septembre 2026, la v3.22.0, et ses correctifs de sécurité s'arrêtent le 10 février 2027. Apprendre aujourd'hui sur une branche qui n'évoluera plus reviendrait à mémoriser des commandes à réapprendre dans six mois.
Un second argument, plus concret, tranche pour ceux qui suivent aussi la formation Kubernetes : la matrice de compatibilité officielle donne Helm 4.3 pour Kubernetes 1.37 à 1.34, et Helm 4.1 seulement jusqu'à 1.35. Sur un cluster récent, le choix de la branche n'en est pas vraiment un.
Cela ne rend pas Helm v3 négligeable, et c'est pourquoi ce parcours garde un module entier de migration. Des milliers de chaînes CI/CD tournent encore en v3, et elles ont jusqu'à février 2027 pour basculer. Le modèle chart, values et release ne change pas ; ce sont des détails d'interface qui cassent les scripts.
Trois écarts font tomber une chaîne qui n'a pas été relue. Les flags renommés d'abord : --atomic devient --rollback-on-failure et --force devient --force-replace, les anciens noms restant acceptés mais dépréciés. Les post-renderers ensuite : ce n'est plus un binaire passé en paramètre, ils passent par le système de plugins, ce qui impacte toutes les chaînes du type --post-renderer ./kustomize. L'authentification OCI enfin : helm registry login attend le domaine (ghcr.io) et non une référence complète.
Avant de migrer, rejouez vos pipelines avec Helm v4 en portant l'attention sur upgrade --install, --wait, --dry-run et le post-rendu. Le module Migrer vers Helm v4 détaille chaque changement avec sa commande de remplacement et une checklist de bascule.
Erreurs fréquentes et dépannage Helm
Section intitulée « Erreurs fréquentes et dépannage Helm »Cinq messages d'erreur couvrent la majorité des blocages des débutants, et aucun ne vient de Helm lui-même : ils viennent du chart, du contexte ou du cluster. Le tableau donne le symptôme exact tel qu'il s'affiche, puis la première chose à essayer.
| Erreur | Symptôme | Solution rapide |
|---|---|---|
| Chart introuvable | Error: chart not found | helm repo update |
| Release existe déjà | cannot reuse a name | Changer le nom ou utiliser helm upgrade --install |
| Values ignorées | La configuration n'est pas appliquée | Vérifier le chemin YAML dans le chart, passer le fichier avec -f |
| Pods en Pending | Les conteneurs ne démarrent pas | Vérifier resources, les PVC et le nodeSelector |
| Erreur de template | nil pointer | Ajouter required ou default dans le gabarit |
Le réflexe qui résout le plus de cas ne figure pas dans ce tableau : rendre le chart localement avec helm template avant d'appliquer. Vous voyez le YAML final, celui que Kubernetes recevra, et la moitié des erreurs de values saute aux yeux à ce moment. Le module Déboguer et valider un chart en fait une méthode complète.
Ce que je défends
Section intitulée « Ce que je défends »Cette formation a des opinions, forgées sur des clusters jetables comme en production. Les voici, pour que vous sachiez à quoi vous vous engagez.
Jamais helm install seul, toujours helm upgrade --install. Le --install rend la commande rejouable : elle passe telle quelle en intégration continue, sans gérer le cas « la release existe déjà ». Attention au sens du mot : rejouer une commande identique crée quand même une nouvelle révision et un secret de release de plus, mesuré sur un chart inchangé. Elle ne casse rien, elle n'est pas sans effet, et c'est pourquoi --history-max compte. J'ajoute --wait --timeout 5m pour ne valider qu'une fois les pods réellement prêts, et --rollback-on-failure pour que la release revienne automatiquement en arrière en cas d'échec au lieu de rester coincée en failed à nettoyer à la main. Ce dernier s'appelait --atomic en Helm v3 ; l'ancien nom reste accepté, avec un avertissement de dépréciation à chaque exécution. Et en v4, --wait devient un choix de stratégie dont le défaut, hookOnly, n'attend que les hooks.
Un chart s'inspecte avant de s'installer. helm show values et helm template coûtent dix secondes et vous disent ce que le chart va créer, avec quels droits et quelles images. Installer un chart public sans l'avoir lu, c'est appliquer du code arbitraire à votre cluster avec les droits du compte qui lance la commande.
Les values de production vivent dans Git, pas dans des --set. Un --set empilé dans un script d'historique de shell n'est ni relisible ni reproductible. Un fichier values-prod.yaml versionné se relit, se commente et se compare d'une release à l'autre.
Un chart publié se signe. Le fichier de provenance .prov et la vérification à l'installation ne coûtent rien une fois la chaîne en place, et ils sont la seule chose qui distingue votre chart d'un chart homonyme poussé par quelqu'un d'autre sur le même registre.
On ne met pas de logique métier dans un gabarit. Un template Helm truffé de conditions imbriquées devient illisible et impossible à tester. Quand un chart réclame ce niveau de logique, c'est en général qu'il devrait être découpé en subcharts, ou que la logique appartient à l'application.
Ce que je vous déconseille
Section intitulée « Ce que je vous déconseille »Trois erreurs reviennent assez souvent pour mériter d'être nommées avant que vous ne les commettiez.
Forker un chart public pour changer trois valeurs. Vous héritez alors de sa maintenance et vous perdez ses mises à jour de sécurité. Les values, les subcharts et, en dernier recours, un post-renderer couvrent presque tous les besoins d'adaptation.
Traiter helm rollback comme un filet de sécurité universel. Il restaure les manifestes, pas les données : une migration de schéma de base de données appliquée par un hook ne se défait pas parce que vous êtes revenu à la révision précédente.
Découvrir Helm v4 le jour où le pipeline casse. Helm v3 n'aura plus de correction de bogue après sa version finale du 9 septembre 2026, et plus aucun correctif de sécurité après le 10 février 2027. Testez la bascule en préproduction pendant que la v3 tient encore.
À retenir
Section intitulée « À retenir »- Helm est le gestionnaire de paquets de Kubernetes : chart, plus values, égale release
- Un chart est un paquet versionné de gabarits ; les values le paramètrent ; la release est l'instance déployée, avec son historique
- Le flux de base tient en quatre commandes :
helm repo add,helm install,helm upgrade,helm rollback - Créer un chart :
helm create, nettoyer le squelette, templater, valider avechelm lintethelm template - En production : publier sur un registre OCI, signer, automatiser en CI/CD
- La formation compte 7 modules, 18 leçons et environ 18 heures, rejoués sur Helm v4.3.0 contre un cluster Kubernetes 1.37
- Les correctifs de sécurité de Helm v3 s'arrêtent le 10 février 2027, après une dernière version de fonctionnalités le 9 septembre 2026 : la migration vers Helm v4 est un chantier à planifier, pas à subir
FAQ : questions fréquentes
Section intitulée « FAQ : questions fréquentes »Ces questions reviennent systématiquement en formation, et la plupart portent sur les frontières de Helm : ce qu'il gère, ce qu'il ne gère pas, et ce qu'il laisse à Kubernetes. Les réponses sont volontairement courtes, chacune renvoyant au guide qui la développe.
helm rollback) en cas de problème.values.yaml par défaut). Une release est une instance installée de ce chart sur un cluster, avec ses propres valeurs et son numéro de révision. Un même chart peut donner plusieurs releases (ex. app-prod et app-staging), chacune suivie indépendamment par Helm.helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm upgrade --install mon-app bitnami/nginx -f values.yaml
helm upgrade --install à helm install : la commande devient idempotente (rejouable en CI). Personnalisez avec -f values.yaml ou --set cle=valeur.values.yaml contient les valeurs de configuration par défaut d'un chart (image, réplicas, ressources, ingress). Les templates du chart s'y réfèrent via {{ .Values.xxx }}. À l'installation, on surcharge ces valeurs avec son propre fichier (-f mes-values.yaml) ou en ligne (--set replicas=3), sans modifier le chart : c'est ce qui rend un même chart réutilisable d'un environnement à l'autre.helm, les charts publics et les registries OCI compatibles s'utilisent sans licence payante, aussi bien en local qu'en CI/CD. Les seuls coûts éventuels viennent de l'infrastructure qui héberge vos charts privés (registry OCI type Harbor, GHCR ou ECR).helm create mon-app
helm lint mon-app
helm template mon-app
helm create crée la structure standard : Chart.yaml (métadonnées), values.yaml (valeurs par défaut) et le dossier templates/. Nettoyez les templates générés, écrivez les vôtres, validez avec helm lint et helm template (rendu sans déployer), puis helm package avant de publier sur un registry OCI. Le détail : Anatomie d'un chart.helm history mon-app
helm rollback mon-app 2
helm history affiche les révisions (numéro, date, statut, version du chart). helm rollback mon-app 2 redéploie l'état exact de la révision 2. Chaque rollback crée lui-même une nouvelle révision, ce qui préserve la traçabilité. C'est l'un des principaux avantages de Helm face à un kubectl apply manuel.Pour aller plus loin
Section intitulée « Pour aller plus loin »- Personnaliser avec les values : Le premier réflexe professionnel, adapter un chart sans le forker.
- Upgrade, rollback et cycle de vie : Faire vivre une release dans la durée et revenir en arrière sans casse.
- Distribuer ses charts via OCI : Publier sur un registre OCI et référencer par digest.
- Migrer vers Helm v4 : Les changements qui cassent une chaîne CI/CD, et la checklist de bascule.