Kubernetes est devenu la réponse par défaut à peu près toutes les questions d’infrastructure, ce qui est précisément le problème. La question qui compte n’est pas « Kubernetes est-il une bonne techno » (oui), mais « est-ce que ma structure a un problème que Kubernetes résout, aujourd’hui, avec l’équipe que j’ai réellement ». Voici comment j’y réponds avant même un premier échange, et comment vous pouvez le faire aussi.
Le mauvais indicateur : la taille de l’infrastructure
Le nombre de serveurs ne dit presque rien. Une infrastructure de plusieurs dizaines de VM peut n’avoir besoin que d’un peu d’ordre (scripts d’automatisation, sauvegardes testées, monitoring qui alerte pour de bonnes raisons), tandis qu’un contexte à une poignée de machines sans aucune orchestration peut transformer chaque déploiement en risque. Kubernetes répond à un problème d’opérations répétées à un rythme qui dépasse ce qu’une équipe humaine peut fiabiliser à la main, pas à un problème de volume.
Les 4 signaux qui comptent réellement
Le rythme de changement dépasse la capacité de vérification manuelle. Si chaque déploiement demande une checklist qu’une seule personne connaît par cœur, et que cette personne est en vacances une fois par an, le problème n’est pas la taille du parc : c’est l’absence de reproductibilité. Kubernetes formalise ce qu’un humain fait de mémoire.
La haute disponibilité est une exigence réelle, pas une case à cocher. Si une coupure d’une heure a un coût mesurable (perte de commandes, pénalité contractuelle, image), la bascule automatique et la répartition de charge deviennent des investissements rentables. Si une coupure d’une heure un mardi soir ne dérange personne, le calcul change du tout au tout.
Plusieurs environnements doivent rester cohérents entre eux. Dev, staging, prod qui divergent au fil du temps parce que chacun est configuré à la main est une dette qui grossit en silence. Kubernetes, combiné à de l’infrastructure as code, force cette cohérence, mais uniquement si l’équipe accepte la discipline qui va avec.
L’équipe a (ou peut développer) la capacité à opérer la plateforme, pas seulement à la faire tourner un jour de bascule. C’est le critère le plus souvent ignoré et le plus déterminant. Un cluster Kubernetes non maintenu devient plus fragile que les VM qu’il a remplacées : c’est une seconde plateforme à opérer, pas juste une nouvelle case dans l’organigramme technique.
Un calcul simple avant de se décider
Estimez le coût annuel actuel de votre situation : heures perdues sur des interventions manuelles répétitives, coût des incidents évitables (temps d’équipe mobilisé plus impact business), et prime de risque implicite du fait qu’une ou deux personnes concentrent la connaissance critique. Comparez-le au coût d’une migration progressive étalée sur plusieurs mois, plus le coût d’exploitation d’un cluster (qui n’est pas nul : quelqu’un doit le comprendre). Si le second chiffre dépasse largement le premier sur un horizon de deux ou trois ans, la réponse honnête est d’attendre, ou de traiter d’abord les causes profondes (sauvegardes non testées, absence de scripts, monitoring silencieux) qui rendraient une migration Kubernetes tout aussi mal en main que l’existant.
Ce qui rend une migration prématurée
Trois situations reviennent souvent. Une équipe de deux ou trois personnes sans platform engineer identifié : Kubernetes ajoute une compétence rare à maintenir, alors que le vrai besoin est souvent une infrastructure as code plus disciplinée sur l’existant. Une application monolithique qui n’a pas besoin d’être découpée : conteneuriser un monolithe sans le redécouper n’apporte ni scalabilité ni résilience supplémentaire, juste une couche d’abstraction en plus à opérer. Et une pression de mode plutôt qu’un problème identifié : « nos concurrents y sont » n’est pas un cahier des charges.
Ce qui rend une migration nécessaire, pas seulement souhaitable
À l’inverse, quand la haute disponibilité est déjà bricolée avec des solutions maison fragiles, quand le service discovery se fait par fichiers de configuration copiés à la main entre environnements, ou quand chaque montée en charge saisonnière transforme l’équipe en pompiers, la question n’est plus de savoir si, mais quand et comment migrer sans tout arrêter pendant la transition.
Comment trancher sans se fier à mon avis
Faites tourner ce cadre par quelqu’un qui n’a rien à vendre : votre lead dev, un pair d’un autre secteur, ou un audit externe cadré (pas un audit qui débouche automatiquement sur une vente). Un test simple pour juger n’importe quel avis sur le sujet, y compris le mien : si la réponse à « est-ce qu’un outil générique pourrait donner cette réponse sans connaître mon contexte » est oui, méfiez-vous de la source.
Si le diagnostic penche vers le oui, la suite logique est un cadrage détaillé plutôt qu’une décision prise sur un article de blog : c’est tout l’objet du diagnostic de modernisation que je propose en amont de toute mission, précisément pour trancher avant d’engager quoi que ce soit de plus lourd.