7 min. de lecture – \u00e9tat avril 2026<\/p>\n
Le Cloud Repatriation sonne en 2026 comme une marche arri\u00e8re, mais ce n’est que la facture qui tombe apr\u00e8s trois ans d’exploitation chez les hyperscalers. La question n’est pas \u00ab sortir du cloud \u00bb, mais : \u00e0 partir de quel profil de charges la colocation plus Kubernetes devient math\u00e9matiquement plus attractive qu’AWS ou Azure. Qui ne fait pas tourner le mod\u00e8le \u00e9conomise de l’argent dans un cloud cher ou le br\u00fble dans un rack mal dimensionn\u00e9.<\/strong><\/p>\n L’essentiel en bref<\/p>\n En lien<\/span>Co\u00fbts d’inf\u00e9rence IA 2026 : FinOps pour charges GPU \/<\/span> Platform Engineering 2026 : Internal Developer Platforms<\/p>\n La discussion tourne depuis que 37signals a pos\u00e9 publiquement en 2023 une \u00e9conomie \u00e0 sept chiffres gr\u00e2ce \u00e0 ses propres serveurs. Depuis, beaucoup d’opinions, peu de chiffres. Ce qui manque dans le contexte Enterprise, c’est un cadre TCO honn\u00eate : pas pour le backend d’un service laptop, mais pour des charges avec une vraie courbe, des exigences de conformit\u00e9 et une responsabilit\u00e9 d’exploitation.<\/p>\n Cet article livre ce cadre. Pas d’id\u00e9ologie, pas de cloud-bashing. Seulement les leviers qui font la diff\u00e9rence. Plus un calcul qu’on peut reproduire sur une feuille A4.<\/p>\n La plupart des cas de rapatriement \u00e9chouent non sur la technique, mais sur le profil des propres charges. Les hyperscalers vendent de l’\u00e9lasticit\u00e9. Un surco\u00fbt par rapport au bare metal est, pour cela, \u00e9quitable. Il devient injuste quand on n’utilise jamais l’\u00e9lasticit\u00e9. Un pipeline d’analyse 24\/7 qui montre chaque jour \u00e0 peu pr\u00e8s la m\u00eame courbe de ressources est le cas d’\u00e9cole pour la colocation. Un e-shop avec pic Black Friday ne l’est pas.<\/p>\n Deuxi\u00e8me facteur souvent ignor\u00e9 : l’egress. Chez AWS, les sorties de donn\u00e9es co\u00fbtent s\u00e9rieusement \u00e0 partir du premier t\u00e9raoctet. Chez Azure, c’est similaire. Les charges qui expulsent de gros volumes – transcoding vid\u00e9o, cibles de backup, entra\u00eenement ML avec dataset externe – portent leur s\u00e9jour hyperscaler pour une part non n\u00e9gligeable via le trafic, pas via le compute.<\/p>\n R\u00e8gle de base pour le premier filtre : si l’utilisation CPU moyenne de vos instances d\u00e9passe 60 % sur un mois en moyenne et que la part egress dans la facture cloud contribue \u00e0 deux chiffres en pourcentage, le mod\u00e8le vaut la peine d’\u00eatre calcul\u00e9. En-dessous, restez chez l’hyperscaler et faites du FinOps. C’est moins cher qu’un projet de migration.<\/p>\n Source : mod\u00e8le TCO cloudmagazin, hypoth\u00e8ses dans la section suivante<\/p>\n Pour ne pas rester dans le vague : prenons une charge r\u00e9aliste. Cent n\u0153uds de compute, \u00e9quivalent grossi\u00e8rement \u00e0 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\u00e9seau volontairement mis de c\u00f4t\u00e9, ils d\u00e9pendent de la charge.<\/p>\n C\u00f4t\u00e9 cloud, on atterrit avec des Reserved Instances \u00e0 environ 420 000 euros par an compute-only, en on-demand autour de 700 000 euros. Les co\u00fbts d’egress sur une sortie typique d’un \u00e0 deux t\u00e9raoctets par jour ajoutent grossi\u00e8rement 60 000 \u00e0 120 000 euros. Facture annuelle r\u00e9aliste pour la charge seule : entre 500 000 et pr\u00e8s d’un million d’euros.<\/p>\n Mise en perspective propre. Les chiffres concrets d\u00e9pendent du profil de charge, de la r\u00e9gion et de la position de n\u00e9gociation.<\/p>\n<\/div>\n C\u00f4t\u00e9 colocation, le calcul est diff\u00e9rent. Deux racks dans un centre de donn\u00e9es DACH avec power et refroidissement, contre-valeur environ 48 000 \u00e0 72 000 euros par an. Amortissement mat\u00e9riel pour cent n\u0153uds Dell ou Supermicro sur cinq ans \u00e0 environ 10 000 \u00e0 14 000 euros de prix de liste par n\u0153ud, soit 200 000 \u00e0 280 000 euros par an. Uplink r\u00e9seau 10 Gbit redondant : 20 000 \u00e0 35 000 euros. Deux SRE d\u00e9di\u00e9s avec responsabilit\u00e9 d’exploitation pour Kubernetes et mat\u00e9riel : en co\u00fbt complet environ 220 000 euros. Tampon pour spare parts, remote hands, changement de provider : 40 000 euros.<\/p>\n Total : entre 528 000 et 647 000 euros par an. Face \u00e0 la facture cloud de 480 000 \u00e0 pr\u00e8s d’un million, ce n’est pas une silver bullet, mais un couloir dans lequel la d\u00e9cision se joue sur le profil de charge et l’egress. Cela devient int\u00e9ressant non pas \u00e0 cent n\u0153uds, mais \u00e0 300 ou 500, o\u00f9 les co\u00fbts mat\u00e9riels jouent en d\u00e9gressif, tandis que le personnel et les racks ne grandissent pas lin\u00e9airement.<\/p>\n En 2019, le rapatriement n’\u00e9tait pas une partie de plaisir op\u00e9rationnelle. Des serveurs bare metal avec Ansible et des configs LB \u00e0 la main sont un voyage dans le temps que personne ne veut faire. En 2026, la situation est diff\u00e9rente. Kubernetes sur mat\u00e9riel propre n’est plus un setup exotique, mais une option plateforme par d\u00e9faut : Cluster-API pour le cycle de vie, Rancher ou OpenShift pour l’exploitation, Flux ou ArgoCD pour GitOps, Cilium pour le r\u00e9seau ainsi que Longhorn ou Ceph pour le stockage.<\/p>\n Ce qui fait la diff\u00e9rence, c’est l’abstraction. Les d\u00e9veloppeurs 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.<\/p>\n Trois endroits sont critiques o\u00f9 l’abstraction fuit. Premi\u00e8rement, le stockage : un volume EBS se comporte diff\u00e9remment d’un volume Longhorn ou Ceph RBD, surtout sous pression de latence. Deuxi\u00e8mement, 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\u00e8mement, l’identit\u00e9 : une f\u00e9d\u00e9ration de type IRSA sur mat\u00e9riel propre est faisable, mais requiert SPIRE ou une couche Workload Identity comparable qui demande de l’exploitation.<\/p>\n Qui n’a pas r\u00e9gl\u00e9 ces trois sujets avant le go-live devra les r\u00e9gler apr\u00e8s, en exploitation productive et en mode incident. C’est le chemin le plus cher. En m\u00eame temps, la communaut\u00e9 2026 est suffisamment mature pour que les runbooks, charts Helm et architectures de r\u00e9f\u00e9rence pour ces points pr\u00e9cis soient disponibles en open source. SUSE, Red Hat et les communaut\u00e9s clients SUSE livrent ici des gabarits qu’on n’a plus \u00e0 b\u00e2tir de z\u00e9ro.<\/p>\n Cela change le caract\u00e8re du projet. Le rapatriement 2019 \u00e9tait une construction sur terrain vierge. Le rapatriement 2026 est un swap structur\u00e9 avec une toolchain de qualit\u00e9, une documentation solide et une communaut\u00e9 qui a d\u00e9j\u00e0 jou\u00e9 la plupart des \u00e9cueils.<\/p>\n Toute architecture a des co\u00fbts qui n’apparaissent qu’en exploitation. En colocation, ce ne sont pas les postes mat\u00e9riels \u00e9vidents, mais les facteurs doux. Voici la comparaison sans fioritures :<\/p>\n Qui lit cette liste et a l’impression que la colonne de droite p\u00e8se plus lourd a probablement bien jug\u00e9. La colocation ne gagne pas contre les hyperscalers parce que le cloud est cher. Elle gagne quand profil de charge, structure de co\u00fbts et setup d’\u00e9quipe s’alignent.<\/p>\n La plupart des projets que j’ai observ\u00e9s de pr\u00e8s ces douze derniers mois n’atterrissent pas sur \u00ab tout dehors \u00bb. Ils atterrissent sur une architecture hybride o\u00f9 60 \u00e0 80 % de la charge compute se trouve en coloc. Le cloud reste alors pour trois choses : bases manag\u00e9es qu’on ne veut pas porter op\u00e9rationnellement, capacit\u00e9 de pic via Kubernetes Cluster Federation, et services edge ou global pour lesquels un site coloc ne suffit pas.<\/p>\n \nLe retour n’est pas une sortie du cloud. C’est la d\u00e9cision de savoir quelles 60 \u00e0 80 % de la charge compute propre ne se comportent plus de mani\u00e8re \u00e9lastique – et ne devraient donc plus \u00eatre pay\u00e9es de mani\u00e8re \u00e9lastique.\n<\/p><\/blockquote>\n Cette ligne n’est pas un compromis, mais la r\u00e9ponse honn\u00eate \u00e0 un calcul que seule une partie des charges passe. Qui l’accepte a d\u00e9j\u00e0 parcouru la moiti\u00e9 du chemin. Qui exige \u00ab tout ou rien \u00bb retombe dans le foss\u00e9 id\u00e9ologique que le d\u00e9bat a trop souvent creus\u00e9 depuis 2023.<\/p>\n Ce qui rend l’architecture cible int\u00e9ressante en plus : elle d\u00e9couple achat et exploitation. L’amortissement mat\u00e9riel court sur cinq ans, les contrats coloc sur 24 \u00e0 36 mois. Les contrats cloud peuvent \u00eatre pivot\u00e9s, au besoin, en quelques semaines. Ce m\u00e9lange 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 \u00e9quipe finance remarque : l’investissement mat\u00e9riel soi-disant d\u00e9mod\u00e9 est le morceau le plus pr\u00e9visible de toute la roadmap d’infrastructure.<\/p>\n 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\u00fbt. Qui dimensionne trop juste commande dans six mois et perd du temps. Les meilleures \u00e9quipes 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\u00e9voir avec certitude.<\/p>\n Le Cloud Repatriation 2026 n’est pas un recul, c’est un processus de maturit\u00e9. La technique est pr\u00eate. Kubernetes dans son propre rack n’est plus un projet de recherche. La d\u00e9cision reste cependant commerciale : utilisation moyenne, part egress, capacit\u00e9 d’\u00e9quipe. Qui ne conna\u00eet pas ces trois chiffres devrait, pour commencer, laisser l’id\u00e9e du rapatriement et rattraper son FinOps. Qui les conna\u00eet et dont le couloir colle obtient \u00e0 la fin un setup qui tourne de mani\u00e8re pr\u00e9visible – et un CFO qui ne sursaute plus chaque mois \u00e0 l’arriv\u00e9e de la facture cloud.<\/p>\n En-dessous d’environ 300 000 euros de co\u00fbts cloud annuels, l’effort organisationnel absorbe les \u00e9conomies. \u00c0 partir d’environ un demi-million d’euros, le mod\u00e8le commence \u00e0 devenir int\u00e9ressant, \u00e0 condition que le profil de charge corresponde. En-dessous, le FinOps est presque toujours le meilleur levier.<\/p>\n<\/details>\n Pour les charges productives avec engagements SLA : oui, deux sites ou un chemin de failover cloud. Un seul centre de donn\u00e9es est un Single Point of Failure. La plupart des setups hybrides r\u00e9solvent cela en gardant le cloud comme cible DR, pas comme exploitation primaire.<\/p>\n<\/details>\n Hors mat\u00e9riel, uniquement exploitation : deux \u00e0 trois postes SRE temps plein pour un cluster de 100 \u00e0 200 n\u0153uds, plus les licences pour le stack d’observabilit\u00e9 et, le cas \u00e9ch\u00e9ant, Rancher ou OpenShift. R\u00e9alistement, 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.<\/p>\n<\/details>\n Non, pas sans effort. Des \u00e9quivalents 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\u00e9es restent donc d\u00e9lib\u00e9r\u00e9ment dans le cloud, m\u00eame quand la partie compute d\u00e9m\u00e9nage.<\/p>\n<\/details>\n De la d\u00e9cision \u00e0 la cl\u00f4ture du premier d\u00e9m\u00e9nagement de charge : six \u00e0 neuf mois. La phase landing zone seule, c’est-\u00e0-dire coloc, Kubernetes, identit\u00e9, observabilit\u00e9, demande trois \u00e0 quatre mois. Qui veut \u00eatre pass\u00e9 en trois mois a soit tout d\u00e9j\u00e0 pr\u00eat, soit envoie le projet dans le mur.<\/p>\n<\/details>\n L’investissement mat\u00e9riel est calcul\u00e9 proprement, les co\u00fbts de personnel sont embellis. Deux SRE deviennent 1,5 SRE, qui aide par ailleurs encore ailleurs. Huit mois plus tard, l’\u00e9quipe est en surcharge. La qualit\u00e9 d’exploitation tombe sous le niveau qu’on avait dans le cloud. C’est le classique contre lequel il faut se prot\u00e9ger.<\/p>\n<\/details>\n Recommandations de la r\u00e9daction<\/p>\n Articles compl\u00e9mentaires dans le r\u00e9seau MBF Media<\/p>\n Data Act : ce que les fabricants IoT doivent maintenant r\u00e9gler\n<\/p><\/div>\n Cloud Repatriation 2026 du point de vue CIO\n<\/p><\/div>\n Infostealers 2026 et le risque MFA-session\n<\/p><\/div>\n<\/div>\n Source image de couverture : Pexels \/ Brett Sayles (px:5480781)<\/p>\n","protected":false},"excerpt":{"rendered":"Cloud Repatriation 2026 comme d\u00e9cision TCO : \u00e0 partir de quel profil de charges la colocation plus Kubernetes devient rentable face \u00e0 AWS et Azure.","protected":false},"author":83,"featured_media":35544,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_yoast_wpseo_focuskw":"Cloud Repatriation 2026","_yoast_wpseo_title":"Cloud Repatriation 2026 : quand le retour est rentable","_yoast_wpseo_metadesc":"Mod\u00e8le TCO Cloud Repatriation 2026 : \u00e0 partir de quel profil de charges la colocation plus Kubernetes bat r\u00e9ellement AWS ou Azure.","_yoast_wpseo_meta-robots-noindex":"","_yoast_wpseo_meta-robots-nofollow":"","_yoast_wpseo_meta-robots-adv":"","_yoast_wpseo_canonical":"","_yoast_wpseo_opengraph-title":"","_yoast_wpseo_opengraph-description":"","_yoast_wpseo_opengraph-image":"","_yoast_wpseo_opengraph-image-id":"","_yoast_wpseo_twitter-title":"","_yoast_wpseo_twitter-description":"","_yoast_wpseo_twitter-image":"","_yoast_wpseo_twitter-image-id":"","ngg_post_thumbnail":0,"pre_headline":"","bildquelle":"","teasertext":"","language":"de","footnotes":""},"categories":[10,946],"tags":[],"industry":[],"class_list":["post-36168","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-firmensuccess","category-success-stories"],"wpml_language":"fr","wpml_translation_of":35545,"acf":[],"yoast_head":"\n\n
Quand le retour a math\u00e9matiquement du sens<\/h2>\n
Le mod\u00e8le de calcul qui tient sur un napperon<\/h2>\n
\n\n
\n \nPoste de co\u00fbt<\/th>\n Hyperscaler<\/th>\n Colocation<\/th>\n V\u00e9rification<\/th>\n<\/tr>\n<\/thead>\n \n Compute<\/strong><\/td>\n on-demand + Reserved\/Savings Plans<\/td>\n CAPEX bare metal + amortissement 3-5 ans<\/td>\n \u00c0 partir de >60 % d’utilisation, la coloc commence \u00e0 gagner<\/td>\n<\/tr>\n \n Egress<\/strong><\/td>\n cher d\u00e8s le premier To<\/td>\n contrats de transit, typiquement moins chers en volume<\/td>\n Poste principal pour vid\u00e9o, backup et datasets ML<\/td>\n<\/tr>\n \n Personnel<\/strong><\/td>\n services manag\u00e9s, overhead SRE faible<\/td>\n min. 2 SRE d\u00e9di\u00e9s, rotation 24\/7 permanente<\/td>\n Le poste que tous sous-estiment – taille minimale, pas luxe<\/td>\n<\/tr>\n \n Plateforme<\/strong><\/td>\n K8s manag\u00e9, queues, bases de donn\u00e9es<\/td>\n stack K8s propre + GitOps + monitoring<\/td>\n Sans couche plateforme, pas de retour ma\u00eetrisable<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Ce que Kubernetes en coloc change vraiment<\/h2>\n
\u00c0 quoi ressemble un chemin de migration r\u00e9aliste<\/h3>\n
\n
Les compromis honn\u00eates<\/h2>\n
\n
\n
O\u00f9 la ligne hybride se situe r\u00e9ellement en 2026<\/h2>\n
Conclusion<\/h2>\n
Questions fr\u00e9quentes<\/h2>\n
\u00c0 partir de quelle facture cloud le rapatriement vaut-il la peine d’\u00eatre regard\u00e9 ?<\/strong><\/summary>\n
Ai-je imp\u00e9rativement besoin de deux sites coloc pour la redondance ?<\/strong><\/summary>\n
Quel est le co\u00fbt annuel r\u00e9aliste d’exploitation d’un cluster Kubernetes en coloc ?<\/strong><\/summary>\n
Les services manag\u00e9s comme RDS ou Cosmos DB suivent-ils ?<\/strong><\/summary>\n
Combien de temps prend un rapatriement partiel r\u00e9aliste ?<\/strong><\/summary>\n
Quelle est l’erreur la plus fr\u00e9quente dans les projets de rapatriement ?<\/strong><\/summary>\n
\n