On l’entend partout. Des entreprises qui « migrent vers le cloud », qui ont besoin d’« orchestration de conteneurs », ou qui « font tourner Kubernetes ». Cela sonne comme l’étape logique suivante dès que vos applications ne tournent plus seulement sur votre propre ordinateur portable. Et soyons honnêtes : si vous cherchez sur Google comment mettre vos conteneurs Docker en production, vous tombez vite sur des tutoriels qui présentent Kubernetes comme une évidence.
Mais Kubernetes résout un type de problème bien précis. Et ce problème n’est pas « j’ai une application qui doit tourner quelque part ». C’est : « j’ai des centaines de services qui montent en charge indépendamment, doivent tourner répartis sur plusieurs serveurs et converger en permanence vers un état souhaité. » C’est un problème qu’ont Netflix, Uber et Google. Pas la plupart des PME.
Dans cet article : ce que Kubernetes vous apporte vraiment, ce que vous réglez déjà avec des outils plus simples, et quand le passage a réellement du sens.
Ce que Kubernetes résout vraiment
Commençons honnêtement : Kubernetes n’est pas un jouet. Il résout de vrais problèmes que des outils plus simples ne traitent pas, ou moins bien. Les principaux :
- Haute disponibilité. Si un serveur tombe, Kubernetes replace automatiquement votre application sur un autre. Sans intervention humaine.
- Auto-réparation au niveau des nœuds. Docker Compose redémarre un conteneur planté, mais si l’hôte lui-même est mort, il ne se passe rien. Kubernetes détecte un nœud mort et déplace les charges de travail.
- Mises à jour progressives sans interruption. Une nouvelle version ne reçoit du trafic qu’une fois vraiment saine, vérifiée par des readiness probes. Pas de courte coupure à chaque déploiement.
- Montée en charge automatique. Ajouter des instances selon le CPU, la mémoire ou des métriques personnalisées, sans action humaine.
- Réconciliation déclarative. Quelqu’un arrête un conteneur par erreur ? Kubernetes le relance. Le système converge en permanence vers l’état souhaité.
Ce sont toutes des choses que vous voulez, si vous avez l’échelle à laquelle elles deviennent nécessaires.
La question à vraiment se poser
La question n’est pas « Kubernetes est-il bon ? ». Il l’est. La question est : « ai-je le problème qu’il résout ? »
Pour la grande majorité des applications de PME, la réponse honnête est non. Une application qui tourne très bien sur un ou deux serveurs n’a pas besoin d’un cluster de plusieurs nœuds. Une équipe de cinq personnes qui maintient ensemble un seul système n’a pas besoin d’une plateforme d’orchestration pour gérer des dizaines de services qui montent en charge indépendamment.
Cela rejoint ce que nous écrivions sur le surdimensionnement : Kubernetes fait souvent partie de ces schémas qui font grimper votre budget logiciel sans que vous le remarquiez. Non pas parce que c’est une mauvaise technologie, mais parce qu’il ajoute une complexité que le problème de fond ne demande pas. Ce que vous montez avec docker compose et un bon reverse proxy, n’importe quel développeur peut l’expliquer en une heure. Ce que vous montez avec un cluster Kubernetes demande un spécialiste pour le modifier, et ce spécialiste est rare et cher.
Ce que vous réglez déjà sans Kubernetes
Une bonne partie de ce qui pousse les gens vers Kubernetes se traite correctement avec des outils plus simples :
- Reverse proxy + TLS automatique : Traefik ou Caddy dans votre stack Compose.
- Déploiements sans interruption : Traefik en blue-green, ou Docker Swarm.
- Plusieurs hôtes et bascule : Docker Swarm (intégré à Docker, pour une fraction de la complexité).
- Interface de gestion : Portainer.
- Monitoring et alertes : Prometheus + Grafana, qui tournent aussi très bien dans Compose.
Docker Swarm est d’ailleurs injustement délaissé. Il vous donne la planification sur plusieurs hôtes, les mises à jour progressives, la découverte de services et la bascule, sans la charge opérationnelle d’un cluster Kubernetes complet. Pour beaucoup de PME qui veulent « plus d’un serveur », c’est la première étape logique, pas Kubernetes.
Vos secrets non plus n’ont pas besoin de migrer vers Kubernetes. Des outils comme SOPS (SOPS-age ou SOPS-GPG) sont une très bonne solution indépendante de la plateforme, souvent même plus robuste que les Kubernetes Secrets standard (qui, par défaut, sont seulement encodés en base64, pas chiffrés).
Quand le passage a vraiment du sens
Il y a des situations où Kubernetes est le bon choix. Les signes que vous y êtes :
- Vous faites tourner des dizaines de services qui montent en charge et se déploient indépendamment les uns des autres.
- Un seul serveur n’est plus envisageable, non pas pour des raisons de budget, mais parce que vos exigences de disponibilité demandent une vraie bascule entre plusieurs machines physiques.
- Vous avez une équipe capable de le maintenir. Pas un développeur enthousiaste isolé, mais des gens qui prennent en charge de façon structurée les mises à jour, les correctifs de sécurité et le monitoring. Maintenant que de plus en plus de PME entrent dans le champ de NIS2, ce n’est pas un luxe optionnel.
- Vous voulez être indépendant du fournisseur cloud et éviter la dépendance à un fournisseur, et vous avez l’échelle pour le justifier.
Vous cochez deux de ces points ou plus ? Alors un Kubernetes managé, comme Scaleway Kapsule, Azure AKS ou Google GKE, est un choix logique. Attention : managé. Monter et maintenir soi-même un cluster Kubernetes n’est une bonne idée pour quasiment aucune PME.
Comment nous faisons chez Tandem
Pas de surprise si vous avez lu nos autres articles : nous restons volontairement ennuyeux. Notre stack par défaut, c’est un ou deux serveurs d’application chez Scaleway, Postgres, Go comme langage, Traefik comme reverse proxy, et docker compose pour l’orchestration. Pas de Kubernetes, sauf s’il existe une raison opérationnelle concrète qui le justifie.
Ce n’est pas une aversion de principe pour Kubernetes. C’est le constat que, pour 95 % des applications de PME que nous construisons, la complexité d’un cluster ne vaut pas le bénéfice. Un serveur que tout développeur comprend est moins cher, plus stable et plus rapide à faire évoluer qu’un écosystème qui exige un spécialiste.
Quand un client a vraiment l’échelle à laquelle Kubernetes devient pertinent, et ça arrive, nous le mettons en place. Mais nous ne l’imposons pas. De même que nous demandons d’abord s’il faut vraiment construire quelque chose, nous demandons d’abord s’il faut vraiment introduire cette complexité.
Pour conclure
La règle empirique est simple : si vous devez vous demander si vous avez besoin de Kubernetes, vous n’en avez probablement pas besoin.
Partez de ce que le problème demande aujourd’hui. Un VPS avec Docker Compose, un bon reverse proxy, de bonnes sauvegardes, et un monitoring qui vous dit quand quelque chose ne va pas. Ce n’est que lorsque vous touchez vraiment les limites de cette configuration (plusieurs serveurs, une charge qui doit suivre de façon élastique, des équipes qui doivent pouvoir déployer indépendamment) qu’il est temps de regarder Kubernetes.
D’ici là, la simplicité n’est pas un compromis. C’est un avantage stratégique.
Vous vous demandez si votre configuration actuelle suffit encore, ou vous en touchez les limites ? Nous regardons volontiers cela ensemble. Pas de discours commercial, juste une estimation honnête de ce dont vous avez vraiment besoin, et de ce dont vous n’avez pas besoin. Prenez rendez-vous pour faire connaissance.
