Le cloud — IaaS, PaaS, SaaS, modèles de déploiement, régions et zones

Objectif

Comprendre ce qu'on loue réellement quand on « passe au cloud », savoir ranger n'importe quel service dans la bonne case (IaaS, PaaS, SaaS ; public, privé, hybride) et choisir une région et des zones adaptées à des utilisateurs au Maroc.

L'essentiel

• Le cloud, c'est de l'informatique louée à la demande : serveurs, disques, réseaux, bases de données, payés à l'usage et créés en quelques minutes par une console, une API ou une ligne de commande.
• Trois modèles de service : IaaS (on loue l'infrastructure), PaaS (on loue une plateforme pour déposer son code), SaaS (on loue un logiciel prêt à l'emploi).
• Trois modèles de déploiement : public (partagé, chez un fournisseur), privé (réservé à une seule organisation), hybride (les deux reliés).
• Les fournisseurs découpent le monde en régions (une zone géographique) et chaque région en zones de disponibilité (des centres de données séparés).
• Choisir sa région, c'est arbitrer entre latence, prix, services disponibles et règles sur les données.

1. Avant le cloud : le serveur dans le placard

Imaginez une startup de livraison à Casablanca en 2012. Pour lancer son application, elle doit :

1. acheter deux serveurs (plusieurs dizaines de milliers de dirhams) ;
2. attendre la livraison, trouver une salle climatisée, un onduleur, une connexion fiable ;
3. installer le système, les mises à jour, la sauvegarde ;
4. prévoir large : si le ramadan double les commandes, les serveurs doivent tenir… et le reste de l'année ils dorment à 10 %.

Avec le cloud, la même startup ouvre un compte, choisit une région et crée deux machines virtuelles en dix minutes. Elle paie à l'heure ou à la seconde. Si le trafic double, elle ajoute des machines, puis les supprime quand le pic est passé.

Les cinq caractéristiques qu'on retrouve chez tous les fournisseurs :

CAPEX contre OPEX

• CAPEX (dépense d'investissement) : on achète le matériel, on l'amortit sur plusieurs années.
• OPEX (dépense de fonctionnement) : on paie un loyer mensuel selon la consommation.

Le cloud transforme une grosse dépense initiale en facture mensuelle. Ce n'est pas automatiquement moins cher : un serveur allumé 24 h/24 pendant cinq ans peut revenir plus cher en location qu'à l'achat. L'intérêt vient surtout de la souplesse et de la vitesse.

2. Les trois modèles de service

La meilleure façon de les comprendre : regarder qui gère quoi.

IaaS — Infrastructure as a Service

Vous louez des machines virtuelles, des disques et des réseaux. Vous installez le système, les paquets, les correctifs : c'est presque comme un serveur physique, sans le matériel.

Exemples : Amazon EC2, Azure Virtual Machines, Google Compute Engine, mais aussi les VPS d'hébergeurs comme OVHcloud ou Contabo.

# Créer une machine virtuelle Ubuntu en une commande (Azure CLI, à titre d'exemple)
az vm create --resource-group rg-boutique --name vm-web-01 \
  --image Ubuntu2404 --size Standard_B2s --admin-username azureuser --generate-ssh-keys

# L'équivalent chez Google Cloud
gcloud compute instances create vm-web-01 --zone=europe-southwest1-a \
  --machine-type=e2-small --image-family=ubuntu-2404-lts-amd64 --image-project=ubuntu-os-cloud

PaaS — Platform as a Service

Vous déposez votre code (ou une image de conteneur) ; la plateforme fournit le système, l'environnement d'exécution, la mise à l'échelle et souvent le certificat HTTPS.

Exemples : Azure App Service, Google App Engine, AWS Elastic Beanstalk, Heroku ; les bases de données managées (Amazon RDS, Azure SQL Database, Cloud SQL) sont aussi du PaaS : vous ne touchez jamais au système de la machine.

SaaS — Software as a Service

Vous utilisez un logiciel fini par le navigateur : messagerie (Gmail, Outlook), CRM, logiciel de paie, visioconférence, caisse enregistreuse en ligne. Vous gérez vos utilisateurs et vos données, rien d'autre.

Et les autres « aaS » ?

• CaaS (Containers as a Service) : on fournit une image de conteneur, la plateforme la fait tourner (Cloud Run, Azure Container Apps, AWS Fargate).
• FaaS (Functions as a Service) : on fournit une fonction, exécutée à chaque événement (AWS Lambda, Azure Functions, Cloud Run functions). C'est le cœur du serverless, vu en leçon 1.2.

Choisir le bon modèle : trois exemples marocains

Règle simple : plus on monte (IaaS → PaaS → SaaS), moins on administre, mais moins on contrôle.

3. Les modèles de déploiement

Cloud public

Le matériel appartient au fournisseur et sert à des milliers de clients isolés logiquement. On paie à l'usage. C'est ce qu'on appelle « le cloud » au quotidien : AWS, Microsoft Azure, Google Cloud, Oracle Cloud, Alibaba Cloud, OVHcloud…

Cloud privé

Une infrastructure dédiée à une seule organisation, avec les mêmes principes (libre-service, API, élasticité) : par exemple une banque qui exploite OpenStack ou VMware dans son propre centre de données, ou des serveurs dédiés chez un hébergeur local. Plus de contrôle, mais il faut acheter et administrer la capacité.

Cloud hybride

Un système d'information qui combine un environnement privé (ou sur site) et un cloud public, reliés par un VPN ou une liaison dédiée. Cas typique : les données sensibles restent dans les murs, les applications web ou les calculs ponctuels vont dans le cloud public.

Multicloud

Utiliser plusieurs fournisseurs publics (par exemple la messagerie chez l'un, l'hébergement chez l'autre). Ce n'est pas la même chose que l'hybride : on peut être multicloud sans rien héberger chez soi.

4. Les grands fournisseurs

Les concepts de ce cours sont les mêmes partout : seuls les noms changent. Un tableau de correspondance vous suivra dans les leçons suivantes.

5. Régions et zones de disponibilité

La région

Une région est un ensemble de centres de données dans une même zone géographique (une ville ou une province). Chaque région a un code :

À la date de rédaction, les trois grands fournisseurs n'ont pas de région ouverte au Maroc ; les régions de la péninsule Ibérique et de France sont les plus proches. Des annonces évoluent régulièrement : vérifiez toujours la liste officielle de votre fournisseur avant un projet.

La zone de disponibilité

Dans une région, une zone de disponibilité est un (ou plusieurs) centre(s) de données avec son alimentation, son refroidissement et son réseau indépendants. Les zones d'une même région sont séparées de plusieurs kilomètres mais reliées par un réseau très rapide (latence de l'ordre de la milliseconde).

Région eu-south-2 (Espagne)
├── zone eu-south-2a   ← serveur web 1
├── zone eu-south-2b   ← serveur web 2
└── zone eu-south-2c   ← base de données de secours

Idée clé : un incendie, une coupure électrique ou une panne réseau touche une zone. Si vos serveurs sont répartis sur plusieurs zones, votre service survit. Ce principe revient en leçon 2.3.

Comment choisir sa région

1. Latence : vos clients sont à Casablanca, Tanger ou Agadir ? Une région ibérique ou française répond en quelques dizaines de millisecondes. Mesurez :

   # Temps de réponse approximatif vers un point d'entrée régional (exemple)
   curl -o /dev/null -s -w '%{time_connect}\n' https://ec2.eu-south-2.amazonaws.com
   

2. Services disponibles : toutes les régions n'ont pas tous les services, ni toutes les tailles de machines.

3. Prix : il varie d'une région à l'autre (parfois de 10 à 30 %).

4. Règles sur les données : certaines données personnelles ou sensibles ne peuvent pas quitter le pays sans conditions. Au Maroc, la loi 09-08 encadre les transferts à l'étranger (leçon 3.1). C'est une question juridique à poser avant de choisir.

5. Reprise d'activité : prévoir une seconde région pour les copies de sauvegarde (par exemple Espagne + France).

Les points de présence (edge)

En plus des régions, les fournisseurs ont des centaines de points de présence dans les grandes villes : ils servent au CDN (mise en cache des images et pages web au plus près des internautes) et au DNS. Ils ne font pas tourner vos machines, mais accélèrent votre site.

6. Comment on pilote un cloud

Trois portes d'entrée, qui font la même chose :

# Lister les régions disponibles (une fois la CLI installée et connectée)
az account list-locations --output table
gcloud compute regions list
aws ec2 describe-regions --output table

Conseil de métier : faites vos premiers essais à la console pour comprendre, puis réécrivez-les en ligne de commande ou en Terraform pour reproduire. Une infrastructure créée uniquement à la souris est difficile à documenter et à recréer.

Pièges fréquents

• Croire que le cloud est toujours moins cher : un serveur allumé en permanence et mal dimensionné coûte vite plus cher qu'un serveur acheté. Le gain vient de l'élasticité et de l'arrêt de ce qui ne sert pas.
• Confondre région et zone : deux serveurs dans la même zone ne protègent pas d'une panne de centre de données.
• Choisir la région la moins chère sans regarder la loi : des données clients peuvent être soumises à des conditions de transfert hors du Maroc.
• Penser qu'en SaaS on n'est responsable de rien : vous restez responsable de vos comptes, de vos mots de passe et de vos données.

Lab

Le lab ne contient pas d'accès au cloud : vous allez écrire de petits fichiers « clé=valeur » qui fixent vos choix, comme dans un dossier d'architecture. Vous classerez trois services (IaaS, PaaS, SaaS), noterez deux codes de région, qualifierez le modèle de déploiement d'une clinique et répartirez trois serveurs sur trois zones.

cat /root/cloud/classement.txt
sort -u /root/cloud/zones.txt | wc -l    # doit afficher 3

Quiz

1. Une entreprise utilise Gmail pour sa messagerie. Quel modèle de service ?
2. Quelle est la différence entre une région et une zone de disponibilité ?
3. Un hôpital garde ses dossiers médicaux dans son centre de données et utilise un cloud public pour son site et ses calculs statistiques. Quel modèle de déploiement ?
4. En IaaS, qui applique les correctifs de sécurité du système d'exploitation ?
5. Citez trois critères pour choisir une région.

Sources de référence : Microsoft Learn et documentation Google Cloud (CC BY 4.0). Texte original MasterLinux.