La repatriation dans le cloud : ce qui reste vraiment en place lors du retour des données

Huit entreprises sur dix prévoient de rapatrier au moins une charge de travail depuis le cloud. Ceux qui y voient un grand abandon du cloud se méprennent sur une illusion statistique – car ne revient que ce qui est rentable. Les architectes et responsables informatiques doivent désormais trier : quel type de charge de travail en profite vraiment, et lequel reste exactement là où il se trouve.

Les points clés en bref

• Sélectif, pas généralisé : Les chiffres d’IDC varient entre 71 et 86 % selon la définition. Le rapatriement est une décision ponctuelle, pas un virage stratégique.
• Trois moteurs, pas un seul : La charge constante d’inférence GPU, la pression réglementaire et la gravité des données déterminent ce qui revient. Qui les mélange perd en précision.
• Ça vaut le coup : L’inférence IA à utilisation constante, les bases de données critiques sur le plan réglementaire, les pipelines gourmands en données. Ça ne vaut pas le coup : les interfaces web fluctuantes, les petits services sans contraintes réglementaires.
• Coûts cachés : L’observabilité, les verrouillages de licences via les services managés et le déficit de compétences entre les opérations cloud-native et on-premises sont souvent oubliés dans le calcul.

Lié :FinOps : réduire réellement les coûts cloud de 30 %  /  AWS et Azure sous surveillance de l’UE : le verrouillage vacille

Pourquoi 86 % ne signifient pas ce qu’ils semblent dire

Les titres sont clairs : 86 % des DSI prévoient de rapatrier des charges de travail depuis le cloud public. Cela sonne comme un exode. Mais en lisant attentivement les études, on se rend compte que ce chiffre est une fourchette, pas un fait établi. Selon ce qui compte comme « rapatriement » – transfert complet d’une charge de travail, ajustement ponctuel ou simple réorientation hybride – la valeur oscille entre 71 et 86 %.

Un article du magazine frère EVM, Digital Chiefs, qualifie ces titres d’illusion statistique. Le message central : il ne s’agit pas d’un mouvement généralisé vers le retour au matériel propriétaire, mais d’une décision sélective pour certains types de charges de travail. La plupart des entreprises restent hybrides – elles déplacent de manière ciblée ce qui peut être exploité de manière plus économique ou plus sûre dans leur propre centre de données. Ce qui est mieux adapté au cloud y reste.

Pour les architectes et responsables informatiques des PME, la question est donc : quelle charge de travail va où ? Et pour y répondre, il faut distinguer les moteurs plutôt que de suivre les tendances.

Trois moteurs à distinguer clairement – et où chacun s’applique

Le débat sur le rapatriement mélange souvent trois motivations totalement différentes. Qui ne les sépare pas mentalement prend de mauvaises décisions pour son infrastructure.

Premier moteur : GPU et inférence IA. La FinOps Foundation estime que 80 à 90 % des dépenses cloud liées à l’IA concernent la phase d’inférence, et non l’entraînement. En fonctionnement continu, l’utilisation des GPU se situe souvent entre 15 et 30 % selon les mêmes études. Qui infère 24h/24 paie une prime cloud pour des capacités inutilisées. C’est là que le cluster GPU interne devient économiquement intéressant.

Deuxième moteur : conformité et souveraineté des données. Selon le Bitkom Cloud Report, 64 % des utilisateurs de cloud se sentent contraints par la politique du gouvernement américain de revoir leur stratégie, et 85 % estiment que l’Allemagne est trop dépendante des États-Unis. Gartner a forgé le terme de géorapatriement – le transfert vers des environnements souverains ou locaux. Le moteur est politico-réglementaire, pas purement économique.

Troisième moteur : gravité des données et latence. Lorsque d’énormes volumes de données développent une attraction physique, les coûts de sortie du cloud deviennent plus élevés que l’exploitation sur le site des données. Les pipelines qui déplacent des téraoctets reviennent là où les données résident.

Quels types de workloads valent le coup – et lesquels non

Ces trois critères permettent d’établir une matrice claire. La règle empirique : ce qui tourne en continu, relève d’exigences réglementaires critiques ou implique des transferts de données intensifs est un candidat au rapatriement. Ce qui fluctue, reste modeste et exempt de régulation a tout intérêt à rester dans le cloud.

Vaut généralement le coup : L’inférence IA en continu (l’utilisation des GPU dans son propre rack devient rentable à partir d’environ 60 % de charge permanente pertinente), les bases de données sensibles en matière de conformité avec des exigences de traitement DACH, et les étapes de pipelines gourmandes en données où les frais de sortie du cloud dépassent les coûts d’exploitation on-premise.

Ne vaut généralement pas le coup : Les interfaces web fluctuantes, où l’avantage d’évolutivité du cloud reste déterminant. Les petits services sans contraintes réglementaires, où les coûts de migration absorbent les économies réalisées sur la durée. Les services fortement cloud-native, couplés à des solutions managées propriétaires comme AWS Lambda ou Kinesis – ici, le réingénierie nécessaire engloutit les économies escomptées.

Ce qui coince techniquement lors du rapatriement

La décision ne représente que la moitié du chemin. Ce que les architectes sous-estiment souvent, ce sont les coûts techniques absents des business cases.

Les services cloud-native comme Lambda, Kinesis ou BigQuery relèvent de choix d’architecture, pas de produits interchangeables. Qui les rapatrie doit les reconstruire avec des équivalents open source comme OpenWhisk, Kafka ou Trino. Cela coûte du temps d’ingénierie. Le nouveau système est rarement fonctionnellement identique à 100 %. Les verrous liés aux licences des services managés sont la principale raison pour laquelle les factures explosent une fois l’euphorie initiale retombée.

S’y ajoutent l’observabilité, la latence réseau et stockage, ainsi que le déficit de compétences entre les opérations cloud-native et on-premise. Une équipe ayant géré de l’Infrastructure-as-Code dans le cloud pendant trois ans ne maîtrise pas nécessairement la traduction de modules Terraform sur du bare metal. Ce n’est pas un argument contre le rapatriement – mais un poste à intégrer dans le calcul de rentabilité.

Comment les architectes décident aujourd’hui – sans réflexe de mode

Un cadre de décision rigoureux repose sur trois questions par workload : quelle est la constance de la charge ? Dans quelle mesure les données sont-elles locales ? Quelle est l’intensité des contraintes de conformité ? Si les trois réponses sont « élevée », le workload est un candidat au rapatriement. Avec deux « non », le cloud reste la solution adaptée.

Le calcul est simple : une instance GPU réservée on-premise devient rentable face à une solution cloud à la demande pour une inférence 24/7 dès environ 60 % d’utilisation, sur un horizon TCO de 18 à 36 mois. En deçà, le cloud conserve assez d’élasticité pour absorber les pics de charge sans surcapacité. La décision se prend donc mathématiquement, sans idéologie – et c’est précisément ce qui la rend opérationnelle.

Qui rapatrie un workload aujourd’hui doit le considérer comme un pilote, pas comme un modèle universel. Le succès du rapatriement d’un pipeline d’inférence prouve sa rentabilité, mais ne s’applique pas automatiquement à une interface web. Rester sélectif relève de la discipline, pas de l’hésitation.

Foire aux questions

Plus d’articles du réseau MBF Media