Un dirigeant nous transmet une proposition reçue pour son application interne de gestion des interventions, utilisée par vingt-deux collaborateurs. Le document prévoit un cluster Kubernetes géré chez un fournisseur cloud, trois environnements distincts, une chaîne de déploiement automatisée et un accompagnement au démarrage. Techniquement, rien n'est faux. La question posée est ailleurs : une fois le prestataire parti, qui mettra ce cluster à jour, qui lira ses alertes, et qui saura remettre l'application en ligne un samedi si un nœud tombe ?
Cet article ne cherche pas à disqualifier l'orchestration de conteneurs, c'est-à-dire le logiciel qui répartit automatiquement des conteneurs sur plusieurs machines, redémarre ceux qui échouent et gère les montées de version sans interruption. Cette technologie apporte un bénéfice réel dans les organisations qui en ont l'usage, et nous l'exploitons pour des clients qui sont dans ce cas. Il s'agit de savoir si votre entreprise en est là aujourd'hui, ou si le même besoin se traite avec un dispositif plus simple que votre équipe saura tenir. Nous instruisons cette décision en mission cloud à 1000 HT / jour, à distance dans toute la France et en Suisse.
Ce que l'orchestration de conteneurs résout vraiment
Kubernetes répond à des problèmes précis, et il les résout bien. Il maintient un nombre d'exemplaires souhaité pour chaque service, ce qui permet de perdre une machine sans perdre l'application. Il déclenche une montée de version progressive, où les nouveaux conteneurs remplacent les anciens seulement s'ils répondent correctement, et il revient en arrière automatiquement si la vérification échoue. Il ajuste le nombre de conteneurs selon la charge mesurée, ce qui compte lorsque le trafic varie fortement dans la journée. Il fournit enfin un vocabulaire commun à des équipes différentes : un développeur décrit ce dont son service a besoin, l'exploitation décrit où et comment ces besoins sont satisfaits.
Ces bénéfices se manifestent lorsque trois conditions sont réunies en même temps. Vous exploitez plusieurs services distincts qui évoluent à des rythmes différents, vous entretenez plusieurs environnements séparés, et une personne au moins a la responsabilité explicite de la plateforme dans son temps de travail. Quand ces trois conditions existent, l'orchestration fait gagner du temps chaque semaine. Quand une seule manque, elle ajoute une couche que personne n'entretient.
Les questions qui montrent que l'orchestration n'est pas encore votre sujet
Nous posons systématiquement les mêmes questions avant de recommander une plateforme, et les réponses tranchent souvent le débat en une heure de réunion.
- Combien de services distincts déployez-vous réellement ? Si l'application se résume à un serveur applicatif et à une base de données, un orchestrateur gère un cluster pour deux conteneurs et son intérêt reste théorique.
- Combien de fois déployez-vous par mois ? Un déploiement mensuel ne justifie pas une mécanique conçue pour absorber plusieurs mises en production par jour.
- Qui est propriétaire de la plateforme en interne ? Si la réponse est un prestataire, une seule personne ou personne du tout, le cluster deviendra un point de dépendance avant d'être un atout.
- Disposez-vous d'une chaîne d'intégration continue qui construit et teste vos images automatiquement ? Sans elle, l'orchestration n'accélère rien, elle déplace le travail manuel un cran plus loin.
- Que coûte réellement une interruption d'une heure de ce service ? Si l'activité continue par téléphone et par messagerie pendant ce délai, le niveau de disponibilité visé peut être obtenu bien plus simplement.
Ces questions ne portent aucun jugement sur les entreprises qui ont déjà fait le choix inverse. Beaucoup d'organisations exploitent un cluster avec profit parce qu'elles ont recruté les compétences correspondantes. Le sujet est la cohérence entre l'outil retenu et les moyens d'exploitation disponibles chez vous.
Ce qu'un cluster ajoute à votre exploitation quotidienne
Le coût d'un orchestrateur n'est pas d'abord celui des machines, il est celui du travail récurrent qu'il impose. Les versions de Kubernetes se succèdent à un rythme soutenu et les anciennes cessent d'être maintenues, ce qui impose plusieurs montées de version par an, chacune avec ses ruptures de compatibilité à vérifier. Le réseau interne, les certificats internes, la gestion du stockage persistant et les droits d'accès forment autant de sous-systèmes à comprendre et à maintenir. L'observabilité doit être installée et surtout lue, faute de quoi le cluster échoue silencieusement pendant des semaines.
La facture suit la même logique. Des nœuds dimensionnés pour la pointe restent allumés la nuit et le week-end, des volumes persistants survivent aux tests qui les ont créés, et un équilibreur de charge par environnement apparaît sans que personne l'ait décidé. Ce mécanisme de dérive n'a rien de propre à Kubernetes, mais un cluster le rend plus rapide, et nous décrivons la méthode pour le reprendre en main dans notre article sur la facture cloud qui augmente. Ce travail d'exploitation continu, que nous appelons le run, ne disparaît jamais : l'orchestration le structure, elle ne le supprime pas, comme le montre notre offre de maintenance cloud.
Les dispositifs qui tiennent la charge sans orchestrateur
Entre le serveur unique et le cluster complet, plusieurs solutions intermédiaires couvrent l'essentiel des besoins d'une PME. Une machine virtuelle correctement dimensionnée, avec une pile de conteneurs décrite dans un fichier Compose, un reverse proxy et des sauvegardes vérifiées, sert honnêtement une application interne pendant des années. Nous détaillons cette approche dans notre article sur les conteneurs sans orchestrateur.
Si la disponibilité devient un enjeu, deux machines identiques derrière un répartiteur de charge, avec une base de données en service géré, apportent la tolérance de panne recherchée sans introduire un cluster à administrer. Les fournisseurs proposent également des services d'exécution de conteneurs où vous fournissez l'image et où l'infrastructure sous-jacente reste chez eux, ce qui constitue souvent le meilleur compromis avant un vrai besoin d'orchestration. Le choix du fournisseur se discute par ailleurs, et nous l'abordons dans AWS, Azure ou GCP pour une PME. Enfin, lorsque les données doivent rester sur un matériel identifié, un serveur virtualisé bien exploité reste une réponse valable, notamment dans le Bassin Genevois où nous assurons le suivi sur site.
Comment nous instruisons la décision avec vous
Nous partons de l'application et non de la technologie. Nous mesurons le trafic réel, la fréquence des mises en production, le nombre de services et le niveau d'interruption acceptable pour l'activité. Nous évaluons ensuite les compétences disponibles chez vous, car une plateforme sans propriétaire interne finit toujours par se figer sur une version ancienne. Nous chiffrons enfin les deux scénarios sur trois ans, en comptant l'infrastructure et le temps d'exploitation, ce qui rend la comparaison beaucoup plus parlante qu'un débat d'outils.
Lorsque l'orchestration se justifie, nous la posons dans le bon ordre : identités et droits d'abord, réseau et sauvegardes ensuite, applications en dernier, avec une documentation d'exploitation destinée à vos équipes. Lorsqu'elle ne se justifie pas encore, nous installons le dispositif plus simple et nous écrivons ce qui devra déclencher le passage à l'étape suivante, afin que la décision se reprenne le jour venu sur des faits.
Notre position tient en une phrase : nous recommandons la solution la plus simple qui tient la charge attendue et que votre équipe saura exploiter. Si une proposition de plateforme vous paraît surdimensionnée, ou au contraire si votre serveur unique commence à montrer ses limites, soumettez-nous le dossier et nous vous dirons ce que nous ferions à votre place, avec les raisons.