Modèles de déploiement cloud : public, privé, hybride et multi-cloud

Les modèles de déploiement cloud définissent où réside votre infrastructure, qui l'exploite et comment les charges de travail circulent entre les environnements. Les quatre modèles principaux — public, privé, hybride et multi-cloud — imposent chacun des compromis différents en matière de coûts, de conformité, de complexité opérationnelle et de performance. Un choix éclairé exige une analyse au niveau de chaque charge de travail, et non une politique uniforme. Ce guide détaille chaque modèle avec les spécificités opérationnelles et le contexte réglementaire français et européen que les présentations génériques omettent.

Points clés à retenir

• Les quatre modèles de déploiement cloud — public, privé, hybride et multi-cloud — présentent chacun des compromis distincts en matière de coût, de contrôle, de conformité et de complexité opérationnelle.
• Le cloud hybride est le modèle le plus largement adopté par les entreprises, selon le rapport State of the Cloud de Flexera, car il permet de placer chaque charge de travail là où elle est la plus pertinente.
• Les organisations européennes doivent évaluer leurs choix de déploiement cloud au regard des exigences NIS2 et du RGPD en matière de résidence des données ; les entreprises indiennes font face à un examen similaire dans le cadre du DPDPA 2023.
• Le multi-cloud n'est pas synonyme de cloud hybride — confondre les deux entraîne une prolifération architecturale, une duplication des outils et des coûts incontrôlés.
• Le choix d'un modèle de déploiement n'est pas une décision ponctuelle ; la classification des charges de travail et une réévaluation périodique empêchent toute dérive vers un modèle inadapté.

Qu'est-ce qu'un modèle de déploiement cloud ?

Un modèle de déploiement cloud décrit la propriété, le périmètre d'accès et la localisation physique de l'infrastructure cloud. Il répond à trois questions : Qui possède le matériel ? Qui peut accéder à l'environnement ? Où les données résident-elles physiquement ?

Ce concept est distinct des modèles de service cloud (IaaS, PaaS, SaaS), qui décrivent le niveau d'abstraction — ce que le fournisseur gère par rapport à ce que vous gérez. Un modèle de déploiement porte sur le où et le comment ; un modèle de service porte sur le quoi. Vous pouvez exécuter de l'IaaS sur un cloud privé ou consommer du SaaS délivré via une architecture hybride. Les deux taxonomies sont orthogonales.

La définition du NIST SP 800-145 identifie quatre modèles de déploiement : public, privé, hybride et communautaire. L'industrie a depuis ajouté le multi-cloud comme cinquième modèle de facto, car ses caractéristiques opérationnelles diffèrent significativement du cloud hybride. Nous couvrons les cinq ci-dessous.

Cloud public

Fonctionnement

L'infrastructure de cloud public est détenue et exploitée par un fournisseur tiers — AWS, Microsoft Azure, Google Cloud Platform (GCP) ou d'autres — et partagée entre de multiples locataires. Vous consommez des ressources à la demande, payez à l'usage, et le fournisseur gère l'approvisionnement matériel, la sécurité physique et l'administration de base de la plateforme.

Les principaux fournisseurs exploitent des régions à l'échelle mondiale. AWS dispose de régions à Paris (eu-west-3), Francfort (eu-central-1) et Stockholm (eu-north-1). Azure opère dans les régions France Central, Germany West Central et Sweden Central. GCP propose europe-west9 (Paris) et europe-north1 (Finlande). Le choix de la région est déterminant pour la latence, la résidence des données et la tarification — ce n'est pas un détail à traiter après coup.

Quand le cloud public est le bon choix

• Charges de travail variables ou imprévisibles : l'auto-scaling élimine les approximations du capacity planning. Vous payez ce que vous consommez, pas ce dont vous pourriez avoir besoin.
• Startups et équipes en mode itération rapide : zéro CapEx initial, provisionnement instantané. Livrez d'abord, optimisez ensuite.
• Applications stateless ou cloud-native : les microservices conteneurisés, les fonctions serverless (AWS Lambda, Azure Functions, Cloud Run) et les bases de données managées (RDS, Cloud SQL) sont conçus pour les primitives du cloud public.
• Environnements de développement/test : on crée, on exécute les tests, on détruit. La capacité réservée n'a pas de sens ici.

Là où le cloud public atteint ses limites

• Contraintes de souveraineté des données : l'article 44 du RGPD restreint les transferts de données personnelles en dehors de l'EEE sauf en présence de protections adéquates. Utiliser la région européenne d'un fournisseur dont le siège est aux États-Unis est généralement admis, mais les implications de l'arrêt Schrems II et les évolutions du EU-US Data Privacy Framework nécessitent une analyse juridique — pas simplement la sélection d'une région. En France, la CNIL surveille de près ces transferts et peut sanctionner les organisations qui ne respectent pas ces obligations. Pour les données sensibles, le label SecNumCloud de l'ANSSI impose des exigences supplémentaires aux fournisseurs cloud.
• Charges stables à utilisation élevée : une VM qui tourne à 80 %+ d'utilisation en 24/7 pendant des années est presque toujours moins coûteuse on-premises ou en cloud privé. Les Reserved Instances et Savings Plans (offrant typiquement 30 à 60 % d'économie par rapport au tarif à la demande, selon la documentation AWS) réduisent l'écart mais ne l'éliminent pas pour des charges véritablement statiques.
• Environnements hautement réglementés : certains régulateurs financiers et agences de défense exigent une isolation physique que la séparation logique des locataires en cloud public ne satisfait pas.

Services cloud managés

Cloud privé

Fonctionnement

Le cloud privé dédie l'infrastructure à une seule organisation. Il peut fonctionner on-premises dans votre propre centre de données ou être hébergé par un tiers (cloud privé hébergé). La caractéristique déterminante est le mono-locataire et le contrôle direct sur l'ensemble de la pile d'infrastructure.

Les clouds privés modernes utilisent les mêmes technologies d'orchestration que les fournisseurs publics. VMware Cloud Foundation, OpenStack, Nutanix et Azure Stack HCI offrent des modèles de consommation de type IaaS en interne. Des distributions Kubernetes comme Red Hat OpenShift ou Rancher ajoutent l'orchestration de conteneurs par-dessus.

Quand le cloud privé est pertinent

• Régimes de conformité stricts : les établissements financiers soumis aux réglementations nationales (par exemple l'ACPR et l'AMF en France, BaFin en Allemagne) font parfois face à des exigences imposant une isolation physique vérifiable. Les organisations de santé traitant des données de patients dans le cadre du RGPD et des recommandations de la CNIL préfèrent souvent une infrastructure privée pour simplifier les chaînes de responsabilité. Le label SecNumCloud de l'ANSSI, requis pour les opérateurs d'importance vitale (OIV) et de plus en plus exigé par les administrations publiques françaises, peut orienter vers le cloud privé ou des offres de cloud public qualifiées.
• Calcul prévisible et à haute densité : les charges de travail HPC, le traitement batch à grande échelle ou l'entraînement de modèles ML sur des clusters GPU dédiés peuvent s'avérer plus rentables sur du matériel détenu en propre lorsque le taux d'utilisation reste élevé.
• Dépendances applicatives historiques : les charges proches du mainframe ou les applications avec des dépendances codées en dur sur des IP, des protocoles non TCP/IP, ou des licences liées à des cœurs physiques ne peuvent souvent pas migrer vers le cloud public sans réécriture.

Les coûts réels que l'on sous-estime

Le cloud privé n'est pas « gratuit parce qu'on possède déjà les serveurs ». Les engagements Cloud FinOps d'Opsio révèlent systématiquement des coûts cachés : alimentation électrique et refroidissement des salles, cycles de renouvellement matériel (typiquement 3 à 5 ans), personnel pour gérer les firmwares, les correctifs et la sécurité physique, plus le coût d'opportunité d'ingénieurs qui effectuent des tâches indifférenciées au lieu de développer les fonctionnalités produit.

Le calcul honnête : si votre taux d'utilisation moyen est inférieur à 60 %, vous payez probablement trop cher pour le cloud privé. S'il dépasse régulièrement 75 %, vous économisez vraisemblablement par rapport au tarif à la demande du cloud public — mais il faut intégrer le coût d'agilité lié aux délais d'approvisionnement.

Cloud hybride

Fonctionnement

Le cloud hybride connecte une infrastructure privée (on-premises ou hébergée) à un ou plusieurs environnements de cloud public via l'orchestration, le réseau et souvent des couches d'identité partagées. Ce qui le distingue du simple fait d'utiliser les deux, c'est l'intégration : les charges de travail, les données et les plans de gestion fonctionnent de manière coordonnée entre les environnements.

Les technologies clés sous-jacentes incluent :

Pourquoi le cloud hybride domine l'adoption en entreprise

Selon le rapport State of the Cloud de Flexera, le mode hybride est systématiquement la stratégie dominante des entreprises depuis plusieurs années consécutives. Les raisons sont pratiques, pas théoriques :

1. La migration est progressive : aucune entreprise ne bascule l'intégralité de son SI vers le cloud public en une seule étape. Le mode hybride est l'architecture de transition naturelle lors de tout programme de Migration cloud.

2. Flexibilité du placement des charges de travail : les données sensibles restent sur l'infrastructure privée tandis que les applications client scalent sur le cloud public. Une entreprise française de e-commerce pourrait conserver les données à caractère personnel dans un environnement privé hébergé en France tout en exécutant sa couche CDN et de calcul sur AWS eu-west-3 (Paris).

3. Capacité de burst : exécuter le calcul de base on-premises et basculer vers le cloud public lors des pics — trafic des soldes, traitements batch de fin de trimestre, demande saisonnière.

4. PRA et résilience : utiliser le cloud public comme cible de reprise après sinistre pour les charges on-premises. AWS Elastic Disaster Recovery, Azure Site Recovery et des services similaires rendent cela opérationnellement viable.

Défis opérationnels du cloud hybride

Le cloud hybride n'offre pas « le meilleur des deux mondes » sans effort. Fort de l'expérience du NOC 24/7 d'Opsio dans la gestion d'environnements hybrides, les points de friction récurrents sont :

• Complexité réseau : les charges sensibles à la latence réparties entre environnements créent des cauchemars de débogage. Si votre base de données est on-premises et votre application dans le cloud public, chaque requête traverse l'interconnexion. Mesurez cela avant de l'architecturer.
• Posture de sécurité incohérente : règles de pare-feu on-prem, security groups dans AWS, NSGs dans Azure — trois langages de politique différents décrivant la même intention. La dérive est inévitable sans Infrastructure as Code (Terraform, Pulumi) et validation continue des politiques (OPA, Checkov).
• Fragmentation du monitoring : une alerte se déclenche dans CloudWatch, une autre dans votre instance Zabbix on-prem, une troisième dans Datadog. Sans couche d'observabilité unifiée, votre équipe SOC perd du temps à corréler les informations entre consoles au lieu de résoudre les incidents.

Sécurité cloud

Multi-cloud

Multi-cloud vs. hybride : une distinction nécessaire

Ces termes sont souvent utilisés de manière interchangeable. Ils ne devraient pas l'être. Hybride signifie combiner infrastructure privée et publique. Multi-cloud signifie utiliser deux fournisseurs de cloud public ou plus. Une organisation qui utilise AWS et Azure est multi-cloud. Une organisation qui utilise AWS et un cluster VMware on-premises est hybride. Une organisation qui fait les deux est en mode hybride multi-cloud — et le gérer constitue le scénario le plus complexe opérationnellement en infrastructure cloud.

Multi-cloud délibéré vs. accidentel

Cette distinction est plus importante que n'importe quel diagramme d'architecture. La plupart des environnements multi-cloud sont accidentels : l'équipe produit a choisi AWS, l'équipe data a choisi GCP pour BigQuery, et l'entreprise a acquis une société qui fonctionnait entièrement sur Azure. Personne ne l'a planifié ; c'est arrivé tout seul.

Le multi-cloud délibéré répond à des justifications spécifiques :

• Exigences réglementaires : certains régulateurs financiers européens imposent une atténuation du risque de concentration — ne pas dépendre d'un seul fournisseur cloud pour les services critiques. L'article 21 de NIS2 exige des « stratégies TIC multi-fournisseurs » dans certaines interprétations pour les entités essentielles. En France, l'ACPR et l'AMF portent une attention particulière à ce risque de concentration pour les établissements financiers.
• Services best-of-breed : GCP BigQuery pour l'analytique, AWS pour le calcul général, Azure pour l'intégration Microsoft 365 et Active Directory. C'est défendable lorsque le coût de la mise en réseau inter-cloud et de la surcharge opérationnelle est justifié par l'avantage au niveau du service.
• Couverture géographique : aucun fournisseur ne dispose de régions partout. Une organisation nécessitant du calcul local dans un pays où un seul fournisseur dispose d'une région sera multi-cloud par nécessité.

La taxe opérationnelle du multi-cloud

En gérant le DevOps managé d'Opsio sur des parcs multi-cloud, nous constatons clairement cette taxe opérationnelle :

• Divergence IAM : AWS IAM, Azure Entra ID et GCP IAM utilisent des modèles de permissions différents, des mécanismes de chaîne de confiance différents et des formats de logs d'audit différents. Construire une couche de gouvernance des accès unifiée nécessite un investissement significatif en outillage.
• Fragmentation de la visibilité des coûts : AWS Cost Explorer, Azure Cost Management et GCP Billing Export produisent chacun des données dans des schémas différents. Sans plateforme Cloud FinOps (Apptio Cloudability, Vantage ou similaire), vous ne pouvez pas répondre à la question « combien coûte cette application par mois ? » de manière transverse.
• Dilution des compétences : chaque fournisseur cloud propose des milliers de services. L'expertise approfondie sur les trois est rare. Des équipes dispersées entre fournisseurs n'en maîtrisent aucun.

La recommandation honnête : ne poursuivez pas le multi-cloud comme stratégie en soi. Ne l'adoptez que lorsque vous avez une raison spécifique et défendable pour chaque fournisseur supplémentaire, et budgétez la surcharge opérationnelle que cela engendre.

Cloud communautaire

Le cloud communautaire — infrastructure partagée entre organisations ayant des exigences communes — est le modèle le moins discuté mais reste pertinent dans des secteurs spécifiques. Parmi les exemples : les clouds communautaires gouvernementaux (AWS GovCloud, Azure Government), les communautés de recherche (GÉANT en Europe, le cloud RENATER en France) et les consortiums industriels partageant une infrastructure conforme.

En pratique, le cloud communautaire est architecturalement similaire à un cloud privé avec une mutualisation entre organisations vérifiées. Sa pertinence est étroite mais réelle : si vous êtes une collectivité territoriale française partageant une infrastructure avec d'autres collectivités via un opérateur comme Numspot ou les offres cloud de la DINUM, vous êtes sur un cloud communautaire.

Comparaison des modèles de déploiement cloud

Comment choisir le bon modèle de déploiement cloud

Le choix d'un modèle de déploiement est une décision au niveau de la charge de travail, pas de l'organisation. Différentes applications au sein d'une même entreprise relèvent légitimement de modèles différents. Voici le cadre décisionnel appliqué par Opsio :

Étape 1 : Classifier vos charges de travail

Pour chaque charge de travail, évaluez :

• Sensibilité des données : traite-t-elle des données personnelles au sens du RGPD, des données financières soumises à la réglementation bancaire, ou des données de santé au regard des lois nationales de santé ? Sous NIS2, les entités essentielles et importantes de 18 secteurs doivent mettre en œuvre des mesures de gestion des risques qui peuvent contraindre les options de déploiement. En France, les données traitées par les OIV et les OSE sont soumises à des exigences spécifiques de l'ANSSI.
• Profil de performance : sensible à la latence (doit être proche des utilisateurs ou d'autres systèmes), intensive en débit (nécessite une bande passante élevée), ou intensive en calcul (nécessite du matériel spécifique comme des GPU) ?
• Variabilité de la demande : état stable, pics saisonniers ou montées en charge imprévisibles ?
• Dépendances d'intégration : cette charge dépend-elle de systèmes on-premises (bases de données, mainframes, APIs historiques) ?

Étape 2 : Cartographier les contraintes

• Réglementaires : exigences RGPD de résidence des données, restrictions de transfert transfrontalier du DPDPA 2023, règles sectorielles (DSP2 pour les paiements, MiFID II pour le trading), qualification SecNumCloud de l'ANSSI pour les données sensibles des administrations et OIV français.
• Financières : budget CapEx disponible, matériel existant avec durée de vie utile résiduelle, engagements de consommation avec les fournisseurs.
• Organisationnelles : compétences de l'équipe, outillage existant, relations fournisseurs.

Étape 3 : Sélectionner par charge de travail, puis consolider

Une fois que chaque charge de travail a un modèle cible, l'agrégation détermine votre modèle organisationnel. Si toutes les charges ciblent le cloud public, vous êtes en mode cloud public exclusif. Si les charges se répartissent entre privé et public, vous êtes en mode hybride. Si elles s'étendent sur plusieurs fournisseurs publics, vous êtes en multi-cloud.

Étape 4 : Réévaluer périodiquement

Le déploiement cloud n'est pas une décision figée. Les caractéristiques des charges de travail évoluent. La tarification change. La réglementation évolue. Opsio recommande une réévaluation formelle au minimum annuelle, alignée sur les cycles de renouvellement de contrats et les calendriers d'audits de conformité.

Considérations de conformité en Europe et en Inde

Union européenne et France

RGPD : l'article 44 restreint les transferts de données personnelles en dehors de l'EEE. Les choix de modèle de déploiement doivent garantir que les contrôles de résidence des données sont architecturalement imposés, et pas seulement fondés sur des politiques. AWS, Azure et GCP proposent tous des engagements de résidence des données en région UE, mais des configurations comme la réplication inter-régions, la mise en cache CDN et les outils d'accès pour le support peuvent transférer involontairement des données en dehors des périmètres prévus. En France, la CNIL est particulièrement vigilante sur ces points et a rendu plusieurs décisions contraignantes concernant les transferts de données vers les États-Unis.

Directive NIS2 : applicable depuis octobre 2024 et transposée en droit français, NIS2 exige des entités essentielles et importantes qu'elles mettent en œuvre des mesures techniques et organisationnelles appropriées de gestion des risques cyber. Cela inclut la sécurité de la chaîne d'approvisionnement — votre fournisseur cloud fait partie de votre chaîne d'approvisionnement. Les décisions de modèle de déploiement doivent documenter comment chaque modèle satisfait les exigences de l'article 21 de NIS2.

Souveraineté cloud : le label SecNumCloud de l'ANSSI impose des exigences supplémentaires aux fournisseurs cloud, notamment l'immunité vis-à-vis des législations extraterritoriales non européennes. Les organisations traitant des données sensibles pour l'État français ou les OIV peuvent être contraintes de recourir à des fournisseurs qualifiés SecNumCloud (comme les offres de 3DS Outscale, OVHcloud ou les futures offres Bleu et S3ns), ce qui peut restreindre significativement les options de modèle de déploiement. L'attestation C5 du BSI allemand constitue un cadre complémentaire pour les organisations opérant également en Allemagne.

Inde

DPDPA 2023 : la loi indienne sur la protection des données personnelles numériques habilite le gouvernement central à restreindre les transferts transfrontaliers de données personnelles à des pays notifiés. Les organisations déployant en Inde doivent s'assurer que le traitement principal des données s'effectue dans les régions indiennes (AWS ap-south-1 Mumbai, Azure Central India, GCP asia-south1 Mumbai) avec des contrôles architecturaux empêchant l'exfiltration de données vers des juridictions non approuvées.

Directives RBI : les entreprises de services financiers en Inde doivent se conformer au cadre de la RBI sur l'externalisation des services informatiques, qui comprend des exigences spécifiques en matière de localisation des données et d'accès aux audits de l'infrastructure du fournisseur cloud.

Sécurité cloud

Ce qu'Opsio observe : schémas opérationnels selon les modèles de déploiement

En assurant des opérations SOC et NOC 24/7 sur les environnements de nos clients couvrant tous les modèles de déploiement, plusieurs schémas émergent de manière constante :

Les environnements hybrides génèrent le plus d'incidents liés à des défaillances aux frontières réseau. L'interconnexion entre on-premises et cloud public (Direct Connect, ExpressRoute) constitue un point de défaillance unique que les équipes sous-surveillent. Lorsqu'elle se dégrade, les symptômes se manifestent comme un ralentissement applicatif plutôt que comme une panne réseau, entraînant un diagnostic malavisé.

L'attribution des coûts multi-cloud est le premier défi FinOps. Les organisations exécutant des charges de travail chez deux fournisseurs ou plus peinent systématiquement à répondre à des questions élémentaires comme « combien coûte cette application par mois ? » sans outillage dédié et discipline de tagging.

Les environnements de cloud privé dérivent le plus vite de leurs référentiels de sécurité. Les fournisseurs de cloud public mettent continuellement à jour les configurations par défaut (chiffrement au repos par défaut, versions TLS minimales, blocage de l'accès public). L'infrastructure de cloud privé conserve la configuration définie au moment du déploiement, sauf maintenance active.

Les organisations exclusivement en cloud public adoptent le plus rapidement les nouvelles capacités mais accumulent aussi le plus de ressources inutilisées. La facilité de provisionnement génère de la prolifération. Le rapport State of the Cloud de Flexera identifie systématiquement le gaspillage cloud comme une préoccupation majeure, et les environnements purement cloud public sont ceux où la pratique FinOps d'Opsio trouve le plus d'opportunités d'optimisation.

Questions fréquentes

Quels sont les 4 modèles de déploiement cloud ?

Les quatre modèles définis par le NIST SP 800-145 sont le cloud public (infrastructure partagée exploitée par un fournisseur comme AWS, Azure ou GCP), le cloud privé (infrastructure dédiée à une seule organisation), le cloud hybride (charges de travail réparties entre environnements publics et privés avec orchestration entre eux) et le cloud communautaire (infrastructure partagée entre organisations ayant des exigences communes, comme des administrations publiques). Le multi-cloud — utilisant plusieurs fournisseurs publics — est souvent considéré comme un cinquième modèle en pratique.

Quel modèle de déploiement cloud est le plus couramment utilisé ?

Le cloud hybride est le modèle le plus couramment adopté par les entreprises. Le rapport State of the Cloud de Flexera a systématiquement constaté qu'une majorité d'entreprises poursuivent une stratégie hybride, combinant des ressources on-premises ou de cloud privé avec un ou plusieurs clouds publics. Les déploiements exclusivement en cloud public sont plus fréquents chez les startups et les petites organisations dépourvues d'infrastructure historique nécessitant une intégration on-premises.

Que sont l'IaaS, le PaaS et le SaaS, et quel est leur rapport avec les modèles de déploiement ?

L'IaaS (Infrastructure as a Service), le PaaS (Platform as a Service) et le SaaS (Software as a Service) sont des modèles de service cloud — ils décrivent le niveau d'abstraction et ce que le fournisseur gère par rapport à ce que vous gérez. Les modèles de déploiement décrivent où et comment l'infrastructure est hébergée. Les deux sont indépendants : vous pouvez exécuter de l'IaaS sur un cloud privé, consommer du PaaS sur un cloud public, ou utiliser du SaaS délivré via une architecture hybride. Choisir un modèle de déploiement ne vous enferme pas dans un modèle de service spécifique.

AWS est-il un cloud public, privé ou hybride ?

AWS est avant tout un fournisseur de cloud public, mais il prend en charge tous les modèles de déploiement. AWS Outposts permet d'installer une infrastructure managée par AWS dans votre propre centre de données pour des déploiements privés ou hybrides. AWS GovCloud fournit des régions isolées pour les charges de travail du gouvernement américain. AWS Local Zones rapprochent le calcul des utilisateurs finaux. La plupart des organisations utilisent AWS comme composante cloud public d'une stratégie hybride ou multi-cloud plus large.

Le cloud hybride est-il moins cher que le cloud privé ?

Le coût dépend entièrement du profil de charge de travail. Le cloud hybride réduit généralement les coûts pour les charges variables, car vous pouvez basculer vers le cloud public au lieu de sur-dimensionner l'infrastructure privée pour absorber les pics de demande. Toutefois, le mode hybride introduit des coûts de réseau (frais d'interconnexion, charges de transfert de données), une complexité d'intégration et des surcoûts d'outillage supplémentaires. Pour des charges stables avec un taux d'utilisation systématiquement élevé, le cloud privé peut s'avérer plus rentable par unité de calcul. L'approche rigoureuse : modélisez le TCO pour vos charges de travail spécifiques sur les deux modèles avant de trancher.