La scène est connue : un comité de pilotage, un deck impeccablement designé, et deux mots qui claquent comme des promesses de maturité — cloud hybride et multicloud. Sur le papier, tout est limpide. Le cloud hybride, c’est “le meilleur des deux mondes” : garder le sensible en interne, profiter de l’élasticité du cloud public. Le multicloud, c’est “éviter l’enfermement” : plusieurs fournisseurs, plus de résilience, plus de pouvoir de négociation. Et au milieu, une équation magique : plus de flexibilité, moins de risques, et une facture censée rester sous contrôle.
Dans la vraie vie, ce n’est pas faux. Mais ce n’est jamais aussi simple. Les slides racontent une intention. Le terrain, lui, raconte la gravité.
Le premier non-dit : vous ne choisissez pas une architecture, vous choisissez une complexité
Le mot “hybride” rassure parce qu’il ressemble à un compromis raisonnable. Mais l’hybride, c’est avant tout une complexité structurelle : deux mondes à faire cohabiter, deux logiques d’exploitation, deux cadres de sécurité, deux types de dépendances. Tout ce qui est “entre” devient votre sujet principal : interconnexions, latences, identités, segmentation, observabilité, flux applicatifs, gouvernance des données, continuité d’activité. L’hybride n’est pas une destination, c’est un couloir où l’on passe beaucoup de temps.
Le multicloud, lui, rassure parce qu’il sonne “anti-monopole”. Mais il ne supprime pas le verrouillage, il le déplace. Vous ne serez pas verrouillé par un fournisseur unique, vous serez souvent verrouillé par votre propre empilement : outils, compétences, scripts, pipelines, modèles de sécurité, conventions d’architecture, et arbitrages historiques. Le multicloud ne rend pas tout portable : il rend certains choix plus coûteux à changer.
La question n’est donc pas “hybride ou multicloud ?” mais “quelle complexité acceptons-nous, et qui la porte ?”.
Le deuxième non-dit : la portabilité est une promesse marketing, pas un état naturel
Dans les présentations, on parle de “workloads portables”, de “containers”, de “Kubernetes” comme si la standardisation réglait le sujet. Certes, la conteneurisation aide. Mais la portabilité réelle se brise sur les détails : services managés, stockage, réseau, IAM, chiffrage, monitoring, files de messages, bases de données, pratiques de déploiement. Une application moderne n’est plus un exécutable : c’est un graphe de dépendances.
Beaucoup d’organisations découvrent tardivement que la portabilité n’est pas un choix technique unique, c’est une discipline. Et une discipline a un prix : design, tests, outillage, documentation, règles d’architecture, et surtout la volonté de renoncer à certaines “facilités” des clouds publics. Plus vous utilisez les services différenciants d’un fournisseur, plus vous gagnez en vitesse à court terme… et plus vous payez si vous devez sortir.
Le multicloud “pur” — où une application tournerait indifféremment chez deux hyperscalers — existe, mais il est rare. On le rencontre surtout là où le coût du risque dépasse le coût de la complexité : systèmes critiques, contraintes réglementaires fortes, ou enjeux géopolitiques.
Le troisième non-dit : l’hybride échoue souvent sur la donnée, pas sur le compute
On migre des serveurs, on refond des plateformes, on modernise des chaînes CI/CD. Et puis la réalité rattrape : la donnée. Les applications n’ont pas seulement besoin de CPU, elles ont besoin d’accès rapides, cohérents et gouvernés aux données. Or la donnée est lourde, sensible, parfois contrainte par le droit, et surtout difficile à “dupliquer” sans créer des incohérences.
C’est là que l’hybride se complique : quand un service on-prem doit appeler une API cloud, quand une base on-prem doit être répliquée vers un data warehouse cloud, quand des flux temps réel traversent des liens réseau qui deviennent soudain votre nouveau goulot d’étranglement. Le réseau, dans l’hybride, n’est pas un tuyau. C’est un produit. Avec un SLA, des tests, des sécurités, et des incidents.
La plupart des difficultés hybrides sont des difficultés d’exploitation : latence imprévue, saturation, règles de sécurité trop larges ou trop strictes, manque de visibilité bout-en-bout. Sur les slides, tout est “connecté”. Dans les logs, tout est “intermittent”.
Le quatrième non-dit : le multicloud est souvent… une addition d’achats, pas une stratégie
Beaucoup d’entreprises deviennent multicloud sans le décider. Une filiale signe avec un fournisseur, une équipe data choisit un autre, un éditeur impose sa stack, une acquisition arrive avec son contrat existant. Résultat : plusieurs clouds, mais pas de gouvernance multicloud. Et donc pas les bénéfices affichés.
La version “slide” du multicloud suppose une gouvernance consolidée : politiques de sécurité communes, standards d’architecture, catalogue de services, modèles de coûts, FinOps, et une vision produit des plateformes. Sans cela, vous obtenez un zoo : des comptes dispersés, des identités dupliquées, des logs non centralisés, des outils de monitoring en parallèle, des pratiques de tagging incohérentes, et des coûts qui échappent à toute lecture simple.
Le multicloud n’est pas un trophée. C’est une organisation.
Le cinquième non-dit : la facture n’explose pas “à cause du cloud”, elle explose à cause des angles morts
Ce que les slides ne montrent jamais, ce sont les lignes de facture qui poussent dans l’ombre : egress, interconnexions, coûts de stockage mal gouvernés, snapshots oubliés, environnements de test jamais éteints, surdimensionnement par peur de manquer, logs conservés “au cas où”, duplication des outils, licences superposées.
La bascule hybride ou multicloud sans discipline FinOps revient à conduire une voiture sans tableau de bord. Le problème n’est pas le cloud ; le problème, c’est l’absence de garde-fous. Tagging obligatoire, budgets, alertes, showback/chargeback, politique de rétention des logs, normes de sizing, et revues mensuelles : tout cela n’est pas glamour, donc rarement sur les slides. Pourtant, c’est ce qui évite que la discussion budgétaire devienne une guerre de récits.
Dans les organisations matures, l’enjeu n’est pas “réduire la facture” mais “payer pour de la valeur mesurable”. Et la valeur se mesure : disponibilité, time-to-market, capacité à absorber une crise, temps de reprise, qualité de service, sécurité, productivité.
Le sixième non-dit : la sécurité n’est pas un module, c’est un modèle opératoire
Hybride ou multicloud, la question centrale est l’identité : qui a accès à quoi, comment, et avec quel niveau de traçabilité. L’IAM est le cœur du système. Les slides parlent de “Zero Trust” comme d’un label ; le terrain parle de fédération d’identités, de MFA, de gestion des secrets, de segmentation réseau, de posture management, de revues d’accès, et d’investigation.
Le piège classique, c’est de faire cohabiter des modèles de sécurité différents : on-prem avec ses habitudes historiques, cloud avec ses primitives modernes. Si on ne réconcilie pas, on obtient le pire des deux : trop d’exceptions d’un côté, trop de permissions par défaut de l’autre. Et une incidentologie qui devient incompréhensible.
Le multicloud accentue ce sujet : chaque fournisseur a ses logiques, ses services, ses subtilités. La promesse “on standardise” est vraie, mais seulement si vous investissez dans une couche de gouvernance et d’observabilité réellement transverse.
Le vrai critère : quel problème essayez-vous de résoudre ?
Quand on retire le vernis, cloud hybride et multicloud répondent à des problèmes différents.
L’hybride est souvent un choix de transition et de pragmatisme : moderniser sans tout déplacer, garder certaines contraintes en interne, avancer par étapes, protéger des workloads “legacy” tout en créant une plateforme cloud-native à côté. Il fonctionne très bien si vous assumez qu’une partie du SI restera durablement en double, et si vous traitez le réseau, l’identité et la donnée comme des produits critiques.
Le multicloud est souvent un choix de gestion du risque et d’indépendance : éviter une dépendance totale, répondre à des contraintes de localisation de données, améliorer la résilience, ou garder un levier commercial. Il fonctionne très bien si vous avez un vrai modèle de gouvernance, des équipes plateforme solides, et une discipline d’architecture qui accepte de payer le coût de la portabilité là où elle a de la valeur.
Dans les faits, la plupart des entreprises finissent dans une forme mixte : hybride par héritage, multicloud par accumulation. Ce n’est pas un échec. C’est un état. Mais un état qu’il faut piloter.
Ce qu’il faut dire au Comex, sans jargon
La bonne décision n’est pas “hybride ou multicloud”, c’est : où met-on la complexité pour réduire le risque sans ralentir le business ? Et ensuite : comment mesure-t-on la valeur, et qui tient le gouvernail ?
Les slides vendent des slogans. Le réel exige trois choses simples : une gouvernance (qui décide), une exploitation (qui tient le run), et une lecture économique (qui paye quoi et pourquoi). Si ces trois piliers sont en place, hybride ou multicloud deviennent des outils. S’ils ne le sont pas, ces mots deviennent un camouflage élégant pour une dette opérationnelle qui finira toujours par se rappeler à vous — un lundi matin, au pire moment, sur le mauvais incident.
En savoir plus sur GDL T&C
Subscribe to get the latest posts sent to your email.