Le mot revient de plus en plus souvent dans les réunions de direction : « il faudrait passer sur Kubernetes ». Suit une démonstration technique dont le dirigeant ressort convaincu que c'est important, sans savoir dire pourquoi.
Ce qu'on entend le plus souvent : Kubernetes serait une infrastructure moderne qui s'adapte toute seule à la charge, qui coûte moins cher parce qu'on ne paie que ce qu'on consomme, qui s'installe en quelques clics, et par laquelle toutes les entreprises sérieuses seraient déjà passées.
Chacune de ces idées reçues contient une part de vrai. Aucune n'est complète, et ce qui manque décide de la réussite ou de l'échec du projet.
Ce qui suit n'est pas une synthèse de documentation. C'est un retour de terrain accumulé depuis deux ans, sur des plateformes réelles, en production, dans des entreprises qui n'ont pas les moyens d'une direction informatique de grand groupe.
Kubernetes en une phrase
Vos applications tournent sur des serveurs. Quelqu'un doit décider laquelle tourne sur quelle machine, la redémarrer quand elle plante, en lancer une copie supplémentaire quand la charge augmente. Traditionnellement, ce quelqu'un est un administrateur système.
Kubernetes est le logiciel qui prend ces décisions à sa place. On lui décrit l'état souhaité, et il se charge en permanence de faire correspondre la réalité à cette description. Si une machine tombe, il redéploie ailleurs. Si une application plante, il la relance.
C'est un projet open source, gouverné par la Cloud Native Computing Foundation, utilisé aussi bien par des géants du web que par des structures de dix personnes. Cette double échelle est le piège dans lequel tombent beaucoup de PME.
Ce qui est vrai dans la promesse
Les quatre bénéfices existent réellement. Chacun a sa contrepartie.
La montée en charge. Une infrastructure classique se dimensionne pour le pic : on achète les serveurs du jour le plus chargé de l'année, et on les paie les 364 autres jours. Kubernetes ajuste automatiquement le nombre de copies d'une application selon la charge réelle. Mais cela suppose que l'application ait été conçue pour tourner en plusieurs exemplaires, ce qui n'est pas le cas de beaucoup de logiciels métier existants. Mettre une application non prévue pour ça derrière Kubernetes n'ajoute qu'une couche de complexité au-dessus du même goulot d'étranglement.
Le choix du fournisseur reste ouvert. Tous les grands hébergeurs proposent Kubernetes : AKS chez Azure, EKS chez AWS, GKE chez Google, et leurs équivalents chez OVHcloud, Scaleway ou Infomaniak. L'intérêt n'est pas technique, il est contractuel : une capacité de négociation au renouvellement, et une sortie de secours crédible. Mais la portabilité est partielle. Ce qui résiste, ce sont les services périphériques dans lesquels on finit par s'installer : base de données managée, stockage, authentification. Plus on les utilise, plus la porte se referme.
La localisation des données. Un hébergeur possède des dizaines de centres de données regroupés en régions. Déployer sur Kubernetes, c'est déclarer explicitement où chaque application et chaque donnée résident. Ce choix devient une ligne de configuration versionnée et vérifiable, au lieu d'une case cochée un jour par quelqu'un qui a quitté l'entreprise. Pour un audit RGPD, une réponse à appel d'offres public ou une clause avec un grand compte, pouvoir le démontrer change tout. Mais le multi-région double une partie de la facture. Pour la majorité des PME, le bon niveau est une seule région choisie en connaissance de cause, avec des sauvegardes ailleurs.
Les déploiements automatisés. C'est le vrai gain de sécurité, et celui dont on parle le moins. Kubernetes s'intègre dans une chaîne d'intégration et de déploiement continus : à chaque modification, les tests s'exécutent et la nouvelle version part en production sans intervention manuelle. Pour un RSSI, cela veut dire un correctif critique appliqué en vingt minutes au lieu d'un trimestre, un retour arrière immédiat en cas de problème, une configuration auditable, et des contrôles de sécurité automatiques qui bloquent le déploiement si nécessaire. Mais cette chaîne devient elle-même un actif critique : qui peut déclencher un déploiement peut exécuter du code en production.
La réalité : facile à installer, difficile à sécuriser dans la durée
Monter un cluster est étonnamment simple. Chez un hébergeur managé, quelques clics et vingt minutes. Cette facilité est trompeuse, parce que ce qu'on obtient n'est pas encore une plateforme utilisable.
Kubernetes n'est pas un produit fini
Livré nu, il ne sait ni faire communiquer vos applications entre elles, ni les exposer sur Internet, ni chiffrer leurs échanges. Chaque fonction est un composant séparé à choisir, installer et maintenir : un module réseau, un contrôleur d'entrée, un maillage de services pour le chiffrement interne, un opérateur par type de base de données, plus la gestion des certificats, des secrets, des sauvegardes et de la supervision.
Chacun a son éditeur, son rythme de publication et ses failles. Vous n'avez pas adopté un logiciel, vous en avez adopté une douzaine.
La rupture revient tous les quatre mois
Ces modules ne sont pas garantis compatibles entre eux, ni avec toutes les versions de Kubernetes. La combinaison exacte que vous avez retenue n'a peut-être jamais été testée par personne d'autre que vous.
Kubernetes publie trois versions par an, soit une échéance tous les quatre mois. Chaque version n'étant supportée qu'un an environ, rester en arrière signifie ne plus recevoir de correctifs de sécurité. Il faut donc monter. Et à chaque fois, la même question : est-ce que tous nos modules suivent déjà ? Souvent non. Parfois jamais, parce que le projet a été abandonné, et il faut alors le remplacer.
Surtout, ces montées de version sont douloureuses. Ce n'est jamais une simple mise à jour : il faut vérifier la compatibilité de chaque module, ajuster des configurations dont la syntaxe a changé, et accepter qu'une partie du travail se fasse à l'aveugle, sans certitude que la production redémarrera comme avant. Une équipe qui a vécu une montée difficile aborde la suivante avec appréhension, et l'appréhension a une conséquence prévisible : on repousse.
C'est ce qui explique que sur les plateformes que nous auditons, la version soit presque toujours en retard de deux ou trois cycles. Le mécanisme est constant : une montée se passe mal, la suivante est reportée à un moment plus calme qui n'arrive jamais, le retard s'installe. Et plus on attend, plus l'écart à rattraper est grand, donc plus l'opération devient risquée, donc plus on la repousse encore. Pendant ce temps, la plateforme ne reçoit plus de correctifs de sécurité.
Chaque composant est une porte de plus
C'est ici que le sujet devient un problème de sécurité.
Un contrôleur d'entrée est exposé sur Internet par définition. Un maillage de services intercepte tout le trafic interne. Un opérateur de base détient les accès aux données. La plupart de ces composants tournent avec des privilèges élevés, parce que leur fonction l'exige. Une faille dans l'un d'eux ne compromet pas un service isolé : elle compromet la plateforme.
Et ce ne sont pas des risques théoriques. Les briques qui composent un cluster font l'objet de vulnérabilités très régulièrement, y compris critiques : Kubernetes lui-même, les moteurs de conteneurs, les contrôleurs d'entrée exposés sur Internet, les maillages de services. C'est logique : ce sont des logiciels jeunes, complexes, développés vite et déployés partout, donc scrutés de près par les chercheurs comme par les attaquants. Les avis de sécurité tombent au rythme de plusieurs par mois sur l'ensemble de l'écosystème.
Multiplier les modules, c'est donc multiplier les points d'entrée et les veilles à assurer. Chacun publie ses avis à son rythme, sur son canal. Qui suit ces douze canaux dans l'entreprise ?
Mais le problème réel n'est pas le composant qu'on surveille, c'est celui qu'on a oublié. Sur une plateforme de quelques années, nous retrouvons systématiquement :
- des composants obsolètes depuis deux ans, installés pour un besoin ponctuel, remplacés depuis, jamais désinstallés. Ils tournent toujours, avec leurs privilèges d'origine et leurs failles publiques ;
- de vieux services dont l'usage a cessé sans que personne ne les arrête : une application de démonstration, un outil interne remplacé, une API dont le client est parti. Encore joignables, encore connectés à la base ;
- des accès et des secrets créés pour eux, toujours valides.
Ce sont des angles morts au sens propre : aucun tableau de bord ne les affiche, aucune alerte ne les signale. Ce sont pourtant eux, et non le cœur de la plateforme, qui ressortent en premier quand nous cherchons un chemin d'attaque. Un attaquant qui scanne votre infrastructure ne fait pas la différence entre un service actif et un service oublié.
La conséquence pratique : un inventaire des composants déployés et de leur justification tous les six mois, au même titre que les sauvegardes. La facilité avec laquelle Kubernetes permet de déployer est exactement ce qui le rend indispensable.
Puis vient la facture
Moins critique que ce qui précède, mais souvent décisif : un cluster consomme avant de servir à quoi que ce soit.
Une configuration de production sérieuse démarre à deux nœuds de travail plus un plan de contrôle correctement dimensionné. Cette base se facture même à vide, avant qu'une seule application n'y soit déployée, et les modules cités plus haut consomment eux aussi. Le résultat est un coût plancher élevé. Face à une ou deux machines virtuelles classiques, l'écart n'est pas en faveur de Kubernetes tant qu'on n'exploite pas réellement l'élasticité.
S'y ajoute le coût qui ne figure sur aucun devis : le temps humain de la veille, des montées de version et des inventaires. C'est celui qu'on oublie de chiffrer, et le plus élevé sur cinq ans.
La vraie question : avez-vous la taille ?
Le seuil d'entrée de Kubernetes ne se mesure ni en budget ni en trafic. Il se mesure en personnes.
Pour tenir la veille sur une douzaine de composants, assurer une montée de version tous les quatre mois, maintenir l'inventaire de ce qui est déployé et rester joignable le jour de l'incident, il faut une équipe de trois à quatre personnes dont c'est le métier. En dessous, il n'y a ni relève pendant les congés, ni second regard sur une décision d'architecture, ni continuité quand quelqu'un part.
Ce critère élimine la majorité des PME, et c'est le plus souvent ce que nous leur disons. Sans équipe dédiée, le cluster se dégrade en silence : les versions prennent du retard, les correctifs ne s'appliquent plus, les composants oubliés s'accumulent, et l'infrastructure censée renforcer la sécurité devient le maillon faible.
Deux autres cas où la réponse est non : une seule application au trafic stable qui tourne correctement sur son serveur, et le projet dont l'argument principal est que « tout le monde le fait ». Ce dernier est, dans notre expérience, le plus fréquent.
Ce qu'on en retient
Les idées reçues du début ne sont pas fausses. L'élasticité, la portabilité, la maîtrise de la localisation des données et l'automatisation des déploiements sont des bénéfices réels.
Ce qui est faux, c'est de croire qu'ils s'obtiennent à l'installation. Ils s'obtiennent par l'entretien, et l'entretien ne s'arrête jamais : une douzaine de composants privilégiés à surveiller, une rupture possible tous les quatre mois, et une plateforme où déployer est si simple qu'elle accumule ce que plus personne n'utilise ni ne met à jour. Un cluster mal entretenu n'est pas neutre pour la sécurité de l'entreprise, il est une aggravation.
Notre conclusion, après deux ans de terrain : Kubernetes est fait pour les grandes entreprises, et pour celles qui disposent d'une équipe de trois à quatre personnes dédiée à ces sujets. En dessous, la promesse d'une infrastructure plus solide se retourne en fragilité supplémentaire.
Ce n'est pas une raison de renoncer à la modernisation, mais une raison de poser la question dans le bon ordre : quel problème cherchons-nous à résoudre, et quelle est la solution la plus simple qui le résout ? Pour une PME, ce sont souvent deux machines virtuelles bien administrées, sauvegardées et tenues à jour. Ce n'est pas moderne, mais ça se défend très bien un jour d'audit.
Si vous avez cet arbitrage à faire, nous pouvons le regarder avec vos équipes techniques. Nous ne vendons pas d'infrastructure : notre intérêt est que la décision soit la bonne.