On a reçu notre facture AWS de juillet, et on l'a comparée avec celle de janvier de la même année. Elle avait augmenté de 40%, sans qu'on ait ajouté un seul nouveau client important. On a creusé : du stockage S3 qu'on n'utilisait plus vraiment, des instances qu'on avait dimensionnées "au cas où" deux ans plus tôt et jamais redimensionnées, des frais de transfert de données entre régions qu'on n'avait même pas identifiés comme une ligne de coût distincte.
On n'a pas quitté AWS. On veut être honnêtes là-dessus dès le départ, parce que beaucoup d'articles sur le "cloud repatriation" racontent une histoire à sens unique — on part, on économise, tout le monde applaudit. Ce n'est pas notre histoire, et ce n'est pas non plus celle de la majorité des entreprises qui se posent la question.
Mais l'exercice qu'on a fait — recalculer, poste par poste, ce que coûterait la même charge de travail hébergée différemment — nous a forcés à une question qu'on avait évitée depuis trois ans : est-ce qu'on paie pour de l'élasticité qu'on utilise vraiment, ou est-ce qu'on paie une prime de confort pour ne pas avoir à gérer des serveurs ?
37signals, l'éditeur de Basecamp, a répondu à cette question en quittant AWS : de 3,2 millions de dollars par an à environ 1,3 million, pour une charge de travail stable et prévisible. Dropbox avait fait la même chose des années avant eux. Mais GEICO a fait l'inverse pendant dix ans — migrer vers le cloud — pour se retrouver avec des coûts 2,5 fois supérieurs aux prévisions sur plus de 600 applications, et rapatrier maintenant la moitié de ses workloads.
Deux histoires opposées, avec les mêmes outils. La question qu'on se pose : dans laquelle sommes-nous ?
Ce que 37signals a vraiment économisé, et à quel prix
Le cas 37signals est le plus documenté, donc le plus utile pour comprendre les vrais mécanismes. Ils dépensaient environ 3,2 millions de dollars par an sur AWS en 2022. Ils ont acheté pour 600 000 à 700 000 dollars de serveurs, et ont ramené leur facture annuelle à environ 1,3 million de dollars — soit près de 2 millions d'économies par an, avec une projection de gain sur cinq ans dépassant 10 millions.
Sur la partie stockage seule, ils ont déplacé 18 pétaoctets hors de S3 vers des baies Pure Storage, pour environ 1,5 million de dollars de matériel, avec un coût d'exploitation annoncé sous les 200 000 dollars par an. Détail révélateur : AWS aurait renoncé à environ 250 000 dollars de frais de sortie de données pour leur permettre de migrer — ce qui en dit long sur la marge que ces frais représentent normalement.
Ce que cette histoire ne dit pas assez fort : 37signals avait une charge de travail stable, prévisible, avec des pics limités. C'est exactement le profil qui rend la repatriation rentable. Ce n'est pas le profil de toutes les entreprises.
Le contre-exemple qu'on ne cite jamais assez : GEICO
GEICO a fait l'inverse de 37signals — migrer vers le cloud pendant une décennie — et le résultat a été un dépassement de coût de 2,5 fois les attentes initiales, sur plus de 600 applications migrées vers Azure. L'entreprise rapatrie aujourd'hui au moins la moitié de ses workloads vers un cloud privé OpenStack, avec un objectif de réduction de 50% du coût compute par cœur et 60% sur le stockage par gigaoctet.
Ce cas nous intéresse davantage que celui de 37signals, parce qu'il ressemble plus à notre réalité opérationnelle : une migration décidée pour de bonnes raisons théoriques — élasticité, services managés, vitesse de déploiement — qui accumule, année après année, des coûts que personne n'avait anticipés à l'échelle où ils sont apparus.
Pourquoi on n'a pas fait le calcul plus tôt
La vraie raison pour laquelle on n'avait jamais recalculé notre facture poste par poste, ce n'est pas la paresse. C'est que le cloud public a un avantage réel qu'on ne veut pas minimiser : la vitesse. Quand on démarre un projet client, on ne veut pas attendre trois semaines de délai d'approvisionnement de serveur. On veut une instance en cinq minutes. Cette vitesse a une valeur, même si elle n'apparaît sur aucune ligne de facture.
Le problème, c'est qu'on paie cette vitesse en continu, même pour des charges qui, deux ans plus tard, sont devenues parfaitement prévisibles et stables. Une charge de travail qui a besoin d'élasticité le premier mois n'en a souvent plus besoin la troisième année. Et c'est précisément là que la facture continue de grimper sans qu'on la questionne.
Ce que le calcul nous a réellement montré
Sur les trois workloads qu'on a analysés en détail — notre plateforme de traitement de données pour un client bancaire, notre infrastructure de développement interne, et notre archivage de logs — un seul aurait justifié une migration vers une solution hébergée différemment : l'archivage, qui est volumineux, stable, et rarement consulté. Les deux autres bénéficient réellement de l'élasticité du cloud public, parce que leur charge varie fortement selon les périodes de facturation de nos clients.
Cette conclusion nous a un peu déçus, si on est honnêtes. On espérait trouver une histoire nette à raconter, du genre "on a quitté AWS et économisé 40%". La réalité est plus terne : on garde l'essentiel de notre infrastructure là où elle est, et on migre un seul composant, pour une économie qu'on estime à environ 15 000 dollars par an — modeste, mais réelle.
Le coût caché qu'on avait complètement sous-estimé : les compétences
Ce qu'aucun article sur le cloud repatriation ne dit assez clairement : migrer un seul composant hors du cloud public nous a obligés à recruter, en partie, des compétences qu'on n'avait plus en interne depuis des années. Administrer une baie de stockage physique, gérer un contrat de colocation, prévoir la maintenance matérielle — ce sont des métiers que le cloud public nous avait permis de ne jamais développer. Les études sur la repatriation mentionnent des investissements initiaux de 500 000 à 2 millions d'euros pour serveurs, stockage, réseau et capacité de datacenter, plus le coût de personnel. Pour notre seul composant d'archivage, ce coût de montée en compétence a réduit d'environ un tiers l'économie nette qu'on avait projetée sur la première année.
On a changé d'avis sur un point précis : la question n'est jamais "faut-il quitter le cloud", elle est "quel pourcentage de notre infrastructure a encore besoin de ce qu'on paie pour elle". Chez nous, la réponse est "la majorité, mais pas tout" — ce qui n'est ni le récit héroïque du repatriation ni le statu quo confortable.
On ne sait pas si notre calcul tiendra dans deux ans. Les prix du cloud bougent, nos charges de travail aussi, et on n'a pas la prétention d'avoir trouvé une formule stable. Ce qu'on a gagné, c'est l'habitude de refaire ce calcul chaque année plutôt que de le faire une fois et de considérer le sujet clos.
Si vous gérez une infrastructure cloud : la dernière fois que vous avez recalculé le coût réel de vos workloads les plus stables, poste par poste — c'était il y a combien de temps ?
En attendant, on garde notre facture AWS ouverte sur un écran, comme un rappel plutôt qu'une fatalité.
