« Kubernetes » figure aujourd’hui sur une grande partie des CV de développeurs, de DevOps et d’ingénieurs cloud. Le mot seul ne dit pourtant presque rien au lead qui recrute. Entre un développeur qui pousse son application sur un cluster préparé par une autre équipe, un ingénieur qui administre ce cluster et un architecte qui conçoit la plateforme sur laquelle travaillent vingt équipes, l’écart de compétences est immense. Un CV qui ne précise pas lequel de ces trois profils vous êtes vous expose à deux risques : être écarté d’un poste à votre portée, ou être retenu pour un poste qui vous dépasse. Cet article propose des formulations pour chaque niveau.
Trois niveaux d’usage que le recruteur distingue
Kubernetes 🔗 est un orchestrateur de conteneurs : il déploie, met à l’échelle et redémarre des applications conteneurisées sur un ensemble de machines. Autour de lui gravitent trois métiers, que les offres d’emploi distinguent de plus en plus clairement.
- Utiliser Kubernetes pour déployer ses applications. C’est le quotidien d’un développeur backend ou full-stack dans une organisation qui a une équipe plateforme. Vous écrivez ou modifiez des manifestes (Deployment, Service, ConfigMap), des charts Helm ou des fichiers de configuration fournis par la plateforme, et vous savez lire les journaux d’un pod en erreur.
- Administrer des clusters. C’est le travail d’un ingénieur DevOps, SRE ou d’exploitation. Vous gérez la création et la mise à jour des clusters, le réseau, le stockage, les droits d’accès, la supervision, les sauvegardes, et vous intervenez quand un nœud tombe.
- Concevoir une plateforme. C’est le travail d’une équipe plateforme ou d’un architecte. Vous définissez comment les équipes produit déploient, avec quels outils, quelles règles de sécurité, quel modèle de multi-locataire, et vous mesurez la fiabilité de l’ensemble.
Le recruteur cherche à savoir où vous vous situez, et le lead le vérifiera en entretien. Votre CV doit donc l’écrire noir sur blanc, dans les expériences et pas seulement dans la rubrique compétences.
Formuler une expérience de déploiement
Pour un développeur, l’enjeu est de montrer que vous êtes autonome pour faire tourner votre service, sans prétendre administrer le cluster.
Avant : « Docker, Kubernetes, CI/CD. »
Après : « Conteneurisation de 4 services Node.js avec Docker et déploiement sur le cluster Kubernetes de l’équipe plateforme via des charts Helm ; configuration des sondes de disponibilité et des limites de ressources ; diagnostic des incidents de déploiement à partir des journaux et des événements des pods. »
La seconde formulation dit qui gère le cluster, ce que vous faites vous-même et sur combien de services. Elle mentionne des notions précises (sondes, limites de ressources) qui montrent une vraie pratique. Dans la rubrique compétences, la mention devient : « Kubernetes (déploiement d’applications, Helm) ».
Formuler une expérience d’administration
Pour un profil DevOps ou SRE, il faut montrer le périmètre administré et ce que vous y avez changé.
Avant : « Administration de clusters Kubernetes. »
Après : « Administration de 3 clusters EKS (production, préproduction, outillage) hébergeant 60 services ; mises à jour de version trimestrielles sans interruption ; mise en place de l’autoscaling des nœuds et des pods ; supervision avec Prometheus et Grafana ; gestion des accès par rôles avec l’équipe sécurité. »
Cette version donne le nombre de clusters, leur usage, le volume de services, et des responsabilités concrètes d’exploitation. Le mot « sans interruption » appellera une question en entretien : préparez la façon dont vous avez organisé ces mises à jour. Le modèle de CV d’ingénieur DevOps ou SRE illustre ce type de puce, avec un indicateur de fiabilité à chaque fois.
Formuler une expérience de conception de plateforme
Au niveau plateforme, le recruteur veut lire des décisions, des utilisateurs internes et un effet mesuré sur la livraison.
Avant : « Conception d’une plateforme Kubernetes. »
Après : « Conception de la plateforme de déploiement commune à 18 équipes produit : clusters GKE créés en Terraform, déploiement GitOps avec Argo CD, gabarits Helm standardisés et règles de sécurité appliquées par politique ; délai de mise en ligne d’un nouveau service ramené de deux semaines à une journée. »
Ici, Kubernetes n’est plus qu’une brique parmi d’autres. Ce qui compte, ce sont les choix (GitOps, gabarits, politiques), le nombre d’équipes servies et le gain obtenu. C’est cette dimension que l’on attend d’un profil senior ou staff, et qu’il faut faire apparaître dès l’accroche.
Docker, Helm et services managés : ce qu’on cite avec
Kubernetes ne s’écrit jamais seul. Les technologies qui l’accompagnent précisent votre niveau aussi sûrement qu’une phrase.
- Docker ou un autre outil de construction d’images : attendu à tous les niveaux. Citez-le, mais il ne vous distingue pas.
- Helm 🔗 ou Kustomize : signale que vous packagez et paramétrez vos déploiements. Au niveau déploiement, c’est souvent l’outil que vous manipulez le plus.
- Les services managés : EKS 🔗 chez AWS, GKE 🔗 chez Google Cloud, AKS 🔗 chez Azure. Les nommer indique sur quel cloud vous avez travaillé et évite qu’on vous imagine administrer des machines physiques.
- Les outils GitOps (Argo CD, Flux) : marqueurs d’un niveau administration ou plateforme.
- L’infrastructure as code (Terraform, Pulumi) : indique que vous créez les clusters, et pas seulement que vous les utilisez.
- La supervision et la sécurité (Prometheus, Grafana, OpenTelemetry, politiques d’admission, gestion des secrets) : marqueurs d’un niveau exploitation.
Regroupez ces outils dans une même ligne « Conteneurs et plateforme » de votre rubrique compétences, plutôt que de les disperser. Notre article sur la présentation de la stack technique détaille cette logique de regroupement par usage.
Les certifications de la CNCF peuvent aussi situer votre niveau. La CKAD 🔗 vise les développeurs qui déploient des applications ; la CKA 🔗 vise l’administration de clusters ; la CKS 🔗 porte sur la sécurité. Ce sont des examens pratiques, passés sur un terminal, que les équipes plateforme connaissent bien. Indiquez-les dans la rubrique formation avec leur date.
Les questions d’entretien qui vérifient le niveau annoncé
Le lead qui lit « Kubernetes » sur votre CV a quelques questions prêtes, qui correspondent aux trois niveaux. Préparez-vous à celles de votre niveau, et un peu au-delà.
Niveau déploiement :
- Quelle différence entre un Deployment et un StatefulSet ?
- À quoi servent les sondes de disponibilité et de vivacité, et que se passe-t-il quand elles échouent ?
- Comment injectez-vous la configuration et les secrets dans un pod ?
- Votre pod redémarre en boucle : que regardez-vous en premier ?
Niveau administration :
- Comment mettez-vous à jour la version d’un cluster sans interruption de service ?
- Comment fonctionne l’autoscaling 🔗 des pods et des nœuds, et quelles sont ses limites ?
- Comment organisez-vous les droits d’accès entre équipes ?
- Un nœud devient indisponible en pleine journée : que se passe-t-il pour les applications, et que faites-vous ?
Niveau plateforme :
- Comment avez-vous décidé entre un cluster partagé et un cluster par équipe ?
- Comment les équipes produit déploient-elles sans connaître Kubernetes en détail ?
- Comment mesurez-vous la fiabilité de la plateforme, et qui est responsable quand un service tombe ?
Pour la façon de raconter vos expériences en entretien, notre article sur la préparation d’un entretien technique donne une méthode en couches qui s’applique bien à une architecture de déploiement.
Une fois les formulations trouvées, faites en sorte qu’elles soient lues. L’éditeur de TechCV met en page vos expériences sans colonnes ni icônes, et le PDF obtenu reste lisible par les logiciels de tri, qui retrouvent ainsi Kubernetes et ses compagnons là où vous les avez écrits. Vous pouvez reprendre votre CV en partant du modèle DevOps.
Questions fréquentes
Peut-on écrire Kubernetes si l’on n’a fait que déployer ?
Oui, et il faut le faire, car l’offre le cite probablement. Précisez simplement le niveau : « Kubernetes (déploiement d’applications sur un cluster existant, Helm) ». Cette honnêteté vous évite un entretien centré sur l’administration et rassure le lead sur le reste de votre CV.
Minikube ou un cluster personnel comptent-ils comme expérience ?
Ils comptent comme apprentissage. Mentionnez-les dans un projet personnel, avec ce que vous y avez fait (déploiement d’une application à plusieurs services, ingress, supervision), mais ne les présentez pas comme une expérience de production.
La certification CKA suffit-elle pour un poste DevOps ?
Elle aide à passer le premier tri et prouve que vous savez manipuler un cluster. Elle ne remplace pas une expérience d’exploitation : les recruteurs chercheront aussi un périmètre réel, des incidents gérés et des mises à jour menées.
Faut-il mentionner OpenShift ou Rancher ?
Oui, si vous les avez utilisés : ce sont des distributions de Kubernetes répandues dans les grandes entreprises et chez les hébergeurs. Citez-les à côté de Kubernetes, avec votre niveau d’usage, car certaines offres les recherchent explicitement.