Hébergement Kubernetes managé
Un cluster souverain qui s'éteint quand personne ne s'en sert.
Sur devis, dimensionné au besoin réel.
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 : vos manifestes, vos images de conteneurs, vos variables, votre pipeline. Nous prenons ce qui n'apporte rien à votre produit — le plan de contrôle, les montées de version, le réseau, le stockage, les certificats, la supervision et les sauvegardes. Il n'y a pas de couche propriétaire à apprendre : l'orchestration est certifiée, et vos manifestes Kubernetes restent des manifestes Kubernetes.
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.
La question qui vient toujours ensuite est celle de 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.
Scale-to-zero : ce que ça change vraiment
Le scale-to-zero éteint automatiquement les pods sans trafic entrant, puis les rallume à la première requête suivante.
- Aucun trafic entrant sur un service : ses pods sont arrêtés. Plus de CPU, plus de RAM, plus d'énergie mobilisée pour attendre.
- Première requête : le service est remonté et sert la réponse. Le réveil, c'est le démarrage d'un conteneur — quelques secondes selon l'application, pas les minutes d'un démarrage de 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 là où le trafic est intermittent : environnements de staging inutilisés la nuit, API à faible trafic, traitements périodiques, préproductions de démonstration.
- Conséquence directe : moins de ressources mobilisées pour un service au repos, donc une consommation réduite — et un dimensionnement calé sur la charge observée plutôt que sur le pic redouté.
Les workloads qui doivent rester chauds en permanence ne descendent pas à zéro : c'est un arbitrage qu'on pose service par service au cadrage.
Isolation par namespace, et pas voisinage forcé
La comparaison la plus fréquente est celle avec l'hébergement mutualisé. Les deux modèles n'ont ni le même contrat ni les mêmes garanties.
Un serveur, des centaines de voisins
Un même serveur physique est partagé 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'est pas délimité par une frontière technique nette.
Un namespace, des limites garanties
Chaque workload dispose de son propre namespace, de limites de CPU et de mémoire garanties, de ses secrets chiffrés et d'une isolation réseau par politique : seuls les flux que vous déclarez entrent et sortent. Le périmètre est explicite : on peut dire où vivent les données et qui peut les atteindre.
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
Sur devis, dimensionné au besoin réel.
À 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é.
Quatre étapes, pas de formulaire
-
On regarde votre stack actuelle
Inventaire de vos services, images, volumes et dépendances managées, et lecture de vos fenêtres de trafic réelles. C'est ce qui révèle ce qui tourne pour rien.
-
On cadre le besoin réel
Découpage en namespaces, limites CPU et mémoire par workload, et arbitrage explicite sur ce qui peut tomber à zéro et ce qui doit rester chaud.
-
On migre sans coupure
Le cluster est monté en parallèle de votre existant, puis la bascule se fait progressivement, service par service, chacune réversible : l'état du cluster est décrit en Git, donc un retour arrière est la révocation d'un commit.
-
On supervise
Monitoring et alerting 24/7, sauvegardes quotidiennes avec restauration à un instant précis, et revue du dimensionnement une fois la charge réelle observée sur le cluster.
- Scale-to-zero Réveil à la 1ʳᵉ requête
- Sauvegardes Quotidiennes + PITR 7 j
- Données 100 % France
- Monitoring 24/7
Le cluster tourne dans un datacenter alimenté à 100 % au solaire, refroidi par free cooling d'altitude — zéro litre d'eau, jusqu'à 95 % de consommation en moins sur le cooling face à des systèmes CRAC/CRAH classiques. Le PUE visé est inférieur à 1.1, contre une moyenne de 1.58 pour les datacenters européens (Uptime Institute, 2023). Le détail de l'installation est sur la page infrastructure.
Parlons de votre charge réelle
Décrivez votre stack actuelle — nombre de services, dépendances managées, contraintes de conformité, fenêtres de trafic. On répond avec les écarts que nous voyons et l'architecture que nous proposons. Il n'y a pas de formulaire : un mail suffit.
Sur devis, dimensionné au besoin réel.