Sur LinkedIn, en conférence, en entretien technique : Kubernetes est partout. Des entreprises qui n’ont pas encore validé leur produit provisionnent déjà des clusters multi-nœuds, écrivent des Helm charts et débattent de leur stratégie de service mesh. Dans la majorité des cas que j’ai croisés, ce n’était pas nécessaire.

Le syndrome du marteau

“Quand on a un marteau dans les mains, on pense que tout est un clou.” Kubernetes est devenu ce marteau. Il est sexy, il fait bien sur un CV, il est LA réponse qu’on attend en entretien quand on parle de scalabilité. Sauf que la scalabilité n’est pas un problème du jour 1. C’est une étape dans l’évolution d’un produit, qui arrive quand le produit a prouvé qu’il fonctionne et qu’il a effectivement besoin d’absorber de la charge.

Avant d’en arriver là, l’objectif d’une entreprise n’est pas de faire des choses compliquées pour le plaisir des technicien(ne)s. C’est de dégager du chiffre d’affaires. Une infrastructure Kubernetes que personne dans l’équipe ne maîtrise, pour un produit qui n’a pas encore trouvé ses utilisateurs, ne sert ni l’un ni l’autre.

Un cas vécu

J’ai été confronté à ce contexte dans une entreprise. Le produit s’appuyait sur des modèles de machine learning pour reconstruire des images 3D à partir d’images 2D, une charge d’inférence typiquement variable et candidate naturelle à une infra “scalable”.

Un architecte a conçu, en amont, une infrastructure Kubernetes pensée pour absorber une montée en charge à venir. Sur le papier c’était cohérent avec le besoin produit. Dans les faits :

• Une seule personne, devops junior, était en charge de déployer et maintenir cette infrastructure.
• Une seule personne côté MLOps, également junior, sans connaissance de Kubernetes, devait faire tourner les modèles dessus.
• Le volume à traiter au démarrage était très faible, avec une montée en charge qui devait être progressive.

Résultat : deux personnes juniors se retrouvaient à porter la complexité opérationnelle d’un cluster (réseau, ordonnancement, observabilité, mises à jour, sécurité) pour un volume qui aurait tenu sur une poignée de conteneurs managés, voire sur du serverless pur. L’énergie de l’équipe est allée dans la compréhension de Kubernetes plutôt que dans l’amélioration du produit ou la fiabilisation des modèles. Le risque opérationnel (un cluster mal maîtrisé qui tombe) a été introduit avant même que la charge ne le justifie.

Ce n’est pas un problème de compétence individuelle. C’est un problème de séquencement : on a dimensionné pour un futur incertain avant d’avoir validé le présent.

Vérifier que le produit fonctionne avant de scaler

Avant toute infrastructure complexe, deux questions devraient être tranchées :

1. Le produit répond-il à un besoin réel, avec des utilisateurs qui reviennent ?
2. A-t-on effectivement du volume à absorber, ou anticipe-t-on un volume hypothétique ?

Tant que la réponse à la première question n’est pas claire, investir dans la scalabilité, c’est optimiser une variable qui n’est pas le facteur limitant. Le risque n’est pas de manquer de capacité, il est de construire quelque chose que personne n’utilise, avec une infrastructure sophistiquée en prime.

Une approche itérative

Plutôt que de partir directement sur Kubernetes, une progression par paliers, en fonction du volume réel et de la maturité de l’équipe, marche mieux dans la grande majorité des cas :

1. Cloud Functions (serverless) : zéro gestion d’infra, facturation à l’usage, adapté à un volume faible ou irrégulier. C’est le bon point de départ pour valider un besoin sans immobiliser de ressources humaines sur l’infra.
2. Cloud Run (conteneurs managés) : on garde la flexibilité du conteneur (dépendances, runtime, temps d’exécution plus long) sans la charge opérationnelle d’un orchestrateur. C’est l’étape naturelle quand le serverless devient limitant (cold starts, durée, mémoire) mais que la charge ne justifie pas encore un cluster.
3. Kubernetes : quand la charge est là, réelle et mesurée, que les besoins d’orchestration deviennent complexes (multi-services, scaling fin, topologies réseau spécifiques), et surtout que l’équipe a les compétences ou les moyens de les acquérir pour l’opérer durablement.

Dans le cas vécu plus haut, l’équipe aurait probablement pu tenir l’étape 1 ou 2 pendant plusieurs mois, le temps de stabiliser les modèles et de monter en compétence, avant d’envisager Kubernetes.

Quand Kubernetes est justifié

Ce n’est pas une charge contre Kubernetes en tant que tel. C’est un outil solide, et il devient le bon choix quand plusieurs conditions se rejoignent :

• Le produit a une traction avérée, avec une charge réelle et croissante à absorber.
• L’équipe dispose de compétences DevOps/SRE en interne, ou a le budget pour se les offrir (plateforme managée, prestataire, recrutement), et pas une seule personne junior qui porte le sujet seule.
• Les besoins dépassent ce qu’un service managé (Cloud Run, ECS, App Runner) peut couvrir : orchestration multi-services fine, autoscaling avancé, contraintes réseau ou de sécurité spécifiques.
• Le coût d’opération (temps humain, formation, veille sécurité) a été mis en face du gain attendu, pas seulement de l’attrait technique.

Si ces conditions ne sont pas réunies, Kubernetes n’ajoute pas de valeur : il ajoute de la complexité et du risque, financé par une équipe qui pourrait investir ce temps ailleurs.

Conclusion

Tout est une question de contexte, de moyens financiers et humains. La scalabilité ne se décrète pas au jour 1, elle se mérite à mesure que le produit prouve qu’il en a besoin. Avant de sortir le marteau Kubernetes, il vaut mieux vérifier qu’on a bien affaire à un clou.