Rentrée dans le cloud (Cloud-Repatriation) : Quand il est pertinent de revenir sur la plateforme locale
&8211; L&8217;essentiel La « Cloud-Repatriation » désigne le transfert partiel de charges de travail depuis le cloud public vers une infrastructure locale. 37signals (Basecamp) a économisé 7 millions de dollars sur cinq …
L’essentiel
- La « Cloud-Repatriation » désigne le transfert partiel de charges de travail depuis le cloud public vers une infrastructure locale.
- 37signals (Basecamp) a économisé 7 millions de dollars sur cinq ans grâce à sa sortie du cloud.
- Les charges de travail stables, prévisibles et à fort volume de données constituent les meilleurs candidats.
- La repatriation n’est pas une déclaration anti-cloud, mais une optimisation rationnelle des coûts.
- La plupart des entreprises aboutissent à un modèle hybride : le cloud pour les charges variables, l’infrastructure locale pour les charges de base.
Le cloud promettait des coûts réduits, une évolutivité illimitée et une simplicité opérationnelle. Pour de nombreuses charges de travail, cela reste vrai. Pour certaines, non. Un nombre croissant d’entreprises ramène désormais certaines charges de travail – non par scepticisme vis-à-vis du cloud, mais suite à une analyse froide et rigoureuse. La « Cloud-Repatriation » n’est pas un recul, mais une maturation de la stratégie cloud.
Pourquoi les entreprises ramènent certaines charges de travail
Le cas le plus médiatisé : 37signals (Basecamp, HEY) a quitté AWS et a ainsi économisé, selon le CTO David Heinemeier Hansson, 7 millions de dollars sur cinq ans. La raison ? Des charges de travail stables, avec une charge prévisible et un volume élevé de données – exactement le profil pour lequel les coûts du cloud deviennent supérieurs à ceux d’un matériel propre.
Le calcul est simple : un serveur doté de 128 Go de RAM et de 2 To de stockage NVMe coûte entre 5 000 et 8 000 euros à l’achat et fonctionne pendant cinq ans. Son équivalent dans le cloud revient à 500-1 000 euros par mois – soit entre 30 000 et 60 000 euros sur la même période. En cas de charge stable, le matériel propre est donc 5 à 10 fois moins cher.
S’y ajoutent les coûts de transfert de données sortantes (Data-Egress) : AWS facture 0,09 USD par Go de trafic sortant. Celui qui transfère plusieurs téraoctets par mois paie des sommes à quatre chiffres – uniquement pour le réseau.
Quelles charges de travail conviennent à la repatriation ?
Les charges de travail stables de base, avec une charge prévisible : bases de données, serveurs de compilation, systèmes de supervision. Le cloud n’offre ici aucun avantage en matière d’évolutivité, mais génère des coûts permanents.
Les charges de travail gourmandes en données, avec un volume élevé de stockage et de transfert : encodage vidéo, analyse Big Data, systèmes de sauvegarde. Les coûts de transfert sortant rendent le cloud disproportionnellement coûteux.
Les charges de travail sensibles à la latence, devant s’exécuter à proximité de la source des données : Edge Computing, traitement IoT, inférence locale d’IA.
Ne conviennent pas : les charges de travail variables (activités saisonnières), les applications mondiales (multi-région), les startups en phase de croissance (évolution imprévisible), ou encore les équipes dépourvues de compétences opérationnelles.
Les coûts cachés de la rentrée dans le cloud
La repatriation n’est pas un repas gratuit. Le coût total de possession (Total Cost of Ownership, TCO) comprend : l’acquisition du matériel, les frais de colocation (baie, alimentation, refroidissement, réseau), les ressources humaines dédiées à l’exploitation et à la maintenance, les licences logicielles (VMware, sauvegarde, supervision) ainsi que les coûts ponctuels liés à la migration.
Le facteur critique est la main-d’œuvre : un administrateur Linux qualifié ou un ingénieur réseau coûte entre 70 000 et 100 000 euros par an. Une entreprise sans capacité Ops existante doit intégrer ces coûts dans sa réflexion. 37signals disposait déjà d’une équipe Ops – ce n’est pas une situation donnée.
Le compromis hybride
La réalité pour la plupart des entreprises se situe entre deux extrêmes : ni le cloud intégral, ni l’infrastructure locale intégrale, mais un modèle hybride. Les charges de travail stables de base sont hébergées sur matériel propre (colocation ou infrastructure locale), tandis que les charges variables et les pics de capacité restent dans le cloud.
Kubernetes rend ce modèle hybride réalisable : les charges de travail sont portables entre infrastructure locale et cloud. Des outils comme Rancher, Anthos ou Azure Arc permettent une gestion unifiée des deux environnements. GitOps avec ArgoCD déploie le même code partout.
Cadre décisionnel : cloud, hybride ou repatriation ?
Trois questions orientent la réponse : La charge est-elle variable ? Charge variable → cloud. Charge stable → infrastructure locale possible. Le volume de données est-il élevé ? Volume élevé de transfert sortant → infrastructure locale plus attractive. Volume faible → les coûts du cloud restent acceptables. Disposons-nous de compétences Ops ? Absence d’équipe Ops → cloud (le fournisseur cloud devient votre équipe Ops). Équipe expérimentée → la repatriation devient calculable.
La décision doit être prise au cas par cas, charge de travail par charge de travail, et non de façon globale. Même 37signals n’a pas rapatrié l’intégralité de ses charges de travail – seulement celles dont le calcul économique était clair.
Questions fréquentes
La « Cloud-Repatriation » est-elle une tendance ou une niche ?
C’est une tendance croissante, mais pas un mouvement de masse. La plupart des entreprises optimisent leur utilisation du cloud plutôt que de revenir entièrement sur une infrastructure locale. La repatriation partielle – ramener individuellement certaines charges de travail – est plus courante que les sorties complètes du cloud. Les analystes estiment que 10 à 15 % des charges de travail dans le cloud seront rapatriées à moyen terme.
Comment calcule-t-on le TCO entre cloud et infrastructure locale ?
Comparez tous les coûts sur une période de cinq ans : cloud (Compute + Stockage + Egress + Support) contre infrastructure locale (Matériel + Colocation + Personnel + Licences + Maintenance + Migration). Important : incluez les coûts d’opportunité – le temps que l’équipe consacre à l’infrastructure au lieu du développement produit.
Existe-t-il des risques de verrouillage (Lock-in) lors du retour sur infrastructure locale ?
Oui, notamment avec les services natifs du cloud (Lambda, DynamoDB, BigQuery). Les charges de travail reposant sur des services propriétaires nécessitent, avant la repatriation, une réécriture sur des alternatives open source. Les charges de travail basées sur Kubernetes sont nettement plus portables.
Les petites entreprises peuvent-elles tirer profit de la repatriation ?
Rarement. Les PME ne disposent ni de la capacité Ops ni du volume suffisant pour exploiter du matériel propre de manière rentable. Les services gérés proposés par les fournisseurs cloud offrent généralement aux PME un meilleur rapport qualité-prix. La repatriation devient typiquement pertinente à partir d’une dépense mensuelle dans le cloud supérieure à 50 000 euros.
Quelle est la différence entre repatriation et cloud hybride ?
La repatriation consiste à déplacer des charges de travail existantes depuis le cloud vers une infrastructure propre. Le cloud hybride est un modèle architectural où les charges de travail sont délibérément réparties entre cloud et infrastructure locale. La repatriation conduit souvent à un modèle hybride – mais toute stratégie hybride ne suppose pas nécessairement une repatriation.
Source de l’image : Pexels / panumas nikhomkhai
Traduit de l’original allemand par intelligence artificielle. La version allemande fait foi.
