Case Study - Cloud Exit : de 200 K€/an à une infrastructure maîtrisée

Le problème du « Mets tout dans le cloud »

Le cloud, c'est pratique — jusqu'à ce que la facture arrive. Ce client a démarré comme la plupart des SaaS : livraison rapide sur services managés, focus total sur le produit. Le Kubernetes managé avait du sens au début — externaliser la complexité, itérer vite, valider le marché. Ça a marché. Le produit a trouvé son public, les clients se sont inscrits, l'équipe technique est restée légère.

Mais en grandissant, la facture cloud a grandi plus vite. De 50 K€ la première année à 120 K€ la deuxième, puis près de 200 K€ la troisième. L'architecture applicative n'avait pas fondamentalement changé. L'infrastructure était juste devenue plus chère. Kubernetes managé sur deux régions. Stockage objet facturé à l'egress. Load balancers facturés à l'heure. Les lignes se multipliaient, pas la valeur.

L'équipe n'était pas profondément verrouillée dans des services propriétaires — la plupart des workloads tournaient sur du Kubernetes standard avec de l'outillage open-source. La base de données était PostgreSQL. Le stockage était compatible S3. Ce n'était pas un problème d'architecture cloud-native, c'était un problème d'économie cloud. Ils payaient des primes de service managé pour une infrastructure qu'ils pouvaient exploiter eux-mêmes.

Au-delà du coût, il y avait des préoccupations structurelles. Les données clients éparpillées sur des régions de fournisseurs avec des garanties de résidence incohérentes. La conformité RGPD était respectée sur le papier, mais la réalité opérationnelle — traces d'audit limitées, flux de données opaques, mutualisation — mettait l'équipe juridique mal à l'aise. Et il y avait une question plus dure : que se passe-t-il quand un fournisseur cloud change ses tarifs ou déprécie un service ?

Le CTO avait lu les articles de Basecamp sur leur cloud exit. Ça résonnait. Mais ils avaient besoin d'aide pour concevoir, déployer et migrer une charge de production sans perdre un paquet.

Ce que nous avons fait

Planification de capacité

Avant de toucher le moindre serveur, nous avons cartographié leurs workloads existants : ressources demandées par les pods versus consommation réelle, patterns de trafic, besoins IOPS de stockage, et projections de croissance réalistes sur trois ans. Les factures cloud sont un mauvais proxy des besoins en compute — les services managés portent un overhead significatif et encouragent le sur-provisionnement. La charge réelle tenait confortablement dans un cluster à une fraction du coût managé.

Nous avons profilé leur cluster Kubernetes de production pendant deux semaines : usage CPU et mémoire par service, patterns d'I/O stockage, volumes d'egress réseau, cycles de trafic quotidiens et hebdomadaires. La charge de pointe était prévisible. La plupart des services tournaient bien en dessous de leurs ressources demandées. Les données montraient qu'ils payaient pour une capacité qu'ils n'utilisaient pas.

Nous avons dimensionné un cluster de 5 nœuds autour de la charge de pointe mesurée avec 40 % de marge pour la croissance. Processeurs EPYC, RAM haute densité, et disques NVMe par nœud alimentant Ceph directement. 51 To de stockage utilisable avec réplication 3×. Suffisant pour les besoins actuels, extensible sans réarchitecturer.

Procurement et déploiement matériel

La décision matérielle portait sur la fiabilité, pas les specs. Serveurs entreprise avec couverture support complète du constructeur — intervention sur site sous un jour ouvré. Une panne matérielle à 3h du matin n'est pas un problème logiciel ; ça nécessite un camion, pas un message Slack.

Nous avons spécifié une alimentation redondante, du management out-of-band, et une séparation réseau dédiée : management, trafic VM, stockage Ceph, et migration à chaud chacun sur leurs chemins isolés. Aucun point de défaillance unique au niveau réseau. Le matériel a été racké et câblé par le partenaire de colocation. Nous avons validé la couche physique avant de toucher un fichier de config.

Cluster ProxMox

ProxMox était la couche de virtualisation. Pas parce que c'est à la mode — ça ne l'est pas — mais parce que c'est opérationnellement honnête. Pas de vendor lock-in, migration à chaud solide, intégration Ceph qui fonctionne, et une communauté qui documente les modes de défaillance plutôt que de les cacher. L'équipe du client devrait exploiter ça pendant des années. Ils avaient besoin de quelque chose qu'ils pouvaient comprendre et réparer.

Cinq nœuds, Ceph sur tous, séparation VLAN partout. Le cluster était live et stable avant que Kubernetes n'entre en scène.

Conception et déploiement du cluster Kubernetes

Nous avons déployé Kubernetes en tant que VMs au-dessus de ProxMox, pas directement sur bare metal. C'était un choix architectural délibéré : ça préserve la migration à chaud pour la maintenance de nœuds sans perturber les workloads, et sépare les préoccupations d'infrastructure des préoccupations applicatives. L'équipe plateforme gère Kubernetes. L'équipe infrastructure gère ProxMox et Ceph. Frontières opérationnelles claires.

Le cluster Kubernetes reflétait la structure logique de leur setup cloud pour simplifier la migration : mêmes namespaces, mêmes patterns RBAC, mêmes conventions de nommage de services. Nous voulions que les manifests de workloads soient portables avec un minimum de changements.

Réseau : MetalLB pour les IPs LoadBalancer avec un VLAN dédié. Cilium comme CNI — choisi pour son observabilité (Hubble), l'application de network policies, et les performances eBPF. Nous avons répliqué leurs network policies cloud directement en ressources Cilium NetworkPolicy.

Livraison GitOps : ArgoCD synchronisé depuis les mêmes dépôts Git qu'ils utilisaient pour les déploiements cloud. Mêmes pipelines CI/CD, mêmes images de conteneurs. Seul l'endpoint d'API du cluster a changé.

Stockage : Ceph RBD pour le stockage bloc (StatefulSets, bases de données), CephFS pour l'accès filesystem partagé (apps legacy attendant une sémantique NFS). Storage classes configurées pour matcher les équivalents cloud par nom — PVCs migrés sans changement de manifests.

Stratégie et exécution de migration

La migration a suivi un pattern blue-green conçu pour minimiser le risque. Le nouveau cluster a tourné en parallèle de l'environnement cloud pendant six semaines pendant que nous validions chaque couche de service.

Nous avons catégorisé les workloads par criticité et chaînes de dépendances, puis migré par vagues :

Vague 1 : Services internes — monitoring, logging, dashboards internes. Impact utilisateur faible, signal opérationnel élevé. Ceux-ci ont tourné en dual-stack (cloud + on-prem) pendant deux semaines pendant que nous validions l'observabilité, les performances de stockage, et les workflows de réponse aux incidents.

Vague 2 : Workers de fond — processeurs de jobs asynchrones, tâches planifiées, opérations batch. Ces services tolèrent les défaillances transitoires et nous ont donné confiance dans le stockage Ceph sous des patterns de charge réels. Nous avons lancé des splits de trafic A/B via le routage de queue pour comparer performances et fiabilité entre les environnements.

Vague 3 : Services API — la couche applicative orientée client. TTLs DNS pré-configurés à 60 secondes deux semaines avant. Chaque service migré individuellement sur les week-ends, surveillé pendant 48 heures avant de passer au suivant. Trafic basculé progressivement : 10 % → 50 % → 100 % sur la fenêtre de migration de chaque service.

Vague 4 : Workloads stateful — PostgreSQL, Redis, stockage objet. Données répliquées à l'avance, puis bascule pendant les fenêtres de maintenance planifiées avec sauvegardes complètes et plans de rollback. Lag de réplication de base de données surveillé en continu ; la bascule ne procédait que quand le lag était sous 5 secondes.

Tout au long de la migration, les deux environnements tournaient avec des déploiements synchronisés. Un rollback était à un changement DNS. La bascule finale a été un non-événement — la plupart des utilisateurs ne l'ont jamais remarqué.

Sécurité et conformité

Segmentation réseau dès le premier jour : le trafic de management ne touche jamais le trafic des workloads. VPN pour tous les accès distants. Pas de SSH public. Certificats gérés en interne avec des cycles de rotation courts.

La résidence des données est devenue concrète : toutes les données clients dans un seul emplacement physique connu. L'équipe conformité a obtenu un registre de traitement des données réel derrière lequel elle pouvait se tenir — pas une feuille de calcul de régions cloud avec des astérisques.

Monitoring

Prometheus et Grafana sur toute la stack — nœuds ProxMox, Kubernetes, stockage, réseau. Routage d'alertes via PagerDuty. Le client sait maintenant quand un disque se dégrade avant que Ceph ne le marque en échec, et quand un nœud est sous pression mémoire avant qu'un pod ne soit OOMkilled. Avec le cloud managé, ils avaient des dashboards sans contexte. Maintenant ils ont du signal.

Le résultat

La migration s'est achevée sans incidents côté client. Les workloads de production qui tournaient sur du Kubernetes cloud managé tournent maintenant sur une infrastructure que l'équipe possède et exploite. Les temps de réponse se sont améliorés — la latence du stockage local est mesurablement meilleure que les volumes bloc cloud, et les sauts réseau entre services sont passés de cross-AZ à same-rack.

Le passage OpEx-vers-CapEx a changé la conversation financière. La dépense cloud était une ligne récurrente qui croissait avec l'usage et résistait aux prévisions. Le matériel possédé est un investissement en capital qui s'amortit sur cinq ans, avec des coûts prévisibles pour la colocation, l'électricité et la maintenance. Le coût total de possession est substantiellement inférieur — et le client possède l'actif à la fin.

Plus concrètement : l'équipe exploite une infrastructure qu'elle comprend et contrôle. Quand quelque chose casse, elle sait comment le réparer — pas d'attente de tickets de support. Cette confiance opérationnelle vaut plus que n'importe quelle ligne de coût. Ils peuvent prévoir les coûts d'infrastructure pour les trois prochaines années avec précision, quelque chose d'impossible avec la facturation cloud.

Ce que nous avons utilisé