Cloud hybride, multicloud, on-prem : comment choisir sans se faire enfumer par les buzzwords

Il suffit d’assister à deux comités de direction IT pour entendre le même refrain : “On part au cloud.” Parfois, la phrase est prononcée comme un acte de foi, parfois comme une menace, parfois comme une promesse de salut budgétaire. Entre les slides des éditeurs, les pitchs des intégrateurs et les modes du moment, on finit par confondre stratégie et vocabulaire. Hybride, multicloud, souverain, edge, cloud-native : les mots s’empilent, les décisions se prennent à l’instinct, et quelques mois plus tard la réalité rappelle tout le monde à l’ordre. La facture surprend, la migration patine, la sécurité devient un chantier, et l’organisation découvre qu’elle a acheté une destination alors qu’elle avait besoin d’un itinéraire.

La vérité est plus prosaïque : on-prem, cloud public, hybride ou multicloud ne sont pas des idéologies. Ce sont des modèles d’exploitation. Et le bon choix dépend moins de la modernité affichée que des charges de travail, des contraintes et du coût total réel.

Les buzzwords font vendre, les cas d’usage font réussir

Commençons par remettre les mots à leur place.

On-prem (datacenter, colocation, cloud privé) : vous possédez ou contrôlez l’infrastructure. Vous gagnez en maîtrise, vous payez en capacité, vous assumez l’exploitation.

Cloud public : vous consommez des ressources et des services managés à l’usage. Vous gagnez en vitesse et en élasticité, vous payez en variabilité, en complexité contractuelle et en gouvernance.

Hybride : les deux cohabitent. Ce n’est pas un compromis “tiède”, c’est souvent la situation la plus réaliste : certaines applications ne bougent pas, d’autres migrent, des données restent, d’autres s’exposent.

Multicloud : plusieurs clouds publics (souvent deux), parfois plus, parfois avec de l’on-prem. C’est soit une stratégie assumée (résilience, souveraineté, négociation), soit un fait accompli (rachats, historiques, choix locaux).

Le piège classique est d’annoncer “multicloud” comme un label de maturité. En pratique, multicloud est une dette organisationnelle si vous ne savez pas la gérer : duplication de compétences, d’outillage, de pratiques de sécurité, et un risque très concret de finir avec des équipes qui parlent des dialectes différents.

Le comparatif utile : “quoi” tourne “où”, et “pourquoi”

La meilleure façon de choisir est de cesser de raisonner en plateformes et de raisonner en workloads.

On-prem : la force tranquille… si vous savez tenir l’usine

On-prem reste redoutablement pertinent pour des charges stables, prévisibles, et longues. Un ERP, un cœur de base de données transactionnelle, une application qui tourne 24/7 avec un profil de charge peu variable : dans ces cas, la maîtrise et la prédictibilité peuvent battre le cloud sur le coût unitaire. On-prem est également un choix logique lorsque la latence est critique, que la connectivité est incertaine (sites industriels, environnements contraints), ou que la souveraineté impose un contrôle renforcé.

Le revers, on le connaît : l’obsolescence arrive toujours, la capacité se planifie, et l’exploitation exige des compétences rares (réseau, stockage, sécurité, IAM). On-prem n’est pas “ancien”, mais il est exigeant : si vous n’avez pas l’excellence opérationnelle, le risque est de payer cher… pour une disponibilité moyenne.

Cloud public : l’accélérateur… qui facture chaque kilomètre

Le cloud public brille quand l’entreprise veut aller vite : lancer, tester, scaler, industrialiser. Les services managés (bases, queues, analytics, observabilité, IA) peuvent supprimer des mois de travail d’infrastructure et réduire le time-to-market. Pour des charges avec des pics (e-commerce, campagnes marketing, calculs ponctuels), l’élasticité est une évidence.

Mais le cloud public est aussi un modèle qui facture les détails : le stockage, les logs, les snapshots, le trafic sortant, les requêtes, la redondance, les sauvegardes. Et ce modèle récompense la discipline. Sans discipline, l’élasticité devient une fuite : tout est simple à créer, rien n’est simple à arrêter.

Hybride : la réalité du terrain, pas un entre-deux

L’hybride n’est pas une hésitation. C’est souvent la seule manière de migrer un patrimoine sans casser le business. On garde des briques lourdes on-prem, on modernise par couches, on déplace ce qui a du sens, on expose des APIs, on refond par tranches.

Mais l’hybride coûte une chose rare : la maîtrise du réseau et des identités. Interconnexions, segmentation, DNS, latences, flux, chiffrement, fédération IAM : c’est l’endroit où beaucoup de projets se compliquent. Hybride fonctionne si vous avez une architecture claire et une gouvernance forte ; sinon, c’est un millefeuille de dépendances.

Multicloud : la promesse de liberté… au prix de la complexité

On vend souvent le multicloud comme une garantie anti-lock-in. Dans les faits, il ne suffit pas d’être sur deux clouds pour être “libre”. La liberté vient de la capacité à déplacer — et déplacer coûte cher si vous utilisez des services propriétaires.

Le multicloud est pertinent dans trois cas :

1. résilience (éviter une dépendance critique à un seul fournisseur),
2. conformité/souveraineté (certaines données ou traitements doivent être sur une plateforme spécifique),
3. stratégie de négociation (mettre en concurrence, éviter l’asymétrie contractuelle).

Mais multicloud sans maturité, c’est un risque : multiplication des outils, fragmentation des compétences, incohérences de sécurité, et coûts d’exploitation qui explosent. La question à poser est brutale : avez-vous la bande passante organisationnelle pour opérer deux clouds comme il faut ?

Les coûts cachés : là où le cloud “pas cher” devient cher

Le sujet qui revient toujours, c’est le coût. Et ce qui coûte n’est pas toujours là où on regarde.

1) Le trafic sortant (egress) et les flux inter-zones

Déplacer des données hors du cloud, entre régions, ou entre clouds, peut devenir un poste majeur, surtout avec l’analytics, les logs et les sauvegardes.

2) Les logs et l’observabilité

L’observabilité est vitale — et souvent facturée à la requête, au volume ingéré, à la rétention. Beaucoup d’organisations découvrent après coup que “voir” coûte cher.

3) Les environnements fantômes

Dev, test, préprod, POC, branches éphémères : tout le monde crée, peu de gens détruisent. Sans politique d’expiration automatique, la facture s’empile.

4) La sécurité et la conformité

Chiffrement, gestion des clés, audits, segmentation, posture management, SIEM : indispensables, mais rarement intégrés au “prix annoncé”. Le cloud n’ôte pas la sécurité, il la déplace et l’amplifie.

5) L’humain : compétences, exploitation, support

Le cloud ne supprime pas l’exploitation : il change sa nature. Vous payez moins en matériel, plus en ingénierie (SRE, plateforme, IAM, FinOps). Les compétences sont le vrai coût structurel.

Les erreurs classiques : le piège du “lift & shift” et l’oubli du FinOps

S’il fallait désigner deux erreurs qui ruinent des programmes entiers, ce seraient celles-ci.

Le lift & shift raté : déplacer sans transformer

Le lift & shift consiste à déplacer une application telle quelle dans le cloud, “pour commencer”, en promettant une modernisation plus tard. Parfois, c’est une étape utile. Souvent, c’est une impasse.

Pourquoi ? Parce que vous importez dans le cloud les défauts du on-prem : monolithe, dépendances, stockage mal géré, sur-dimensionnement. Résultat : vous payez le cloud au prix fort, sans en utiliser les avantages. C’est le pire des deux mondes : coûts variables + architecture non adaptée.

Le lift & shift n’est acceptable que si vous avez un plan clair derrière : découplage, services managés, refonte par tranches. Sinon, ce n’est pas une migration, c’est un déménagement.

L’absence de FinOps : quand la facture devient un incident

FinOps n’est pas un gadget. C’est la condition pour que le cloud reste un modèle économique et ne se transforme pas en roulette russe.

Sans FinOps, vous n’avez pas :

• de tags fiables par produit/équipe/environnement,
• de budgets, d’alertes, de garde-fous,
• de politiques de rightsizing,
• de stratégie de réservation/engagement,
• de gouvernance pour arbitrer coût vs performance.

Et sans ces mécanismes, la facture n’est pas pilotée : elle est subie.

La méthode de choix : trois questions qui tranchent

Plutôt que de partir d’un slogan, partez de trois questions qui forcent la clarté.

1) Quel est le profil de charge ?

Stable 24/7 ou variable ? Pics prévisibles ? Besoin d’élasticité immédiate ? Le cloud est un avantage quand la charge fluctue ou quand vous avez besoin d’accélérer, pas quand vous avez une charge stable parfaitement dimensionnée.

2) Quel est le niveau de contrainte ?

Données, latence, résidence, réglementation, dépendances industrielles. Certaines contraintes se traitent dans le cloud ; d’autres rendent l’hybride rationnel ; certaines justifient de garder des socles on-prem.

3) Quel est votre niveau de maturité opérationnelle ?

C’est la question la plus gênante et la plus importante. Avez-vous : CI/CD, IaC, observabilité, SRE, IAM solide, gestion des secrets, gouvernance des changements ? Sans cela, le cloud ne vous sauvera pas : il rendra vos fragilités plus rapides et plus chères.

La conclusion qui protège des fumées : choisir une architecture, pas une religion

Le bon choix n’est pas “tout cloud” ou “tout on-prem”. Le bon choix est une carte des workloads, une stratégie de modernisation par étapes, et une discipline économique (FinOps) qui évite l’illusion du “pay as you go” sans pilotage.

Dans les entreprises matures, on observe souvent une forme de pragmatisme : un socle on-prem ou privé pour certaines charges stables et contraintes, du cloud public pour accélérer sur les produits, de l’hybride pour migrer sans casser, et parfois du multicloud là où le risque ou la conformité le justifient. Le reste, ce n’est pas une “vision”, c’est du bruit.

Le cloud n’est pas une destination. C’est un modèle d’exploitation. Et comme tout modèle, il récompense la lucidité — pas les buzzwords.