D'abord vers le cloud, ensuite rapatrier ce qui est à l'arrêt

Une direction veut se débarrasser de sa salle serveur. Le réflexe est de dessiner d'abord l'image finale idéale : quelle charge doit aller sur le cloud, laquelle sur du matériel propre, et ce n'est qu'une fois cela fixé que quelque chose déménage. Un tel plan prend des mois. Le temps qu'il soit prêt, la moitié des hypothèses ne tiennent plus, car la charge que vous tentiez d'estimer, vous ne l'avez jamais mesurée.

Le plan final parfait est le mauvais premier pas

Le placement, la question de savoir quelle charge de travail tourne sur quelle infrastructure, est à la fois une question de coût et une question d'architecture. Qui veut la fixer d'avance jusqu'à la virgule passe des mois à estimer sur des chiffres qui n'existent pas encore. Votre on-premise actuel dissout la charge réelle : les heures de pointe, la courbe de croissance, ce qu'un traitement nocturne consomme vraiment. Vous devinez, vous coulez ce pari dans un document, et vous bâtissez ensuite toute une migration autour.

Les plans qui verrouillent tout à l'avance ont un bilan médiocre. McKinsey et l'université d'Oxford ont étudié en 2012 les projets informatiques de plus de 15 millions de dollars. Ils dépassent en moyenne leur budget de 45 % et livrent 56 % de valeur en moins que promis, et dans 17 % des cas cela dérape au point que la survie de l'organisation est en jeu. Plus vous faites peser la première décision, plus ces chiffres frappent fort.

D'abord quitter le matériel ancien

Inversez l'ordre. Ne choisissez pas encore d'emplacement final. Détachez-vous d'abord de l'on-premise vieillissant : soulevez la charge vers un cloud européen, ou reconstruisez-la là où c'est plus rapide. Le cloud ne demande pas de capex, vous activez et désactivez de la capacité, et vous tournez en quelques semaines au lieu d'attendre un achat de matériel avec délai de livraison. Cela vous achète deux choses : de l'espace pour monter en charge sans nouvelle salle serveur, et du temps pour voir comment la charge se comporte réellement.

Le cloud d'abord n'est pas la même chose qu'emporter le désordre. Si vous soulevez un processus laborieux vers une infrastructure élastique et coûteuse, vous payez désormais ce caractère laborieux à l'heure. Nettoyez donc d'abord ce qui peut disparaître. Un audit de processus établit où se trouve vraiment la charge avant que quoi que ce soit ne déménage, afin que vous déplaciez les charges de travail propres et non les habitudes qui les entourent.

Mesurez d'abord, placez ensuite

Dès que la charge tourne dans le cloud, vous pouvez mesurer au lieu de deviner. Par charge de travail, vous voyez maintenant ce qu'elle coûte et combien elle pèse, heure après heure, semaine après semaine. Avec ces chiffres sur la table, le placement devient un choix étayé.

Le cloud mérite sa prime sur une charge qui bouge. Des pics autour d'une campagne, d'une clôture mensuelle ou d'une saison. Un traitement qui pèse un jour dix fois plus lourd que le lendemain. Là, payer à l'usage revient moins cher qu'un parc de serveurs dimensionné toute l'année sur le pic. Dès que la charge cesse de bouger, la facture bascule.

Un service qui tourne sept jours sur sept à peu près à la même charge est une charge de base prévisible. Pour cela, le prix flexible du cloud est une prime pour une capacité de montée en charge que vous n'utilisez jamais. De telles charges de travail ont leur place sur du matériel que vous possédez ou louez vous-même, où le coût unitaire est plus bas sur quelques années. Mesurez la charge de base, et rapatriez-la.

Rapatrier est enfin bon marché

Longtemps, le frein au rapatriement était le coût de sortie. Qui quittait le cloud payait des frais de sortie par gigaoctet pour emporter ses propres données. En 2024, cette barrière est tombée. Google Cloud a supprimé en janvier les frais de sortie pour qui part, AWS a suivi le 5 mars 2024, tous deux notamment sous la pression de la réglementation européenne.

Cette réglementation est le Data Act, le règlement (UE) 2023/2854, applicable depuis le 12 septembre 2025. Il oblige les fournisseurs à la portabilité et à l'équivalence fonctionnelle, et démantèle les coûts de transfert et de sortie. Le Data Act vous donne ainsi un droit de changer de fournisseur, avec une limite sur ce qu'un fournisseur peut vous facturer pour cela. Rapatrier une charge de travail vers votre propre matériel ne porte donc plus de pénalité qui s'ajoute au travail ordinaire.

Cela se retrouve dans les chiffres. Le Barclays CIO Survey de 2024 a révélé que 83 % des DSI voulaient cette année-là rapatrier au moins une charge de travail hors du cloud public, contre 43 % fin 2020, avec le coût comme premier moteur. Attention à la nuance : les sorties complètes restent rares et la plupart des organisations restent hybrides. Il s'agit de replacer de manière sélective les charges de travail là où cela vaut la peine, pas de renier le cloud.

La stack qui rend le déménagement possible sans reconstruction

Cela ne fonctionne que si une charge de travail peut déménager sans être reconstruite à chaque fois. Là, la stack est la clé. Si tout tourne en conteneurs sur Kubernetes, avec PostgreSQL et ClickHouse en dessous, alors l'infrastructure sur laquelle cela tourne est interchangeable. Le même conteneur tourne sur un cloud européen et sur votre propre matériel, sans réécriture et sans format fermé qui vous lie à un seul fournisseur. Ainsi la plateforme est indépendante de l'endroit où elle tourne par hasard, et un déménagement devient un travail que votre équipe planifie elle-même.

Le placement reste en mouvement

Le placement évolue avec votre entreprise. La charge se déplace, un produit grandit, un pic redescend en charge de base ou l'inverse. Mesurez, placez, et replacez dès que les chiffres basculent. Ce rythme correspond à notre façon de travailler : un audit IT FinOps met à nu le coût et la charge avant que quoi que ce soit ne déménage, et la construction se déroule par vagues avec un go ou no-go à chaque étape, de sorte que chaque déménagement reste mesurable.

L'avantage de cet ordre croît avec le temps. Le cloud absorbe la charge qui bouge, votre propre matériel porte la charge à l'arrêt, et comme les deux font tourner le même conteneur, vous glissez une charge de travail de l'un à l'autre dès que les chiffres l'exigent. Votre prochain pic ou charge de base ne devient alors pas un projet de migration, mais une mesure et un bouton.