Où vont réellement tourner vos applications cloud ? Cette question détermine votre modèle de déploiement : cloud public (infrastructure mutualisée chez Outscale, OVH, Scaleway ou les hyperscalers), cloud privé (infrastructure dédiée à votre organisation), cloud hybride (mix des deux), ou multi-cloud (plusieurs fournisseurs publics). Ce guide vous explique les 4 modèles de déploiement, leurs avantages/inconvénients, et comment choisir selon votre contexte.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Les 4 types de déploiement cloud et leurs différences
- Quel modèle choisir selon votre contexte (startup, grande entreprise, secteur réglementé)
- Les pièges courants de chaque modèle
- Les critères de décision concrets
Prérequis : Connaître les bases du cloud computing. Si besoin, commencez par Définition et promesses du cloud.
Les 4 modèles de déploiement
Section intitulée « Les 4 modèles de déploiement »Chaque modèle répond à des besoins différents. Le bon choix dépend de votre taille, secteur d’activité, exigences réglementaires et budget.
Cloud public : le plus courant
Section intitulée « Cloud public : le plus courant »Définition : Infrastructure mutualisée entre plusieurs clients, gérée par un fournisseur cloud (AWS, Azure, GCP, Outscale, OVH…).
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), mais votre trajet reste privé.
Le cloud public fonctionne pareil : Vos applications tournent sur des serveurs physiques qui hébergent aussi celles d’autres clients. Vos données restent strictement isolées grâce à la virtualisation.
Comment ça marche
Section intitulée « Comment ça marche »Quand vous créez une machine virtuelle (VM) chez un fournisseur cloud :
- Le fournisseur alloue de la capacité CPU/RAM/disque sur un serveur physique
- Cette capacité est isolée logiquement de celle des autres clients
- Vous accédez à “votre” serveur via Internet (SSH, RDP, console web)
- Vous payez à l’heure ou à la minute
C’est comme louer un appartement dans un immeuble : vous partagez la structure (murs, toit, plomberie), mais votre espace est privé et sécurisé.
Avantages et inconvénients
Section intitulée « Avantages et inconvénients »✅ Avantages
- Pas d’investissement initial : Pas de matériel à acheter
- Scalabilité illimitée : De 1 à 10 000 serveurs en minutes
- Maintenance gérée : Patches, mises à jour, pannes hardware prises en charge
- Innovation rapide : Accès immédiat aux nouvelles technologies (GPU, IA, Kubernetes…)
- Pay-as-you-go : Vous payez uniquement ce que vous consommez
❌ Inconvénients
- Moins de contrôle : Vous ne choisissez pas le matériel ni l’OS hyperviseur
- Localisation des données : Peuvent ê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 (ressources oubliées)
- 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é rapide, focus produit vs infra |
| Applications web | Élasticité pour gérer les pics de trafic |
| Environnements dev/test | Créer/détruire rapidement sans gaspiller du matériel |
| Projets agiles | Rapidité prime sur contrôle total de l’infrastructure |
Exemple concret
Section intitulée « Exemple concret »Une startup SaaS lance son MVP (Minimum Viable Product) :
- Jour 1 : 2 instances cloud (50 €/mois) pour 100 utilisateurs bêta
- Mois 6 : Le produit décolle → 50 instances autoscalées (2000 €/mois) pour 10 000 utilisateurs
- Mois 12 : Levée de fonds réussie → migration vers architecture conteneurs (Kubernetes) sans réarchitecturer 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.
Cloud privé : contrôle total
Section intitulée « Cloud privé : 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, entretien, où la garer)
- Toujours disponible quand vous en avez besoin
- Capacité limitée par ce que vous avez acheté
Comment ça marche
Section intitulée « Comment ça marche »Deux options pour un cloud privé :
Option 1 : On-premise (dans vos locaux) :
Vous achetez des serveurs, les installez dans votre datacenter (ou salle serveur), et déployez une plateforme cloud (OpenStack, VMware vSphere, Proxmox, Nutanix…).
Option 2 : Hosted private cloud (hébergé chez un tiers) :
Vous louez des serveurs dédiés chez un hébergeur (OVH Dedicated, Hetzner, Scaleway…), mais l’infrastructure reste exclusivement la vôtre (pas de multi-tenancy).
Avantages et inconvénients
Section intitulée « Avantages et inconvénients »✅ Avantages
- Contrôle total : Choix du matériel, de l’OS hyperviseur, des configurations
- Souveraineté des données : Vous savez exactement où elles sont stockées
- Conformité RGPD : Plus facile de prouver que les données ne quittent pas l’UE
- Performance prévisible : Pas de “noisy neighbors” (voisins bruyants) en multi-tenancy
- Personnalisation : Configurations exotiques possibles (hardware spécifique)
❌ Inconvénients
- Coût élevé : CAPEX initial 100 000 € à plusieurs millions
- Scalabilité limitée : Impossible d’ajouter 100 serveurs en 5 minutes
- Expertise nécessaire : Équipe dédiée pour gérer l’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 matériel, 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 :
- Exigences légales : Les données ne peuvent pas quitter le territoire français
- Certifications : PCI-DSS pour les cartes bancaires, certifications ANSSI
- Performance : Latence ultra-faible nécessaire pour les transactions
- Audit : Contrôle total pour les audits de sécurité réguliers
Solution : Cloud privé on-premise avec datacenters en France métropolitaine, géré par une équipe infrastructure dédiée de 50 personnes.
Cloud hybride : le compromis
Section intitulée « Cloud hybride : le compromis »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 :
- Trafic variable (pics promo, soldes)
- Besoin d’autoscaling
- Pas de données sensibles (pages statiques, CSS, JS)
→ Hébergé sur CDN + Object Storage (Scaleway, OVH, ou autre)
🔒 Cloud privé
Base de données clients :
- Données personnelles (RGPD)
- Conformité bancaire (PCI-DSS)
- Performance prévisible nécessaire
- Connexions légales avec banques partenaires
→ Hébergée on-premise
Communication : Les deux environnements sont reliés via un tunnel VPN sécurisé ou une interconnexion directe proposée par les fournisseurs cloud.
Quand un client passe commande sur le site (cloud public), la transaction est envoyée de manière sécurisée vers la base de données (cloud privé) pour validation et enregistrement.
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”, migrer service par service
- Optimisation coûts : Workloads stables sur privé (RI/dédié), 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 de données entre public/privé facturés (egress)
- Latence : Communication inter-cloud plus lente que 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 vers le cloud sans arrêt d’activité |
| Secteurs réglementés partiellement | Certaines données peuvent aller au cloud, d’autres non |
| Applications legacy coûteuses à refondre | Garder le legacy on-premise, développer le nouveau sur public |
| Workloads mixtes | Batch intensif sur privé, frontend scalable sur public |
Multi-cloud : plusieurs fournisseurs
Section intitulée « Multi-cloud : plusieurs fournisseurs »Définition : Utilisation simultanée de plusieurs fournisseurs de cloud public pour répartir les risques et optimiser les coûts par service.
Pourquoi le multi-cloud
Section intitulée « Pourquoi le multi-cloud »Trois raisons principales poussent les entreprises vers le multi-cloud :
- Éviter le vendor lock-in : Ne pas dépendre à 100% d’un seul fournisseur
- Meilleur prix par service : Choisir le moins cher pour chaque besoin (stockage AWS S3, Kubernetes GCP GKE, AD Azure…)
- Résilience géographique : Si AWS tombe en panne (rare mais possible), basculer sur Azure
Exemple d’architecture multi-cloud
Section intitulée « Exemple d’architecture multi-cloud »Une entreprise européenne peut choisir :
| Service | Fournisseur | Raison |
|---|---|---|
| Stockage objet | Scaleway Object Storage | Tarif compétitif, datacenter en France |
| Kubernetes | OVHcloud Managed Kubernetes | Bon rapport qualité/prix, support en français |
| VM compute | Outscale | Certification SecNumCloud, souveraineté |
| Backup | Infomaniak | Hébergé 100% en Suisse, RGPD-compliant |
Chaque service tourne chez le fournisseur adapté au besoin (prix, certification, localisation).
Chaque service tourne chez le fournisseur “best-in-class” pour ce domaine.
Avantages et inconvénients
Section intitulée « Avantages et inconvénients »✅ Avantages
- Pas de vendor lock-in : Liberté de migrer si un fournisseur devient trop cher
- Meilleur prix global : Optimisation service par service
- Résilience maximale : Basculement automatique si un cloud tombe
- Respect souveraineté : Données UE sur cloud européen, données US sur cloud US
❌ 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…)
- 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 | Rachats d’entreprises déjà sur un cloud différent |
Tableau comparatif
Section intitulée « Tableau comparatif »| Critère | Cloud Public | Cloud Privé | Cloud Hybride | Multi-cloud |
|---|---|---|---|---|
| CAPEX initial | 0 € | 100 k€ à millions | Moyen | 0 € |
| OPEX mensuel | Variable | Fixe + maintenance | Mixte | Variable |
| Scalabilité | Illimitée | Limitée par matériel | Mixte | Illimitée |
| Complexité | Faible | Moyenne | Élevée | Maximale |
| Contrôle données | Faible | Total | Partiel | Faible |
| Vendor lock-in | Élevé | Aucun | Moyen | Faible |
| Compétences requises | 1 cloud | Infra privée | 2 clouds + réseau | 3+ clouds |
| Délai provisioning | Secondes | Semaines/mois | Mixte | Secondes |
Critères de décision
Section intitulée « Critères de décision »Voici comment choisir selon votre contexte :
Vous êtes une startup ou PME
Section intitulée « Vous êtes une startup ou PME »→ Cloud public (Outscale, Scaleway, OVH, ou hyperscalers internationaux)
Raisons :
- Pas de capital initial
- Scalabilité immédiate
- Focus sur le produit vs infrastructure
Vous êtes dans un secteur réglementé
Section intitulée « Vous êtes dans un secteur réglementé »→ Cloud privé ou hybride
Raisons :
- Contraintes légales sur localisation des données
- Audits de sécurité stricts
- Certifications spécifiques (HDS, SecNumCloud, PCI-DSS)
Exemple : Banque → cloud privé on-premise pour données clients, cloud public pour site vitrine
Vous avez des applications legacy
Section intitulée « Vous avez des applications legacy »→ Cloud hybride
Raisons :
- Migration progressive sans réarchitecture complète
- Coût de refonte trop élevé à court terme
- Nouvelles apps sur public, legacy sur privé
Vous êtes une multinationale cloud-native
Section intitulée « Vous êtes une multinationale cloud-native »→ Multi-cloud (si équipes matures)
Raisons :
- Résilience inter-cloud critique
- Optimisation coûts service par service
- Équipes avec expertise multi-cloud existante
Pièges courants
Section intitulée « Pièges courants »Piège #1 : “On-premise = cloud privé”
Section intitulée « Piège #1 : “On-premise = cloud privé” »❌ Faux : Avoir des serveurs dans vos locaux ne fait pas un cloud privé.
✅ Vrai cloud privé : API self-service, autoscaling, orchestration automatisée
Piège #2 : “Multi-cloud par défaut”
Section intitulée « Piège #2 : “Multi-cloud par défaut” »❌ Faux : “On va prendre AWS ET Azure pour éviter le lock-in” sans avoir l’expertise
✅ Approche saine : Maîtriser un cloud d’abord, ajouter un second uniquement si besoin objectif
Piège #3 : “Cloud public = moins cher”
Section intitulée « Piège #3 : “Cloud public = moins cher” »❌ Faux : Sans gouvernance, le cloud public peut coûter plus cher que l’on-premise
✅ Réalité : Pay-as-you-go + ressources oubliées + sur-dimensionnement = facture surprise
Piège #4 : “Hybride = meilleur des deux mondes”
Section intitulée « Piège #4 : “Hybride = meilleur des deux mondes” »❌ Faux : Hybride = complexité des deux mondes si mal géré
✅ Réalité : N’allez hybride que si contrainte réelle, sinon choisissez public ou privé
À retenir
Section intitulée « À retenir »Le choix du modèle de déploiement cloud dépend de votre contexte :
- Cloud public : Default choice pour 80% des cas (startups, apps web, dev/test)
- Cloud privé : Secteurs réglementés, données ultra-sensibles, expertise interne
- Cloud hybride : Migration progressive, contraintes partielles
- Multi-cloud : Grandes entreprises matures, résilience critique
Règle d’or : Commencez simple (mono-cloud public si possible), complexifiez uniquement si contrainte objective.
Prochaines étapes
Section intitulée « Prochaines étapes »Définition et promesses du cloud
Comprenez les 5 caractéristiques fondamentales du cloud computing
Modèles de service IaaS/PaaS/SaaS
Découvrez les niveaux de service cloud et leurs responsabilités
Régions et zones de disponibilité
Apprenez à choisir où déployer géographiquement vos applications
Résilience et haute disponibilité
Concevez des architectures cloud tolérantes aux pannes