La facture arrive, et le débat repart : pourquoi louer si cher des ressources que l’on pourrait acheter ? À première vue, rapatrier une application du cloud ressemble à du bon sens comptable. Mais derrière le serveur moins coûteux se cachent des astreintes, des sauvegardes, des licences et des migrations rarement indolores. En ce mois de septembre 2026, la bonne question n’est donc pas « cloud ou pas cloud ? », mais quelles applications exploiter, où, et avec quel niveau de service. Voici les repères documentés et les arbitrages à examiner, sans transformer les promesses d’économies en certitudes.
Le retour des serveurs, pas la fin du cloud
Le rapatriement n’est pas une idée neuve. Dropbox a décrit dès 2016 le déplacement d’une grande partie de son stockage depuis Amazon S3 vers sa propre infrastructure, baptisée Magic Pocket. Plus récemment, 37signals, l’éditeur de Basecamp et de HEY, a publiquement raconté sa sortie du cloud et les économies qu’il en attendait. Ces expériences sont réelles, mais elles concernent des entreprises dotées de compétences techniques et de charges particulières. Elles ne constituent pas un barème applicable à toutes les directions informatiques.
Le mot « rapatriement » entretient d’ailleurs un malentendu. Il ne signifie pas nécessairement installer des baies dans les locaux de l’entreprise. Il peut désigner des serveurs dédiés chez un hébergeur, une colocation en datacenter ou une infrastructure privée administrée par un prestataire. Chaque formule redistribue les responsabilités. Sortir du cloud public ne supprime pas les fournisseurs : cela change les contrats, les dépendances et les risques.
Comparer un service avec un service
Le premier piège consiste à mettre face à face le prix mensuel d’une machine virtuelle et celui d’un serveur physique amorti sur plusieurs années. Cette comparaison peut révéler un écart considérable, mais elle ne mesure pas le même objet. Selon l’offre retenue, le cloud fournit aussi une capacité rapidement disponible, des interfaces d’automatisation et des services managés. Une base de données administrée ne se compare pas seulement au matériel qui pourrait l’héberger.
Il faut reconstruire un périmètre équivalent : calcul, stockage, réseau, sauvegardes, supervision, sécurité et continuité d’activité. Puis chiffrer l’exploitation sur une durée commune, avec plusieurs hypothèses de croissance. En infrastructure propre, une capacité inutilisée reste payée. Dans le cloud, elle peut souvent être réduite, mais seulement si les équipes adaptent effectivement les ressources. L’élasticité promise ne vaut rien lorsque les machines tournent toute l’année à vide.
Les postes qui changent le résultat
- La capacité utile : dimensionnement courant, pointes, marge de croissance et matériel de secours.
- Les coûts récurrents : hébergement, énergie, connectivité, maintenance, licences et support.
- Le travail humain : administration, mises à jour, sécurité, astreintes et recrutement.
- La transition : réécriture éventuelle, tests, transferts, fonctionnement parallèle et interruption possible.
Les données ont un prix de sortie
Une application ne voyage jamais seule. Elle emporte ses bases, ses fichiers, ses journaux et parfois des années d’archives. Les frais de transfert sortant peuvent peser sur le projet, mais la facture réseau ne résume pas le problème. Il faut aussi disposer d’un débit suffisant, vérifier l’intégrité des copies et synchroniser les modifications jusqu’à la bascule. Une migration facturée modestement peut rester lente et mobiliser durablement les équipes.
En 2024, Google Cloud, AWS et Microsoft Azure ont annoncé des dispositifs supprimant certains frais de transfert lors d’un départ de leur plateforme, selon des modalités propres à chacun. Il serait imprudent d’en déduire une gratuité générale des mouvements de données. Les conditions contractuelles doivent être vérifiées au moment du projet, notamment pour une sortie partielle. Les échanges courants entre une application rapatriée et des services conservés dans le cloud peuvent, eux, maintenir des coûts et ajouter de la latence.
Licences : le devis oublié
Déplacer une machine virtuelle ne déplace pas automatiquement tous ses droits d’utilisation. Systèmes d’exploitation, bases de données et outils de virtualisation obéissent à des métriques différentes : cœurs, processeurs, instances ou utilisateurs. Les droits de mobilité et les restrictions d’hébergement varient selon les éditeurs et les contrats. Un serveur puissant peut ainsi diminuer le coût matériel tout en augmentant celui des licences, si davantage de cœurs doivent être couverts.
Les changements commerciaux engagés autour de VMware après son acquisition par Broadcom en 2023 rappellent également qu’une infrastructure privée n’offre aucune immunité contre les évolutions tarifaires. Avant de choisir une architecture, il faut obtenir des devis correspondant au montage exact, secours compris. Et si l’alternative repose sur des logiciels libres, prévoir malgré tout le support, la formation et les compétences nécessaires : l’absence de redevance ne signifie pas l’absence de coût.
Qui répond quand le service tombe ?
C’est souvent ici que le tableur devient moins séduisant. Remplacer un disque est simple ; garantir une restauration rapide après une corruption de données l’est moins. Exploiter suppose des procédures, des alertes pertinentes et des personnes capables d’intervenir. Si une petite équipe absorbe ces tâches, leur coût apparaît rarement comme une nouvelle dépense : il se traduit par des projets retardés et une dépendance accrue à quelques spécialistes.
La disponibilité doit surtout être comparable. Un serveur unique ne remplace pas une architecture répartie sur plusieurs zones. À l’inverse, héberger une application dans le cloud ne la rend pas automatiquement résiliente : sa conception compte. Le calcul doit partir d’objectifs explicites de durée maximale d’interruption et de perte de données acceptable. Il faut ensuite financer les moyens correspondants : redondance, sauvegardes isolées, second site si nécessaire et exercices réguliers de restauration.
Rapatrier les bonnes charges, pas les mauvaises habitudes
Les meilleurs candidats présentent généralement une demande stable, une utilisation élevée et des dépendances maîtrisées. Un traitement prévisible peut rentabiliser du matériel dédié. Une application très saisonnière, une expérimentation ou un service dépendant étroitement de composants managés réclame un examen différent. Réécrire une application pour économiser sur son hébergement peut immobiliser des développeurs dont le travail aurait davantage de valeur ailleurs.
Avant de déménager, un nettoyage s’impose : supprimer les ressources oubliées, ajuster les tailles, revoir la rétention des données et les engagements de consommation. Ces corrections fournissent un point de comparaison honnête. Vient ensuite un pilote limité, avec mesures de performance, restauration testée et possibilité de retour. Le dossier financier doit distinguer économies récurrentes, dépenses de migration et incertitudes. Un scénario défavorable reste indispensable : croissance plus lente, panne majeure ou départ d’un administrateur clé.
Et maintenant ? L’hypothèse la plus crédible pour les prochaines années n’est pas un abandon général du cloud, mais un placement plus sélectif des applications. Certaines entreprises pourraient réserver le cloud aux besoins variables et conserver les charges prévisibles sur des infrastructures dédiées. Cette combinaison n’est rentable que si sa complexité reste maîtrisée. Le bon rapatriement ne gagne pas un concours de prix du serveur : il délivre un service comparable, avec un coût complet inférieur et des risques assumables.
