1 : Comprendre le Cloud Computing

1.1 Qu'est-ce que le cloud ?

Le cloud computing, ou informatique en nuage, est un mode de fourniture de ressources
informatiques (serveurs, stockage, bases de données, réseaux, logiciels, etc.) via Internet. Les
ressources sont mises à disposition à la demande, sans que l'utilisateur ait à gérer
l'infrastructure sous-jacente. Le cloud est accessible depuis n'importe quel appareil connecté à
Internet.

1.2 Avantages du cloud computing

• Coûts réduits : pas de matériel à acheter ou à entretenir.

• Accessibilité : accès aux applications et fichiers depuis n'importe où.

• Haute disponibilité : services accessibles 24h/24 et 7j/7.

• Mise à l'échelle rapide : ressources adaptables en fonction des besoins.

• Entretien minimal : les mises à jour et la maintenance sont assurées par le fournisseur.

1.3 Les types de cloud

• Cloud public : partagé entre plusieurs clients. Exemples : Amazon Web Services (AWS),
Microsoft Azure, Google Cloud Platform (GCP).

• Cloud privé : dédié à une seule organisation. Peut être local ou hébergé.

• Cloud hybride : combinaison des deux précédents, permettant plus de flexibilité.

1.4 Caractéristiques essentielles du cloud selon le NIST

• Libre-service à la demande.

• Accès réseau large.

• Mutualisation des ressources.

• Élasticité rapide.

• Service mesurable.

1.5 Utilisations courantes

• Sauvegarde et récupération de données.

• Déploiement d'applications web.

• Stockage et partage de fichiers (Dropbox, Google Drive).

• Plateformes de messagerie (Gmail, Outlook).

2 : Modèles de services Cloud : IaaS, PaaS, SaaS

2.1 IaaS (Infrastructure as a Service)

Modèle où le fournisseur met à disposition des ressources physiques (machines virtuelles,
stockage, réseaux).
 • L'utilisateur gère le système d'exploitation, les applications, les données.

• Exemples : AWS EC2, Azure VM, Google Compute Engine.

• Avantages : flexibilité, contrôle total sur l'environnement, bon pour les développeurs
avancés.

2.2 PaaS (Platform as a Service)

Le fournisseur gère l'infrastructure ainsi que la plateforme logicielle.

• L'utilisateur se concentre sur le développement et le déploiement de son application.

• Exemples : Google App Engine, Azure App Service, Heroku.

• Avantages : gain de temps, gestion simplifiée, idéal pour les développeurs.

2.3 SaaS (Software as a Service)

Modèle où l'utilisateur accède directement à une application prêt à l'emploi via un navigateur.

• Pas de gestion d'infrastructure ni d'installation de logiciel.

• Exemples : Gmail, Microsoft 365, Dropbox.

• Avantages : accessibilité, mise à jour automatique, très simple pour l'utilisateur final.

2.4 Comparaison rapide

Modèle Qui gère quoi ? Exemple

IaaS Client gère OS, apps AWS EC2

PaaS Client gère apps Heroku

SaaS Tout géré par fournisseur Gmail

3 : L’approche Cloud Native

3.1 Définition
Le cloud native est une approche de conception, de développement et de déploiement
d’applications qui sont spécialement conçues pour être exécutées dans des environnements
cloud.

3.2 Objectifs

• Exploiter les avantages du cloud : évolutivité, résilience, rapidité.

• Réduire les coûts de maintenance.

• Permettre l’innovation rapide par des cycles courts de développement (Agilité).

3.3 Caractéristiques

• Utilisation des microservices : chaque fonctionnalité est un service autonome.

• Conteneurisation avec Docker : unité standard pour le déploiement.

 • CI/CD (intégration et livraison continues) : automatisation des tests, intégration,
déploiement.

• Infrastructure as Code (IaC) : définition de l’infrastructure via du code (ex : Terraform).

• Observabilité : surveillance en temps réel, journaux, métriques.

3.4 Entreprises utilisatrices

• Netflix : déploiement de milliers de microservices quotidiennement.

• Uber, WeChat : adaptabilité rapide aux besoins du marché.

3.5 Avantages

• Flexibilité, modularité, testabilité accrue.

• Temps de mise sur le marché réduit.

• Moins de risques lors des mises à jour (mise à jour d’un microservice sans perturber
l’ensemble).

4 : APIs REST avec Node.js et Express.js

4.1 Définition des APIs REST

Une API (Application Programming Interface) REST est une interface permettant à deux
applications de communiquer via des requêtes HTTP. REST (Representational State Transfer)
repose sur l'utilisation de méthodes HTTP standards : GET, POST, PUT, DELETE.

4.2 Avantages des APIs REST

• Légères et simples à mettre en œuvre.

• Fonctionnent bien sur HTTP, compatible avec tous les navigateurs.

• Idéal pour les applications web et mobiles.

4.3 Écosystème Node.js

Node.js est un environnement JavaScript côté serveur. Il utilise une architecture événementielle,
non bloquante, idéale pour les applications en temps réel et les APIs.

• Asynchrone, rapide, efficace.

• Fonctionne sur le moteur V8 de Chrome.

• Utilisé par des entreprises comme Netflix, LinkedIn, PayPal.

4.4 Framework Express.js

Express.js est un framework minimaliste basé sur Node.js pour créer des serveurs web et APIs
REST.

Exemple simple :

const express = require('express');

const app = express();

app.get('/', (req, res) => res.send('Hello World'));

app.listen(3000);

4.5 Mise en œuvre d’une API REST

• Création de routes (ex: /produits).

• Utilisation de middlewares (ex: body-parser).

• Intégration avec une base de données (ex: MongoDB via Mongoose).

(Suite : Page 5 : Authentification JWT, Page 6 : Microservices, Page 7 : Conteneurs Docker, etc.)

5 : Authentification avec JWT (JSON Web Token)

5.1 Définition
Le JWT est un standard ouvert (RFC 7519) permettant l’échange sécurisé de données entre
parties sous forme de token JSON signé. Il est très utilisé dans les applications cloud-native
pour implémenter une authentification sans session côté serveur.

5.2 Structure d’un JWT

Un token JWT est composé de trois parties encodées en base64, séparées par des points (.) :

• Header : indique l’algorithme utilisé (ex : HS256) et le type de token.

• Payload : contient les données (claims) comme userId, role, exp.

• Signature : générée avec une clé secrète, elle permet de vérifier que le token n’a pas été
modifié.

Exemple :

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.

eyJ1c2VySWQiOiIxMjM0NTYiLCJleHAiOjE2MzY5NzY0MDB9.

HkQ3jl8jdZsYgPUm_WHD-t4x6nE9YqUdkLRdrc6lQOY

5.3 Fonctionnement typique

1. L’utilisateur s’authentifie via une route /login.

2. Le serveur génère un token JWT et le renvoie au client.

3. Le client stocke le token (souvent en localStorage).

4. À chaque requête, le client envoie ce token dans l’en-tête Authorization: Bearer TOKEN.

5. Le serveur vérifie la signature du token avant d’exécuter l’action.

5.4 Avantages du JWT

• Stateless : aucune session à stocker côté serveur.

• Portabilité : facilement utilisable dans les applications mobiles, web, API.

• Performance : réduction de la charge serveur.

• Sécurité : signature numérique garantissant l'intégrité.

5.5 Implémentation avec Node.js / Express
Installation :

npm install jsonwebtoken bcryptjs

Création d’un token :

const jwt = require('jsonwebtoken');

const token = jwt.sign({ id: user._id }, 'secretKey', { expiresIn: '1h' });

Vérification d’un token middleware :

function verifyToken(req, res, next) {

const token = req.headers['authorization']?.split(' ')[1];

if (!token) return res.status(403).send('Token requis');

jwt.verify(token, 'secretKey', (err, decoded) => {

if (err) return res.status(403).send('Token invalide');

req.userId = decoded.id;

next();

});

6 : Architecture microservices

6.1 Définition
L’architecture microservices est une approche de conception logicielle où une application est
structurée comme un ensemble de petits services indépendants, chacun étant responsable
d'une fonctionnalité métier spécifique. Ces services communiquent entre eux via des APIs,
souvent REST ou des messages asynchrones.

6.2 Monolithe vs Microservices

• Monolithique : l’application est une seule entité, difficile à maintenir, à tester ou à

mettre à l’échelle.

• Microservices : l’application est divisée en services modulaires pouvant être

développés, déployés et scalés indépendamment.

6.3 Avantages

• Scalabilité : chaque service peut être mis à l’échelle indépendamment selon la charge.

• Résilience : un service défaillant n’impacte pas toute l’application.

• Flexibilité technologique : chaque service peut être écrit avec le langage ou la base de
données la plus adaptée.

• Déploiement rapide : les équipes peuvent livrer en continu.

6.4 Inconvénients

• Complexité accrue de la communication inter-services.

• Nécessité d’une orchestration (ex : Kubernetes).

• Multiplication des bases de données et des configurations.

• Surveillance, journalisation et tests plus complexes.

6.5 Communication entre microservices

• Synchrone : via HTTP/REST.

• Asynchrone : via files de messages (ex : RabbitMQ, Kafka).

6.6 Exemple
Une application e-commerce peut être divisée en :

• Service Utilisateur

• Service Produits

• Service Commandes

• Service Paiement

Chaque service est isolé, a sa propre base de données et peut être redéployé sans impact sur
les autres.

6.7 API Gateway

Un point d’entrée unique pour gérer les appels vers les différents services. Il permet :

• Le routage des requêtes.

• L’authentification centralisée.

• Le filtrage et la limitation du trafic.

7 : Conteneurs avec Docker

7.1 Définition
Docker est une plateforme de conteneurisation permettant d'exécuter des applications dans
des environnements isolés appelés "conteneurs". Un conteneur regroupe une application et
toutes ses dépendances dans un seul paquet exécutable.

7.2 Différence entre machine virtuelle et conteneur

• Machine virtuelle : embarque un système d'exploitation complet. Lourd, plus lent à

démarrer.

• Conteneur : partage le noyau de l'hôte, léger, rapide à exécuter.

7.3 Avantages des conteneurs

• Portabilité : fonctionne de la même façon en local, en test ou en production.

• Isolation : chaque conteneur est indépendant.

• Légèreté : consommation réduite de ressources.

 • Scalabilité : facile à multiplier ou répartir sur plusieurs machines.

7.4 Image vs Conteneur

• Image : modèle statique contenant l’application et ses dépendances.

• Conteneur : instance exécutable d’une image.

7.5 Dockerfile
Fichier de configuration décrivant comment construire une image Docker.

Exemple :

FROM node:18

WORKDIR /app

COPY package*.json ./

RUN npm install

COPY . .

EXPOSE 3000

CMD ["node", "index.js"]

7.6 Commandes de base

• docker build -t nom-image . : créer une image.

• docker run -p 3000:3000 nom-image : exécuter un conteneur.

• docker ps : lister les conteneurs actifs.

• docker stop id_conteneur : arrêter un conteneur.

7.7 Cas d’usage typique

• Développement local reproductible.

• Déploiement sur cloud ou serveur distant.

• Environnement de test isolé.

8 : Messaging asynchrone avec RabbitMQ

8.1 Définition
RabbitMQ est un système de messagerie open source basé sur le protocole AMQP (Advanced
Message Queuing Protocol). Il permet la communication asynchrone entre services ou
applications grâce à un modèle de file d’attente.

8.2 Pourquoi la communication asynchrone ?

Dans une architecture microservices, il est souvent nécessaire de découpler les services pour
éviter qu’ils dépendent les uns des autres. Grâce à un message envoyé dans une file, un service
peut continuer à fonctionner sans attendre la réponse d’un autre.

8.3 Concepts clés

• Producer : l’émetteur de message.

 • Consumer : le destinataire du message.

• Queue : file d’attente contenant les messages.

• Exchange : point d’entrée qui redirige les messages vers les bonnes queues.

• Binding : liaison entre exchange et queue selon certaines règles.

8.4 Fonctionnement

1. Le producteur envoie un message à un exchange.

2. L’exchange l’achemine à une ou plusieurs queues selon les bindings.

3. Le consommateur écoute une queue et traite les messages reçus.

8.5 Types d’exchange

• Direct : routage selon un mot-clé exact.

• Fanout : broadcast à toutes les queues.

• Topic : routage basé sur des motifs.

• Headers : filtrage via des en-têtes.

8.6 Exemple avec Node.js

Installation du client :

npm install amqplib

Producteur :

const amqp = require('amqplib');

const sendMessage = async () => {

const conn = await amqp.connect('amqp://localhost');

const channel = await conn.createChannel();

await channel.assertQueue('taches');

channel.sendToQueue('taches', Buffer.from('Nouvelle tâche'));

setTimeout(() => conn.close(), 500);

};

sendMessage();

Consommateur :

const amqp = require('amqplib');

const consume = async () => {

const conn = await amqp.connect('amqp://localhost');

const channel = await conn.createChannel();

 await channel.assertQueue('taches');

channel.consume('taches', msg => {

console.log("Message reçu:", msg.content.toString());

channel.ack(msg);

});

};

consume();

8.7 Cas d’usage courant

• Traitement différé (emails, notifications).

• Orchestration entre microservices.

• Communication inter-applications hétérogènes.

9 : Reverse proxy avec NGINX

9.1 Définition
Un reverse proxy est un serveur intermédiaire qui reçoit les requêtes des clients et les redirige
vers les bons serveurs internes. NGINX est l’un des reverse proxy les plus utilisés dans le monde
du cloud pour sa légèreté et ses performances.

9.2 Rôles d’un reverse proxy

• Routage des requêtes vers le service approprié (microservice, API).

• Sécurité : gestion du HTTPS, des headers, masquage de l’infrastructure interne.

• Load balancing : répartition de charge sur plusieurs serveurs.

• Cache : amélioration des performances via la mise en cache des réponses.

• Point d’entrée unique : simplifie l’accès aux services backend.

9.3 Exemple de configuration NGINX

Supposons que nous ayons deux microservices :

• Service Produits sur le port 4001

• Service Clients sur le port 4002

Fichier nginx.conf :

http {

server {

listen 80;

location /produits {
 proxy_pass http://localhost:4001;

location /clients {

proxy_pass http://localhost:4002;

9.4 Utilisation avec Docker

NGINX peut être exécuté dans un conteneur Docker et configuré pour servir de proxy à d’autres
conteneurs de l’application.

Extrait docker-compose.yml :

services:

nginx:

image: nginx:latest

ports:

- "80:80"

volumes:

- ./nginx.conf:/etc/nginx/nginx.conf

depends_on:

- produits

- clients

9.5 Avantages de NGINX dans le cloud native

• Très performant sous haute charge.

• Compatible avec HTTPS et certificats SSL (ex: via Let’s Encrypt).

• Facile à intégrer dans une stack Docker ou Kubernetes.

(Suite : Page 10 : Déploiement d’une application cloud native sur Azure)

10 : Déploiement d’une application cloud native sur Azure

10.1 Pourquoi Azure ?

Microsoft Azure est une plateforme cloud proposant des services IaaS, PaaS et SaaS. Elle offre
un environnement intégré pour héberger, gérer et surveiller des applications cloud natives.

10.2 Préparer l’application pour le cloud

Avant le déploiement, il est essentiel de :

• Conteneuriser l’application avec Docker.

• Définir les variables d’environnement (ex : DB_HOST, JWT_SECRET).

• Créer un fichier docker-compose.yml si l’application contient plusieurs services.

10.3 Azure App Service (PaaS)

Service permettant de déployer rapidement des applications web ou API en Node.js, .NET, Java,
Python.

Étapes :

1. Créer une App Service via le portail Azure.

2. Connecter GitHub ou déposer un fichier ZIP avec le code source.

3. Configurer les paramètres d’environnement.

4. Lancer le déploiement.

10.4 Déploiement via Azure CLI

az login

az group create --name myResourceGroup --location westeurope

az appservice plan create --name myPlan --resource-group myResourceGroup --sku B1 --is-

linux

az webapp create --resource-group myResourceGroup --plan myPlan --name monappcloud --

runtime "NODE|18-lts"

az webapp deployment source config --name monappcloud --resource-group

myResourceGroup --repo-url https://github.com/monrepo --branch main --manual-integration

10.5 Base de données et stockage

• Azure SQL Database pour des données relationnelles.

• Cosmos DB pour les données NoSQL.

• Azure Blob Storage pour stocker des fichiers.

10.6 Surveillance et scalabilité

• Azure Monitor : métriques en temps réel, alertes.

• Application Insights : traçage des erreurs, logs.

 • Scaling automatique : Azure peut ajuster dynamiquement les ressources selon la
charge.

10.7 Bonnes pratiques

• Utiliser des groupes de ressources pour organiser les composants.

• Sécuriser les secrets avec Azure Key Vault.

• Déployer via CI/CD avec GitHub Actions ou Azure DevOps.

• Configurer les sauvegardes automatiques.