Hébergement Kubernetes managé
Un cluster souverain qui s’éteint quand personne ne s’en sert.
Sur devis, dimensionné au besoin réel. Le cluster tourne à Briançon, 1 326 m d’altitude.
La nuit, les batteries prennent le relais.
Un staging que personne n’utilise la nuit ne tourne pas pour rien : sans trafic, ses pods s’éteignent, puis se rallument à la première requête.
- Scale-to-zero Réveil à la 1ʳᵉ requête
- Sauvegardes Quotidiennes + PITR 7 j
- Données 100 % France
- Monitoring 24/7
Les Écrins vus à 3 000 m d’altitude, au-dessus du fort de l’Infernet, sous le ciel de l’instant (par ciel clair). La nuit, la montagne est montrée plus claire qu’à l’œil : c’est une illustration. Relief : IGN LiDAR HD, Copernicus · Photographies aériennes : IGN, EOX · Voie lactée : ESO/S. Brunier · Étoiles : HYG
Vous payez de la capacité réservée, pas de l’usage
Vos conteneurs tournent 24 h/24 alors que votre trafic, lui, ne tourne pas 24 h/24 : votre facture comme votre empreinte suivent la capacité réservée, pas l’usage réel.
Un cluster calé sur la charge observée
Nous opérons pour vous un cluster Kubernetes souverain à Briançon : vous poussez vos images, nous tenons le plan de contrôle, les mises à jour, la supervision et les sauvegardes. Les services sans trafic tombent à zéro pod, et se réveillent à la première requête.
Ce que « managé » veut dire chez nous
Vous gardez la main sur ce qui est à vous : manifestes, images de conteneurs, variables, pipeline. Nous prenons ce qui n’apporte rien à votre produit : plan de contrôle, montées de version, réseau, stockage, certificats, supervision, sauvegardes. Aucune couche propriétaire à apprendre : l’orchestration est certifiée, et vos manifestes Kubernetes restent des manifestes Kubernetes.
Ce qui dort, ce qui reste chaud
Sans trafic entrant, les pods d’un service sont arrêtés : plus de CPU, de RAM ni d’énergie mobilisés pour attendre. Le gain est maximal quand le trafic est intermittent : staging inutilisé la nuit, API à faible trafic, traitements périodiques, préproductions de démonstration. Ce qui doit rester chaud en permanence ne descend pas à zéro : l’arbitrage se pose service par service, au cadrage. Si l’attente se voit, le visiteur reçoit une page d’attente aux couleurs du service plutôt qu’une erreur.
Un namespace, pas un voisinage forcé
Un mutualisé partage un même serveur physique entre des centaines de clients, sans isolation réseau ni garantie de ressources : la charge d’un voisin devient votre problème de performance, et le périmètre de vos données n’a pas de frontière technique nette. Ici, chaque workload a son namespace, des limites de CPU et de mémoire garanties, ses secrets chiffrés et une isolation réseau par politique : seuls les flux que vous déclarez entrent et sortent. On peut dire où vivent les données, et qui peut les atteindre.
Nœuds ARM et free cooling d’altitude
Nous déployons des nœuds ARM basse consommation, dont l’empreinte énergétique par serveur est très inférieure à celle d’un équivalent x86. Ils chauffent moins, donc ils demandent moins de refroidissement, et à 1 326 m d’altitude ce refroidissement se fait à l’air libre, sans climatisation mécanique et sans un litre d’eau. Kubernetes et Linux sont nativement disponibles en arm64 ; la seule contrainte porte sur vos images, qui doivent être construites en multi-architecture. C’est un point que nous vérifions au cadrage, et qui décide de ce qui part sur ARM et de ce qui reste sur x86.
Le cluster tourne dans un datacenter alimenté à 100 % au solaire et refroidi par free cooling d’altitude : jusqu’à 95 % de consommation en moins sur le refroidissement face à des systèmes CRAC/CRAH classiques, pour un PUE visé inférieur à 1,1, contre une moyenne mondiale de 1,58 (Uptime Institute, 2023). Le détail de l’installation est sur la page infrastructure.
Le périmètre, sans zone grise
- Orchestration Kubernetes certifiée, conteneurs isolés par namespace
- Scale-to-zero automatique : les pods sans trafic s’éteignent, puis se rallument à la première requête
- Déploiement GitOps : chaque changement est un commit, chaque retour arrière une révocation de commit
- Monitoring et alerting 24/7
- Sauvegardes quotidiennes des bases, transactions journalisées en continu : restauration à un instant précis (PITR), rétention 7 jours, copie hors site
- Limites CPU/mémoire garanties, isolation réseau par politique, secrets chiffrés au repos
À qui ce service s’adresse
- Éditeurs SaaS qui veulent sortir des hyperscalers sans réécrire leur stack
- Équipes produit avec des environnements de staging inutilisés la nuit
- Organisations soumises au RGPD ou à NIS2 qui doivent localiser leurs données
Parlons de votre charge réelle
Décrivez votre stack actuelle : services, images, volumes, dépendances managées, contraintes de conformité, fenêtres de trafic réelles. On répond avec les écarts que nous voyons et l’architecture que nous proposons ; le cluster est ensuite monté en parallèle de votre existant, et la bascule se fait service par service, chacune réversible.