1. Quatre modèles NIST #
Le critère : à qui appartient et qui utilise l'infrastructure ?
Panorama #
| Modèle | Description | Exemples | Avantages | Limites |
|---|---|---|---|---|
| Public | Infrastructure mutualisée détenue par un fournisseur | AWS, Azure, GCP, OVHcloud, Scaleway | Élasticité, pas d'investissement initial, paiement à l'usage | Moins de contrôle, conformité et souveraineté à étudier |
| Privé | Dédié à une seule organisation (sur site ou hébergé) | OpenStack, VMware, Nutanix, Proxmox | Contrôle total, isolation, conformité | Investissement, exploitation à votre charge |
| Communautaire | Partagé entre organisations aux besoins communs | Cloud santé HDS, cloud administrations | Coûts partagés, exigences communes | Gouvernance complexe |
| Hybride | Combinaison de privé et de public reliés entre eux | Données sensibles sur site + pics sur AWS | Flexibilité, migration progressive | Complexité réseau et sécurité |
2. Choisir son modèle #
Un arbre de décision pragmatique.
Critères #
- Sensibilité des données : données réglementées (santé, finance) → privé ou cloud qualifié (SecNumCloud, HDS).
- Variabilité de la charge : pics importants → public (élasticité) ; charge stable et prévisible → privé souvent moins cher.
- Latence et localisation : proximité des utilisateurs, edge computing.
- Compétences : exploiter un cloud privé demande une équipe plateforme.
- Réversibilité : éviter l'enfermement (lock-in) avec des standards ouverts (Kubernetes, Terraform, OpenTelemetry).
3. Relier le privé et le public (hybride) #
Connectivité et identité.
Les briques techniques #
# VPN site à site vers AWS (exemple Terraform)
resource "aws_vpn_gateway" "vgw" { vpc_id = aws_vpc.main.id }
resource "aws_customer_gateway" "onprem" {
bgp_asn = 65000
ip_address = "203.0.113.10"
type = "ipsec.1"
}
resource "aws_vpn_connection" "site2site" {
vpn_gateway_id = aws_vpn_gateway.vgw.id
customer_gateway_id = aws_customer_gateway.onprem.id
type = "ipsec.1"
static_routes_only = true
}4. Multi-cloud : promesses et pièges #
Utiliser plusieurs fournisseurs.
Mettre en pratique #
# Un même code Terraform, deux fournisseurs
terraform init
terraform workspace new aws && terraform apply -var provider=aws
terraform workspace new azure && terraform apply -var provider=azure
# Un même cluster Kubernetes, plusieurs contextes
kubectl config get-contexts
kubectl --context aks-prod get nodes
kubectl --context eks-prod get nodesErreur Courante : Le multi-cloud n'est pas une garantie de disponibilité : il multiplie les compétences, les coûts de transfert de données et la surface de sécurité. Justifiez-le par un besoin réel (réglementation, résilience, négociation).
Bonne Pratique : Concentrez-vous sur la portabilité (conteneurs, IaC, standards ouverts) plutôt que sur la duplication systématique de chaque service.
