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 : 6 modules, 15 leçons, environ 13 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 guides sont vérifiés sur Helm v3.20.0, avec un module dédié à la bascule vers Helm v4.
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 6 modules et 15 leçons, pour environ 13 heures de travail, manipulations sur cluster comprises. Elle est gratuite et accessible sans inscription.
| Ce que vous suivez | Volume |
|---|---|
| Modules pédagogiques | 6 |
| Leçons | 15 |
| Durée estimée | environ 13 heures |
| Version de référence des guides | Helm v3.20.0 |
| Version couverte par le module de migration | Helm v4 |
| Environnement de travail | cluster local kind ou k3d |
| 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 marque la leçon comme lue et vous emmène à la suivante. Vous pouvez donc étaler les 13 heures sur plusieurs semaines et reprendre exactement là 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, puis préparer la bascule vers Helm v4.
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, kind ou k3d, monté en une commande. 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, values.schema.json, documentation | 2 h |
| Sécuriser et distribuer | Signature et fichier .prov, publication sur un registre OCI | 1 h 15 |
| 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. Les deux outils conviennent, choisissez celui que vous avez déjà :
# Option 1 : kindkind create cluster --name helm-lab
# Option 2 : k3dk3d cluster create helm-labVérifiez ensuite que kubectl cluster-info répond avant d'installer quoi que ce soit : un helm install sur un contexte pointant vers un cluster éteint échoue avec un message de connexion qui n'a rien à voir avec Helm.
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 : kind, k3d ou minikube en local suffisent.
Helm v3 ou Helm v4 : quelle version apprendre ?
Section intitulée « Helm v3 ou Helm v4 : quelle version apprendre ? »Apprenez sur Helm v3, la version que documentent ces guides, mais planifiez la bascule : le support de sécurité de Helm v3 s'arrête le 11 novembre 2026, et le support correctif a pris fin le 8 juillet 2026. Le modèle chart, values et release ne change pas en v4 ; ce sont des détails d'interface qui cassent les scripts.
Trois écarts font tomber une chaîne CI/CD 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 la 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 re-use 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 sautent 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 k3d 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 idempotente : elle se rejoue telle quelle en intégration continue, sans gérer le cas « la release existe déjà ». J'ajoute --wait --timeout 5m pour ne valider qu'une fois les pods réellement prêts, et --atomic pour que la release revienne automatiquement en arrière en cas d'échec au lieu de rester coincée en failed à nettoyer à la main. En Helm v4, ce dernier flag s'écrit --rollback-on-failure.
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. Le support correctif de Helm v3 est terminé depuis le 8 juillet 2026 et le support de sécurité s'arrête le 11 novembre 2026. 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 6 modules, 15 leçons et environ 13 heures, vérifiés sur Helm v3.20.0
- Le support de sécurité de Helm v3 s'arrête le 11 novembre 2026 : la migration vers Helm v4 est un chantier à planifier, pas à subir
FAQ : questions fréquentes
Section intitulée « FAQ : questions fréquentes »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.