7 min. de lecture – état avril 2026

Le Cloud Repatriation sonne en 2026 comme une marche arrière, mais ce n’est que la facture qui tombe après trois ans d’exploitation chez les hyperscalers. La question n’est pas « sortir du cloud », mais : à partir de quel profil de charges la colocation plus Kubernetes devient mathématiquement plus attractive qu’AWS ou Azure. Qui ne fait pas tourner le modèle économise de l’argent dans un cloud cher ou le brûle dans un rack mal dimensionné.

En lienCoûts d’inférence IA 2026 : FinOps pour charges GPU  /  Platform Engineering 2026 : Internal Developer Platforms

La discussion tourne depuis que 37signals a posé publiquement en 2023 une économie à sept chiffres grâce à ses propres serveurs. Depuis, beaucoup d’opinions, peu de chiffres. Ce qui manque dans le contexte Enterprise, c’est un cadre TCO honnête : pas pour le backend d’un service laptop, mais pour des charges avec une vraie courbe, des exigences de conformité et une responsabilité d’exploitation.

Cet article livre ce cadre. Pas d’idéologie, pas de cloud-bashing. Seulement les leviers qui font la différence. Plus un calcul qu’on peut reproduire sur une feuille A4.

Quand le retour a mathématiquement du sens

La plupart des cas de rapatriement échouent non sur la technique, mais sur le profil des propres charges. Les hyperscalers vendent de l’élasticité. Un surcoût par rapport au bare metal est, pour cela, équitable. Il devient injuste quand on n’utilise jamais l’élasticité. Un pipeline d’analyse 24/7 qui montre chaque jour à peu près la même courbe de ressources est le cas d’école pour la colocation. Un e-shop avec pic Black Friday ne l’est pas.

Deuxième facteur souvent ignoré : l’egress. Chez AWS, les sorties de données coûtent sérieusement à partir du premier téraoctet. Chez Azure, c’est similaire. Les charges qui expulsent de gros volumes – transcoding vidéo, cibles de backup, entraînement ML avec dataset externe – portent leur séjour hyperscaler pour une part non négligeable via le trafic, pas via le compute.

Règle de base pour le premier filtre : si l’utilisation CPU moyenne de vos instances dépasse 60 % sur un mois en moyenne et que la part egress dans la facture cloud contribue à deux chiffres en pourcentage, le modèle vaut la peine d’être calculé. En-dessous, restez chez l’hyperscaler et faites du FinOps. C’est moins cher qu’un projet de migration.

Source : modèle TCO cloudmagazin, hypothèses dans la section suivante

Le modèle de calcul qui tient sur un napperon

Pour ne pas rester dans le vague : prenons une charge réaliste. Cent nœuds de compute, équivalent grossièrement à des AWS m7i.4xlarge (16 vCPU, 64 Go RAM). Dans le cloud on-demand, environ 0,80 euro par heure par instance, avec des Reserved Instances 1 an environ 0,48 euro. Stockage et réseau volontairement mis de côté, ils dépendent de la charge.

Côté cloud, on atterrit avec des Reserved Instances à environ 420 000 euros par an compute-only, en on-demand autour de 700 000 euros. Les coûts d’egress sur une sortie typique d’un à deux téraoctets par jour ajoutent grossièrement 60 000 à 120 000 euros. Facture annuelle réaliste pour la charge seule : entre 500 000 et près d’un million d’euros.

Côté colocation, le calcul est différent. Deux racks dans un centre de données DACH avec power et refroidissement, contre-valeur environ 48 000 à 72 000 euros par an. Amortissement matériel pour cent nœuds Dell ou Supermicro sur cinq ans à environ 10 000 à 14 000 euros de prix de liste par nœud, soit 200 000 à 280 000 euros par an. Uplink réseau 10 Gbit redondant : 20 000 à 35 000 euros. Deux SRE dédiés avec responsabilité d’exploitation pour Kubernetes et matériel : en coût complet environ 220 000 euros. Tampon pour spare parts, remote hands, changement de provider : 40 000 euros.

Total : entre 528 000 et 647 000 euros par an. Face à la facture cloud de 480 000 à près d’un million, ce n’est pas une silver bullet, mais un couloir dans lequel la décision se joue sur le profil de charge et l’egress. Cela devient intéressant non pas à cent nœuds, mais à 300 ou 500, où les coûts matériels jouent en dégressif, tandis que le personnel et les racks ne grandissent pas linéairement.

Ce que Kubernetes en coloc change vraiment

En 2019, le rapatriement n’était pas une partie de plaisir opérationnelle. Des serveurs bare metal avec Ansible et des configs LB à la main sont un voyage dans le temps que personne ne veut faire. En 2026, la situation est différente. Kubernetes sur matériel propre n’est plus un setup exotique, mais une option plateforme par défaut : Cluster-API pour le cycle de vie, Rancher ou OpenShift pour l’exploitation, Flux ou ArgoCD pour GitOps, Cilium pour le réseau ainsi que Longhorn ou Ceph pour le stockage.

Ce qui fait la différence, c’est l’abstraction. Les développeurs voient toujours une API Kubernetes, que ce soit EKS, AKS ou un cluster dans une coloc de Francfort qui tourne en dessous. C’est le vrai levier : le rapatriement devient un backend-swap, pas un application-rewrite.

Trois endroits sont critiques où l’abstraction fuit. Premièrement, le stockage : un volume EBS se comporte différemment d’un volume Longhorn ou Ceph RBD, surtout sous pression de latence. Deuxièmement, le networking : AWS Load Balancer Controller et Cilium-LB sur base MetalLB offrent des fonctions similaires, mais les temps de failover et la logique de configuration leur sont propres. Troisièmement, l’identité : une fédération de type IRSA sur matériel propre est faisable, mais requiert SPIRE ou une couche Workload Identity comparable qui demande de l’exploitation.

Qui n’a pas réglé ces trois sujets avant le go-live devra les régler après, en exploitation productive et en mode incident. C’est le chemin le plus cher. En même temps, la communauté 2026 est suffisamment mature pour que les runbooks, charts Helm et architectures de référence pour ces points précis soient disponibles en open source. SUSE, Red Hat et les communautés clients SUSE livrent ici des gabarits qu’on n’a plus à bâtir de zéro.

Cela change le caractère du projet. Le rapatriement 2019 était une construction sur terrain vierge. Le rapatriement 2026 est un swap structuré avec une toolchain de qualité, une documentation solide et une communauté qui a déjà joué la plupart des écueils.

À quoi ressemble un chemin de migration réaliste

1. Inventaire des charges avec des chiffres honnêtes. Utilisation CPU p95 sur 90 jours, besoin mémoire, egress réseau, dépendances aux services managés comme RDS ou Cosmos DB. Les candidates sont des services stables, peu stateful, à forte base.
2. Monter la landing zone en coloc avant qu’une seule charge ne déménage. Deux racks, Kubernetes via Cluster-API, raccordement identité à l’IdP existant, logs et metrics dans le même stack que côté cloud. Objectif : opérationnellement interchangeable.
3. Migrer une charge pilote qui fait mal si elle tombe. Pas d’outils internes en premier. Si l’exploitation et la pipeline de déploiement ne tiennent pas la pression productive, l’architecture n’est pas prête.
4. Les bases de données en dernier – et uniquement avec un plan clair. PostgreSQL managé ou Cosmos DB sont souvent le levier qui reste dans le cloud. Un cluster PostgreSQL propre est faisable, mais exige du temps DBA réel et une stratégie de sauvegarde propre.
5. Définir les critères de sortie avant de démarrer. À partir de quel incident, de quelle dégradation MTTR ou quel dérapage budgétaire le retour devient-il un retour. Sur papier, pas dans la tête.

Les compromis honnêtes

Toute architecture a des coûts qui n’apparaissent qu’en exploitation. En colocation, ce ne sont pas les postes matériels évidents, mais les facteurs doux. Voici la comparaison sans fioritures :

Qui lit cette liste et a l’impression que la colonne de droite pèse plus lourd a probablement bien jugé. La colocation ne gagne pas contre les hyperscalers parce que le cloud est cher. Elle gagne quand profil de charge, structure de coûts et setup d’équipe s’alignent.

Où la ligne hybride se situe réellement en 2026

La plupart des projets que j’ai observés de près ces douze derniers mois n’atterrissent pas sur « tout dehors ». Ils atterrissent sur une architecture hybride où 60 à 80 % de la charge compute se trouve en coloc. Le cloud reste alors pour trois choses : bases managées qu’on ne veut pas porter opérationnellement, capacité de pic via Kubernetes Cluster Federation, et services edge ou global pour lesquels un site coloc ne suffit pas.

Le retour n’est pas une sortie du cloud. C’est la décision de savoir quelles 60 à 80 % de la charge compute propre ne se comportent plus de manière élastique – et ne devraient donc plus être payées de manière élastique.

Cette ligne n’est pas un compromis, mais la réponse honnête à un calcul que seule une partie des charges passe. Qui l’accepte a déjà parcouru la moitié du chemin. Qui exige « tout ou rien » retombe dans le fossé idéologique que le débat a trop souvent creusé depuis 2023.

Ce qui rend l’architecture cible intéressante en plus : elle découple achat et exploitation. L’amortissement matériel court sur cinq ans, les contrats coloc sur 24 à 36 mois. Les contrats cloud peuvent être pivotés, au besoin, en quelques semaines. Ce mélange CAPEX/OPEX est plus lisible pour les CFO qu’une facture cloud qui change chaque mois. Qui parcourt une fois une calcul hybride propre avec son équipe finance remarque : l’investissement matériel soi-disant démodé est le morceau le plus prévisible de toute la roadmap d’infrastructure.

Le prix, c’est de la discipline dans le capacity planning. Qui garde en permanence 30 % de marge en coloc perd une partie de l’avantage coût. Qui dimensionne trop juste commande dans six mois et perd du temps. Les meilleures équipes que j’ai vues travaillent avec des forecasts glissants sur 12 mois et une option cloud burst pour les pics qu’elles ne peuvent pas prévoir avec certitude.

Conclusion

Le Cloud Repatriation 2026 n’est pas un recul, c’est un processus de maturité. La technique est prête. Kubernetes dans son propre rack n’est plus un projet de recherche. La décision reste cependant commerciale : utilisation moyenne, part egress, capacité d’équipe. Qui ne connaît pas ces trois chiffres devrait, pour commencer, laisser l’idée du rapatriement et rattraper son FinOps. Qui les connaît et dont le couloir colle obtient à la fin un setup qui tourne de manière prévisible – et un CFO qui ne sursaute plus chaque mois à l’arrivée de la facture cloud.

Questions fréquentes

À partir de quelle facture cloud le rapatriement vaut-il la peine d’être regardé ?

En-dessous d’environ 300 000 euros de coûts cloud annuels, l’effort organisationnel absorbe les économies. À partir d’environ un demi-million d’euros, le modèle commence à devenir intéressant, à condition que le profil de charge corresponde. En-dessous, le FinOps est presque toujours le meilleur levier.

Ai-je impérativement besoin de deux sites coloc pour la redondance ?

Pour les charges productives avec engagements SLA : oui, deux sites ou un chemin de failover cloud. Un seul centre de données est un Single Point of Failure. La plupart des setups hybrides résolvent cela en gardant le cloud comme cible DR, pas comme exploitation primaire.

Quel est le coût annuel réaliste d’exploitation d’un cluster Kubernetes en coloc ?

Hors matériel, uniquement exploitation : deux à trois postes SRE temps plein pour un cluster de 100 à 200 nœuds, plus les licences pour le stack d’observabilité et, le cas échéant, Rancher ou OpenShift. Réalistement, entre 300 000 et 450 000 euros par an. Qui pense qu’un demi-poste suffit sous-estime l’exploitation en incident et le cycle de vie.

Les services managés comme RDS ou Cosmos DB suivent-ils ?

Non, pas sans effort. Des équivalents auto-exploitables existent (CloudNativePG, CrunchyData, YugabyteDB), mais exigent du temps DBA et des processus de sauvegarde propres. Dans de nombreux setups hybrides, les bases de données restent donc délibérément dans le cloud, même quand la partie compute déménage.

Combien de temps prend un rapatriement partiel réaliste ?

De la décision à la clôture du premier déménagement de charge : six à neuf mois. La phase landing zone seule, c’est-à-dire coloc, Kubernetes, identité, observabilité, demande trois à quatre mois. Qui veut être passé en trois mois a soit tout déjà prêt, soit envoie le projet dans le mur.

Quelle est l’erreur la plus fréquente dans les projets de rapatriement ?

L’investissement matériel est calculé proprement, les coûts de personnel sont embellis. Deux SRE deviennent 1,5 SRE, qui aide par ailleurs encore ailleurs. Huit mois plus tard, l’équipe est en surcharge. La qualité d’exploitation tombe sous le niveau qu’on avait dans le cloud. C’est le classique contre lequel il faut se protéger.

Source image de couverture : Pexels / Brett Sayles (px:5480781)