Depuis des années, le choix d’une technologie relevait d’une décision d’ingénierie : coûts, risques, compétences de l’équipe et besoins réels. Mais dans une partie du secteur logiciel, Kubernetes est passé d’un outil — certes puissant — à un symbole de statut. Dans certaines interviews techniques, propositions commerciales ou même conversations informelles, la question semble devenue incontournable : « Utilisez-vous Kubernetes ? » Et, trop souvent, la réponse est perçue comme un gage de maturité ou, à l’inverse, d’obsolescence.

C’est cette critique fondamentale qui refait surface avec vigueur dans les communautés techniques suite à une réflexion approfondie publiée sur LinkedIn par un professionnel du cloud. Son argumentaire, provocateur mais accessible, évoque une certitude que tout professionnel ayant travaillé sur des infrastructures modernes peut reconnaître : Kubernetes est exceptionnel quand il résout le bon problème ; pour d’autres cas, il peut devenir un coût et une complexité inutiles.

De l’ingénierie au “culte du cargo” : imiter sans en saisir le coût

Ce propos s’appuie sur une idée classique du monde tech : le « culte du cargo », une métaphore illustrant la tendance à copier des rituels externes en espérant obtenir les mêmes résultats. Dans le contexte du cloud, cela revient à observer que des géants hyperscalaires ou des plateformes globales utilisent Kubernetes, et à croire qu’imiter cette architecture garantit automatiquement fiabilité, rapidité ou succès.

En réalité, nombre d’organisations découvrent tard que Kubernetes ne se limite pas à « orchestrer des conteneurs » : il introduit un véritable écosystème opérationnel. Configurations d’ingress, gestion des certificats, DNS automatique, politiques réseau, observabilité, gestion des secrets, mises à jour fréquentes, compatibilités entre versions… tout cela exige des compétences pointues pour l’administration quotidienne, sans transformer chaque incident en une nuit blanche.

Le rédacteur le souligne avec ironie : l’industrie a confondu « montée en charge » avec « crédibilité », comme si toute entreprise était confrontée à un problème avec des millions d’utilisateurs. Ce n’est pas le cas. La plupart cherchent simplement à déployer rapidement, sans erreur humaine, avec une haute disponibilité raisonnable et sans mobiliser la moitié de l’équipe sur la plateforme.

Le retour du sysadmin : prioriser les fondamentaux plutôt que la liturgie

Une autre dimension du débat touche à la culture IT : la perception selon laquelle le profil traditionnel d’administrateur systèmes — celui qui maîtrise le processus, la mémoire, le réseau, les permissions et le diagnostic — aurait été sous-estimé face à des rôles modernes recouverts de sigles et d’outils vantant l’abstraction.

Ce n’est pas une critique contre le cloud ou DevOps en soi, mais contre la « mise en scène de la complexité » : multiplier les couches comme preuve de sophistication. La leçon est simple : quand une panne survient à 3 heures du matin, ce qui sauve le système, ce n’est pas un slogan, mais la maîtrise des fondamentaux et la capacité de déboguer efficacement.

Le cas pratique : réduire le déploiement de plusieurs heures à quelques minutes sans Kubernetes

Ce qui intéresse le plus les équipes produit, c’est cette partie concrète : comment passer de déploiements manuels de 2,5 heures à un processus automatisé qui ne prend que quelques minutes, sans avoir recours à Kubernetes.

La solution s’appuie sur une approche courante chez AWS : utiliser ECS avec Fargate (des conteneurs « serverless » en ce sens qu’on ne gère pas les nœuds), associée à une automatisation par scripts (python avec boto3 par exemple) pour créer et configurer de façon idempotente les ressources. La recette, simple en apparence mais efficace, consiste à :

• construire et publier l’image du conteneur,
• déployer ou mettre à jour le service,
• configurer de manière automatisée le load balancer, les certificats et le DNS,
• laisser la plateforme gérer le déploiement continu (rolling) et la vérification de l’état des services.

L’objectif n’est pas de vanter Fargate comme la solution universelle, mais de montrer que, pour certains contextes de petite à moyenne taille, réduire la surface opérationnelle est souvent plus pertinent que de l’étendre.

Quand Kubernetes a-t-il du sens, et quand non ?

Ce raisonnement, malgré un ton volontairement critique, ne rejette pas catégoriquement Kubernetes. Au contraire, il propose un critère réfléchi que beaucoup de sociétés de conseil appliquent… même si ce n’est pas toujours le cas :

Kubernetes est pertinent lorsque :

• il y a des dizaines ou centaines de services aux besoins complexes,
• une équipe dédiée à la plateforme est en place,
• la portabilité (multi-cloud ou hybride) est essentielle,
• des patterns avancés (opérateurs, StatefulSets complexes, traitements par lots, maillages de services) doivent être déployés.

En revanche, des alternatives comme ECS/Fargate ou autres plateformes managées conviennent mieux lorsque :

• le nombre de services est modéré,
• l’équipe est petite ou souhaite se concentrer sur le produit plutôt que sur l’opération,
• la rapidité de déploiement prime sur un contrôle précis,
• on souhaite limiter le maintien de la couche d’orchestration.

Au fond, il s’agit de revenir à la question clé : “Quel est le problème réel que nous cherchons à résoudre ?” Si la réponse est “déployer vite et en toute sécurité”, alors la solution n’exige pas forcément la même complexité qu’une plateforme opérant à l’échelle mondiale.

Le piège du “standard de l’industrie”

Kubernetes est devenu la norme, oui. Mais « norme » ne signifie pas « obligatoire ». Cette confusion a un coût : architectures surdimensionnées, équipes épuisées par la gestion, budgets détournés vers la plateforme plutôt que vers le produit, et paradoxalement, des déploiements plus lents.

Ce débat n’est pas prêt de s’arrêter, car il mêle technologie et identité professionnelle. Mais il est précieux : dans un contexte où de nombreuses entreprises cherchent à gagner en efficacité, réduire la friction et accélérer leur time-to-market, remettre en question le « parce que c’est comme ça » peut s’avérer la décision la plus judicieuse.

Questions fréquentes

Kubernetes est-il indispensable pour une entreprise de taille moyenne ?
Pas nécessairement. C’est une solution adaptée si votre besoin en échelle, en complexité et en compétences est élevé. Cependant, beaucoup d’entreprises de taille intermédiaire parviennent à des déploiements solides en utilisant des plateformes gérées et des scripts d’automatisation.

Que signifie “culte du cargo” appliqué à Kubernetes ?
Il s’agit d’adopter des outils ou des architectures par imitation (parce que de grandes entreprises le font), sans évaluer si le coût opérationnel et la complexité sont en adéquation avec le problème réel et la taille de l’équipe.

Quelles alternatives à Kubernetes pour déployer des conteneurs en production ?
Tout dépend du fournisseur et du contexte : ECS/Fargate d’AWS, services managés de conteneurs, PaaS pour le déploiement continu, ou des approches plus simples avec automation et bonnes pratiques sur des VMs, lorsque c’est pertinent.

Comment déterminer si mon entreprise “a besoin” de Kubernetes ou si l’adopte sous pression du marché ?
Une piste : si gérer la plateforme mobilise une équipe dédiée ou détourne le focus du produit, si les mises à jour ou le diagnostic prennent trop de temps, et si vos besoins ne nécessitent pas une orchestration avancée, alors vous payez peut-être une complexité superflue.