IaaS, PaaS, SaaS et les régions

Trois niveaux de service

Ces trois sigles répondent à une seule question : jusqu'où va le fournisseur, et où commence votre travail. IaaS (vous louez une machine nue et installez tout le reste vous-même), PaaS (vous louez une machine dont le système et l'environnement d'exécution sont déjà prêts, vous n'apportez que votre application) et SaaS (vous louez le logiciel fini, il suffit d'ouvrir un navigateur pour s'en servir). Du premier au troisième, vous perdez du contrôle et vous gagnez du temps.

• IaaS (Infrastructure as a Service) : le fournisseur gère le matériel, l'administrateur gère l'OS, les mises à jour, les applications. Exemple : une machine virtuelle EC2 (AWS) ou Azure VM.
• PaaS (Platform as a Service) : le fournisseur gère aussi l'OS et le runtime, l'administrateur ne gère que le code et la configuration. Exemple : Azure App Service, Google App Engine.
• SaaS (Software as a Service) : application complète prête à l'emploi, aucune gestion d'infrastructure. Exemple : Microsoft 365, Google Workspace.

Plus on monte dans la pile (IaaS → PaaS → SaaS), moins on a de contrôle, mais moins on a de responsabilité opérationnelle.

Régions et zones de disponibilité

Un fournisseur cloud opère des régions géographiques (ex. eu-west-3 = Paris chez AWS). Chaque région contient plusieurs zones de disponibilité (datacenters physiquement séparés au sein de la même région), pour répartir une charge et survivre à la panne d'un seul site.

flowchart TD
    Region[Région eu-west-3 - Paris] --> AZ1[Zone A]
    Region --> AZ2[Zone B]
    Region --> AZ3[Zone C]
    AZ1 --> VM1[VM 1]
    AZ2 --> VM2[VM 2]

Pourquoi choisir sa région

• Latence : plus proche des utilisateurs = temps de réponse plus rapide.
• Conformité réglementaire : le RGPD impose souvent que les données de citoyens européens restent en Europe.
• Coût : les tarifs varient significativement d'une région à l'autre pour le même service.

Cas concret

Une PME française héberge son application sur une seule VM dans une seule zone de disponibilité. La zone subit une panne électrique : l'application est totalement indisponible pendant plusieurs heures. Une architecture multi-zones (au moins 2 VMs réparties sur 2 zones, derrière un load balancer) aurait absorbé la panne sans interruption visible.

Erreurs fréquentes

• Choisir une région uniquement sur le prix, sans considérer la latence pour les utilisateurs réels ni les obligations RGPD.
• Déployer sur une seule zone de disponibilité en pensant que "le cloud ne tombe jamais" : les pannes de datacenter existent bel et bien.
• Confondre PaaS et SaaS : PaaS nécessite toujours de déployer son propre code, SaaS non.

À retenir

• IaaS = contrôle maximal, SaaS = zéro gestion d'infrastructure, PaaS entre les deux.
• Une région contient plusieurs zones de disponibilité physiquement séparées.
• Répartir sur plusieurs zones protège contre la panne d'un seul datacenter.

Mini-exercice

Une entreprise doit stocker des données de clients européens en conformité RGPD. Quel critère de choix de région est ici non négociable ?

Réponse : la localisation géographique de la région (en Europe), indépendamment du prix ou de la latence, pour respecter les obligations de résidence des données.