Les Écrins depuis Briançon, éclairés par le ciel de l’instant · Relief : IGN LiDAR HD, Copernicus · Photographies aériennes : IGN, EOX · Voie lactée : ESO/S. Brunier · Étoiles : HYG
Hébergement Kubernetes managé
Un cluster souverain qui s'éteint quand personne ne s'en sert.
Sur devis, dimensionné au besoin réel.
- Scale-to-zero Réveil à la 1ʳᵉ requête
- Sauvegardes Quotidiennes + PITR 7 j
- Données 100 % France
- Monitoring 24/7
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 — et 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.
Scale-to-zero
Sans trafic entrant, les pods d’un service sont arrêtés : plus de CPU, de RAM ni d’énergie mobilisés pour attendre. À la première requête, il est remonté et sert la réponse. Le réveil est le démarrage d’un conteneur : quelques secondes selon l’application, pas les minutes d’une machine. Si l’attente se voit, le visiteur reçoit une page d’attente aux couleurs du service plutôt qu’une erreur.
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.
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, free cooling d’altitude, latence vers Paris
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 de 1.58 pour les datacenters européens (Uptime Institute, 2023). Quant à la distance, nous mesurons une douzaine de millisecondes de latence entre Briançon et notre point de présence parisien : négligeable pour la quasi-totalité des usages web, API et applicatifs. 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
Si votre besoin porte d’abord sur des applications, des API ou des bases managées sans passer par un cluster, regardez plutôt l’hébergement web, API et bases de données. Si l’enjeu est la conformité NIS2 et la localisation des clés, voyez sécurité, souveraineté et conformité.
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.