Cloud repatriation : quels workloads rapatrier en premier (et lesquels laisser)
Rapatrier des workloads du cloud public vers une infrastructure dédiée n'est plus un contre-courant : c'est un arbitrage financier assumé, popularisé par des cas publics comme celui de 37signals (Basecamp). La bonne question n'est pas « faut-il quitter le cloud ? » mais « quels workloads rapatrier, dans quel ordre — et lesquels laisser où ils sont ».
Pourquoi la repatriation s'installe
Le cloud public a été vendu sur l'élasticité : payer ce que l'on consomme, absorber les pics, démarrer vite. Tout cela reste vrai. Mais une grande partie des workloads d'entreprise n'a rien d'élastique : des bases de données qui tournent en continu, des applications internes à charge stable, du stockage qui ne fait que croître. Pour ces charges prévisibles, la facturation à l'usage revient à payer en permanence une flexibilité que l'on n'utilise jamais.
S'y ajoutent les coûts de sortie de données (egress), les hausses tarifaires et la maturité des pratiques FinOps, qui rend enfin visible le coût réel par application. Le cas 37signals, documenté publiquement par l'entreprise elle-même, a montré qu'une équipe d'exploitation compétente pouvait sortir des workloads majeurs du cloud public et en tirer des économies durables. La souveraineté joue aussi : garder la maîtrise de la localisation de ses données devient un critère contractuel, pas seulement une préférence.
La grille de tri : quatre critères
- Stabilité de la charge : une charge plate et prévisible est le candidat idéal ; une charge en dents de scie profite réellement de l'élasticité du cloud public.
- Coût total réel : compute, stockage, egress, licences, services managés et supervision. Comparez-le au coût complet d'une infrastructure dédiée, exploitation comprise — pas seulement au prix du serveur.
- Criticité et continuité : quel RTO, quel RPO ? Le coût d'une heure d'arrêt de l'application détermine le niveau de redondance à prévoir, où qu'elle soit hébergée.
- Sensibilité des données : données personnelles, réglementées ou stratégiques ? La localisation et le contrôle d'accès peuvent imposer — ou interdire — certains choix d'hébergement.
Les premiers candidats au rapatriement
- Bases de données à charge constante : dimensionnées une fois, elles tournent sans surprise sur du matériel dédié.
- Stockage volumineux à croissance régulière : archives, sauvegardes, médias — souvent le poste où l'écart de coût est le plus net, egress compris.
- Applications internes stables : ERP, outils métier, intranets, dont la charge varie peu d'un mois à l'autre.
- Machines virtuelles « lift and shift » jamais réarchitecturées : elles n'exploitent aucun service cloud natif et paient le tarif fort.
- Inférence IA continue : un volume constant sur GPU se rentabilise mieux sur du matériel dédié que facturé à la requête.
Ce qu'il vaut mieux laisser dans le cloud public
Le rapatriement n'est pas une idéologie. Restent mieux dans le cloud public : les charges à forte saisonnalité ou à pics imprévisibles, les services managés profondément intégrés dont la réécriture coûterait plus cher que l'économie espérée, les applications servant une audience mondiale qui exigent des points de présence multiples, et les prototypes dont la charge réelle est encore inconnue.
Autre condition souvent oubliée : rapatrier, c'est reprendre la responsabilité de l'exploitation — supervision continue, sauvegardes, PRA, astreinte. Sans cela, on échange une facture contre un risque. C'est précisément le sens d'un cloud privé opéré sous SLA, le modèle que SOVALYX applique à Maurice : les économies du dédié, sans renoncer aux garanties d'exploitation. Avant de décider, posez-vous aussi les quatre questions du test de la panne cloud : elles valent dans les deux sens.
Tableau récapitulatif : rapatrier ou laisser ?
| Profil de workload | Recommandation |
|---|---|
| Base de données à charge constante | Rapatrier en priorité |
| Stockage massif à croissance régulière | Rapatrier, en ne payant l'egress qu'une seule fois |
| Application interne stable (ERP, métier) | Rapatrier après les données |
| Inférence IA à volume constant | Rapatrier sur GPU dédié |
| Pics saisonniers, campagnes, burst | Laisser dans le cloud public |
| Services managés profondément intégrés | Laisser, ou réarchitecturer d'abord |
| Audience mondiale, latence faible partout | Laisser (CDN et régions multiples) |
| Prototypes et projets exploratoires | Laisser, décider une fois la charge connue |
Commencez par un inventaire honnête des coûts par application, rapatriez d'abord un workload stable et non critique pour roder la méthode, puis étendez. La repatriation réussie est progressive — jamais un déménagement en une nuit.
Comment SOVALYX peut vous aider
Le diagnostic infrastructure de SOVALYX applique cette grille de tri à votre parc : coûts réels par workload, stabilité de la charge, criticité et sensibilité des données, pour aboutir à un ordre de rapatriement argumenté. Les workloads rapatriés rejoignent un cloud privé résilient hébergé à Maurice et opéré sous SLA — supervision 24/7, sauvegardes, PRA automatisé et testé — pour que la reprise en main de l'exploitation ne devienne pas un nouveau risque. Vous gardez ainsi les économies du dédié sans renoncer aux garanties d'exploitation.
Parler coûts d'infrastructure avec un ingénieur🧰 L'outil qui va avec : Cloud public ou privé : que disent vos chiffres sur 3 ans ? — gratuit · 2 minutes.
Relu et optimisé par IA.