Fondements du Cloud Computing

Abdelfattah TOULAOUI

1
INTRODUCTION – POURQUOI LE
CLOUD COMPUTING EST
IMPORTANT ?
 Contexte général
Le Cloud Computing est un pilier fondamental de l’informatique moderne.
➔ Utilisé par :
◆ Les particuliers
◆ Les entreprises
◆ Les administrations

➔ Présent dans la majorité des services numériques actuels

➔ Transformation profonde de la manière :

◆ De développer des applications
◆ De stocker et traiter les données
◆ De gérer les infrastructures informatiques
 Problèmes de l’informatique traditionnelle
Avant le cloud, les organisations devaient :
➔ Acheter et maintenir leur propre matériel
➔ Gérer :
◆ Les serveurs
◆ Le stockage
◆ Les réseaux
➔ Anticiper la charge maximale (sur-dimensionnement)
➔ Assumer :
◆ Des coûts élevés
◆ Une maintenance complexe
◆ Des interruptions de service
Manque de flexibilité et de scalabilité
 Qu’apporte le Cloud Computing ?
Le cloud propose une nouvelle approche :
➔ Accès à des ressources informatiques à la demande

➔ Mutualisation des ressources

➔ Facturation à l’usage (pay-as-you-go)

➔ Déploiement rapide des services

➔ Réduction des coûts initiaux

➡ L’infrastructure devient un service, et non un investissement lourd.
 Exemples concrets du quotidien
Le cloud est déjà dans notre vie quotidienne :
➔ Messagerie : Gmail, Outlook

➔ Stockage : Google Drive, OneDrive

➔ Streaming : Netflix, Spotify

➔ Réseaux sociaux

➔ Jeux en ligne

➔ Outils collaboratifs (documents partagés)

L’utilisateur consomme le service sans gérer l’infrastructure.
 Cloud vs Informatique traditionnelle

Informatique traditionnelle Cloud Computing

Infrastructure locale Infrastructure distante

Coûts fixes élevés Coûts variables

Scalabilité limitée Scalabilité dynamique

Déploiement lent Déploiement rapide

Maintenance interne Maintenance externalisée

 Pourquoi les entreprises adoptent le cloud ?
Principales motivations :
➔ Réduction des coûts opérationnels

➔ Adaptation rapide aux besoins du marché

➔ Haute disponibilité des services

➔ Accélération de l’innovation

➔ Accès mondial aux ressources

Le cloud devient un avantage stratégique.
ÉVOLUTION HISTORIQUE DES
MODÈLES DE CALCUL
 Les débuts : le calcul centralisé
Mainframe Computing (années 1950–1970)
➔ Ordinateur central unique très puissant
➔ Utilisé par :
◆ Gouvernements
◆ Banques
◆ Grandes institutions
➔ Accès via des terminaux passifs
➔ Ressources partagées entre plusieurs utilisateurs
Avantage :
➔ Centralisation du contrôle
Limites :
➔ Coût très élevé
➔ Faible accessibilité
➔ Forte dépendance au système central
 Le partage du temps (Time-Sharing)

➔ Apparition du time-sharing

➔ Plusieurs utilisateurs utilisent la même machine simultanément

➔ Le processeur alterne rapidement entre les utilisateurs

Concept clé :
➔ Partage équitable des ressources
Première idée de mutualisation, fondamentale
pour le cloud.
 Le modèle Client–Serveur
Années 1980–1990
➔ Séparation entre :
◆ Clients (PC, interfaces)
◆ Serveurs (données, traitements)
➔ Déploiement dans les réseaux locaux (LAN)
Avantages :
➔ Meilleure flexibilité
➔ Informatique distribuée
Limites :
➔ Scalabilité limitée
➔ Administration complexe
➔ Serveurs souvent sous-utilisés
 Clients lourds vs clients légers

➔ Client lourd :
◆ Traitement local
◆ Dépendance au matériel

➔ Client léger :
◆ Traitement côté serveur
◆ Interface simple
Le cloud adoptera massivement le client léger (navigateurs
web).
 Le calcul distribué
Années 1990–2000
➔ Répartition des calculs sur plusieurs machines

➔ Machines interconnectées par un réseau

➔ Objectifs :
◆ Performance
◆ Disponibilité
◆ Tolérance aux pannes
Exemples :
➔ Calcul scientifique

➔ Traitement de données massives

 Le Cluster Computing
➔ Groupe de machines homogènes
➔ Fonctionnent comme un seul système
➔ Utilisé pour :
◆ Calcul haute performance (HPC)
◆ Serveurs web
Avantages :
➔ Haute performance
➔ Redondance
Limites :
➔ Infrastructure rigide
➔ Gestion complexe
➔ Scalabilité limitée dynamiquement
 Le Grid Computing

➔ Ressources distribuées géographiquement

➔ Machines hétérogènes

➔ Partage entre plusieurs organisations

Objectif :
➔ Exploiter la puissance inutilisée
Différence clé avec le cloud :
➔ Pas orienté service

➔ Pas de facturation à l’usage

➔ Gestion plus complexe

 L’émergence de la virtualisation
Années 2000
➔ Abstraction du matériel physique

➔ Création de machines virtuelles

➔ Utilisation de hyperviseurs
Apports majeurs :
➔ Meilleure utilisation des ressources

➔ Isolation des environnements

➔ Déploiement plus rapide

Fondation technique du cloud computing
 Les centres de données à grande échelle

➔ Construction de data centers massifs

➔ Automatisation de :
◆ L’allocation des ressources
◆ La supervision
◆ La maintenance

➔ Mutualisation à très grande échelle

Passage d’une logique locale à une logique
globale.
 Les débuts du Cloud Computing : contexte et problème
d’Amazon
Pourquoi le Cloud est né chez Amazon
➔ À la fin des années 1990 – début 2000, Amazon était en pleine croissance rapide en tant que plateforme
e-commerce.
➔ L’entreprise faisait face à un problème d’over-provisioning : pour éviter les pannes lors des pics de trafic,
elle devait acheter trop de serveurs et faire tourner des fermes de machines sous-utilisées la plupart du temps.
➔ Résultat : coûts énormes, complexité opérationnelle, et duplication de l’effort à chaque nouveau projet ou
service.
➔ Pour résoudre cela, des ingénieurs (dont Benjamin Black et Chris Pinkham) ont conçu une architecture
interne de services web standardisés, modulaires et automatisés pour partager et réutiliser l’infrastructure.
Cette réflexion a posé les bases d’un produit externe.
L’idée centrale : ne plus bâtir des piles d’infrastructure spécifiques à chaque service, mais proposer des
primitives réutilisables à la demande.
 AWS : naissance, standardisation et succès commercial
De la résolution interne à un produit cloud commercial
➔ Amazon a commencé à exposer certaines de ces briques techniques comme API dès 2002, mais c’est en mars
2006 que la division est officialisée sous le nom Amazon Web Services (AWS), regroupant S3 (stockage),
SQS (messagerie) et EC2 (instances VM).
➔ Cette vision a transformé des problèmes internes en offre produit : infrastructure informatique à la demande,
scalable, élastique, mesurée et accessible via des API.
 Impact économique et position actuelle

➔ Aujourd’hui, AWS est l’une des activités les plus rentables et stratégiques d’Amazon, représentant une
part significative du chiffre d’affaires du groupe global. Par exemple, au quatrième trimestre 2025, AWS a
généré environ 35,6 milliards $ de revenus, en croissance de 24 %, malgré un contexte macro complexe.
➔ Avant même de considérer d’autres segments d’Amazon, la branche cloud constitue une machine à revenus
à part entière, entraînant une croissance soutenue et démontrant l’importance du cloud public dans l’
économie numérique moderne.
DÉFINITION ET CARACTÉRISTIQUES DU
CLOUD COMPUTING
 Objectifs de la section
À la fin de cette section, vous saurez :
➔ Donner une définition standardisée du cloud computing

➔ Expliquer les caractéristiques essentielles qui distinguent le cloud

➔ Identifier les rôles/acteurs d’un écosystème cloud

➔ Éviter les confusions fréquentes (hébergement ≠ cloud, etc.)

 Définition (standard NIST)
Le NIST (National Institute of Standards and Technology) propose une définition très utilisée dans l’industrie :
➔ Le cloud computing est un modèle permettant un accès réseau :
◆ ubiquitaire et pratique,
◆ à la demande,
◆ à un pool partagé de ressources configurables (réseau, serveurs, stockage, applications, services),
◆ rapidement provisionnées et libérées,
◆ avec un effort minimal de gestion ou interaction humaine avec le fournisseur.
Point clé : le cloud n’est pas “un serveur sur Internet”, c’est un modèle d’exploitation.
 Définition (standards ISO/IEC et ITU-T)
Les standards internationaux convergent sur une idée similaire :
➔ ISO/IEC (vocabulaire cloud) : paradigme permettant l’accès réseau à un pool scalable et élastique de
ressources partageables (physiques ou virtuelles) avec self-service à la demande.
➔ ITU-T Y.3500 : insiste aussi sur le pool scalable/élastique, le self-service, et une vision “paradigme” (cadre
global).
Convergence : pool partagé + élasticité + self-service + accès réseau.
 Ce que la définition implique (lecture “ingénieur”)
Si on reformule “façon ingénieur”, un système cloud doit permettre :
➔ Provisionner des ressources rapidement (VM, stockage, réseau, services managés)

➔ Les dimensionner (scale up/down, scale out/in)

➔ Les facturer/mesurer à l’usage

➔ Les fournir via des interfaces standardisées (console, API, IaC)

Le cloud est une combinaison de technologie + automatisation + modèle économique.
LES 5 CARACTÉRISTIQUES
ESSENTIELLES (NIST)
 Vue d’ensemble (NIST : 5 caractéristiques)
Le NIST dit explicitement que le “cloud model” est composé de :
➔ 5 caractéristiques essentielles

➔ des modèles de services et de déploiement (vus ensuite)

Les 5 caractéristiques :
1. Self-service à la demande

2. Accès réseau étendu

3. Mutualisation des ressources

4. Élasticité rapide

5. Service mesuré
 1) Self-service à la demande (On-demand self-service)
Le consommateur peut provisionner unilatéralement des capacités (ex : temps CPU, stockage) sans interaction
humaine avec le fournisseur.
Exemples pédagogiques :
➔ Créer une VM en 2 minutes via console/API

➔ Ajouter un bucket de stockage instantanément

➔ Déployer une base managée en quelques clics

C’est l’opposé d’un processus “ticket + attente + intervention admin”.
 2) Accès réseau étendu (Broad network access)
Les ressources sont disponibles sur le réseau via des mécanismes standard :
➔ Accès depuis divers clients (PC, mobile, thin client)

➔ API/HTTP, consoles web, SDK, etc.

Le cloud est conçu pour la consommation réseau, pas pour un usage local isolé.
 3) Mutualisation des ressources (Resource pooling)
Les ressources du fournisseur sont mutualisées pour servir plusieurs clients (multi-tenant) :
➔ Allocation/désallocation dynamique selon la demande

➔ Localisation souvent abstraite (ex : région, zone)

C’est l’une des raisons majeures des gains économiques du cloud.
 4) Élasticité rapide (Rapid elasticity)
Capacité à augmenter/diminuer rapidement les ressources :
➔ Parfois automatiquement (autoscaling)

➔ L’impression pour l’utilisateur : ressources “quasi infinies”

Exemples :
➔ Pic de trafic e-commerce → scale out

➔ Fin de pic → retour à la normale

 5) Service mesuré (Measured service)
Le système cloud mesure et optimise automatiquement l’usage :
➔ CPU, stockage, bande passante, requêtes, etc.

➔ Base du pay-as-you-go et de la gouvernance des coûts

À faire passer :
➔ La mesure sert à la facturation

➔ Mais aussi au contrôle (budgets, alertes, optimisation)

MODÈLES ET ACTEURS
 Les modèles de service et de déploiement (rappel
NIST)
Dans la définition NIST, le modèle cloud inclut aussi :
➔ 3 modèles de service (IaaS, PaaS, SaaS)

➔ 4 modèles de déploiement (public, privé, hybride, communautaire)

Ici, l’objectif est surtout de comprendre que :
➔ Les caractéristiques “cloud” sont indépendantes du fournisseur

➔ Elles structurent l’ensemble des offres

 Les acteurs/ rôles (NIST Cloud Reference Architecture)
Pour parler correctement de cloud, on distingue des acteurs (NIST RA) :
➔ Cloud Consumer : l’utilisateur/organisation cliente

➔ Cloud Provider : le fournisseur de services cloud

➔ Cloud Broker : intermédiaire/agrégateur (optionnel)

➔ Cloud Carrier : transport réseau (connectivité)

➔ Cloud Auditor : audit/contrôle/évaluation

Très utile pour introduire ensuite : contrats, SLA, conformité, sécurité.
ARCHITECTURE FONDAMENTALE
DU CLOUD
 Objectifs

➔ Comprendre comment un cloud est structuré (couches + plans)

➔ Relier les composants à des exigences réelles : scalabilité, disponibilité, sécurité, coût

➔ Lire une architecture cloud : régions/zones, VPC/VNet, compute, stockage, orchestration, observabilité

➔ Introduire les notions control plane vs data plane + shared responsibility

 Le cloud comme “système de systèmes”
Idée clé : le cloud est un empilement cohérent de :
➔ Infrastructure physique (data centers)

➔ Virtualisation & isolation (VM, réseaux/stockage virtualisés)

➔ Plateformes & services managés (DB, messaging, analytics…)

➔ Plan de management (API, IAM, policies, facturation, monitoring)

➔ Automatisation (IaC, autoscaling, déploiement continu)

Cette vision est compatible avec les référentiels d’architecture cloud (ex. rôles & fonctions dans les architectures
de référence).
 Plans : Data Plane vs Control/Management Plane
Data plane (plan de données) : là où passent les flux applicatifs
➔ Trafic utilisateur → load balancer → services → bases → stockage

➔ Performance/latence/HA se jouent ici

Control / management plane (plan de contrôle/gestion) : là où l’on administre
➔ API, console, IAM, policies, logs, métriques

➔ Déploiement, orchestration, scaling, configuration

Dans Kubernetes aussi, on parle explicitement de control plane et de workers/nœuds (analogie très utile).
 Vue “couches” (du bas vers le haut)

1. Data center (énergie, refroidissement, racks, liens réseau)

2. Compute / Storage / Network physiques

3. Virtualisation (hyperviseur, virtual networks, volumes)

4. Containers + orchestration (Kubernetes, autoscaling, self-healing)

5. Services managés (DBaaS, cache, queue, IAM, monitoring)

6. Applications (microservices, API, frontends)

Les architectures ISO/NIST décrivent justement des couches/fonctions et leurs relations.
 Régions, zones, et domaines de panne
Pour concevoir la résilience, on raisonne par :
➔ Région : zone géographique (latence, souveraineté, conformité)

➔ Zone de disponibilité (AZ) : site(s) distinct(s) dans une région (réduit le risque de panne corrélée)

➔ Domaines de panne : alimentation, réseau, rack, etc. (selon fournisseur)

Message pratique : on conçoit pour que la panne arrive, et le système continue.
 Edge computing et CDN (quand “la région” est trop
loin)
Cas d’usage : réduire la latence, économiser la bande passante, absorber des pics.
➔ CDN / edge servers : contenu (ou calcul) plus proche de l’utilisateur

➔ Edge computing : déplacer une partie du traitement au bord du réseau pour réduire latence/bande passante
Exemples :
➔ Cache des images/vidéos au plus proche

➔ Auth légère / routage / personnalisation

➔ Pré-traitement IoT local avant envoi cloud

 Réseau cloud : VPC/VNet et segmentation
Dans la pratique, tout commence par le réseau :
➔ Réseau privé virtuel (ex : VPC/VNet) avec sous-réseaux

➔ Routage, NAT, pare-feu, security groups/NSG

➔ Segmentation :
◆ Subnet public (load balancer / bastion)
◆ Subnet privé (apps / DB)

➔ Connexions hybrides : VPN / liens dédiés

Bon réflexe pédagogique : dessiner le réseau avant de choisir les services.
 Compute : VM, containers, serverless
VM (IaaS) :
➔ contrôle fin, compatibilité legacy

➔ gestion OS (patching, images, scaling)

Containers :
➔ packaging standard, densité, déploiements rapides

➔ nécessite orchestration (Kubernetes)

Serverless / FaaS :
➔ exécution à la demande, scaling automatique

➔ limites : cold start, contraintes runtime, observabilité différente

L’orchestration de containers est un point central en cloud moderne.
 Stockage : objet, bloc, fichier
Stockage objet (buckets) :
➔ idéal pour médias, backups, data lakes

➔ très scalable, accès API HTTP

Stockage bloc (volumes attachés aux VM) :
➔ base des disques de VM, bonnes perfs, snapshots
Stockage fichier (partages) :
➔ compatibilité applications (NFS/SMB), home directories, etc.
Pratique : le choix du stockage impacte coût, performances, et architecture (backup/DR).
 Données & services managés (DB, cache, messaging)
Tendance cloud : “managed services” pour réduire l’ops :
➔ DB managée (patching, backups, réplication)

➔ Cache managé (ex : in-memory)

➔ Messaging/queue (découpler les services)

➔ Data processing (ETL, stream, analytics)

Insight : on échange du contrôle contre :
➔ vitesse de delivery

➔ fiabilité “built-in”

➔ opérabilité standardisée
 Load balancing et patterns de scalabilité
Pour absorber la charge, on combine :
➔ Load balancer (L4/L7)

➔ Autoscaling (horizontal)

➔ Stateless services (sessions externalisées)

➔ Caching (CDN / cache applicatif)

➔ Découplage par messages (queue/pubsub)

Principe : si votre service ne peut pas scaler horizontalement, il “résiste” mal au cloud.
 Identité, IAM et “policy as code”
La sécurité “architecture” commence par l’identité :
➔ IAM (utilisateurs, rôles, services)

➔ Least privilege (moindre privilège)

➔ Séparation des environnements (dev/test/prod)

➔ Policies centralisées, auditables (approche “policy as code”)

Dans les architectures de référence, sécurité et gestion sont des fonctions transverses.
 Observabilité : logs, métriques, traces
Sans observabilité, pas d’exploitation fiable :
➔ Logs centralisés (recherche, corrélation)

➔ Métriques (SLO/SLA, saturation, latence, erreurs)

➔ Traces distribuées (microservices)

➔ Alerting + runbooks
Pratique : “Si ce n’est pas mesuré, ce n’est pas opérable” (liens directs avec measured service).
 Fiabilité : redondance, DR, et tolérance aux pannes
Pattern essentiels :
➔ Multi-AZ pour les composants critiques

➔ Backups + restauration testée

➔ DR (Disaster Recovery) : stratégie RPO/RTO

➔ Dégradation contrôlée (graceful degradation)

On relie ici aux cadres well-architected : fiabilité, excellence opérationnelle, sécurité, coût
 “Landing zones” et organisation à l’échelle entreprise (Azure
CAF)
À grande échelle, l’architecture inclut la structure d’organisation :
➔ hiérarchie (management groups), subscriptions, séparation plateforme vs workloads

➔ politiques, gouvernance, réseau partagé, sécurité centrale

C’est l’idée de landing zone : une fondation standardisée pour déployer des workloads propres.
MODÈLES DE DÉPLOIEMENT DU
CLOUD
 Objectifs de la section
À la fin de cette section, vous serez capables de :
➔ Définir les modèles de déploiement du cloud selon les standards

➔ Comparer public, privé, hybride et communautaire

➔ Choisir un modèle adapté à un contexte réel

➔ Comprendre les compromis (coût, sécurité, contrôle, flexibilité)

 Définition (standard NIST)
Selon le NIST, les cloud deployment models décrivent où et pour qui l’infrastructure cloud est déployée.
Le NIST définit 4 modèles :
1. Public Cloud

2. Private Cloud

3. Hybrid Cloud

4. Community Cloud
Ces modèles sont indépendants des modèles de service (IaaS, PaaS, SaaS).
 Pourquoi plusieurs modèles ?
Il n’existe pas de modèle universel.
Les choix dépendent de :
➔ Sensibilité des données

➔ Contraintes réglementaires

➔ Budget et compétences internes

➔ Besoins de scalabilité

➔ Héritage applicatif (legacy)

Le modèle de déploiement est un choix stratégique, pas seulement technique.
 Public Cloud : définition
Définition (NIST) Le cloud public est une infrastructure mise à disposition du grand public, détenue et
exploitée par un fournisseur cloud.
Caractéristiques :
➔ Infrastructure partagée (multi-tenant)

➔ Accès via Internet

➔ Paiement à l’usage

➔ Gestion assurée par le fournisseur

 Public Cloud : avantages

➔ Aucun investissement matériel initial

➔ Scalabilité et élasticité quasi immédiates

➔ Déploiement très rapide

➔ Large écosystème de services managés

➔ Coûts optimisés à court et moyen terme

Idéal pour : startups, projets dynamiques, workloads variables
 Public Cloud : limites

➔ Moins de contrôle sur l’infrastructure physique

➔ Contraintes de conformité selon les données

➔ Dépendance au fournisseur (vendor lock-in)

➔ Latence possible selon la région

Le public cloud n’est pas “non sécurisé”, mais la responsabilité est partagée.
 Private Cloud : définition
Définition (NIST) Le cloud privé est une infrastructure cloud exclusive à une seule organisation.
Il peut être :
➔ Sur site (on-premise)

➔ Hébergé chez un tiers

➔ Géré par l’organisation ou un prestataire

 Private Cloud : avantages

➔ Contrôle total sur les données et l’infrastructure

➔ Meilleure conformité réglementaire

➔ Personnalisation avancée

➔ Intégration plus simple avec systèmes legacy

Très utilisé dans : finance, défense, santé, administrations
 Private Cloud : limites

➔ Coûts élevés (CAPEX + OPEX)

➔ Scalabilité limitée par l’infrastructure

➔ Nécessite des compétences internes élevées

➔ Innovation plus lente que le public cloud

Ce n’est pas “moins cher”, mais plus contrôlé.
 Hybrid Cloud : définition
Définition (NIST) Le cloud hybride combine au moins deux infrastructures cloud distinctes (public et privé),
reliées par des technologies standardisées.
Objectif :
➔ Permettre la portabilité des données et applications
 Hybrid Cloud : cas d’usage
Exemples typiques :
➔ Données sensibles en cloud privé

➔ Traitement ou front-end en cloud public

➔ Cloud bursting : extension temporaire vers le public cloud

➔ Migration progressive vers le cloud

Modèle très courant dans les grandes entreprises.
 Hybrid Cloud : défis

➔ Complexité d’architecture

➔ Sécurité inter-environnements

➔ Gestion réseau avancée

➔ Observabilité plus difficile

Le défi n’est pas technique seul, mais organisationnel.
 Community Cloud : définition
Définition (NIST) Le cloud communautaire est partagé par plusieurs organisations ayant des besoins
communs :
➔ Réglementaires

➔ Sécuritaires

➔ Fonctionnels
Exemples :
➔ Institutions gouvernementales

➔ Secteur santé

➔ Universités
 Community Cloud : avantages et limites
Avantages
➔ Mutualisation des coûts

➔ Gouvernance commune

➔ Conformité sectorielle
Limites
➔ Moins flexible

➔ Plus rare dans la pratique

➔ Dépend fortement de la coordination entre acteurs

 Comparaison des modèles

Critère Public Privé Hybride Communautaire

Coût initial Faible Élevé Moyen Moyen

Scalabilité Très élevée Limitée Élevée Moyenne

Contrôle Faible Très élevé Élevé Partagé

Complexité Faible Moyenne Élevée Élevée

Cas typiques Startups Données sensibles Grandes entreprises Secteurs régulés

 Comment choisir un modèle ?
Questions clés à poser :
➔ Où sont stockées les données sensibles ?

➔ Quelle est la variabilité de la charge ?

➔ Quelles obligations légales/réglementaires ?

➔ Quelles compétences internes ?

➔ Quelle tolérance au vendor lock-in ?

Le “bon” modèle dépend du contexte, pas de la mode.
 Tendance actuelle (industrie)

➔ Forte adoption du hybrid cloud

➔ Montée du multi-cloud (non défini par le NIST, mais très courant)

➔ Usage croissant des services managés

➔ Séparation plateforme / workloads

Les architectures modernes sont souvent hybrides par nature.
MODÈLES DE SERVICES CLOUD
(APERÇU CONCEPTUEL)
 Objectifs de la section
À la fin de cette section, vous saurez :
➔ Définir les modèles de services cloud selon les standards

➔ Distinguer IaaS, PaaS et SaaS

➔ Comprendre le partage des responsabilités

➔ Choisir un modèle selon un besoin métier/technique

 Définition (standard NIST)
Selon le NIST, les cloud service models décrivent le niveau d’abstraction auquel un service cloud est fourni au
consommateur.
Le NIST définit trois modèles :
1. Infrastructure as a Service (IaaS)

2. Platform as a Service (PaaS)

3. Software as a Service (SaaS)

La différence clé : qui gère quoi.
 Notion d’abstraction (idée centrale)
Les modèles de service forment une pyramide d’abstraction :
➔ Plus on monte :
◆ Moins on gère l’infrastructure
◆ Plus on se concentre sur la valeur métier

➔ Plus on descend :
◆ Plus on a de contrôle
◆ Plus la gestion est complexe
Ce n’est pas “meilleur ou pire”, c’est un choix d’architecture.
 IaaS : définition
Définition (NIST) L’IaaS fournit des ressources fondamentales de calcul :
➔ Machines virtuelles

➔ Stockage

➔ Réseau
Le consommateur :
➔ Déploie et gère ses systèmes

➔ Contrôle l’OS, le stockage, les applications

 IaaS : ce que l’utilisateur gère
L’utilisateur est responsable de :
➔ Système d’exploitation

➔ Middleware et runtime

➔ Applications et données

➔ Sécurité au niveau OS et applicatif

Le fournisseur gère :
➔ Matériel

➔ Virtualisation

➔ Infrastructure réseau
Modèle le plus proche de l’informatique traditionnelle, mais élastique.
 IaaS : cas d’usage typiques

➔ Migration d’applications existantes (lift-and-shift)

➔ Environnements de test/dev flexibles

➔ Besoins forts de personnalisation

➔ Charges de calcul intensives (HPC, IA)

Avantages
➔ Contrôle maximal

➔ Grande flexibilité
Limites
➔ Gestion opérationnelle élevée

➔ Patching et sécurité à assurer

 PaaS : définition
Définition (NIST) Le PaaS fournit une plateforme complète pour développer, tester et déployer des applications.
Le consommateur :
➔ Déploie du code

➔ Configure l’environnement applicatif

Le fournisseur :
➔ Gère l’infrastructure + OS + runtime
 PaaS : ce que l’utilisateur gère
L’utilisateur est responsable de :
➔ Code applicatif

➔ Données

➔ Paramètres de configuration
Le fournisseur gère :
➔ OS

➔ Middleware

➔ Runtime

➔ Scaling de la plateforme
Le développeur se concentre sur le code, pas sur les serveurs.
 PaaS : cas d’usage typiques
➔ Développement web/API
➔ Applications cloud-native
➔ Prototypage rapide
➔ Équipes orientées DevOps
Avantages
➔ Productivité élevée
➔ Déploiement rapide
➔ Scaling intégré
Limites
➔ Moins de contrôle bas niveau
➔ Risque de dépendance à la plateforme
 SaaS : définition
Définition (NIST) Le SaaS fournit des applications complètes accessibles via le réseau.
Le consommateur :
➔ Utilise l’application

➔ Gère uniquement les paramètres utilisateur

Le fournisseur :
➔ Gère tout le reste
 SaaS : ce que l’utilisateur gère
L’utilisateur est responsable de :
➔ Comptes utilisateurs

➔ Paramétrage fonctionnel

➔ Données saisies
Le fournisseur gère :
➔ Application

➔ Infrastructure

➔ Sécurité

➔ Mises à jour
C’est le modèle le plus simple à consommer.
 SaaS : cas d’usage typiques
➔ Messagerie et collaboration
➔ CRM, ERP
➔ Outils RH, finance
➔ Outils pédagogiques
Avantages
➔ Aucune gestion technique
➔ Mise à jour transparente
➔ Coût prévisible
Limites
➔ Personnalisation limitée
➔ Dépendance forte au fournisseur
Comparaison des modèles de service
 Comment choisir le bon modèle ?
Questions clés :
➔ Ai-je besoin de contrôle ou de rapidité ?

➔ Mon équipe peut-elle gérer l’OS et la sécurité ?

➔ L’application est-elle standard ou spécifique ?

➔ Quelle est la tolérance au vendor lock-in ?

En pratique, les architectures modernes mélangent souvent les modèles.
CONCEPTS CLÉS ET TERMINOLOGIE DU
CLOUD COMPUTING
 Objectifs de la section
À la fin de cette section, vous serez capables de :
➔ Comprendre et utiliser le vocabulaire fondamental du cloud

➔ Lire et interpréter une architecture cloud

➔ Éviter les confusions fréquentes

➔ Faire le lien entre concepts techniques et exigences métier

 Pourquoi le vocabulaire est crucial
En cloud computing :
➔ Les décisions sont architecturales

➔ Les concepts sont transversaux (réseau, sécurité, coût, perf)

➔ Une mauvaise compréhension → mauvaise architecture

Le vocabulaire cloud n’est pas du jargon : c’est un outil de conception.
 Scalabilité (Scalability)
Scalabilité : capacité d’un système à supporter une augmentation de charge.
Deux formes :
➔ Verticale (scale up) : plus de ressources sur une même machine

➔ Horizontale (scale out) : plus de machines/services

La scalabilité décrit un potentiel, pas une réaction immédiate.
 Élasticité (Elasticity)
Élasticité : capacité à augmenter ET réduire rapidement les ressources en fonction de la demande.
Différence clé :
➔ Scalabilité : peut-on grandir ?

➔ Élasticité : peut-on grandir et rétrécir automatiquement ?

L’élasticité est une propriété centrale du cloud (standardisée, ex. NIST).
 Performance : latence, débit, throughput
Concepts souvent confondus :
➔ Latence : temps de réponse (ms)

➔ Débit (bandwidth) : quantité de données par unité de temps

➔ Throughput : travail réellement traité par le système

Une architecture cloud performante minimise la latence et maximise le throughput, pas forcément la bande
passante.
 Disponibilité (Availability)
Disponibilité : proportion de temps où un service est opérationnel.
Exprimée en pourcentage d’indisponibilité :
➔ 99 % ≈ 87.6 heures/an

➔ 99,9 % ≈ 8,76 heures/an

➔ 99,99 % ≈ 52.56 minutes/an

D’où l’expression : “nombre de 9”.
 Fiabilité et tolérance aux pannes

➔ Fiabilité : capacité à fonctionner correctement dans le temps

➔ Tolérance aux pannes : capacité à continuer malgré une défaillance

Moyens classiques :
➔ Redondance

➔ Réplication

➔ Isolation des pannes

En cloud, on accepte la panne et on conçoit pour y survivre.
 HA
HA (High Availability) : architecture conçue pour éviter les points de défaillance uniques.
Caractéristiques :
➔ Multi-instances

➔ Multi-zones de disponibilité

➔ Load balancing

➔ Failover automatique
 Multi-tenancy
Multi-tenancy : plusieurs clients partagent une même infrastructure physique.
Points clés :
➔ Isolation logique (VM, containers, réseau)

➔ Mutualisation des coûts

➔ Base économique du cloud public

Multi-tenancy ≠ absence de sécurité.
 Load balancing
Load balancing : répartition du trafic entre plusieurs ressources.
Objectifs :
➔ Améliorer les performances

➔ Éviter la surcharge

➔ Augmenter la disponibilité
Types :
➔ L4 (transport)

➔ L7 (application)
 Service mesuré & Pay-as-you-go
Concept clé du cloud :
➔ Ressources mesurées automatiquement

➔ Facturation à l’usage réel

➔ Possibilité d’optimisation fine des coûts

Celà entraine : * Avantage : flexibilité * Risque : dérive des coûts si mal géré
 SLA (Service Level Agreement)
SLA : engagement contractuel du fournisseur.
Contient :
➔ Disponibilité garantie

➔ Temps de réponse support

➔ Compensation en cas de non-respect

Un SLA ne garantit pas l’absence de panne, mais des engagements mesurables.
 Observabilité
Capacité à comprendre l’état interne d’un système via :
➔ Logs

➔ Métriques

➔ Traces distribuées
Objectifs :
➔ Détection d’incidents

➔ Analyse de performance

➔ Amélioration continue
Indispensable dans les architectures cloud modernes.
 Stateless vs Stateful

➔ Stateless : aucun état local (idéal pour le cloud)

➔ Stateful : état conservé localement (plus complexe à scaler)

Bonne pratique cloud :
➔ Externaliser l’état (DB, cache, stockage partagé)

➔ Garder les services stateless

 Résilience et Disaster Recovery

➔ Résilience : continuer à fonctionner malgré des incidents

➔ Disaster Recovery (DR) : reprise après un incident majeur

Concepts associés :
➔ RPO (perte de données acceptable)

➔ RTO (temps de reprise acceptable)

La résilience est architecturale, le DR est stratégique.
ASPECTS ÉCONOMIQUES ET
BUSINESS DU CLOUD COMPUTING
 Objectifs de la section
À la fin de cette section, vous serez capables de :
➔ Comprendre l’impact économique du cloud

➔ Comparer CAPEX vs OPEX

➔ Expliquer les modèles de coûts cloud

➔ Identifier les bénéfices business et les risques

➔ Relier choix techniques et décisions stratégiques

 Pourquoi le cloud est aussi un sujet business
Le cloud n’est pas seulement une technologie :
➔ C’est un modèle économique

➔ Il modifie :
◆ La structure des coûts
◆ La vitesse de mise sur le marché
◆ La manière d’innover

➔ Il influence les décisions stratégiques des organisations

Beaucoup de migrations cloud sont motivées par le business, pas par la technique.
 CAPEX (informatique traditionnelle)
CAPEX (Capital Expenditure) :
➔ Investissements lourds initiaux
➔ Achat de :
◆ Serveurs
◆ Stockage
◆ Réseau
◆ Locaux, climatisation
Caractéristiques :
➔ Coûts fixes
➔ Amortissement sur plusieurs années
➔ Sur-dimensionnement fréquent
Risque : payer pour des ressources sous-utilisées.
 OPEX (modèle cloud)
OPEX (Operational Expenditure) :
➔ Paiement à l’usage

➔ Dépenses étalées dans le temps

➔ Ajustement dynamique des ressources

Caractéristiques :
➔ Coûts variables

➔ Plus de flexibilité financière

➔ Meilleure visibilité à court terme

Le cloud transforme l’IT en service consommable.
 Comparaison CAPEX vs OPEX

Critère CAPEX OPEX (Cloud)

Investissement initial Élevé Faible

Flexibilité Faible Élevée

Scalabilité Limitée Dynamique

Risque financier Important Réduit

Agilité Faible Forte

 Pay-as-you-go (paiement à l’usage)
Principe fondamental du cloud :
➔ Paiement uniquement pour :
◆ Le temps de calcul
◆ Le stockage utilisé
◆ Le trafic réseau
◆ Les requêtes
Avantages :
➔ Pas de gaspillage théorique

➔ Adapté aux charges variables

⚠ Inconvénient : coûts imprévisibles si mal contrôlés.
 Autres modèles de tarification
Selon les services, on trouve :
➔ À l’usage (heure, seconde, requête)

➔ Abonnement mensuel

➔ Tarification par paliers

➔ Réservations à long terme (réduction de coût)

➔ Facturation différenciée selon performance / région

Le choix du modèle a un impact direct sur l’architecture.
 Agilité et time-to-market
Le cloud permet :
➔ Déployer en minutes ce qui prenait des semaines

➔ Tester rapidement de nouvelles idées

➔ Itérer sans coûts initiaux élevés

Avantage clé : réduction du time-to-market
Exemple :
➔ MVP lancé rapidement

➔ Abandon possible sans perte matérielle

 Innovation et expérimentation
Grâce au cloud :
➔ Accès facile à des technologies avancées :
◆ IA
◆ Big Data
◆ IoT

➔ Faible barrière à l’entrée

➔ Expérimentation à faible risque

Le cloud favorise l’innovation continue.
 Scalabilité business
Le cloud permet d’aligner :
➔ Les ressources techniques

➔ Avec la croissance réelle du business

Exemples :
➔ Pic saisonnier (e-commerce)

➔ Lancement marketing

➔ Croissance internationale
Le système informatique ne bloque plus la croissance.
 Coûts cachés et dérive budgétaire
Risques fréquents :
➔ Ressources oubliées (VM, stockage)

➔ Mauvaise configuration

➔ Surdimensionnement “par confort”

➔ Facturation réseau imprévue

Le cloud peut coûter plus cher qu’un data center s’il est mal géré.
 Vendor lock-in
Vendor lock-in : dépendance forte à un fournisseur.
Causes :
➔ Services propriétaires

➔ APIs spécifiques

➔ Données difficiles à migrer

Conséquences :
➔ Coûts de sortie élevés

➔ Moins de pouvoir de négociation

Problème stratégique, pas seulement technique.
 Gouvernance et FinOps
Réponse moderne aux défis économiques :
FinOps :
➔ Discipline qui combine :
◆ Finance
◆ IT
◆ Business

➔ Objectifs :
◆ Visibilité des coûts
◆ Optimisation continue
◆ Responsabilisation des équipes
“Everyone owns their cloud bill”.
 Comment une organisation décide ?
Critères clés :
➔ Taille et maturité de l’entreprise

➔ Sensibilité des données

➔ Variabilité de la charge

➔ Compétences internes

➔ Objectifs business (croissance, innovation, réduction des coûts)

Le cloud est un choix stratégique évolutif, pas binaire.
CONCLUSION
 Conclusion
Au cours de ce chapitre, nous avons établi les fondations essentielles du cloud computing :
➔ Le cloud est l’aboutissement d’une évolution historique des modèles de calcul

➔ Il repose sur des principes normalisés (accès à la demande, élasticité, mutualisation, service mesuré)

➔ Son architecture combine virtualisation, automatisation, résilience et services managés

➔ Les modèles de déploiement et de service offrent différents niveaux de contrôle et de responsabilité

➔ Le cloud transforme profondément les aspects économiques et stratégiques de l’informatique

Le cloud n’est pas seulement une technologie, mais un changement de paradigme dans la manière de concevoir,
déployer et exploiter les systèmes informatiques.
FIN