Helm Kubernetes : Tutoriel en 12 Étapes [2026]

Déployer une application sur Kubernetes avec de simples fichiers YAML devient vite ingérable dès que le nombre de services grandit. C’est exactement le problème que Helm, le gestionnaire de paquets de Kubernetes, résout depuis 2016. En 2026, Helm reste l’outil préféré pour packager, versionner et déployer des applications sur un cluster : selon l’enquête CNCF publiée fin décembre 2025, 75 % des équipes qui utilisent Kubernetes s’appuient sur Helm comme gestionnaire de paquets, loin devant les alternatives comme Kustomize seul.

Ce tutoriel montre comment installer Helm 4, créer votre premier chart, le configurer avec des values.yaml propres, gérer les secrets correctement, publier vos charts sur un registre OCI et automatiser le tout en CI/CD. On couvre aussi les pièges classiques et les erreurs les plus fréquentes, avec leurs solutions, plus une section dédiée aux CVE Helm publiées en 2025 et 2026 à connaître avant tout déploiement en production.

Comptez environ 90 minutes pour suivre l’intégralité des douze étapes sur un cluster local, en partant d’une machine vierge sans Helm ni Minikube installés. Si vous avez déjà un cluster de test opérationnel, prévoyez plutôt 45 minutes en sautant l’étape de préparation de l’environnement.

Qu’est-ce que Helm et pourquoi l’adopter en 2026

Helm packages vos manifestes Kubernetes (Deployment, Service, ConfigMap, Ingress, etc.) dans une archive versionnée appelée “chart”. Un chart contient des templates Go, un fichier de valeurs par défaut et des métadonnées. Au lieu de dupliquer des dizaines de fichiers YAML pour chaque environnement, vous écrivez un chart une fois et vous injectez des valeurs différentes selon que vous déployez en développement, en staging ou en production.

Le projet Helm décrit son rôle ainsi : “Helm helps you manage Kubernetes applications – Helm Charts help you define, install, and upgrade even the most complex Kubernetes application” (Helm aide à gérer les applications Kubernetes, les charts permettant de définir, installer et mettre à jour même l’application la plus complexe), selon la page d’accueil officielle du projet. Le README du dépôt GitHub compare l’outil à un gestionnaire de paquets système classique : “Think of it like apt/yum/homebrew for Kubernetes” (pensez-y comme apt/yum/homebrew pour Kubernetes).

Helm 4.0.0 est sorti le 12 novembre 2025 lors de KubeCon + CloudNativeCon North America, la première version majeure depuis Helm 3 en 2019. Au 4 septembre 2026, la version stable courante est Helm 4.2.4, avec les versions 4.3.0 et 3.22.0 planifiées pour le 9 septembre 2026. Le dépôt GitHub du projet précise que “Helm v4 is the current stable release, developed on the main branch” (Helm v4 est la version stable actuelle, développée sur la branche main), confirmant que la branche 4.x n’est plus expérimentale mais la ligne de développement principale recommandée pour tout nouveau déploiement.

Côté cluster, Kubernetes 1.37 est la version stable de référence début septembre 2026, avec des mises à jour sur l’allocation dynamique de ressources (DRA), comme le détaille le calendrier officiel des releases Kubernetes. Ce tutoriel utilise Helm 4.2.4 et Kubernetes 1.37 comme versions de référence, mais les commandes restent compatibles avec Helm 3.x récent (3.20 et plus) si votre organisation n’a pas encore migré.

Concrètement, pourquoi ce changement de version majeure compte-t-il pour vous ? Helm 4 rend par défaut plusieurs comportements qui étaient auparavant optionnels dans Helm 3.6, notamment autour du nouveau format de bundle et de la gestion de la racine de confiance pour les vérifications de signature. Si vous gérez des charts internes signés ou si vous prévoyez de le faire, ce changement mérite d’être anticipé avant une migration en masse plutôt que découvert en pleine mise à jour de production.

Prérequis : outils et versions nécessaires

Avant de commencer, assurez-vous de disposer des éléments suivants. Le tableau ci-dessous liste les versions minimales recommandées pour suivre ce tutoriel sans mauvaise surprise.

Outil	Version minimale conseillée	Rôle dans le tutoriel
Helm	4.2.4 (ou 3.20.2+ si vous restez sur Helm 3)	Créer, packager et installer les charts
kubectl	1.36 ou 1.37	Interagir avec le cluster
Un cluster Kubernetes local	Minikube 1.34+ ou Kind 0.24+	Environnement de test isolé
Docker ou Podman	Docker 27+ / Podman 5+	Construire l’image de l’application exemple
Un registre OCI accessible	GHCR, Docker Hub ou Harbor	Publier le chart packagé
Go (optionnel)	1.22+	Comprendre la syntaxe des templates Go utilisée par Helm

Si vous avez déjà suivi notre tutoriel Minikube, vous disposez déjà d’un cluster local fonctionnel : passez directement à l’étape 1. Sinon, comptez 15 minutes supplémentaires pour installer Minikube avant de démarrer.

Dans quels cas Helm change vraiment la donne

Avant de plonger dans les étapes techniques, il vaut mieux savoir dans quels contextes Helm apporte un vrai gain, plutôt que de l’adopter par réflexe. Trois cas d’usage reviennent le plus souvent chez les équipes qui migrent depuis des manifestes YAML bruts.

Le premier concerne les architectures microservices avec dix, vingt ou cinquante services qui partagent la même structure de déploiement (un Deployment, un Service, parfois un Ingress et un HorizontalPodAutoscaler). Sans Helm, chaque nouveau microservice implique de copier-coller des fichiers YAML et de traquer les différences à la main. Avec un chart générique paramétré, un nouveau service se déploie en écrivant simplement un fichier de valeurs de vingt lignes.

Le deuxième cas d’usage est le SaaS multi-tenant, où la même application doit être déployée plusieurs fois avec des paramètres différents (domaine, quotas, base de données dédiée) pour chaque client. Les fichiers de valeurs par tenant remplacent alors une bibliothèque de scripts de déploiement maison, souvent fragile et mal documentée.

Le troisième cas concerne la distribution de logiciels tiers : si vous publiez un produit destiné à être installé par des clients sur leur propre cluster, un chart Helm publié sur un registre OCI ou sur Artifact Hub, l’annuaire public de référence pour les charts et autres artefacts CNCF, offre une expérience d’installation standardisée que vos utilisateurs connaissent déjà.

Étape 1 : Installer Helm 4 sur macOS, Linux et Windows

Sur macOS avec Homebrew, l’installation tient en une ligne :

brew install helm

Sur Linux, la méthode reproductible recommandée par la documentation officielle consiste à récupérer le binaire directement depuis les releases GitHub plutôt que d’exécuter un script distant sans vérification :

curl -fsSL -o helm.tar.gz \
  https://get.helm.sh/helm-v4.2.4-linux-amd64.tar.gz
tar -zxvf helm.tar.gz
sudo mv linux-amd64/helm /usr/local/bin/helm
helm version

Sur Windows, passez par Chocolatey ou Scoop :

choco install kubernetes-helm

Vérifiez ensuite que la version installée correspond bien à la branche 4.x avant de continuer : helm version --short doit afficher quelque chose comme v4.2.4. Si vous voyez une version 3.x et que vous voulez tester Helm 4, désinstallez l’ancien binaire au préalable pour éviter les conflits de PATH.

Étape 2 : Démarrer un cluster Kubernetes local

Pour suivre ce tutoriel sans toucher à un cluster de production, démarrez un cluster local avec Minikube :

minikube start --kubernetes-version=v1.37.0 --cpus=4 --memory=6144
kubectl get nodes

La sortie doit indiquer un nœud à l’état Ready. Si vous préférez Kind, la commande équivalente est kind create cluster --image kindest/node:v1.37.0. Pour un déploiement réel sur Azure, consultez notre tutoriel AKS Azure pour créer le cluster managé avant d’y installer vos charts Helm.

Étape 3 : Installer votre premier chart depuis un dépôt public

Avant d’écrire votre propre chart, installez-en un existant pour comprendre le flux Helm. Ajoutez le dépôt Bitnami, mettez à jour l’index local, puis installez nginx :

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm install mon-nginx bitnami/nginx --namespace demo --create-namespace
helm list -n demo

Exemple de sortie attendue pour helm list :

NAME       NAMESPACE  REVISION  STATUS    CHART         APP VERSION
mon-nginx  demo       1         deployed  nginx-18.2.1  1.27.3

Chaque installation crée une “release”, un nom unique attaché à une révision. C’est cette notion de release qui permet à Helm de suivre l’historique et de faire un rollback plus tard. En interne, Helm stocke ces informations sous forme de Secrets Kubernetes dans le namespace de la release, ce qui signifie que l’état de vos déploiements Helm vit directement dans le cluster et non dans un système externe.

Pour explorer d’autres charts publics avant d’écrire le vôtre, parcourez Artifact Hub, qui référence les charts maintenus par la communauté et par des éditeurs comme Bitnami, Grafana ou Elastic. C’est souvent plus rapide de partir d’un chart existant et de le personnaliser que d’en écrire un de zéro pour des briques standards (bases de données, monitoring, ingress controllers).

Étape 4 : Créer votre propre chart avec helm create

Passons à la création d’un chart pour une application interne. Helm fournit un squelette de départ :

helm create mon-app
tree mon-app

Vous obtenez une arborescence standard : Chart.yaml pour les métadonnées, values.yaml pour les valeurs par défaut, un dossier templates/ avec les manifestes Kubernetes sous forme de templates Go, et un dossier charts/ réservé aux dépendances (subcharts). C’est cette structure que Helm interprète pour générer les manifestes finaux avant de les envoyer à l’API Kubernetes.

Étape 5 : Configurer Chart.yaml et values.yaml

Ouvrez Chart.yaml et renseignez le nom, la version du chart (version) et la version de l’application packagée (appVersion). Ces deux champs sont distincts : le premier suit le cycle de vie du chart, le second celui de votre application.

apiVersion: v2
name: mon-app
description: Chart Helm pour mon-app
type: application
version: 0.1.0
appVersion: "1.0.0"

Dans values.yaml, définissez des valeurs par défaut sûres et minimales, par exemple le nombre de réplicas, l’image et les ressources CPU/mémoire. La bonne pratique 2026 consiste à garder ce fichier comme configuration de base neutre, puis à créer des fichiers additionnels par environnement (values-staging.yaml, values-prod.yaml) que vous superposez au moment de l’installation plutôt que de dupliquer des manifestes YAML complets par environnement.

La documentation officielle des bonnes pratiques de charts Helm recommande aussi de documenter chaque clé de values.yaml avec un commentaire expliquant son rôle et son type attendu. Sur un chart maintenu par plusieurs personnes, cette documentation inline évite les régressions provoquées par une valeur mal comprise et réutilisée à tort.

Étape 6 : Écrire les templates avec le langage Go et les helpers

Les fichiers dans templates/ utilisent la syntaxe de templating Go, avec des fonctions comme .Values, .Release.Name ou .Chart.Name. Voici un extrait simplifié d’un Deployment paramétré :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-mon-app
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Chart.Name }}
  template:
    metadata:
      labels:
        app: {{ .Chart.Name }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

Le fichier _helpers.tpl centralise les fonctions réutilisables, comme la génération de noms cohérents entre toutes vos ressources. Évitez de dupliquer la même logique de nommage dans chaque template : passez par un helper unique appelé partout.

Quelques fonctions reviennent dans presque tous les charts sérieux : default pour fournir une valeur de repli quand une clé n’est pas définie, required pour forcer l’échec explicite du rendu si une valeur critique manque (plutôt que de laisser passer une chaîne vide en production), et toYaml combiné à nindent pour injecter proprement des blocs YAML complets, comme des limites de ressources ou des variables d’environnement, sans casser l’indentation du fichier final.

Étape 7 : Linter, rendre et tester à blanc avant d’installer

Avant tout déploiement réel, validez la syntaxe et prévisualisez le rendu final :

helm lint ./mon-app
helm template mon-app ./mon-app
helm install mon-app ./mon-app --dry-run --debug

helm lint détecte les erreurs de structure et les valeurs manquantes. helm template affiche le YAML final généré sans rien envoyer au cluster : c’est l’étape à ne jamais sauter avant une mise en production, car elle révèle immédiatement les fautes de frappe dans les noms de clés .Values.

Étape 8 : Installer, mettre à jour et revenir en arrière (rollback)

Une fois le rendu validé, installez pour de vrai :

helm install mon-app ./mon-app --namespace demo
helm upgrade mon-app ./mon-app --namespace demo --set image.tag=1.1.0
helm history mon-app -n demo
helm rollback mon-app 1 -n demo

C’est l’un des plus gros avantages de Helm face à des manifestes YAML bruts appliqués via kubectl apply : chaque upgrade crée une nouvelle révision, et helm rollback permet de revenir en une commande à un état antérieur connu, sans reconstruire manuellement les anciens fichiers.

Étape 9 : Surcharger les valeurs avec –set et des fichiers par environnement

Pour un ajustement ponctuel, utilisez --set. Pour une configuration complète d’environnement, préférez un fichier de valeurs dédié :

helm upgrade mon-app ./mon-app -n prod \
  -f values.yaml \
  -f values-prod.yaml \
  --set replicaCount=5

Helm fusionne les fichiers dans l’ordre où ils sont passés : le dernier -f ou --set l’emporte sur les précédents. Gardez toujours values.yaml comme base commune et ne mettez dans les fichiers d’environnement que les différences réelles (nombre de réplicas, domaine, limites de ressources).

Un piège classique à ce stade consiste à copier l’intégralité de values.yaml dans chaque fichier d’environnement, puis à ne modifier qu’une seule ligne. Six mois plus tard, une nouvelle option ajoutée au chart n’apparaît que dans certains fichiers d’environnement, ce qui provoque un comportement différent entre staging et production sans qu’aucune erreur ne soit levée. Ne surchargez que ce qui doit réellement changer, jamais l’ensemble du fichier.

Étape 10 : Ajouter des dépendances de chart (subcharts)

Si votre application a besoin d’une base de données ou d’un cache, déclarez-les comme dépendances dans Chart.yaml plutôt que de les redéployer manuellement :

dependencies:
  - name: redis
    version: "20.x.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: redis.enabled

Téléchargez ensuite les dépendances avant d’installer :

helm dependency update ./mon-app

Le champ condition permet d’activer ou désactiver la dépendance depuis values.yaml, utile quand vous utilisez un Redis externe géré en production mais un Redis local en développement.

Étape 11 : Packager et publier le chart sur un registre OCI

Depuis Helm 3.8 et de façon généralisée en 2026, les registres OCI (Docker Hub, GHCR, ECR, Harbor) sont devenus la méthode de distribution recommandée pour les charts, au même titre que les images de conteneurs. Le chart devient un artefact versionné et immuable dans le même registre que vos images applicatives :

helm package ./mon-app
helm registry login registry.example.com
helm push mon-app-0.1.0.tgz oci://registry.example.com/charts
helm install mon-app oci://registry.example.com/charts/mon-app --version 0.1.0

Cette approche remplace progressivement les anciens dépôts basés sur un fichier index.yaml statique hébergé sur un simple serveur HTTP, plus difficile à sécuriser qu’un registre OCI avec contrôle d’accès natif. La documentation officielle sur les registres OCI détaille les options avancées, comme l’authentification via des jetons à courte durée de vie plutôt que des identifiants statiques stockés en clair dans la configuration CI.

Étape 12 : Automatiser Helm en CI/CD et GitOps

En production, on évite les helm install manuels depuis un poste de développeur. Deux approches dominent en 2026 :

Pipeline CI classique (GitHub Actions, GitLab CI) qui exécute helm upgrade --install après les tests, avec le chart poussé depuis le registre OCI.
GitOps avec Argo CD, qui surveille un dépôt Git contenant les références de charts et applique automatiquement les changements sur le cluster.

Extrait minimal pour GitHub Actions :

- name: Deploy with Helm
  run: |
    helm upgrade --install mon-app oci://registry.example.com/charts/mon-app \
      --version ${{ github.sha }} \
      --namespace prod \
      -f values-prod.yaml \
      --atomic --timeout 5m

Le drapeau --atomic force un rollback automatique si le déploiement échoue, ce qui évite de laisser un cluster dans un état intermédiaire cassé après un déploiement CI raté. Pour un pipeline complet, notre tutoriel Azure DevOps détaille la mise en place d’un pipeline CI/CD généraliste que vous pouvez adapter à Helm.

Que vous choisissiez le pipeline CI classique ou le GitOps, gardez le même principe : le cluster ne doit jamais recevoir de helm install ou helm upgrade lancé manuellement depuis un poste de travail en production. Toute modification doit passer par le même chemin automatisé et traçable, avec un historique de déploiement consultable dans les logs CI ou dans l’interface Argo CD, plutôt que dans la mémoire d’un développeur.

Sécuriser les secrets dans vos charts Helm

L’erreur la plus fréquente chez les équipes qui débutent avec Helm consiste à mettre des mots de passe ou des clés API en clair dans values.yaml, un fichier généralement versionné dans Git. Une fois qu’un secret a été committé, même sa suppression ultérieure ne l’efface pas de l’historique Git : il reste récupérable par quiconque a accès au dépôt, ce qui oblige à une rotation complète du secret exposé plutôt qu’à une simple correction du fichier. Trois approches évitent ce piège dès le départ :

Le plugin helm-secrets combiné à SOPS pour chiffrer les fichiers de valeurs sensibles avant de les committer.
Sealed Secrets, qui chiffre un Secret Kubernetes côté client pour qu’il ne soit déchiffrable que par le contrôleur du cluster cible.
Un opérateur de secrets externe (External Secrets Operator) qui va chercher les valeurs dans un coffre-fort (Vault, AWS Secrets Manager) au moment du déploiement, sans jamais les stocker dans le chart.

Pour une gestion plus poussée des secrets Kubernetes natifs, notre tutoriel dédié aux secrets Kubernetes détaille la configuration de ces trois options pas à pas.

5 pièges fréquents avec Helm (et comment les éviter)

Voici les erreurs les plus courantes constatées chez les équipes qui adoptent Helm, avec la correction associée. La plupart de ces pièges ne se manifestent pas lors des premiers tests sur un cluster local, mais apparaissent une fois que plusieurs équipes ou plusieurs environnements partagent les mêmes charts.

Piège	Conséquence	Correction
Secrets en clair dans values.yaml	Fuite de credentials via Git	helm-secrets + SOPS ou External Secrets Operator
Pas de helm lint avant install	Erreurs de syntaxe détectées trop tard en cluster	Ajouter helm lint et helm template au pipeline CI
Trop de logique conditionnelle imbriquée	Templates illisibles et difficiles à maintenir	Extraire la logique dans des helpers _helpers.tpl
Réutiliser –set pour toute la config	Commandes de déploiement longues et non reproductibles	Fichiers values-{env}.yaml versionnés
Absence de –atomic en CI	Cluster dans un état intermédiaire après un échec	Toujours utiliser –atomic –timeout dans les pipelines

Dépannage Helm : 8 erreurs fréquentes et leurs solutions

Même avec un chart bien écrit, Helm renvoie régulièrement les mêmes catégories d’erreurs. La plupart se résolvent en quelques secondes une fois qu’on sait où regarder. Voici les erreurs les plus signalées par les utilisateurs de Helm et comment les résoudre, classées de la plus fréquente pour un débutant à la plus spécifique aux environnements de production.

“Error: INSTALLATION FAILED: cannot re-use a name that is still in use” : une release du même nom existe déjà dans le namespace. Utilisez helm list -n <namespace> pour vérifier, puis helm uninstall si nécessaire ou changez le nom de release.
“Error: UPGRADE FAILED: another operation (install/upgrade/rollback) is in progress” : une opération précédente s’est mal terminée. Résolvez avec helm rollback <release> 0 ou en dernier recours en supprimant le secret de release Helm bloqué.
“Error: template: mon-app/templates/deployment.yaml: nil pointer evaluating interface {}.tag” : une valeur attendue dans values.yaml est absente. Vérifiez l’orthographe exacte de la clé et ajoutez une valeur par défaut avec default.
“Error: found in Chart.yaml, but missing in charts/ directory” : une dépendance déclarée n’a pas été téléchargée. Exécutez helm dependency update avant l’installation.
Pods en CrashLoopBackOff après un helm install réussi : l’installation Helm elle-même a fonctionné mais l’application plante. Le problème est applicatif, pas Helm : inspectez avec kubectl logs et kubectl describe pod.
“Error: OOMKilled” lors du chargement d’un schéma JSON de chart : un schéma JSON malformé ou trop profondément imbriqué peut épuiser la mémoire sur les versions de Helm antérieures aux correctifs de 2025. Mettez à jour vers Helm 3.18.5 ou supérieur.
helm upgrade qui ne change rien visiblement : souvent lié à un cache local du dépôt obsolète. Lancez helm repo update avant de relancer l’upgrade.
Rollback qui échoue avec “no revision found” : l’historique de révisions a été purgé (limite par défaut ou nettoyage manuel). Vérifiez avec helm history <release> le numéro de révision réellement disponible avant de cibler un rollback précis.

Sécurité : les CVE Helm à connaître avant de déployer en production

Trois vulnérabilités Helm méritent une attention particulière avant tout déploiement en production en 2026. La première, un déni de service par épuisement mémoire lors du chargement d’un schéma JSON malveillant, a été corrigée dans Helm 3.18.5. La deuxième, une exécution de code local via un Chart.yaml couplé à un Chart.lock spécialement construit, avec un score CVSS de 8,5, a été corrigée dans Helm 3.18.4. La troisième, plus récente, concerne helm pull --untar qui pouvait écrire le contenu d’un chart dans un répertoire inattendu sur les versions antérieures à Helm 3.20.2 et 4.1.4.

Pourquoi ces failles touchent surtout les charts tiers non vérifiés

Les trois vulnérabilités ont un point commun : elles s’exploitent via un chart malveillant que quelqu’un installe, pas via une attaque réseau directe contre le binaire Helm. C’est pour cela que le risque grimpe fortement dès que votre équipe installe des charts provenant de dépôts tiers non audités. La bonne pratique consiste à limiter les sources de charts autorisées en production à une liste explicite de dépôts de confiance, et à faire passer tout chart externe par une revue avant de l’ajouter à cette liste.

Une équipe plateforme qui gère plusieurs dizaines de clusters peut aussi automatiser cette vérification avec un scanner de vulnérabilités pour conteneurs, comme celui que nous détaillons dans notre tutoriel Trivy, en intégrant le scan directement dans le pipeline qui packages et publie vos charts.

La règle pratique : ne restez jamais sur une version de Helm vieille de plus de deux cycles mineurs en production, et surveillez les avis de sécurité publiés par les distributions qui embarquent Helm (Red Hat, SUSE) en plus du dépôt officiel du projet. Pour le cluster lui-même, notre tutoriel Cilium complète cette approche côté réseau, une fois vos charts déployés.

Astuces avancées pour la production

Une fois les bases maîtrisées, quelques pratiques distinguent une utilisation Helm amateur d’une utilisation prête pour la production. Ces astuces viennent généralement après plusieurs mois d’usage, quand les premiers incidents de déploiement ont révélé les angles morts d’une configuration Helm trop basique.

Utilisez helm test pour exécuter des pods de vérification post-déploiement définis dans votre chart, avant de considérer un déploiement comme validé.
Passez par Helmfile pour orchestrer plusieurs releases et environnements de façon déclarative, plutôt que d’enchaîner des commandes helm manuelles dans des scripts shell.
Signez vos charts packagés avec une clé GPG (helm package --sign) pour garantir leur provenance avant publication sur un registre partagé par plusieurs équipes.
Limitez l’historique de révisions conservé avec --history-max pour éviter l’accumulation de secrets Helm obsolètes dans le cluster.
Séparez les charts “librairie” (type library dans Chart.yaml) des charts applicatifs quand plusieurs équipes partagent des helpers communs, pour éviter de dupliquer la même logique de templating dans chaque dépôt.

Pour les équipes qui pratiquent le déploiement progressif (canary releases, blue-green), Helm se combine bien avec des contrôleurs comme Flagger ou Argo Rollouts : le chart définit la structure de l’application, tandis que le contrôleur de rollout gère le basculement graduel du trafic entre l’ancienne et la nouvelle version. Cette séparation des responsabilités évite de réinventer une logique de rollout progressif directement dans les templates Helm, ce qui serait fragile et difficile à tester.

Migrer un projet existant de kubectl vers Helm

Si votre équipe gère déjà une application en production avec des manifestes YAML appliqués via kubectl apply -f, la migration vers Helm se fait sans interruption de service si elle est bien préparée. Commencez par générer un chart avec helm create, puis copiez le contenu de vos manifestes existants dans les templates correspondants, en remplaçant les valeurs codées en dur (nom d’image, nombre de réplicas, domaine) par des références à .Values.

L’étape critique est l’adoption des ressources déjà présentes dans le cluster. Sans précaution, un helm install sur des ressources qui existent déjà provoque une erreur de conflit de propriété. La solution consiste à annoter et labelliser manuellement les ressources existantes avant la première installation Helm :

kubectl annotate deployment mon-app \
  meta.helm.sh/release-name=mon-app \
  meta.helm.sh/release-namespace=prod
kubectl label deployment mon-app \
  app.kubernetes.io/managed-by=Helm

Une fois ces annotations posées sur chaque ressource concernée (Deployment, Service, ConfigMap), un helm install ciblant le même namespace et le même nom de release “adopte” les ressources existantes sans les recréer ni provoquer de coupure. Testez systématiquement cette procédure sur un environnement de staging identique avant de la reproduire en production.

Helm vs kubectl vs Kustomize : quand utiliser quoi

Ces trois outils ne sont pas strictement concurrents et beaucoup d’équipes en combinent deux. kubectl apply convient pour des manifestes simples et statiques, sans logique de templating ni gestion de versions. Kustomize excelle pour des overlays déclaratifs sans langage de templating (patchs YAML purs), un choix apprécié par les équipes qui veulent éviter la syntaxe Go de Helm. Helm reste le plus adapté dès que vous distribuez un logiciel à des tiers, gérez des dépendances entre composants, ou avez besoin d’un historique de révisions avec rollback intégré.

Critère	kubectl apply	Kustomize	Helm
Templating	Aucun	Patchs YAML uniquement	Langage Go complet
Gestion de versions	Aucune	Non native	Releases avec historique
Rollback intégré	Non	Non	Oui, helm rollback
Gestion de dépendances	Non	Non	Oui, subcharts
Courbe d’apprentissage	Faible	Moyenne	Moyenne à élevée
Adoption CNCF 2025	Base native	Intégré à kubectl	75 % préférence package manager

Dans la pratique, une équipe de taille moyenne combine souvent les trois : kubectl pour le débogage ponctuel et les commandes d’inspection, Kustomize pour des overlays simples sur des manifestes tiers qu’elle ne veut pas réécrire en chart, et Helm pour tout ce qui doit être versionné, distribué et réutilisé entre équipes ou entre clusters. Le choix n’est donc pas exclusif : il dépend de la stabilité et de la complexité de chaque composant applicatif.

Le projet complet : structure finale du chart

À l’issue de ce tutoriel, votre projet doit ressembler à ceci :

mon-app/
├── Chart.yaml
├── values.yaml
├── values-staging.yaml
├── values-prod.yaml
├── charts/
│   └── redis-20.x.x.tgz
├── templates/
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   ├── _helpers.tpl
│   └── tests/
│       └── test-connection.yaml
└── .helmignore

Ce squelette, packagé et publié sur un registre OCI, constitue une base réutilisable pour n’importe quel microservice de votre organisation : il suffit de dupliquer le dossier templates/ et d’ajuster values.yaml pour chaque nouvelle application. Une fois ce premier chart validé, la plupart des équipes créent un “chart de référence” interne, versionné dans un dépôt Git séparé, que chaque nouvelle équipe copie pour démarrer un service sans repartir de zéro.

Sur un cluster de taille moyenne (une vingtaine de microservices), le passage de manifestes YAML bruts à des charts Helm structurés de cette façon réduit généralement le temps nécessaire pour ajouter un nouvel environnement de déploiement de plusieurs heures à quelques minutes, puisque la logique de templating est déjà écrite et testée : il ne reste qu’à fournir un nouveau fichier de valeurs.

Questions fréquentes sur Helm et les charts Kubernetes

Faut-il migrer vers Helm 4 dès maintenant ?
Si vous démarrez un nouveau projet, oui : Helm 4 est la version stable recommandée depuis fin 2025. Pour un projet existant en Helm 3, planifiez la migration sur plusieurs semaines en testant d’abord les charts critiques en environnement de pré-production, puis en basculant les pipelines non critiques avant les charts qui touchent directement les clients.

Helm fonctionne-t-il avec n’importe quel cluster Kubernetes managé ?
Oui, Helm est un client qui communique avec l’API Kubernetes standard. Il fonctionne aussi bien avec un cluster local Minikube qu’avec AKS, EKS ou GKE, sans installation côté serveur particulière depuis Helm 3.

Quelle est la différence entre un chart et une release ?
Le chart est le paquet source réutilisable (templates + valeurs par défaut). La release est une instance déployée de ce chart dans un namespace donné, identifiée par un nom unique et un historique de révisions.

Peut-on utiliser Helm sans écrire de templates Go ?
Oui, en installant simplement des charts publics existants depuis Artifact Hub ou un dépôt d’éditeur (Bitnami, par exemple), sans jamais toucher à la syntaxe de templating.

Comment gérer plusieurs environnements avec un seul chart ?
En superposant plusieurs fichiers de valeurs (values.yaml plus values-staging.yaml ou values-prod.yaml) au moment de l’installation, sans dupliquer les templates eux-mêmes.

Les registres OCI remplacent-ils complètement les anciens dépôts Helm ?
La tendance 2026 va clairement dans ce sens pour les nouveaux projets, car les registres OCI offrent un contrôle d’accès et un stockage unifié avec les images de conteneurs. Les anciens dépôts basés sur un index.yaml restent supportés mais ne sont plus la méthode recommandée par défaut.

Que faire si helm upgrade casse la production ?
Utilisez immédiatement helm rollback <release> <revision> pour revenir à la dernière révision stable connue. En CI/CD, le drapeau --atomic déclenche ce rollback automatiquement en cas d’échec du déploiement, sans intervention manuelle, ce qui limite le temps d’indisponibilité à la durée du health check qui a détecté l’échec.

Faut-il un plugin spécifique pour gérer les secrets avec Helm ?
Ce n’est pas obligatoire mais fortement recommandé. Le plugin helm-secrets associé à SOPS, ou un opérateur de secrets externe connecté à un coffre-fort, évite de stocker des identifiants en clair dans un dépôt Git versionné.

Quels changements cassants Helm 4 introduit-il par rapport à Helm 3 ?
Helm 4 rend permanents plusieurs comportements qui étaient optionnels dans Helm 3.6, notamment le nouveau format de bundle pour les signatures et le paramètre de racine de confiance. Si vos charts utilisent des attestations ou des vérifications de provenance, testez-les explicitement sur Helm 4 avant la bascule plutôt que de supposer une compatibilité totale avec vos scripts Helm 3 existants.

Helm : Déployer sur Kubernetes en 12 Étapes, 90 Min [2026]