MEMOIRE MASTER CLOUD COMPUTING FRANCK RECKATY.pdf

REPUBLIQUE DU SENEGAL
Un peuple-Un but-Une foi
Ministère de l’Enseignement Supérieur et de la Recherche
Direction Générale de l’Enseignement Supérieur Privé
Institut Supérieur d’Informatique
MEMOIRE
Présenté et soutenu par :
M. RECKATY TOURE Franck L.A.K
Pour l’obtention du diplôme de :
Master Professionnel : réseaux et systèmes informatiques
Parcours : Informatique
Sujet :
Soutenu à Dakar, le 16/ 12 /2025
Membres du Jury
Statut NOM et Prénom Grade
Président Pr Ibrahima NIANG Professeur
Superviseur de mémoire Dr Latyr Ndiaye Docteur
Directeur de mémoire M. Massamba LO Ingénieur
Examinateur 1 : M. Racine Oumar Sall Ingénieur
Année académique : 2024-2025
Etude et mise en place d’une solution cloud
computing

REPUBLIQUE DU SENEGAL
Un peuple-Un but-Une foi
Ministère de l’Enseignement Supérieur et de la Recherche
Direction Générale de l’Enseignement Supérieur Privé
Institut Supérieur d’Informatique
MEMOIRE
Présenté et soutenu par :
M. RECKATY TOURE Franck L.A.K
Pour l’obtention du diplôme de :
Master Professionnel : réseaux et systèmes informatiques
Parcours : Informatique
Sujet :
Soutenu à Dakar, le 16/12/2025
Membres du Jury
Statut NOM et Prénom Grade
Président Pr Ibrahima NIANG Professeur
Superviseur de mémoire Dr Latyr Ndiaye Docteur
Directeur de mémoire M. Massamba LO Ingénieur
Examinateur 1 : M. Racine Oumar Sall Ingénieur
Année académique : 2024-2025
Etude et mise en place d’une solution cloud
computing

I
A la mémoire de
Tous ceux et celles qui ont contribué à notre évolution par leur sincérité et qui nous ont quittés
pour poursuivre leur chemin :
• NKOUBIA Y RAZINGUET Joséphine, ma Akou
• REMANDE Roger
• MPOSSI Sabine
• OLAGO Armand
• AMBOUROUET ROGONOU François
• OVOUELE Jacqueline
• IWENGA Alphonsine (NGWE)
• EYANG MENGUIRE Léonie
Paix à vos âmes et que le Très-Haut vous accueille au sein de sa continuité universelle.

II
Dédicace
A ma mère, Charlotte NKOLO RECKATY, en guise de ma profonde reconnaissance pour
tous les sacrifices que tu as effectué, pour ton amour inébranlable. Je n’ai pas grand-chose à
rajouter, parce que aucun mot ne pourrait exprimer l’indescriptible respect, amour que je te
porte.
Puisse Dieu t’accorder santé, bonheur et longue vie afin que nous pussions un jour
combler de joie et que tu sois élevée Akewa.

III
Remerciements
Je rends grâce à Dieu, qui m’a accordé la santé, la patience et la persévérance nécessaires
pour mener à bien ce travail.
J’exprime ma profonde gratitude à M. Massamba LO, mon directeur de mémoire, qui a accepté
de m’encadrer et pour les conseils reçus dès la licence, conseils qui m’ont permis de me
dépasser et de produire ce mémoire.
Mes remerciements s’adressent également à l’ensemble du corps professoral de l’Institut
Supérieur d’Informatique pour les connaissances théoriques et pratiques transmises tout au long
de ma formation, ainsi qu’aux membres du jury pour leur contribution à mon évolution.
Je remercie M. Félicien RECKATY et son épouse Mme Jeanine RECKATY, ma
Ninine, pour leur affection, leurs conseils et leur disponibilité, qui m’ont toujours porté,
notamment dans l’élaboration de ce mémoire.
J’exprime également ma profonde gratitude à mon père pour ce qu’il a pu m’apporter, à ma
mère pour sa fougue et son énergie, à mes petites sœurs ainsi qu’à Ruth Néhémie pour leur
soutien constant, leur patience et leurs encouragements.
Enfin, je remercie toutes les personnes qui, de près ou de loin, ont contribué à la
réalisation de ce travail, notamment par la motivation qu’elles m’ont apportée.
Merci.

IV
Avant-propos
L’Institut Supérieur d’Informatique (ISI), leader et référence dans les TIC, est un
établissement privé d’enseignement supérieur justifiant des années d’expériences dans les
domaines de l’informatique de la gestion des télécommunications. L’ISI délivre dans ces
domaines des diplômes, qui sont pour la majorité reconnus par le CAMES et L’ANAQ SUP,
allant du DTS au Master en passant par la licence.
Pour l’obtention de master en réseau informatique, ISI exige aux étudiants la rédaction
d’un mémoire de fin de cycle. C’est dans ce cadre que nous avons élaboré ce document qui a
pour sujet : Etude et mise en place d’une solution cloud computing.
Le choix de ce sujet peut se justifie par l’évolution actuelle des systèmes d’information
vers la virtualisation et la mutualisation des ressources. De nombreuses entreprises locales
disposent déjà de matériel, mais peinent à le transformer en véritable plateforme de services.
Le cloud computing, lorsqu’il est déployé en privé permet de mieux utiliser les ressources
existantes, d’améliorer la disponibilité des services, de sécuriser les accès et de garder la
souveraineté sur les données. Ce travail vise donc à construire une infrastructure cloud adaptée
au contexte d’une entreprise locale.
Chers membres du jury, ce document n’est guère exempt de reproches ni
d’imperfections, peut-être car il demeure l’œuvre d’un être humain avant tout, et celle d’un
chercheur encore en apprentissage, manquant d’expérience. C’est pourquoi nous implorons
votre bienveillance et votre indulgence quant à l’évaluation de notre travail.

V
Sommaire
Chapitre 1 : Introduction Générale ------------------------------------------------------------------ 1
1.1. Présentation du sujet................................................................................................. 1
1.2. Contexte et enjeux de la transformation numérique.............................................. 2
1.2.1. La transformation numérique moteur d’adoption du cloud------------------------- 2
1.2.2. La transformation numérique locale --------------------------------------------------- 2
1.2.3. Les enjeux stratégiques, économiques et humains ----------------------------------- 3
1.3. Problématique............................................................................................................ 6
1.4. Objectifs du mémoire ................................................................................................ 7
1.4.1. Objectif général --------------------------------------------------------------------------- 7
1.4.2. Objectifs spécifiques --------------------------------------------------------------------- 7
1.5. Intérêts du sujet ......................................................................................................... 8
1.5.1. Intérêts pour l’entreprise ----------------------------------------------------------------- 8
1.5.2 Intérêts pour l'étudiant-------------------------------------------------------------------- 8
Chapitre 2 : État de l’art et solutions existantes--------------------------------------------------- 9
2.1. Fondamentaux techniques et réseaux pour le cloud............................................... 9
2.1.1. La virtualisation --------------------------------------------------------------------------10
2.1.2. Les hyperviseurs -------------------------------------------------------------------------10
2.1.3. Les avantages de la virtualisation------------------------------------------------------12
2.1.4. Les types de virtualisation --------------------------------------------------------------12
2.1.5. Les outils de virtualisation--------------------------------------------------------------15
2.2. Le Cloud Computing............................................................................................... 18
2.2.1. Les différents services du Cloud Computing ----------------------------------------18
2.2.2. Architecture Fondamentale d'un Cloud-----------------------------------------------20
2.2.3. Les modèles de déploiement dans le Cloud Computing----------------------------21
2.2.4. La notion de Datacenter-----------------------------------------------------------------23
2.2.5. Les technologies complémentaires du Cloud ----------------------------------------29

VI
2.3. L’architecture réseau dans le cloud....................................................................... 31
2.3.1. Rappel sur le réseau ---------------------------------------------------------------------31
2.3.2. Les types de réseaux---------------------------------------------------------------------31
2.3.3. Les topologies réseau--------------------------------------------------------------------32
2.3.4. Les modèles de référence ---------------------------------------------------------------33
2.3.5. L’adressage IP, la gestion réseau et les protocoles essentiels ---------------------34
2.4. Critères de comparaisons des solutions Cloud...................................................... 36
2.4.1. Les critères fonctionnels ----------------------------------------------------------------36
2.4.2. Les critères non fonctionnels-----------------------------------------------------------37
2.5. Etude des solutions existantes................................................................................. 40
2.6. Conclusion................................................................................................................ 51
Chapitre 3 : Analyse de l’existant et Conception de la solution proposée ------------------52
3.1. Présentation de l’entreprise.................................................................................... 52
3.1.1. Activités principales ---------------------------------------------------------------------52
3.1.2. Structure organisationnelle -------------------------------------------------------------53
3.2. Architecture de l’existant........................................................................................ 55
3.2.1. Présentation du réseau de GDS --------------------------------------------------------55
3.2.2. Topologie du réseau existant -----------------------------------------------------------56
3.2.3. Inventaire des ressources matérielles et logicielles existantes---------------------56
3.2.4. Les avantages et limites de l’existant -------------------------------------------------59
3.3. Conception de la solution proposée........................................................................ 61
3.3.1. Analyse des Besoins---------------------------------------------------------------------61
3.4. Modèle fonctionnel – Cas d’utilisation .................................................................. 63
3.5. Choix des solutions technologiques et matérielles ................................................ 64
3.5.1. Choix matériel et infrastructure de base ----------------------------------------------64
3.5.2. Choix de la Solution Cloud-------------------------------------------------------------65
3.6. Architecture Cible de la Solution (Physique et Logique)..................................... 66

VII
3.6.1. Architecture physique cible (Entreprise) ---------------------------------------------67
3.6.2. Architecture Logique Cible-------------------------------------------------------------68
3.7. Conclusion................................................................................................................ 71
Chapitre 4 : Mise en place de la solution proposée ----------------------------------------------72
4.1. Schéma de Déploiement .............................................................................................. 72
4.2. Présentation de l'Environnement de Test ................................................................. 73
4.2.1 Plan d’adressage------------------------------------------------------------------------------74
4.2.2. Prérequis Logiciels --------------------------------------------------------------------------74
4.3. Déploiement du Router/Pare-feu (PfSense) .............................................................. 74
4.3.1. Création et Configuration des Interfaces Réseau ---------------------------------------75
4.3.2. Configuration des Services Réseau et Sécurité------------------------------------------76
4.3.3. Règles de sécurité Pare-feu et segmentation---------------------------------------------77
4.4. Présentation de Proxmox VE...................................................................................... 77
4.4.1. Architecture générale de Proxmox VE ---------------------------------------------------77
4.4.2. Modes de déploiement----------------------------------------------------------------------78
4.4.3. Gestion du Réseau dans Proxmox---------------------------------------------------------78
4.4.4. Rôle de Proxmox (cloud privé ) -----------------------------------------------------------79
4.5. Installation et configuration des nœuds Proxmox .................................................... 79
4.5.1. Installation de Proxmox VE----------------------------------------------------------------79
4.5.2. Création des bridges réseau ----------------------------------------------------------------82
4.5.3. Création du cluster Proxmox---------------------------------------------------------------83
4.6. Mise en place du stockage partagé (NAS / NFS)....................................................... 86
4.6.1. Installation et adressage de la VM GDS-NAS ------------------------------------------87
4.6.2. Ajout du disque de stockage et création du système de fichiers ----------------------88
4.6.3. Création du dossier partagé et export NFS-----------------------------------------------90
4.6.4. Ajout du NAS dans Proxmox comme stockage NFS ----------------------------------91
4.7. Déploiement des services du cloud privé ................................................................... 93

VIII
4.7.1. Déploiement des conteneurs ---------------------------------------------------------------93
4.7.2. Service S6 – Portail interne d’accès ------------------------------------------------------95
4.7.3. Service S2 – Stockage collaboratif--------------------------------------------------------96
4.7.4. Service S1 – IAM / annuaire LDAP ------------------------------------------------------98
4.7.5. Service S3 – Supervision (Prometheus)--------------------------------------------------99
4.8. Tests et validation ...................................................................................................... 100
4.8.1. Test DNS interne depuis l’employé du vlan30 --------------------------------------- 101
4.8.2. Test d’accès aux services----------------------------------------------------------------- 101
4.8.3. Test de la segmentation------------------------------------------------------------------- 103
4.9. Complément : déploiement d’OpenStack via MicroStack ................................ 104
4.9.1. Mise en place de la VM OpenStack------------------------------------------------- 104
4.9.2. Installation de MicroStack------------------------------------------------------------ 105
4.9.3. Création du projet et des utilisateurs ------------------------------------------------ 107
4.9.4. Création du réseau privé OpenStack ------------------------------------------------ 107
4.9.5. Lancement d’une instance OpenStack ---------------------------------------------- 109
4.9.6. Test d’accessibilité--------------------------------------------------------------------- 110
Chapitre 5 : Conclusion et perspectives ---------------------------------------------------------- 112
Bibliographie-----------------------------------------------------------------------------------------------i
I. Mémoires .....................................................................................................................i
II. Rapports .....................................................................................................................ii
Webographie --------------------------------------------------------------------------------------------- iii
Annexes----------------------------------------------------------------------------------------------------- v
Annexes I : Questionnaire.................................................................................................... v
Annexes II : Autres documents ..........................................................................................ix
Table des matières ------------------------------------------------------------------------------------ xxv

IX
Glossaire
ACL Access Control List (Liste de contrôle d’accès) - Ensemble de règles dans un pare-
feu comme pfSense qui autorisent ou bloquent le trafic réseau.
API Application Programming Interface (Interface de programmation)
AWS Amazon Web Services - Plateforme de cloud computing public d'Amazon
CAPEX / OPEX Capital Expenditure / Operational Expenditure - les dépenses d'investissement
(CAPEX) et les dépenses d'exploitation (OPEX).
Cloud Act Loi fédérale américaine permettant aux autorités américaines d'accéder aux
données stockées par les fournisseurs de services cloud basés aux États-Unis.
Cloud
Computing
Modèle permettant un accès réseau à la demande à un pool partagé de ressources
informatiques
Cloud Privé Infrastructure de cloud computing dédiée à une seule organisation
Cluster (Grappe) - Ensemble de serveurs (nœuds) interconnectés qui fonctionnent comme
un système unique pour améliorer la haute disponibilité.
DHCP Dynamic Host Configuration Protocol - Protocole d'attribution dynamique
d'adresses
DNS Domain Name System - Système de noms de domaine
Firewall (Pare-feu) - Dispositif de sécurité (comme pfSense) qui filtre le trafic réseau
entrant et sortant pour protéger l'infrastructure.
GAFAM Acronyme désignant les géants américains du web (Google, Apple, Facebook,
Amazon, Microsoft), principaux fournisseurs de cloud public.
HA High Availability (Haute Disponibilité) - Capacité d'un système à rester
opérationnel
Hyperviseur Logiciel qui crée, exécute et gère les machines virtuelles
IaaS Infrastructure as a Service (Infrastructure en tant que Service)
IAM Identity and Access Management (Gestion des identités et des accès) - Processus
et services pour gérer les identités et leurs droits.
KVM Kernel-based Virtual Machine - Technologie de virtualisation complète intégrée
au noyau Linux
LAN Local Area Network (Réseau local) - Réseau informatique connectant des
appareils dans une zone limitée (ex: réseau local du GDS).
LDAP Lightweight Directory Access Protocol - Protocole d'accès à un service d'annuaire,
utilisé pour centraliser la gestion des identités (IAM).

X
LXC Linux Containers - Technologie de virtualisation légère (conteneurisation) qui
partage le noyau de l'hôte, utilisée par Proxmox VE.
NAS Network Attached Storage (Stockage en réseau) - Dispositif de stockage connecté
au réseau
NAT Network Address Translation (Traduction d’adresses réseau)
NFS Network File System (Système de fichiers réseau) - Protocole de partage de
fichiers
OMV OpenMediaVault - Solution logicielle open-source NAS virtuel
OpenStack Plateforme de cloud computing open-source mentionnée comme une alternative
plus complexe à Proxmox VE.
PaaS Platform as a Service (Plateforme en tant que Service)
PfSense Distribution logicielle open-source utilisée comme routeur et pare-feu pour
sécuriser l'infrastructure et segmenter le réseau (VLAN).
Prometheus Outil open-source de surveillance (monitoring)
Proxmox VE Plateforme de virtualisation open-source
RGPD Règlement Général sur la Protection des Données - Loi européenne sur la
protection de la vie privée et des données personnelles.
SaaS Software as a Service (Logiciel en tant que Service)
SSO Single Sign-On (Authentification unique)
Souveraineté
Numérique
Capacité d'une organisation à maîtriser et à protéger ses propres données et
infrastructures numériques
TCO Total Cost of Ownership (Coût total de possession) - Estimation financière
incluant le coût d'achat (CAPEX) et les coûts d'exploitation (OPEX).
Virtualisation Technologie permettant de créer des versions virtuelles
VLAN Virtual Local Area Network (Réseau local virtuel)
VM Virtual Machine (Machine virtuelle)
VPN Virtual Private Network (Réseau privé virtuel)
WAN Wide Area Network (Réseau étendu)

XI
Liste des figures
Figure 1 : Structure représentative de la virtualisation (Type2)............................................... 10
Figure 2 : Schéma d’un hyperviseur de type 1......................................................................... 11
Figure 3 : Schéma d’un hyperviseur de type 2......................................................................... 11
Figure 4 : Illustration récapitulative des types de virtualisation .............................................. 14
Figure 5 : Schéma récapitulatif des modèles de services du Cloud Computing ...................... 18
Figure 6 : Répartition des responsabilités entre client et fournisseur selon le modèle de service
.................................................................................................................................................. 19
Figure 7 : Schéma de l'architecture d'une pile IaaS (Back-End).............................................. 21
Figure 8 : Schéma fonctionnel d’un data center...................................................................... 26
Figure 9 : Composant critique d’un data center : infrastructure en rack.................................. 26
Figure 10 : Synthèse comparative des technologies complémentaires .................................... 30
Figure 11 : Schéma représentatif des topologies réseau .......................................................... 33
Figure 12 : Correspondance entre les modèles OSI et TCP/IP ................................................ 33
Figure 13 : Services d’OpenStack............................................................................................ 41
Figure 14 : Architecture fonctionnelle d’OpenStack ............................................................... 41
Figure 15 : Illustration d’architecture intégrée de Proxmox VE.............................................. 43
Figure 16 : Organigramme de GDS ......................................................................................... 54
Figure 17 : Architecture réseau de GDS .................................................................................. 56
Figure 18 : Cas d’utilisation du cloud privé GDS.................................................................... 63
Figure 19 – Topologie physique de la solution cible ............................................................... 67
Figure 20 : Topologie logique de la solution cible................................................................... 69
Figure 21 : Architecture de notre maquette de test .................................................................. 72
Figure 22 : Interfaces assignées (pfSense) ............................................................................... 75
Figure 23 : configuration du DHCP ......................................................................................... 76
Figure 24 : Entrées DNS statiques pour les nœuds Proxmox et Nas ....................................... 77
Figures 25 : Résumé de la configuration initiale des Vms Proxmox....................................... 80
Figures 26 : Écrans web Proxmox après installation du nœud 1 et 2....................................... 81
Figure 27 : Création du bridge vmbr1...................................................................................... 82
Figure 28 : Bridges configurés sur le réseau des nœuds .......................................................... 83
Figures 29 : Création du cluster gds-cluster sur le nœud 1 ...................................................... 84
Figures 30 : le nœud 2 rejoint le cluster................................................................................... 85
Figure 31 : Cluster avec les deux nœuds.................................................................................. 86

XII
Figure 32 : Résumé de la création du cluster ........................................................................... 86
Figure 33 : Interface de connexion du Nas .............................................................................. 87
Figure 34 : Interfaces réseau configurées dans OMV.............................................................. 88
Figures 35 : Disque /dev/sdb ajouté et système de fichiers EXT4 “proxmox-nfs” monté....... 89
Figures 36 : Création du dossier partagé.................................................................................. 90
Figure 37 : Partage NFS “proxmox-nfs”.................................................................................. 91
Figures 38 : Stockage NFS “nas-nfs” monté sur les deux nœuds Proxmox ............................ 92
Figure 39 : Stockage NFS nas-nfs visible sur les deux nœuds................................................. 93
Figure 40 : Exemple de conteneur LXC de service créé sur Proxmox .................................... 94
Figure 41 : Host Overrides dans pfSense pour les services ..................................................... 95
Figure 42 : téléchargement du serveur web Nginx .................................................................. 95
Figure 43 : Portail cloud disponible ......................................................................................... 96
Figure 44 : Installation du serveur Apache et MariaDB .......................................................... 96
Figure 45 : création de la base Nextcloud................................................................................ 97
Figures 46 : Le portail et la page d’accueil Nextcloud ............................................................ 97
Figures 47 : interface phpLDAPadmin, accessible .................................................................. 98
Figure 48 : index.html du portail cloud.................................................................................... 99
Figures 49 : Les interfaces de Prometheus............................................................................. 100
Figure 50 : Ping sur le portail web ......................................................................................... 101
Figure 51 : Ping via le nom de domaine................................................................................. 101
Figure 52 : Portail web du cloud ............................................................................................ 102
Figure 53 : Service annuaire disponible................................................................................. 102
Figure 54 : Tentative vers nœud1 VLAN10 (Action bloquée par pfsense) ........................... 103
Figures 55 : Installation et initialisation de MicroStack – capture du terminal ..................... 106
Figures 56 : Page de connexion et tableau de bord Horizon.................................................. 106
Figure 57 : Création du projet et des utilisateurs ................................................................... 107
Figure 58 : Création du réseau privé et du routeur dans Horizon)......................................... 108
Figure 59 : Instance de vm-gds-stack active et cli opérationnelle ......................................... 109
Figures 60 : test avec un employé .......................................................................................... 111

XIII
Liste des tableaux
Tableau 1 – Solutions de virtualisation serveur (orientées cloud et production)..................... 16
Tableau 2 – Virtualisation poste de travail (usage individuel / test)........................................ 17
Tableau 3 - Synthèse comparative des modèles de déploiement ............................................. 23
Tableau 4 - Principaux protocoles réseau ................................................................................ 35
Tableau 5 : Comparatif des principales solutions Cloud Computing....................................... 50
Tableau 6 : Équipements d’interconnexion réseau .................................................................. 56
Tableau 7 : Recapitulatif des équipements serveurs et ordinateurs.......................................... 57
Tableau 8 : Recapitulatif des logiciels et systèmes d'exploitation ........................................... 58
Tableau 9 : Matériel Réutilisé pour la solution cloud .............................................................. 65
Tableau 10 – Plan d’adressage de la maquette......................................................................... 74
Tableau 11 : Interfaces réseau.................................................................................................. 75
Tableau 12 : tableau réseau des nœuds Proxmox et VirtualBox.............................................. 79

1
Chapitre 1 : Introduction Générale
1.1. Présentation du sujet
Dans un contexte de transformation numérique accélérée, les entreprises et les organisations
doivent moderniser leurs infrastructures informatiques pour gagner en efficacité, en sécurité et
en disponibilité. Le cloud computing s’est imposé comme l’un des moyens privilégiés pour
atteindre ces objectifs, en offrant un accès à la demande à des ressources de calcul, de stockage,
de réseau ou d’applications, sans qu’il soit nécessaire de gérer directement l’infrastructure
physique.
Selon la définition du National Institute of Standards and Technology (NIST), le cloud
computing est « un modèle permettant un accès omniprésent, pratique et à la demande via le
réseau à un ensemble partagé de ressources informatiques configurables […] pouvant être
rapidement provisionnées et libérées avec un minimum d’effort de gestion »1
. Ce modèle repose
notamment sur la virtualisation, la mutualisation des ressources et la capacité à faire évoluer
rapidement les services.
D’après le Grand View Research la forte adoption du cloud au niveau mondial montre que
ce modèle transforme profondément les architectures IT traditionnelles2
. Toutefois, cette
évolution soulève aussi des exigences nouvelles : sécurisation des données, maîtrise des coûts,
conformité aux réglementations locales et besoin de souveraineté numérique, en particulier dans
les contextes où les infrastructures et les cadres juridiques sont encore en construction.
C’est dans ce cadre que s’inscrit ce mémoire intitulé « Étude et mise en place d’une
solution de cloud computing ». Il vise à analyser les principes du cloud et à proposer, à partir
de technologies ouvertes (virtualisation...), une architecture cloud adaptée aux réalités d’une
organisation locale.
1
Peter Mell et Timothy Grance, The NIST Definition of Cloud Computing, NIST Special Publication 800-145
2
Grand View Research, Taille du marché du cloud computing, part de marché | Rapport sectoriel

2
1.2. Contexte et enjeux de la transformation numérique
Cette section présente le cadre dans lequel s’inscrit la problématique du cloud
computing, en montrant comment la transformation numérique pousse les organisations à
moderniser leurs infrastructures informatiques. Elle met également en évidence les défis
propres aux contextes émergents, où les contraintes techniques, économiques et réglementaires
rendent nécessaire l’adoption de solutions cloud locales maîtrisées. L’objectif est de
comprendre les facteurs qui conditionnent l’adoption du cloud et qui justifient la conception
d’une architecture adaptée au contexte d’une organisation locale.
1.2.1. La transformation numérique moteur d’adoption du cloud
La transformation numérique désigne l’intégration progressive des technologies
digitales dans les activités et les services d’une organisation afin d’en améliorer la performance,
la qualité de service et la compétitivité. Elle s’impose aujourd’hui comme un impératif
stratégique pour les entreprises comme pour les administrations. Cette évolution s’appuie de
plus en plus sur le cloud computing, qui offre la flexibilité, la mutualisation des ressources et
l’automatisation nécessaires pour déployer rapidement de nouveaux services tout en maîtrisant
les coûts3
.
Cependant, cette dynamique ne se déploie pas de manière uniforme. Dans les pays
africains notamment, l’adoption du cloud est réelle mais reste freinée par le coût de la
connectivité, la disponibilité limitée d’infrastructures locales, le manque de compétences
spécialisées et des cadres juridiques encore en construction. Ces spécificités expliquent l’intérêt
de solutions de cloud locales, basées sur des technologies ouvertes, permettant de concilier
modernisation des systèmes d’information, sécurité des données et exigences de souveraineté.
1.2.2. La transformation numérique locale
En Afrique, la transformation numérique suit une dynamique réelle mais graduelle. Elle
est portée par des investissements récents dans les infrastructures numériques (fibre, data
centers)4
. Toutefois, le recours au cloud computing reste encore limité par rapport aux
économies développées : la majorité des organisations utilisent des outils numériques de base,
3
McKinsey & Company, L’Afrique en marche vers le cloud : opportunités et obstacles
4
Stationnex, La progression du marché IT et l’utilisation des solutions intelligentes en Afrique à l’horizon 2025

3
mais peu accèdent à des services cloud avancés, faute de compétences, en raison du coût des
services et d’une confiance encore relative envers les prestataires étrangers.
Plusieurs initiatives publiques et privées montrent cependant une volonté d’accélérer
cette adoption. Au Sénégal par exemple, le lancement du cloud souverain DOOR offre une
infrastructure locale aux entreprises et aux services publics. Des acteurs régionaux comme
Liquid Intelligent Technologies étendent de leur côté, la connectivité et les centres de données
sur le continent, ce qui crée un socle technique plus favorable au cloud5
.
Ces évolutions confirment que le cloud computing est perçu comme un levier
d’efficacité et de souveraineté pour les pays africains, mais qu’il doit être décliné dans des
formes adaptées au contexte : solutions locales, maîtrisables, conformes aux réglementations
nationales et exploitables avec les compétences disponibles. C’est dans cette perspective que
s’inscrit la suite de cette section, qui analyse les enjeux économiques, réglementaires et humains
de cette mutation avant de proposer une architecture de cloud adaptée.
1.2.3. Les enjeux stratégiques, économiques et humains
La transformation numérique ne se limite pas à l’adoption de nouvelles technologies.
Elle implique aussi des choix économiques, réglementaires et de gouvernance. Le cloud
computing se situe au centre de ces choix, car il modifie la manière de consommer les ressources
informatiques et pose des questions de coût, de sécurité et de souveraineté. Les sections
suivantes reviennent sur ces principaux enjeux dans le contexte des organisations locales.
1.2.3.1. Enjeux économiques
Le cloud computing permet aux organisations d’accéder à des ressources informatiques
à la demande et de remplacer des investissements matériels lourds (CAPEX) par un modèle de
paiement à l’usage (OPEX) plus souple et plus prévisible6
. Il offre aussi un gain d’agilité : les
services peuvent être déployés plus rapidement, ce qui favorise l’innovation et la mise en
production de nouveaux services.
5
Digital Business Africa, Sénégal : Door , le cloud piloté par l’IA lancé pour réduire le gap technologique entre
l’Afrique et le reste du monde
6
Oracle, Qu’est-ce que l’économie du cloud ?

4
Dans les pays africains, où les infrastructures sont parfois limitées et les budgets restreints, cet
avantage est déterminant : le cloud permet aux PME, administrations et établissements de
disposer de services modernes sans devoir déployer immédiatement un datacenter complet7
.
C’est d’ailleurs le sens des initiatives de cloud souverain (comme DOOR au Sénégal), qui
proposent des ressources locales, sécurisées et adaptées aux exigences réglementaires
régionales.
Ainsi, le cloud apparaît comme un moyen de réduire les barrières financières à la transformation
numérique tout en améliorant la compétitivité. Toutefois, ces bénéfices économiques ne
peuvent être dissociés des questions de conformité, de localisation des données et de confiance
envers les fournisseurs, qui conditionnent la durabilité des modèles cloud dans les contextes
émergents.
1.2.3.2. Enjeux réglementaires
L’adoption du cloud computing implique de tenir compte des cadres juridiques qui
régissent la protection des données. Le RGPD européen impose, même aux organisations hors
UE qui traitent des données de résidents européens, des exigences fortes en matière de sécurité,
de traçabilité et de maîtrise des sous-traitants. À l’inverse, le CLOUD Act américain permet
aux autorités des États-Unis de demander l’accès à des données hébergées par un prestataire
soumis au droit américain, même lorsque ces données sont stockées à l’étranger8
.
Cette situation crée un risque d’extraterritorialité juridique pour les organisations qui
utilisent des clouds étrangers. Dans plusieurs pays africains, notamment au Gabon la protection
des données personnelles est encadrée, mais il n’existe pas toujours de stratégie nationale
spécifiquement dédiée au cloud. Cela rend plus complexe la migration vers des environnements
cloud publics étrangers, en particulier lorsque les données sont sensibles (administrations,
secteurs régulés, entreprises publiques).
Dans ce contexte, la protection des données devient un enjeu central de gouvernance :
il s’agit de garantir la localisation maîtrisée des données, de sécuriser les échanges (chiffrement,
contrôle des accès) et d’assurer une traçabilité conforme aux standards actuels. Ces exigences
conduisent naturellement à privilégier des solutions de cloud locales ou souveraines,
7
McKinsey & Company, Le bond en avant de l’Afrique vers le cloud : opportunités et obstacles
8
Commission Européenne, Règlement général sur la protection des données (RGPD)

5
hébergées sur le territoire national ou dans des infrastructures maîtrisées, afin de réduire la
dépendance vis-à-vis des grands fournisseurs internationaux (AWS, Microsoft, Google) et de
renforcer la souveraineté numérique.
1.2.3.3. Souveraineté numérique
La souveraineté numérique renvoie à la capacité d’un État ou d’une organisation à
maîtriser ses données, ses infrastructures et les technologies qui les supportent9
. Dans le
domaine du cloud computing, cette question est centrale dès lors que de nombreux services sont
fournis par de grands acteurs internationaux (AWS, Microsoft Azure, Google Cloud). Le
recours à ces plateformes peut exposer les organisations à des législations extraterritoriales
(comme le CLOUD Act) et créer une dépendance technologique, voire un verrouillage
propriétaire, qui limite la possibilité de migrer vers d’autres solutions ou d’interconnecter des
services.
Pour réduire cette dépendance, plusieurs pays cherchent à développer des solutions de
cloud souverain ou à héberger leurs services dans des infrastructures locales. C’est le cas au
Sénégal, où le data center de Diamniadio, porté par l’ADIE, offre une capacité d’hébergement
national pour les administrations et les entreprises, dans une logique de maîtrise des données et
de continuité de service.
Cependant la souveraineté ne repose pas uniquement sur la possession de
l’infrastructure elle suppose aussi une gouvernance claire, des compétences locales capables
d’administrer les plateformes et l’usage de technologies ouvertes favorisant l’interopérabilité.
Elle permet aux organisations de contrôler leur environnement tout en restant conformes aux
exigences réglementaires.
1.2.3.4. Défis humains et organisationnels
L’adoption du cloud computing dépend aussi de la capacité des organisations à les
administrer et à les faire accepter en interne. Dans un contexte émergent, les freins sont souvent
d’ordre humain avec un manque de compétence à la sécurité des infrastructures, à
9
Frédéric Soulé, La souveraineté numérique en Afrique : dépasser la question des données locales, CIGI Institute

6
l’automatisation des déploiements ou encore à la supervision d’environnements distribués.
Cette faible disponibilité des compétences limite l’exploitation du cloud.
À cela s’ajoutent des enjeux de gouvernance, la complexité des environnements exige
une gouvernance adaptée pour assurer la cohérence entre la maîtrise des coûts et la conformité
réglementaire. L’absence de visibilité globale sur les ressources déployées souvent réparties
entre plusieurs fournisseurs et accroît les risques de dérives budgétaires ou de failles de sécurité.
1.3. Problématique
L’adoption du cloud computing transforme donc profondément les modèles techniques,
économiques et organisationnels des entreprises. A l’échelle mondiale il permet aux
organisations d’accéder à des ressources informatiques à la demande par Internet tout en
optimisant leurs coûts d’exploitation .
Cependant, dans les économies émergentes, cette transition demeure confrontée à
plusieurs contraintes : infrastructures limitées, coûts élevés, compétences techniques
insuffisantes, cadres réglementaires peu matures et des enjeux croissants de souveraineté
numérique.
Dès lors, la question essentielle est la suivante :
Comment concevoir et mettre en place une solution cloud computing sécurisée et
interopérable capable de répondre aux besoins techniques, économiques et réglementaires
d’une organisation locale ?
Pour y répondre, cette étude s’articule autour des interrogations suivantes :
● Quels modèles d’architecture cloud permettent de concilier performance, conformité
et optimisation des coûts ?
● Quelles approches technologiques favorisent une migration fluide et durable vers le
cloud ?
● Comment intégrer les exigences de sécurité et de conformité réglementaire dans une
infrastructure locale ?
● Comment assurer l’interopérabilité entre les services cloud et les systèmes existants ?

7
1.4. Objectifs du mémoire
Les objectifs de ce mémoire orienteront la conception, la mise en œuvre et l’évaluation
d’une solution de cloud computing adaptée au contexte d’une organisation locale. Ils traduisent
la problématique en un ensemble de services techniques à déployer.
1.4.1. Objectif général
L’objectif général est de concevoir et mettre en place une solution cloud computing
sécurisée et interopérable, capable de répondre aux besoins techniques, économiques et
réglementaires d’une organisation locale.
1.4.2. Objectifs spécifiques
Pour atteindre cet objectif général, les objectifs spécifiques suivants ont été définis sous
formes de services :
• Service 1 : Gestion unifiée des identités et des accès (IAM)
Intégrer un mécanisme d’authentification et de contrôle des accès afin de renforcer la sécurité
des utilisateurs et de faciliter l’administration des services.
• Service 2 : Stockage sécurisé et souverain des fichiers
Déployer un stockage local/privé (NAS / NFS) permettant d’héberger les données sensibles de
l’organisation, avec un contrôle sur leur localisation et leur intégrité.
• Service 3 : Supervision et journalisation centralisée
Prévoir un dispositif de monitoring afin d’assurer la traçabilité des événements et la détection
des incidents de sécurité.
• Service 4 : Sauvegarde et restauration des données
Mettre en place l’infrastructure nécessaire (stockage partagé, politique de sauvegarde) pour
permettre la sauvegarde et la restauration des services critiques.
• Service 5 : Réseau privé virtuel (VPN interne)

8
Déployer ou préparer un accès VPN sécurisé vers l’infrastructure cloud afin de permettre
l’accès distant ou l’interconnexion de sites dans un contexte d’infrastructures limitées.
• Service 6 : Portail web d’administration et d’accès aux services
Proposer une interface web centralisée pour administrer les ressources, faciliter leur
supervision et garantir l’interopérabilité entre les différents services.
1.5. Intérêts du sujet
1.5.1. Intérêts pour l’entreprise
Pour l’entreprise, l’adoption d’une solution de cloud computing représente une
évolution technologique majeure et un levier de compétitivité surtout dans notre contexte local.
Elle lui permettra de se concentrer davantage sur l’innovation des services. Grâce à une
scalabilité rapide, l’entreprise gagnera en agilité et pourra répondre plus efficacement aux
variations de la demande des clients. Enfin, l’accès à des services innovants permettra de
nouvelles perspectives de développement, notamment en renforçant la valeur ajoutée et la
qualité des services proposés.
1.5.2 Intérêts pour l'étudiant
Pour nous, ce projet constitue une opportunité de mettre en pratique nos expériences et
compétences acquises durant notre cursus. Il nous permettra d’acquérir une méthodologie de
déploiement d’infrastructures, depuis l’analyse de l’existant jusqu’aux tests techniques. Il nous
offrira également une expérience concrète et un atout professionnel considérable en renforçant
notre employabilité sur le marché du travail.
En conclusion, ce chapitre a permis de présenter le contexte global et régional de la
transformation numérique à travers l’adoption du cloud computing, en identifiant différents
enjeux notamment économiques, réglementaires, souverains et humains qui en découlent.

9
Chapitre 2 : État de l’art et solutions existantes
Ce chapitre présente l’état de l’art et les principales solutions en matière de cloud
computing, dans le but d’établir une base technique et conceptuelle pour la conception de notre
propre solution. À la suite de la problématique posée à savoir comment concevoir et mettre en
place une solution cloud sécurisée et interopérable adaptée aux contraintes techniques,
économiques et réglementaires d’une organisation locale.
Ce chapitre analysera donc d’abord les fondamentaux techniques et réseaux qui ont
permis le passage des infrastructures informatiques traditionnelles vers le cloud. Il définira
ensuite les critères retenus pour comparer les plateformes existantes, avant de proposer une
analyse des principales solutions afin de justifier le choix technologique final.
2.1. Fondamentaux techniques et réseaux pour le cloud
La transition vers le cloud est le résultat d’une évolution progressive des infrastructures
informatiques. À l’origine, l’informatique d’entreprise reposait sur les mainframes, des
ordinateurs centraux très puissants, mais coûteux, peu flexibles et accessibles uniquement via
des terminaux passifs. Dans les années 1980-1990, l’architecture client/serveur a apporté
davantage de souplesse en répartissant le traitement entre les postes utilisateurs et les serveurs,
mais elle a aussi complexifié l’administration et la maintenance10
.
Pour dépasser ces limites, la virtualisation s’est imposée. En introduisant une couche
logicielle entre le matériel et les systèmes d’exploitation, elle permet d’exécuter plusieurs
machines virtuelles (VM) sur un même serveur physique. Cette approche améliore le taux
d’utilisation des ressources, réduit les coûts matériels et surtout rend le déploiement de services
beaucoup plus agile. C’est cette capacité à découpler les ressources physiques de leur usage
applicatif qui fait de la virtualisation la base du cloud computing11
.
Parallèlement, l’émergence de réseaux plus segmentés et plus sécurisés (VLAN,
routage, pare-feu) a permis d’exposer ces ressources virtualisées de manière contrôlée, ce qui
est indispensable dans un environnement cloud multi-utilisateurs.
10
IBM Think, Qu’est-ce que le mainframe ?
11
IBM Think, Qu’est-ce que la virtualisation ?

10
2.1.1. La virtualisation
La virtualisation est une technologie clé qui consiste à créer des versions logicielles de
ressources physiques (serveurs, stockage, systèmes d’exploitation ou réseaux) à l’aide d’un
logiciel appelé hyperviseur12. Celui-ci introduit une couche d’abstraction entre le matériel et
les machines virtuelles (VMs), ce qui permet à plusieurs environnements isolés de fonctionner
simultanément sur un même serveur physique.
Chaque VM dispose de son propre système d’exploitation (OS) et de ses applications,
tout en partageant le processeur, la mémoire, le réseau et le stockage. Cette séparation logique
offre une indépendance vis-à-vis du matériel, une grande flexibilité et une scalabilité adaptées
aux exigences du cloud computing.13
Figure 1 : Structure représentative de la virtualisation (Type2)
2.1.2. Les hyperviseurs
L’hyperviseur est le composant central de la virtualisation. Il crée, exécute et isole les machines
virtuelles tout en gérant l’allocation des ressources. On distingue deux grandes catégories :
12
IBM, qu’est-ce que la virtualisation ?
13
IBM, qu’est-ce qu’un hyperviseur ?

11
• Hyperviseur de type 1 (bare-metal) : Installé directement sur le serveur physique, il gère
les systèmes d’exploitation invités sans passer par un OS hôte. Sa proximité avec le matériel
lui confère de meilleures performances et une meilleure stabilité.14
Ce type d’hyperviseur
est utilisé dans les datacenters.
Figure 2 : Schéma d’un hyperviseur de type 1
• Hyperviseur de type 2 : Installé au-dessus d’un système d’exploitation existant (Windows,
Linux, macOS), il fonctionne comme une application. Il est moins performant mais très
pratique pour les environnements de test, de formation ou de maquette, comme ceux que
nous avons utilisés pour simuler notre infrastructure.
Figure 3 : Schéma d’un hyperviseur de type 2
14
Amazon Web Services, la différence entre les hyperviseurs de type 1 et de type 2

12
2.1.3. Les avantages de la virtualisation
La virtualisation constitue aujourd’hui la base du cloud computing en permettant la
mutualisation et la gestion dynamique des ressources15
. Ses principaux avantages sont les
suivants :
1. Optimisation des ressources
Plusieurs VMs peuvent coexister sur un même serveur tout en utilisant de manière plus
complète le processeur, la mémoire et le stockage pour réduire le gaspillage énergétique et
améliorer l’efficacité de l’infrastructure.
2. Flexibilité et agilité
Les machines virtuelles peuvent être créées, clonées, migrées ou supprimées en quelques
instants, ce qui accélère la mise en service des applications et la réponse aux besoins métiers.
3. Réduction des coûts
En limitant l’achat de serveurs physiques et en améliorant leur taux d’utilisation, la
virtualisation réduit les CAPEX (investissement) et les OPEX (énergie, maintenance, espace),
pour contribuer à un modèle économique plus durable.
4. Sécurité et portabilité
L’isolation entre VMs limite la propagation des pannes ou attaques. Les VMs peuvent être
déplacées vers un autre hôte ou vers un cloud privé/public sans modification majeure, ce qui
favorise la continuité de service.
2.1.4. Les types de virtualisation
En tenant compte de ces avantages, il faut préciser que la virtualisation s’est déclinée en
plusieurs formes selon les besoins techniques et les objectifs d’exploitation. Chaque type
15
Portworx, Les principaux avantages de la virtualisation.

13
répond à une problématique précise (performance, sécurité, flexibilité, continuité de service) et
contribue à faire évoluer les systèmes d’information vers le modèle cloud16
.
• Virtualisation des serveurs
Elle consiste à exécuter plusieurs serveurs virtuels sur une même machine physique à l’aide
d’un hyperviseur. Chaque serveur virtuel fonctionne de manière indépendante avec son propre
système d’exploitation et ses applications, tout en partageant les ressources du matériel hôte
(CPU, RAM, stockage). Cette approche réduit le nombre de serveurs physiques, optimise les
ressources et simplifie l’administration de l’infrastructure. C’est le principe utilisé dans les
datacenters et dans les solutions de cloud privé,
• Virtualisation des postes de travail (VDI)
La virtualisation des postes de travail consiste à ce que les environnements utilisateurs
soient hébergés sur un serveur central et accessibles à distance via un client léger ou un
navigateur. Les sessions sont isolées mais mutualisent les ressources, pour faciliter la
maintenance, renforcer la sécurité de l’environnement et permettre la mobilité des utilisateurs.
Ce modèle est particulièrement adapté aux entreprises, administrations pour réduire les coûts
matériels et favoriser la mobilité.
• Virtualisation du stockage
Elle regroupe plusieurs ressources de stockage physiques (disques locaux, NAS) en un
espace logique unique accessible par les serveurs ou VMs. Elle simplifie la gestion des volumes,
améliore la résilience et permet d’augmenter la capacité sans interrompre le service. Des
solutions comme les réseaux SAN ou VMware vSAN, mais aussi des NAS associé à un partage
NFS, permettent de constituer des pools de stockage partagés pour les environnements
virtualisés pour assurer la haute disponibilité.
• Virtualisation du réseau
La virtualisation du réseau vise de créer des réseaux virtuels indépendants de l’infrastructure
physique, afin de segmenter et sécuriser les flux de communication. Elle est basée sur des
mécanismes comme les VLANs, elle autorise la séparation logique des services sans multiplier
16
IBM, qu’est-ce que la virtualisation ?

14
le matériel. Cette approche prépare la transition vers des réseaux Software-Defined
Networking (SDN), actuellement très utilisés dans les architectures cloud modernes.
• Virtualisation des applications
Elle consiste à exécuter des applications dans des environnements isolés sans installation
locale. Les applications sont empaquetées avec leurs dépendances puis diffusées aux
utilisateurs, ce qui réduit les conflits logiciels et facilite les mises à jour.
• Virtualisation des données
Elle offre une vue logique unifiée de données provenant de sources hétérogènes sans les
déplacer physiquement. Elle est utilisée dans les contextes analytiques ou Big Data pour
faciliter l’accès et l’exploitation des informations.
Figure 4 : Illustration récapitulative des types de virtualisation
L’étude de ces différentes formes montre qu’elles sont complémentaires et qu’elles
interviennent à des niveaux distincts, tout en permettant à l’infrastructure d’être plus flexible,
mieux utilisable. Dans la section suivante, nous présenterons donc les principaux outils de
virtualisation, afin d’identifier ceux qui sont les plus adaptés à la mise en place de notre solution.

15
2.1.5. Les outils de virtualisation
Dans le cadre de la mise en place de notre solution de cloud computing, le choix
s’oriente principalement vers la virtualisation de serveurs, puisqu’elle constitue la base
technique de toute infrastructure cloud17
. Il est donc nécessaire d’identifier les outils les plus
adaptés, capables d’assurer résilience, scalabilité, et interopérabilité. Les solutions de
virtualisation de postes de travail seront également mentionnées.
On distingue deux grandes catégories :
• Solutions de virtualisation serveur : conçues pour les environnements de production et
les infrastructures cloud. Elles offrent des fonctions avancées (haute disponibilité,
migration)18
• Solutions de virtualisation poste de travail : destinées aux usages individuels, à la
formation ou aux tests. Elles sont simples à installer et compatibles multi-OS, mais ne
proposent pas le même niveau de résilience ni d’évolutivité.
17
IBM Think, Comprendre la virtualisation
18
Microsoft, Virtualisation Hyper-V dans Windows Server, Microsoft Learn

16
Tableau 1 – Solutions de virtualisation serveur (orientées cloud et production)
Critères /
Solutions
VMware
vSphere /
ESXi
Microsoft
Hyper-V
Proxmox
VE 19
Citrix
Hypervisor
KVM20
Red Hat
Virtualization
(RHV)
Type
d’hyperviseur
Type 1
(bare-metal)
Type 1 Type 1
(bare-metal
+
conteneurs)
Type 1 Type 1 intégré
Linux
Type 1 basé
KVM
Licence Commercial Inclus
Windows
Open
source
(AGPL)
Commercial Open source
(GPL)
Abonnement
Red Hat
Compatibilité
OS
Windows,
Linux
Windows Linux Windows,
Linux
Linux Linux (RHEL,
SuSE)
Interface de
gestion
vCenter /
Web
SCVMM Interface
web
Citrix
Studio
Virt-Manager RHV Manager
Haute
disponibilité
Oui
(vMotion,
DRS)
Oui Oui (Ceph,
cluster)
Oui Oui Oui
Sécurité /
conformité
TPM,
chiffrement
VM
BitLocker ACL, Ceph RBAC SELinux SELinux,
RBAC
Interopérabilité
/ API
REST,
NSX,
OpenStack
Azure
API
OpenStack,
Terraform
XenAPI OpenStack,Libvirt
API
OpenStack
Compatibilité
stockage
SAN, NAS,
NFS
SMB,
iSCSI
Ceph, ZFS NFS, iSCSI LVM, Ceph SAN, NFS
Scalabilité Excellente Moyenne Élevée Moyenne Élevée Élevée
TCO (Coût
total
d’exploitation)
Élevé Moyen Faible Élevé Faible Moyen
19
PVE : Plateforme de virtualisation open source basée sur Debian Linux, intégrant KVM pour les machines
virtuelles et LXC pour les conteneurs
20
KVM : Kernel-based Virtual Machine est une technologie de virtualisation intégrée au noyau Linux,
transformant celui-ci en hyperviseur de type 1.

17
L’analyse met en évidence deux orientations principales :
• Les solutions open source (Proxmox VE, KVM) offrent un bon compromis entre
performance, flexibilité et coût total d’exploitation. Elles s’intègrent bien avec des
technologies cloud natives (OpenStack, Ceph) et conviennent mieux aux contextes à budget
limité ou à exigences de souveraineté.
• Les solutions commerciales (VMware vSphere, RHV) sont riches en fonctionnalités, mais
leur coût peut être un frein dans un contexte d’organisation locale.21
Ainsi, dans le cadre d’une approche visant à concevoir notre infrastructure cloud, les
hyperviseurs Proxmox VE et KVM apparaissent comme les choix les plus pertinents.
Tableau 2 – Virtualisation poste de travail (usage individuel / test)
Ces outils sont adaptés aux environnements de test, mais ne sont pas conçus pour
supporter une infrastructure cloud en production.
En somme, cette étude met en avant que le recours à un hyperviseur serveur open source, peut
être le choix le plus pertinent pour un contexte local a cause des coûts maîtrisés, l’hébergement
local, et leur interopérabilité possible avec d’autres technologies. Cette base ouvre sur la partie
suivante, consacrée aux modèles de cloud computing et aux modes de déploiement.
21
VMware, VMware vSphere – Plateforme de virtualisation
Critères / Solutions Oracle VM VirtualBox VMware Workstation Pro
Type d’hyperviseur Type 2 (hosted) Type 2 (hosted)
Licence Open source (GPL) Commercial
Compatibilité OS Windows, Linux, macOS Windows, Linux
Interface de gestion Interface graphique locale Interface graphique locale
Haute disponibilité Non (usage individuel) Non (usage individuel)
Fonctionnalités Gratuit, large compatibilité Haute performance, support 3D

18
2.2. Le Cloud Computing
Dans le chapitre précédent, le cloud computing a été présenté comme un modèle d’accès
à des ressources informatiques partagées, disponibles à la demande et accessibles via le réseau.
Pour concevoir notre propre solution, il est nécessaire de préciser ce que le cloud met réellement
à disposition (modèles de services) et de quelles façons il peut être déployé (modèles de
déploiement). Les modèles de services décrivent ce que le cloud fournit, tandis que les modèles
de déploiement décrivent où et sous quel contrôle ces services sont exécutés.
2.2.1. Les différents services du Cloud Computing
Le modèle du cloud computing repose sur trois niveaux de services complémentaires :
● Infrastructure as a Service (IaaS)
● Platform as a Service (PaaS)
● Software as a Service (SaaS)
Cette structuration va de l’infrastructure vers l’usage : les équipes systèmes travaillent surtout
au niveau IaaS, les développeurs exploitent le PaaS, et les utilisateurs finaux consomment le
SaaS.22
Figure 5 : Schéma récapitulatif des modèles de services du Cloud Computing
22
Microsoft, Qu’est-ce que l’IaaS, le PaaS et le SaaS ?, Dictionnaire du cloud computing Azure, Microsoft Azure

19
Infrastructure as a Service (IaaS)
L’IaaS fournit des ressources virtualisées (machines, stockage, réseau) à la demande.
L’organisation n’achète plus le serveur physique mais alloue les ressources nécessaires au
moment voulu. Ce modèle favorise la flexibilité et le passage du CAPEX vers l’OPEX. Des
services comme Amazon EC2 ou Azure Virtual Machines en sont des exemples dans le cloud
public. Dans notre contexte, c’est ce niveau qui nous intéresse le plus, car il correspond à la
mise à disposition d’une infrastructure virtuelle dans un environnement maîtrisé (cloud privé).
Platform as a Service (PaaS)
Le PaaS met à disposition un environnement complet pour développer, tester et déployer
des applications sans gérer les serveurs sous-jacents : frameworks, bases de données,
intégration. Le développeur se concentre sur la logique métier, la plateforme gère la montée en
charge et la maintenance. Il peut être public (Google App Engine, Heroku) ou privé lorsqu’il
est hébergé dans le datacenter de l’organisation, pour plus de contrôle et de conformité.
Software as a Service (SaaS)
Le SaaS fournit directement l’application prête à l’emploi via Internet (Microsoft 365,
Google Workspace, Dropbox). L’utilisateur n’administre pas l’infrastructure c’est le
fournisseur qui gère l’hébergement, les mises à jour et la sécurité. Ce modèle est très répandu
pour les services collaboratifs et bureautiques.
Figure 6 : Répartition des responsabilités entre client et fournisseur selon le modèle de service

20
2.2.2. Architecture Fondamentale d'un Cloud
Les modèles de services (IaaS, PaaS, SaaS) précisent le niveau de responsabilité entre le
fournisseur et l’utilisateur. L’architecture technique décrit comment un cloud est construit, elle
se divise en deux parties :
• Front-end : c’est l’interface d’accès au cloud (portail web, API, application). Dans
notre cas, il s’agira du portail d’administration permettant de créer et gérer les ressources
(S6).
• Back-end : c’est le cœur du cloud, là où sont gérés les serveurs, le stockage, le réseau,
et la sécurité de l’infrastructure.
Le Back-End d’un IaaS peut être décrit en plusieurs couches :
1. Couche d’infrastructure physique : regroupe le matériel concret les serveurs, baies de
stockage, équipements réseau.
2. Couche de virtualisation (hyperviseur) : assure l’abstraction du matériel et la création des
ressources virtuelles (CPU, RAM, disques, interfaces réseau).
3. Couche de gestion et d’orchestration (Cloud Management Platform) : C’est la couche
logicielle qui fait “le cloud”, elle automatise la création des VMs, gère le stockage partagé,
définit et applique les configurations réseau expose un portail web d’administration
4. Couche de sécurité transversale : Elle recouvre les mécanismes d’authentification,
d’autorisation, de chiffrement, de journalisation et de filtrage réseau. Elle s’applique à
toutes les autres couches et garantit l’isolement entre les tenants/utilisateurs.

21
Figure 7 : Schéma de l'architecture d'une pile IaaS (Back-End)
2.2.3. Les modèles de déploiement dans le Cloud Computing
Après les modèles de services, les modèles de déploiement précisent où et sous quel
niveau de contrôle les ressources cloud sont hébergées. Le choix du modèle dépend du besoin
de souveraineté, du budget, du niveau de sécurité attendu et de la capacité de l’organisation à
administrer son infrastructure. On distingue quatre modèles principaux : cloud privé, cloud
public, cloud hybride et cloud communautaire.
2.2.3.1. Le Cloud privé
Le cloud privé est une infrastructure dédiée à une seule organisation. Il offre un contrôle total
sur l’environnement informatique, y compris la sécurité des données, la gestion des accès et la
personnalisation de l’infrastructure.
Selon la gestion et l’emplacement, il y’a deux formes :

22
● Cloud privé sur site (on-premise) : hébergé dans le datacenter interne de l’entreprise,
garantissant une maîtrise complète du matériel ;
● Cloud privé externalisé : hébergé chez un prestataire tiers, mais isolé et réservé à
l’organisation.
Techniquement, il repose sur les mêmes briques que le cloud public (virtualisation,
automatisation, portail), mais déployées dans l’environnement de l’organisation, avec des outils
comme VMware vSphere, KVM ou Proxmox VE.
Ses principaux atouts sont la maîtrise des données, la personnalisation et la
conformité. Ses limites résident dans le coût d’investissement initial (serveurs, stockage,
compétences) et dans une scalabilité liée aux ressources physiques disponibles. C’est toutefois
le modèle le plus pertinent pour les organisations locales recherchant souveraineté et intégration
forte. C’est ce modèle que nous retiendrons pour notre solution.
2.2.3.2. Le Cloud public
Le cloud public est opéré par un fournisseur (AWS, Azure, GCP) qui mutualise
l’infrastructure entre plusieurs clients. L’organisation consomme les services à la demande sans
gérer le matériel. Ses forces sont la scalabilité quasi illimitée, le paiement à l’usage et la rapidité
de mise en service. Ses faiblesses, dans notre contexte, sont la dépendance au fournisseur, la
localisation parfois étrangère des données et l’application de cadres juridiques
extraterritoriaux. Il reste adapté aux charges variables et aux services non sensibles.
2.2.3.3. Le Cloud hybride
Le cloud hybride combine un cloud privé (pour les données ou services sensibles) et un
cloud public (pour l’élasticité, les pics de charge). Il apporte une bonne flexibilité mais au prix
d’une plus grande complexité de gestion (réseau, sécurité, supervision entre environnements).
Il convient surtout aux organisations ayant déjà une base d’infrastructure et souhaitant l’étendre
sans perdre le contrôle.
2.2.3.4. Le Cloud communautaire
Le cloud communautaire est partagé par plusieurs organisations d’un même secteur (santé,
éducation, administrations) qui ont les mêmes contraintes de sécurité ou de conformité. Il

23
permet de mutualiser les coûts et d’aligner les politiques d’accès, mais nécessite une
gouvernance commune et reste limité au périmètre de la communauté.
Tableau 3 - Synthèse comparative des modèles de déploiement
Critères Cloud
Privé
Cloud Public Cloud
Hybride
Cloud
Communautaire
Contrôle /
Souveraineté
Très élevé Faible à moyen Équilibré Élevé (partagé)
Sécurité /
Confidentialité
Renforcée Bonne Élevée si bien
gérée
Élevée (gouvernance
commune)
Coût
d’investissement
Élevé Faible à moyen Variable Moyen à élevé
Évolutivité /
Scalabilité
Moyenne Très élevée Élevée Moyenne
Interopérabilité /
Intégration
Forte Variable Forte Bonne
Cette comparaison montre que, dans un contexte où la localisation des données et la
maîtrise des coûts sont prioritaires, le cloud privé(on-premise) est le modèle le plus adapté.
C’est donc ce modèle qui servira de référence pour la conception de notre solution dans les
chapitres suivants.
2.2.4. La notion de Datacenter
L’essor du cloud computing s’appuie sur une réalité très concrète : derrière chaque
“nuage” se trouvent des centres de données physiques. Un centre de données (datacenter)
peut être défini comme un site physique (bâtiment, étage ou salle dédiée) composée de
l’ensemble des ressources nécessaires au fonctionnement continu des systèmes d’information :
serveurs, baies de stockage, équipements réseau et télécoms, systèmes d’alimentation et

24
de refroidissement, dispositifs de sécurité et de supervision, que les entreprises utilisent pour
organiser, traiter, stocker et diffuser de grandes quantités de données.23
Dans le cloud computing, le datacenter représente le socle physique sur lequel reposent les
couches de virtualisation, d’orchestration et de services. La qualité du cloud (performance,
disponibilité, sécurité) dépend donc directement de la conception et de l’exploitation du
datacenter sous-jacent.
2.2.4.1. Architecture et principaux composants d’un datacenter
Un datacenter moderne est un ensemble cohérent d’infrastructures techniques, organisé pour
garantir en permanence l’alimentation électrique, le refroidissement, la connectivité réseau
et la protection des équipements informatiques.
On y retrouve généralement :
• Les salles informatiques (salles blanches) où sont installés les baies et racks accueillant
les serveurs, les équipements de stockage et les équipements réseau (commutateurs,
routeurs, firewalls). Ces salles sont conçues pour limiter la poussière, stabiliser la
température et l’hygrométrie et faciliter la circulation de l’air.
• Les racks : structures métalliques normalisées qui permettent d’installer de manière
ordonnée les serveurs, onduleurs, panneaux de brassage et autres équipements.
L’utilisation de racks optimise l’occupation de l’espace et le refroidissement.
• Les systèmes de stockage : Les baies de disques systèmes SAN (Storage Area Network)
ou NAS (Network Attached Storage), qui sont accessibles via des protocoles comme NFS
hébergent les données, les VMs et les sauvegardes. Ils sont au cœur des infrastructures
cloud, car ils supportent à la fois le stockage des volumes des VMs, des fichiers applicatifs,
et des données utilisateurs. Leur conception (redondance des disques, RAID, réplication)
contribue directement au niveau de disponibilité global du datacenter.
• L’alimentation électrique principale : elle fournit l’énergie nécessaire à l’ensemble du
site à partir du réseau public. Pour éviter toute coupure brutale, elle est complétée par des
systèmes de secours.
• Les systèmes d’alimentation sans interruption (UPS/ASI) qui servent de tampon en cas
de microcoupures ou de coupure brève. Ils assurent la continuité électrique pendant le
23
Cisco, Qu’est-ce qu’un centre de données ? glossaire Cisco

25
temps nécessaire au basculement sur les groupes électrogènes ou à l’arrêt contrôlé des
systèmes.
• Les sources d’alimentation de secours (groupes électrogènes, batteries, double arrivée
électrique) qui prennent le relais lors des coupures prolongées et permettent de maintenir
le datacenter en fonctionnement pendant plusieurs heures ou jours, selon la capacité
prévue.
• Les systèmes de refroidissement et de climatisation (climatiseurs de précision, allées
chaudes/allées froides, systèmes de confinement) qui évacuent la chaleur produite par les
équipements IT. La maîtrise de la température et de l’humidité est essentielle pour garantir
la longévité et la fiabilité des matériels.
• Le câblage et l’infrastructure réseau : câbles cuivre et fibre optique, panneaux de
brassage, chemins de câbles, liaisons vers les opérateurs télécoms et vers les autres sites.
Cet ensemble assure la connectivité à Internet, aux autres sites de l’organisation et aux
utilisateurs.
• Les systèmes de détection et de protection incendie (capteurs, alarmes, systèmes
d’extinction adaptés à l’électronique) qui visent à détecter au plus tôt tout départ de feu et
à le maîtriser sans détruire les équipements.
• Les systèmes de supervision (énergie, environnement, charge des serveurs, état des liens
réseau) qui permettent aux équipes IT de surveiller en temps réel l’état du datacenter et de
réagir rapidement en cas d’anomalie.
Dans le contexte d’un cloud privé, ces différents éléments sont dimensionnés pour permettre
l’hébergement d’une infrastructure virtualisée, la mise en place de stockage partagé, de
réseaux segmentés (VLAN) et de services critiques tout en garantissant un niveau de
disponibilité conforme aux besoins métier.

26
Figure 8 : Schéma fonctionnel d’un data center
Figure 9 : Composant critique d’un data center : infrastructure en rack

27
2.2.4.2. Typologie et niveaux de disponibilité des datacenters
Tous les datacenters ne fournissent pas le même niveau de service. Selon leur conception et
le degré de redondance des infrastructures (alimentation, refroidissement, réseau), ils offrent
des niveaux de disponibilité différents. Des référentiels internationaux proposent des niveaux
(tiers) qui vont généralement de I à IV :
• Un datacenter de niveau I correspond à une infrastructure de base, avec un chemin
d’alimentation unique et peu de redondance. Une panne électrique ou un incident sur un
équipement critique peut entraîner une interruption de service. Ce niveau est souvent
rencontré dans les petites structures.
• Un datacenter de niveau II introduit des composants redondants (UPS supplémentaires,
groupes électrogènes, climatisation redondante). Il offre un meilleur taux de disponibilité,
mais reste vulnérable à certains travaux de maintenance.
• Un datacenter de niveau III est conçu de manière à être maintenable simultanément :
chaque composant critique (alimentation, climatisation, réseau) dispose au moins d’un
chemin de secours permettant de réaliser des travaux sans arrêter les services. Les
interruptions non planifiées sont fortement réduites.
• Un datacenter de niveau IV va plus loin en intégrant une tolérance aux pannes sur
l’ensemble de la chaîne énergétique et de refroidissement. Il est conçu pour assurer une
disponibilité très élevée, même en cas de défaillance simultanée de plusieurs éléments.
Les centres de données sont aussi classés selon le temps de disponibilité comme suit :
• Centre de données de niveau I(disponibilité minimale de 99,611%)
• Centre de données de niveau II(disponibilité minimale de 99,741%)
• Centre de données de niveau III(disponibilité minimale de 99,982%)
• Centre de données de niveau IV (disponibilité minimale de 99,995%)
Plus le niveau est élevé, plus la disponibilité est grande.24
24
Scalaire, « Les différentes classifications d’un datacenter (Tiers I à IV) »

28
2.2.4.3. Sécurité et sûreté des centres de données
En plus de la continuité de service, un datacenter doit assurer un haut niveau de sécurité
et de sûreté, car il concentre des ressources sensibles : données, applications critiques,
équipements coûteux. La sécurité d’un datacenter s’envisage à la fois sur le plan physique et
logique.
Sur le plan physique, plusieurs mesures sont généralement mises en œuvre :
• Contrôle d’accès : Les accès aux locaux exigent des badges, des codes, biométrie des
procédures d’enregistrement. Seules les personnes habilitées peuvent pénétrer dans les
salles techniques.
• Zonage des espaces : La séparation entre les zones publiques (accueil, bureaux), les zones
techniques (local électrique, climatisation) et les salles informatiques, avec des niveaux de
sécurité croissants.
• Vidéosurveillance et détection d’intrusion : Les caméras, les enregistrements, et les
alarmes permettent de détecter les actes malveillants ou les comportements suspects.
• Supervision environnementale : Les capteurs de température, d’humidité, de fumée, de
fuite d’eau, sont présents afin de prévenir les incidents matériels.
Sur le plan logique, la sécurité du datacenter s’intègre dans une démarche globale de sécurité
du cloud avec :
• La segmentation du réseau : Elle permet de séparer le réseau en plusieurs parties
(VLAN, DMZ, réseau d’administration) pour limiter les déplacements d’un pirate en cas
d’attaque.
• Mise en place de pare-feux et de systèmes de détection/prévention d’intrusion
(IDS/IPS) : Pour appliquer des règles de filtrage strictes entre les zones du réseau
(utilisateurs, serveurs, administration) permet de mieux contrôler les accès et bloquer les
attaques.
• Gestion des identités et des accès : Pour gérer les comptes, les droits d’accès et les
actions des utilisateurs en lien avec les services IAM du cloud comme LDAP.
• Chiffrement des données : les données sensibles sont cryptées au repos sur des disques
ou une partition de stockage et en transit via VPN pour se protéger des interceptions ou
des vols physiques de supports.

29
• Journalisation et supervision : Elle va permettre d’enregistrer et surveiller les
événements (logs système, applicatifs, sécurité) permet de repérer les anomalies,
comprendre les incidents et répondre aux audits.
Enfin, les bonnes pratiques de sécurité des datacenters et des clouds privés s’inscrivent
souvent dans le cadre des normes comme ISO 27001. 25
2.2.5. Les technologies complémentaires du Cloud
L’évolution du cloud computing ne repose pas uniquement sur la virtualisation des serveurs.
Elle s’est enrichie de technologies qui facilitent la portabilité des applications, l’automatisation
et la montée en charge : la conteneurisation et l’orchestration. Ces technologies sont très
présentes dans les architectures cloud modernes et constituent une étape naturelle au-delà de la
simple virtualisation.
2.2.5.1. La conteneurisation
La conteneurisation consiste à encapsuler une application et ses dépendances
(bibliothèques, configurations, variables d’environnement,) dans un environnement isolé
appelé conteneur26. Contrairement aux VMs, les conteneurs partagent le noyau du système
hôte tout en restant isolés les uns des autres grâce à plusieurs mécanismes du noyau Linux :
● Namespaces : fournissent une vue isolée du système (processus, réseau etc.) empêchant
un conteneur d’accéder aux ressources d’un autre ;
● Cgroups (Control Groups) : limitent et surveillent la consommation de ressources par
les conteneurs ;
● UnionFS (système de fichiers en couches) : permet de partager des fichiers communs
tout en enregistrant les modifications spécifiques à chaque conteneur dans des couches
distinctes.
Ces mécanismes rendent les conteneurs légers, rapides à déployer et faciles à répliquer, ce
qui favorise leur portabilité entre différents environnements cloud. L’outil de conteneurisation
25
La norme ISO/IEC 27001 définit les exigences pour mettre en place, maintenir et améliorer un système de
management de la sécurité de l’information (SMSI).
26
Docker, Qu’est-ce qu’un conteneur ? , Documentation Docker

30
le plus répandu est Docker, basé sur le moteur Docker Engine. Il permet de créer des images
standardisées et de les exécuter sous forme de conteneurs.
Grâce à la conteneurisation, une application peut être déplacée sans modification d’un
environnement à un autre par exemple du poste de développement au cloud, tout en conservant
son intégrité.
2.2.5.2. L’orchestration
Lorsque le nombre de conteneurs augmente, leur gestion manuelle devient complexe.
L’orchestration intervient alors pour automatiser le déploiement, la supervision et la résilience
des conteneurs.
L’outil de référence dans ce domaine est Kubernetes, une plateforme open source
développée initialement par Google27
. Kubernetes répartit automatiquement les charges de
travail entre les nœuds d’un cluster, surveille l’état des applications, redémarre les conteneurs
défaillants et gère la montée en charge. Il n’est pas systématiquement déployé dans toutes les
architectures cloud mais il s’intègre parfaitement aux architectures multi cloud et hybrides.
Figure 10 : Synthèse comparative des technologies complémentaires
27
Kubernetes, Vue d’ensemble – Concepts Kubernetes

31
En somme, la conteneurisation et l’orchestration complètent la virtualisation
traditionnelle en apportant une portabilité accrue des applications, plus d’agilité et résilience
des infrastructures cloud. Dans la section suivante, nous aborderons le rôle du réseau dans le
cloud computing, élément fondamental pour assurer connectivité, sécurité et performance.
2.3. L’architecture réseau dans le cloud
Le réseau dans le cloud computing, garantit la communication, la disponibilité et la
sécurité des services hébergés dans les infrastructures cloud (publiques, privées, hybrides ou
communautaires). Sans un réseau performant et bien structuré, aucun environnement cloud ne
pourrait offrir l’élasticité, la fiabilité ni la qualité de service attendues.28
Dans un cloud, le réseau relie l’ensemble des composants comme les serveurs
physiques, les VMs, les baies de stockage, pare-feux, passerelles, et utilisateurs distants pour
assurer une connectivité continue et sécurisée.
Sur le plan fonctionnel, il joue trois rôles essentiels :
● Connectivité et performance : garantir des communications rapides et stables via des
topologies optimisées, un adressage IP structuré et une segmentation logique du trafic ;
● Disponibilité et fiabilité : assurer la redondance et la continuité de service ;
● Sécurité et gouvernance : protéger les échanges, contrôler les accès et surveiller les
flux.
Il est donc essentiel dans la conception d’une infrastructure cloud dans cette section nous ferons
un rappel sur les bases essentielles du réseau, suivi de ses principes de gestion réseau et quelques
protocoles essentiels.
2.3.1. Rappel sur le réseau
Un réseau informatique est un ensemble d’équipements interconnectés (ordinateurs,
serveurs, routeurs, commutateurs, etc.) permettant le partage de données et de ressources.
2.3.2. Les types de réseaux
Les principaux types de réseaux sont :
28
Cisco, Réseautage cloud expliqué

32
● LAN (Local Area Network) : réseau local limité à un bâtiment ou un site ;
● WAN (Wide Area Network) : réseau étendu reliant plusieurs sites distants ;
● MAN (Métropolitain Area Network) : réseau métropolitain reliant plusieurs LAN au
sein d’une même ville ;
● VLAN (Virtual LAN) : réseau logique créé sur une infrastructure physique, permettant
de segmenter le trafic en sous-réseaux isolés.
2.3.3. Les topologies réseau
Une topologie réseau décrit la manière dont les équipements sont connectés entre eux.
Il y a deux types de topologie, la topologie logique qui est la manière dont les données vont
circuler sur le réseau. Et la topologie physique qui est le mode d'interconnexion physique des
différents éléments du réseau.
Les topologies actuelles sont les suivantes :
● Topologie en étoile : chaque équipement est relié à un point central (commutateur ou
routeur), simplifiant la gestion et la maintenance ;
● Topologie hiérarchique (en arbre) : organisée en couches (cœur, distribution, accès), elle
favorise la scalabilité et la séparation des rôles ;
● Topologie maillée : chaque nœud est interconnecté à plusieurs autres, assurant une forte
résilience ;
● Topologie hybride : combinaison de plusieurs structures pour profiter des avantages de
chacune ;
● Topologie virtualisée (VPC, overlays) : propre aux environnements cloud, elle permet de
créer des réseaux logiques indépendants de la couche physique, favorisant la flexibilité et
l’isolation des ressources.

33
Figure 11 : Schéma représentatif des topologies réseau
2.3.4. Les modèles de référence
La communication entre les équipements d’un réseau repose sur deux modèles fondamentaux :
● Le modèle OSI (Open System Interconnexion) est une architecture théorique à sept
couches de la couche physique (1) à la couche application (7).
● Le modèle TCP/IP : plus utilisé dans Internet et le cloud, il regroupe les fonctions en
quatre couches (Accès réseau, Internet, Transport, Application).
Figure 12 : Correspondance entre les modèles OSI et TCP/IP

34
2.3.5. L’adressage IP, la gestion réseau et les protocoles essentiels
La communication dans un environnement cloud repose sur des mécanismes
d’adressage, de routage et de gestion assurant la fiabilité et la sécurité des échanges entre les
équipements physiques ou virtuels.
L’adressage IP
L’Internet Protocol (IP) identifie chaque machine sur un réseau et permet le routage des paquets
vers leur destination. Deux versions coexistent :
● IPv4 (32 bits), encore majoritaire (ex. 192.168.1.1) ;
● IPv6 (128 bits), introduite pour pallier la pénurie d’adresses et améliorer la
performance.
Les adresses peuvent être statiques donc affectées manuellement aux serveurs critiques ou
dynamiques attribuées automatiquement via le DHCP (Dynamic Host Configuration
Protocol). L’IP se situe à la couche réseau (OSI) et à la couche Internet (TCP/IP). Il permet la
segmentation logique grâce au masque de sous-réseau et la communication inter-réseaux via la
passerelle par défaut.
Gestion du réseau
La gestion du réseau vise à maintenir la disponibilité, la performance et la sécurité des
communications dans l’infrastructure. Elle s’appuie sur :
● La segmentation VLAN (couche 2 – liaison de données), pour isoler les flux entre
production, administration et utilisateurs ;
● Le DNS (Domain Name System), qui traduit les noms de domaine en adresses IP,
améliorant la résilience et l’accès aux services ;
● Le DHCP, pour l’attribution dynamique d’adresses IP ;
● Les VPN (Virtual Private Network), pour un accès distant chiffré et sécurisé, assurant
la confidentialité des communications entre les environnements cloud et les utilisateurs.

35
Les protocoles essentiels
Un protocole réseau définit les règles d’échange de données entre équipements, le tableau
suivant présente les principaux protocoles utilisés dans les infrastructures cloud.
Tableau 4 - Principaux protocoles réseau
Catégorie Protocole Couches OSI /
TCP-IP
Ports Fonction principale
Protocoles de base IP OSI 3 / TCP-IP
Internet
— Adressage et routage des paquets.
TCP OSI 4 / TCP-IP
Transport
Dynamique Transmission fiable et ordonnée.
Accès &
communication
HTTP /
HTTPS
OSI 7 / TCP-IP
Application
80 / 443 Communication Web et transfert
sécurisé.
DNS OSI 7 / TCP-IP
Application
53
(TCP/UDP)
Résolution des noms de domaine.
DHCP OSI 7 / TCP-IP
Application
67 / 68 Attribution dynamique des
adresses IP.
Sécurité TLS / SSL OSI 7 / TCP-IP
Application
443 Chiffrement des communications.
SSH OSI 7 / TCP-IP
Application
22 Administration distante sécurisée.

36
2.4. Critères de comparaisons des solutions Cloud
Avant d’analyser les solutions existantes, il est nécessaire de définir les critères qui
permettront de juger leur adéquation avec notre problématique : concevoir et mettre en place
une solution de cloud computing, sécurisée et interopérable, adaptée aux contraintes
techniques, économiques et réglementaires d’une organisation locale. Nous avons montré
au chapitre 1, que certaines les organisations africaines évoluent dans un contexte marqué par
des infrastructures limitées, des coûts élevés, un manque de compétences et des exigences de
souveraineté et de conformité. Ces critères refléteront donc ces réalités.
Nous retiendrons deux familles de critères :
• des critères fonctionnels, qui correspondent directement aux services que la solution
doit offrir (S1 à S6 définis dans les objectifs) ;
• des critères non fonctionnels, qui apprécieront la qualité globale de la solution
(performance, sécurité, coût, maintenabilité, ouverture).
2.4.1. Les critères fonctionnels
Les critères fonctionnels traduisent les services indispensables pour qu’une organisation locale
puisse exploiter son cloud de manière sécurisée, maîtrisée et résiliente. Ils reprennent les six
services définis dans le chapitre 1.
1. Gestion unifiée des identités et des accès (S1)
La solution doit permettre de centraliser l’authentification et le contrôle des privilèges (IAM)
afin de réduire les risques d’accès non autorisés et de faciliter l’interopérabilité entre services.
Toutes les plateformes ne l’offrent pas nativement, d’où l’importance de ce critère.
2. Stockage sécurisé et souverain des fichiers (S2)
Les données sensibles doivent pouvoir être hébergées localement ou dans un environnement
maîtrisé. `Ce critère répond aux enjeux de protection des données et de souveraineté abordée
dans le chapitre 1.
3. Supervision et journalisation centralisée (S3)

37
La solution doit permettre de surveiller les ressources, collecter les logs et tracer les actions des
utilisateurs. Cela favorise la détection d’incidents, la transparence opérationnelle et la
conformité (ISO 27001, bonnes pratiques de sécurité).
4. Sauvegarde et restauration des données (S4)
La plateforme doit proposer ou permettre la mise en place de sauvegardes régulières et de
restaurations rapides, afin d’assurer la continuité d’activité, notamment dans des
environnements soumis à des coupures ou à une connectivité instable.
5. Réseau privé virtuel ou sécurisé (VPN interne) (S5)
La solution doit permettre un accès distant chiffré aux ressources cloud, pour connecter
plusieurs sites ou utilisateurs distants de manière sécurisée. Ce critère est important dans les
contextes où les accès Internet ne sont pas totalement maîtrisés.
6. Portail web d’administration et d’accès aux services (S6)
Une interface web centralisée doit permettre de gérer les ressources, visualiser l’état du cloud,
ce critère facilite fortement l’exploitation au quotidien.
Ces six critères fonctionnels seront utilisés comme première grille de lecture pour comparer les
solutions cloud (open source et commerciales) et identifier celles qui répondent le mieux à notre
contexte :
• S1 : sécurité et gouvernance des accès
• S2 : souveraineté et confidentialité des données
• S3 : traçabilité et supervision
• S4 : résilience et continuité d’activité
• S5 : connectivité sécurisée et interopérabilité
• S6 : accessibilité et simplicité de gestion
2.4.2. Les critères non fonctionnels
Les critères non fonctionnels complètent les critères fonctionnels (S1 à S6) en évaluant la
qualité, la soutenabilité et l’adéquation réelle des solutions cloud au contexte visé. Ils tiennent
compte des contraintes d’une organisation locale (infrastructures limitées, maîtrise des coûts,

38
exigences de souveraineté et de conformité) et permettent de distinguer les solutions seulement
riches en fonctionnalités de celles qui sont réellement déployables29
.
1. Performance et scalabilité
La solution doit garantir des temps de réponse acceptables, une disponibilité suffisante et une
stabilité des services. La scalabilité (capacité à augmenter ou réduire les ressources) est
également essentielle afin de pouvoir accompagner la croissance de l’organisation sans
réinvestir immédiatement dans le matériel. Ce critère est important dans les environnements où
les ressources sont comptées.
2. Interopérabilité
La plateforme doit pouvoir s’intégrer avec d’autres systèmes (annuaire, outils de sauvegarde,
solutions de messagerie) ou même avec d’autres clouds (publics ou privés) grâce à des standards
(API REST, support OpenStack, compatibilité KVM). Une bonne interopérabilité limite le
verrouillage propriétaire et répond à l’enjeu de souveraineté.
3. Sécurité et conformité
La solution doit proposer ou permettre la mise en œuvre de mécanismes de protection
(authentification, contrôle d’accès, chiffrement, segmentation réseau, journalisation). Elle doit
aussi pouvoir s’aligner sur les cadres réglementaires et normatifs (RGPD, recommandations de
l’autorité nationale, ISO 27001). Dans un contexte où les données peuvent être sensibles
(administrations, établissements publics), ce critère est déterminant.
4. Souveraineté et localisation des données
La solution doit offrir la possibilité d’héberger les données sur une infrastructure maîtrisée
(locale, nationale ou régionale) afin de répondre aux exigences de protection des données et
d’éviter les risques liés aux législations extraterritoriales. Ce point fait le lien direct avec les
enjeux exposés au chapitre 1.
5. Coût total de possession (TCO)
29
IBM, Informatique en nuage : critères de sélection et gestion des risques , IBM Cloud Docs

39
Au-delà du coût de licence éventuel, il s’agit d’évaluer le coût global : installation, formation,
exploitation, ressources matérielles nécessaires, support et évolutivité. Dans un contexte de
PME ou d’administration locale, un TCO maîtrisé est un critère de décision central.
6. Facilité de déploiement et de maintenance
La solution doit être installable et administrable par des équipes locales, avec une
documentation accessible et, idéalement, une communauté active. Plus la solution est simple à
maintenir, moins l’organisation dépendra d’experts externes et plus le projet sera pérenne.
En résumé, les critères fonctionnels définissent ce que la solution doit offrir (IAM,
stockage souverain, supervision, sauvegarde, VPN, portail), tandis que les critères non
fonctionnels définissent dans quelles conditions ces services doivent être fournis
(performance, interopérabilité, sécurité/conformité, souveraineté, coût, maintenabilité).
Ensemble, ces critères constituent la grille d’analyse qui sera utilisée dans la section suivante
pour comparer les principales solutions cloud et retenir celle qui répond le mieux aux réalités
techniques, économiques et réglementaires locales.

40
2.5. Etude des solutions existantes
À la suite de la définition des critères fonctionnels et non fonctionnels, cette section
présente une étude comparative des principales solutions cloud existantes. Pour évaluer à
travers ces critères la capacité de chaque plateforme à répondre aux besoins identifiés dans notre
problématique de ce fait un tableau de synthèse permettra enfin de confronter les différentes
solutions selon ces dimensions afin d’identifier celles offrant le meilleur équilibre entre
performance, souveraineté, sécurité et viabilité économique.
OpenStack
OpenStack30
est aujourd’hui l’une des solutions open source les plus complètes pour la
création et la gestion de clouds privés ou publics (IaaS). Il est conçu initialement par la NASA
et Rackspace, elle repose sur une architecture modulaire et distribuée, composée de nombreux
"projets" (services) indépendants mais interconnectés.
Les composants de base, qui répondent directement à nos critères (Sx31
), sont :
• Keystone (Identité) [S1] : C'est le service central d'authentification et de gestion des
accès. Il fournit les services IAM/SSO en gérant les utilisateurs, les rôles et les "tenants"
(projets), assurant une gouvernance centralisée.
• Cinder (Stockage Bloc) et Swift (Stockage Objet) [S2] : Cinder fournit le stockage en
mode bloc (disques virtuels persistants) pour les VMs, tandis que Swift offre un stockage
objet massivement scalable, idéal pour les sauvegardes ou les archives.
• Ceilometer (Télémétrie) [S3] : Il collecte les métriques de supervision sur l'utilisation
des ressources de l'ensemble du cloud, servant de base à la facturation et au monitoring.
• Heat (Orchestration) [S4] : Bien qu'OpenStack n'ait pas d'outil de sauvegarde unique,
Heat permet d'automatiser le déploiement et la recréation d'infrastructures entières à partir
de modèles (templates), contribuant à la résilience.
• Neutron (Réseau) [S5] : C'est le composant qui gère l'ensemble du réseau virtuel, y
compris les routeurs, les sous-réseaux, les pares-feux et les services VPN, permettant une
segmentation réseau complexe.
30
Fondation OpenStack, Composants et architecture d’OpenStack
31
Sx : Correspondance technologique pour les services attendus de la solution proposée

41
• Horizon (Tableau de bord) [S6] : L'interface web officielle d'OpenStack, le portail
d'administration centralisé pour les administrateurs et les utilisateurs.
• Nova (Calcul) : Le moteur principal qui gère le calcul et le cycle de vie des machines
virtuelles (VMs).
Pour la sécurité Cinder et Swift permettent un chiffrement natif avec une isolation réseau
par Security Groups
Figure 13 : Services d’OpenStack
Figure 14 : Architecture fonctionnelle d’OpenStack

42
Cette modularité favorise une interopérabilité élevée et une compatibilité avec divers
hyperviseurs (KVM, VMware, Proxmox). Il constitue une base solide pour concevoir des
infrastructures cloud flexibles, scalables et indépendantes des fournisseurs. Mais sa mise en
œuvre demande une expertise technique avancée et une maintenance rigoureuse, ce qui peut
représenter un défi pour des structures à ressources limitées.
Proxmox VE
Proxmox Virtual Environment (VE)32
est une solution open source qui s'est imposée
comme une plateforme de virtualisation et de cloud privé "tout-en-un". Sa conception vise la
simplicité, la robustesse et une gestion centralisée des opérations, il est très populaire pour les
PME et les institutions. Elle intègre nativement, au sein d'une seule interface, tous les
composants nécessaires.
Elle s’articule autour de composants principaux comme :
• Hyperviseurs (KVM et LXC) : Elle combine la virtualisation complète basée sur KVM
(pour les VMs Windows ou Linux) et la virtualisation légère par conteneurs (LXC) pour
les applications Linux, optimisant l'usage des ressources.
• Proxmox Cluster Manager (pmxcfs) : C'est le cœur de la solution. Un système de
fichiers de cluster qui permet une gestion centralisée de tous les nœuds, assurant la Haute
Disponibilité (HA) des VMs.
• Interface Web (Web UI) [S6] : Le portail d'administration unique, réactif (basé sur
HTML5), permet de gérer les VMs, le stockage, le réseau et les utilisateurs (via un système
de gestion des droits d’accès intégré RBAC [S1]) depuis un point central.
• Stockage (Ceph / NFS) [S2] : Proxmox intègre nativement des solutions de stockage
avancées notamment avec Ceph qui permet de créer une infrastructure de stockage
hyperconvergée, distribuée, et résiliente.
• Réseau (VPN intégré) [S5] : La solution gère les ponts réseau, les VLANs et inclut des
options de VPN (via Open vSwitch ou WireGuard) pour la gestion et la sécurisation des
communications internes.
• Supervision (Dashboard) [S3] : L'interface intègre des graphiques de performance en
temps réel (CPU, RAM, réseau) pour chaque nœud et chaque VM.
32
Proxmox Server Solutions, Proxmox Virtual Environment – Vue d’ensemble du produit et fonctionnalités

43
• Sauvegarde (Proxmox Backup Server) [S4] : Elle s'intègre parfaitement à Proxmox
Backup Server (PBS), une solution compagnon gratuite pour des sauvegardes
dédupliquées et chiffrées.
Figure 15 : Illustration d’architecture intégrée de Proxmox VE
Cette figure illustre la structure interne d’un datacenter basé sur Proxmox VE.
On y distingue :
• une première couche de virtualisation assurée par les hyperviseurs KVM ;
• une seconde couche dédiée aux conteneurs LXC ;
• un stockage mutualisé via Ceph et NAS Synology ;
• une supervision centralisée et la gestion haute disponibilité via pmxcfs ;
• enfin, la gestion du réseau (VLAN, VPN, VRF) permettant l’isolation des clients et la
sécurité des flux.

44
Cette architecture intégrée permet de garantir la résilience et la continuité de service,
tout en réduisant les coûts d’exploitation. Proxmox se distingue par sa facilité de déploiement,
sa maintenance simplifiée et son adéquation avec les environnements institutionnels locaux, où
les ressources matérielles et humaines peuvent être limitées. Son interface Web intuitive et sa
compatibilité avec OpenStack renforcent son potentiel d’interopérabilité.
VMware vSphere / vCloud Suite
VMware vSphere est une suite propriétaire, commerciale et leader de la virtualisation
elle est destinée aux environnements d’entreprise et se base sur l’hyperviseur ESXi et le
gestionnaire vCenter , tandis que vCloud Suite y ajoute la couche d'automatisation et de gestion
cloud, elle intègre les services suivants : de stockage (vSAN), de réseau (NSX) et
d’automatisation (vRealize Suite). 33
• vCenter Server [S6] : C'est le point de gestion centralisé et sécurisé, qui gère
l'administration de l'ensemble de l'infrastructure et l'authentification (SSO vCenter
[S1]).
• vSAN [S2] : La solution de stockage défini par logiciel (Software-Defined Storage) de
VMware concurrente de Ceph qui propose une securite par chiffrement natif
• vRealize Operations (vRops) [S3] : c’est la suite de supervision et de monitoring
avancée, qui analyse les performances, la capacité et la santé de l'infrastructure.
• Site Recovery Manager (SRM) [S4] : L'outil d'orchestration de la reprise d'activité
(PRA) et de la sauvegarde automatisée.
• NSX [S5] : La solution de virtualisation réseau (SDN) qui permet de créer des réseaux
virtuels, des pare-feux et des VPN de manière logicielle.
Elle garantit une haute performance, une supervision centralisée et une continuité d’activité
optimale, mais son coût élevé et son caractère propriétaire réduisent son attractivité pour les
contextes locaux cherchant la souveraineté.
Microsoft Azure Stack Hub
Azure Stack est l’extension locale du cloud Microsoft Azure, permettant de déployer
des services Azure on-premise tout en bénéficiant de la même interface de gestion. Il réplique
33
VMware vSphere et vCloud Suite – Vue d’ensemble du produit et architecture

45
l'expérience Azure : même portail (Portal Azure [S6]), mêmes API, offrant une interopérabilité
forte.34
• Azure Active Directory (Azure AD) [S1] : Il s'intègre nativement avec AAD pour la
gestion des identités dans le cloud ou en local avec Active Directory Federation Services
qui permet d’utiliser AAD avec des identités locales sans synchronisation (ADFS).
• Stockage [S2] : Il fournit les équivalents locaux de Blob Storage, Table Storage
• Supervision [S3] : Il utilise les mécanismes d'Azure Monitor pour la supervision locale.
• Sauvegarde [S4] : Il s'intègre avec Azure Recovery Services pour la protection des
données.
• Réseau [S5] : Il permet de créer des réseaux virtuels et des VPN Gateway locaux.
Cette solution garantit une interopérabilité, une sécurité renforcée et une conformité ISO 27001.
Cependant, la dépendance à Microsoft et les investissements matériels nécessaires limitent son
accessibilité pour les organisations émergentes.
Red Hat OpenShift
OpenShift est une plateforme PaaS open source basée sur Kubernetes et Docker,
développée par Red Hat. Elle facilite le déploiement et l’orchestration d’applications
conteneurisées, tout en intégrant des mécanismes de sécurité avancés (SELinux, RBAC), un
stockage via des Persistent Volumes, mais n'est pas une solution de stockage en soi avec une
supervision native via Prometheus et Grafana qui sont devenus des standards de la supervision.
Pour la partie reseau elle gere son propre SDN interne pour la communication entre
conteneurs via une interface fournit par une console web complete.
Il est adapté aux architectures modernes orientées microservices, offrant une scalabilité
élevée et une portabilité multicloud, mais sa complexité d’administration reste un frein pour les
petites équipes techniques.35
Apache CloudStack
Apache CloudStack est une plateforme open source de gestion de clouds IaaS, et un
concurrent direct d'OpenStack, souvent considéré comme plus léger et plus simple à déployer
34
Microsoft, Vue d’ensemble d’Azure Stack Hub
35
Red Hat OpenShift – Vue d’ensemble de la plateforme de conteneurs Kubernetes

46
et à maintenir, elle prend en charge plusieurs hyperviseurs (KVM36
). CloudStack offre une
interface web centralisée qui permet de gérer l’ensemble des ressources du cloud :
• Calcul : création, démarrage, arrêt et migration des machines virtuelles.
• Stockage : gestion des volumes, snapshots, templates et images ISO.
• Réseau : configuration des VLAN, NAT, DHCP, pare-feu, équilibrage de charge, et
VPN.
Cette interface est complétée par une API RESTful, permettant l’automatisation des tâches et
l’intégration avec des orchestrateurs comme Terraform ou Ansible. Il intègre nativement
plusieurs services essentiels à la gestion d’un cloud privé :
• Supervision intégrée [S3] : suivi des ressources (CPU, RAM, réseau, disques), alertes
système et une compatibilité avec des outils externes comme Zabbix, Prometheus ou
Grafana.
• Gestion multi-datacenter : architecture distribuée avec zones, pods et clusters, permettant
de gérer plusieurs sites physiques ou logiques depuis une seule console.
• Compatibilité API AWS : prise en charge partielle des API EC2/S3, facilitant les
intégrations avec des outils conçus pour Amazon Web Services ou les migrations hybrides.
• LDAP / SSO [S1] : intégration avec des annuaires LDAP (OpenLDAP, Active Directory)
pour l’authentification centralisée, et support du Single Sign-On via SAML ou OpenID
Connect.
• Stockage local / S3 [S2] : gestion du stockage primaire et secondaire, avec compatibilité
S3 (Amazon, MinIO, Ceph RGW), NFS, iSCSI, ou stockage local.
• VPN Service [S5] : prise en charge des VPN site-à-site ou client, avec protocoles IPsec ou
OpenVPN, pour sécuriser les communications entre instances ou vers l’extérieur.
CloudStack repose sur une architecture modulaire, distribuée et extensible, conçue pour
orchestrer l’ensemble des ressources d’un cloud : calcul, stockage, réseau, sécurité et
supervision. Son interface web centralisée permet aux administrateurs de gérer efficacement les
infrastructures multi-sites, tout en offrant une API RESTful pour l’automatisation et
l’intégration avec des outils tiers.
36
Apache Software Foundation, Apache CloudStack – Plateforme open source de cloud computing IaaS

47
C’est une alternative fiable et légère à OpenStack pour des contextes locaux avec un faible coût
d’exploitation
Nextcloud/ ownCloud
Nextcloud est une solution SaaS privée orientée collaboration et stockage sécurisé et
permet la synchronisation et le partage de fichiers via le chiffrement et l’authentification
LDAP/OAuth2, Bien qu’elle ne constitue pas une solution IaaS, Nextcloud est une brique
complémentaire pour la couche applicative d’un cloud.37
OpenNebula
OpenNebula est une solution open source IaaS légère et flexible, compatible avec
KVM, VMware et le bare-metal et propose une gestion centralisée du cycle de vie des VMs, du
stockage et des réseaux virtuels, tout en restant simple à déployer. Sa conception favorise la
maîtrise des coûts elle est moins complète que OpenStack en termes de fonctionnalités
avancées. OpenNebula repose sur une architecture modulaire, avec des composants intégrés
qui assurent la gestion complète des ressources cloud38
:
• Sunstone UI [S6] :Interface web intuitive permettant aux administrateurs et utilisateurs de
gérer les machines virtuelles, les réseaux, les datastores et les utilisateurs. Elle offre une
expérience simplifiée, adaptée aux environnements non experts.
• Ceph / Datastore [S2] :Support du stockage distribué avec Ceph, ainsi que des datastores
locaux ou NFS. OpenNebula permet de gérer les images, les snapshots et les volumes
persistants, avec une flexibilité dans le choix du backend.
• Sunstone Auth [S1] :Module d’authentification intégré, avec support LDAP, Active
Directory, et SSO via OpenID Connect ou SAML. Il permet une gestion fine des rôles et
des permissions.
• Virtual Networks [S5] :Gestion des réseaux virtuels, incluant les VLAN, les réseaux isolés,
les IP flottantes, et les services réseau comme DHCP, NAT, firewall et VPN. OpenNebula
peut s’interfacer avec des SDN comme Open vSwitch.
37
Nextcloud – Plateforme open source de collaboration stockage
38
OpenNebula, Plateforme open source de cloud et d’edge computing

48
• Monitoring intégré [S3] :Suivi des ressources (CPU, RAM, stockage, réseau) en temps réel,
avec alertes et tableaux de bord. Peut être enrichi par des outils comme Grafana,
Prometheus ou Zabbix.
Par contre OpenNebula ne dispose pas d’un système de sauvegarde complet intégré. À
la place, il propose une prise en charge partielle via des mécanismes personnalisés comme des
Hooks et scripts qui peuvent être déclenchés automatiquement à des événements du cycle de
vie des VM (ex. : arrêt, suppression) pour lancer des sauvegardes personnalisées (ex. : export
de disque, copie vers stockage distant).
Eucalyptus
Eucalyptus est une plateforme open source compatible AWS, elle déploie des clouds
privés avec des API EC2/S3, facilitant la connexion avec le cloud public Amazon tout en
maintenant un contrôle local sur les ressources.39
Eucalyptus repose sur une architecture
modulaire qui réplique les services fondamentaux d’un cloud public :
• IAM [S1] :Gestion des identités et des accès, inspirée du service AWS IAM. Permet de
définir des utilisateurs, des rôles, des politiques d’accès et des groupes.
• Walrus Storage [S2] : Service de stockage objet compatible avec l’API S3. Il permet de
stocker des images, des snapshots et des fichiers, mais reste limité par rapport aux
solutions modernes comme Ceph ou MinIO.
• VPC [S5] : Gestion des réseaux virtuels privés, avec configuration des sous-réseaux,
des passerelles, des tables de routage et des règles de sécurité. Inspiré du service
Amazon VPC.
• Monitoring CLI [S3] : Outils en ligne de commande pour superviser les ressources du
cloud (instances, stockage, réseau). L’interface graphique est limitée, et la supervision
avancée nécessite des outils externes.
• Node Controller : Composant installé sur les hôtes physiques, responsable de
l’exécution des machines virtuelles. Il communique avec le Cloud Controller pour
orchestrer les ressources.
39
Eucalyptus Cloud, Eucalyptus – Clouds privés et hybrides compatibles avec AWS

49
Solutions IaaS
Service 1 :
IAM / SSO
Service
2 :
Stockag
e
sécurisé
Service 3
:
Supervisi
on
Servic
e 4 :
Sauve
garde
Service
5 :
VPN
interne
Service
6 :
Portail
Web
N1 :
Perfor
mance
N2 :
Intero
pérabi
lité
N3 :
Sécurité
/
confor
mité
N4 :
Souver
aineté
N5 :
Coût
total
N6 :
Maintenanc
e /
déploiement
OpenStack Oui
Oui
(Keystone)
Oui
(Swift/C
inder)
Oui
(Ceilomet
er)
Oui
(Heat)
Oui
(Neutro
n)
Oui
(Horizo
n)
Élevée Élevée
Oui
(RBAC,
ISO
27001)
Oui Moyen Complexe
Proxmox
VE
Oui
Oui (RBAC
intégré)
Oui
(Ceph)
Oui
(Dashboar
d)
Oui
(Backu
p
Server)
Oui
(VPN
intégré)
Oui
(Web
UI)
Bonne
Moyen
ne
Moyenn
e
Oui Faible Facile
VMware
vSphere /
vCloud
Oui
Oui (SSO
vCenter)
Oui
(vSAN)
Oui
(vRealize
Ops)
Oui
(SRM)
Partiel
(NSX)
Oui
(vCente
r)
Très
élevée
Moyen
ne
Oui Non Élevé Payante
Microsoft
Azure Stack
Oui
Oui (Azure
AD)
Oui
(Blob
Storage)
Oui
(Azure
Monitor)
Oui
(Recov
ery
Service
s)
Oui
(VPN
Gatewa
y)
Oui
(Portal
Azure)
Très
élevée
Forte
Oui
(ISO
27001)
Non Élevé Complexe
Red Hat
OpenShift
Partiel
Oui
(RBAC,
OAuth)
Partiel
(Persiste
nt
Volume
s)
Oui
(Promethe
us,
Grafana)
Oui
(Backu
p
CronJo
bs)
Oui
(SDN
interne)
Oui
(Consol
e Web)
Élevée Forte Oui
Moyen
ne
Moyen Moyenne

50
Apache
CloudStack
Oui
Oui
(LDAP/SS
O)
Oui
(Local /
S3)
Oui
(Monitori
ng
intégré)
Partiel
(Snaps
hots)
Oui
(VPN
Service
)
Oui
(Web
UI)
Moyen
ne
Moyen
ne
Moyenn
e
Oui Faible Facile
Nextcloud Non
Oui (LDAP
/ OAuth2)
Oui
(Chiffre
ment
AES)
Oui
(Audit
Log)
Partiel
(Backu
p
manuel
)
Non
Oui
(Interfa
ce Web)
Moyen
ne
Moyen
ne
Oui
(RGPD)
Oui
Très
faible
Simple
OwnCloud Non
Oui (LDAP
/ SAML)
Oui
(Chiffre
ment
AES)
Partiel
(Logs)
Partiel
(Extern
al
Tools)
Non
Oui
(Web
Admin)
Moyen
ne
Moyen
ne
Oui Oui
Très
faible
Simple
OpenNebula Oui
Oui
(Sunstone
Auth)
Oui
(Datasto
re,
Ceph)
Oui
(Monitori
ng
intégré)
Partiel
(Hooks
/
Scripts
)
Oui
(Virtual
Networ
k)
Oui
(Sunsto
ne UI)
Moyen
ne
Moyen
ne
Oui Oui Faible Facile
Eucalyptus Oui Oui (IAM)
Oui
(Walrus
Storage)
Partiel
(CLI
Monitorin
g)
Partiel
(Snaps
hots)
Oui
(VPC)
Partiel
(Web
UI)
Moyen
ne
Élevée
(API
EC2/S
3)
Moyenn
e
Moyen
ne
Faible Moyenne
Tableau 5 : Comparatif des principales solutions Cloud Computing

51
2.6. Conclusion
L’analyse du tableau comparatif montre que les solutions commerciales comme VMware
vSphere/vCloud Suite et Microsoft Azure Stack Hub se distinguent par leur performance
élevée, leur niveau de sécurité avancé et leur interopérabilité complète avec d’autres
environnements mais leur coût d’acquisition et de maintenance est important
Les solutions open source plus accessibles et complète comme OpenStack couvrent la
majorité des critères fonctionnels : gestion des identités (Keystone), stockage (Swift/Cinder),
supervision (Ceilometer), orchestration (Heat), réseau (Neutron) et portail d’administration
(Horizon). Mais elle a une grande complexité de déploiement et d’un besoin élevé en
compétences techniques ce qui en limite l’adoption dans les petites et moyennes structures.
Proxmox VE se démarque aussi il intègre la virtualisation (KVM/LXC), la sauvegarde
(Proxmox Backup Server), le stockage distribué (Ceph), un VPN interne et une interface Web,
il répond à la majorité des services fonctionnels tout en restant facile à administrer. C’est une
solution pertinente pour des organisations locales disposant de ressources limitées mais
cherchant à mettre en place une infrastructure cloud privée fiable.
Les solutions Apache CloudStack et OpenNebula offrent aussi une interopérabilité solide,
une gestion centralisée et une compatibilité multi-hyperviseur avec un faible coût d’exploitation
et une facilité de maintenance.
En conclusion, l’étude comparative montre qu’aucune solution ne répond totalement aux
besoins de notre problématique, mais des solutions open source telles que Proxmox VE qui s'est
imposée comme une plateforme de virtualisation et de cloud suivi de, Nextcloud/ownCloud
avec leurs services applicatifs peuvent répondre aux exigences techniques et réglementaires
identifiées, avec un cout total de possession relativement moindre, une maintenance et un
déploiement moins complexe pour les petites et moyennes structures , tout en gardant
OpenStack comme piste d’évolution vers un IaaS plus complet..
Dans le chapitre suivant, nous procéderons à l’analyse de l’existant au sein d’une
organisation basée au Gabon afin d’identifier son environnement actuel, ses limites et ses
besoins, cette étude servira de base à la conception de notre infrastructure cloud.

52
Chapitre 3 : Analyse de l’existant et Conception de la solution
proposée
Dans ce chapitre nous analyserons l’existant au sein d’une organisation et afin de
concevoir une solution Cloud Computing adaptée à ses besoins. L’étude se base sur un cas
observé au Gabon afin d’illustrer la démarche de mise en place de notre solution cloud tout en
tenant compte des contraintes locales telles que les ressources, la connectivité, les coûts
d’investissement et la sécurité.
Ce chapitre se divise en deux grandes parties :
• L’analyse de l’existant, qui présente l’environnement organisationnel et technique actuel,
ses équipements, ses services et ses limites.
• La conception de la solution proposée, qui définit les besoins, les choix technologiques et
l’architecture cible permettant de répondre à notre problématique.
3.1. Présentation de l’entreprise
Gabon Digital Services (GDS) est une petite entreprise privée qui offre des services
numériques, implantée à Libreville dans le quartier d’Oloumi. Créée en 2021, elle évolue dans
le secteur des technologies de l’information et de la communication (TIC), avec pour mission
principale d’accompagner les entreprises et institutions locales dans leur transformation
numérique.
3.1.1. Activités principales
Les principales activités de GDS s’articulent autour des axes suivants :
• La création et hébergement de sites web ;
• Le développement et la maintenance logicielle (outils métiers) ;
• Administration, maintenance des infrastructures informatiques ;
• Audit et accompagnement technique

53
3.1.2. Structure organisationnelle
L’entreprise est composée de trois services principaux, placés sous la responsabilité directe
de la Direction Générale :
1. Le service administratif et financier qui gère les ressources humaines, la comptabilité et
la logistique de l’entreprise.
2. Le service Développement conçoit et maintient les applications web et outils internes et
travaille principalement sur des projets ponctuels de clients locaux.
3. Le service Technique qui regroupe deux cellules internes assure la gestion quotidienne de
l’infrastructure informatique et des équipements

54
Figure 16 : Organigramme de GDS
Direction Generale
Service Technique
Cellule IT
Techniciens Réseau/
Système
Cellule Support et
Maintenance
Technicien support
Service Dev
Developpeurs
Service
Administration/
financier
RH/Compta

55
3.2. Architecture de l’existant
Dans cette section nous présenterons l’analyse au sein de l’existant, en étudiant le réseau
et la composition de son parc informatique pour comprendre les limites actuelles et proposer
notre solution cloud computing.
3.2.1. Présentation du réseau de GDS
L’infrastructure réseau actuelle de Gabon Digital Services (GDS) repose sur une architecture
client–serveur centralisée, composée d’un réseau local (LAN) filaire et Wi-Fi. Elle s’appuie sur
deux switchs interconnectés :
• Le switch principal, qui relie les postes clients, l’imprimante réseau le point d’accès
Wi-Fi et la liaison vers le routeur/pare-feu ;
• Le switch secondaire, situé dans la salle serveur, qui interconnecte les serveurs internes
(Web, Mail, NAS).
L’accès Internet est fourni par Gabon Télécom via une liaison fibre optique connectée à un
modem FAI, lui-même relié à un routeur/pare-feu assurant la sécurité périmétrique du LAN,
la traduction d’adresses (NAT) et la distribution du trafic interne vers le réseau local.
Les connexions entre équipements utilisent un câblage Ethernet cuivre Catégorie 6,
garantissant des débits de 100 Mb/s à 1 Gb/s, assurant ainsi une bonne stabilité et une bande
passante suffisante entre les deux zones bureautiques et la zone serveur.
La figure suivante illustre la topologie physique du réseau actuel et la répartition des
principaux équipements au sein du siège de GDS.

56
3.2.2. Topologie du réseau existant
Figure 17 : Architecture réseau de GDS
3.2.3. Inventaire des ressources matérielles et logicielles existantes
L'infrastructure de GDS repose sur un ensemble d'équipements et de logiciels hétérogènes qui
constitue son parc informatique, l’inventaire suivant regroupe les différents équipements
recensés au sein de l’entreprise.
3.2.3.1. Equipements réseaux
Cette section détaille l'infrastructure qui assure l'interconnexion des équipements et la
protection périmétrique du réseau de GDS.
Rôle Quantité Marque/Modèle Fonction principale /
Spécification
Routeur/Pare-
feu
1 Cisco RV340 Routage, NAT, Sécurité
périmétrique, VPN
Switchs 2 Cisco CBS250-24T-
4G
24 ports, L2 administrable
Point d'accès
Wi-Fi
1 Ubiquiti UniFi AP AC
LR
Connectivité sans-fil des
employés
Tableau 6 : Équipements d’interconnexion réseau

57
3.2.3.1. Inventaire des équipements serveurs et ordinateurs
L’entreprise possède en tout :
Tableau 7 : Recapitulatif des équipements serveurs et ordinateurs
Catégorie Quantité Marque/Modèle
(Exemple)
Spécifications / Rôle principal
Serveur Web 1 Dell PowerEdge T140 Intel Xeon E-2224, 32 Go RAM /
Hébergement des sites clients.
Serveur Mail 1 HP ProLiant ML30
Gen10
Intel Xeon E-2124, 32 Go RAM /
Gestion de la messagerie.
Stockage (NAS) 1 Synology DiskStation
DS920+
Intel Celeron J4125, 6 Go RAM /
Partage de fichiers, sauvegardes.
Ordinateur de
bureau
5 Dell/HP Core i5, 8 Go RAM / Postes fixes
(Service administratif).
Ordinateur
portable
10 HP EliteBook,
MacBook Pro…
Core i5/i7, 8-16 Go RAM / Postes
mobiles (Services Dev/Tech).
Imprimante
Réseau
1 HP LaserJet Pro MFP Multifonction, partagée sur le
réseau.

58
3.2.3.2.Inventaire des logiciels et systèmes d'exploitation
Cette dernière section répertorie la couche logicielle et les services qui s'exécutent sur
le matériel.
Tableau 8 : Recapitulatif des logiciels et systèmes d'exploitation
Catégorie Logiciel / Technologie Rôle principal / Hébergement
OS Serveurs Ubuntu Server 20.04 LTS Serveur Mail / Serveur Web
Synology DSM Système de stockage (sur NAS)
OS Clients Windows 10 Pro,Win11,
macOS
Postes de travail (PC/Laptops)
Services
d'Infrastructure
Gestion des utilisateurs Comptes gérés localement (sur chaque
poste/service)
DNS/DHCP Services hébergés sur le routeur (Cisco
RV340)
Services Applicatifs Pile Mail (Postfix,
Dovecot)
Service de messagerie interne
Pile LAMP (Apache,
MySQL, PHP)
Hébergement des sites clients (sur
Serveur Web)
Sécurité Antivirus Protection des postes et serveurs
Sauvegarde Synology Active Backup Sauvegarde des serveurs sur le NAS
(locale)

59
3.2.4. Les avantages et limites de l’existant
L'inventaire de la section précédente nous permet à présent de procéder à une analyse critique
de l'infrastructure de GDS.
3.2.4.1. Les Avantages de l’infrastructure actuelle
L’infrastructure informatique actuelle de Gabon Digital Services (GDS) présente plusieurs
points forts :
• Faible coût initial : L’open source avec Ubuntu Server et la pile LAMP (Apache,
MySQL, PHP) permet à GDS de déployer ses services (hébergement, messagerie,
stockage) sans supporter de lourdes charges liées aux licences logicielles propriétaires.
• Une architecture claire et maîtrisable : Elle repose sur une architecture client–serveur
classique, facile à administrer et réduit la complexité de maintenance.
• Matériel professionnel : Le choix d’équipements de gamme professionnelle, tels que les
commutateurs Cisco CBS250, le routeur/pare-feu Cisco RV340 et le point d’accès
Ubiquiti UniFi, constitue une base matérielle de qualité.
• Organisation du réseau : La répartition du réseau sur deux switchs distincts l’un dédié
aux postes clients et au Wi-Fi (SW-USER), l’autre aux serveurs internes et au NAS (SW-
SRV) permet une bonne clarté de câblage et une bonne organisation physique de la salle
serveur.
• Centralisation des données : Le NAS Synology DiskStation DS920+ offre une
plateforme de stockage centralisée et constitue le premier pilier d'une stratégie de
sauvegarde
3.2.4.2.Les limites et contraintes observées
Malgré ces points positifs, nous relevons plusieurs faiblesses :
• Sous-utilisation des ressources matérielles : Les serveurs physiques de processeurs
puissants et de 32 Go de RAM, sont exploités pour des rôles uniques (Web, Mail, NAS).
Cette absence de mutualisation provoque une faible utilisation du CPU et de la mémoire,
un surcoût énergétique et une perte d’efficacité opérationnelle. L’absence de virtualisation
empêche aussi la création d’environnements de test, de préproduction ou de reprise
d’activité.

60
• Absence de redondance et de tolérance aux pannes : Aucun mécanisme de haute
disponibilité (HA) n’est prévu ; une panne d’un serveur ou du routeur entraîne l’interruption
immédiate des services internes.
• Sécurité limitée au périmètre : La protection repose uniquement sur le pare-feu du routeur
; aucune segmentation Vlan n’est appliquée. La détection et la supervision des menaces
restent inexistantes.
• Gestion manuelle des utilisateurs : Les comptes sont créés localement sur chaque poste,
faute de domaine Active Directory ou d’annuaire LDAP, ce qui complique la gestion et
affaiblit la sécurité.
• Sauvegardes uniquement locales : Les données du NAS ne sont pas répliquées à distance
en cas de sinistre physique ou d’attaque, l’entreprise risque une perte totale d’informations.
• Manque de supervision et de journalisation : Aucun outil de monitoring n’est déployé,
rendant difficile le suivi des performances, la détection d’anomalies et la planification de la
maintenance.
• Scalabilité limitée : L’ajout de nouveaux services ou d’utilisateurs nécessite des
investissements matériels supplémentaires, faute d’environnement virtualisé.
• Dépendance au fournisseur d’accès unique : L’unique lien fibre fourni par Gabon
Télécom constitue un point de défaillance : une coupure Internet paralyse toute l’activité
externe.
L’analyse de l’existant a permis de mettre en évidence la structure technique actuelle de
Gabon Digital Services (GDS), ses forces, mais également ses limites majeures. L’entreprise
dispose d’une base matérielle correcte et de solutions logicielles open source fiables, adaptées
à ses besoins. Mais son infrastructure demeure sous-exploitée et rigide, isolée et faiblement
optimisée, ne répondant plus aux exigences actuelles de performance, de disponibilité et de
sécurité.
La section suivante présentera donc la conception de la solution proposée avec l’analyse
détaillée des besoins fonctionnels et techniques de GDS, le choix des technologies et des outils
adaptés, ainsi que la modélisation de l’architecture cible.

61
3.3. Conception de la solution proposée
L’analyse de l’existant a permis de mettre en évidence les forces et les limites de
l’infrastructure actuelle de Gabon Digital Services (GDS), notamment la sous-utilisation des
ressources matérielles, l’absence de redondance et de supervision, ainsi que la faiblesse des
mécanismes de sécurité et de sauvegarde.
Dans cette section nous allons définir les besoins auxquels devra répondre notre solution
cloud alignée avec les objectifs de performance et d’optimisation des coûts de GDS.
3.3.1. Analyse des Besoins
Les limites identifiées dans l’existant sont reparties en besoins fonctionnels, techniques et
organisationnels.
3.3.1.1. Besoins fonctionnels
Sur le plan fonctionnel, pour rationaliser la gestion et la continuité de ses services les besoins
identifiés sont les suivants :
• Virtualisation et mutualisation des ressources : La solution doit permettre de mutualiser
la totalité des ressources matérielles (CPU, RAM, stockage) afin d’héberger plusieurs
services virtualisés sur une même infrastructure et d’optimiser les performances.
• Haute disponibilité et continuité de service : L’architecture cible devra assurer la
continuité de service en cas de panne d’un serveur ou d’une coupure réseau.
• Supervision centralisée : Une solution de monitoring devra permettre la surveillance en
temps réel des performances des serveurs (CPU, RAM, stockage), du réseau et des
machines virtuelles. [S3]
• Interface d’administration : Offrir une interface unique de gestion centralisée des
ressources afin de simplifier l’administration et le déploiement des services[S6]
• Gestion centralisée des identités (IAM) déployer un annuaire centralisé (LDAP ou
Active Directory) permettant l’authentification centralisée [S1].

62
3.3.1.2. Besoins techniques
Sur le plan technique, la future infrastructure doit s’appuyer sur des technologies stables,
évolutives et compatibles avec le matériel existant.
Les besoins principaux identifiés sont les suivants :
• Virtualisation complète des serveurs : transformer les serveurs Dell et HP en hôtes
hyperviseurs pour maximiser et mutualiser les ressources, l’usage du CPU, de la RAM et
du stockage et réduire les coûts énergétiques.
• Implémentation de VLANs : isoler les flux entre serveurs, utilisateurs et équipements
pour renforcer la sécurité interne [S2].
• Mécanismes de redondance : mettre en place des systèmes de tolérance aux pannes et de
basculement automatique des services (HA, cluster). [S5].
• Supervision des ressources et des services : intégrer une solution de monitoring (Zabbix
ou Grafana) pour surveiller l’état des services et anticiper les incidents [S3].
• Sauvegardes automatisées et externalisées : automatiser les sauvegardes quotidiennes
vers le NAS et une destination externe chiffrée [S4].
• Sécurisation multicouche : intégrer pare-feu virtuel, chiffrement des communications
[S5] et authentification renforcée (IAM) [S1].
3.3.1.3. Besoins organisationnels et réglementaires
Ces besoins concernent la gouvernance, la conformité et la pérennité de la solution :
• Optimisation des coûts (CAPEX/OPEX) : réduire les coûts matériels et opérationnels
grâce à la consolidation et à la virtualisation.
• Évolutivité et agilité : permettre l’intégration future de nouvelles applications métiers
sans remise en cause de l’architecture globale.
L’analyse des besoins nous permet de dire que GDS doit évoluer vers une infrastructure
virtualisée et mutualisée, pour maximiser l’usage des ressources existantes.

63
3.4. Modèle fonctionnel – Cas d’utilisation
Cette section présente le modèle fonctionnel du cloud privé. Deux acteurs principaux
interagissent avec le système : l’Employé et l’Administrateur IT.
Les cas d’utilisation couvrent : l’accès au portail interne qui unifie les entrées,
l’authentification via l’IAM/LDAP, le stockage/partage de fichiers avec Nextcloud et la
consultation de l’état des services via Prometheus.
Figure 18 : Cas d’utilisation du cloud privé GDS
La section suivante présentera donc les choix technologiques et matériels retenus pour
concevoir la solution Cloud Computing adaptée à GDS, en expliquant les critères de sélection
et la justification du choix de la plateforme de virtualisation.

64
3.5. Choix des solutions technologiques et matérielles
La conception de la solution Cloud Computing de Gabon Digital Services (GDS) repose
sur des choix technologiques, tenant compte des contraintes locales (coût, connectivité,
compétences disponibles) notre objectif sera d’adopter une architecture performante et
évolutive, tout en utilisant les ressources matérielles existantes et ses choix se structurent autour
de deux axes.
3.5.1. Choix matériel et infrastructure de base
L’environnement matériel de GDS constitue un socle solide pour la mise en œuvre de
notre solution. Elle s’appuie sur la réutilisation des serveurs existants, tout en ajoutant certains
équipements pour améliorer la redondance et la disponibilité.
Équipement Rôle Justification
Serveur Dell
PowerEdge T140
Premier nœud de
virtualisation
Serveur récent doté d’un processeur Xeon E-
2224 et 32 Go de RAM, adapté aux charges
d’hébergement web et applicatif.
Serveur HP ProLiant
ML30 Gen10
Second nœud de
virtualisation
Serveur robuste utilisé pour la messagerie
interne, réaffecté au cluster cloud pour
mutualiser les ressources.
NAS Synology
DS920+
stockage partagé et de
sauvegarde centralisée
Sert de stockage réseau (NFS/iSCSI) pour les
images des machines virtuelles et les
sauvegardes automatisées.
Commutateurs Cisco
CBS250
Interconnexion
physique et création de
VLANs
Switchs administrables L2 permettant la
segmentation du réseau et la séparation des
flux internes (serveurs, utilisateurs, Wi-Fi).
Routeur/Pare-feu
Cisco RV340
Sécurité périmétrique et
routage
Gère le NAT, et la connectivité Internet du
réseau..

65
Point d’accès
Ubiquiti UniFi AP
AC LR
Connectivité Wi-Fi
sécurisée
Permet un accès sans fil contrôlé pour les
employés et les appareils mobiles.
Baie & Câblage Cat.6 Socle de connectivité -
Tableau 9 : Matériel Réutilisé pour la solution cloud
En complément, afin de garantir la continuité de service et la sécurité du futur
environnement Cloud, il est préconisé d'ajouter un FAI secondaire pour assurer le Load
balancing (et donc la continuité d’accès Internet en cas de panne du FAI principal), ainsi qu’un
onduleur (UPS) pour la protection électrique, afin d’éviter les arrêts brutaux en cas de coupure,
et un groupe électrogène. Ainsi La section suivante justifiera le choix de la solution cloud.
3.5.2. Choix de la Solution Cloud
Pour rappel des besoins à couvrir, dans le chapitre 2 avec l’étude de l’existant et l’analyse
des besoins de GDS ont mis en évidence sept exigences techniques majeures pour notre solution
cloud :
1. Virtualisation et mutualisation des ressources ;
2. Haute disponibilité et redondance d’accès ;
3. Sécurité interne par segmentation réseau ;
4. Gestion centralisée des identités (IAM/SSO) ;
5. Mécanismes de sauvegarde et de reprise d’activité ;
6. Supervision centralisée ;
7. Portail d’administration unifié.
La solution doit pouvoir fournir ces services, tout en restant déployables par une petite
équipe et compatibles avec le matériel déjà présent, le tableau comparatif du chapitre 2 a permis
de classer les solutions en deux :
• Solutions complètes : VMware vSphere/vCloud, Microsoft Azure Stack, OpenStack.
Elles couvrent presque tous les services (IAM, stockage, supervision, réseau, portail)
mais demandent soit un cout important (VMware, Azure), soit un haut niveau
d’expertise.

66
• Solutions open source légères : Proxmox VE, Apache CloudStack, OpenNebula. Elles
couvrent les différents services avec un coût réduit et une maintenance plus simple.
Notre conclusion du Chapitre 2 montrait qu’aucune solution ne répondait totalement à la
problématique, mais des solutions open source telles que Proxmox VE avec une combinaison
via Nextcloud/ownCloud avec leurs services applicatifs peuvent répondre aux exigences d’une
petite entreprise dans le cas de GDS.
Sur le plan non fonctionnel, il est faible coût et facile à déployer ce qui répond directement
aux contraintes de GDS. De plus sur le plan matériel, il peut être installé directement sur les
deux serveurs existants pour former un cluster de virtualisation et ainsi réutiliser l’infrastructure
actuelle.
Sur le plan fonctionnel Proxmox fournit la virtualisation KVM/LXC, une interface web
d’administration, la sauvegarde via Proxmox Backup Server, une gestion sécurisée du réseau.
Suite à cette Analyse, nous avons choisi comme solution adéquate, Proxmox VE.
3.6. Architecture Cible de la Solution (Physique et Logique)
Apres fait le choix de Proxmox VE, cette section sur l’architecture cible a pour objectif
d’héberger le cloud privé Proxmox tout en sécurisant le réseau interne de GDS. Elle s’appuie
uniquement sur le matériel déjà présent.
Elle est présentée en deux points :
1. Une architecture physique axée sur la redondance pour l’entreprise.
2. Une architecture logique axée sur la sécurité et l'organisation des Services (S1-S6).

67
3.6.1. Architecture physique cible (Entreprise)
La Figure suivante présente la topologie physique retenue qui élimine tous les points de
défaillance uniques et où chaque composant critique est redondé.
Figure 19 – Topologie physique de la solution cible
Contrairement à l'existant, le cœur de réseau est désormais résilient. Les deux switchs Cisco
CBS250 (SW-CORE-1 et SW-CORE-2) ne sont plus en cascade mais forment un "Cœur de
Réseau" unique. Pour garantir une Haute Disponibilité (HA) totale :
• Les deux serveurs (NŒUD-PROXMOX-1 et NŒUD-PROXMOX-2) sont connectés aux
deux switchs ce qui permet au cluster Proxmox de rester joignable même en cas de panne
d’un switch.
• Le NAS Synology est également connecté aux deux switchs pour garantir la disponibilité des
sauvegardes et du stockage partagé.
• Le ROUTER-FW (Cisco RV340) il est relié au cœur de réseau et reçoit les deux liens
opérateurs (FAI1 et FAI2) configurés en Dual WAN pour résoudre ainsi la dépendance à
un seul FAI.
Ainsi, la panne d'un câble ou d'un switch (SW-CORE-1 par exemple) n'entraîne aucune
interruption de service, car le trafic bascule automatiquement sur SW-CORE-2. Enfin, le

68
ROUTER-FW est configuré en mode Dual WAN (FAI1 et FAI2) pour la continuité d’Internet
et n’entraînera plus l’arrêt global du système.
3.6.2. Architecture Logique Cible
Cette section détaille l'architecture logique et l'organisation des services S1-S6 qui seront.
Sur cette architecture physique cible redondée, une architecture logique a été mise en place afin
d’isoler les différents types de trafic pour mieux protéger les services du cloud et d’appliquer
les politiques d’accès au niveau du routeur–pare-feu.
3.6.2.1. Les Services de la solution proposée (S1-S6)
Dans notre conception, les services définis sont déployés au sein du CLUSTER-PMX /
SERVICES qui est le moteur de notre cloud privé il est définit sur le VLAN20, comme illustré
sur la figure qui suivra.
S1 (Service d'Identité - IAM) : il sera déployé dans le VLAN20 pour assurer l'authentification
centralisée de tous les employés.
S2 (Service de Stockage) : Ce service est dédié et déployé pour fournir la plateforme de
partage de fichiers accessible depuis le VLAN30 via le pare-feu physique de GDS.
S3 (Service de Supervision) : Pour surveiller en temps réel la santé du cluster, des VMs et
des hôtes Proxmox et un accès a la console réservée au VLAN10
S4 (Service de Sauvegarde) : Ce service est géré par Proxmox et utilise le SRV-NAS comme
cible de stockage pour les sauvegardes automatisées.
S5 (Service de Sécurité Réseau) : Ce service est implémenté d’une part au niveau de
l'infrastructure par le ROUTER-FW (pare-feu) et les SWs (segmentation VLAN)
S6 (Service d'Administration) : Ce service est l'interface web qui permet de gérer l'ensemble
du cloud accessible uniquement depuis le VLAN 10 et il sera présent pour accéder aux services
du cloud depuis le VLAN30

69
3.6.2.2. L’Architecture de la solution
Pour sécuriser ces services et les rendre accessibles de manière contrôlée, nous les plaçons dans
une architecture logique segmentée. La figure suivante illustre cette segmentation via des
VLANs.
Figure 20 : Topologie logique de la solution cible
Cette architecture isole le trafic en quatre zones, dont l'accès est contrôlé par le ROUTER-FW:
• VLAN 10 (Management) : C'est le réseau d’administration à haut niveau de confiance
totalement isolée. Elle héberge l'accès aux interfaces d’administration Proxmox et ses
services (S6), interface d’admin du NAS, interface d’admin du routeur/pare-feu. Pour une
sécurité maximale, seuls les postes de la cellule IT authentifiés avec des adresses IP
spécifiques dans le VLAN 30 peuvent y accéder via le pare-feu sur le ROUTER-FW qui
autorise se connecter.
•

70
• VLAN 20 (Serveurs) : C'est le réseau cœur qui héberge le cluster Proxmox qui fait
tourner tous les services sous formes de VMs, ainsi que le SRV-NAS, le ROUTER-FW
est configuré pour autoriser le VLAN 30 à y accéder, mais uniquement pour consommer
les services.
• VLAN 30 (Employés) : C'est la zone de travail des utilisateurs. Elle contient les différents
postes de travail (Développeurs, Administration/Financier) et les postes de la Cellule IT
pour leur travail quotidien ainsi que l’imprimante avec un accès contrôlé vers le VLAN
20 pour consommer les services.
• VLAN 40 (Invités) : C'est une zone "zéro confiance" pour le POINT-WIFI. Elle est
totalement isolée par le ROUTER-FW, qui lui bloque tout accès aux VLANs 10, 20 et 30,
n'autorisant qu'un accès à Internet.

71
3.7. Conclusion
Ce chapitre a permis d’analyser l’infrastructure de Gabon Digital Services (GDS) à la
définition d’une architecture cible adaptée à son contexte. L’analyse de l’existant a montré que,
malgré un matériel professionnel et des services open source l’infrastructure restait sous-
exploitée avec une absence de virtualisation, un réseau non segmenté, aucun mécanisme de
haute disponibilité, une gestion des utilisateurs dispersée et dépendance à un seul lien Internet.
Ce qui ne permettaient plus d’assurer la disponibilité, la sécurité et l’évolutivité attendues pour
les activités de GDS.
Nous avons traduit les besoins en trois niveaux (fonctionnels, techniques et
organisationnels) qui ont servi de base au choix d’une solution IaaS légère, et économiquement
accessible, Proxmox VE, comme plateforme de virtualisation, car elle couvre les besoins
identifiés (virtualisation KVM/LXC, sauvegarde, interface web, réseau VLAN/VPN) tout en
restant déployable sur les deux serveurs existants.
L’architecture physique et logique cibles proposées répondent enfin aux principales faiblesses
de l’existant :
• Redondance réseau grâce au double cœur de commutation et au dual WAN ;
• Segmentation logique en quatre VLANs (management, serveurs, utilisateurs, invités)
pour la sécurité ;
• Hébergement centralisé des services S1 à S6 sous forme de machines virtuelles sur le
cluster Proxmox ;
Cette conception fournit donc un cadre technique cohérent pour mettre en place un cloud
privé interne, évolutif et sécurisé.
Dans le chapitre suivant nous ferons l'implémentation concrète de cette architecture via la
mise en place de notre environnement de test, l'installation du cluster Proxmox, la configuration
du réseau et le déploiement des différents services.

72
Chapitre 4 : Mise en place de la solution proposée
Dans ce chapitre, nous ferons l'implémentation concrète de cette architecture cible
conçue précédemment via la mise en place de notre environnement de test, l'installation du
cluster Proxmox en guise de base a notre cloud privé, la configuration du réseau par pfsense
appuyé par un Nas virtuel et le déploiement des différents services. Nous suivrons différentes
étapes jusqu’à l’implémentation finale.
4.1. Schéma de Déploiement
Figure 21 : Architecture de notre maquette de test
Le schéma présente quatre blocs logiques :
• VLAN 10 – Administration : héberge les interfaces d’admin de pfSense, Proxmox et
du NAS. C’est le réseau réservé à l’équipe IT.
• VLAN 20 – Serveurs : héberge les services applicatifs (conteneurs LXC dans Proxmox)
et le NAS duquel ils tirent les ISO / sauvegardes.
• VLAN 30 – Utilisateurs : réseau client depuis lequel on teste l’accès aux services.
• VLAN 40 – Invités : réseau isolé.

73
Tous ces segments sont reliés par pfSense qui joue à la fois le rôle de passerelle, de routeur
inter-VLAN et de serveur DNS interne.
4.2. Présentation de l'Environnement de Test
L'implémentation est réalisée sur l'hyperviseur de Type 2 Oracle VM VirtualBox.
L'architecture est simulée à l'aide des six machines virtuelles suivantes:
Nom VMs Rôle Réseau (VLAN
Simulé)
Objectifs
GDS-FW Pare-feu /
Routeur Central
Tous (WAN, 10, 20,
30, 40)
inter-VLAN, DHCP, DNS local
GDS-
PMX-N1
Nœud 1 du
Cluster
VLAN 10 (Admin) &
20 (Service)
Héberger les conteneurs, maître du
cluster
GDS-
PMX-N2
Nœud 2 du
Cluster
VLAN 10 (Admin) &
20 (Service)
Second hôte pour valider la
création du cluster et la HA.
GDS-NAS Stockage
Central
VLAN 10 (Admin) &
20 (Service)
Simule le NAS et Fournit le
stockage NFS partagé
GDS-
Client-
Admin
Poste de la
Cellule IT
VLAN 10
(Management)
Valide l'accès administratif
(pfSense, Proxmox) depuis le
VLAN10.
GDS-
Client-
Emp
Poste Utilisateur
Classique
VLAN 30
(Employés)
Valide l'accès aux services
(VLAN 20)
Tableau 10 – VMs de la maquette

74
4.2.1 Plan d’adressage
Chaque VLAN est représenté par un réseau interne VirtualBox, voir annexe II. La VM GDS-
FW (pfSense) possèdera donc plusieurs cartes réseau (une par VLAN).
Le plan d'adressage IP géré par la VM GDS-FW (pfSense) qui sert de passerelle pour chaque
segment est le suivant :
Rôle (VLAN
Simulé)
Réseau Interne
(VirtualBox)
Plage d'Adresses
IP
Passerelle (IP du
GDS-FW)
Management
(VLAN 10)
net-mgmt 192.168.10.0/24 192.168.10.254
Serveurs (VLAN
20)
net-servers 192.168.20.0/24 192.168.20.254
Employés (VLAN
30)
net-employés 192.168.30.0/24 192.168.30.254
Tableau 10 – Plan d’adressage de la maquette
4.2.2. Prérequis Logiciels
Avant de démarrer la création de la première machine virtuelle, les fichiers d'installation
suivants doivent être téléchargés et prêts à l'emploi :
• pfSense CE 2.7.2 (pour GDS-FW)
• Proxmox VE 9.0-1 (pour GDS-PMX-N1 et GDS-PMX-N2)
• OpenMediaVault (OMV) (pour GDS-NAS)
• ISO Client (Windows 10 pour les VMs de test)
4.3. Déploiement du Router/Pare-feu (PfSense)
Le premier composant déployé est la VM GDS-FW, qui simule le routeur/pare-feu
central. Il est le fondement de notre segmentation réseau, car elle fournit les passerelles pour
tous les autres composants. Nous utilisons l'ISO pfSense-CE-2.7.2-RELEASE-amd64.

75
4.3.1. Création et Configuration des Interfaces Réseau
La VM GDS-FW est créée sur VirtualBox, voir annexe. La configuration réseau est
établit en cinq cartes réseau virtuelles sont assignées pour correspondre aux cinq segments de
notre architecture (1 WAN + 4 VLANs simulés).
Chaque carte est connectée au réseau de VirtualBox, après l’installation de pfSense, les
interfaces ont été assignées et configurées via la console comme suit, voir annexe :
Interface Réseau
VirtualBox
Rôle / VLAN Adresse IP Statique
em0 NAT / WAN Accès Internet DHCP (Adresse
dynamique)
em1 net-mgmt LAN / Admin (VLAN 10) 192.168.10.254
em2 net-servers OPT1 / Serveurs (VLAN 20) 192.168.20.254
em3 net-employes OPT2 / Employés (VLAN
30)
192.168.30.254
em4 net-invites OPT3 / Invités (VLAN 40) 192.168.40.254
Tableau 11 : Interfaces réseau
Figure 22 : Interfaces assignées (pfSense)

76
4.3.2. Configuration des Services Réseau et Sécurité
Une fois l'accès à l'interface pfsense, des configurations essentielles ont été appliquées pour
garantir le routage inter-VLAN et la sécurité.
a. Serveur DHCP pour les Employés
Afin d'automatiser l'attribution des adresses IP sur le réseau des employés, le service DHCP
a été activé sur l'interface OPT2 (net-employes) :
• Menu : Services > DHCP Server > OPT2
• Plage : Configuration d'une plage d'adresses pour la distribution automatique.
Figure 23 : configuration du DHCP
b. Résolution DNS Locale (DNS Resolver)
Pour faciliter l'administration, trois entrées DNS statique ont été ajoutées pour le portail
d'administration de Proxmox et du NAS :
• Menu : Services > DNS Resolver > Host Overrides
• Host : gds-pmx-n1/ gds-pmx-n2 et gds-NAS
• Domain : gds.local
• IP Address : 192.168.10.11 - 192.168.10.12 et 192.168.10.50
• Description : Portail d’administration Proxmox et du NAS (OpenMediaVault)

77
Figure 24 : Entrées DNS statiques pour les nœuds Proxmox et Nas
4.3.3. Règles de sécurité Pare-feu et segmentation
La segmentation du réseau assurée par des règles de filtrage, appliquées sur les
interfaces OPT1 (Serveurs) et OPT2 (Employés), assurent que les serveurs sont isolés et que
les employés ne peuvent pas accéder au réseau d'administration (LAN), voir annexe II.
4.4. Présentation de Proxmox VE
La plateforme de virtualisation Proxmox VE combine dans une même solution,
l’hypervision, la gestion du réseau virtuel, le stockage via une interface accessible. C’est une
solution “tout-en-un” pour construire un cloud privé dans un contexte comme celui de GDS, où
l’on veut réutiliser le matériel existant et éviter la complexité d’OpenStack.
4.4.1. Architecture générale de Proxmox VE
Proxmox VE repose sur :
- Un système Linux (Debian): l’ISO Proxmox installe un Debian minimal avec le noyau
Proxmox.
- Deux technologies de virtualisation :
• KVM pour la virtualisation complète (VMs Windows, Linux, applicatives).
• LXC pour la virtualisation légère de services Linux (supervision, petit serveur web,
etc.).

78
- Une interface web d’administration qui permet de créer une VM, gérer le stockage, faire
les sauvegardes, voir la charge des nœuds.
- Un moteur de gestion de cluster (Corosync) pour faire travailler plusieurs serveurs
Proxmox ensemble.
4.4.2. Modes de déploiement
Proxmox peut être déployer et utiliser de plusieurs façons :
• Mode autonome (standalone) : Un seul serveur Proxmox pour un petit site avec un
manque de haute disponibilité si le serveur tombe, toutes les VMs tombent.
• Mode cluster Proxmox (2 ou plusieurs nœuds) : Plusieurs serveurs Proxmox sont joints
dans le même cluster, l’administration se fait sur une seule interface web. On peut déplacer
les VMs d’un nœud à l’autre avec un stockage partagé (NAS, Ceph), et activer la haute
activité et une redondance pour que les VMs redémarrent automatiquement sur l’autre
nœud.
• Mode cloud privé complet :
Proxmox est directement couplé à :
- Proxmox Backup Server pour les sauvegardes centralisées (S4),
- Un stockage réseau (NAS, NFS, iSCSI, Ceph) pour héberger les disques des VMs,
- Ou un pare-feu (pfSense) pour appliquer la politique de sécurité.
L’organisation hyperviseur, stockage, firewall, services en VMs devient
fonctionnellement un cloud privé, dans notre cas on part sur un déploiement en cluster à 2
nœuds avec un stockage réseau (NAS) et pfSense pour le routage des VLANs.
4.4.3. Gestion du Réseau dans Proxmox
Pour que les nœuds Proxmox puissent communiquer et héberger des VMs, leur réseau
interne est configuré. Proxmox utilise des "Linux Bridges" des ponts virtuels (vmbr0, vmbr1)
qui agissent comme des commutateurs virtuels.

79
Chaque pont est attaché à une carte réseau physique de la VM connectée au réseau interne
VirtualBox et gère le trafic d'un VLAN spécifique Dans notre architecture, GDS-PMX-N1 et
GDS-PMX-N2 sont doublement branchés sur deux (2) VLANs simulés :
• VLAN 10 (Management) : Pour l'administration des serveurs
• VLAN 20 (Serveurs/Services) : Pour le trafic de toutes les machines virtuelles qui
serviront les services (S1, S2, etc.).
Le tableau suivant résume la configuration réseau des nœuds Proxmox :
Carte Réseau
(VM)
Réseau Interne
(VirtualBox)
Pont Proxmox (Bridge) Rôle (VLAN
Simulé)
Carte 1
(enp0s3)
net-mgmt vmbr0 (Pont de
Management)
VLAN 10
Carte 2
(enp0s8)
net-servers vmbr1 (Pont de
Service/Cluster)
VLAN 20
Tableau 12 : tableau réseau des nœuds Proxmox et VirtualBox
4.4.4. Rôle de Proxmox (cloud privé )
Dans le chapitre 3, on a défini 6 services à fournir (S1 à S6). Proxmox est l’origine de ces
services parce qu’il fournit l’infrastructure d’hébergement et permettra de déployer tous les
services du cloud.
Il héberge les conteneurs qui serviront d’IAM (S1), la VM de stockage collaboratif ou de
Nextcloud (S2), et celle de supervision (S3), il va permettre de planifier et déclenche les
sauvegardes via Proxmox Backup Server (S4), en exposant les interfaces réseau des VMs vers
les VLANs protégés par pfSense (S5) via son portail d’administration (S6).
4.5. Installation et configuration des nœuds Proxmox
4.5.1. Installation de Proxmox VE
La première étape consiste à créer les VMs GDS-PMX-N1 et GDS-PMX-N2 (4Go
RAM, 2 CPU, 32Go Disque) dans VirtualBox sur l'ISO de Proxmox. Chacune des Vms utilisent

80
deux cartes réseau connectée à net-mgmt (VLAN 10) et net-servers (VLAN 20), voir annexe
II. Au moment de la configuration réseau :
• Interface de Management : enp0s3 (la carte connectée à net-mgmt).
• Adresse IP (statique) : 192.168.10.11/24
• Passerelle (Gateway) : 192.168.10.254 (L'adresse IP de notre GDS-FW pfSense)
• Serveur DNS : 192.168.10.254 (pfSense peut aussi agir comme DNS)
Nous répétons l'opération pour GDS-PMX-N2 avec l'IP 192.168.10.12/24.
Figures 25 : Résumé de la configuration initiale des Vms Proxmox

81
À la fin de l'installation, nous pouvons accéder à l'interface web de Proxmox sur les
deux VMs depuis notre GDS-Client-Admin sur le VLAN 10 via l'adresse https://gds-pmx-
n1:8006 et n2 pour le second nœud.
Figures 26 : Écrans web Proxmox après installation du nœud 1 et 2

82
4.5.2. Création des bridges réseau
Comme les VMs Proxmox sont doublement branchées (admin et services), on a créé deux
ponts Linux, Pour activer la seconde carte réseau (VLAN 20), un pont Linux (vmbr1) est créé
(via Datacenter > gds-pmx-n1 > Système > Réseau) et configuré :
• vmbr0 : relié à l’interface physique enp0s3 (réseau VirtualBox net-mgmt) via l’ip
192.168.10.11/24 ou .12 sur le deuxième nœud avec pour passerelle 192.168.10.254
• vmbr1 relié à l’interface physique enp0s8 (net-servers) via 192.168.20.11/24
Figure 27 : Création du bridge vmbr1

83
Figure 28 : Bridges configurés sur le réseau des nœuds
4.5.3. Création du cluster Proxmox
Nous allons maintenant procéder à la création du cluster afin de permettre au nœud de
GDS-PMX-N2 rejoindre le nœud principal de GDS-PMX-N1
Sur le nœud 1 :
Nom de la grappe : gds-cluster
Lien de cluster : 192.168.10.11 (vmbr0)

84
Figures 29 : Création du cluster gds-cluster sur le nœud 1
Sur le nœud 2 :
les informations de jonction récupérées sur le nœud 1
le mot de passe admin@gds.local du nœud 1
réseau de cluster 192.168.10.0/24 (vmbr0)

85
Figures 30 : le nœud 2 rejoint le cluster

86
Figure 31 : Cluster avec les deux nœuds
À ce stade, les deux hôtes apparaissent dans le même centre de données et sont
administrables depuis une seule interface.
Figure 32 : Résumé de la création du cluster
Nous pouvons aussi voir sur le menu le nombre de cluster en ligne, les ressources, donc
les tâches récentes se sont toutes exécutées avec succès.
4.6. Mise en place du stockage partagé (NAS / NFS)
Dans l’infrastructure cible le stockage doit être centralisé et accessible par les deux
nœuds Proxmox afin d’héberger les mêmes ISO, les mêmes templates LXC et un espace de
sauvegarde commun. Nous avons opté pour un NAS virtuel basé sur OpenMediaVault (OMV),
installé lui aussi dans VirtualBox, voir annexe II.
L’organisation est la suivante :
• La VM GDS-NAS est branchée sur VLAN 10 (pour l’administration) et sur VLAN 20
(pour le trafic de stockage),
• On lui ajoute un second disque qui servira au partage (voir annexe),

87
• Dans OMV on crée un système de fichiers puis un dossier partagé,
• On publie ce dossier en NFS,
• Et enfin on ajoute ce partage NFS dans Proxmox comme stockage commun.
Ainsi les deux nœuds gds-pmx-n1 et gds-pmx-n2 voient exactement le même stockage.
4.6.1. Installation et adressage de la VM GDS-NAS
Une fois que la VM GDS-NAS est créée pendant l’installation, l’interface principale est la
carte reliée au réseau net-mgmt (VLAN 10), voir annexe:
IPv4 : 192.168.10.50/24
Passerelle : 192.168.10.254 (pfSense)
DNS : 192.168.10.254
Cette adresse permettra au poste GDS-Client-Admin d’administrer OMV via l’interface web :
http://192.168.10.50
Figure 33 : Interface de connexion du Nas
Après le premier accès à l’interface, nous avons configuré la seconde carte réseau (celle reliée
à net-servers, VLAN 20) directement dans OMV :
Interface : enp0s9
IPv4 : 192.168.20.50/24

88
Passerelle : vide (on garde la passerelle du VLAN 10)
Cette double connexion rend le NAS joignable :
• depuis VLAN 10 pour l’administration,
• depuis VLAN 20 pour le montage NFS par Proxmox.
Figure 34 : Interfaces réseau configurées dans OMV
4.6.2. Ajout du disque de stockage et création du système de fichiers
Par défaut, OMV n’a qu’un seul disque (celui du système). Pour ne pas mélanger
système et données, nous avons ajouté un deuxième disque à la VM dans VirtualBox, voir
annexe.
Stockage → Disques : le disque /dev/sdb apparaît.
Stockage → Systèmes de fichiers → Créer :
Type : EXT4
Périphérique : /dev/sdb
Nom : proxmox-nfs
Une fois le système de fichiers créé, il est monté pour qu’il soit utilisable.

89
Figures 35 : Disque /dev/sdb ajouté et système de fichiers EXT4 “proxmox-nfs” monté
Ce volume sera la base du partage NFS.

90
4.6.3. Création du dossier partagé et export NFS
Nous passons à la création d’un dossier partagé proxmox-nfs et la publication en NFS
pour le réseau 192.168.20.0/24 (Vlan20).
Stockage → Dossiers partagés → Créer
Nom : proxmox-nfs
Périphérique : le volume EXT4 créé juste avant
Chemin : /proxmox-nfs
Figures 36 : Création du dossier partagé
Dans la section services le service NFS a été activé pour permettre l’accès aux nœuds du
cluster et de permettre aux nœuds Proxmox d’accéder à un espace de stockage partagé pour les
sauvegardes, les ISO et les conteneurs, nous avons mis en place un export NFS via OMV pour
garantir l’interopérabilité entre les nœuds du cluster et centraliser les données.

91
Dans l’interface d’administration on a tout d’abord créé un dossier partagé proxmox-nfs,
rattaché au volume EXT4 préalablement configuré. Ce dossier est accessible via le chemin
/proxmox-nfs.
• Clients autorisés : 192.168.20.0/24, ce qui limite volontairement l’accès au seul VLAN
20, où sont situés les deux nœuds Proxmox.
• Permissions : Lecture/Écriture, pour permettre aux nœuds de lire et écrire dans le
partage.
Une fois ces étapes réalisées, l’export NFS est accessible sur l’adresse IP 192.168.20.50
sous la forme /export/proxmox-nfs, pour être monté par les nœuds du cluster.
Figure 37 : Partage NFS “proxmox-nfs”
4.6.4. Ajout du NAS dans Proxmox comme stockage NFS
Dans cette dernière étape nous pouvons déclarer ce partage NFS côté Proxmox pour que
les deux nœuds puissent l’utiliser, voir les configurations dans l’annexe.
Dans l’interface Proxmox :
Centre de données → Stockage → Ajouter → NFS
ID : nas-nfs
Serveur : 192.168.20.50
Export : /export/proxmox-nfs

92
Contenu : Sauvegarde, Image ISO, Conteneur
Nœuds : gds-pmx-n1 et gds-pmx-n2
Figures 38 : Stockage NFS “nas-nfs” monté sur les deux nœuds Proxmox
Le stockage apparaît alors dans la liste, avec le chemin monté /mnt/pve/nas-nfs et le statut
“Oui” pour signaler que le partage est opérationnel.

93
Figure 39 : Stockage NFS nas-nfs visible sur les deux nœuds
4.7. Déploiement des services du cloud privé
Après la mise en place de l’infrastructure virtuelle (Proxmox pour la virtualisation, pfSense
pour la sécurité et le routage, NAS/NFS pour le stockage), nous avons déployé des services
métiers prévus dans la conception (S1 à S6).
Tous les services ont été déployés sous forme de conteneurs LXC plutôt que de machines
virtuelles complètes, car ils consomment moins de ressources et Proxmox les gère nativement.
Nous avons déployé quatre services :
1. S6 – Portail interne (point d’entrée)
2. S2 – Stockage collaboratif (Nextcloud)
3. S1 – IAM / Annuaire (OpenLDAP + phpldapadmin)
4. S3 – Supervision (Prometheus)
Tous les conteneurs sont sur le VLAN 20, avec une IP fixe, et un enregistrement DNS dans
pfSense.
4.7.1. Déploiement des conteneurs
Tous les services S1 à S6 ont été créés selon la même méthode :
1. Création du conteneur LXC dans Proxmox

94
Nœud : gds-pmx-n1
Bridge réseau : vmbr1 (VLAN 20 –servers)
Adresse IP statique du service : 192.168.20.60-63/24
Passerelle : 192.168.20.254 (pfSense – interface net-
servers)
DNS : 192.168.10.254 (pfSense)
2. Déclaration dans pfSense
Pour chaque service, une entrée a été ajoutée dans DNS Resolver de pfsense pour
permettre au poste d’un employé (VLAN 30) d’appeler le service par son nom et non par son
IP
Figure 40 : Exemple de conteneur LXC de service créé sur Proxmox

95
Figure 41 : Host Overrides dans pfSense pour les services
4.7.2. Service S6 – Portail interne d’accès
Ce service joue le rôle de point d’entrée unique vers l’ensemble des services du cloud privé.
Il s’agit d’une page web interne, hébergée dans un conteneur, qui regroupe les liens vers:
• Le stockage collaboratif (S2),
• L’annuaire / IAM (S1),
• La supervision (S3),
Dans le conteneur :
Figure 42 : téléchargement du serveur web Nginx

96
Depuis un poste utilisateur situé sur le VLAN 30, l’URL http://portal.gds.local affiche ce
portail grâce à la résolution DNS assurée par pfSense.
Figure 43 : Portail cloud disponible
Le portail affiché depuis le client VLAN 30
4.7.3. Service S2 – Stockage collaboratif
Ce service montre la capacité de la plateforme à héberger une application de type SaaS privé
comme Nextcloud pour le partage et la synchronisation de fichiers.
• La mise-à-jour des paquets et installation du serveur web Apache, du serveur MariaDB
pour la base de données, et des modules PHP requis pour Nextcloud sont les suivants
Figure 44 : Installation du serveur Apache et MariaDB
• La création de la base Nextcloud et de l’utilisateur SQL (admin) dans MariaDB avec le
téléchargement et déploiement de Nextcloud dans /var/www/html/Nextcloud.

97
Figure 45 : création de la base Nextcloud
• L’assistant d’installation Nextcloud s’affiche depuis le vlan de l’employé.
Figures 46 : Le portail et la page d’accueil Nextcloud

98
4.7.4. Service S1 – IAM / annuaire LDAP
Ce service permet de centraliser les identités dans un annuaire (OpenLDAP) hébergé dans
le cloud, les configurations voir annexe II. Le conteneur comporte :
• Un serveur OpenLDAP,
• Et l’interface web phpLDAPadmin pour l’administration graphique.
Le service est ensuite référencé dans le portail S6 afin que les administrateurs puissent y accéder
facilement.
Figures 47 : interface phpLDAPadmin, accessible

99
• La définition de l’url dans le portail :
Figure 48 : index.html du portail cloud
4.7.5. Service S3 – Supervision (Prometheus)
L’un des manques de l’existant était l’absence de supervision. En ajoutant Prometheus, on
démontre que nos services cloud peuvent être observés.
• Dans le conteneur on effectue le téléchargement et la décompression de Prometheus dans
/opt/prometheus;
cd /opt
wget
https://github.com/prometheus/prometheus/releases/download/v2.54.0/prometheus-
2.54.0.linux-amd64.tar.gz
tar -xzf prometheus-2.54.0.linux-amd64.tar.gz
mv prometheus-2.54.0.linux-amd64 prometheus
/opt/prometheus/prometheus --config.file=/opt/prometheus/prometheus.yml
Le lien dans le portail vers est http://ct-s3-monitor.gds.local:9090

100
Figures 49 : Les interfaces de Prometheus
La page web Prometheus donc accessible depuis le VLAN 30 et le scraper des conteneurs est
présent, voir annexe II pour les configurations.
4.8. Tests et validation
Pour valider l’ensemble de la solution, les tests suivants ont été réalisés depuis le poste GDS-
Client-Emp (VLAN 30) :

101
4.8.1. Test DNS interne depuis l’employé du vlan30
• Ping sur portal.gds. local, il répond 192.168.20.60
Figure 50 : Ping sur le portail web
• Ping sur le conteneur ct-s2-stockage.gds.local, il répond 192.168.20.61
Figure 51 : Ping via le nom de domaine
4.8.2. Test d’accès aux services
• http://portal.gds.local, le portail est opérationnel OK

102
Figure 52 : Portail web du cloud
• http://ct-s1-iam.gds.local/phpldapadmin, ce service d’annuaire est donc disponible
Figure 53 : Service annuaire disponible

103
4.8.3. Test de la segmentation
La tentative d’accès au VLAN 10 depuis VLAN 30 qui est refusé selon les règles pfSense que
nous avons défini pour la sécurité
Figure 54 : Tentative vers nœud1 VLAN10 (Action bloquée par pfsense)
Ces tests nous montrent que :
✓ la couche réseau (pfSense et VLANs) fonctionne et est sécurisée ;
✓ la couche virtualisation (Proxmox) héberge bien les services ;
✓ la couche services est réellement consommable depuis le réseau utilisateurs (VLAN30).

104
4.9. Complément : déploiement d’OpenStack via MicroStack
OpenStack a été identifié comme une plateforme de référence pour la mise en place de
clouds privés de type IaaS. Afin d’intégrer concrètement OpenStack à la solution, une preuve
de conception a été réalisée en déployant un cloud OpenStack à l’aide de MicroStack.
L’objectif n’est pas de remplacer l’architecture Proxmox/pfSense/NAS décrite
précédemment, mais de montrer qu’elle peut coexister avec une pile IaaS complète (Keystone,
Nova, Neutron, Glance, Cinder, Horizon), et que l’organisation pourrait à terme migrer vers un
cloud privé OpenStack en s’appuyant sur la même infrastructure réseau.
4.9.1. Mise en place de la VM OpenStack
Pour limiter la complexité matérielle, OpenStack a été déployé sous forme d’un nœud
unique “all-in-one” dans VirtualBox, une machine virtuelle dédiée a été créée :
• Nom de la VM : gds-os-all
• Système d’exploitation : Ubuntu 24.0 (64 bits)
• Ressources allouées : 4 vCPU, 8 Go de RAM, 60 Go de disque
• Réseau : carte réseau attachée au réseau interne net-servers (VLAN 20)
L’interface réseau de la VM a reçu les paramètres suivants :
• Adresse IPv4 : 192.168.20.70/24
• Passerelle : 192.168.20.254 (interface VLAN 20 de pfSense)
• DNS : 192.168.10.254 (pfSense, déjà utilisé comme DNS interne)
Pour rendre la plateforme facilement accessible depuis le poste employé (VLAN 30), une entrée
de résolution DNS interne a été ajoutée dans pfSense (Services → DNS Resolver → Host
Overrides) :
• Host : gds-os-all
• Domaine : gds.local
• IP : 192.168.20.70
L’interface est accessible via l’URL https://192.168.20.70/

105
4.9.2. Installation de MicroStack
MicroStack est une distribution empaquetée d’OpenStack proposée sous forme de
paquet. Elle permet de déployer en quelques commandes un nœud « tout-en-un » avec ses
services principaux :
• Keystone : service d’authentification et de gestion des identités (utilisateurs, rôles,
projets) ;
• Glance : service de gestion des images systèmes ;
• Nova : service de calcul pour l’orchestration des machines virtuelles ;
• Neutron : service de réseau pour la création des réseaux virtuels, sous-réseaux et
règles de sécurité ;
• Cinder : service de stockage bloc pour les volumes persistants ;
• Horizon : tableau de bord web permettant d’administrer la plateforme et de lancer
des instances.
Après avoir mis à jour les paquets et installé snapd (service de gestion des paquets Snap),
les commandes suivantes ont été exécutées sur la VM gds-os-all :
sudo snap install microstack –beta : permet d’installer MicroStack, une version simplifiée
d’OpenStack, à partir du canal bêta via le gestionnaire de paquets Snap.
sudo microstack init --auto –control : initialise automatiquement MicroStack en configurant
la machine comme nœud de contrôle du cloud OpenStack
Apres ça on récupère le mot de passe admin Keystone Via : sudo snap get microstack
config.credentials.keystone-password

106
Figures 55 : Installation et initialisation de MicroStack – capture du terminal
À l’issue de cette étape, tous les services nécessaires sont opérationnels sur ce noeud et le
tableau de bord Horizon est exposé sur l’adresse 192.168.20.70.
Figures 56 : Page de connexion et tableau de bord Horizon

107
La page Overview offre un résumé rapide de l’état actuel du cloud : quotas de calcul, de
mémoire, de stockage et de réseau.
4.9.3. Création du projet et des utilisateurs
Pour simuler l’usage par les employés, un projet spécifique a été créé. L’interface
OpenStack joue alors le rôle de portail IAM complémentaire au service S1 (OpenLDAP) pour
l’authentification et l’autorisation :
• Projet : GDS-employés
• Rôle : admin pour le compte administrateur, member pour les utilisateurs classiques.
Dans le menu Identity → Projects, le projet est créé. Ensuite, dans Identity → Users, des
comptes utilisateurs (emp1, emp2) sont ajoutés et associés au projet avec le rôle membre.
Figure 57 : Création du projet et des utilisateurs
4.9.4. Création du réseau privé OpenStack
Afin d’isoler les instances OpenStack dans un sous-réseau logique, un réseau privé a été créé
dans le projet GDS-employés, voir annexe II :

108
• Menu : Project → Network → Networks → Create Network
• Nom du réseau : gds-subnet
• Sous-réseau : 10.10.0.0/24
• Attribution DHCP : activée pour les instances
• Passerelle du sous-réseau : 10.10.0.1
Un routeur virtuel gds-router a ensuite été créé (annexe II) et associé au réseau public par
défaut de MicroStack (external-subnet), ce qui permettrait d’attribuer des futures adresses
flottantes (Floating IP) aux instances, annexe II.
Figure 58 : Création du réseau privé et du routeur dans Horizon)
Ce réseau privé complète la segmentation déjà réalisée avec pfSense : l’instance
OpenStack sera regroupée dans un segment logique interne au cloud, tout en restant joignables
via les mécanismes de routage d’OpenStack et de pfSense.

109
Pour pouvoir lancer des instances, une image système a été importée dans Glance voir annexe
II.
4.9.5. Lancement d’une instance OpenStack
Une fois le réseau, l’image et les règles de sécurité prêts, une instance de test a été déployée :
• Menu : Project → Compute → Instances → Launch Instance
• Nom de l’instance : vm-gds-stack
• Source de démarrage : image Cirros
• Réseau attaché : gds-subnet (annexe II)
• Saveur : saveur par défaut adaptée
Figure 59 : Instance de vm-gds-stack active et cli opérationnelle
L’instance passe à l’état ACTIVE et la console intégrée permet de vérifier le bon démarrage
du système.

110
4.9.6. Test d’accessibilité
Depuis le poste de l’utilisateur emp1, l’interface web Horizon est accessible : après
authentification, l’employé est automatiquement placé dans le projet GDS-employés qui lui a
été assigné en tant que membre. Il peut y consulter l’instance vm-gds-stack et, selon les droits
associés à son rôle

111
Figures 60 : test avec un employé
Ce chapitre a présenté la mise en œuvre opérationnelle de l’architecture cible définie.
Sur la base de pfSense, d’un cluster Proxmox VE et d’un NAS NFS, une infrastructure virtuelle
segmentée en VLAN a été construite pour héberger les services essentiels du cloud privé :
gestion des identités (S1), stockage collaboratif (S2), supervision (S3) et portail d’accès (S6).
Les tests réalisés depuis le VLAN 30 ont confirmé le bon fonctionnement de la couche réseau,
de la couche de virtualisation et de la couche services, ainsi que l’efficacité des mécanismes de
segmentation et de sécurité.
Enfin, le complément réalisé avec MicroStack a montré qu’une pile IaaS OpenStack peut être
intégrée sur la même infrastructure, ouvrant la voie à une éventuelle montée en puissance vers
un cloud privé OpenStack plus complet.

112
Chapitre 5 : Conclusion et perspectives
Ce travail avait pour thème « Étude et mise en place d’une solution de cloud computing »
dans un contexte où les organisations locales veulent moderniser leurs infrastructures sans
perdre la maîtrise de leurs données ni exploser leurs coûts d’équipement.
L’objectif général était de concevoir et mettre en place une solution de cloud computing
sécurisée et interopérable, capable de répondre aux besoins techniques, économiques et
réglementaires d’une organisation locale.
L’analyse de l’existant a permis de formuler les besoins sous forme de six services
fonctionnels (S1 à S6) qui ont servi de fil conducteur à l’ensemble du mémoire :
• S1 : gestion unifiée des identités / IAM
• S2 : stockage collaboratif souverain
• S3 : supervision / monitoring
• S4 : sauvegarde
• S5 : réseau sécurisé
• S6 : portail d’accès aux services
Leur mise en œuvre a permis de construire un cloud privé opérationnel, reposant sur des
outils open source robustes : Proxmox VE, pfSense, Nextcloud, OpenLDAP, et Prometheus.
On peut donc conclure point par point sur les objectifs qui ont été atteints.
Code Service Résultat
S1 Gestion des
identités / IAM
Atteint – Mise en œuvre d’un annuaire ldap via
phpLDAPadmin.
S2 Stockage
collaboratif
souverain
Atteint – Déploiement de Nextcloud sur un conteneur web
offrant un partage de fichiers accessible depuis le VLAN
utilisateurs.
S3 Supervision et
monitoring
Atteint – Installation de Prometheus pour la collecte de
métriques et visualisation des performances.
S4 Sauvegarde et
restauration
Partiellement atteint – Infrastructure prête (NAS NFS,
Proxmox Backup intégré), mais sans politique complète.

113
S5 Réseau sécurisé Atteint – Mise en œuvre de pfSense assurant le routage, la
segmentation VLAN et la sécurité des flux inter-VLAN.
S6 Portail d’accès
unifié
Atteint – Déploiement d’un portail web interne centralisant
l’accès aux services (stockage, IAM, supervision).
L’évaluation globale montre que les objectifs S1 (IAM), S2 (stockage souverain), S3
(supervision), S5 (réseau segmenté et sécurisé) et S6 (portail d’accès) ont été atteints.
Ainsi, la solution obtenue constitue une preuve de faisabilité d’un cloud privé localement
déployable, sécurisé, interopérable et économiquement viable pour une organisation locale.
De plus, le complément réalisé avec OpenStack via MicroStack a montré qu’une solution
complète peut être déployée sur la même infrastructure réseau que celle utilisée pour Proxmox
et confirme que notre architecture proposée peut évoluer vers un cloud privé OpenStack, sans
remettre en cause la segmentation réseau ni les services déjà déployés.
À l’issue de ces travaux, plusieurs pistes d’évolution peuvent être envisagées :
1. Renforcer la sauvegarde (S4)
Mettre en place Proxmox Backup Server avec une politique et la réplication distante pour la
mise en place d’un plan de reprise d’activité complet.
2. Optimiser la gestion des identités
Intégrer OpenLDAP avec Nextcloud, le portail interne, afin d’avoir vers une gestion
d’identités plus propre et qui simplifie l’authentification.
3. Améliorer la supervision
Associer Grafana à Prometheus pour construire des tableaux de bord plus avancés, incluant
non seulement les ressources Proxmox, mais aussi les équipements réseau, le NAS
4. Évoluer vers une structure de haute disponibilité
Étendre le cluster Proxmox à trois nœuds et intégrer un stockage distribué de type Ceph pour
renforcer la résilience.

i
Bibliographie
I. Mémoires
1. BARRY, Adja Fatoumata, Conception et Déploiement d'Infrastructures Cloud Virtualisées
avec Proxmox VE et OpenStack, Ecole Centrale des Logiciels Libres et de
Télécommunications (EC2LT), 2025, 124 pages.
2. DIOP, Mouhamadou Moustapha, Etude et mise en place d'une solution de cloud computing,
Institut Supérieur d'Informatique (ISI), 2018, 130 pages.
3. EL HELOU, Marwan, Comment le Cloud Computing peut accroître les performances d'un
système de production 4.0, HESAM Université, 2023, 115 pages.
4. ETOUAZNE Walid, Etude et mise en place des scenarios cloud sur google cloud platform
(GCP), École Nationale des Sciences Appliquées de Safi, 2023-2024, 89 pages.
5. GUESMI, Feten, Etude et mise en place d'une solution libre de Cloud Computing Privé
type Iaas, Université Virtuelle de Tunis (UVT), 2018-2019, 87 pages.
6. ISMAIL, Idris Abdillahi, Etude et Mise en Place d'une Solution Cloud Computing Privé,
École Supérieure de Management, de Télécommunication et d'Informatique (SUP MTI),
2018-2019, 53 pages.
7. KABA, Moustapha, Etude et mise en place d'une solution cloud computing sur une
infrastructure de virtualisation, Université Dakar Bourguiba, 2018-2019, 150 pages.
8. MEKEDEM, Sara, Le Cloud vis-à-vis du On-Premise, Université Paris 1 Panthéon
Sorbonne, 2021-2022, 85 pages.
9. MOUFAKIR, Tarik, Gestion des fonctions réseau et du trafic dans les réseaux virtualisés,
École de Technologie Supérieure (Université du Québec), 2022, 116 pages.
10. SLIM, Hannachi, Etude et Mise en Place d'une Solution Cloud Computing Privé au sein de
Tunisie Télécom, Institut Supérieur d'Informatique (ISI) / Université Tunis El Manar, 2014-
2015, 87 pages.
11. SOW, Souleymane, Orchestration de machines virtuelles, Université de Lille/ POLYTECH
LILLE, 2020-2021, 33 pages.

ii
II. Rapports
1. COLIN, Jean-Claude, Installation et configuration de Proxmox Virtualisation
Environnement, SEPR l'école des métiers, 26 pages.
2. MAAREF Slaheddine, Cloud Computing en Afrique : Situation et perspectives, Union
Internationale des Télécommunications (UIT), 2012, 59 pages.
3. MELL, Peter et GRANCE, Timothy, The NIST Definition of Cloud Computing, National
Institute of Standards and Technology (NIST), 2011, 7 pages.
4. NDG et VMware IT Academy, Cloud and Virtualization Concepts,100 pages.
5. RF-232, Installation physique de Proxmox VE, Micronator-dev, 2024, 169 pages.
6. SMILE, Virtualisation & Cloud: Principes, mise en oeuvre et outils open source, Smile,
2012, 47 pages.

iii
Webographie
https://www.futura-sciences.com/tech/definitions/informatique-cloud-computing-11573/
,consulté le 28 juillet 2025 à 16h00
https://www.redhat.com/fr/topics/virtualization , consulté le 30 juillet 2025 à 14h30
https://blog.stephane-robert.info/docs/virtualiser/ , consulté le 2 août 2025 à 11h00
https://www.redhat.com/fr/topics/cloud-computing , consulté le 5 août 2025 à 15h20
https://cloud.google.com/discover/types-of-cloud-computing?hl=fr , consulté le 7 août 2025 à
16h00
https://www.checkpoint.com/fr/cyber-hub/cloud-security/what-is-openstack/ , consulté le 9
août 2025 à 21h00
https://www.coursera.org/fr-FR/articles/cloud-solutions , consulté le 11 août 2025 à 06h00
https://www.oracle.com/africa-fr/cloud/networking/what-is-cloud-networking/ , consulté le 13
août 2025 à 04h45
https://cloud.google.com/learn/what-is-cloud-network-security?hl=fr , consulté le 15 août 2025
à 2h45
https://aws.amazon.com/fr/compare/the-difference-between-kubernetes-and-docker/ , consulté
le 17 août 2025 à 9h15
https://www.redhat.com/fr/topics/virtualization/what-is-a-virtual-machine , consulté le 19 août
2025 à 8h20
https://systalink.com/enjeux-cloud-computing-afrique/#Les_avantages_du_cloud_computing ,
consulté le 24 juillet 2025 à 03h36
https://www.akamai.com/fr/glossary/what-is-cloud-network-security , consulté le 26 juillet
2025 à 13h10
https://www.it-connect.fr/tuto-proxmox-ve-configuration-reseau/ , consulté le 4 août 2025 à
23h

iv
https://www.axido.fr/quels-sont-les-logiciels-de-virtualisation/ , consulté le 12 août 2025 à
05h15
https://aws.amazon.com/fr/what-is/digital-transformation/ , consulté le 20 août 2025 à 16h00
https://www.ibm.com/fr-fr/topics/cloud-computing , consulté le 22 août 2025 à 21h00
https://www.geeksforgeeks.org/cloud-computing/ , consulté le 24 août 2025 à 10h36
https://www.cloudflare.com/fr-fr/learning/network-layer/what-is-it-infrastructure/ , consulté le
26 août 2025 à 2h15
https://azure.microsoft.com/fr-fr/resources/cloud-computing/what-is-multicloud , consulté le
28 août 2025 à 13h10
https://www.fortinet.com/fr/resources/cyberglossary/cloud-security , consulté le 30 août 2025
à 22h55
https://www.proxmox.com , consulté le 1 septembre 2025 à 04h45
https://www.it-training-hub.com/proxmox , consulté le 3 septembre 2025 à 05h15
https://www.openmediavault.org , consulté le 5 septembre 2025 à 15h30
https://docs.netgate.com/pfsense/en/latest/ , consulté le 7 septembre 2025 à 19h47
https://docs.nextcloud.com , consulté le 9 septembre 2025 à 1h
https://prometheus.io/docs/introduction/overview/ , consulté le 11 septembre 2025 à 08h
https://www.openldap.org/doc/admin/ , consulté le 13 septembre 2025 à 17h
https://github.com/leenooks/phpLDAPadmin , consulté le 15 septembre 2025 à 19h

v
Annexes
Annexes I : Questionnaire
Le questionnaire soumis à certains professionnels via LinkedIn.

vi
Les réponses que j’ai pu avoir de 5 répondants :

ix
Annexes II : Autres documents
• La structure du projet sur VirtualBox
• Définition des cartes réseau dans la vm pfsense.

xi
• Dans le NAS
• Les employes du vlan 30 ont une carte reseau net-servers
• Les configurations d’installation pfsense

xii
• Apres assignation des interfaces réseau et adressage ip sur pfsense pour segmenter le
réseau

xiii
• Règles de sécurité définis sur pfSense

xiv
• DHCP activé pour les employés et les DNS definis pour l’accessibilité aux services
• Installation Openmediavault

xvi
• Ajout du disque dans virtualbox pour la mise en place du stockage partagé (NAS / NFS)

xvii
• Creation des conteneurs et installation des services accessibles sur nos nœuds proxmox
Configuration du conteneur avec le service qui hebergera l’interface web centralisé de tous les
services. Avec nginx

xviii
Pour le stockage avec nextcloud

xix
Installation de Openldap pour l’annuaire des utilisateurs

xx
Pour la supervision et l’etat des services nous avons installé prometheus et scrapper les ip
exportees depuis les services via commande prometheus-exporter

xxi
Dans le conteneur qui héberge le service de supervision nous avons défini les targets sur les IP
définit dans le réseau interne de Proxmox en écoute sur le vlan 20 définit dans pfSense
Le nœud exporter du Prometheus a été défini de la même façon dans les autres conteneurs
• OpenStack
• Création du réseau

xxiii
Création de l’image et de la cle sur openstack
• Creation de l’instance

xxv
Table des matières
Chapitre 1 : Introduction Générale ------------------------------------------------------------------ 1
1.1. Présentation du sujet................................................................................................. 1
1.2. Contexte et enjeux de la transformation numérique.............................................. 2
1.2.1. La transformation numérique moteur d’adoption du cloud ------------------------- 2
1.2.2. La transformation numérique locale --------------------------------------------------- 2
1.2.3. Les enjeux stratégiques, économiques et humains ----------------------------------- 3
1.2.3.1. Enjeux économiques ---------------------------------------------------------------- 3
1.2.3.2. Enjeux réglementaires -------------------------------------------------------------- 4
1.2.3.3. Souveraineté numérique------------------------------------------------------------ 5
1.2.3.4. Défis humains et organisationnels ------------------------------------------------ 5
1.3. Problématique............................................................................................................ 6
1.4. Objectifs du mémoire ................................................................................................ 7
1.4.1. Objectif général --------------------------------------------------------------------------- 7
1.4.2. Objectifs spécifiques --------------------------------------------------------------------- 7
1.5. Intérêts du sujet ......................................................................................................... 8
1.5.1. Intérêts pour l’entreprise ----------------------------------------------------------------- 8
1.5.2 Intérêts pour l'étudiant-------------------------------------------------------------------- 8
Chapitre 2 : État de l’art et solutions existantes--------------------------------------------------- 9
2.1. Fondamentaux techniques et réseaux pour le cloud............................................... 9
2.1.1. La virtualisation --------------------------------------------------------------------------10
2.1.2. Les hyperviseurs -------------------------------------------------------------------------10
2.1.3. Les avantages de la virtualisation------------------------------------------------------12
2.1.4. Les types de virtualisation --------------------------------------------------------------12
2.1.5. Les outils de virtualisation--------------------------------------------------------------15
2.2. Le Cloud Computing............................................................................................... 18
2.2.1. Les différents services du Cloud Computing ----------------------------------------18

xxvi
2.2.2. Architecture Fondamentale d'un Cloud-----------------------------------------------20
2.2.3. Les modèles de déploiement dans le Cloud Computing----------------------------21
2.2.3.1. Le Cloud privé ----------------------------------------------------------------------21
2.2.3.2. Le Cloud public---------------------------------------------------------------------22
2.2.3.3. Le Cloud hybride -------------------------------------------------------------------22
2.2.3.4. Le Cloud communautaire ---------------------------------------------------------22
2.2.4. La notion de Datacenter-----------------------------------------------------------------23
2.2.4.1. Architecture et principaux composants d’un datacenter ----------------------24
2.2.4.2. Typologie et niveaux de disponibilité des datacenters ------------------------27
2.2.4.3. Sécurité et sûreté des centres de données ---------------------------------------28
2.2.5. Les technologies complémentaires du Cloud ----------------------------------------29
2.2.5.1. La conteneurisation ----------------------------------------------------------------29
2.2.5.2. L’orchestration----------------------------------------------------------------------30
2.3. L’architecture réseau dans le cloud....................................................................... 31
2.3.1. Rappel sur le réseau ---------------------------------------------------------------------31
2.3.2. Les types de réseaux---------------------------------------------------------------------31
2.3.3. Les topologies réseau--------------------------------------------------------------------32
2.3.4. Les modèles de référence ---------------------------------------------------------------33
2.3.5. L’adressage IP, la gestion réseau et les protocoles essentiels ---------------------34
2.4. Critères de comparaisons des solutions Cloud...................................................... 36
2.4.1. Les critères fonctionnels ----------------------------------------------------------------36
2.4.2. Les critères non fonctionnels-----------------------------------------------------------37
2.5. Etude des solutions existantes................................................................................. 40
2.6. Conclusion................................................................................................................ 51
Chapitre 3 : Analyse de l’existant et Conception de la solution proposée ------------------52
3.1. Présentation de l’entreprise.................................................................................... 52
3.1.1. Activités principales ---------------------------------------------------------------------52

xxvii
3.1.2. Structure organisationnelle -------------------------------------------------------------53
3.2. Architecture de l’existant........................................................................................ 55
3.2.1. Présentation du réseau de GDS --------------------------------------------------------55
3.2.2. Topologie du réseau existant -----------------------------------------------------------56
3.2.3. Inventaire des ressources matérielles et logicielles existantes---------------------56
3.2.3.1. Inventaire des équipements serveurs et ordinateurs ---------------------------57
3.2.3.2. Inventaire des logiciels et systèmes d'exploitation ----------------------------58
3.2.4. Les avantages et limites de l’existant -------------------------------------------------59
3.2.4.1. Les Avantages de l’infrastructure actuelle--------------------------------------59
3.2.4.2. Les limites et contraintes observées ---------------------------------------------59
3.3. Conception de la solution proposée........................................................................ 61
3.3.1. Analyse des Besoins---------------------------------------------------------------------61
3.3.1.1. Besoins fonctionnels ---------------------------------------------------------------61
3.3.1.2. Besoins techniques -----------------------------------------------------------------62
3.3.1.3. Besoins organisationnels et réglementaires-------------------------------------62
3.4. Modèle fonctionnel – Cas d’utilisation .................................................................. 63
3.5. Choix des solutions technologiques et matérielles ................................................ 64
3.5.1. Choix matériel et infrastructure de base ----------------------------------------------64
3.5.2. Choix de la Solution Cloud-------------------------------------------------------------65
3.6. Architecture Cible de la Solution (Physique et Logique)..................................... 66
3.6.1. Architecture physique cible (Entreprise) ---------------------------------------------67
3.6.2. Architecture Logique Cible-------------------------------------------------------------68
3.7. Conclusion................................................................................................................ 71
Chapitre 4 : Mise en place de la solution proposée ----------------------------------------------72
4.1. Schéma de Déploiement .............................................................................................. 72
4.2. Présentation de l'Environnement de Test ................................................................. 73
4.2.1 Plan d’adressage------------------------------------------------------------------------------74

xxviii
4.2.2. Prérequis Logiciels --------------------------------------------------------------------------74
4.3. Déploiement du Router/Pare-feu (PfSense) .............................................................. 74
4.3.1. Création et Configuration des Interfaces Réseau ---------------------------------------75
4.3.2. Configuration des Services Réseau et Sécurité------------------------------------------76
4.3.3. Règles de sécurité Pare-feu et segmentation---------------------------------------------77
4.4. Présentation de Proxmox VE...................................................................................... 77
4.4.1. Architecture générale de Proxmox VE ---------------------------------------------------77
4.4.2. Modes de déploiement----------------------------------------------------------------------78
4.4.3. Gestion du Réseau dans Proxmox---------------------------------------------------------78
4.4.4. Rôle de Proxmox (cloud privé ) -----------------------------------------------------------79
4.5. Installation et configuration des nœuds Proxmox .................................................... 79
4.5.1. Installation de Proxmox VE----------------------------------------------------------------79
4.5.2. Création des bridges réseau ----------------------------------------------------------------82
4.5.3. Création du cluster Proxmox---------------------------------------------------------------83
4.6. Mise en place du stockage partagé (NAS / NFS)....................................................... 86
4.6.1. Installation et adressage de la VM GDS-NAS ------------------------------------------87
4.6.2. Ajout du disque de stockage et création du système de fichiers ----------------------88
4.6.3. Création du dossier partagé et export NFS-----------------------------------------------90
4.6.4. Ajout du NAS dans Proxmox comme stockage NFS ----------------------------------91
4.7. Déploiement des services du cloud privé ................................................................... 93
4.7.1. Déploiement des conteneurs ---------------------------------------------------------------93
4.7.2. Service S6 – Portail interne d’accès ------------------------------------------------------95
4.7.3. Service S2 – Stockage collaboratif--------------------------------------------------------96
4.7.4. Service S1 – IAM / annuaire LDAP ------------------------------------------------------98
4.7.5. Service S3 – Supervision (Prometheus)--------------------------------------------------99
4.8. Tests et validation ...................................................................................................... 100
4.8.1. Test DNS interne depuis l’employé du vlan30 --------------------------------------- 101

xxix
4.8.2. Test d’accès aux services----------------------------------------------------------------- 101
4.8.3. Test de la segmentation------------------------------------------------------------------- 103
4.9. Complément : déploiement d’OpenStack via MicroStack ................................ 104
4.9.1. Mise en place de la VM OpenStack------------------------------------------------- 104
4.9.2. Installation de MicroStack------------------------------------------------------------ 105
4.9.3. Création du projet et des utilisateurs ------------------------------------------------ 107
4.9.4. Création du réseau privé OpenStack ------------------------------------------------ 107
4.9.5. Lancement d’une instance OpenStack ---------------------------------------------- 109
4.9.6. Test d’accessibilité--------------------------------------------------------------------- 110
Chapitre 5 : Conclusion et perspectives ---------------------------------------------------------- 112
Bibliographie-----------------------------------------------------------------------------------------------i
I. Mémoires .....................................................................................................................i
II. Rapports .....................................................................................................................ii
Webographie --------------------------------------------------------------------------------------------- iii
Annexes----------------------------------------------------------------------------------------------------- v
Annexes I : Questionnaire.................................................................................................... v
Annexes II : Autres documents ..........................................................................................ix
Table des matières ------------------------------------------------------------------------------------ xxv

Résumé
Ce mémoire s’inscrit dans un contexte de transformation numérique au sein d’une
organisation locale, marqué par la modernisation des infrastructures et par des enjeux de
souveraineté, de sécurité et de conformité. Elle aborde la problématique de la conception d’une
solution de cloud computing locale, sécurisée et interopérable. La méthodologie adoptée
comprend l’analyse de l’infrastructure existante et l’élaboration d’une architecture cible
virtualisée. La solution mise en œuvre s’appuie sur des technologies open source : Proxmox VE
(virtualisation), pfSense (sécurité réseau), Nextcloud (stockage collaboratif), OpenLDAP
(gestion des identités), Prometheus (supervision) et un serveur de fichiers NFS/NAS. Ces outils
ont permis de déployer des services intégrés avec la gestion unifiée des identités, le stockage
collaboratif souverain, la supervision du système, et un portail d’accès unifié. La mise en place
de cette solution démontre la faisabilité d’un cloud privé, sécurisé, interopérable et
économiquement viable dans un contexte local.
Mots-clés : Cloud privé ; Virtualisation ; Proxmox VE ; pfSense ; NFS/NAS ; IAM/LDAP ;
Nextcloud ; Prometheus ; Souveraineté numérique.
Abstract
This thesis is set within a context of digital transformation in a local organization,
characterized by infrastructure modernization and issues of sovereignty, security, and
regulatory compliance. It addresses the challenge of designing a local, secure, and interoperable
cloud computing solution. The adopted methodology involves analyzing the existing
infrastructure and designing a virtualized target architecture.The implemented solution is based
on open-source technologies: Proxmox VE (virtualization), pfSense (network security),
Nextcloud (collaborative storage), OpenLDAP (identity management), Prometheus
(monitoring), and an NFS/NAS file server. These tools enabled the deployment of integrated
services including unified identity management, sovereign collaborative storage, system
monitoring, and a centralized access portal. The deployment of this solution demonstrates the
feasibility of a secure, interoperable, and cost-effective private cloud infrastructure tailored to
local contexts.
Keywords: Private Cloud; Virtualization; Proxmox VE; pfSense; NFS/NAS; IAM/LDAP;
Nextcloud; Prometheus; Digital Sovereignty.

MEMOIRE MASTER CLOUD COMPUTING FRANCK RECKATY.pdf

Contenu connexe

Similaire à MEMOIRE MASTER CLOUD COMPUTING FRANCK RECKATY.pdf

Dernier

MEMOIRE MASTER CLOUD COMPUTING FRANCK RECKATY.pdf