Cloud repatriation : quand revenir on-premise est vraiment rentable en 2026

Le chiffre qui change tout

En 2024, Dhruv Malhotra, VP Engineering d'une société SaaS mid-market européenne, a rendu publique sa facture AWS : 2,1 millions de dollars par an pour des workloads tournant sur des instances r6i.4xlarge avec un taux d'utilisation moyen de 68 %. Après une migration partielle vers du bare-metal en colocation, la dépense opérationnelle est tombée à 740 000 dollars. Non pas parce que le cloud est mauvais. Mais parce que, dans ce contexte précis, c'était le mauvais outil.

Le phénomène a un nom : cloud repatriation. Ce n'est pas un retour nostalgique au modèle on-premise des années 2000. C'est une décision architecturale que, en 2026, un nombre croissant d'organisations prend sur la base de données concrètes.

Pourquoi le cloud n'est plus automatiquement moins cher

La narrative « cloud = moins cher » tenait lorsque les entreprises migraient depuis des datacenters sous-utilisés, mal gérés, avec un CAPEX gonflé par du matériel dimensionné pour le pic. Aujourd'hui, les organisations matures ont souvent des workloads au profil opposé :

Utilisation stable et prévisible : aucun bénéfice de l'élasticité, que vous payez quand même en overhead dans les tarifs.
Rapport compute/stockage élevé : bases de données OLAP, rendu graphique, inférence ML. Le coût des instances mémoire-optimisées chez les grands hyperscalers a augmenté de 12 à 18 % entre 2022 et 2025.
Egress élevé : faire sortir des données d'AWS, GCP ou Azure a un coût. Un cluster Kafka avec 50 To/mois de débit inter-régions peut générer 4 000 à 8 000 USD/mois rien qu'en frais d'egress.

Le cloud reste pertinent là où vous avez besoin d'élasticité réelle, de déléguer la gestion de services complexes, ou d'une présence géographique distribuée sans infrastructure propre. Mais « pertinent » ne signifie pas « toujours ».

Les workloads candidats au rapatriement

Tout ne revient pas on-premise. La décision s'applique à des catégories spécifiques.

1. Bases de données à charge stable

PostgreSQL ou MySQL à 10 000 requêtes/seconde en charge constante, sur une instance RDS db.r6g.4xlarge, coûte environ 8 000 USD/mois en reserved 1 an. Un serveur bare-metal avec 256 Go de RAM et NVMe en colocation de qualité revient à 1 200-2 000 USD/mois tout compris. Le seuil de rentabilité est atteint en moins de quatre mois.

Le coût caché, c'est l'exploitation : sauvegardes, failover, patching. Mais si vous avez un DBA en interne, ou un partenaire qui assure ce service en marque blanche, l'écart opérationnel est comblable.

2. Inférence ML à volume fixe

Servir un modèle de 7 milliards de paramètres en production sur une instance AWS g5.xlarge (GPU A10G) coûte environ 1,20 USD/heure. En utilisation continue (730 heures/mois), c'est 876 USD/mois par GPU. Deux GPU dans votre propre serveur en colo : investissement ponctuel d'environ 20 000 USD, amorti sur 24 mois. À partir du 25e mois, le coût marginal est quasi nul.

Si votre charge est concentrée sur des pics imprévisibles — inférence seulement en heures de pointe —, le cloud reste supérieur.

3. Stockage haute capacité à accès fréquent

S3 Standard coûte 0,023 USD/Go/mois. Pour 500 To, c'est 11 500 USD/mois, hors egress et frais de requêtes. Du stockage Ceph sur hardware propre en colo peut descendre à 0,003-0,005 USD/Go/mois tout compris. Sur 500 To, économie potentielle : 9 000 à 10 000 USD par mois.

L'architecture hybride est la vraie destination

Aucune organisation sérieuse ne revient au modèle datacenter-only de 2005. Le rapatriement sélectif mène à une architecture hybride où :

On-premise/colo : compute stable, stockage chaud haute capacité, inférence GPU sur matériel propre.
Cloud : capacité burst, reprise d'activité, services managés complexes (Kafka managé, search, CDN), edge computing.

Un schéma concret :

[Trafic utilisateur]
        |
   [CDN cloud] → [Load balancer cloud] → [Couche API cloud]
                                               |
                             [Backend on-premise via VPN/Direct Connect]
                                               |
                             [DB on-prem] + [Object storage on-prem]
                                               |
                             [Backup froid sur S3 Glacier]

Le VPN ou Direct Connect introduit une latence — typiquement 1 à 3 ms entre un colo européen et la région cloud la plus proche. Pour la grande majorité des backends applicatifs, ce n'est pas un problème. Pour les systèmes temps réel avec une exigence sous les 10 ms de bout en bout, mesurez avant de décider.

Un cadre de décision en quatre questions

Avant de lancer tout projet de rapatriement, répondez à ces questions avec des données réelles :

1. Quel est votre taux d'utilisation moyen effectif ? Si vos instances cloud sont en dessous de 50 % d'utilisation, vous avez d'abord un problème de dimensionnement, avant d'avoir un problème de localisation.

2. Vos workloads ont-ils des pics imprévisibles ? Si oui, quantifiez l'écart entre la charge de base et le pic. Si le pic est 3x la baseline pour 200 heures/an, le cloud n'est pertinent que pour le delta — la baseline peut migrer on-premise.

3. Avez-vous les compétences infrastructure pour exploiter ce matériel ? Le coût caché du rapatriement, c'est le personnel. Un ingénieur infrastructure senior coûte 70 000 à 90 000 EUR/an. Si vous ne l'avez pas, intégrez-le au TCO — ou externalisez la gestion.

4. Quel est votre horizon de planification ? Le rapatriement exige du CAPEX initial : matériel, rack, câblage, contrat colo. Si votre runway est inférieur à 18 mois ou si votre stratégie produit est incertaine, la flexibilité du cloud a une valeur réelle.

Ce qu'il ne faut pas faire

Trois erreurs fréquentes observées dans les projets de rapatriement :

Migrer sans mesurer : déplacer tout ce qui « coûte trop cher » sans analyse workload par workload donne des résultats décevants et aggrave souvent la situation.
Reproduire le cloud on-premise : acheter du bare-metal pour y installer Kubernetes avec une couche d'abstraction lourde annule l'essentiel des économies compute.
Ignorer la connectivité : un colo avec un uplink de 1 Gbps partagé est insuffisant pour des workloads I/O-intensifs. Précisez les exigences réseau dans le contrat.

À retenir

Le rapatriement est rentable quand : l'utilisation est stable au-dessus de 60 %, l'horizon de planification dépasse 24 mois, les workloads sont compute/stockage-intensifs, et les compétences infrastructure sont disponibles — en interne ou en outsourcing. Dans tous les autres cas, optimisez d'abord les dépenses cloud : Reserved Instances, Savings Plans, rightsizing.

La vraie question n'est pas l'endroit où tourne votre code. C'est le TCO à 36 mois, calculé honnêtement.

---

Evviva Group accompagne les entreprises technologiques dans la conception et l'exploitation d'architectures hybrides en marque blanche. Si vous envisagez une analyse TCO pour un projet de rapatriement, contactez-nous.