Table des matières :
- Vous pensiez que le choix était évident ? Spoiler : non.
- Cloud public, privé, hybride : définitions opérationnelles
- Matrice de décision : critères techniques et métiers
- Sécurité, compliance et souveraineté des données
- Gouvernance, observabilité et automatisation
- FinOps : quand la facture devient la vraie KPI
- Performance, latence et architecture réseau
- Cas d’usage : du e-commerce temps réel au ML sous NDA
- Méthodologie de migration et plan de rollback
- Faut-il encore parler de multi-cloud ?
- Le mot de la fin
Vous pensiez que le choix était évident ? Spoiler : non.
La question « cloud public ou privé ? » fait partie du top 10 des marronniers que l’on ressort aux conférences DevOps depuis plus de dix ans. Pourtant, en 2025, les enjeux ont radicalement changé : explosion des workloads IA, généralisation de Kubernetes, réglementations extraterritoriales (bonjour le Cloud Act américain !) et pression FinOps permanente. Résultat : ce qui ressemblait autrefois à une simple comparaison de TCO est devenu un véritable exercice d’architecture d’entreprise.
« 80 % des dépassements budgétaires proviennent d’une simple méconnaissance des modèles tarifaires » — FinOps Foundation, State of FinOps 2025
Pour ne rien arranger, la communication des hyperscalers brouille les cartes : AWS parle de « Dedicated Zones », Microsoft d’« Azure Stack HCI » et Google d’« Anthos ». Tout ceci sonne très hybride, très souverain, très magique — mais reste incompréhensible si l’on ne se plonge pas dans les SLA et les modèles de facturation à la ligne. Devinez quoi ? 80 % des dépassements budgétaires proviennent d’une simple méconnaissance de ces subtilités, comme le rappelle le « State of FinOps 2025 Report » publié par la Fondation FinOps.
À Caen, où 42 % des PME industrielles ont lancé un projet d’IA appliquée (CCI Normandie, 2024), le débat « public vs privé » n’est plus cantonné aux DSI : il arrive désormais sur la table du COMEX, chiffres carbone et cyber-résilience à l’appui.
Bref, choisir son modèle de cloud computing aujourd’hui nécessite plus qu’un comparatif de machines virtuelles. Il faut parler réseau, compliance, outillage IaC, DevSecOps, observabilité et culture d’entreprise. Allez, on démonte tout ça méthodiquement.
Cloud public, privé, hybride : définitions opérationnelles
On commence par clarifier la sémantique — promesse tenue, pas de blabla marketing. Le cloud public est un environnement mutualisé fourni par un tiers (AWS, Azure, GCP, mais aussi les régionaux de l’étape comme Scaleway ou OVHcloud). La facturation est à l’usage, le provisionnement quasi instantané et la responsabilité partagée (« shared responsibility model ») fait loi. Concrètement, on externalise l’infrastructure physique et une bonne partie du réseau, on garde la main sur l’OS et la couche applicative.
Le cloud privé, à l’inverse, repose sur une infrastructure dédiée à une seule entité. Il peut être on-premise (vos racks, votre clim’) ou hébergé chez un fournisseur spécialisé. Dans les deux cas, l’entreprise récupère la gouvernance complète : choix de l’hyperviseur, segmentation réseau, chiffrement disque, cycle de vie matériel. C’est souvent perçu comme plus sécurisé — en pratique c’est surtout plus exigeant à maintenir. Le lien avec votre SOC et vos politiques IAM devient critique.
Le cloud hybride mixe les deux mondes via une interconnexion (VPN IPSec, Direct Connect, Fabric Interconnect, selon le vocabulaire) avec latence contrôlée. L’objectif : orchestrer des workloads qui bougent selon des règles de coût, de performance ou de conformité. C’est l’option « best of both worlds », mais aussi « worst of both » si l’orchestration et la gouvernance échouent.
| Caractéristique | Cloud public | Cloud privé | Cloud hybride |
|---|---|---|---|
| CapEx / OpEx | 0 % CapEx / 100 % OpEx | 100 % CapEx / 0 % OpEx | Mix variable |
| Provisionnement | Minutes | Jours à semaines | Mix |
| SLA nominal | ≥ 99,99 % régionales | Dépend du data-center | Dépend de chaque composant |
| Conformité (HDS, PCI…) | Certifications fournisseur | À charge du client | Double lecture nécessaire |
| Élasticité | Quasi infinie | Limitée au hardware | Bursting possible si réseau dimensionné |
Matrice de décision : critères techniques et métiers
Premier critère, la criticité applicative. Un e-commerce B2C soumis à des pics Black Friday n’a pas la même élasticité qu’un ERP interne. Les hyperscalers déploient des capacités quasi infinies ; un cloud privé devra sur-allouer du hardware pour absorber le pic, sauf à faire du bursting vers le public. Traduction : si votre volumétrie est erratique, le public (ou l’hybride avec bursting) est plus rationnel.
Deuxième critère, la compliance. Les données de santé (HDS), bancaires (PCI-DSS) ou défense (SecNumCloud) sont encadrées par des normes qui restreignent parfois le recours au public pur. Les fournisseurs « souverains » comblent le gap, mais le coût grimpe. Avant d’acheter des racks, passez vos clauses contractuelles au peigne fin avec le RSSI ; c’est souvent là que la balance bascule. À Lyon, le CHU a ainsi maintenu son cluster d’imagerie en privé tout en basculant le front web en public pour gagner 30 % de disponibilité (retour d’expérience publié au JFR 2024).
Troisième critère, la culture DevOps. Automatiser une infrastructure privée sans Infrastructure as Code, c’est un aller simple pour le Shadow IT. Terraform + GitOps + CI/CD sont plus faciles à mettre en œuvre sur les grosses API cloud public. Si vous visez la maturité décrite dans notre article « Infrastructure as Code : optimiser la gestion des infrastructures informatiques », anticipez l’effort d’outillage sur un data-center maison.
| Critère décisif | Public | Privé | Hybride |
|---|---|---|---|
| Pics de charge fréquents | ✅ | ⚠️ | ✅ |
| Données ultra-sensibles | ⚠️ | ✅ | ✅ |
| Équipe FinOps dédiée | ✅ | ⚠️ | ✅ |
| Time-to-Market < 2 sem. | ✅ | ⚠️ | ✅ |
| Ecosystème DevOps/API | ✅ | ⚠️ | ✅ |
Sécurité, compliance et souveraineté des données
On l’a dit : « On-prem, my rules ». Mais aussi « On-prem, my incidents ». Chez les hyperscalers, la pile matérielle est patchée, testée, redondée. Dans un cloud privé, c’est votre équipe qui gère le microcode Intel ou le firmware de la baie SAN. L’argument sécurité ne tient donc que si vous investissez réellement dans un SOC 24/7 et une démarche DevSecOps, à l’image de ce que nous décrivons dans « DevSecOps-as-a-service : intégrer la sécurité au pipeline CI/CD ».
« La localisation physique d’un serveur n’est qu’un indice ; c’est la juridiction applicable qui prime » — CNIL, 2023
Sur la souveraineté, c’est la fameuse trilogie : localisation, juridiction, accès. Une VM hébergée à Francfort reste soumise au Cloud Act américain si elle tourne chez AWS. Si votre DPO perd déjà ses cheveux, le cloud privé opéré dans un data-center local est une option crédible. Mais n’oubliez pas la sauvegarde hors site ; une copie S3 à Dublin pulvérise votre argumentaire souverain. (Voir le guide CNIL : https://www.cnil.fr/fr/solutions/cloud-computing).
Enfin, parlons segmentation réseau. En public, on isole via des VPC et des Security Groups. En privé, c’est du VLAN, du VXLAN, parfois de la micro-segmentation via NSX. Les attaques latérales (East-West) sont statistiquement plus fréquentes en privé mal segmenté, comme l’a montré l’étude « Private Cloud Breach Analysis 2024 » de Palo Alto Networks.
Gouvernance, observabilité et automatisation
Une architecture hybride sans gouvernance, c’est un sapin de Noël câblé en 380 V : beau, mais dangereux. Il vous faut un plan de taggage (qui paie quoi ?), un RBAC fédéré et une console de monitoring unifiée. Prometheus, Grafana, OpenTelemetry et Loki fonctionnent aussi bien sur bare-metal que sur AWS — à condition de standardiser vos labels.
Checklist express « gouvernance hybride » :
- Identité : SSO + MFA + RBAC croisé (Azure AD / LDAP / Keycloak)
- Tags minimum : CostCenter, Environment, Owner, Sensitivity
- Observabilité : métriques + logs + traces exportés via OTLP
- Sécurité : scans d’images (Trivy) + CSPM (Cloud Security Posture Management)
- Revue trimestrielle des rôles et « least privilege »
Côté automatisation, le duo Terraform + Ansible reste un classique. Les modules provider doivent cependant pointer vers vos endpoints privés (vCenter, Proxmox) et publics (AWS, Azure). Le moindre oubli génère du drift, puis du chaos. Pensez à la fonction driftctl ou à Atlantis pour valider vos MR.
Pour la visibilité budgétaire, taguez vos ressources avec les mêmes clefs CostCenter, Environment et Owner dans les deux mondes. Le FinOps Foundation Framework rappelle qu’un tag manquant coûte en moyenne 17 % de temps d’analyse supplémentaire par mois. Vous voilà prévenus.
FinOps : quand la facture devient la vraie KPI
En public, le compteur tourne chaque seconde, et chaque service managé (Aurora, BigQuery, Cosmos DB…) ajoute sa propre ligne opaque au CSV. D’où la montée en puissance des plateformes FinOps (CloudHealth, Apptio, Finout) et de l’expertise interne dédiée. Selon Gartner, 65 % des entreprises de plus de 1 000 employés disposent désormais d’un « Cloud Economist ».
| Indicateur clé | Cloud public (OPEX) | Cloud privé (CAPEX) |
|---|---|---|
| Base de calcul | $/Heure ‑ $/Go | Amortissement 3-5 ans |
| KPI conseillé | COGS / Revenue | TCO sur 7 ans |
| Volatilité | Haute | Faible |
| Effet cash-flow | Retardé (mensuel) | Immédiat (invest.) |
En cloud privé, le modèle CAPEX redevient roi : achat de serveurs, amortissement sur cinq ans, contrats de maintenance. Sur le papier, la dépense globale peut paraître plus faible, surtout si la densité VM dépasse 70 %. Mais le cash-flow, lui, souffre. Notre conseil : modélisez deux indicateurs : le Net Present Cost (NPC) pour le privé, le Total Contracted Spend (TCS) pour le public. Comparez sur sept ans, pas trois.
Cerise sur le gâteau : le coût carbone. Un hyperscaler alimenté à 80 % d’énergie renouvelable peut réduire votre scope 2, mais vous expose au « Greenwashing Gap ». Les data-centers on-prem mal optimisés en PUE explosent votre bilan RSE. À méditer pendant le stand-up.
Performance, latence et architecture réseau
Le cloud public brille par son backbone. Une requête inter-zones AWS eu-central-1 ⇄ eu-west-3 transite sur un réseau 100 Gbps privé, souvent plus rapide que votre MPLS. En cloud privé, la latence dépend de votre opérateur et de l’ingénierie réseau interne. Les millisecondes coûtent cher lorsque vos micro-services chattent en gRPC.
| Test de ping (ms) | Paris ⇄ AWS eu-west-3 | Paris ⇄ DC privé Île-de-France | Rouen ⇄ AWS eu-central-1 |
|---|---|---|---|
| Moyenne observée | 5-7 ms | 2-3 ms (LAN to Metro) | 11-13 ms |
Pour les applications temps réel (jeu, IoT, trading), l’edge public (CloudFront, Cloudflare) apporte un gain décisif. Mais vous pouvez hybrider : front stateless en edge, back stateful en privé. Les L3 Gateway Transit de Cisco ou les SD-WAN de Fortinet simplifient ce schéma, à condition de maîtriser BGP.
N’oubliez pas la bande passante sortante : 0,09 €/Go sur AWS, gratuite on-prem. Les flux egress vers un CDN peuvent retourner le ROI en un trimestre. Comparez toujours le coût au Go avec celui d’un transit IP local.
Cas d’usage : du e-commerce temps réel au ML sous NDA
E-commerce haute saisonnalité : un site PrestaShop qui explose à Noël. Front en cloud public auto-scalé, bases MySQL répliquées sur un cluster MariaDB privé pour compliance RGPD. C’est littéralement le scénario décrit dans « Cloud computing : moteur d’innovation pour la transformation des PME ».
Machine Learning confidentiel : entraînement de modèles LLaMA 3 sur des données sous NDA. GPU on-prem (CUDA 12, PCIe 5) pour contenir les datas, déploiement en inference server sur Amazon SageMaker. Lien dédié 10 Gbps, chiffrement TLS 1.3 + IPsec. Les modèles restent sur site, la scalabilité inference part dans les nuages.
SaaS B2B multi-tenant : multi-cloud actif/actif pour SLA 99,99 % et latence < 50 ms. Load balancers multi-régions, stockage objet répliqué + erasure coding. Ici le « Hébergement d’infrastructures THD (Très Haute Disponibilité) » proposé par notre division hébergeur >>> THD est pertinent.
Méthodologie de migration et plan de rollback
Phase 1 : audit applicatif. On scanne les dépendances avec un outil type Cloudamize ou CAST Highlight. Puis on classifie selon les « 6 R » (Rehost, Replatform, Refactor…). Étonnamment, 45 % des workloads finissent en « Retire », dixit AWS Migration Report 2024.
Phase 2 : design de l’architecture cible dans un outil de cartographie (Lucidchart, Miro, ou l’ancestral Visio pour les plus téméraires). On inclut : IP scheme, CIDR, IAM roles, stratégie de backup.
Phase 3 : exécution pilotée par IaC, blue/green ou canary. Pas de big-bang. On garde un plan de rollback x-hours. Exemple : si la transco ERP échoue, on rebasculera le DNS vers l’IP on-prem grâce à un TTL de 60 s. Pensez au « A/B switch » décrit dans la page DevOps : création et optimisation d’infrastructures d’hébergement.
terraform {
required_providers {
aws = { source = "hashicorp/aws" }
vsphere = { source = "hashicorp/vsphere" }
}
}
provider "aws" {
region = "eu-west-3" # Paris
}
provider "vsphere" {
user = var.vsphere_user
password = var.vsphere_password
vsphere_server = "vcenter.rouen.local"
allow_unverified_ssl = true
}
Exemple minimaliste : un même plan Terraform pilote la création d’un VPC AWS et d’un réseau vSphere privé, garantissant un rollback unifié.
Faut-il encore parler de multi-cloud ?
Le multi-cloud, c’est l’hybride en stéroïdes : plusieurs clouds publics + éventuellement du privé. L’argument majeur : éviter le vendor lock-in. Selon le « Flexera State of the Cloud 2025 », 89 % des grandes entreprises utilisent au moins deux clouds. Spoiler : la moitié d’entre elles reconnaissent « sous-exploiter » un des fournisseurs.
Techniquement, les solutions de plateforme (Crossplane, Terraform Cloud, Anthos, Azure Arc) simplifient l’orchestration, mais la couche Data Gravity reste le vrai frein. Déplacer 100 To d’analytics BigQuery vers Snowflake n’est pas qu’une question de scripts, c’est une question de bande passante et de gouvernance.
Bref, le multi-cloud n’est pas une fin en soi. Il doit répondre à un besoin métier précis (résilience, négociation tarifaire, couverture géo) ou rester un fantasme PowerPoint.
Le mot de la fin
Vous l’aurez compris : choisir entre cloud public, privé ou hybride n’est pas un match à deux variables. C’est un arbitrage complexe entre coûts, risques, performances et culture d’entreprise. L’option « hybride » est séduisante, mais exigeante en gouvernance. Le privé rassure le CISO, mais coûte un bras au DAF. Le public séduit le CTO, mais angoisse le DPO.
Checklist finale avant signature :
- Mapping des données réglementées (RGPD, PCI, HDS).
- KPI FinOps alignés sur la DSI et la Direction financière.
- Automatisation IaC + GitOps éprouvée dans un bac à sable.
- Monitoring full-stack (APM + logs + traces) avec alertes unifiées.
- Plan de continuité et de reprise testé (failover + restore + chaos engineering).
- Contrat d’infogérance ou SOC 24/7 si cloud privé.
- DRP croisé sur au moins deux régions physiques distinctes.
Besoin d’un œil externe ? Parlons-en, vous pouvez même prendre RDV et passer nous voir, on offre le café.
On pourra parler cybersécurité, hébergement et devOPs – ou de choses intéressantes si vous préférez !
