cloud computing revu

☁️ Cloud Computing — TS STIC 2

Synthèse finale, harmonisée, explicite et approfondie
Objectif : Document unifié sans confusion, avec résolution explicite de tous les exercices, liens
inter-thématiques, nuances opérationnelles et exemples concrets.

Table des matières

1. Des systèmes distribués au Cloud
2. Définitions fondamentales (avec distinctions précises)
3. Les 5 caractéristiques essentielles du Cloud (NIST)
4. Avantages du Cloud Computing (nuancés)
5. Modèles de services : IaaS, PaaS, SaaS, DaaS
6. Modèles de déploiement
7. Architecture Cloud et Sécurité
8. Big Data, IA, IoT : la synergie
9. Fournisseurs de services Cloud
10. Haute disponibilité, PRA et PCA
11. Les métiers du Cloud
12. Cas Moodle : déploiement et résolution d'incidents
13. Corrections complètes des examens et TD
14. Projets TS STIC 2 : orientations techniques
15. Récapitulatif final

1. Des systèmes distribués au Cloud : la transition logique

1.1 Les systèmes distribués (précurseurs)
Un système distribué est un ensemble de machines indépendantes reliées par un réseau, qui
apparaissent à l'utilisateur comme un système unique et cohérent.
Promesse;, Réalité opérationnelle
Puissance de calcul théorique Difficulté d'administration et de maintenance
immense
Capacité de stockage quasi Programmation complexe (concurrence, tolérance aux
illimitée pannes)
Mutualisation des ressources Gestion lourde des middlewares (couches
intermédiaires)

Nuance essentielle : Les systèmes distribués n'ont pas disparu — ils sont devenus
invisibles. Le Cloud est leur industrialisation : le fournisseur gère la complexité, le client
consomme la puissance.

1.2 Pourquoi le Cloud Computing ? (4 moteurs fondamentaux)

1. Besoin croissant d'espace de stockage : Facebook génère ~4 Po/jour. Aucune entreprise
ne peut stocker cela en local de manière rentable.
2. Besoin de puissance de calcul : L'IA, le Machine Learning et la cryptographie moderne
nécessitent des milliards d'opérations par seconde.
3. Coût élevé d'acquisition d'un Data Center : Investissement initial (CAPEX) en
infrastructure physique, énergie, refroidissement, sécurité physique et personnel qualifié.
4. Complexité des algorithmes : Le traitement distribué (MapReduce, Spark) et le Deep
Learning nécessitent une orchestration à grande échelle impossible à gérer manuellement.

Lien direct : Le Cloud transforme un CAPEX (achat) en OPEX (location à l'usage), rendant
l'informatique de haut niveau accessible aux PME et startups.

2. Définitions fondamentales (avec distinctions précises)

2.1 Système d'information vs Système informatique vs Cloud
Computing
Système d'information (SI) : Ensemble organisé de ressources (humaines, matérielles,
logicielles, financières) permettant de collecter, stocker, traiter et diffuser l'information au
sein d'une organisation. C'est une notion organisationnelle et stratégique.
Système informatique : Partie technique du SI : hardware, software, réseaux, bases de
données. C'est la dimension technique et matérielle.
Cloud Computing : Modèle de fourniture de services informatiques (calcul, stockage,
réseau, applications) via Internet, à la demande, avec un modèle de paiement à l'usage.
 Lien : Le Cloud Computing est un mode de mise à disposition du système informatique,
qui sert lui-même le système d'information.

2.2 Cloud Computing (définition NIST — référence absolue)

Définition officielle : Modèle permettant un accès réseau ubiquitaire, pratique et à la
demande à un pool partagé de ressources informatiques configurables (réseaux,
serveurs, stockage, applications, services) pouvant être rapidement provisionnées et
libérées avec un minimum d'effort de gestion ou d'interaction avec le fournisseur.

Mots-clés à retenir :

Ubiquitaire : accessible de n'importe où, n'importe quand.

Pool partagé : mutualisation (multi-tenant).
Rapidement : minutes, pas des semaines comme en on-premise.
Minimum d'effort : l'utilisateur n'achète pas, il consomme.

2.3 Big Data (les 5V)

Le Big Data désigne les données dont la complexité dépasse les capacités des outils
traditionnels (SGBD relationnels classiques).

V Définition Exemple concret Lien avec le Cloud

Volume Quantité massive Facebook : 4 Po/jour Le Cloud offre du stockage quasi
(To, Po, Eo) infini (S3, Blob Storage)
Vélocité Vitesse de Tweets en temps L'élasticité du Cloud absorbe les
génération réel, capteurs IoT pics de flux (Auto Scaling)
Variété Diversité des Images, vidéos, Les Data Lakes Cloud stockent
formats JSON, CSV, logs tout format brut
Valeur Bénéfice Prédiction de churn, Le Cloud met à disposition des
économique de détection de fraude outils d'analyse (BigQuery, EMR)
l'analyse
Véracité Fiabilité et qualité Données bruitées Les services de gouvernance
des données vs données Cloud (IAM, catalogues)
certifiées sécurisent la qualité

Indicateur pratique : Si vos données ne tiennent pas en RAM, vous faites face à un
problème Big Data → il faut paralléliser les calculs sur plusieurs machines (Hadoop,
Spark).

2.4 Base de données vs Data Center

 Base de données (BDD) : Conteneur logiciel structuré permettant de stocker, organiser et
interroger des données (MySQL, PostgreSQL, Oracle). C'est un logiciel.
Data Center : Infrastructure physique (racks, serveurs, routeurs, onduleurs, climatisation,
sécurité physique). C'est le lieu physique.

Nuance : Une base de données peut tourner dans un Data Center, dans un serveur local,
ou être fournie en tant que service Cloud (RDS, Azure SQL Database). Le Data Center est
le contenant ; la base de données est le contenu logiciel.

2.5 Data Center vs Cloud

Data Center : Infrastructure physique. C'est le lieu.
Cloud : Modèle de service qui abstrait le Data Center. L'utilisateur ne voit pas les serveurs
physiques, il interagit avec des ressources virtuelles.

Nuance : Le Cloud n'abolit pas le Data Center — il le virtualise et le mutualise. Derrière

AWS ou Azure se trouvent des dizaines de Data Centers mondiaux.

2.6 Data Lake vs Data Warehouse

Data Lake Data Warehouse

Données Brutes, non transformées, tous Structurées, nettoyées, transformées
formats
Schéma Schema-on-read (défini à la lecture) Schema-on-write (défini à l'écriture)
Utilisateurs Data Scientists, Data Engineers Analystes métier, BI
Technologie HDFS, S3, Azure Data Lake Hive, BigQuery, Snowflake, Teradata
Coût Faible (stockage objet) Plus élevé (calcul + stockage
optimisé)

2.7 Data Lab

Environnement expérimental et collaboratif où les équipes data explorent, prototypent et testent
des hypothèses sans impacter la production. C'est le laboratoire R&D de la donnée dans le
Cloud.

2.8 Intelligence Artificielle (IA)

L'IA vise à reproduire des activités mentales humaines (compréhension, perception, décision)
par des algorithmes.

Hiérarchie :
 Intelligence Artificielle (IA générale)
└── Apprentissage Automatique (Machine Learning)
└── Apprentissage Profond (Deep Learning — réseaux de neurones)

Lien Cloud-IA : L'entraînement d'un modèle de Deep Learning nécessite des GPU et des
pétaoctets de données. Seul le Cloud permet d'y accéder à la demande (AWS SageMaker,
Google Vertex AI, Azure ML).

2.9 Internet des Objets (IoT)

Réseau d'appareils physiques (capteurs, actionneurs, objets du quotidien) intégrant des
logiciels et technologies pour se connecter à Internet et échanger des données.

Chaîne de valeur complète :

Objet IoT → Collecte → Cloud → Stockage Big Data → Analyse IA → Décision →
Action (ex: feu de circulation ajusté, alerte médicale envoyée)

3. Les 5 caractéristiques essentielles du Cloud (NIST)

3.1 Libre-service à la demande (On-Demand Self-Service)
L'utilisateur provisionne des ressources automatiquement sans interaction humaine avec le
fournisseur. Il se connecte à une console web, clique, et sa VM est prête en minutes.

Exemple : Sur AWS EC2, un développeur lance une instance Ubuntu 22.04 à 14h00 pour
un test, et la termine à 16h00. Il n'a appelé personne chez Amazon.

3.2 Large accès au réseau (Broad Network Access)

Les services sont accessibles via des mécanismes standard (navigateur web, API REST)
depuis n'importe quel terminal : PC, laptop, smartphone, tablette.

Nuance : "Standard" signifie HTTP/HTTPS, pas de VPN propriétaire obligatoire (même si

un VPN peut être utilisé pour la sécurité).

3.3 Mise en commun des ressources (Resource Pooling)

Les ressources physiques sont mutualisées entre plusieurs clients (multi-tenant). Le client
ignore l'emplacement physique exact de ses données, mais peut choisir une région
géographique (ex: "Europe", "Afrique de l'Ouest").
 Exemple : Votre VM AWS EC2 tourne sur un serveur physique partagé avec d'autres
clients. L'hyperviseur (KVM, Xen) isole vos ressources.

3.4 Élasticité rapide (Rapid Elasticity)

Les ressources peuvent être provisionnées et libérées automatiquement pour s'adapter à la
charge. C'est l'auto-scaling.

Exemple concret (Black Friday) : Un site e-commerce passe de 2 serveurs à 50 serveurs

automatiquement le jour J, puis revient à 2 serveurs le lendemain. Le client paie
uniquement les 50 serveurs pendant quelques heures.

3.5 Service mesuré (Measured Service)

L'utilisation est monitorée, contrôlée et facturée de manière transparente. C'est le modèle
Pay-as-you-go (payez ce que vous consommez), comparable à l'eau ou l'électricité.

Exemple : AWS facture l'EC2 à la seconde d'utilisation CPU, le stockage S3 au Go/mois, le

transfert réseau au Go sortant.

4. Avantages du Cloud Computing (nuancés)

Avantage Explication Nuance / Limite

Haute disponibilité SLA souvent à 99,9% ou Le fournisseur garantit l'infra, pas
99,99% votre application mal codée
Collaboration & Accès multi-utilisateur, Nécessite une gouvernance des
mobilité multi-device accès (IAM) stricte
Récupération & Snapshots, réplication Le client doit configurer ses politiques
sauvegarde géographique de backup (surtout en IaaS)
Sécurité Investissements massifs En IaaS, la sécurité IN the Cloud
des hyperscalers reste de la responsabilité du client
Flexibilité Choix du service, de la Le "vendor lock-in" (dépendance au
région, du modèle fournisseur) est un risque réel
Évolution Scale up (vertical) ou scale Scale out implique une architecture
(Scalabilité) out (horizontal) applicative adaptée (stateless)
Gestion simplifiée Plus de maintenance En IaaS, vous gérez quand même
physique l'OS, les patches, les mises à jour
Agilité Déploiement en minutes Nécessite une culture DevOps et des
compétences Cloud
 Avantage Explication Nuance / Limite
Reprise après Réplication multi-régions Le PRA/PCA doit être pensé et testé,
sinistre facilitée pas seulement "activé"

5. Modèles de services : le cœur du Cloud

5.1 La pyramide de responsabilité
La question fondamentale est : qui gère quoi ?

┌─────────────────────────────────────┐
│ SaaS │ ← Vous CONSOMMEZ (vous gérez : données,
compte)
│ Applications, Données │
├─────────────────────────────────────┤
│ PaaS │ ← Vous CONSTRUISEZ (vous gérez :
applications, données)
│ Runtime, Middleware, OS │
├─────────────────────────────────────┤
│ IaaS │ ← Vous MIGREZ (vous gérez : OS,
middleware, runtime, applications, données)
│ Virtualisation, Serveurs, Stockage│
├─────────────────────────────────────┤
│ Fournisseur Cloud │ ← Gère toujours : Physique, Réseau
physique, Datacenter
└─────────────────────────────────────┘

5.2 IaaS — Infrastructure as a Service

Concept : Le fournisseur livre des ressources d'infrastructure virtualisées (VM, stockage bloc,
réseau). Le client installe et gère tout ce qui est au-dessus de l'hyperviseur.

Responsabilités :

Fournisseur : Datacenter physique, réseau physique, serveurs, stockage physique,

hyperviseur.
Client : OS, middleware, runtime, applications, données, sécurité applicative.

Facturation :

Temps CPU des instances (à l'heure ou à la seconde)

 Go de stockage provisionné (mois)
Trafic réseau sortant (Go)
I/O disque (nombre d'opérations)

Exemples : Amazon EC2, Azure Virtual Machines, Google Compute Engine, OVH Public
Cloud, RackSpace.

Sous-modèles IaaS :

DBaaS (Database as a Service), NaaS (Network as a Service), STaaS (Storage as a

Service), LBaaS (Load Balancing as a Service).

Analogie : Louer un appartement vide. Le propriétaire gère l'immeuble (toit, chauffage

central, ascenseur). Vous installez la cuisine, la salle de bain, le mobilier, et vous faites le
ménage.

5.3 PaaS — Platform as a Service

Concept : Le fournisseur livre un environnement de développement et d'exécution
complet. Le client apporte uniquement son code et ses données.

Responsabilités :

Fournisseur : Tout ce qu'IaaS gère + OS + middleware + runtime + outils de

développement.
Client : Applications et données uniquement.

Caractéristiques :

Langages/frameworks prêts : Python, Java, PHP, [Link], Ruby, Go.

Services intégrés : gestion des utilisateurs, bases de données gérées, équilibrage de
charge.
Déploiement simplifié : git push et l'application est en ligne.

Exemples publics : Google App Engine, Heroku, Salesforce [Link], Oracle Apex,
[Link] (hébergement managé), AWS Elastic Beanstalk.
Exemples privés : CloudFoundry, OpenShift (Red Hat).

Analogie : Louer un appartement meublé et équipé (cuisine, vaisselle, lave-linge). Vous

n'apportez que vos affaires personnelles (code) et vous vivez. Si le robinet fuit, c'est le
propriétaire qui répare.

5.4 SaaS — Software as a Service

Concept : Le fournisseur livre une application clé en main via Internet. L'utilisateur final
n'installe rien, ne gère rien — il consomme.

Responsabilités :

Fournisseur : Tout (infrastructure + plateforme + application + maintenance + mises à

jour).
Client : Ses données, la configuration de son compte, la formation de ses utilisateurs.

Modèle commercial : Abonnement mensuel/annuel par utilisateur (seat).

Exemples par catégorie :

Bureautique : Microsoft Office 365, Google Workspace (Gmail, Docs, Drive)

CRM : Salesforce, HubSpot
Vidéoconférence : Zoom, Webex, Skype, Teams
Stockage : Dropbox, OneDrive, Google Drive
Divertissement : Netflix, Spotify
Collaboration : Trello, Slack, Notion
Réseaux sociaux : Facebook, LinkedIn

Analogie : Aller au restaurant. Vous ne cuisinez pas, vous ne faites pas la vaisselle, vous
ne réparez pas le four. Vous choisissez au menu et vous payez pour ce que vous
consommez.

5.5 DaaS — Data as a Service

Fourniture de données structurées ou en flux via API, prêtes à être consommées. Le
fournisseur gère la collecte, la mise à jour et la qualité.

Exemples : Google Maps API, API météo (OpenWeather), données financières (Bloomberg),
données de géolocalisation.

5.6 Tableau comparatif unifié des responsabilités

Couche On-Premises IaaS PaaS SaaS

Applications Vous Vous Vous Fournisseur
Données Vous Vous Vous Fournisseur
Runtime Vous Vous Fournisseur Fournisseur
Middleware Vous Vous Fournisseur Fournisseur
OS Vous Vous Fournisseur Fournisseur
Couche On-Premises IaaS PaaS SaaS
Virtualisation Vous Fournisseur Fournisseur Fournisseur
Serveurs Vous Fournisseur Fournisseur Fournisseur
Stockage Vous Fournisseur Fournisseur Fournisseur
Réseau Vous Fournisseur Fournisseur Fournisseur
Stratégie Tout construire Migrer Construire dessus Consommer

6. Modèles de déploiement
6.1 Cloud Public
Propriétaire : Fournisseur tiers (AWS, Azure, GCP, OVH).
Accès : Internet.
Infrastructure : Mutualisée (multi-tenant), virtualisée, partagée entre plusieurs clients.
Usage : Workloads non sensibles, développement, tests, sites web grand public.
Avantages : Aucun CAPEX, scalabilité maximale, tarification à l'usage.
Risques : Moins de contrôle sur la localisation physique exacte, conformité réglementaire à
vérifier (RGPD, lois de souveraineté des données).

6.2 Cloud Privé

Propriétaire : Organisation unique (en interne ou chez un hébergeur dédié).
Accès : Internet, fibre dédiée ou réseau privé (VPN, MPLS).
Infrastructure : Dédiée et privatisée. Données sur serveurs non partagés.
Usage : Données confidentielles, systèmes critiques (banque, santé, défense).
Technologies : OpenStack, VMware vSphere, Nutanix.
Avantages : Contrôle total, conformité maximale, personnalisation.
Inconvénients : CAPEX élevé, nécessite une équipe IT qualifiée en interne.

6.3 Cloud Hybride

Définition : Combinaison de Cloud Privé et Public. Les données critiques restent en privé ;
les workloads variables ou publics vont sur le Cloud Public.
Mécanisme clé : Cloud Bursting — quand le Cloud Privé est saturé, le surplus de charge
"déborde" vers le Cloud Public.
Exemple : Une banque garde ses données clients en privé, mais héberge son application
mobile et sa campagne marketing sur AWS.
6.4 Cloud Communautaire
Définition : Infrastructure partagée entre plusieurs organisations ayant des besoins
communs (même secteur, mêmes contraintes réglementaires).
Gestion : Interne ou externalisée.
Exemple : Plusieurs hôpitaux d'une région partagent un Cloud Communautaire pour
respecter les normes de confidentialité médicale tout en mutualisant les coûts.

6.5 Tableau comparatif des déploiements

Critère Public Privé Hybride Communautair

Propriété Fournisseur Organisation Mixte Groupe
tiers unique d'organisations
CAPEX initial Nul Élevé Moyen Partagé
Scalabilité Infinie Limitée par Bonne Bonne
le hardware (bursting)
Sécurité/Confidentialité Standard Maximale Sélective Bonne (secteur
(shared (sensitive=privé) spécifique)
responsibility)
Contrôle Faible Total Partiel Partiel
(console/API) (gouvernance
partagée)
Exemples AWS, Azure, OpenStack Banque + AWS Hôpitaux
OVH interne régionaux

7. Architecture Cloud et Sécurité

7.1 Les 4 composants
1. Frontend (côté client) : Navigateur, applications mobiles, clients lourds. Exemple : ouvrir
Gmail sur son téléphone.
2. Backend (côté cloud) : Applications, services, middleware (OpenStack), outils de sécurité
(pare-feu virtuels, backups), ressources de calcul et stockage.
3. Modèle de diffusion : IaaS, PaaS, SaaS — ce que le fournisseur expose.
4. Réseau : Internet (public), Intranet (privé), InterCloud (connexion entre fournisseurs).

7.2 Sécurité : "Security OF the Cloud" vs "Security IN the Cloud"

Cette distinction est fondamentale et source de confusion.

Security OF the Cloud Security IN the Cloud

Traduction Sécurité DU Cloud Sécurité DANS le Cloud
Responsable Fournisseur Client
Portée Physique, réseau, hyperviseur, Données, applications, accès
datacenter utilisateurs, chiffrement
Exemples Sécurité des serveurs, Configuration IAM, chiffrement des
refroidissement, alimentation, données sensibles, gestion des mots
pare-feu réseau du fournisseur de passe, correctifs OS (en IaaS)

Nuance selon le modèle de service :

En SaaS, le client gère presque uniquement la sécurité IN (ses données et ses

comptes).
En IaaS, le client gère l'OS, le middleware, l'application ET les données → sa
responsabilité IN est maximale.
En PaaS, responsabilité partagée : le fournisseur sécurise l'OS et le runtime, le client
sécurise son code et ses données.

8. Big Data, IA, IoT, Data Center et Cloud : la synergie

8.1 L'écosystème Hadoop dans le Cloud
Hadoop est le framework open-source de référence pour le traitement distribué de données
massives.

Composant Rôle dans l'écosystème

HDFS Système de fichiers distribué (stockage tolérant aux pannes)
MapReduce Moteur de traitement distribué (paradigme Map → Shuffle → Reduce)
YARN Gestionnaire de ressources et d'ordonnancement du cluster
Hive Datawarehouse SQL-like sur Hadoop (transforme requêtes SQL en jobs
MapReduce)
Pig Langage de haut niveau (Pig Latin) pour l'analyse de données complexes
HBase Base de données NoSQL orientée colonnes, distribuée et scalable
HCatalog Catalogue de métadonnées partagé entre Hive, Pig, MapReduce
 Composant Rôle dans l'écosystème
ZooKeeper Coordination et synchronisation des services distribués
Oozie Ordonnancement de workflows (chaînage de jobs)

Usages : Analyse de logs, recherche distribuée (Elasticsearch), analyse de texte et d'images,

ETL à grande échelle.

8.2 Cluster Hadoop dans le Cloud — Paramètres de performance

Les performances d'un cluster Hadoop dans le Cloud dépendent de :

1. Caractéristiques des nœuds : nombre de cœurs CPU, RAM, taille disque.

2. Réseau : latence inter-VM et débit (crucial pour le shuffle de MapReduce).
3. Taille des blocs HDFS : par défaut 128 Mo (anciennement 64 Mo).
4. Degré de réplication : par défaut 3 (tolérance à la panne de 2 nœuds).
5. Nombre de tâches Map/Reduce par nœud : doit être calibré selon les ressources.

Défis Cloud spécifiques :

Placement des VMs : si plusieurs nœuds HDFS sont sur la même machine physique, une
panne physique entraîne la perte de plusieurs répliques.
Migration : déplacer une VM contenant des données HDFS est lourd (Go à transférer).
Élasticité : Amazon EMR, OpenStack Sahara permettent de redimensionner le cluster
dynamiquement.

8.3 Traitement Batch vs Temps Réel

Dimension Batch (Traitement par lots) Temps Réel (Stream Processing)

Données Volumes massifs stockés Flux continus entrants
Latence Minutes à heures Millisecondes à secondes
Usage Rapports périodiques, Surveillance, alertes, détection de fraude,
entraînement ML, ETL personnalisation live
nocturne
Technologies Hadoop MapReduce, Spark Apache Kafka, Spark Streaming, Flink,
(batch mode) Storm
Exemple Calcul de la paie mensuelle, Alertes de fraude bancaire à la
bilan comptable transaction, ajustement des feux de
circulation
 Lien IoT → Cloud → Big Data : Les capteurs d'une ville intelligente génèrent des flux
continus (temps réel) stockés dans HDFS (batch) pour analyse historique, tout en
déclenchant des alertes immédiates (temps réel).

9. Les fournisseurs de services Cloud

9.1 Amazon Web Services (AWS) — Leader mondial
Philosophie : Plus de 200 services, granularité maximale, "everything is an API".

Service Catégorie Description Équivalent Moodle

EC2 IaaS Serveurs virtuels élastiques Serveur Apache + PHP
EBS IaaS Stockage bloc pour EC2 Disque système de la VM
S3 IaaS Stockage objet illimité Stockage des fichiers
moodledata
RDS PaaS Bases de données MariaDB/MySQL Moodle
relationnelles gérées
Route 53 IaaS DNS évolutif Nom de domaine
[Link]
Auto IaaS Élasticité automatique Gestion des pics d'inscription
Scaling
ELB IaaS Équilibrage de charge Répartition entre plusieurs
EC2
VPC IaaS Réseau privé virtuel Isolation réseau sécurisée
CloudFront IaaS CDN (réseau de diffusion de Accélération des assets
contenu) statiques
EMR PaaS Hadoop/Spark managé Analyse des logs
d'apprentissage
SageMaker PaaS Machine Learning Modèles de prédiction de
réussite

9.2 Microsoft Azure

Philosophie : Intégration forte avec l'écosystème Microsoft (Windows Server, Office 365,
.NET), plus de 150 services.

Services clés : Virtual Machines, Virtual Network, Blob Storage, SQL Database, Azure Active
Directory, App Service, Azure DevOps, Cognitive Services, IoT Hub.
 Lien TD 2023-2024 : Les modèles de déploiement chez AWS sont : Public, Privé (VPC +
Direct Connect), Hybride. Les catégories de produits sont : Calcul (EC2, Lambda), Mise en
réseau (VPC, ELB, Route 53), Sécurité (IAM, KMS, WAF), Stockage (S3, EBS, Glacier),
Base de données (RDS, DynamoDB, Redshift).

9.3 Google Cloud Platform (GCP)

Philosophie : Data Analytics et IA-native. Environ 50+ services.

Services clés : Compute Engine, Cloud Storage, BigQuery (analytics serverless), Kubernetes
Engine (GKE), Cloud Load Balancing, App Engine, Vertex AI.

9.4 OVH
Philosophie : Fournisseur européen (français), souveraineté des données, offre orientée
hébergement traditionnel évolué.

Services : VPS, Serveurs dédiés, Public Cloud (instances, GPU), Private Cloud (vSphere),
Object Storage, Anti-DDoS, Load Balancing.

9.5 Fournisseurs africains

MTN Cloud : Offres IaaS et SaaS dans plusieurs pays africains.
Orange Cloud : Présent en Côte d'Ivoire et dans la zone Orange Afrique.
SONATEL (Sénégal) : Cloud et Big Data pour le marché ouest-africain.

Nuance géopolitique : Le choix d'un fournisseur européen (OVH) ou africain peut être
dicté par la souveraineté des données (RGPD, lois locales) et la latence réseau
(datacenter proche des utilisateurs).

10. Haute disponibilité, PRA et PCA

10.1 Haute Disponibilité (HA — High Availability)
Capacité d'un système à rester opérationnel de manière continue malgré des pannes partielles.

Métriques SLA (Service Level Agreement) :

99% (2 nines) : 3,65 jours d'indisponibilité/an — inacceptable pour une banque.

99,9% (3 nines) : 8,76 heures/an — standard pour de nombreux services web.
99,99% (4 nines) : 52,56 minutes/an — exigence pour les services critiques.
99,999% (5 nines) : 5,26 minutes/an — niveau télécom/opérateur.
Mécanismes dans le Cloud :

Multi-AZ (Multiple Availability Zones) : réplication dans plusieurs datacenters d'une même
région.
Load Balancing : répartition du trafic sur plusieurs instances saines.
Auto-failover : basculement automatique vers une instance ou une base de données de
secours.

10.2 Plan de Reprise d'Activité (PRA)

Ensemble de procédures techniques permettant de reprendre les systèmes informatiques
après un sinistre majeur (incendie, inondation, cyberattaque ransomware).

Indicateurs mesurables :

RTO (Recovery Time Objective) : temps maximal acceptable d'indisponibilité. "Combien de

temps pouvons-nous être à l'arrêt ?"
RPO (Recovery Point Objective) : quantité maximale de données acceptables à perdre.
"Jusqu'où pouvons-nous revenir en arrière ?"

Exemple : Si RTO = 4h et RPO = 1h, l'entreprise doit reprendre en moins de 4 heures en

ne perdant pas plus que la dernière heure de données.

Dans le Cloud : Le PRA est facilité par la réplication automatique multi-régions (S3 Cross-
Region Replication, RDS Multi-AZ, snapshots automatisés).

10.3 Plan de Continuité d'Activité (PCA)

Stratégie organisationnelle et métier plus large que le PRA. Le PCA vise à assurer que
l'entreprise continue de fonctionner (même dégradée) pendant et après un sinistre.

Différence PRA vs PCA :

PRA = "Comment redémarre l'informatique ?" → Focus technique.

PCA = "Comment l'entreprise continue à vivre ?" → Focus métier, humain, processus,
communication.

Exemple PCA d'une banque : Redirection des appels vers un call center de secours,
activation du télétravail, utilisation de systèmes dégradés (consultation de solde sans
virement), communication de crise vers la clientèle et les régulateurs.

10.4 Sauvegarde vs Restauration

 Sauvegarde (Backup) : Copie de données à un instant T, stockée sur un support distinct
(snapshot EBS, dump SQL, sauvegarde S3). C'est une action proactive.
Restauration (Restore) : Action de reconstitution des données à partir d'une sauvegarde
après une perte. C'est une action réactive.

Nuance : Une sauvegarde sans test de restauration régulier est une illusion de sécurité. Le
PRA doit inclure des exercices de restauration.

11. Les métiers du Cloud

Le Cloud a créé un écosystème de métiers hybrides, à l'intersection du développement, de
l'infrastructure et de la data.

Métier Rôle principal Compétences clés

Architecte Cloud Conçoit l'infrastructure globale Multi-cloud, réseau, sécurité,
(choix des services, topologie, optimisation financière (FinOps)
sécurité, coût)
Professionnel Automatise le cycle de vie des Terraform, Ansible, Docker,
DevOps applications (CI/CD, Kubernetes, GitLab CI/CD
Infrastructure as Code)
Data Engineer Construit les pipelines de Spark, Kafka, Airflow, SQL/NoSQL,
données (ingestion, Cloud Storage
transformation, stockage)
Data Scientist / ML Développe des modèles Python, R, TensorFlow,
Engineer prédictifs entraînés sur des SageMaker, statistiques
données Cloud
Administrateur Gère les réseaux virtuels TCP/IP, SDN, BGP, sécurité réseau
Réseau Cloud (VPC, VPN, firewall, load
balancers)
Administrateur Gère IAM, chiffrement, Certifications (CISSP, CCSP),
Sécurité Cloud conformité, audits RGPD, chiffrement
Administrateur Gère les VMs, OS, patches, Linux, Windows Server, scripting,
Système Cloud monitoring CloudWatch/Prometheus
Administrateur BD Administre les bases de MySQL, PostgreSQL, HBase,
/ Big Data données et clusters Cassandra, optimisation de
Hadoop/Spark requêtes
Data Architect Conçoit la stratégie globale Modélisation données,
des données (modélisation, gouvernance, catalogage, lignage
gouvernance, qualité)
 Métier Rôle principal Compétences clés
Product Owner Traduit les besoins métier en Agile, compréhension métier,
Cloud solutions techniques Cloud communication technique

11.1 Administrateur On-Premises vs Administrateur Cloud

Critère Admin On-Premises Admin Cloud

Focus Hardware physique, maintenance, Services virtuels, API, automation,
salle serveur coûts
Outils KVM local, iDRAC, baies de Console web, CLI (AWS CLI, Azure
stockage CLI), Terraform
Compétences Câblage, RAID, remplacement de IAM, VPC, auto-scaling, monitoring
disques distribué
Mentalité "Je possède" "Je consomme et j'optimise"
Disponibilité Interventions physiques Gestion 100% à distance
nécessaires

11.2 Fiche de poste type : Administrateur Big Data

Mission : Installer, mettre en production, administrer et garantir la disponibilité des
environnements Big Data. Sécuriser et auditer les plateformes.

Compétences requises (niveau expert = 4) :

Systèmes : Linux (Red Hat), Windows

Big Data : Hadoop (HDFS, MapReduce), Pig, Hive, HBase
Langages : Spark, Python, R, Java
Bases : SQL, Datamining, MySQL, PostgreSQL, Oracle
Cloud : AWS, Azure, GCP
Automatisation : Shell scripting, Ansible
Méthodologies : Agile, DevOps

Formation : Bac+5 en informatique, 2 à 3 ans d'expérience en administration Big Data.

12. Moodle : déploiement d'une plateforme e-learning

12.1 Présentation
Moodle (Modular Object-Oriented Dynamic Learning Environment) est un LMS/CMS open
source en PHP, très répandu dans l'enseignement supérieur et la formation professionnelle.

12.2 Stack technique

Serveur Web : Apache 2 ou Nginx
Langage : PHP 8.x (avec extensions mbstring, curl, gd, xml, zip, etc.)
Base de données : MariaDB, MySQL, PostgreSQL
Système de fichiers :
moodle/ : code source PHP, fichiers de configuration
moodledata/ : fichiers uploadés par les utilisateurs (PDF, vidéos, images, devoirs)

12.3 Déploiement local (XAMPP) — Procédure explicite

1. Installer XAMPP (distribution Apache + PHP + MariaDB + Perl).
2. Télécharger Moodle (version stable compatible avec votre version PHP).
3. Dézipper Moodle dans le répertoire htdocs/ de XAMPP.
4. Créer la base de données via phpMyAdmin ou ligne de commande :

CREATE DATABASE moodle_db

DEFAULT CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

5. Créer un utilisateur dédié (principe du moindre privilège) :

CREATE USER 'moodle_user'@'localhost'

IDENTIFIED BY 'MotDePasseFort@2026';

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE,

CREATE TEMPORARY TABLES, DROP, INDEX, ALTER
ON moodle_db.* TO 'moodle_user'@'localhost';

FLUSH PRIVILEGES;

6. Lancer l'assistant [Link] et suivre les étapes (choix de la

langue, vérification des extensions PHP, configuration de la base, création du compte
admin).

12.4 Déploiement sur AWS (Architecture haute disponibilité)

Service AWS Rôle dans Moodle Modèle de

service
EC2 Serveur applicatif (Apache + PHP + IaaS
Moodle)
Service AWS Rôle dans Moodle Modèle de
service
RDS (MariaDB/MySQL) Base de données gérée, Multi-AZ PaaS
S3 Stockage des fichiers moodledata IaaS
Elastic Load Balancer Répartition du trafic HTTPS IaaS
(ELB)
Auto Scaling Création automatique d'instances EC2 IaaS
selon la charge
CloudFront CDN pour les contenus statiques (CSS, JS, IaaS
images)
Route 53 DNS et health checks IaaS
VPC Réseau privé virtuel avec sous-réseaux IaaS
publics/privés
IAM Gestion des accès (rôles EC2, utilisateurs IaaS
admins)

12.5 Diagramme UML de déploiement (Moodle HA sur AWS)

[Internet]
│
┌─────────▼─────────┐
│ Route 53 (DNS) │
│ (Health Check) │
└─────────┬─────────┘
│
┌─────────▼─────────┐
│ CloudFront (CDN) │
│ (HTTPS/SSL) │
└─────────┬─────────┘
│
┌─────────▼─────────┐
│ Elastic Load │
│ Balancer (ALB) │
│ (HTTPS:443) │
└────┬──────────┬───┘
│ │
┌────────────▼──┐ ┌────▼────────────┐
│ EC2 Instance │ │ EC2 Instance │
│ (Zone A) │ │ (Zone B) │
│ Apache+PHP │ │ Apache+PHP │
│ + Moodle │ │ + Moodle │
 │ (Auto Scaling)│ │ (Auto Scaling) │
└──────┬────────┘ └────────┬────────┘
│ │
└─────────┬──────────┘
│
┌─────────▼──────────┐
│ Amazon RDS │
│ (Multi-AZ) │
│ Primary (Zone A) │
│ Standby (Zone B) │
└──────────────────────┘
│
┌─────────▼──────────┐
│ Amazon S3 │
│ (moodledata) │
│ Réplication │
│ automatique │
└──────────────────────┘

12.6 Déploiement sur Microsoft Azure (Projet TS STIC 2)

Basé sur le rapport du Groupe 3 (TS INFO 2), voici la procédure opérationnelle :

Étape 1 : Création du compte et ressources

Créer un compte étudiant Azure (crédit 100$).

Créer un Groupe de ressources (ex: Moodle_ressources ).
Créer une Machine Virtuelle :
OS : Ubuntu 20.04 LTS
RAM : 1 Go minimum (2 Go recommandé pour production)
Disque : 16 Go minimum
Ports ouverts : SSH (22), HTTP (80), HTTPS (443)
Région : Afrique du Sud Nord (ou Europe Ouest pour meilleure latence depuis la CI)

Étape 2 : Connexion et préparation

ssh utilisateur3@[Link]
sudo su
passwd # Définir le mot de passe root

Étape 3 : Installation du stack LAMP

 # Mise à jour
sudo apt update && sudo apt upgrade -y

# Apache
sudo apt install -y apache2

# MariaDB (MySQL compatible)

sudo apt install -y mariadb-server
sudo mysql_secure_installation

# Création de la base Moodle

sudo mysql -u root -p
CREATE DATABASE moodle DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'moodleuser'@'localhost' IDENTIFIED BY 'MotDePasseFort';
GRANT ALL PRIVILEGES ON moodle.* TO 'moodleuser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

# PHP 7.4 et extensions

sudo apt install -y php7.4 php7.4-common php7.4-mysql php7.4-xml php7.4-xmlrpc
php7.4-curl php7.4-gd php7.4-imagick php7.4-cli php7.4-dev php7.4-imap php7.4-
mbstring php7.4-opcache php7.4-soap php7.4-zip php7.4-intl imagemagick git zip
libgd-dev libapache2-mod-php

Étape 4 : Téléchargement et configuration de Moodle

cd /var/www/html
sudo git clone [Link]
sudo chown -R www-data:www-data /var/www/html/moodle
sudo chmod -R 755 /var/www/html/moodle

# Créer le répertoire moodledata

sudo mkdir /var/moodledata
sudo chown -R www-data:www-data /var/moodledata
sudo chmod -R 777 /var/moodledata # En production, utiliser 755 avec ACLs

Étape 5 : Configuration Apache

sudo nano /etc/apache2/sites-available/[Link]

Contenu :
 <VirtualHost *:80>
ServerName [Link]
DocumentRoot /var/www/html/moodle
<Directory /var/www/html/moodle>
Options FollowSymLinks
AllowOverride All
Require all granted
</Directory>
</VirtualHost>

sudo a2ensite [Link]

sudo a2enmod rewrite
sudo systemctl restart apache2

Étape 6 : Fichier de configuration Moodle ( [Link] )

Après l'installation web, Moodle génère un fichier [Link] dans /var/www/html/moodle/
contenant :

<?php
unset($CFG);
global $CFG;
$CFG = new stdClass();
$CFG->dbtype = 'mariadb';
$CFG->dblibrary = 'native';
$CFG->dbhost = 'localhost';
$CFG->dbname = 'moodle';
$CFG->dbuser = 'moodleuser';
$CFG->dbpass = 'MotDePasseFort';
$CFG->prefix = 'mdl_';
$CFG->dboptions = array (
'dbpersist' => false,
'dbport' => '',
'dbsocket' => '',
'dbssl' => '',
'dbsslca' => '',
'dbsslcert' => '',
'dbsslkey' => '',
'dbsslverifyservercert' => false,
);
$CFG->wwwroot = '[Link]
$CFG->dataroot = '/var/moodledata';
$CFG->admin = 'admin';
 $CFG->directorypermissions = 0777;
require_once(__DIR__ . '/lib/[Link]');

Nuance Azure spécifique : Avec 1 Go de RAM, Moodle tourne mais peine sous charge.
Pour un usage académique réel, prévoir au minimum 2 Go + swap, ou utiliser Azure
Database for MySQL (PaaS) pour décharger la base de données de la VM.

12.7 Procédure de résolution d'incident (Moodle indisponible)

Étape 1 : Diagnostic (quoi ? où ?)

Console AWS CloudWatch / Azure Monitor : vérifier CPU, mémoire, statut des instances.
Vérifier le statut RDS / Azure Database : "Available" ? "Failed" ?
Logs Apache sur la VM : /var/log/apache2/[Link]
Tester la connectivité réseau : ping , curl -I [Link]

Étape 2 : Identification de la cause racine

EC2/VM arrêtée : panne système, disque plein, surcharge mémoire (OOM killer).
Apache down : erreur de configuration, conflit de ports, crash PHP.
RDS/BDD inaccessible : saturation des connexions, maintenance planifiée, panne AZ.
Disque plein : logs non rotatés, moodledata ayant dépassé la capacité EBS/Disk.
Pic de trafic : DDoS légitime (rentrée universitaire) sans Auto Scaling configuré.

Étape 3 : Actions correctives

VM crashée : l'Auto Scaling doit démarrer une nouvelle instance. Si absent, restaurer
depuis un snapshot ou relancer manuellement.
Apache arrêté : sudo systemctl restart apache2 ; investiguer l'erreur dans les logs.
BDD saturée : augmenter la classe d'instance ou activer le read replica.
Disque plein : nettoyer les caches Moodle, augmenter le volume, ou migrer moodledata
vers S3/Azure Blob.
Pic de trafic : vérifier les règles Auto Scaling, ajuster les seuils (CPU > 70% = +1 instance).

Étape 4 : Prévention (PCA/PRA)

Activer Multi-AZ sur la base de données (failover automatique).

Configurer des alarmes (CPU > 80%, disque > 85%, 5xx HTTP).
Sauvegardes automatiques (snapshots quotidiens, rétention 7-30 jours).
Tester régulièrement les procédures de reprise (exercice de Disaster Recovery).
13. Correction complète et harmonisée des exercices
13.1 TD 2023-2024 — Questions de cours
Q1. Qu'est-ce qu'un système d'information, un système informatique, le Cloud
Computing ?

Système d'information : Ensemble organisé de ressources permettant de collecter,

stocker, traiter et diffuser l'information. Dimension organisationnelle.
Système informatique : Infrastructure technique (hardware, software, réseaux) supportant
le SI.
Cloud Computing : Modèle de fourniture de ressources informatiques à la demande via
Internet, avec paiement à l'usage.

Q2. Définir le Big Data.

Données caractérisées par les 5V (Volume, Vélocité, Variété, Valeur, Véracité) dont le
traitement dépasse les capacités des outils traditionnels. Nécessite des architectures
distribuées (Hadoop, Spark) et le Cloud pour l'élasticité.

Q3. Différence entre base de données et data center.

Base de données : Logiciel de stockage structuré (MySQL, Oracle).

Data Center : Infrastructure physique (bâtiment, serveurs, climatisation).

Analogie : La BDD est le livre ; le Data Center est la bibliothèque.

Q4. Donner 4 fournisseurs de services cloud.

1. Amazon Web Services (AWS)

2. Microsoft Azure
3. Google Cloud Platform (GCP)
4. OVHcloud (ou IBM Cloud, Salesforce, MTN Cloud, Orange Cloud)

Q5. Pourquoi les entreprises hésitent à adopter le cloud ?

Sécurité et confidentialité : peur de perdre le contrôle des données sensibles.

Dépendance au fournisseur (vendor lock-in) : difficulté à migrer ensuite.
Conformité réglementaire : RGPD, lois de souveraineté des données (ex: données
bancaires locales).
Latence réseau : en Afrique, la connectivité internationale peut être instable.
Culture interne : résistance au changement, manque de compétences Cloud.
Coûts cachés : transfert de données, sortie de données (egress fees), surconsommation.
Q6. Qui sont les gros consommateurs du cloud ? En expliquer les raisons.

GAFAM et grandes entreprises tech : besoin de scalabilité massive, de calcul distribué

(IA, streaming).
Startups : pas de CAPEX, déploiement rapide, focus sur le produit.
Banques et assurances : analytics, conformité, reprise après sinistre.
Secteur santé : stockage d'imagerie médicale, télémédecine.
Éducation : plateformes e-learning (Moodle, MOOCs), collaboration.

Raison commune : Besoin d'élasticité, de résilience et de réduction des coûts

d'infrastructure.

Q7. Différence entre un administrateur On-Premises et un administrateur Cloud.

(Voir section 11.1 ci-dessus.)

Q8. C'est quoi la haute disponibilité ? La sauvegarde ? La restauration ?

Haute disponibilité : Capacité à rester opérationnel malgré les pannes (SLA 99,9%+).
Sauvegarde : Copie de données à un instant T pour protection.
Restauration : Reconstitution des données à partir d'une sauvegarde après incident.

Q9. Différence entre scalabilité verticale et horizontale avec exemples.

Scale Up (Vertical) : Augmenter la puissance d'une machine existante (plus de RAM, CPU,
disque).
Exemple : Passer une VM AWS de [Link] (2 vCPU, 4 Go) à [Link] (2 vCPU, 8
Go).
Limite : Plafond matériel de la machine physique ; temps d'arrêt souvent nécessaire.
Scale Out (Horizontal) : Ajouter des machines supplémentaires pour répartir la charge.
Exemple : Passer de 2 serveurs web à 5 serveurs web derrière un load balancer.
Avantage : Pas de limite théorique ; tolérance aux pannes accrue ; aligné avec l'auto-
scaling Cloud.

13.2 TD 2023-2024 — Amazon Web Services

Q1. Comment sont nommés les trois modèles de déploiement chez AWS ?
AWS organise ses modèles de déploiement en :

1. Cloud Public (services accessibles via Internet, infrastructure mutualisée)

2. Cloud Privé (VPC isolé, Direct Connect dédié, Outposts pour on-premise)
3. Cloud Hybride (combinaison des deux, avec AWS Outposts, Storage Gateway, VMware
Cloud on AWS)
 Nuance : Le NIST définit 4 modèles (public, privé, hybride, communautaire). AWS
commercialement met l'accent sur les 3 premiers.

Q2. Dans chaque catégorie, identifier les principaux produits AWS.

Catégorie Produits principaux Modèle

Calcul EC2 (VMs), Lambda (serverless), ECS/EKS (conteneurs), IaaS/PaaS
Elastic Beanstalk (PaaS)
Mise en VPC (réseau privé), ELB/ALB (load balancing), Route 53 IaaS
réseau (DNS), API Gateway
Sécurité IAM (identité), KMS (chiffrement), WAF (pare-feu web), Shield IaaS/SaaS
(DDoS), GuardDuty (threat detection)
Stockage S3 (objet), EBS (bloc), EFS (fichier), Glacier (archivage) IaaS
Base de RDS (relationnelle gérée), DynamoDB (NoSQL), Redshift PaaS
données (data warehouse), ElastiCache (cache)

Q3. Dans chaque modèle de service (IaaS, PaaS, SaaS), identifier les principaux produits
AWS.

Modèle Produits AWS

IaaS EC2, EBS, S3, VPC, ELB, Route 53
PaaS Elastic Beanstalk, RDS, EMR, Lambda, API Gateway, SageMaker
SaaS Amazon WorkMail, Amazon Chime, AWS IQ (marketplace expert)

13.3 Devoir 11 Février 2025 — Correction intégrée

Exercice I : Culture générale (5 pts)

1/ Expliquer le concept de traitement de données en mode batch et en (presque) temps

réel.
(Voir section 8.3 ci-dessus pour la comparaison détaillée.)

Réponse synthétique :

Batch : Traitement de volumes massifs de données déjà stockées, par lots, avec une
latence de minutes à heures. Exemple : calcul mensuel de la paie, bilan comptable
nocturne avec Hadoop MapReduce.
 Temps réel (Stream) : Traitement continu des données au fur et à mesure de leur arrivée,
latence de millisecondes à secondes. Exemple : détection de fraude bancaire immédiate,
alertes capteurs IoT via Apache Kafka + Spark Streaming.

2/ Donner 6 services cloud proposés par AWS.

1. Amazon EC2 — Serveurs virtuels élastiques (IaaS)

2. Amazon S3 — Stockage objet illimité (IaaS)
3. Amazon RDS — Bases de données relationnelles gérées (PaaS)
4. AWS Lambda — Calcul serverless (FaaS/PaaS)
5. Amazon VPC — Réseau privé virtuel (IaaS)
6. AWS IAM — Gestion des identités et accès (IaaS)
(Autres valides : CloudFront, Route 53, DynamoDB, Elastic Beanstalk, SageMaker, etc.)

3/ Orange CI souhaite faire la maintenance préventive de ses pylônes. Collecte de

données IoT : démarche.

Démarche opérationnelle :

1. Choix des capteurs : Capteurs de vibration, température, inclinomètres, caméras

thermiques sur chaque pylône.
2. Connectivité : Transmission via réseau cellulaire (4G/5G Orange) ou LoRaWAN pour
zones isolées.
3. Ingestion Cloud : Utilisation d'Azure IoT Hub ou AWS IoT Core pour collecter les flux de
données sécurisés (MQTT/HTTPS).
4. Stockage :
Temps réel : Données de vibration critique stockées dans une base de séries
temporelles (InfluxDB, Amazon Timestream).
Batch : Données historiques dans un Data Lake (S3, Azure Data Lake) pour analyse
de tendances.
5. Traitement et analyse :
Temps réel : Alertes immédiates si vibration anormale (seuil dépassé) via AWS Lambda
ou Azure Functions.
Batch : Modèles de Machine Learning (SageMaker, Azure ML) pour prédire la corrosion
ou la fatigue métallique.
6. Visualisation : Tableaux de bord Grafana ou Power BI pour les équipes de maintenance.
7. Action : Génération automatique d'ordres de maintenance préventive dans le SI de Orange
CI.

Lien métier : La maintenance préventive réduit les pannes coûteuses et améliore la qualité
de service réseau.
4/ Cas Paypal / Google Cloud : Qui apporte le plus d'avis sur le choix ?

Réponse : d) Data Architect

Justification détaillée :
Le Data Architect est le professionnel chargé de concevoir l'architecture globale de gestion
des données. Pour un acteur comme PayPal (300 millions de clients, 100 devises, 200
marchés), il évalue :

La scalabilité : capacité à absorber un milliard de transactions/jour.

La latence : temps de réponse pour les paiements en ligne (< 200ms).
La conformité : PCI-DSS pour les paiements, RGPD pour les données européennes, lois
locales de souveraineté des données.
Le coût total de possession (TCO) : comparaison fine entre solutions Cloud (Google
Cloud, AWS, Azure).
La résilience : architecture multi-régions, stratégie de reprise après sinistre.

Pourquoi pas les autres ?

Product Owner : définit les besoins fonctionnels mais n'a pas la compétence technique
pour comparer les plateformes.
Administrateur Système : gère l'opérationnel, pas la stratégie d'architecture globale.
Data Engineer : implémente les pipelines mais ne choisit pas la plateforme globale ; il
exécute la vision de l'architecte.

Exercice II : Étude de cas — Startup IaaS/PaaS/SaaS (5 pts)

Contexte : NANCY, MARIE, OSEE et SIBAH veulent créer une startup offrant des services
IaaS, PaaS, SaaS.

1/ Caractéristiques essentielles pour être un fournisseur cloud sérieux.

Pour être reconnu comme fournisseur crédible, la startup doit implémenter les 5
caractéristiques NIST :

1. Libre-service à la demande : Console web/API permettant au client de provisionner seul.

2. Large accès réseau : Disponibilité via Internet avec des protocoles standard
(HTTP/HTTPS, API REST).
3. Mise en commun des ressources : Architecture multi-tenant isolant les clients
(virtualisation, containers).
4. Élasticité rapide : Capacité à augmenter/réduire les ressources automatiquement.
5. Service mesuré : Facturation granulaire (à la seconde, au Go, au requête) avec tableaux
de bord de consommation.
Compléments stratégiques :

Sécurité certifiée : ISO 27001, SOC 2, conformité RGPD.

SLA garantis : Engagement de disponibilité (99,9% minimum) avec pénalités.
Support technique : Hotline, documentation, communauté.
Inter-cloud : APIs ouvertes évitant le lock-in.

2/ Avis sur l'aménagement d'un Data Center.

Analyse critique :
L'affirmation "avoir les moyens pour l'aménagement d'un Data Center" est insuffisante pour
justifier la construction d'un Data Center propre.

Arguments contre (nuancés) :

CAPEX massif : Construction, climatisation, onduleurs, sécurité physique, bande passante

fibre. L'amortissement prend 5 à 10 ans.
Compétences rares : Ingénieurs datacenter, techniciens réseau, experts sécurité
physique. Une startup de 4 personnes ne couvre pas ces besoins.
Délai : 12 à 24 mois pour construire et certifier un DC.
Scalabilité limitée : En cas de succès brutal, le DC privé sera sous-dimensionné. Le Cloud
public offre l'élasticité immédiate.

Arguments pour (cas spécifiques) :

Si les clients cibles sont des banques ou ministères exigeant la souveraineté des
données (ex: Côte d'Ivoire, données fiscales).
Si la startup vise un Cloud Communautaire régional avec un avantage compétitif sur la
latence.

Conseil : Pour une startup, le modèle Cloud Hybride ou Revendeur/Partenaire est plus sage
: louer de l'espace dans un datacenter tiers (colocation) ou utiliser un hyperscaler (AWS, Azure)
en marque blanche, plutôt que construire un DC from scratch.

Exercice III : Étude de cas — Netflix (5 pts)

Contexte : Netflix, 190 pays, 158 millions de membres, leader du streaming.

a) Modèle de déploiement de la solution cloud que Netflix doit utiliser.

Réponse : Cloud Public (principalement AWS).

Justification : Netflix a besoin d'une scalabilité quasi infinie pour absorber les pics de
visionnage (soirée, week-end, sortie d'une série). Le Cloud Public offre cette capacité sans
investissement initial. Néanmoins, Netflix utilise aussi des CDN privés (Open Connect
 Appliances) placés chez les FAI pour réduire la latence — ce qui constitue une touche
hybride.

b) Modèle de service correspondant aux ressources utilisées par Netflix.

Réponse : Principalement IaaS et PaaS.

Détail : Netflix utilise des milliers d'instances EC2 (IaaS), du stockage S3 (IaaS), de la base
de données DynamoDB (PaaS), du Big Data EMR (PaaS), du machine learning SageMaker
(PaaS). Ils ne consomment pas de SaaS pour leur cœur de métier ; ils construisent leur
propre plateforme sur l'infrastructure AWS.

c) Deux avantages de l'utilisation du cloud pour ce type d'entreprise.

1. Élasticité extrême : Passer de milliers à dizaines de milliers de serveurs en minutes lors

du lancement d'une série (ex: Squid Game), puis réduire. Paiement uniquement pour
l'usage réel.
2. Disponibilité mondiale et basse latence : Réplication multi-régions (AWS Regions dans
le monde entier) + CDN (CloudFront) pour servir les vidéos depuis le point d'accès le plus
proche, garantissant une expérience fluide.

Exercice IV : Pratique avec AWS — Moodle indisponible (10 pts)

Contexte : Moodle déployé sur AWS est indisponible.

1/ Diagramme de déploiement de Moodle sur AWS avec haute disponibilité (PCA).

(Voir section 12.5 ci-dessus pour le diagramme UML complet avec Route 53, CloudFront, ELB,
EC2 Multi-AZ, RDS Multi-AZ, S3.)

2/ Démarche de résolution de l'indisponibilité.

(Voir section 12.7 ci-dessus pour la procédure complète en 4 étapes : Diagnostic, Identification,
Actions correctives, Prévention.)

3/ Le client souhaite changer de base de données. Quel fichier modifier ?

Réponse : Le fichier [Link] situé à la racine du répertoire Moodle
( /var/www/html/moodle/[Link] ou équivalent).

Paramètres à modifier :

$CFG->dbtype = 'nouveau_type'; // ex: 'pgsql' pour PostgreSQL

$CFG->dbhost = 'nouveau_host'; // ex: '[Link]'
$CFG->dbname = 'nouvelle_base';
$CFG->dbuser = 'nouvel_utilisateur';
$CFG->dbpass = 'nouveau_mot_de_passe';
$CFG->prefix = 'mdl_'; // Peut rester identique
 Nuance opérationnelle : Avant de modifier [Link] , il faut :

1. Sauvegarder la base actuelle (dump SQL) et le fichier [Link] .

2. Vérifier la compatibilité : Moodle supporte MySQL/MariaDB, PostgreSQL, SQL Server,
Oracle. Pas tous les SGBD.
3. Migrer les données : Importer l'ancienne base dans la nouvelle structure (outils comme
moodle-database-transfer ou scripts ETL).
4. Tester sur un environnement de staging avant production.
5. Vider les caches Moodle ( moodledata/cache ) après changement.

13.4 Examen 2022-2023 — Correction intégrée

Partie Cours (10 points)

Q1. Définir Big Data, Data Center, Data Lake, Data Lab, Cloud Computing.
(Voir sections 2.2, 2.3, 2.4, 2.5, 2.1 ci-dessus pour les définitions complètes et nuancées.)

Q2. Que signifient IaaS, SaaS, PaaS, DaaS ? Exemples.

(Voir section 5.2 à 5.5 ci-dessus.)

Q3. Traitement batch vs temps réel.

(Voir section 8.3 ci-dessus.)

Q4. Deux services Microsoft.

1. Azure Virtual Machines (IaaS) : VMs scalables dans le Cloud Azure.

2. Azure SQL Database (PaaS) : base relationnelle gérée, backups automatiques, patching.
(Autres réponses valides : Office 365, Azure Blob Storage, Azure Active Directory, Azure
DevOps...)

Q5. Deux services Google.

1. Google Compute Engine (IaaS) : machines virtuelles.

2. Google BigQuery (PaaS/SaaS) : entrepôt de données analytiques serverless, requêtes
SQL sur des pétaoctets en secondes.
(Autres : Cloud Storage, App Engine, Kubernetes Engine, Google Workspace...)

Q6. Deux services AWS.

1. Amazon EC2 (IaaS) : serveurs virtuels élastiques.

2. Amazon RDS (PaaS) : bases de données relationnelles gérées (MySQL, PostgreSQL,
Oracle, SQL Server, MariaDB).
QCM (10 points) — Réponses justifiées

Q1. Qu'est-ce que le Cloud Computing ?

✅ b) Une méthode de stockage de données (réponse attendue par le cours, bien que
simplificatrice).

Nuance : Le Cloud est bien plus qu'un stockage — c'est un modèle de fourniture de calcul,
réseau et applications. Cependant, parmi les choix proposés, b) est la moins inexacte. a)
(progiciel) et c) (gestion d'applications en entreprise) sont incorrects.

Q2. Plate-forme d'exécution, de déploiement et de développement.

✅ b) PaaS
Le PaaS fournit précisément l'environnement de développement + runtime + middleware.
L'IaaS ne fournit que l'infrastructure ; le SaaS ne permet pas de développer des
applications personnalisées.

Q3. Externaliser serveurs, réseau, stockage ; démarrer/arrêter des VMs.

✅ a) IaaS
L'IaaS abstrait le Data Center physique. L'entreprise gère des VMs sans posséder de
matériel. Le PaaS va plus loin (middleware, runtime) ; le SaaS encore plus (applications
complètes).

Q4. Couche applicative (CRM, RH, comptabilité, messagerie...).

✅ c) SaaS
Le SaaS = "tout inclus". L'utilisateur consomme une application hébergée et maintenue par
le fournisseur. Exemples : Salesforce (CRM), SAP (ERP), Office 365 (bureautique).

Q5. Partie publique, partie interne pour données critiques.

✅ c) Cloud hybride
Définition exacte du cloud hybride : combinaison de cloud public (workloads standards) et
cloud privé (données critiques). Le cloud communautaire (b) implique plusieurs
organisations partageant la même infrastructure.

Q6. Infrastructure hébergée à l'extérieur de l'entreprise.

✅ a) Cloud public
Cloud public = infrastructure externe, partagée, gérée par un fournisseur tiers. Les données
sont hébergées sur des serveurs mutualisés.

Q7. Infrastructure hébergée à l'intérieur de l'entreprise.

✅ b) Cloud privé
 Cloud privé = infrastructure dédiée, hébergée en interne (ou chez un prestataire dédié).
Données sur infrastructure non partagée.

Q8. Méthodes NIST de classification.

✅ b) Modèles de déploiement et d) Modèles de service
Le NIST classe le Cloud selon : caractéristiques essentielles, modèles de service (IaaS,
PaaS, SaaS) et modèles de déploiement (public, privé, hybride, communautaire). Les
"fournisseurs" et "OPEX/CAPEX" ne sont pas des classifications NIST.

Q9. Éléments proposés par le fournisseur PaaS.

✅ b) Système d'exploitation, d) Couche de virtualisation, e) Outils de développement
En PaaS, le fournisseur gère : infrastructure physique, virtualisation, OS, middleware,
runtime ET fournit les outils de développement. Le client gère ses applications (a) et ses
données. Le matériel informatique (c) est géré par le fournisseur mais n'est pas "proposé"
en tant que service direct au client — il est transparent.

⚠️ Clarification importante : Dans le QCM original, l'option (a) "Application" est

techniquement gérée par le client en PaaS, pas par le fournisseur. Si l'énoncé du QCM
visait "éléments gérés/proposés par le fournisseur", la réponse correcte stricte est b, d, e (et
c en arrière-plan). Cependant, selon la logique du cours, les réponses attendues sont b, d,
e.

Q10. Modèles de service décrits par NIST.

✅ b) SaaS, IaaS, PaaS
Le NIST définit officiellement trois modèles de service : IaaS, PaaS, SaaS. XaaS (a, d) est
une extension marketing informelle. Privé/public/hybride (c) sont des modèles de
déploiement.

13.5 Examen de Rattrapage 2022-2023 — Correction

Q1. Définir haute disponibilité, PRA, PCA.
(Voir section 10 ci-dessus.)

Q2. Deux services Microsoft.

1. Azure Virtual Machines (IaaS)

2. Microsoft Office 365 (SaaS)

Q3. Deux services MTN Cloud.

 1. MTN Cloud Hosting (IaaS — serveurs virtuels)
2. MTN Cloud Storage (IaaS — stockage objet)

Nuance : L'offre MTN Cloud varie selon les pays africains. Toute réponse décrivant une
offre IaaS ou SaaS de MTN est acceptée.

Q4. Deux services AWS.

1. Amazon EC2 (IaaS)

2. Amazon S3 (IaaS — stockage objet)

Q5. Cas Paypal/Google Cloud — Qui apporte le plus d'avis sur le choix ?
✅ d) Data Architect
Justification détaillée : Le Data Architect est le professionnel chargé de concevoir
l'architecture globale de gestion des données. Il évalue la scalabilité (300 millions de clients,
100 devises, 200 marchés), la latence, la conformité réglementaire (PCI-DSS pour les
paiements) et le coût total de possession (TCO) de chaque solution Cloud. C'est le seul
métier à avoir la vision transverse métier + technique + financière pour ce type de décision
stratégique.

Le Product Owner définit les besoins fonctionnels mais n'a pas la compétence
technique pour comparer les plateformes.
L'Administrateur Système gère l'opérationnel, pas la stratégie.
Le Data Engineer implémente les pipelines mais ne choisit pas la plateforme globale.

Étude de cas 1 (WordPress) et 2 (IoT) : Voir sections 13.6 et 13.7 ci-dessous.

13.6 Exercice WordPress — Hébergement selon IaaS, PaaS, SaaS

Énoncé : Héberger une application WordPress (Serveur Web, PHP, SGBD) selon IaaS, PaaS,
SaaS.

🔷 IaaS — "Je construis tout"

Le fournisseur vous donne une machine virtuelle vierge avec un OS de base (ex: Ubuntu
22.04 sur AWS EC2).

Procédure explicite :
 1. Connexion SSH : ssh -i ma_cle.pem ubuntu@mon_ip
2. Mise à jour système : sudo apt update && sudo apt upgrade -y
3. Installation du stack LAMP :
Apache : sudo apt install apache2
MariaDB : sudo apt install mariadb-server
PHP + extensions : sudo apt install php php-mysql php-curl php-gd php-mbstring
php-xml php-zip
4. Sécurisation de MariaDB : sudo mysql_secure_installation
5. Création de la base WordPress :

CREATE DATABASE wordpress_db;

CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'MotDePasseFort';
GRANT ALL PRIVILEGES ON wordpress_db.* TO 'wp_user'@'localhost';
FLUSH PRIVILEGES;

6. Téléchargement de WordPress, configuration de [Link] (clés de salage,

paramètres DB).
7. Configuration du Virtual Host Apache ( /etc/apache2/sites-available/[Link] ).
8. Activation HTTPS (Let's Encrypt via Certbot).
9. Maintenance continue : patches OS, mises à jour WordPress, sauvegardes manuelles.

Responsabilité : Client = OS, middleware, runtime, application, données, sécurité applicative.

🔷 PaaS — "Je développe et déploie"

Le fournisseur vous donne un environnement LAMP préconfiguré et managé (ex: Heroku
PHP, OVH Web Hosting, AWS Elastic Beanstalk).

Procédure explicite :

1. Créer un environnement PaaS via la console web.

2. Créer une base de données associée (souvent managée, ex: ClearDB MySQL sur Heroku,
ou RDS via Elastic Beanstalk).
3. Télécharger WordPress en local.
4. Configurer [Link] avec les variables d'environnement fournies (host DB, user,
password).
5. Déployer via Git ( git push heroku main ) ou FTP/SFTP.
6. Lancer l'assistant WordPress ( wp-admin/[Link] ).
7. Le PaaS gère : mises à jour OS, patches sécurité Apache/PHP, scaling horizontal (si
configuré).
Responsabilité : Client = application WordPress + données. Fournisseur = OS, middleware,
runtime.

🔷 SaaS — "Je configure et j'utilise"

[Link] (ou Wix, Squarespace) propose WordPress en tant que service fini.

Procédure explicite :

1. Créer un compte sur [Link]

2. Choisir un plan (gratuit ou payant avec domaine personnalisé).
3. Sélectionner un thème visuel.
4. Configurer les pages, les menus, les plugins autorisés.
5. Publier du contenu (articles, pages, médias).

Responsabilité : Client = contenu + configuration du site. Fournisseur = TOUT le reste

(hébergement, maintenance, mises à jour, sécurité, backups).

📊 Synthèse comparative WordPress

Modèle Votre niveau d'effort Votre niveau de contrôle Exemple

SaaS Très faible (configuration Très faible (thèmes/plugins [Link]
uniquement) limités)
PaaS Moyen (installation + Moyen (accès au code, pas Heroku, Elastic
configuration) au serveur) Beanstalk
IaaS Élevé (installation Total (OS, sécurité, AWS EC2, Azure VM
complète) performance)

13.7 Exercice IoT — Gestion des données selon IaaS, PaaS, SaaS
Énoncé : Gérer les données collectées via des objets connectés (ville connectée, robots) selon
IaaS, PaaS, SaaS.

🔷 IaaS — "Je construis ma plateforme Big Data from scratch"

Architecture :

1. Provisionner des VMs EC2 (ou Azure VM) avec CPU, RAM et disque importants.
2. Installer manuellement un cluster Hadoop : HDFS (stockage distribué), YARN (gestion
des ressources), MapReduce (traitement).
3. Déployer Apache Kafka sur des VMs dédiées pour l'ingestion des flux IoT.
4. Configurer ZooKeeper pour la coordination du cluster Kafka.
5. Développer des jobs MapReduce ou Spark pour le traitement batch des données
historiques.
6. Gérer soi-même la haute disponibilité (réplication HDFS, backups), la scalabilité (ajout
manuel de nœuds) et la sécurité (firewall, chiffrement).

Responsabilité : L'entreprise gère l'intégralité de la chaîne : ingestion, stockage, traitement,

analyse, sécurité.

Nuance : Cette approche offre un contrôle total mais demande une expertise rare
(administrateurs Hadoop, ingénieurs réseau) et un temps de mise en production long
(semaines).

🔷 PaaS — "Je me concentre sur les données, pas sur l'infrastructure"

Architecture :

1. Amazon Kinesis (ou Azure Event Hubs, Google Pub/Sub) : ingestion et traitement des flux
IoT en temps réel, managé.
2. Amazon EMR (Elastic MapReduce) : cluster Hadoop/Spark managé — vous choisissez le
nombre de nœuds, AWS gère l'installation et la maintenance.
3. Amazon S3 : stockage des données brutes (Data Lake) avec durabilité 99,999999999%.
4. AWS Glue : ETL (Extract, Transform, Load) serverless pour préparer les données.
5. Amazon Athena ou Redshift Spectrum : analyse SQL directe sur S3 sans serveur.
6. L'équipe de l'entreprise développe uniquement les jobs Spark/Hive et les tableaux de bord.

Responsabilité : L'entreprise gère les pipelines de données et la logique métier ; AWS gère
l'infrastructure sous-jacente.

Nuance : C'est l'approche la plus courante aujourd'hui. Elle équilibre contrôle (vous écrivez
le code) et productivité (pas de gestion de cluster).

🔷 SaaS — "Je consomme des insights"

Architecture :
L'entreprise utilise des solutions analytiques clé en main où même la logique d'analyse est pré-
construite.

Exemples :

Microsoft Azure IoT Hub + Power BI : connecter les appareils, visualiser les métriques en
temps réel.
IBM Watson IoT Platform : gestion des appareils, analyse prédictive (maintenance
prédictive des robots).
Google Looker / Tableau Online : connexion aux sources de données, création de
dashboards sans écrire de code d'infrastructure.
Salesforce IoT Cloud : orchestration des actions métier basées sur les événements IoT.

Procédure :

1. Souscrire au service SaaS.

2. Configurer les connecteurs IoT (protocoles MQTT, HTTP, CoAP).
3. Mapper les données entrantes aux modèles de l'outil.
4. Configurer les alertes et les dashboards.
5. Consommer les rapports et les notifications.

Responsabilité : L'entreprise configure les sources et consomme les résultats. Tout le reste
est opaque et géré par le fournisseur.

Nuance : Rapide à mettre en œuvre (jours), mais peu flexible. Si l'outil ne supporte pas
votre protocole IoT propriétaire, vous êtes bloqué.

📊 Synthèse comparative IoT

Modèle Effort Contrôle sur la Temps de mise Compétences

technique chaîne en œuvre requises
IaaS Très élevé Total Semaines Hadoop, Kafka,
Linux, réseau
PaaS Moyen Logique métier + Jours/semaines Spark, SQL, data
pipelines engineering
SaaS Faible Configuration Jours Connaissance métier,
métier uniquement paramétrage
13.8 Examen 2023-2024 — Correction intégrée
Cours (8 points)

Q1 à Q3 : Voir sections 2 et 8 ci-dessus.

Q4. Deux services Microsoft.

1. Azure Virtual Machines (IaaS)

2. Azure SQL Database (PaaS géré)

Q5. Deux services AWS.

1. Amazon EC2 (IaaS)

2. Amazon RDS (PaaS — base de données relationnelle gérée)

Étude de cas 1 — Moodle indisponible (6 points)

Q1. Services AWS pour Moodle.

(Voir section 12.4 ci-dessus.)

Q2. Diagramme de déploiement UML.

(Voir section 12.5 ci-dessus.)

Q3. Démarche de résolution.

(Voir section 12.7 ci-dessus.)

Étude de cas 2 — Gestion données IoT

(Voir section 13.7 ci-dessus.)

14. Projets TS STIC 2 : orientations techniques

Voici les orientations techniques pour les 10 projets proposés en 2023-2024 :

1. Application web/mobile de gestion des diplômés (NoSQL)

Stack suggéré :

Frontend : React / Flutter

Backend : [Link] / Python Flask
BDD NoSQL : MongoDB Atlas (PaaS) ou DynamoDB (AWS) ou Cosmos DB (Azure)
 Cloud : Heroku (PaaS) ou AWS Elastic Beanstalk

2. Application e-commerce (NoSQL)

Stack suggéré :

BDD : MongoDB (catalogue produits flexibles) ou Firebase (temps réel pour panier)
Stockage images : S3 / Azure Blob
Paiement : Intégration API Stripe ou PayPal

3. Collecte et visualisation de données IoT (Azure IoT / AWS IoT)

Architecture :

Capteurs → Azure IoT Hub / AWS IoT Core → Stream Analytics → Power BI / Grafana
Stockage historique : Azure Data Lake / S3 + Athena

4. Analyse et tests de sécurité dans le cloud

Méthodologie :

Scan de vulnérabilités : Nessus, OpenVAS sur une VM Cloud

Test d'intrusion (éthique) : Kali Linux sur EC2 ciblant une VPC isolée
Audit IAM : AWS IAM Analyzer, Azure AD logs
Chiffrement : Test de chiffrement S3, EBS, Azure Disk Encryption

5. Refonte visuelle d'une plateforme Moodle dans le cloud

Approche :

Thème Moodle personnalisé (Mustache/SCSS)

Déploiement sur Azure VM (rapport Groupe 3) ou AWS EC2
CDN CloudFront/Azure CDN pour les assets du thème
Haute disponibilité : RDS Multi-AZ + S3 pour moodledata

6. Détecteur de présence (AWS/Azure)

Architecture :

Capteur PIR / RFID / Caméra → Raspberry Pi → AWS IoT Greengrass / Azure IoT Edge
Traitement : Lambda / Azure Functions pour alerte email/SMS
Dashboard : Temps réel avec WebSocket

7. MySQL en haute disponibilité sur AWS (sans PaaS, avec EC2)

Contrainte : Pas de RDS. Utiliser EC2 uniquement.
Solution :

2 instances EC2 Ubuntu avec MySQL Community

Réplication Master-Slave (ou Master-Master avec Galera)
Virtual IP (VIP) avec Keepalived pour failover automatique
EBS gp3 pour disques performants
Backup : Scripts cron + S3

8. Migration d'une plateforme Moodle dans le cloud

Plan de migration (Lift & Shift puis optimisation) :

1. Audit de l'existant (version Moodle, PHP, base de données, taille moodledata)

2. Provisionnement AWS/Azure cible (IaaS)
3. Migration de la base : mysqldump → import RDS/Azure Database
4. Migration des fichiers : rsync → S3 / Azure Blob avec plugin Moodle adapté
5. Test en parallèle (DNS basculement progressif)
6. Optimisation PaaS (passage de la BDD en RDS, CDN, Auto Scaling)

9. Commande d'objets connectés via le cloud

Architecture :

Interface web/mobile → API Gateway → Lambda/Function → AWS IoT / Azure IoT Hub
Protocole : MQTT pour commandes vers objets (LED, moteurs, relais)
Retour d'état : IoT → DynamoDB / Cosmos DB → Frontend temps réel

10. Administration d'un service SharePoint

Approche :

SharePoint Online (SaaS Microsoft 365) ou SharePoint Server on-premise migré vers Azure
Gouvernance : Permissions, sites collections, workflows Power Automate
Intégration : Teams, OneDrive, Azure AD

15. Récapitulatif final — Les incontournables

En une phrase
 Concept Résumé opérationnel
Cloud Computing Louer de l'informatique à la demande, comme de l'électricité
IaaS Je loue des briques, je construis la maison
PaaS Je loue un atelier équipé, je fabrique mon produit
SaaS Je vais au restaurant, je consomme ce qui est cuisiné
Big Data Des données trop grosses pour un seul ordinateur
IoT Des objets physiques qui parlent au Cloud
Hadoop Le framework qui fait travailler ensemble des milliers d'ordinateurs
PRA Comment redémarre l'informatique après un crash
PCA Comment l'entreprise survive après un crash
HA Le système ne s'arrête jamais (ou presque)

Les 5V du Big Data

Volume · Vélocité · Variété · Valeur · Véracité

Les 5 caractéristiques NIST

1. On-Demand Self-Service : Je commande seul, sans appeler personne.
2. Broad Network Access : J'accède depuis mon téléphone, mon PC, ma tablette.
3. Resource Pooling : Les ressources sont mutualisées (je partage le serveur physique sans
le savoir).
4. Rapid Elasticity : Les ressources grandissent et rétrécissent automatiquement selon mes
besoins.
5. Measured Service : Je paie exactement ce que j'ai consommé, au Go, à la seconde, au
Mo.

Les 4 modèles de déploiement

Public : Chez le fournisseur, partagé, Internet.
Privé : Chez moi, dédié, contrôle total.
Hybride : Les deux, selon la sensibilité des données.
Communautaire : Partagé entre organisations du même secteur.

Sécurité : la règle d'or

Security OF the Cloud → Fournisseur (physique, réseau, hyperviseur).
Security IN the Cloud → Client (données, applications, accès, configuration).
 Plus on descend dans IaaS → plus la responsabilité du client augmente.

Tableau-mémo des modèles de service

Modèle Gestion par le client Gestion par le fournisseur Usage

IaaS OS, Middleware, Runtime, Physique, Réseau, Migration lift & shift
App, Données Virtualisation, Serveurs
PaaS Application, Données Tout + OS + Middleware + Développement
Runtime + Outils dev rapide
SaaS Données, Configuration Tout (y compris l'application) Consommation
compte directe