Si IaaS / PaaS / SaaS répondent à « quel niveau d'abstraction j'achète », les modèles de déploiement répondent à une autre question : « où vit physiquement et juridiquement mon infrastructure ». Le NIST a posé quatre modèles historiques (public, privé, hybride, community), auxquels s'ajoute en 2026 un cinquième modèle qui s'impose en Europe : le sovereign cloud. Et le multi-cloud, qui n'est pas un modèle NIST mais une stratégie industrielle, complète le paysage. Cette page détaille les 6 modèles, leurs avantages, leurs pièges, et défend une opinion claire sur le modèle par défaut à choisir selon votre profil.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Les 6 modèles de déploiement : public, privé, hybride, multi, sovereign, community
- Les avantages, inconvénients et coûts de chaque modèle
- Comment choisir selon votre profil (startup, ETI, secteur réglementé, multinationale)
- Pourquoi le sovereign cloud s'impose comme 5e modèle en Europe
- Les pièges classiques des choix de déploiement et comment les éviter
Prérequis : avoir compris la grille XaaS. Si besoin, lisez d'abord IaaS, PaaS, SaaS, FaaS, CaaS.
1. Les 6 modèles de déploiement en un coup d'œil
Section intitulée « 1. Les 6 modèles de déploiement en un coup d'œil »Le NIST (US National Institute of Standards and Technology) a posé en 2011 quatre modèles canoniques : public, private, community, hybrid. La pratique de l'industrie a ajouté deux notions complémentaires depuis : le multi-cloud (stratégie d'utilisation de plusieurs clouds publics), et le sovereign cloud (variante de cloud public ou privé qui garantit l'indépendance juridique et technologique vis-à-vis d'États tiers).
| Modèle | Définition courte | Cas d'usage typique |
|---|---|---|
| Public | Infrastructure mutualisée, fournisseur tiers, accessible via Internet | Startup, app web, dev/test |
| Privé | Infrastructure dédiée à une seule organisation, on-prem ou hosted | Banque, hôpital, défense |
| Hybride | Combinaison public + privé, avec interconnexion sécurisée | Migration progressive, ETI |
| Multi-cloud | Plusieurs fournisseurs publics utilisés simultanément | Multinationale mature, FinOps avancé |
| Sovereign | Cloud public ou privé qualifié pour la souveraineté nationale | Données réglementées UE, administrations |
| Community | Infrastructure mutualisée entre organisations partageant des contraintes | Recherche, santé multi-CHU, secteur public |
Aucun modèle n'est universellement supérieur. Le choix est contextuel et dépend de quatre variables : contraintes réglementaires (RGPD, HDS, SecNumCloud), profil de charge (stable / variable), expertise interne disponible, exigence de souveraineté.
2. Cloud public — le défaut historique
Section intitulée « 2. Cloud public — le défaut historique »Définition : infrastructure mutualisée entre plusieurs clients, gérée par un fournisseur cloud (AWS, Azure, GCP, Outscale, OVHcloud, Scaleway).
Analogie : le métro parisien
Section intitulée « Analogie : le métro parisien »Imaginez le métro : vous partagez le transport avec des milliers d'autres passagers, mais chacun a sa propre destination. Les rames sont mutualisées (économies d'échelle), votre trajet reste privé. Le cloud public fonctionne pareil : vos applications tournent sur des serveurs physiques qui hébergent aussi celles d'autres clients, mais vos données restent strictement isolées par la virtualisation.
C'est aussi comme louer un appartement dans un immeuble : vous partagez la structure (murs, toit, plomberie), votre espace reste privé et sécurisé.
Comment ça marche en pratique
Section intitulée « Comment ça marche en pratique »Quand vous créez une VM chez un fournisseur cloud public, le fournisseur alloue de la capacité CPU/RAM/disque sur un serveur physique. Cette capacité est isolée logiquement de celle des autres clients par l'hyperviseur (KVM, Hyper-V, Xen). Vous accédez à « votre » serveur via Internet (SSH, RDP, API), vous payez à l'heure ou à la seconde selon le fournisseur (cf. Pay-as-you-go).
Avantages et inconvénients
Section intitulée « Avantages et inconvénients »✅ Avantages
- Pas d'investissement initial : pas de matériel à acheter, OPEX pur.
- Scalabilité illimitée : de 1 à 10 000 instances en minutes.
- Maintenance gérée : patches matériel, refroidissement, énergie pris en charge.
- Innovation rapide : accès immédiat aux nouvelles technologies (GPU, IA managée, Kubernetes managé).
- Pay-as-you-go : facturation à l'usage seul.
❌ Inconvénients
- Moins de contrôle : vous ne choisissez pas le matériel ni l'hyperviseur.
- Localisation des données : peut être hors UE selon la région choisie.
- Vendor lock-in : dépendance aux services propriétaires du fournisseur.
- Coûts variables : peuvent exploser sans gouvernance (instances oubliées, egress).
- Latence Internet : dépend de votre connexion vers le datacenter.
Pour qui ?
Section intitulée « Pour qui ? »| Profil | Pourquoi cloud public |
|---|---|
| Startups | Pas de capital initial, scalabilité immédiate, focus produit |
| Applications web/mobile | Élasticité pour gérer les pics de trafic |
| Environnements dev/test | Création/destruction rapides, pas de gaspillage |
| Projets agiles | Rapidité prime sur contrôle total |
Exemple concret
Section intitulée « Exemple concret »Une startup SaaS lance son MVP. Jour 1 : 2 instances cloud (50 €/mois) pour 100 utilisateurs bêta. Mois 6 : le produit décolle, autoscaling à 50 instances (2 000 €/mois) pour 10 000 utilisateurs. Mois 12 : levée de fonds réussie, migration vers une architecture conteneurs Kubernetes managé sans réécrire from scratch.
Sans cloud public, il aurait fallu investir 100 000 € dès le jour 1 pour dimensionner « au cas où », avec un risque énorme si le produit échoue. C'est exactement le scénario économique modélisé dans TCO cloud vs on-premise.
3. Cloud privé — le contrôle total
Section intitulée « 3. Cloud privé — le contrôle total »Définition : infrastructure cloud dédiée exclusivement à votre organisation, hébergée dans vos locaux ou chez un prestataire de confiance.
Analogie : votre propre voiture
Section intitulée « Analogie : votre propre voiture »Avoir un cloud privé, c'est comme posséder votre propre voiture plutôt que prendre le métro ou un taxi : plus cher à l'achat et l'entretien, vous décidez de tout (modèle, garage, options), elle est toujours disponible quand vous en avez besoin, mais sa capacité est limitée à ce que vous avez acheté.
Deux variantes
Section intitulée « Deux variantes »On-premise (dans vos locaux) : vous achetez les serveurs, les installez dans votre datacenter ou salle serveur, et déployez une plateforme cloud (OpenStack, VMware vSphere, Proxmox VE, Nutanix). Vous gérez le matériel, l'énergie, le refroidissement, le réseau physique.
Hosted private cloud (chez un tiers) : vous louez des serveurs dédiés chez un hébergeur (OVH Dedicated, Hetzner, Scaleway Bare Metal), mais l'infrastructure reste exclusivement la vôtre — pas de multi-tenancy. Vous évitez les coûts de datacenter sans renoncer au contrôle.
Avantages et inconvénients
Section intitulée « Avantages et inconvénients »✅ Avantages
- Contrôle total : choix du matériel, de l'hyperviseur, des configurations.
- Souveraineté des données : vous savez exactement où elles sont stockées.
- Conformité RGPD : facile à prouver que les données ne quittent pas l'UE.
- Performance prévisible : pas de noisy neighbors en multi-tenancy.
- Personnalisation : configurations exotiques possibles (hardware spécifique, GPU custom).
❌ Inconvénients
- Coût élevé : CAPEX initial 100 000 € à plusieurs millions d'euros.
- Scalabilité limitée : impossible d'ajouter 100 serveurs en 5 minutes.
- Expertise nécessaire : équipe dédiée pour gérer infrastructure, réseau, stockage, hyperviseur.
- Maintenance lourde : pannes hardware, mises à jour, obsolescence à votre charge.
- Délais longs : 2 à 6 mois pour augmenter la capacité (commande, livraison, installation).
Pour qui ?
Section intitulée « Pour qui ? »| Profil | Pourquoi cloud privé |
|---|---|
| Banques | Contraintes réglementaires strictes, données ultra-sensibles |
| Hôpitaux | Données de santé soumises à réglementation (HDS en France) |
| Administrations | Souveraineté nationale, confidentialité défense / renseignement |
| Entreprises legacy | Applications anciennes incompatibles avec le cloud public |
Exemple concret
Section intitulée « Exemple concret »Une banque française traite des données financières de millions de clients. Les exigences légales imposent que les données ne quittent pas le territoire français. Les certifications PCI-DSS pour les cartes bancaires et SecNumCloud / ANSSI sont obligatoires. La performance exige une latence ultra-faible pour les transactions. Les audits de sécurité réguliers nécessitent un contrôle total.
Solution typique : cloud privé on-premise avec datacenters en France métropolitaine, géré par une équipe infrastructure dédiée de plusieurs dizaines de personnes. Coût annuel structurel : plusieurs millions d'euros, mais c'est le prix d'entrée du métier régulé.
4. Cloud hybride — le compromis pragmatique
Section intitulée « 4. Cloud hybride — le compromis pragmatique »Définition : combinaison de cloud public ET privé, avec interconnexion sécurisée permettant le transfert de données et la répartition des workloads.
Pourquoi le cloud hybride existe
Section intitulée « Pourquoi le cloud hybride existe »Le cloud hybride est né d'un constat pragmatique : toutes les applications ne peuvent pas migrer vers le cloud public (réglementations, dépendances legacy, coûts de refonte), mais on veut quand même bénéficier de ses avantages pour les nouveaux projets. Au lieu de choisir « tout public » ou « tout privé », on place chaque workload là où il a le plus de sens.
Exemple concret : site e-commerce
Section intitulée « Exemple concret : site e-commerce »☁️ Cloud public
Site web vitrine + frontend
- Trafic variable (pics promo, soldes Black Friday).
- Besoin d'autoscaling.
- Pas de données sensibles (HTML, CSS, JS, images produit).
→ Hébergé sur CDN + Object Storage chez Scaleway, OVH ou hyperscaler.
🔒 Cloud privé
Base de données clients + transactions
- Données personnelles (RGPD strict).
- Conformité bancaire (PCI-DSS).
- Performance prévisible nécessaire.
- Connexions privées avec banques partenaires.
→ Hébergée on-premise ou en hosted private.
Communication entre les deux environnements via tunnel VPN sécurisé ou interconnexion directe (Direct Connect AWS, ExpressRoute Azure, Cloud Interconnect GCP, équivalent Outscale). Quand un client passe commande sur le site (cloud public), la transaction est routée de manière sécurisée vers la base de données (cloud privé) pour validation.
Architecture hybride type
Section intitulée « Architecture hybride type »
Avantages et inconvénients
Section intitulée « Avantages et inconvénients »✅ Avantages
- Flexibilité maximale : best of both worlds.
- Migration progressive : pas de big bang, on migre service par service.
- Optimisation coûts : workloads stables sur privé, variables sur public.
- Conformité partielle : données sensibles restent sur privé, le reste sur public.
❌ Inconvénients
- Complexité élevée : deux environnements à gérer, compétences doubles.
- Coût réseau : transferts public/privé facturés (egress).
- Latence : communication inter-cloud plus lente qu'intra-cloud.
- Sécurité complexe : plus de points d'entrée/sortie à protéger.
- Gestion des identités : IAM à synchroniser entre environnements.
Pour qui ?
Section intitulée « Pour qui ? »| Profil | Pourquoi cloud hybride |
|---|---|
| Grandes entreprises en transition | Migration progressive sans arrêt d'activité |
| Secteurs partiellement réglementés | Certaines données peuvent aller au cloud, d'autres non |
| Applications legacy coûteuses à refondre | Garder le legacy on-prem, développer sur public |
| Workloads mixtes | Batch intensif sur privé, frontend scalable sur public |
5. Multi-cloud — la stratégie de répartition
Section intitulée « 5. Multi-cloud — la stratégie de répartition »Définition : utilisation simultanée de plusieurs fournisseurs de cloud public pour répartir les risques, optimiser les coûts par service, ou répondre à des contraintes géographiques.
Pourquoi le multi-cloud
Section intitulée « Pourquoi le multi-cloud »Trois raisons principales poussent les entreprises vers le multi-cloud, dans l'ordre de fréquence réelle :
- Multi-cloud accidentel (le plus courant) : fusion-acquisition d'une entreprise déjà sur un autre cloud, ou rachat d'un produit historique, sans intention stratégique multi-cloud à l'origine.
- Optimisation par service : choisir le moins cher ou le plus mature pour chaque besoin (BigQuery GCP pour l'analytique, S3 AWS pour l'objet, OKS Outscale pour la souveraineté Kubernetes).
- Résilience géographique ou stratégique : si AWS tombe en panne (rare mais possible), basculer sur Azure. Ou si Cloud Act évolue, basculer sur souverain européen.
Exemple d'architecture multi-cloud souverain
Section intitulée « Exemple d'architecture multi-cloud souverain »Une entreprise européenne peut composer une architecture comme suit, en privilégiant les fournisseurs souverains pour les données sensibles :
| Service | Fournisseur | Raison |
|---|---|---|
| VM compute principal | Outscale | Certification SecNumCloud, souveraineté technologique |
| Stockage objet | Scaleway Object Storage | Tarif compétitif, datacenter en France |
| Kubernetes managé | OVHcloud Managed Kubernetes | Bon rapport qualité/prix, support en français |
| Backup secondaire | Infomaniak | Hébergé 100 % en Suisse, RGPD-compliant |
Chaque service tourne chez le fournisseur adapté au besoin (prix, certification, localisation, expertise).
Avantages et inconvénients
Section intitulée « Avantages et inconvénients »✅ Avantages
- Pas de vendor lock-in unique : liberté de migrer si un fournisseur devient trop cher.
- Meilleur prix par service : optimisation service par service.
- Résilience maximale : basculement possible si un cloud tombe.
- Respect souveraineté : données UE sur cloud européen, données non-sensibles ailleurs.
❌ Inconvénients
- Complexité maximale : équipes doivent maîtriser 3 clouds différents.
- Coûts de transfert inter-cloud : egress très cher entre fournisseurs.
- Compétences multi-cloud : formations et certifications coûteuses.
- Outils de gestion : monitoring, logging, IAM à unifier (Terraform, Datadog, Grafana).
- Support fragmenté : 3 tickets différents pour un incident global.
Pour qui ?
Section intitulée « Pour qui ? »| Profil | Pourquoi multi-cloud |
|---|---|
| Grandes entreprises cloud-native | Équipes matures avec expertise multi-cloud |
| Haute disponibilité critique | Résilience maximale exigée (finance, e-commerce) |
| Optimisation coûts avancée | FinOps mature, choisir le meilleur prix par service |
| Fusions / acquisitions | Hérité de rachats d'entreprises sur clouds différents |
6. Sovereign cloud — le 5e modèle qui s'impose en Europe
Section intitulée « 6. Sovereign cloud — le 5e modèle qui s'impose en Europe »Définition : variante de cloud public ou privé qualifiée pour garantir l'indépendance juridique et technologique vis-à-vis d'États tiers. C'est un modèle qui n'existait pas explicitement dans la classification NIST de 2011 — il s'est imposé entre 2018 et 2026 sous la pression de la souveraineté numérique européenne.
Pourquoi un 5e modèle distinct
Section intitulée « Pourquoi un 5e modèle distinct »Le cloud public américain (AWS, Azure, GCP) est juridiquement soumis au CLOUD Act et au FISA Section 702, ce qui permet au gouvernement américain d'exiger l'accès à des données stockées chez un acteur US, même si ces données sont physiquement en France. Cette extraterritorialité juridique est incompatible avec certaines obligations RGPD strictes ou réglementations sectorielles (santé, défense, finance, administration).
Le sovereign cloud répond à ce besoin par trois piliers : juridiction du fournisseur intégralement européenne, gouvernance opérationnelle européenne (capital, dirigeants, salariés), et idéalement technologie de la stack indépendante des éditeurs américains. Le détail technique vit dans Souveraineté technologique de la stack, parce que ce dernier point est souvent mal compris et mérite une page entière.
Les variantes sovereign cloud
Section intitulée « Les variantes sovereign cloud »Sovereign public cloud : un cloud public opéré par un fournisseur européen sous juridiction européenne. Exemples français qualifiés SecNumCloud par l'ANSSI en 2026 : Outscale, OVHcloud, Cegedim, Cloud Temple, Orange Business, Worldline.
Sovereign private cloud : cloud privé construit sur des technologies européennes ou open source auditées, hébergé dans un datacenter européen, opéré par du personnel européen. Variante plus exigeante mais aussi plus coûteuse.
Sovereign hybride : combinaison sovereign privé pour les données sensibles + sovereign public pour les workloads variables. Le compromis qui équilibre coût et conformité.
Alliances « souveraines » à techno étrangère : Bleu (Microsoft × Capgemini × Orange), S3NS (Google × Thales). Ces offres revendiquent la souveraineté juridique mais reposent sur des technologies américaines (Azure, Google Cloud) dont le support, les patches et les mises à jour dépendent du fournisseur amont. Ce ne sont pas des sovereign clouds au sens technologique, et ce point fait l'objet d'une opinion éditoriale documentée.
Avantages et inconvénients
Section intitulée « Avantages et inconvénients »✅ Avantages
- Juridiction européenne garantie : pas de CLOUD Act, pas de FISA.
- Conformité réglementaire : SecNumCloud, HDS, ISO 27017/27018.
- Souveraineté technologique (selon le fournisseur) : stack libre auditée.
- Tarifs egress souvent compétitifs : 5 à 10 fois moins cher que les hyperscalers.
- Support en français : pour les équipes francophones, c'est un confort opérationnel.
❌ Inconvénients
- Catalogue de services plus restreint : moins de services managés exotiques (IA, ML, edge).
- Maturité variable : certaines fonctionnalités cloud-native ont 2 à 3 ans de retard.
- Écosystème plus petit : moins d'intégrations tierces, moins de fournisseurs SaaS compatibles.
- Pricing parfois moins agressif sur le compute brut.
Pour qui ?
Section intitulée « Pour qui ? »| Profil | Pourquoi sovereign cloud |
|---|---|
| Administrations publiques | Doctrine « Cloud au centre » 2021–2026, obligation légale |
| Hôpitaux, cliniques | Données de santé soumises à HDS |
| Banques, assurances | Données financières, audit ANSSI |
| Entreprises ETI manipulant données européennes sensibles | Conformité RGPD stricte, anticipation NIS2 |
| Défense, renseignement | Sécurité nationale, exclusivité juridique |
7. Community cloud — le modèle oublié du NIST
Section intitulée « 7. Community cloud — le modèle oublié du NIST »Définition : infrastructure cloud mutualisée entre plusieurs organisations qui partagent des contraintes communes (réglementaires, métier, géographiques). Présent dans la classification NIST originale, peu utilisé sous ce nom dans le marketing, pourtant bien réel sur certains segments.
Comment ça se concrétise
Section intitulée « Comment ça se concrétise »Un community cloud est financé et utilisé conjointement par un consortium d'organisations qui mutualisent l'infrastructure parce qu'elles ont les mêmes besoins de conformité. Exemples concrets :
Recherche académique : EUDAT, EGI, OpenStack-based clouds opérés par les universités européennes pour partager les coûts d'une infrastructure de calcul scientifique.
Santé : projets régionaux d'hébergement HDS mutualisé entre plusieurs CHU, qui partagent un datacenter HDS sans pouvoir se permettre individuellement le coût d'une infrastructure dédiée.
Secteur public : initiatives type FranceCloud (en réflexion 2024–2026) ou GENCI pour le calcul intensif administratif.
Finance : R3 Corda Network pour la blockchain interbancaire, infrastructure mutualisée entre banques participantes.
Avantages et inconvénients
Section intitulée « Avantages et inconvénients »✅ Avantages
- Coût partagé : permet à des organisations seules d'accéder à une infra qu'elles n'auraient pas individuellement.
- Conformité commune : optimisée pour les contraintes du secteur (HDS santé, eIDAS administration).
- Gouvernance partagée : décisions stratégiques par consortium, pas par fournisseur tiers.
- Souveraineté partielle : possible si tous les membres sont européens.
❌ Inconvénients
- Lourdeur de gouvernance : décisions à plusieurs, plus lentes.
- Catalogue limité : focalisé sur les besoins du consortium.
- Maturité variable : dépend fortement de l'expertise et de la dynamique du consortium.
- Modèle peu connu : peu de littérature, peu d'acteurs marchands.
Pour qui ?
Section intitulée « Pour qui ? »| Profil | Pourquoi community cloud |
|---|---|
| Consortium de recherche | Mutualisation calcul scientifique entre universités |
| Santé multi-établissements | HDS partagé entre plusieurs CHU |
| Initiatives sectorielles | Aviation (SITA), finance (R3), administration |
| Coopératives publiques | Infrastructure mutualisée entre collectivités locales |
8. Tableau comparatif des 6 modèles
Section intitulée « 8. Tableau comparatif des 6 modèles »| Critère | Public | Privé | Hybride | Multi | Sovereign | Community |
|---|---|---|---|---|---|---|
| CAPEX initial | 0 € | 100 k€ à M€ | Moyen | 0 € | 0 € (public) à M€ (privé) | Partagé |
| OPEX mensuel | Variable | Fixe + maintenance | Mixte | Variable × N | Variable | Partagé |
| Scalabilité | Illimitée | Limitée matériel | Mixte | Illimitée | Élevée mais < hyperscalers | Limitée |
| Complexité | Faible | Moyenne | Élevée | Maximale | Faible à moyenne | Élevée gouvernance |
| Contrôle données | Faible | Total | Partiel | Faible × N | Élevé | Partagé |
| Vendor lock-in | Élevé | Aucun | Moyen | Réparti | Faible (souverain libre) | Moyen |
| Conformité UE / RGPD | Variable | Élevée | Élevée | Variable | Maximale | Élevée |
| Souveraineté juridique | Faible (US) | Élevée | Mixte | Variable | Maximale | Élevée |
| Délai provisioning | Secondes | Semaines | Mixte | Secondes | Secondes | Variable |
9. Comment choisir selon votre profil
Section intitulée « 9. Comment choisir selon votre profil »Vous êtes une startup ou PME
Section intitulée « Vous êtes une startup ou PME »→ Cloud public par défaut. Privilégiez un fournisseur européen (Outscale, OVHcloud, Scaleway) plutôt qu'un hyperscaler américain si vous manipulez des données de citoyens européens — c'est le défaut le plus défendable juridiquement en 2026, sans sacrifier la simplicité.
Vous êtes une ETI manipulant des données réglementées
Section intitulée « Vous êtes une ETI manipulant des données réglementées »→ Sovereign cloud public (Outscale, OVHcloud SecNumCloud) ou hybride sovereign + privé. Le sovereign public couvre 80 % des cas, le privé n'est nécessaire que pour les workloads les plus sensibles ou les contraintes techniques très spécifiques.
Vous êtes dans un secteur ultra-réglementé (banque, défense, santé hospitalière)
Section intitulée « Vous êtes dans un secteur ultra-réglementé (banque, défense, santé hospitalière) »→ Cloud privé ou hybride sovereign. Les contraintes réglementaires (PCI-DSS, ANSSI, HDS) imposent souvent des audits que seul un cloud privé ou sovereign certifié peut passer. Démarrez par évaluer ce qui peut aller en sovereign public, gardez en privé uniquement ce qui doit absolument rester sous votre contrôle direct.
Vous avez des applications legacy lourdes
Section intitulée « Vous avez des applications legacy lourdes »→ Cloud hybride assumé. Migration progressive du nouveau sur public/sovereign, conservation du legacy sur privé tant que la refonte n'est pas justifiable économiquement.
Vous êtes une multinationale cloud-native
Section intitulée « Vous êtes une multinationale cloud-native »→ Multi-cloud assumé si vos équipes sont matures, mono-cloud sinon. Le multi-cloud à 50/50 sur deux hyperscalers américains coûte plus cher que la valeur qu'il apporte dans 80 % des cas.
Vous êtes une administration française
Section intitulée « Vous êtes une administration française »→ Sovereign public SecNumCloud obligatoire depuis la doctrine « Cloud au centre » de 2021. Outscale, OVHcloud Public Cloud, Cegedim, Cloud Temple selon le périmètre fonctionnel.
10. Pièges classiques des choix de déploiement
Section intitulée « 10. Pièges classiques des choix de déploiement »Piège 1 — « On-premise = cloud privé ». Faux. Avoir des serveurs dans vos locaux ne fait pas un cloud privé. Un vrai cloud privé exige API self-service, autoscaling, orchestration automatisée. Sans ces propriétés, vous avez un datacenter classique, pas un cloud. La nuance est cruciale parce que les bénéfices du cloud (élasticité, agilité) ne tombent pas du ciel — ils viennent de l'API et de l'orchestration, pas de la virtualisation seule.
Piège 2 — « Multi-cloud par défaut pour éviter le lock-in ». Faux. Le multi-cloud sans expertise multi-cloud crée plus de lock-in qu'il n'en évite, parce que chaque équipe finit par maîtriser un fournisseur et tolérer mal les autres. Maîtrisez un cloud d'abord, ajoutez un second uniquement si besoin objectif (résilience, optimisation par service, contrainte géographique).
Piège 3 — « Cloud public = moins cher ». Faux. Sans gouvernance FinOps, le cloud public peut coûter plus cher qu'on-prem (cf. TCO cloud vs on-premise). Le cloud public est moins cher uniquement sur les workloads variables avec un ratio pic/baseline supérieur à 3.
Piège 4 — « Hybride = meilleur des deux mondes ». Faux. Hybride mal géré = complexité des deux mondes. N'allez hybride que si vous avez une contrainte objective (réglementaire, technique, budgétaire). Si vous pouvez tout mettre sur public ou tout sur privé, faites-le.
Piège 5 — « Sovereign cloud = juste un cloud français ». Faux. La souveraineté inclut la juridiction, l'opération, et la technologie de la stack. Une offre Bleu ou S3NS revendiquant la souveraineté juridique peut rester techniquement vulnérable à une coupure unilatérale du fournisseur amont — c'est précisément ce que documente Souveraineté technologique de la stack. Vérifier les trois piliers, pas seulement le siège social.
11. Critères pour choisir entre les modèles
Section intitulée « 11. Critères pour choisir entre les modèles »Plutôt qu'un défaut universel, voici les critères d'évaluation à pondérer selon votre contexte. Le bon modèle dépend du métier, des données, des compétences disponibles, et des contraintes réglementaires.
Critère 1 — La sensibilité juridique des données. Les données personnelles RGPD, les données de santé HDS, les données soumises à secret bancaire ou défense exigent une vigilance particulière sur la juridiction applicable au fournisseur. Le CLOUD Act américain peut s'appliquer aux fournisseurs US même s'ils hébergent en Europe, tandis qu'un fournisseur européen sous juridiction européenne offre une garantie juridique différente. Ce critère est traité en détail dans Souveraineté technologique de la stack.
Critère 2 — La maturité technique requise. Les besoins en services managés très spécialisés (IA générative entraînée, services data warehouse à grande échelle, edge computing global) sont mieux servis par les hyperscalers américains qui ont 5 à 10 ans d'avance sur certains segments. Les besoins standards (VM, stockage objet, base managée, Kubernetes managé, conteneurs serverless) sont disponibles chez tous les fournisseurs.
Critère 3 — Le profil de charge réseau. Les applications à fort trafic sortant (média, e-commerce volumique, gaming) sont sensibles aux tarifs egress, qui varient significativement entre fournisseurs. Voir Egress et data transfer pour le détail des grilles tarifaires.
Critère 4 — Les compétences de l'équipe. Une équipe formée à un écosystème spécifique (AWS, Azure, GCP, Outscale, OVHcloud) déploie plus vite et mieux dans cet écosystème. Le coût d'apprentissage d'un nouvel écosystème est non négligeable et doit être intégré au choix.
Critère 5 — La stratégie long terme. Un projet à 18 mois peut accepter un lock-in fort, un projet à 5–10 ans gagne à privilégier des standards portables (containers OCI, Kubernetes upstream, S3-compatible API).
Ces critères se combinent. Une startup MVP avec données non sensibles peut démarrer chez n'importe quel fournisseur selon les compétences. Une administration française est tenue par la doctrine « Cloud au centre » d'utiliser un cloud qualifié SecNumCloud par l'ANSSI. Un éditeur SaaS B2B européen équilibre généralement maturité technique, conformité RGPD et souveraineté juridique selon son marché cible.
À retenir
Section intitulée « À retenir »- Le NIST définit 4 modèles (public, privé, hybride, community), la pratique 2026 en compte 6 avec multi-cloud et sovereign cloud.
- Cloud public reste le défaut pour les charges variables et les MVP — mais le défaut européen souverain s'impose face aux hyperscalers américains pour les données réglementées.
- Cloud privé se justifie en secteur ultra-réglementé, en legacy, ou avec contrainte technique spécifique.
- Hybride résout des contraintes réelles mais ajoute de la complexité — n'y aller que si nécessaire.
- Multi-cloud stratégique 50/50 est un mythe coûteux ; multi-cloud accidentel est courant et acceptable ; multi-cloud souverain par service est la meilleure version.
- Sovereign cloud s'impose en Europe pour des raisons juridiques (CLOUD Act, FISA), techniques (rattrapage de maturité) et financières (egress).
- Community cloud existe et structure des consortiums (recherche, santé, finance) — sous-utilisé mais valable pour des contextes spécifiques.