Faut-il du Kubernetes pour une petite équipe ?

J’ai déjà écrit ailleurs quand il ne faut pas faire de Kubernetes et je n’y reviens pas ici (voir kubernetes-ou-pas ). L’angle de ce billet est différent : une petite structure, un seul DevOps, quelques devs sans expérience infra et la question qui revient à chaque fois de savoir s’il faut adopter K8s ou pas.

La réponse n’est pas technique, elle est humaine. Je la pose sous forme de trois options, A, B et C, avec leurs limites respectives.

Option A : Kubernetes complet

K8s standardise tout ce qu’on finit de toute façon par reconstruire à la main : service discovery, rollout, drain, health checks, scheduling. C’est l’argument massue et il est réel.

Seulement, avec un seul DevOps et quatre devs sans expérience infra, le risque l’est tout autant. Si cette personne est la seule à comprendre la plateforme, chaque absence bloque tout le monde et le bus factor tombe à un. Des manifests K8s, pour des devs qui n’ont jamais touché d’infra, c’est un mur.

K8s ne se justifie donc que si le DevOps a le bagage pour le monter vite et, surtout, le temps d’accompagner l’équipe dans sa montée en compétence. Sans ce temps d’accompagnement, on n’a pas une plateforme, on a une dette avec un seul créancier. Et si l’on part quand même sur du K8s, le monter proprement (voir Kubernetes bare-metal en HA ) et le durcir (voir hardening Kubernetes ) fait partie du bagage, pas des options.

Option B : l’orchestration déléguée au provider

C’est le choix par défaut si le DevOps recruté a un profil cloud-native ou junior en infra. Il s’appuie sur le provider pour l’orchestration, le scaling et la haute disponibilité et se concentre sur ce qui apporte de la valeur visible : la CI/CD, l’observabilité et la DX.

La mise en production se compte en quelques semaines et l’équipe peut interagir avec la stack sans expertise infra pointue. La limite, elle, est connue : vendor lock-in et des coûts qui gonflent avec le trafic.

Je serai franc, c’est l’option que je retiendrais le moins volontiers. On y gagne du temps court et on y perd la main sur sa propre facture.

Option C : la solution intermédiaire

Entre les deux, il existe un espace où l’on récupère une partie des bénéfices d’orchestration sans imposer la pleine complexité de K8s à des gens qui n’y sont pas prêts. C’est l’option de compromis, celle qui garde une marge de réversibilité tout en restant accessible à l’équipe qui doit vivre avec au quotidien.

Ce qui tranche vraiment

Au final, le choix se fait sur deux axes et aucun des deux n’est une question d’architecture : les compétences réelles du DevOps et la capacité de toute l’équipe à interagir avec la stack au quotidien.

Dans beaucoup de contextes, les trois options peuvent fonctionner sur le papier. Ce qui fera la différence, c’est l’adéquation entre le choix technique et les gens qui le portent. Moi, je prendrais A ou C selon le bagage du DevOps et le temps d’accompagnement disponible ; quant à B, j’aurais du mal à le défendre de gaieté de coeur, même si je comprends qu’on y vienne par contrainte de calendrier.

YAGNI, tout simplement

• La question n’est pas de savoir si K8s est bon, mais si votre équipe peut vivre avec.
• Un seul DevOps qui comprend la plateforme, c’est un bus factor de un, donc un risque de blocage à chaque absence.
• Des manifests K8s restent un mur pour des devs qui n’ont jamais touché d’infra.
• B achète du temps court contre du lock-in et une facture qui grimpe.
• Le vrai critère, ce sont les compétences du DevOps et la capacité de toute l’équipe à vivre avec la stack, pas la mode.

[edit: 2026] L’implémentation Ansible de tout ceci: le rôle k0s .