Mise en place d’un cloud privé hautement disponible (Proxmox® - Ceph – Terraform – Ansible) Soutenu par : RECULE Damien Organisme de formation : NEXT FORMATION – Paris Période du 11/09/2025 au 21/04/2026 Confidentialité : Document réservé aux membres du jury et au cadre pédagogique. Version du document : 3.1

Projet réalisé dans le cadre de la validation du titre professionnel

Administrateur d’Infrastructures Sécurisées

Mise en place d’un cloud privé hautement disponible

(Proxmox® - Ceph – Terraform – Ansible - Jenkins)

Table des mises à jours du document

Version	Date	Auteur	Description de la mise à jour
1.0	20/09/2025	RECULE Damien	Création initiale du document
1.1	22/09/2025	RECULE Damien	Ajout structure initiale et sommaire
1.2	25/09/2025	RECULE Damien	Ajout de l’introduction, préface
1.3	02/10/2026	RECULE Damien	Remerciements et présentation du contexte.
1.4	05/10/2026	RECULE Damien	Ajout de la présentation des entreprises
1.5	07/10/2025	RECULE Damien	Rédaction complète de l’analyse du besoin, objectifs, QQQQCCP et diagrammes
1.6	10/10/2025	RECULE Damien	Ajout du diagramme de la bête à cornes, pieuvre, Ishikawa et analyse fonctionnelle.
1.7	17/10/2025	RECULE Damien	Ajout du Cahier des Charges Fonctionnel et Technique (CDCF & CDCT).
1.8	20/10/2025	RECULE Damien	Méthodes, risques (AMDEC) et Gantt prévisionnel
1.9	21/10/2025	RECULE Damien	Ajout de la conception technique : architecture réseau, Ceph, OPNSense, Proxmox.
2.0	03/11/2025	RECULE Damien	Ajout diagrammes UML, WBS
2.1	07/11/2025	RECULE Damien	Ajout de la matrice RACI
2.2	10/11/2025	RECULE Damien	Ajout organigramme fonctionnel, architecture globale.
2.3	12/11/2025	RECULE Damien	Ajout du schéma réseau
2.4	15/12/2025	RECULE Damien	Rédaction de la phase de réalisation : installation, configuration, Dashboard Flask.
2.5	16/12/2025	RECULE Damien	Mise à jour du budget : matériel, licences, coût M0, TCO / ROI.
2.6	22/12/2025	RECULE Damien	Mise à jour risques, finalisation des annexes techniques.
2.7	23/12/2025	RECULE Damien	Corrections globales
2.8	24/12/2025	RECULE Damien	Uniformisation du style, ajout des légendes et schémas
2.9	28/12/2025	RECULE Damien	Finalisation du document pour soutenance
3.0	29/12/2025	RECULE Damien	Relecture et mise en forme.
3.1	23/01/2026	RECULE Damien	Relecture finale et mise en forme définitive.

Table des illustrations

Figure 1 Entreprise NebTech	26

Figure 2 Chiffre d'affaires NebTech	27

Figure 3 Organigramme NebTech	27

Figure 4 Entreprise NovaTechSolutions	28

Figure 5 Chiffres d'affaires NovaTechSolutions	29

Figure 6 Organigramme NovaTechSolutions	29

Figure 7 ANSSI (MIS) / ISO27001	33

Figure 8 Infrastructure initiale	35

Figure 9 Gestion d’une machine virtuelle (AS IS / TO-BE)	37

Figure 10 Business Model NovaTechSolutions	38

Figure 11 Méthode QQQQCCP	40

Figure 12 Diagramme d'Ishikawa	40

Figure 13 Diagramme Bête à cornes	42

Figure 14 Diagramme de la pieuvre	43

Figure 15 Objectifs fonctionnels	45

Figure 16 Carte Radar	45

Figure 17 Diagramme des objectifs techniques	46

Figure 18 Comparatifs Cloud Public – Cloud privés	47

Figure 19 Types de Cloud Privés	47

Figure 20 Objectifs opérationnels	48

Figure 21 Objectifs stratégiques	48

Figure 22 Tableau périmètre et hors périmètre	49

Figure 23 Structure WBS	51

Figure 24 Diagramme RACI	52

Figure 25 Carte des risques	53

Figure 26 Tableau – Carte des risques	53

Figure 27 Tableau – Evaluation des risques	53

Figure 28 Surface de risques du projet ………………………………………………………...…54

Figure 29 Diagramme de Gantt	56

Figure 30 Diagramme des contraintes	57

Figure 31 Diagramme des SysML	59

Figure 32 Radar KPI	61

Figure 33 Comparatif des Hyperviseurs Type 1	64

Figure 34 Synthèse – Choix des solutions	64

Figure 35 Diagramme d’architecture	65

Figure 36 Tableau coûts direct estimés	66

Figure 37 Diagramme TCO/ROI	66

Figure 38 Délais prévisionnels du projet	67

Figure 39 Budget – Prévision	68

Figure 40 Détails du Budget prévisionnel	68

Figure 41 Tableau énumération main-d’œuvre prévisionnel	69

Figure 42 Diagramme Workflow UML	70

Figure 43 Schéma d’architecture	71

Figure 44 Schéma d’architecture réseau.	72

Figure 45 Représentation matériels sur site	73

Figure 46 Plan d’adressage IP	74

Figure 47 Diagramme d’architecture technique globale	75

Figure 48 Tableau d’architecture technique globale	75

Figure 49 Récapitulatif des rôles des outils	76

Figure 50 MFA / Mtls	77

Figure 51 Centralisation des logs	78

Figure 52 Graylog – Logs Pve01	78

Figure 53 Stratégie de sauvegarde	79

Figure 54 PCA - PRA	80

Figure 55 Budget (estimation)	81

Figure 56 Répartition des grandes dépenses	81

Figure 57 Budget logiciels	82

Figure 58 Organigramme des services IT sollicités	83

Figure 59 Coût de main-d’œuvre	83

Figure 60 Gains annuels estimés	84

Figure 61 Analyse financières Power BI	84

Figure 62 Devis	85

Figure 63 BPI - France	86

Figure 64 Synthèse des indicateurs de succès KPI	87

Figure 65 Tableau de synthèse de clôture de projet	90

Figure 66 Formation du personnel	91

Figure 67 Bilan du projet	92

Figure 68 Améliorations futures	93

Figure 69 Correspondances REAC - Projet	95

Figure 70 Dashboard - Déploiement	96

Figure 71 Dashboard - Déploiement	97

Figure 72 Dashboard - Groupe de déploiement	97

Figure 73 Dashboard - Ansible	98

Figure 74 Dashboard – Déploiement logiciels	99

Figure 75 Identification Dashboard (MFA)	99

Figure 76 Accès au Dashboard refusé – Mtls absent	100

Figure 77 Connexion VPN au Dashboard	101

Figure 78 Centralisation des logs - Graylog	101

Figure 79 Résultats audit initial	111

Figure 80 Certificat – Python	115

Figure 81 Certificat – Python/Flask	115

Figure 82 Certificat – Kubernetes	115

Figure 83 Certificat – Windows Server 2025	115

Figure 84 Certificat – Docker avancé	115

Figure 85 Certificat – ANSSI MOOC	115

Figure 86 Inventaire Matériel	116

Figure 87 Cluster serveur Proxmox VE	116

Figure 88 Cluster OPNSense & Switch	117

Figure 89 Postes utilisateurs	117

Figure 90 Serveur Proxmox Backup	117

Figure 91 Serveur Proxmox Backup & SRV-ADDS	117

Figure 92 Serveur Proxmox Datacenter Mangement	117

Figure 93 Dashboard Proxmox pve01	118

Liste des abréviations

Abréviation	Signification	Description / Contexte projet
VM	Virtual Machine	Machine virtuelle déployée via Terraform sur Proxmox.
IAC	Infrastructure As Code	Concept d’automatisation de l’infrastructure via du code (Terraform, Ansible).
CI/CD	Continuous Intégration Continuous Deployment	Pipeline automatisé (Jenkins) pour déployer, tester et livrer en continu.
API	Application Programming Interface	Interface utilisée par Terraform pour communiquer avec Proxmox.
LAN	Local Area Network	Réseau interne (VLANs 10 / 20 / 30 / 40).
WAN	Wide Area Network	Accès Internet via box Free (port SFP+).
VLAN	Virtual Local Area Network	Segmentation réseau (Prod, Storage, Management…).
HA	High Availability	Haute disponibilité (Proxmox + Ceph).
HDD/SSD/NVMe	Hard Drive / Solid State Drive / Non-Volatile Memory Express	Types de stockage des nœuds Proxmox.
RBD	RADOS Block Device	Format de disque distribué utilisé par Ceph.
OSD	Object Storage Daemon	Processus Ceph stockant physiquement les données.
MON	Monitor	Service Ceph qui gère le quorum du cluster.
MGR	Manager	Service Ceph qui fournit la supervision et les métriques.
PBS	Proxmox Backup Server	Solution de sauvegarde utilisée pour les VM.
PVE	Proxmox Virtual Environment	Hyperviseur utilisé pour le cluster.
QEMU	Quick Emulator	Technologie de virtualisation utilisée par Proxmox.
LXC	Linux Container	Conteneur léger géré par Proxmox (optionnel).
SSH	Secure Shell	Accès sécurisé utilisé par Ansible et les administrateurs.
YAML	Yet Another Markup Language	Format utilisé par cloud-init et Ansible.
JSON	JavaScript Object Notation	Format utilisé pour certaines API et configs Terraform.
DNS	Domain Name System	Résolution de noms pour les VM et services.
ACL	Access Control List	Règles d'accès sur OPNSense / Ceph / Proxmox.
TFA / MFA	Two-Factor Authentication Multi-Factor Authentication	Sécurisation des comptes Proxmox / Jenkins.
UPS	Uninterruptible Power Supply	Onduleur pour sécuriser l’alimentation.
PDU	Power Distribution Unit	Barre d’alimentation intelligente dans la baie.
SFP+	Small Form-Factor Pluggable Plus	Port 10 Gbit utilisé pour uplinks switch ↔ OPNSense ↔ Freebox.
NIC	Network Interface Card	Carte réseau utilisée pour les VLAN, Ceph, management.
GUI	Graphical User Interface	Interface graphique (Proxmox WebUI, Dashboard Flask).
CLI	Command Line Interface	Ligne de commande (Terraform, Ansible, Jenkins CI).
HTTP(S)	HyperText Transfer Protocol (Secure)	Accès web à Proxmox, OPNSense, dashboard.
FW	Firewall	OPNSense dans ton projet.
IaC Pipeline	Infrastructure Pipeline	Chaîne Terraform → Ansible → Jenkins.
MAC	Media Access Control	Adresse matérielle réseau.
IPAM	IP Address Management	Gestion des adresses IP (répartition VLAN).
OIDC	OpenID Connect	Authentification possible pour Proxmox / Jenkins.
CA	Certificate Authority	Autorité de certification (sécurisation TLS).
RBAC	Role-Based Access Control	Gestion des permissions sous Proxmox / Jenkins.
PKI	Public Key Infrastructure	Infrastructure de certificats TLS.
PoE	Power over Ethernet	Pas utilisé ici mais possible pour switch administrables.
VPN	Virtual Private Network	WireGuard sur OPNSense (accès admin distant).
WG	Wireguard	Protocol VPN utilisé pour l’administration sécurisée.
AD	Active Directory	Pour ton template Windows ADirectory.

Table des matières

Table des mises à jour du document -----------------------------------------------------------------------------

Table des illustrations ----------------------------------------------------------------------------------------------

Liste des abréviations -----------------------------------------------------------------------------------------------

Table des matières ---------------------------------------------------------------------------------------------------

I. Préface --------------------------------------------------------------------------------------------------------------

II. Introduction ------------------------------------------------------------------------------------------------------

II.1 Contexte et objectifs du document -----------------------------------------------------------------------

II.2 Remerciements -----------------------------------------------------------------------------------------------

II.3 Les parties prenantes ---------------------------------------------------------------------------------------

A. Le porteur du projet (Parcours et missions réalisées) ------------------------------------------------

A.1 Mise en œuvre d'un serveur de stockage pour le service PAO --------------------------------

A.2 Participation à une campagne de sensibilisation à la sécurité informatique -----------------

A.3 Réalisation d'un projet "Maison de Santé du Bidou" -------------------------------------------

A.4 Formations complémentaires ----------------------------------------------------------------------

B. L'organisme de formation --------------------------------------------------------------------------------

C. Les éditeurs et communautés open source -------------------------------------------------------------

II.4 Présentation de l'entreprise NebTech (Prestataire) --------------------------------------------------

A. Historique et activité --------------------------------------------------------------------------------------

B. Organisation et rôle dans le projet ----------------------------------------------------------------------

II.5 Présentation de l'entreprise NovaTechSolutions (Client) -------------------------------------------

A. Historique et activité --------------------------------------------------------------------------------------

B. Organisation et rôle dans le projet ----------------------------------------------------------------------

III. Audit initial et analyse de l’existant -----------------------------------------------------------------------

III.1 Objectifs et périmètre de l’audit ------------------------------------------------------------------------

A. Objectif de l’audit ---------------------------------------------------------------------------------------

B. Périmètre de l’audit -------------------------------------------------------------------------------------

III.2 Méthodologie d’audit retenue ---------------------------------------------------------------------------

A. Etape de la méthodologie --------------------------------------------------------------------------------

III.3 Constat de l’infrastructure existante ------------------------------------------------------------------

A. Architecture et exploitation -----------------------------------------------------------------------------

B. Sécurité et gestion des accès ----------------------------------------------------------------------------

C. Supervision et sauvegardes ------------------------------------------------------------------------------

D. Identification des SPOF ----------------------------------------------------------------------------------

III.4 Synthèse des constats et axes d’amélioration -------------------------------------------------------

A. Recommandations ANSSI (MIS1 / MIS2) -------------------------------------------------------------

B. ISO/IEC 27001 – bonnes pratiques ---------------------------------------------------------------------

C. RGPD – principes généraux -----------------------------------------------------------------------------

IV. Analyse du besoin -----------------------------------------------------------------------------------------------

IV.1 Problématique et constats initiaux ----------------------------------------------------------------------

A. Constats de l'infrastructure initiale de NovaTechSolutions ------------------------------------------

B. Limites des dysfonctionnements identifiés -------------------------------------------------------------

B.1 Limites du processus AS IS (existant) -------------------------------------------------------------

B.2 Objectifs du processus TO-BE (cible) -------------------------------------------------------------

B.3 Synthèse AS IS / TO-BE ----------------------------------------------------------------------------

IV.2 Méthodologie d'analyse ------------------------------------------------------------------------------------

A. Le besoin ----------------------------------------------------------------------------------------------------

B. Problématiques ---------------------------------------------------------------------------------------------

IV.3 Analyse fonctionnelle --------------------------------------------------------------------------------------

A. Méthode QQQQCCP -------------------------------------------------------------------------------------

B. Limites de l'infrastructure existante (Diagramme d'Ishikawa) --------------------------------------

C. Diagramme de la bête à cornes --------------------------------------------------------------------------

D. Diagramme de la pieuvre --------------------------------------------------------------------------------

E. Acteurs externes -------------------------------------------------------------------------------------------

F. Acteurs internes -------------------------------------------------------------------------------------------

G. Objectifs fonctionnels ------------------------------------------------------------------------------------

H. Carte radar - Analyse visuelle ---------------------------------------------------------------------------

I. Objectifs opérationnels et stratégiques ------------------------------------------------------------------

I.1 Objectifs opérationnels -------------------------------------------------------------------------------

I.2 Objectifs stratégiques --------------------------------------------------------------------------------

V. Gestion du projet ------------------------------------------------------------------------------------------------

V.1 Objectif du projet -------------------------------------------------------------------------------------------

V.2 Périmètre et hors périmètre ------------------------------------------------------------------------------

A. Le projet couvre ------------------------------------------------------------------------------------------

B. Le projet ne couvre pas ----------------------------------------------------------------------------------

V.3 Méthodologie retenue : approche en cascade ----------------------------------------------------------

A. Diagramme RACI -----------------------------------------------------------------------------------------

V.4 Analyse des risques -----------------------------------------------------------------------------------------

A. Tableau d’évaluation des risques -----------------------------------------------------------------------

B. Risques opérationnels ------------------------------------------------------------------------------------

C. Risques stratégiques --------------------------------------------------------------------------------------

D. Spécifications techniques --------------------------------------------------------------------------------

V.5 Planification du projet -------------------------------------------------------------------------------------

A. Diagramme de GANTT ----------------------------------------------------------------------------------

VI. Cahier des charges --------------------------------------------------------------------------------------------

VI.1 Cahier des charges fonctionnel (CDCF) ---------------------------------------------------------------

A. Besoins fonctionnels ------------------------------------------------------------------------------------

B. Contraintes fonctionnelles -----------------------------------------------------------------------------

C. Diagramme SysML Requirements --------------------------------------------------------------------

D. Contraintes techniques, fonctionnelles et financières ----------------------------------------------

D.1 Introduction au diagramme des contraintes ----------------------------------------------------

D.2 Contraintes techniques -----------------------------------------------------------------------------

D.3 Contraintes fonctionnelles ------------------------------------------------------------------------

D.4 Contraintes financières ----------------------------------------------------------------------------

D.5 Indicateurs de succès (KPI) ----------------------------------------------------------------------

VI.2 Cahier des charges techniques (CDCT) ---------------------------------------------------------------

A. Exigences et contraintes techniques -------------------------------------------------------------------

A.1 Infrastructure système -----------------------------------------------------------------------------

A.2 Automatisation Terraform ------------------------------------------------------------------------

A.3 Dashboard Web (Flask/Python) -------------------------------------------------------------------

A.4 Intégration Ansible ---------------------------------------------------------------------------------

A.5 Supervision et Journaux d'évènements ----------------------------------------------------------

B. Etude comparative des solutions ----------------------------------------------------------------------

B.1 Comparatif des hyperviseurs de type 1 (Proxmox, VMware, Hyper V) --------------------

B.2 Comparatif des solutions de pare-feu (PfSense, OPNsense, Fortigate, Cisco, Sophos) ---

C. Architecture cible ----------------------------------------------------------------------------------------

C.1 Choix d’architecture --------------------------------------------------------------------------------

C.2 Schéma logique --------------------------------------------------------------------------------------

VI.3 Enveloppe budgétaire -------------------------------------------------------------------------------------

A. Coûts directs estimés (Diagramme TCO/ROI) ------------------------------------------------------

B. Délais (Prévision) ----------------------------------------------------------------------------------------

C. Introduction au devis ------------------------------------------------------------------------------------

D. Budget main d'œuvre -------------------------------------------------------------------------------------

VII. Phase de conception ------------------------------------------------------------------------------------------

VII.1 Conception fonctionnelle -------------------------------------------------------------------------------

A. Diagramme de séquence « Déploiement VM » (Workflow UML) -------------------------------

VII.2 Conception technique ----------------------------------------------------------------------------------

A. Schéma d'architecture ----------------------------------------------------------------------------------

B. Analyse du schéma d'architecture ----------------------------------------------------------------------

C. Schéma d'architecture réseau ---------------------------------------------------------------------------

D. Plan d’adressage IP --------------------------------------------------------------------------------------

VII.3 Vision d’exploitation et de production ---------------------------------------------------------------

A. Diagramme d’Architecture Technique Global ------------------------------------------------------

B. Stratégie de sécurité globale ---------------------------------------------------------------------------

B.1 Authentification forte (MFA, Mtls) -------------------------------------------------------------

B.2 Segmentation réseau -------------------------------------------------------------------------------

B.3 Journalisation et SOC ------------------------------------------------------------------------------

B.4 Gestion des vulnérabilités --------------------------------------------------------------------------

C. Plan de continuité (PCA) et reprise d’activité (PRA) ------------------------------------------------

VIII. Budget détaillé ----------------------------------------------------------------------------------------------

VIII.1 Introduction et objectifs budgétaires ---------------------------------------------------------------

VIII.2 Budget logiciels ------------------------------------------------------------------------------------------

VIII.3 Coût de main d'œuvre ---------------------------------------------------------------------------------

VIII.4 Analyse financière --------------------------------------------------------------------------------------

VIII.5 Analyse comparative : cloud public & Cloud privé ----------------------------------------------

VIII.6 Devis -------------------------------------------------------------------------------------------------------

VIII.7 Dispositifs d’accompagnement et aides à la transformation numérique ---------------------

IX. Analyse des résultats -----------------------------------------------------------------------------------------

IX.1 Performance ------------------------------------------------------------------------------------------------

IX.2 Stabilité et disponibilité ----------------------------------------------------------------------------------

IX.3 Gains obtenus ----------------------------------------------------------------------------------------------

IX.4 Respect du budget et des délais ------------------------------------------------------------------------

X. Clôture du projet & Recette -----------------------------------------------------------------------------------

X.1 Recette fonctionnelle ---------------------------------------------------------------------------------------

A. Livrables réalisés ----------------------------------------------------------------------------------------

A.1 Livrables techniques -------------------------------------------------------------------------------

A.2 Livrables documentaires --------------------------------------------------------------------------

A.3 Formation du personnel ---------------------------------------------------------------------------

A.4 Conduite du changement --------------------------------------------------------------------------

A.5 Mise en production --------------------------------------------------------------------------------

B. Bilan du projet -------------------------------------------------------------------------------------------

XI. Pistes d’amélioration futures -------------------------------------------------------------------------------

XI.1 Contexte et démarches d’amélioration continue ---------------------------------------------------

XI.2 Montée en maturité DevOps ---------------------------------------------------------------------------

XI.3 Mise en place d’une observabilité avancée ----------------------------------------------------------

XI.4 Automatisation du patch management ---------------------------------------------------------------

XI.5 Evolutivité et industrialisation de l’architecture ---------------------------------------------------

XI.6 Bénéfices attendus des améliorations futures --------------------------------------------------------

XII. Compétences couvertes par le projet ---------------------------------------------------------------------

XIII. Tests de production ----------------------------------------------------------------------------------------

XIII.1 Tests fonctionnels et techniques ---------------------------------------------------------------------

XIII.2 Tests de sécurité et de conformité -------------------------------------------------------------------

XIV. Glossaire ------------------------------------------------------------------------------------------------------

XV. Bibliographie -------------------------------------------------------------------------------------------------

XVI. Webographie --------------------------------------------------------------------------------------------------

XVII. Annexes --------------------------------------------------------------------------------------------------------

XVII.1 Rapports d’audit de l’infrastructure initiale de NovaTechSolutions ------------------------

XVII.2 Certificats de formation ------------------------------------------------------------------------------

XVII.3 Matériels utilisés pour la mise en place du projet ------------------------------------------------

XVII.4 Annexes techniques du Dashboard -----------------------------------------------------------------

Préface

Préface

Présentation et objectifs personnels

Depuis mon enfance, l’informatique occupe une place essentielle dans mes centres d’intérêt. C’est au début des années 80 que j’ai découvert mes premiers ordinateurs (Atari STE, Amiga), puis plus tard les plateformes Intel 80486DX et 80486DXII 66. Ils ont éveillé en moi une passion profonde pour les systèmes, la logique et la technologie. Cette curiosité initiale ne m’a jamais quitté, même lorsque mon parcours professionnel m’a orienté vers un tout autre domaine.

Après une scolarité classique, j’ai rejoint le secteur automobile et intégré le groupe Renault, où j’ai travaillé près de trente ans au sein des chaînes de production. J’y ai progressivement évolué jusqu’à devenir responsable de la programmation des robots industriels, notamment via les systèmes professionnels KUKA.

Cette expérience m’a permis de développer une grande rigueur technique, une capacité d’analyse aiguisée et une méthodologie structurée, des compétences que l’on retrouve naturellement dans l’administration système et réseau.

En 2022, porté par l’envie de me consacrer plus amplement à ma passion pour l’informatique, j’ai entamé une reconversion professionnelle. J’ai d’abord appris en autodidacte les bases des systèmes, des réseaux et des environnements Windows et Linux, avant d’intégrer la formation de Technicien Supérieur Systèmes et Réseaux au sein de l’organisme de formation NextFormation. Cette première étape a renforcé mon intérêt pour les infrastructures, la sécurité et l’automatisation, ce qui m’a conduit naturellement vers la formation d’Administrateur d’Infrastructures Sécurisées, que je poursuis aujourd’hui avec motivation et détermination.

En parallèle de mon parcours technique et après 30 ans d’étude en égyptien hiéroglyphique au sein de l’Institut Khéops et l’école du Louvre, je suis depuis plus de treize ans pigiste pour un magazine spécialisé en égyptologie (Pharaon Magazine), où je traduis des textes littéraires en hiéroglyphes. Cette activité, exigeant patience, précision et sens du détail, complète parfaitement les qualités nécessaires au travail d’un administrateur systèmes et réseaux : constance, minutie, grande rigueur documentaire et maîtrise des outils intellectuels.

C’est dans ce contexte mêlant reconversion, passion ancienne et montée en compétences progressive que s’inscrit ce projet de fin d’étude. La conception d’un cloud privé automatisé, associé à un Dashboard complet développé en Flask/Python, représente pour moi bien plus qu’un exercice technique, c’est la synthèse de mon expérience industrielle, de ma méthodologie acquise en formation, et de ma volonté d’apprendre et de créer par moi-même.

À l’issue de ma formation d’Administrateur d’Infrastructures Sécurisées, j’ambitionne de poursuivre mon parcours au sein de NextFormation en préparant la certification de Formateur pour Adultes, afin de transmettre à mon tour les compétences que j’ai acquises et accompagner d’autres apprenants dans leur évolution professionnelle.

Ce rapport traduit non seulement le travail technique fourni, mais également le chemin parcouru, la reconversion accomplie et la passion qui continue de me guider.

RECULE Damien

Introduction

Introduction

II.1 Contexte et objectifs du document

Ce mémoire de fin d’études est réalisé dans le cadre de l’obtention du titre d’Administrateur d’Infrastructures Sécurisées. Il sera soutenu devant un jury composé de professionnels du secteur et s’appuiera sur un projet concret et particulièrement enrichissant : la mise en place d’un cloud privé hautement disponible, que j’ai eu l’opportunité de concevoir et de déployer cette année au sein de mon infrastructure personnelle. J’atteste que ce document est le fruit de mon travail personnel et des efforts que j’ai consacrés à sa réalisation.

II.2 Remerciements

Je souhaite exprimer ma profonde gratitude à l’ensemble des personnes qui ont contribué, de près ou de loin, à l’élaboration de ce mémoire. Leur accompagnement, leur confiance et leurs encouragements ont constitué une aide précieuse tout au long de ce projet.

Je remercie tout particulièrement mes deux tuteurs de stages, Maxime Glorieux et Edouard COT ainsi que l’ensemble de mes formateurs, dont les conseils avisés, la disponibilité constante et l’expertise professionnelle ont guidé chacune des étapes de mon travail. Leur exigence bienveillante et leur sens du partage ont largement participé à l’enrichissement de mes connaissances et au développement de mes compétences.

J’adresse également mes sincères remerciements à mes collègues et camarades, dont le soutien, les échanges constructifs et l’esprit de collaboration ont favorisé un climat d’apprentissage stimulant et motivant.

Enfin, je tiens à exprimer toute ma reconnaissance à ma famille et à mes proches. Leur patience, leur compréhension et leur présence indéfectible ont été pour moi une source essentielle de réconfort et de motivation tout au long de la rédaction de ce document.

II.3 Les parties prenantes

Dans le cadre de ce projet, plusieurs parties prenantes interviennent et contribuent directement ou indirectement à sa réussite.

A. Le porteur du projet (Parcours et missions réalisées)

Le premier acteur est moi-même, en tant qu’auteur et concepteur du projet.
Mon rôle a consisté à définir les besoins techniques et fonctionnels, concevoir l’architecture de la solution, développer le Dashboard en Flask/Python, intégrer et automatiser les outils (Proxmox, Terraform, Ansible, Jenkins), assurer les tests, la documentation et la mise en production.

Mon implication personnelle est centrale, le projet s’inscrivant dans un parcours de reconversion professionnelle, d’autoformation et de montée en compétence continue.

Au cours de ma formation et de mes expériences professionnelles en reconversion, j’ai été amené à participer à plusieurs projets techniques et organisationnels qui ont consolidé mes compétences en administration système, en gestion d’infrastructures, en cyber sécurité et en gestion de projet.
Ces missions m’ont permis d’acquérir une vision globale du fonctionnement d’un système d’information moderne, tout en développant une méthodologie rigoureuse et une capacité d’adaptation essentielle au métier d’administrateur d’infrastructures sécurisées.

A.1 Mise en œuvre d’un serveur de stockage pour le service PAO

Dans le cadre de mon stage qui s’est déroulé du 10/02/2026 au 10/04/2026 ; j’ai été amené à participer à l'amélioration des performances et de la gestion des ressources du service PAO de la Caisse d’allocations familiales située 82 rue Brûle-Maison à Lille.

Cette mission comportait les actions suivantes :

Analyse des besoins en capacité, redondance et performances.

Sélection d’une architecture de stockage adaptée (NAS/SAN).

Installation et configuration du serveur (système, RAID, services).

Mise en place des partages réseau (SMB/NFS) et gestion fine des ACL.

Optimisation des performances en fonction des charges PAO.

Réalisation des tests, validation, documentation et mise en production.

Ce projet m’a permis de développer des compétences solides en gestion du stockage, en administration système et en sécurisation de données critiques.

A.2 Participation à une campagne de sensibilisation à la sécurité informatique

Conscient des risques liés aux comportements utilisateurs, j’ai également contribué à l’élaboration d’un programme interne de sensibilisation à la cyber sécurité.
Cette campagne avait pour objectif d’améliorer la posture de sécurité globale de l’entreprise.

Mes actions :

Identification des failles organisationnelles liées aux usages.

Rédaction de supports pédagogiques : affiches, guides, communications internes.

Création de contenus liés au phishing, à la gestion des mots de passe, aux usages mobiles.

Vulgarisation de notions techniques pour les rendre accessibles à tous.

Participation au déploiement de la campagne dans les différents services.

Cette mission m’a permis de renforcer mes compétences en cyber sécurité, communication, pédagogie et conduite du changement.

A.3 Réalisation d’un projet « Maison de Santé du Bidou »

Avant de réaliser le projet de Cloud Privé présenté dans ce dossier, j’ai conçu et mené à terme un premier projet complet d’infrastructure informatique : la Maison de Santé du Bidou.

Ce projet, effectué dans un contexte pédagogique, m’a permis de consolider mes compétences techniques et méthodologiques à travers une architecture réseau multi-VLAN, sécurisée et opérationnelle.

Présentation générale du projet

La Maison de Santé du Bidou est un établissement fictif regroupant plusieurs professionnels de santé (médecins, infirmiers, psychologues, secrétariat, dentistes, sécurité, etc.).

L’objectif était de concevoir une infrastructure informatique complète, intégrant :

Un réseau isolées et sécurisées.

Des postes et serveurs répartis en VLAN.

Une haute disponibilité firewall (OPNSense HA CARP).

Des services Active Directory, RDS, Web, VoIP, caméra IP.

Une DMZ sécurisée pour les accès externes et les invités.

Une supervision et une gestion des logs.

L’infrastructure conçue devait répondre aux besoins d’un établissement médical moderne : sécurité, confidentialité, disponibilité, résilience, gestion fine des réseaux métiers et invités.

Architecture réseau mise en place

L’architecture complète est représentée dans le schéma ci-dessous :

Projet Maison de santé du Bidou

Détails de l’infrastructure

Cluster de virtualisation Proxmox

Segmentation réseau par VLAN (10 / 20 / 30 / 40 / 50 / 60).

Firewalling – OPNSense - cluster HA (CARP)

Réseaux WAN, VPN, DMZ, invités.

Interface SYNC dédiée pour HA.

Active Directory : domaine MS_BIDOU.lan

DNS, DHCP, WSUS, WDS.

Serveur Web / Mail / RDS.

DMZ

Services Web et accès distant sécurisés.

Bornes Wifi invité isolées.

Téléphonie VoIP

Serveur VoIP (3CX / XIVO).

Postes téléphoniques dédiés aux médecins, secrétariat, dentiste.

Vidéo-protection & sécurité

VLAN caméra dédié.

Serveur supervision interne.

L’ensemble a été conçu de manière professionnelle, segmentée, sécurisée et conforme aux bonnes pratiques (séparation des flux, zones de confiance, DMZ, accès invités isolés…).

Compétences mobilisées

Conception et administration d’un réseau sécurisé

Mise en place d’un plan d’adressage structuré.

Segmentation du réseau en VLAN métiers, invités, caméra, DMZ.

Déploiement d’une infrastructure firewall en haute disponibilité (OPNSense HA CARP).

Rédaction et application de politiques de filtrage et de routage sécurisées.

Isolation réseau des flux sensibles (AD, caméras).

Mise en œuvre d’un environnement Active Directory sécurisé

Installation d’ADDS (domaine : MS_BIDOU.lan).

Mise en place d’un DNS/DHCP AD-intégrés.

Structuration des OU, GPO de sécurité et gestion des stratégies utilisateur.

Déploiement de services complémentaires (WSUS, WDS, RDS).

Administration des systèmes virtualisés

Création et gestion des VM sous Proxmox.

Isolation réseau via bridges + VLAN.

Mise en place de snapshots et bonnes pratiques de virtualisation.

Déploiement d’un cluster virtualisé

Utilisation de Proxmox VE pour centraliser les services du SI.

Virtualisation des firewalls, serveurs métier et services AD.

Gestion de la disponibilité élevée via la duplication des firewalls.

Services en DMZ et gestion des zones exposées

Déploiement de services Web et Email en zone isolée.

Mise en place d’une DMZ sécurisée pour accès externes.

Architecture multizones conforme aux bonnes pratiques (LAN, DMZ, WAN, Guests)

Téléphonie IP et infrastructure VoIP

Déploiement d’un serveur 3CX/XIVO virtualisé.

Intégration des postes VoIP dans le VLAN téléphonie.

Sécurité interne et vidéo-protection

Intégration d’un réseau caméra IP dédié.

Mise en place d’un serveur de supervision du système de sécurité.

Isolation totale du VLAN caméra du reste du SI.

Documentation, supervision et gestion des incidents

Documentation technique complète (schémas, plan IP, topologie).

Centralisation des logs via OPNSense + supervision des serveurs.

Analyse et résolution des incidents de connectivité (routage, ACL, VLAN).

Méthodologie et gestion de projet (C12)

Analyse des besoins et rédaction du cahier des charges initiales.

Réalisation du schéma d’architecture final.

Planification, organisation des tâches et justification des choix techniques.

Présentation du projet finalisé (communication professionnelle).

A.4 Formation complémentaire

Dans le cadre de ma reconversion et afin de renforcer mes compétences techniques au-delà du programme officiel de la formation d’Administrateur d’Infrastructures Sécurisées, j’ai suivi plusieurs formations supplémentaires, toutes validées par des certifications.
Ces apprentissages volontaires témoignent de ma volonté de monter rapidement en compétence, d’acquérir une autonomie technique solide et de maîtriser les technologies indispensables à la mise en place d’infrastructures modernes.

Certifications obtenues

Certification - Docker – Conteneurisation & orchestration

Cette formation m’a permis d’acquérir une compréhension avancée des principes de conteneurisation, de la gestion des images et de l’isolation applicative.
Utilisé pour effectuer des test hors production, cette compétence a renforcé ma compréhension des environnements virtualisés et des pipelines DevOps.

Certification - Python – Développement d’automatisation

Python étant au cœur de mon projet (backend du dashboard, interactions API, monitoring), cette certification a constitué une base essentielle pour développer une application robuste, sécurisée et maintenable.

Certification - Flask – Développement Web Python

Cette formation m’a permis de comprendre et mettre en œuvre la structure d’une application Flask complète, la gestion des routes, des templates et des sessions, l’intégration d’API externes (ici : API Proxmox) et la sécurisation des applications web (HTTPS, authentification).
C’est grâce à ces compétences que j’ai pu développer intégralement le Dashboard utilisé dans ce projet.

Certification - Windows Server 2025 – Administration & Sécurité

Cette formation couvre la gestion de l’Active Directory, la mise en place d’ADCS (PKI), utilisée ici pour générer un certificat HTTPS, les stratégies de sécurité avancées, la supervision et les bonnes pratiques de durcissement.
Elle a contribué directement à sécuriser mon infrastructure et à comprendre les enjeux d’authentification centralisée.

- Certificats - Kubernetes - Installation & Configuration

Cette formation apporte les bases techniques et méthodologiques nécessaires à la mise en œuvre de clusters Kubernetes, en couvrant l’architecture, le réseau, le déploiement d’applications conteneurisées et la gestion de la haute disponibilité en environnement de production.

- Certificats - L’essentiel de Windows Server 2025

Cette formation apporte les compétences nécessaires à l’installation, à la configuration et à l’administration de Windows Server 2025, incluant l’intégration cloud Azure, l’administration à distance et le renforcement de la sécurité des services.

Apport au projet

Ces certifications m’ont permis d’acquérir une vision transversale des technologies modernes, couvrant la virtualisation, la sécurité, l’automatisation et le développement.

Elles ont constitué des leviers essentiels pour concevoir et développer un dashboard fiable, sécurisé et ergonomique, mettre en œuvre des automatisations cohérentes via Terraform et Ansible, renforcer la sécurité globale de l’environnement, et structurer une architecture pérenne alignée sur les pratiques professionnelles et les recommandations actuelles.

Elles ont également contribué à une meilleure prise en compte des enjeux d’exploitation, de supervision et d’évolutivité dès la phase de conception.

L’ensemble des certificats est fourni en annexe du dossier.

B. L’organisme de formation

Mon organisme de formation, NextFormation (Paris), joue un rôle central dans la création de mon projet, en assurant l’accompagnement pédagogique, la mise à disposition des ressources techniques, ainsi que le suivi méthodologique nécessaire à la bonne conduite du projet.

Son rôle a été d’assurer la transmission des compétences techniques fondamentales, d’encadrer méthodologiquement le projet et de fournir un cadre pédagogique pour mener à bien cette réalisation.

Les formateurs m’ont apporté leur expertise en sécurité informatique, administration système et gestion d’infrastructures, garantissant la cohérence technique et la conformité aux bonnes pratiques du métier.

De plus, l’équipe pédagogique a assuré un suivi régulier, des retours constructifs et un cadre structuré permettant d’orienter le projet vers des objectifs réalistes et opérationnels.

Enfin, les autres acteurs tels que les apprenants du groupe et les professionnels rencontrés contribuent eux aussi par leurs échanges et leurs retours d’expérience faisant de ce projet un travail collaboratif s’inscrivant pleinement dans un contexte professionnel.

C. Les éditeurs et communautés open source

Bien que n’ayant pas pris part directement à la conduite du projet, les communautés et les éditeurs des technologies mobilisées (notamment Proxmox, Ansible, Jenkins, Python/Flask, Ceph, Terraform, Graylog, Postfix et Docker) doivent également être considérés comme des parties prenantes « externes » à part entière.

En effet, leur contribution dépasse largement la simple mise à disposition d’outils. Elle s’incarne dans la qualité et l’accessibilité de la documentation officielle, dans la richesse des forums d’entraide et des espaces collaboratifs, ainsi que dans la production continue de guides, de recommandations méthodologiques et de bonnes pratiques relatives au déploiement, à l’automatisation et à l’observabilité des systèmes.

L’expertise collective issue de ces communautés techniques constitue un socle de connaissances essentiel, dont la maturité et la fiabilité ont permis d’élaborer une solution robuste, conforme aux standards contemporains de l’ingénierie logicielle et de l’infrastructure informatique. Leur apport s’avère ainsi déterminant dans l’intégration, l’optimisation et la pérennisation des différentes briques technologiques mises en œuvre au sein du projet.

II.4 Présentation de l’entreprise NebTech (Prestataire)

A. Historique et activité

Située à Saint Amand-les-eaux (59), NebTech a été fondée en 2010 par un groupe d’ingénieurs spécialisés en informatique et télécommunications. L’objectif initial de l’entreprise était de fournir des services d’hébergement pour les petites entreprises et de gérer leurs infrastructures informatiques de manière externalisée.

Au fil des années, elle s’est développée rapidement et a élargi ses services pour inclure l’infogérance complète (administration des systèmes et réseaux).

Figure 1 Entreprise NebTech

Aujourd’hui, NebTech compte plusieurs dizaines de collaborateurs et gère plus de 100 clients actifs sur son infrastructure.

L’activité principale de NebTech Solutions repose sur l’hébergement et l’infogérance d’infrastructures IT pour ses clients. Les services proposés incluent l’hébergement de serveurs et d’applications ainsi que la mise à disposition de serveurs physiques et virtuels pour les clients. Elle propose également la gestion et la maintenance des systèmes (suivi, mise à jour et sécurisation des serveurs et des applications), la sauvegarde (sécurité des données), tout comme la virtualisation de serveurs et de postes de travail.

Elle intervient enfin dans le déploiement de clusters Proxmox, VMware ou autres solutions cloud, le support technique et l’assistance hotline, l’intervention sur site et à distance et dans les audits de sécurité.

Chiffre d’affaires

Le chiffre d’affaires de la NebTech présente une croissance régulière sur la période 2020–2025, passant de 1,5 M€ à une prévision de 3,2 M€ en 2025, soit une progression de plus de 113 % en 5 ans.

: 1,5 millions d’euros

: 2,3 millions d’euros

: 2,5 millions d’euros

: 2,7 millions d’euros

: 2,5 millions d’euros

(Prévision) : 3,2 millions d’euros

Figure 2 Chiffre d'affaires NebTech

B. Organisation et rôle dans le projet

Organigramme

Figure 3 Organigramme NebTech

Rôle de NebTech dans le projet

NebTech intervient en tant que prestataire informatique et intégrateur technique chargé de la conception, du déploiement et de l’automatisation du cloud privé de NovaTechSolutions. L’entreprise met à disposition une équipe pluridisciplinaire composée d’un chef de projet IT, d’administrateurs systèmes et réseaux, de spécialistes sécurité, d’un développeur web et d’un pôle support/formation.

Les interactions entre NebTech, NovaTechSolutions et les autres acteurs du projet sont analysées plus en détail dans la phase d’analyse fonctionnelle, notamment à travers les diagrammes de la pieuvre et le diagramme RACI.

II.5 Présentation de l’entreprise NovaTechSolutions (Client)

A. Historique et activité

Fondée en 2019, NovaTechSolutions est une entreprise française basée à Lille, spécialisée dans le développement de logiciels d’entreprise, la gestion de données et les solutions numériques pour PME.

Depuis sa création, NovaTechSolutions a grandi rapidement et s’est imposée comme un acteur clé dans la gestion d’applications métiers, l’édition de logiciels internes, le traitement de données structurées ainsi que le support informatique pour entreprises locales.

L’entreprise est née de la volonté de trois ingénieurs passionnés d’infrastructure IT, de cyber sécurité et d’automatisation, qui ont constaté que de nombreuses PME françaises manquaient d’outils modernes pour exploiter le plein potentiel des solutions numériques.

Figure 4 Entreprise NovaTechSolutions

NovaTechSolutions ambitionne de transformer le numérique des PME en simplifiant l’accès aux technologies modernes. Son objectif est de fournir un environnement logiciel fiable, sécurisé et évolutif, capable d’accompagner la croissance des entreprises locales.

Positionnée dans un marché en croissance, NovaTechSolutions développe et maintien des solutions logicielles utilisées dans la logistique, la santé, les services financiers, les commerces de proximité ou encore l’industrie légère, notamment des applications web internes, des outils de gestion de stock, des plateformes de suivi client et des applications d’analyses et de reporting.

Chiffre d’affaires

Le chiffre d’affaires de NovaTechSolutions présente une croissance plutôt régulière depuis 2021, passant de 1,5 M€ à une prévision de 1.9 M€ en 2025, soit une progression de plus de 26.7 % en 4 ans.

: 1,3 millions d’euros

2020 : 1,1 millions d’euros

2021 : 1,5 millions d’euros

2022 : 1,7 millions d’euros

2023 : 1,5 millions d’euros

: 1,4 millions d’euros

: (Prévision) : 1.9 millions d’euros

Figure 5 Chiffres d'affaires NovaTechSolutions

B. Organisation et rôle dans le projet

Organigramme

Figure 6 Organigramme NovaTechSolutions

Rôle dans le projet

NovaTechSolutions intervient dans ce projet en tant qu’entreprise cliente et bénéficiaire de la solution mise en œuvre.
À ce titre, elle exprime les besoins fonctionnels et opérationnels, définit les contraintes métiers et valide les orientations proposées tout au long du projet.
L’entreprise fournit également l’environnement existant servant de base à l’audit initial, permettant d’identifier les axes d’amélioration et de construire une architecture cible adaptée à ses enjeux.
NovaTechSolutions participe aux phases de validation, notamment lors des étapes de recette fonctionnelle et de mise en production, afin de s’assurer que la solution répond aux attentes en matière de performance, de sécurité et d’exploitabilité.
Enfin, l’entreprise est destinataire des livrables techniques et documentaires, ainsi que de la formation associée, garantissant une appropriation durable de la solution.

-------------------------------------------------------------------

Audit Initial et analyse de l’existant

Audit Initial et analyse de l’existant

(Rapports d’audit en Annexe du document).

III.1 Objectifs et périmètre de l’audit

Objectif de l’audit

L’audit a pour objectif d’évaluer le niveau de maturité de l’infrastructure existante de NovaTechSolutions afin d’identifier les axes d’amélioration en matière de :

Disponibilité et continuité de service.

Sécurité des accès et des données.

Automatisation et industrialisation.

Supervision et exploitation quotidienne.

Cet audit vise à fournir une base factuelle permettant de définir une architecture cible plus résiliente, sécurisée et adaptée à un usage en production.

Périmètre de l’audit

L’audit porte sur :

L’infrastructure de virtualisation Proxmox VE.

L’architecture réseau et les flux.

Les mécanismes de sécurité et de contrôle des accès.

Les processus d’exploitation (déploiement, supervision, sauvegarde).

Le matériel n’est pas remis en cause : l’audit se concentre sur les pratiques, l’architecture et l’exploitation.

III.2 Méthodologie d’audit retenue

L’audit s’appuie sur une démarche de type audit de maturité, inspirée des bonnes pratiques :

ISO 27001 (sécurité de l’information).

Recommandations de l’ANSSI.

Exigences MIS1 / MIS2.

Étapes de la méthodologie

Analyse documentaire (schémas, configurations existantes)

Observation de l’architecture en place

Identification des dysfonctionnements et risques

Analyse des causes (diagramme d’Ishikawa)

Synthèse des constats et priorisation des axes d’amélioration

Cette approche permet de ne pas traiter uniquement les symptômes, mais bien les causes racines.

III.3 Constat de l’infrastructure existante

Architecture et exploitation

L’infrastructure existante repose sur :

Un unique nœud Proxmox VE.

Absence de haute disponibilité.

Stockage local externe (USB).

Les principales limites identifiées sont :

Absence de tolérance à la panne.

Indisponibilité totale en cas de défaillance du nœud.

Processus de création et de gestion des machines virtuelles entièrement manuels.

Temps de déploiement long et non standardisé.

L’architecture est fonctionnelle, mais peu adaptée à un contexte de production.

Sécurité et gestion des accès

L’audit met en évidence :

Une gestion des accès peu centralisée.

L’absence d’authentification forte généralisée.

Des accès d’administration reposant principalement sur des identifiants classiques.

Une segmentation réseau limitée.

Les contrôles de sécurité sont présents mais hétérogènes, ce qui complique :

La traçabilité.

La gestion des droits.

La réduction de la surface d’attaque.

Supervision et sauvegardes

L’infrastructure existante ne dispose pas de :

Supervision centralisée.

Centralisation des journaux d’événements.

Visibilité globale sur l’état du système.

Les sauvegardes sont :

Ponctuelles.

Non automatisées.

Sans véritable stratégie formalisée.

En cas d’incident, le temps de diagnostic et de reprise d’activité est élevé.

Identification des SPOF (Single Point of Failure)

L’audit met en évidence plusieurs points de défaillance uniques :

Le nœud Proxmox unique.

Le stockage local non redondé.

L’absence de redondance réseau.

L’absence de mécanisme de bascule automatique.

Ces SPOF représentent un risque majeur pour la continuité de service et constituent un frein à une exploitation fiable en production.

III.4 Synthèse des constats et axes d’amélioration

L’audit de l’infrastructure existante met en évidence un niveau de maturité limité, principalement en matière de disponibilité, de sécurité et d’exploitation.

Les principaux risques identifiés concernent l’indisponibilité des services, la dépendance à des composants uniques (SPOF), le manque de traçabilité des accès et l’absence d’automatisation des opérations critiques.

Ces constats justifient la mise en place d’une nouvelle architecture cible visant à renforcer la résilience globale, à sécuriser les accès, à industrialiser les déploiements et à améliorer la supervision de l’environnement.

Les axes d’amélioration identifiés servent de fondement aux choix techniques et organisationnels présentés dans les chapitres suivants.

Figure 7 ANSSI (MIS) / ISO27001

Recommandations ANSSI (MIS1 / MIS2)

Le projet s’appuie sur les recommandations publiées par l’Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI), et plus particulièrement sur les Mesures d’Hygiène de Sécurité (MIS1 et MIS2).
Ces recommandations constituent un socle de bonnes pratiques visant à améliorer le niveau de sécurité

des systèmes d’information, notamment en matière de gestion des accès, de journalisation, de segmentation réseau et de sauvegarde des données.
Dans le cadre de ce projet, les principes MIS1 et MIS2 ont servi de référentiel pour identifier les écarts de sécurité de l’infrastructure existante et orienter la conception d’une architecture plus résiliente et sécurisée, adaptée à un environnement de production.

ISO/IEC 27001 – Bonnes pratiques

Les bonnes pratiques issues de la norme ISO/IEC 27001 ont été prises en compte afin d’inscrire le projet dans une démarche structurée de gestion des risques liés à la sécurité de l’information.
Sans viser une certification formelle, cette norme a servi de cadre méthodologique pour aborder les notions de gouvernance, de contrôle des accès, de traçabilité, de gestion des incidents et d’amélioration continue.
L’approche adoptée permet de poser les bases d’un système de management de la sécurité de l’information (SMSI) cohérent, proportionné au contexte et à la taille de l’entreprise.

RGPD – Principes généraux

Le projet intègre les principes fondamentaux du Règlement Général sur la Protection des Données (RGPD), en particulier en matière de confidentialité, de sécurité et de traçabilité des accès aux données.
Les mécanismes mis en œuvre, tels que le contrôle strict des accès, la journalisation des événements et la sécurisation des communications, contribuent à limiter les risques de compromission et à garantir une meilleure protection des données traitées par le système.
Cette prise en compte du RGPD s’inscrit dans une démarche de conformité pragmatique, visant à renforcer la protection des données sans alourdir excessivement l’exploitation de l’infrastructure.

---------------------------------------------------

Analyse du besoin

Analyse du besoin

IV.1 Problématique initiale

A. Constats sur l’infrastructure initiale de NovaTechSolutions

La figure ci-dessus présente l’architecture actuelle de l’infrastructure informatique de NovaTechSolutions. L’accès aux services de l’entreprise s’effectue depuis le réseau WAN, via la box opérateur, puis transite par un firewall unique, ne disposant pas de mécanisme de haute disponibilité. Ce firewall constitue un point critique de l’infrastructure : en cas de panne ou de défaillance, l’ensemble des services devient indisponible.

L’environnement de virtualisation repose sur un unique hyperviseur Proxmox VE fonctionnant sur un seul nœud physique. L’ensemble des applications et machines virtuelles est hébergé sur ce serveur unique, sans possibilité de bascule automatique ni de répartition de charge. Cette architecture crée un point de défaillance unique (Single Point of Failure), augmentant significativement les risques d’interruption de service.

Les données applicatives sont stockées sur une base de données non redondante, sans mécanisme de réplication ou de tolérance aux pannes. En cas de défaillance matérielle ou logicielle, la perte de données pourrait être totale. La stratégie de sauvegarde repose uniquement sur une sauvegarde locale sur support USB. Cette méthode, bien que simple à mettre en œuvre, présente plusieurs limites majeures : absence d’automatisation, dépendance à des manipulations manuelles, absence de redondance et impossibilité de restauration rapide en cas de sinistre majeur (incendie, vol, panne matérielle critique).

Enfin, les postes de travail accèdent directement aux machines virtuelles et aux applications hébergées sur l’hyperviseur, sans segmentation réseau avancée ni isolation stricte des flux, ce qui limite les capacités de sécurisation et de contrôle.

Figure 8 Infrastructure initiale

B. Limites des dysfonctionnements identifiés – Processus AS IS / TO-BE

L’analyse de l’infrastructure existante (AS IS) de NovaTechSolutions met en évidence plusieurs limites structurelles et fonctionnelles qui impactent directement la disponibilité des services, la sécurité des données et l’efficacité opérationnelle des équipes IT.

B1. Limites du processus AS IS (existant)

Le fonctionnement actuel repose sur des processus majoritairement manuels et peu industrialisés.

Les principales limites identifiées sont les suivantes :

Absence de haute disponibilité
L’infrastructure s’appuie sur un unique hyperviseur Proxmox et un firewall sans mécanisme de redondance. Cette architecture introduit plusieurs Single Points of Failure. Une panne matérielle ou logicielle entraîne une indisponibilité totale des services hébergés.

Gestion manuelle du cycle de vie des machines virtuelles
La création, la configuration et la maintenance des machines virtuelles nécessitent des interventions manuelles, directement depuis l’interface Proxmox ou en ligne de commande. Cette approche augmente le temps de déploiement et le risque d’erreurs humaines.

Absence d’automatisation et de standardisation
Les machines virtuelles ne reposent pas sur des templates homogènes ni sur une approche Infrastructure as Code. Chaque déploiement est traité comme un cas isolé, rendant difficile la reproductibilité et la traçabilité des actions.

Stratégie de sauvegarde insuffisante
Les sauvegardes sont réalisées localement sur support USB, sans automatisation, sans redondance et sans externalisation. Ce mode opératoire ne répond pas aux exigences de continuité d’activité (PCA/PRA) et expose l’entreprise à un risque élevé de perte de données.

Supervision et visibilité limitées
L’infrastructure ne dispose pas de solution centralisée de supervision ou de journalisation. Il est difficile d’avoir une vision globale de l’état des ressources (CPU, RAM, stockage, services), ce qui limite la capacité d’anticipation et de réaction face aux incidents.

Sécurité perfectible
L’absence de segmentation réseau avancée, de journalisation centralisée et de contrôle fin des accès limite le niveau de sécurité global de l’infrastructure et complique la détection d’événements anormaux.

B2. Objectifs du processus TO-BE (cible)

Face à ces limites, le projet vise à transformer en profondeur le fonctionnement de l’infrastructure en mettant en place un processus TO-BE moderne, automatisé et résilient.

Le processus cible repose sur les principes suivants :

Haute disponibilité et résilience
Mise en place d’un cluster Proxmox multi-nœuds associé à un stockage distribué Ceph, permettant la tolérance à la panne d’un serveur ou d’un disque sans interruption de service.

Automatisation complète du cycle de vie des VMs
Utilisation de Terraform pour le provisioning automatisé des machines virtuelles et d’Ansible pour leur configuration post-déploiement, garantissant rapidité, homogénéité et fiabilité.

Centralisation des opérations
Développement d’un dashboard web unique permettant de piloter l’ensemble des actions : déploiement, supervision, maintenance et consultation des logs, sans intervention directe sur les outils sous-jacents.

Sécurisation renforcée
Implémentation d’un accès sécurisé au dashboard (HTTPS, authentification renforcée, 2FA), segmentation réseau par VLAN, firewall en haute disponibilité et accès distant sécurisé via VPN.

Supervision et traçabilité
Centralisation des journaux et des métriques via des outils de supervision et de logging (Graylog), offrant une visibilité complète et en temps réel sur l’état de l’infrastructure.

B3. Synthèse AS IS / TO-BE

La transition du processus AS IS vers le processus TO-BE permet de passer d’une infrastructure fragile à une plateforme hautement disponible, d’opérations manuelles à une automatisation complète, d’une gestion dispersée à un pilotage centralisé et d’une sécurité minimale à une sécurité maîtrisée et auditable.

Cette évolution constitue le socle du projet de Cloud Privé pour NovaTechSolutions.

Figure 9 Gestion d’une machine virtuelle (AS IS / TO-BE)

IV.2 Méthodologie d’analyse

A. Le besoin

La mise en place d’une infrastructure Cloud Privé pour NovaTechSolutions répond à plusieurs motivations stratégiques, techniques et organisationnelles. L’entreprise fait face à une croissance soutenue, à des besoins de virtualisation de plus en plus importants et à une dépendance forte aux services Cloud externes, générant des coûts et des risques supplémentaires.

Face à ces enjeux, NovaTechSolutions souhaite disposer d’une infrastructure moderne, automatisée et totalement maîtrisée, capable d’assurer la continuité de service et l’autonomie technologique.

Afin de garantir la cohérence stratégique du projet, il est essentiel d’en comprendre les fondements économiques et organisationnels.

Le diagramme ci-dessous présente une synthèse claire et structurée du Business Plan associé au projet, en mettant en évidence les éléments clés qui orientent les choix techniques et financiers.

Figure 10 Business Model NovaTechSolutions

Moderniser une infrastructure devenue obsolète

Les serveurs actuels de NovaTechSolutions manquent de performance, de redondance et d’outils de gestion modernes.
Le projet vise donc à mettre fin aux déploiements manuels, réduire les risques de panne et à standardiser les environnements de travails.

Gagner en autonomie vis-à-vis du cloud public

Actuellement, une partie des services repose sur des ressources Cloud externes (AWS).
Or, cette solution externe augmente les coûts mensuels, limitent la flexibilité et exposent à la dépendance fournisseur.

Le Cloud Privé apporte, quant à lui, l’autonomie complète sur le matériel, les données et la sécurité.

Réduire les temps de déploiement grâce à l’automatisation

L’un des objectifs majeurs est de réduire drastiquement le temps nécessaire pour créer une nouvelle VM.
Grâce à Terraform, Ansible et aux Template cloud-init, NovaTechSolutions pourra créer une VM en quelques dizaines de secondes, réduire les erreurs humaines et ainsi disposer d’un pipeline CI/CD géré par Jenkins.

Assurer une haute disponibilité et une résilience accrue

L’infrastructure doit être capable de supporter la panne d’un serveur ou d’un disque de stockage sans interruption de service.

Le cluster Proxmox et la technologie Ceph apporte réplication des données, tolérance aux pannes et continuité d'activité.

Renforcer la sécurité et la souveraineté des données

Le Cloud Privé permet de conserver les données dans l’entreprise, protégées par un Firewall, une segmentation réseau (VLAN), un VPN sécurisé, une stratégie de sauvegarde via Proxmox Backup Server (PBS) et une gestion fine des accès aux ressources.

Avec le Dashboard Cloud développé en Python/Flask, NovaTechSolutions obtient un portail interne unique, un accès Terraform Plan / Apply dynamique, un historique des déploiements et une interface simple pour les administrateurs.

Ainsi, cela professionnalise la gestion interne.

Accompagner la croissance de l’entreprise

NovaTechSolutions prévoit une croissance de son activité et du nombre de clients dans un avenir proche, aussi le Cloud Privé répond à l’augmentation des besoins, à la montée en charge et à la nécessité d’être efficace dans les déploiements.

Ce projet s’inscrit donc dans une démarche visant à fiabiliser l’infrastructure, à préparer l’avenir, à soutenir la stratégie digitale et à réduire les coûts opérationnels à long terme.

B. Problématiques

Comment moderniser l’infrastructure interne afin de disposer d’un cloud privé HA, automatisé et scalable, capable d’héberger les services internes de manière fiable, tout en réduisant la dépendance au cloud public ?

Actuellement, l’infrastructure IT de l’entreprise repose sur des serveurs physiques vieillissants et des machines virtuelles déployées de manière manuelle, sans système de haute disponibilité ni solution de sauvegarde centralisée.

Aussi, NovaTech Solutions fait face à une infrastructure fragile, peu résiliente et difficile à maintenir, qui ne répond plus aux standards modernes d’hébergement et d’infogérance.

L’objectif du projet est donc de moderniser l’infrastructure, de mettre en place une plateforme virtualisée, automatisée et résiliente, permettant de réduire les interruptions, d’améliorer la sécurité et la gestion des données, et de faciliter la montée en charge et le déploiement rapide de nouvelles applications.

IV.3 Analyse fonctionnelle

A. Méthode QQQQCCP

Afin de comprendre précisément le besoin réel de NovaTechSolutions et de définir correctement les contours du projet de Cloud Privé, une analyse préliminaire a été réalisée à l’aide de la méthode QQQQCCP (Qui ? Quoi ? Où ? Quand ? Comment ? Combien ? Pourquoi ?).

Cette méthode structurée permet d’examiner le contexte sous tous ses angles et de clarifier les enjeux, les acteurs impliqués, les contraintes techniques et organisationnelles, ainsi que les motivations profondes qui justifient la mise en place d’une infrastructure privée moderne et automatisée.

Il met en évidence les attentes fonctionnelles de NovaTechSolutions, les problématiques identifiées dans l’infrastructure actuelle, et les résultats attendus en termes de disponibilité, sécurité, scalabilité et automatisation. Cette analyse est essentielle pour cadrer le projet, orienter les choix techniques et

garantir que la solution proposée par NebTech réponde pleinement aux objectifs opérationnels et stratégiques du client.

Quoi ?	Mise en place d’un Cloud Privé complet hébergé chez NovaTechSolutions, basé sur un cluster Proxmox, un stockage Ceph, un firewall OPNSense, et un dashboard automatisé permettant le déploiement de VM via Terraform.
Qui ?	NebTech : Conception, déploiement, supervision du projet. NovaTechSolutions : Client final, PME de finance et gestion documentaire.
Où ?	Sur le site informatique de NovaTechSolutions à Lille.
Quand ?	Projet initié en 2024. Mise en place du 26/09/2025 au 31/10/2025.
Comment ?	En construisant une architecture moderne et segmentée : Cluster Proxmox 3 nœuds (VLAN 10) Ceph OSD & HA Templates Windows/Linux (Terraform, Ansible, Jenkins, Docker, K8s, OPNSense Firewall) En automatisant tout le cycle de vie des VM grâce à : Terraform + provider Proxmox Cloud-init Un dashboard Flask pour déploiement en un clic Logging des déploiements
Combien ?	Coût total estimé : ~20k–25k € (hors main d’œuvre client)
Pourquoi ?	Pour résoudre les problèmes actuels de NovaTechSolutions : Déploiement de VM trop lent et manuel Absence d’automatisation / pas d’Infrastructure as Code Manque de standardisation (Templates hétérogènes) Risques de sécurité liés aux interventions manuelles Et apporter : Un cloud privé sur mesure, sécurisé et évolutif Une maîtrise totale des ressources Une réduction des erreurs humaines Une base solide pour le déploiement des Vms

Figure 11 Méthode QQQQCCP

B. Limites de l’infrastructure existante (Diagramme d’Ishikawa)

L’infrastructure actuelle de NovaTechSolutions présente plusieurs limitations qui impactent directement la qualité du service proposé aux clients, aussi un diagramme d’Ishikawa a été établi.

Figure 12 Diagramme d'Ishikawa

Le diagramme présenté ci-dessus permet d’identifier, classifier et visualiser l’ensemble des causes qui conduisent à une infrastructure informatique mal sécurisée, non automatisée et difficile à faire évoluer.

Chaque catégorie regroupe plusieurs problèmes contribuant à la situation actuelle de NovaTechSolutions.

Matériels & Infrastructures

Dans cette branche, le diagramme met en évidence des problèmes physiques et structurels :

Infrastructures vieillissantes

Absence de haute disponibilité

Risques de pannes accrus

Performances limitées

Ces éléments rappellent que l’infrastructure repose sur du matériel obsolète et non redondé, entraînant des risques de coupures et des limitations techniques.

Données & Sécurité

Cette branche identifie les risques liés à la protection des données :

Absence de stratégie de sauvegarde

Risque de perte totale en cas de sinistre

Données non redondées

Absence de segmentation réseau

Ces faiblesses exposent l’entreprise à des pertes majeures et compromettent la continuité d’activité.

Organisation & Gestion

Ici, l’analyse cible les lacunes dans le pilotage stratégique :

Dépendance au cloud public

Absence de vision long terme

Pas de suivi des déploiements et infrastructure non scalable

Ces problèmes montrent un manque de projection dans la croissance future de l’entreprise.

Méthodes & Processus

Cette catégorie regroupe les problèmes liés aux manières de travailler :

Absence d’automatisation des VMs

Procédures non documentées

Délai de mise en production étendu et absence de standardisation

Ces éléments contribuent à un fonctionnement artisanal, lent et source d’erreurs.

Ressources humaines

Cette section concerne les compétences et la disponibilité des équipes :

Risques d’erreurs humaines

Manque de formation du personnel

Charge de travail élevée et manque d’expertise virtualisation

Ces éléments entravent la maintenance et l’évolution cohérente du système d'information.

Logiciels & Systèmes

Cette dernière branche regroupe les lacunes techniques :

Absence d’outils d’orchestration et de Templates normalisées.

Absence de monitoring.

Retards dans les mises à jour logiciels

Ces manquements empêchent l’automatisation, la supervision et la stabilité de l’infrastructure.

C. Diagramme de la bête à cornes

Issu des méthodes de conception centrées sur le besoin, ce diagramme permet de représenter, de manière simple et visuelle, l’intention fondamentale du système, en répondant à trois questions essentielles : À qui le système rend-il service ? Sur quoi agit-il ? Et dans quel but existe-t-il ?

Dans ce projet, ce diagramme a permis d’identifier clairement les attentes de NovaTechSolutions en termes de fiabilité, d’automatisation, de rapidité de déploiement et de sécurisation des services.

Elle constitue donc une étape fondamentale pour aligner la solution technique proposée par NebTech avec les enjeux stratégiques et opérationnels du client.

Dans le cadre de ce projet, la bête à cornes a permis de clarifier et de formaliser l’intention du futur cloud privé.

Elle met en évidence :

Le bénéficiaire principal : NovaTechSolutions, qui s’appuie sur NebTech pour moderniser et automatiser son infrastructure.

L’objet d’action du système : une infrastructure interne vieillissante, difficile à maintenir, non automatisée et dépourvue de mécanismes avancés de supervision.

Les moyens d’action : les technologies d'automatisation telles que Terraform, Ansible, Jenkins, associées à un cluster Proxmox et à un stockage distribué Ceph.

Le but final : mettre en place un cloud privé hautement disponible, scalable, automatisé et capable d’héberger les services internes tout en réduisant la dépendance à des solutions externes.

Figure 13 Diagramme Bête à cornes

D. Diagramme pieuvre

Ce diagramme de la pieuvre, issu de l’analyse fonctionnelle, va servir à définir clairement les frontières fonctionnelles du système, les acteurs externes, et le rôle que joue chacun dans le fonctionnement global.

Figure 14 Diagramme de la pieuvre

Au centre, le système étudié représente le Cloud Privé NovaTechSolutions, qui regroupe l’ensemble des briques d’automatisation et d’infrastructure nécessaires au déploiement et à la gestion des environnements virtualisés.

E. Acteurs externes

Administrateur Systèmes & Réseaux

Il constitue l’utilisateur principal du système qui interagit directement avec le dashboard pour déployer des machines virtuelles, gérer l’infrastructure et superviser l’ensemble des services. C’est lui qui pilote la plupart des actions via l’automatisation.

Terraform

C’est cette solution qui reçoit les paramètres envoyés depuis le dashboard et qui exécute les actions d’infrastructure nécessaires : création, mise à jour ou suppression des machines virtuelles.
Il constitue le lien direct entre la demande utilisateur et Proxmox.

Ansible

Une fois les VMs déployées, Ansible prend le relais pour la configuration automatique (ajout de rôles, durcissement, installation de dépendances et automatisation des tâches de maintenance).

Cluster Proxmox

Il est composé de trois nœuds, il est l’environnement d’exécution du cloud privé. Il fournit la haute disponibilité, la gestion de ressources (CPU/RAM/stockage) et est l’API utilisée par Terraform pour le déploiement.

F. Acteurs internes

Ils bénéficient du résultat final : les services et applications hébergés sur le cloud. Ils sont des consommateurs directs de l’infrastructure.

Jenkins / CI-CD

Il assure l’automatisation avancée des pipelines, la cohérence des déploiements, la remontée d’état et la centralisation de l’historique d’exécution.

Réseau interne de l’entreprise

Il fournit la connectivité et assure le transport de tous les flux entre les différents acteurs du système : API, supervision, interfaces graphiques, SSH.

Firewall & Sécurité

Cet acteur est indispensable pour garantir l’intégrité et la confidentialité des échanges car il protège l'infrastructure en filtrant les flux et en limitant l’exposition des services essentiels.

Supervision & Logs (Syslog / Graylog / Dashboard Flask/API)

Ils collectent les métriques de performances (CPU, RAM, IO, réseaux), les journaux d’activité, les alertes systèmes et assurent la détection précoce d’événements anormaux et permettent un suivi fin de l’infrastructure.

Matériel physique (Cluster Proxmox)

Cet acteur représente les ressources matérielles supportant Proxmox : CPU, RAM, stockage, réseau.
C’est lui qui garantit la disponibilité et les performances du cloud.

Système de sauvegarde

Il assure la protection des données et permet la restauration en cas d’incident. C’est une brique essentielle pour la continuité d’activité (PRA/PCA).

Ce diagramme va servir de base à la rédaction du Cahier des Charges Fonctionnel et à la préparation du diagramme de flux qui en découlera.

G. Objectifs fonctionnels

Les objectifs fonctionnels définissent ce que le Cloud Privé doit savoir faire du point de vue du client, indépendamment des solutions techniques utilisées. Ils décrivent les services rendus par l’infrastructure et les fonctionnalités attendues par les utilisateurs finaux (administrateurs).

Dans le cadre du projet de Cloud Privé pour NovaTechSolutions, les objectifs fonctionnels ont été définis afin de répondre aux problématiques identifiées : besoin d’automatisation, rapidité de déploiement, réduction des erreurs humaines, disponibilité élevée et sécurisation des ressources.

Ces objectifs constituent le fil conducteur du développement du Cloud Privé et garantissent que la solution finale réponde pleinement aux besoins opérationnels et stratégiques de l’entreprise.

Figure 15 Objectifs fonctionnels

H. Carte Radar (Analyse visuelle)

Pour évaluer l’apport réel du projet et mesurer l’écart entre la situation actuelle de NovaTechSolutions et la solution finale proposée par NebTech, une analyse visuelle sous forme de carte radar a été réalisée.

Ce diagramme permet de comparer plusieurs critères essentiels d’un cloud moderne — automatisation, disponibilité, sécurité, rapidité de déploiement, scalabilité, standardisation et maintenabilité — selon différents niveaux de maturité.

Respectivement, la situation actuelle de l’infrastructure de NovaTechSolutions, un scénario intermédiaire (correspondant à une modernisation partielle) et la situation finale, obtenue après la mise en place du cloud privé NebTech. L’objectif idéal, servant de référence

La carte radar permet ainsi d’identifier immédiatement les axes où les améliorations sont les plus significatives, notamment en matière d’automatisation, de standardisation et de déploiement rapide.

Ce visuel met clairement en évidence la montée en maturité technologique apportée par le projet, ainsi que la cohérence globale des choix techniques retenus.

Figure 16 Carte Radar

I. Objectifs opérationnels et stratégiques

Afin de garantir la réussite du projet de cloud privé pour NovaTechSolutions, il est essentiel de définir clairement les objectifs à atteindre.

Ces objectifs se répartissent en deux catégories complémentaires :

Les objectifs opérationnels, qui concernent le fonctionnement quotidien de l’infrastructure, sa performance, sa sécurité et son automatisation.

Les objectifs stratégiques, qui s’inscrivent dans une vision long terme et définissent la manière dont le cloud privé contribuera au développement, à la modernisation et à la compétitivité de l’entreprise.

Le tableau ci-dessous synthétise ces objectifs, afin d’offrir une vision claire des enjeux du projet et d’aligner la solution technique avec les attentes réelles de NovaTechSolutions.

I.1 Objectifs opérationnels

Concrètement, les objectifs opérationnels et stratégiques n’agissent pas au même niveau, mais ils sont étroitement liés et complémentaires.

Les objectifs opérationnels concernent le fonctionnement quotidien du cloud privé, répondent à la question “Comment garantir une infrastructure fiable, performante et sécurisée au jour le jour ?” et portent sur :

-	La disponibilité des services.

-	La performance du cluster Proxmox et du stockage Ceph.

-	L’automatisation des déploiements.

-	La sécurité opérationnelle (pare-feu, accès, backups).

-	La rapidité de mise en production des VMs.

-	La réduction des erreurs humaines via Terraform et Ansible.

Ils ont donc une portée court terme et tangible, car ils influencent directement l’activité quotidienne de NovaTechSolutions.

Figure 17 Diagramme des objectifs techniques

Figure 18 Comparatif de déploiement Cloud

Figure 19 Types de Clouds privés

I.2 Objectifs stratégiques

Ce projet de Cloud privé concerne la capacité du système à évoluer avec l’entreprise (scalabilité), la pérennité des données et des services, la maîtrise des coûts informatiques, la réduction de la dépendance au cloud public, l’amélioration de l’image de marque grâce à une infrastructure fiable ainsi que la montée en compétences du personnel. Ces objectifs ont une portée macro, car ils influencent la stratégie IT sur plusieurs années.

Figure 20 Objectifs opérationnels

Figure 21 Objectifs stratégiques

Gestion du projet

Gestion du projet

V.1 Objectif du projet

L’objectif principal du projet est de concevoir, déployer et automatiser un cloud privé complet pour NovaTechSolutions, afin de remplacer une infrastructure vieillissante, non résiliente et entièrement manuelle.

Ce cloud privé devra permettre :

La création automatique de machines virtuelles via un dashboard simplifié (Flask + Terraform).

Une infrastructure hautement disponible, basée sur un cluster Proxmox à 3 nœuds, avec stockage distribué Ceph.

Une réduction drastique des erreurs humaines grâce à l’usage de l’Infrastructure as Code (IaC).

Un environnement évolutif, capable d’accompagner la croissance de NovaTechSolutions.

Une meilleure sécurité, via une segmentation réseau et un firewall OPNSense renforcé.

La standardisation des déploiements grâce à des Template Windows/Linux préconfigurés.

Une supervision simplifiée, permettant de monitorer l’état des services et du cluster.

En résumé, le projet vise à transformer une infrastructure traditionnelle en un cloud privé moderne, automatisé, sécurisé et souverain.

V.2 Périmètre et hors périmètre

Ce tableau permet d’établir un cadre précis, d’éviter les ambiguïtés, et de garantir une compréhension commune entre le porteur du projet, l’entreprise et les parties prenantes.

Figure 22 Tableau Périmètre - Hors Périmètre

A. Le projet couvre

Infrastructure matérielle

Mise en place d’un cluster Proxmox VE 9.1 à 3 nœuds.

Déploiement d’un stockage distribué Ceph (MON / MGR / OSD).

Installation d’un Proxmox Backup Server (PBS).

Installation du Proxmox Datacenter Manager (PDM) pour superviser le cluster.

Intégration d’une baie de brassage, d’un onduleur (UPS) et d’une PDU.

Architecture réseau

Mise en place d’un OPNSense principal + un OPNSense secondaire (redondance).

Création des VLANs :

VLAN10 : Management & Cluster Proxmox

VLAN20 : Réseau CEPH (OSD, MON, MGR)

VLAN30 : Automatisation & Services Internes

VLAN40 : VPN Wireguard et administration distante

VLAN50 : Production

Infrastructure logicielle

Mise en place d’un dashboard Flask pour le déploiement automatisé.

Génération automatique des fichiers dashboard.auto.tfvars.

Mise en place du pipeline Terraform → Ansible → Jenkins.

Création de templates cloud-init Windows et Linux.

Déploiement des serveurs internes :

Terraform, Ansible Jenkins et Docker / Flask

Automatisation & IaC

Déploiement entièrement automatisé des VMs.

Logging des déploiements dans le dashboard.

Configuration automatique (cloud-init / Ansible).

Pipeline CI/CD infrastructure.

Documentation & sécurité

Rédaction des procédures.

Diagrammes d’architecture.

Gestion des sauvegardes via PBS (règle 3-2-1).

B. Le projet ne couvre pas

La gestion du domaine Active Directory et des postes utilisateurs initiaux.

Organisation des tâches

La gestion des tâches a été structurée de manière rigoureuse afin de garantir une exécution fluide et contrôlée.

Chaque tâche a été définie avec une durée estimée, une date de début et de fin, un responsable, des dépendances avec les tâches précédentes et des livrables clairement identifiés.

Cette granularité permet de s’assurer que le projet avance de manière séquentielle, en validant chaque étape avant d’entamer la suivante.

Afin d’améliorer le pilotage du projet, chaque lot a également été traité comme un mini-cycle de travail, fonctionnant comme un “sprint technique” interne. Grâce à cette approche, la gestion du projet est restée fluide, tout en conservant la rigueur et la prévisibilité du modèle séquentiel.

Figure 23 Structure WBS

V.3 Méthodologie retenue : approche en cascade

Pour la conduite de ce projet, j’ai retenu la méthode en cascade, un modèle séquentiel simple, structuré et particulièrement adapté aux projets dont les besoins sont clairement définis, stables et orientés qualité.
Son fonctionnement repose sur une progression par phases successives, chacune produisant un livrable validé avant de passer à l’étape suivante.

Ce modèle présente plusieurs avantages pour un projet d’infrastructure comme celui-ci :

Une vision claire et anticipée de l’ensemble des étapes.

Des responsabilités bien identifiées pour chaque phase.

Un déroulement rigoureux permettant d’assurer la qualité technique avant d’avancer.

De plus, la validation entre chaque phase garantit que les prérequis sont satisfaits et en cas de problème majeur, un retour à l’étape précédente est possible.

Chaque phase est découpée en sous-tâches clairement identifiées et associées à une durée estimée, à une date de début (Start), à une date de fin prévisionnelle (ETA) et à un responsable NebTech.

Ce planning met en évidence la logique séquentielle du modèle en cascade, les dépendances entre les étapes et de garantir à NovaTechSolutions une vision précise de l’avancement et des livrables attendus.

A. Diagramme RACI

Le diagramme RACI présenté ci-dessous a pour objectif de clarifier qui fait quoi, d’assurer une communication fluide entre les équipes, d’éviter les zones d’ombre, les doublons ou les responsabilités non assumées et de garantir une exécution cohérente et maîtrisée du projet.

Ainsi, il permet d’assurer que chaque compétence est sollicitée au bon moment, et que chaque livrable dispose d’un responsable clairement identifié.

Figure 24 Diagramme RACI

V.4 Analyse des risques

Une analyse détaillée des risques a été réalisée afin d’anticiper les menaces pouvant impacter la réussite technique, opérationnelle et stratégique du déploiement.
Cette étude permet d’identifier les événements susceptibles d’altérer la disponibilité, la sécurité ou la performance de l’infrastructure, ainsi que les risques liés à la gouvernance, aux ressources humaines et au budget.

Cette approche permet de prioriser les actions préventives et correctives, d’assurer une meilleure maîtrise des aléas, et de garantir une mise en production fiable et pérenne de l’infrastructure cloud.

Le tableau ci-dessous présente la synthèse des risques, accompagnée de leur niveau de criticité (vert, jaune, orange, rouge) et des mesures proposées pour réduire leur occurrence ou leurs effets.

Figure 25 Carte des risques

Figure 26 Tableau - Carte des risques

Afin d’évaluer leur criticité, chaque risque a été classé selon deux critères, la probabilité d’occurrence ainsi que l’impact potentiel sur le projet et sur l’entreprise.

A. Tableau d’évaluation des risques

Figure 27 Tableau - Evaluation des risques

Les risques ont été classés selon leur nature, leur impact potentiel et leur probabilité d’occurrence, permettant ainsi de prioriser les actions de prévention et de mitigation.

Figure 28 Surface de risques du projet

B. Risques opérationnels

Les risques opérationnels concernent directement l’exploitation technique de l’infrastructure et des outils mis en œuvre.

Le principal risque identifié est une panne d’infrastructure Proxmox, Ceph ou OPNSense, pouvant entraîner une indisponibilité des services. Ce risque est considéré comme critique en raison de son impact élevé, bien que sa probabilité soit modérée grâce à la mise en place d’une architecture redondante.

Des risques liés à la sécurité sont également pris en compte, notamment les erreurs de configuration réseau ou firewall. Ces risques sont atténués par la segmentation réseau, l’utilisation du chiffrement HTTPS et l’application de bonnes pratiques de sécurité.

L’automatisation, bien que source de gains importants, introduit des risques spécifiques, tels qu’une mauvaise gestion des templates ou une dépendance aux outils comme Terraform et Ceph. Ces risques restent modérés et sont maîtrisés par la standardisation des configurations et la documentation.

Enfin, des risques mineurs, comme une lenteur temporaire du dashboard ou une indisponibilité passagère de l’interface d’administration, ont été identifiés. Leur impact est faible car ils n’affectent pas directement la disponibilité de l’infrastructure, celle-ci restant administrable par les outils natifs.

C. Risques stratégiques

Les risques stratégiques concernent l’évolution du projet dans le temps et son adéquation avec les besoins de l’entreprise.

Parmi ceux-ci, une mauvaise anticipation des besoins futurs ou une absence de compétences internes peut limiter la capacité de l’entreprise à faire évoluer l’infrastructure. Ces risques sont pris en compte par la mise en place d’une architecture évolutive et par le transfert de compétences via la documentation et la formation.

La dépendance à un prestataire ou à des outils spécifiques constitue également un risque stratégique. Ce risque est toutefois atténué par le choix de solutions open source largement adoptées, réduisant l’effet de verrouillage technologique.

Enfin, des risques financiers et d’image, tels qu’un dépassement de budget ou un impact sur la réputation en cas d’incident majeur, ont été identifiés comme critiques. Ils justifient la mise en place d’une gouvernance projet rigoureuse et d’une stratégie de supervision proactive.

D. Spécifications techniques

Pour répondre à ces exigences, j’ai combiné plusieurs technologies complémentaires : Proxmox VE pour la virtualisation, Terraform pour le provisioning automatisé, Ansible pour la configuration, et Jenkins pour l’orchestration et le suivi des pipelines.

Afin de rendre l’utilisation de ces outils fluide et unifiée, j’ai développé un dashboard web sur mesure en Python/Flask, qui offre une interface unique permettant de piloter l’ensemble des opérations.

Les spécificités techniques présentées dans la suite du rapport détaillent la manière dont ces différentes briques interagissent, les choix architecturaux effectués, ainsi que les mécanismes d’automatisation mis en place pour garantir un cloud privé fiable, personnalisable et hautement accessible.

Exigences techniques

Cluster Proxmox VE 9.1 sur 3 nœuds (bare-métal)

Ceph cluster (MON/MGR/OSD)

Templates cloud-init pour VM

Terraform ≥1.5, Ansible ≥2.12, Jenkins LTS

Docker CE pour les applications conteneurisées

Fonctionnalités attendues

Création automatique de VMs via Terraform

Déploiement et configuration des services via Ansible

Pipeline Jenkins pour orchestrer Terraform → Ansible → Déploiement Docker

Templates stockés sur pool Ceph RBD partagé

Stockage Ceph répliqué pour HA

Indicateurs de succès

Tolérance à la panne d’un nœud Proxmox

Tolérance à la panne d’un OSD Ceph

Provisioning d’une VM en < 2 min

Pipeline CI/CD opérationnel

Création d’un dashboard

Création du squelette Flask sur Python

Appels API vers Proxmox, Terraform, Ansible et Jenkins

Routes pour l’interface utilisateur

Gestion des retours (logs, statuts, résultats d’exécution)

Sécurisation des accès (MFA)

V.5 Planification du projet

A. Diagramme de Gantt

Afin d’organiser efficacement les différentes phases du projet, un diagramme de Gantt a été élaboré. Cet outil permet de visualiser l’enchaînement des tâches, leurs durées respectives, les dépendances entre elles ainsi que les jalons clés. Chaque phase du projet (analyse, conception, installation, développement, tests, validation, documentation) est clairement positionnée dans le calendrier, ce qui garantit une exécution fluide et structurée.

Ce diagramme constitue ainsi un outil de pilotage indispensable, facilitant la communication avec les parties prenantes et permettant d’assurer un suivi rigoureux jusqu’à la livraison finale.

Figure 29 Diagramme de GANTT

Cahier des charges

Cahier des charges

Le présent Cahier des charges a pour objectif de définir précisément les contraintes, exigences et critères de réussite nécessaires à la mise en place d’un Cloud Privé haute disponibilité pour la société NovaTechSolutions.

Figure 30 Diagramme des contraintes

VI.1 Cahier Des Charges Fonctionnel (CDCF)

Les besoins fonctionnels dérivent directement de l’analyse fonctionnelle (Bête à Cornes, Pieuvre, QQQOQCCP) et doivent répondre aux problématiques initialement identifiées.

A. Besoins fonctionnels

Automatisation & Déploiement

Permettre le déploiement automatisé d’une machine virtuelle à partir d’un Template choisi par l’utilisateur.

Autoriser le déploiement d’environnements complets (groupes de VMs prédéfinis) en une seule action.

Générer automatiquement les configurations nécessaires (VM ID, ressources, datastore, réseau) sans intervention avancée de l’utilisateur.

Assurer la standardisation des machines déployées, grâce à des Template homogènes validés par l’entreprise.

Supervision & Visualisation

Fournir une interface de supervision du cluster Proxmox, incluant :

Charge CPU, RAM, stockage

Disponibilité des nœuds

Nombre de Vms actives

Afficher en temps réel les logs systèmes provenant des nœuds du cluster Proxmox et des postes utilisateurs.

Lister l’ensemble des machines virtuelles et leurs informations essentielles (ID, nom, état, nœud d’hébergement).

Actions sur les Vms

Permettre les actions simples d’administration directement depuis le Dashboard :

Démarrage / Redémarrage

Arrêt

Reset

Migration

Suppression sécurisée d’une VM

Maintenance & Automatisation complémentaire

Mettre à disposition un module d’exécution de scripts Ansible (tests de connectivité, mises à jour, routines de maintenance).

Centraliser l’accès aux outils d’administration externes.

B. Contraintes fonctionnelles

Les contraintes fonctionnelles définissent les limites, règles et obligations à respecter pour que la solution soit utilisable, intuitive et conforme au besoin initial.

Ergonomie & Accessibilité

L’interface doit être simple et intuitive, utilisable par un technicien systèmes et réseaux sans compétences avancées en Proxmox ou Terraform.

Le Dashboard doit être consultable via un navigateur web standard, notamment :

Google Chrome

Mozilla Firefox

Microsoft Edge

Sécurité & Contrôle

Un système d’authentification renforcé doit être mis en place, incluant un accès sécurisé par mot de passe et un second facteur (2FA - QR Code)

Les logs du système doivent être accessibles, mais ne doivent pas permettre de modifier la configuration sous-jacente.

La suppression d’une VM doit faire l’objet d’une confirmation explicite, afin d’éviter toute erreur de manipulation de l’administrateur.

Fiabilité & Automatisation

Le déploiement d’une VM doit être entièrement automatisé, sans recours à une intervention manuelle sur Proxmox.

La solution doit offrir une expérience utilisateur fluide, même lors de phases de déploiement prolongées.

Intégration

Le dashboard doit s’intégrer avec les services existants (Proxmox, Jenkins, Ansible) sans nécessiter de modification majeure de l’infrastructure actuelle.

C. Diagramme SysML Requirements

Ce diagramme précise les exigences fonctionnelles et techniques, leur hiérarchie, et les relations de dépendance entre elles.
Il permet de structurer le projet selon une approche systémique et d’assurer la traçabilité.

Figure 31 Diagramme SysML

D. Contraintes techniques, fonctionnelles, financières

D.1 Introduction au diagramme des contraintes

Dans le cadre de ce projet et afin de garantir un niveau de qualité conforme aux standards professionnels, j’ai porté une attention particulière aux contraintes liées à l’environnement, aux technologies employées et aux exigences fonctionnelles exprimées.

Bien que le budget alloué soit restreint, une licence Proxmox Enterprise a été intégrée à la solution afin d’assurer l’accès à des dépôts stables, à des correctifs certifiés ainsi qu’à un support technique renforcé.

Ce choix vise à garantir la stabilité de l’hyperviseur, cœur de l’infrastructure, tout en sécurisant les opérations de production. Pour l’ensemble des autres composants, j’ai privilégié des technologies open source reconnues telles que Terraform, Ansible, Jenkins, Ceph et Flask. Ces solutions, robustes et éprouvées, répondent pleinement aux besoins d’automatisation et d’orchestration sans entraîner de surcoûts logiciels.

La conception a également été pensée pour optimiser au maximum les ressources matérielles existantes. L’ensemble des serveurs, équipements réseau et capacités de stockage déjà disponibles ont été réutilisés afin de limiter les investissements additionnels tout en garantissant la performance attendue. Le diagramme présenté ci-après offre une vue synthétique et structurée de l’ensemble des contraintes techniques, fonctionnelles et financières qui ont orienté les choix d’architecture et de déploiement.

D.2 Contraintes techniques

Compatibilité des solutions : Terraform, Ansible, Jenkins et Proxmox doivent pouvoir communiquer entre eux via API.

Ressources matérielles limitées : le projet repose sur une infrastructure Proxmox, ce qui exclut des solutions lourdes comme OpenStack.

VLANs et accès réseau : chaque composant (Proxmox, Ceph, Jenkins, Dashboard Flask…) doit être accessible sur des VLANs distincts tout en respectant les règles de filtrage.

Capacité de stockages : la mise en place d’un cluster Ceph (disponibilité de disques et de serveurs adaptés).

Sécurité et isolation : nécessité de séparer les environnements (Production, Déploiement, Stockage) et d’assurer une isolation maximale.

Automatisation fiable : les playbooks Ansible, scripts Terraform et pipelines Jenkins doivent être rédigés de manière robuste et idempotent.

D.3 Contraintes fonctionnelles

Interface centralisée : l’utilisateur final doit pouvoir tout piloter depuis un seul dashboard.

Simplicité d’utilisation : le but est de masquer la complexité des outils sous-jacents et de rendre les actions accessibles même à un utilisateur non expert.

Réactivité et lisibilité : affichage clair de l’état des déploiements, logs lisibles, messages d’erreur explicites.

Templates standardisés : toutes les VM doivent partir d’images préconfigurées pour garantir l’homogénéité et réduire les erreurs.

D.4 Contraintes financières

Budget limité : le projet est mis en place avec un budget limité, tout en prenant en compte la licence entreprise de Proxmox.

Priorité aux solutions open source : Proxmox, Ceph, Terraform, Ansible, Jenkins et Flask sont retenus car stables et largement documentés.

Optimisation du matériel existant : Certains des serveurs, switches, disques et ressources réseau utilisés proviennent du matériel existant, ce qui permet de limiter le budget matériel.

En adoptant une approche mêlant solutions open source éprouvées, optimisation des ressources existantes et recours ciblé à une licence Proxmox Enterprise, la solution proposée répond de manière équilibrée aux exigences de stabilité, de performance et de maîtrise des coûts.

Ces éléments ont permis d’établir une base solide pour la conception du système, d’assurer la cohérence des outils utilisés et de garantir la pérennité de l’environnement. La section suivante présente donc l’architecture détaillée ainsi que les mécanismes techniques mis en œuvre pour répondre à ces objectifs.

D.5 Indicateurs de succès (KPI)

Figure 32 Radar KPI

Les indicateurs de succès permettent d’évaluer objectivement si la solution répond au besoin initial. Ils servent de base à la recette et à la validation finale du projet.

Performance & Automatisation

Temps de déploiement d’une VM ≤ 2 minutes après création depuis le dashboard.

Déploiement d’un groupe complet ≤ 5 minutes, selon le nombre de VMs.

Homogénéité garantie à 100 % entre les VMs déployées à partir du même Template.

Disponibilité & Supervision

Disponibilité du dashboard ≥ 99 % pendant les périodes prévues.

Actualisation des logs Proxmox ≤ 3 secondes.

Les logs des postes utilisateurs consultables à tout moment depuis le dashboard Graylog.

Prise en main complète par un administrateur en moins de 30 minutes, après une formation avancée.

VI.2 Cahier des Charges Technique (CDCT)

Contrairement au CDCF, centré sur les besoins utilisateurs, le CDCT s’intéresse exclusivement aux moyens techniques nécessaires pour atteindre ces objectifs.

A. Exigences et Contraintes Techniques

Les exigences techniques décrivent le comportement attendu du système, les technologies retenues et les contraintes imposées par l’environnement de NovaTechSolutions.

A.1 Infrastructure système

Cluster Proxmox

Le projet repose sur un cluster Proxmox VE composé de 3 nœuds physiques : pve01, pve02, pve03.

La solution doit être compatible avec Proxmox VE ≥ 8.4.

Les VMs doivent être déployées dans le datastore vmstore afin d’assurer une homogénéité et une meilleure gestion.

La communication avec l’API Proxmox doit s’effectuer via HTTPS sur le port 8006.

Templates

Tous les déploiements doivent être effectués uniquement via des Templates normalisés : Linux, Windows, images spécialisées.

Les Templates doivent intégrer Cloud-Init pour automatiser la personnalisation des VM.

A.2 Automatisation Terraform

Exigences

Terraform doit être utilisé dans sa version ≥ 1.5.

Le provider Proxmox utilisé devra être bpg/Proxmox (v0.87.0).

Les déploiements Terraform doivent être effectués dans des environnements éphémères, stockés temporairement puis supprimés afin d’éviter toute pollution de configuration.

Ces fichiers doivent être générés à chaque déploiement :

main.tf / provider.tf / variables.tf / terraform.tfvars

Contraintes

Aucune configuration persistante ne doit rester sur le serveur près l’exécution.

Les erreurs Terraform doivent être capturées et remontées proprement dans l’interface.

A.3 Dashboard Web (Flask/Python)

Exigences techniques

Le service doit être développé avec Python ≥ 3.11 (Framework obligatoire : Flask).

Interface en HTML/CSS avec scripts JS pour la supervision Proxmox, les actions sur VMs, le monitoring en temps réel, l’affichage des logs, la gestion Ansible et la création de groupes complexes d’infrastructure.

Sécurité

Authentification obligatoire par identifiant + mot de passe.

Implémentation d’un second facteur d’authentification (2FA) avec PyOTP QR Code).

Aucune information critique (mot de passe Proxmox, tokens API) ne doit être accessible côté client.

Contrôle lors de la connexion via HTTPS et MTLS.

Contraintes

Le serveur Flask doit être configuré en mode sécurisé (HTTPS).

Les logs d’accès et d'erreurs doivent être stockés localement.

A.4 Intégration Ansible

Exigences

La plateforme doit pouvoir exécuter des playbooks de tests (ping.yml), des playbooks de maintenance (maj.yml) et des playbooks de déploiements logiciels.

L’exécution doit se faire via SSH depuis le dashboard.

Un retour en temps réel doit être affiché dans l’interface.

Contraintes

Timeout maximum : 300 secondes.

L’utilisateur ne doit pas pouvoir exécuter un playbook non approuvé par des tests en amont.

Le serveur Ansible doit être joignable depuis le dashboard, tout comme Jenkins.

A.5 Supervision et Journaux d’évènements

Exigences

Le dashboard doit pouvoir interroger chaque nœud Proxmox (CPU, RAM, Stockage, Disponibilité

, Nombre de VMs actives).

Les logs doivent être obtenus via la commande : journalctl -n 50 --no-pager.

Contraintes

Le rafraîchissement doit se faire toutes les 5 secondes pour le monitoring.

Les logs doivent être rafraîchis toutes les 3 secondes.

B. Etude comparative des solutions

B.1 Comparatif des hyperviseurs de type 1 (Proxmox, VMware, Hyper-V)

Une étude comparative a été menée entre VMware ESXi, Microsoft Hyper-V et Proxmox VE afin d’identifier la solution la plus adaptée aux besoins de NovaTechSolutions.

VMware ESXi constitue une référence du marché, reconnue pour sa maturité et son écosystème riche, mais implique des coûts de licences élevés et une forte dépendance éditeur.

Hyper-V offre des fonctionnalités avancées telles que la haute disponibilité, la reprise après sinistre et l’optimisation des coûts via la consolidation des serveurs, notamment grâce à son intégration avec Windows Server. Toutefois, cette solution reste fortement liée à l’environnement Microsoft.

Proxmox VE est une plateforme de virtualisation open source reposant sur Debian et combinant KVM pour les machines virtuelles et LXC pour les conteneurs, tout en intégrant nativement la haute disponibilité, le stockage logiciel et les capacités réseau. Cette approche garantit un haut niveau de flexibilité, de transparence technologique et de maîtrise des coûts.

Le choix de Proxmox VE s’est donc imposé pour plusieurs raisons :

Cohérence avec l’infrastructure existante, déjà équipée d’un nœud Proxmox.

Réduction des coûts de licences.

Indépendance vis-à-vis d’un éditeur propriétaire.

Richesse fonctionnelle compatible avec une architecture cloud privée.

Ce choix répond ainsi à une logique à la fois technique, économique et stratégique, tout en respectant la volonté du client de capitaliser sur son socle technologique actuel.

Figure 33 Comparatif des Hyperviseurs Type 1

B.2 Comparatif des solutions de pare-feu (PFSense, OPNsense, Fortigate, Cisco, Sophos)

Synthèse du comparatif et choix de la solution

Figure 34 Synthèse - Choix des solutions

L’étude des différentes solutions de pare-feu (PfSense, OPNsense, Fortinet, Cisco et Sophos) a permis d’identifier les outils capables de répondre aux besoins de sécurité d’une entreprise tout en respectant des contraintes budgétaires.

Les solutions open source comme PfSense et OPNsense sont reconnues pour leurs fonctionnalités avancées, leur sécurité robuste et leur grande flexibilité, ce qui explique leur adoption dans de nombreux environnements professionnels.
À l’inverse, les solutions propriétaires offrent souvent un support éditeur mais impliquent des coûts plus importants.

Après analyse, le choix s’est porté sur OPNSense, pourquoi ?

Plusieurs raisons justifient ce choix :

Alternative économique aux pare-feu commerciaux : OPNSense fournit des fonctionnalités de niveau entreprise sans coûts élevés de licence.

Flexibilité : la solution propose de nombreuses fonctionnalités personnalisables selon les besoins de l’entreprise.

Sécurité élevée : elle offre une protection robuste grâce à un contrôle précis du trafic et au support de VPN assurant la confidentialité des données.

Par ailleurs, OPNSense est considéré comme une plateforme puissante, flexible et sécurisée, capable de maintenir un réseau fiable et efficace pour des organisations de toutes tailles.

Enfin, ce choix s’inscrit également dans une logique de continuité technique : l’entreprise utilise déjà OPNSense et souhaite conserver cette solution. Maintenir un outil existant permet de limiter les coûts de migration, de réduire le temps de déploiement et de capitaliser sur les compétences internes déjà acquises.

Conclusion

Le choix de OPNSense constitue donc une réponse cohérente aux enjeux de l’entreprise. Cette solution offre un équilibre pertinent entre sécurité, performance, maîtrise des coûts et simplicité d’intégration, tout en garantissant la pérennité de l’infrastructure réseau.

C. Architecture cible

C.1 Choix d’architecture

L’architecture repose sur les éléments suivants :

Cluster Proxmox (3 nœuds)

Serveur Flask (Dashboard + Terraform + Rôle d’orchestrateur)

Serveur Ansible

Templates centralisés

Réseau interne NovaTechSolutions

C.2 Schéma logique

Figure 35 Diagramme d'architecture

Standards et normes utilisés

Normes de virtualisation

Proxmox VE (KVM / QEMU) & Cloud-Init ISO 2.4+

Normes de sécurité

MFA (2FA obligatoire), accès HTTPS/SSH et journalisation centralisée

Normes DevOps

Terraform, Ansible et Modèle Infrastructure-as-Code (IaC)

VI.3 Enveloppe budgétaire

Le projet s'appuie sur du matériel existant, ce qui réduit fortement les coûts.

A. Coûts directs estimés

Figure 36 Tableau coûts directs estimés

Figure 37 Diagramme TCO / ROI

Lien entre accompagnement Bpifrance et analyse financière

L’accompagnement de Bpifrance s’intègre dans la réflexion globale sur le coût total de possession (TCO) et le retour sur investissement (ROI) du projet.
En apportant un cadre méthodologique et une aide à la priorisation des actions, il permet de limiter les dépenses non essentielles, de sécuriser les investissements techniques et d’optimiser les coûts d’exploitation à moyen et long terme.
Cette démarche contribue à améliorer la rentabilité globale du projet tout en renforçant la résilience et la sécurité de l’infrastructure.

B. Délais (prévision)

Le tableau ci-dessous présente la décomposition du projet en phases structurées, chacune associée à une durée estimée et à une description précise des travaux réalisés.

Cette organisation facilite le suivi de l’avancement, la maîtrise des risques, la répartition du travail et la justification du planning.

Ces durées sont issues d’une estimation réaliste basée sur l’expérience acquise lors de la mise en œuvre du projet. Elles tiennent compte des temps de développement, d’intégration, de tests fonctionnels et techniques, ainsi que de la production des livrables nécessaires (documentation, supports de soutenance).

Figure 38 Délais Prévisionnels du projet

C. Introduction du devis Cloud Privé pour NovaTechSolutions

Le devis sera établi par NebTech et détaillera les coûts associés à la conception, au déploiement et à la mise en production.

Ce devis couvrira l’ensemble des éléments nécessaires à la réalisation du projet :

Matériel (serveurs, stockage, réseau, équipements de sécurité)

Logiciels et composants open-source intégrés

Conception et déploiement de l’architecture Proxmox + Ceph

Mise en place des outils d’automatisation (Terraform, Ansible, Jenkins)

Développement du dashboard Flask pour le déploiement des VMs

Configuration réseau, VLAN, sécurité et VPN

Sauvegarde et plan de reprise via Proxmox Backup Server

Documentation technique complète et formation utilisateur

L’objectif de ce devis est d’offrir à NovaTechSolutions une vision financière claire, transparente et détaillée de l’ensemble du projet, tout en garantissant un excellent rapport qualité/prix grâce au choix de technologies robustes et open source. Il servira également de référence tout au long du projet, permettant à NovaTechSolutions de valider les coûts, d’anticiper les dépenses futures et d’assurer une maîtrise budgétaire complète.

Figure 39 Budget – Prévision

Afin d’estimer l’investissement global nécessaire à la mise en place du cloud privé de NovaTechSolutions, un budget prévisionnel a été établi.

Ce budget prend en compte l’ensemble des dépenses matérielles, logicielles et humaines nécessaires au déploiement de l’infrastructure :

Achat des serveurs, stockage Ceph et éléments réseau,

Acquisition des licences Proxmox et du matériel associé,

Mise en place physique (baie, PDU, onduleur, câblage),

Temps de conception, de configuration et de validation,

Coûts éventuels de formation et documentation.

L’objectif est de fournir une vision claire du coût total du projet, tout en assurant transparence et justification de chaque poste.
Ce budget permet également d’anticiper la scalabilité future du cloud privé et d’éviter les dépenses imprévues.

Figure 40 Détails du Budget prévisionnel

D. Budget main d'œuvre

Chef de projet : 12 jours × 450 € = 5 400 €

Ingénieur système (IaC) : 25 jours × 380 € = 9 500 €

Technicien réseaux : 10 jours × 320 € = 3 200 €

Rédaction & documentation : 5 jours × 280 € = 1 400 €

Total main d’œuvre = 19 500 €

Figure 41 Tableau rémunération main-d’œuvre prévisionnelle.

Le budget détaillé est établi dans le chapitre VIII.

Phase de conception

Phase de conception

VII.1 Conception Fonctionnelle

Parcours utilisateur

Objectif : illustrer les principales interactions entre l’utilisateur et le système.

A. Diagramme de séquence « Déploiement VM » (Workflow UML)

Le diagramme suivant représente le processus complet de déploiement automatisé d’une machine virtuelle au sein du cloud privé NovaTechSolutions.
Il s’agit d’un diagramme de séquence UML, utilisé pour visualiser l’enchaînement des actions déclenchées par l’utilisateur, les interactions entre les différentes briques techniques (Flask, Terraform, API Proxmox, Ceph, Cloud-Init, Jenkins, Ansible), les points de contrôle, de validation et de gestion des erreurs. Le cheminement exact permettant la création d'une VM sans intervention manuelle.

Figure 42 Diagramme Workflow UML1.

L’utilisateur se connecte au dashboard depuis un navigateur.

Il s’identifie avec des ID transmis par l’administrateur + MFA (QR Code/Mtls).

Depuis le dashboard, il sélection un Template et les caractéristiques souhaitées (RAM, CPU, Storage, ID, nœud).

La VM se déploiement et l’utilisateur peut consulter l’état du déploiement via le monitoring.

Plusieurs Actions sont disponibles (Start, Reset, Stop, Migration, Suppression, visualisation des logs, exécution de playbooks Ansible via un terminal ou depuis Jenkins).

VII.2 Conception Technique

A. Schéma d’architecture

Figure 43 Schéma d'architecture

B. Analyse du schéma d’architecture

VLAN10 – Management & Cluster Proxmox

Trafic d’administration :

API Proxmox

Cœur du cluster

Accès administrateur

VLAN20 – Réseau Ceph (OSD, MON, MGR

Assure la haute disponibilité du stockage :

Synchronisation des blocs CEPH

Réplication OSD ↔ OSD ↔ OSD

Trafic MON ↔ OSD

VLAN30 – Automatisation & Services internes

Permet de centraliser tous les outils d’orchestration :

Terraform (exécution et drivers)

Ansible (post-configuration automatisée)

Jenkins (pipelines CI/CD)

Dashboard Flask (interface administrateur)

ADCS / Docker / Graylog / Wazuh

VLAN40 – VPN / Wireguard

Permet l’accès sécurisé à distance :

Administrateurs distants

Consoles internes

API privées

VLAN50 – Production (VM Déployées)

Espace réseau dans lequel Terraform déploie automatiquement :

Serveurs web

Applications métiers

Environnements de test

Machines Linux / Windows

Services internes

Isolation stricte vis-à-vis du réseau d’administration et du stockage.

C. Schéma d’Architecture Réseau Final

Architecture physique / bare métal – Cluster Proxmox / Ceph NovaTechSolutions

Figure 44 Schéma d'architecture réseau

Figure 45 Représentation matériel sur site

D. Plan d’adressage IP

Figure 46 Plan d’adressage IP

VII.3 Vision d’exploitation et de production

A. Diagramme d’Architecture Technique Global

Le diagramme d’architecture technique globale présenté ci-après offre une vision synthétique et structurée de l’ensemble des composants du cloud privé NovaTechSolutions et de leurs interactions.
Il permet au lecteur de comprendre rapidement la logique d’ensemble du système, depuis l’interface utilisateur jusqu’à l’exécution automatique du déploiement.

Ce schéma met en évidence :

Le Dashboard Flask, point d’entrée pour l’utilisateur final, permettant les actions de déploiement, consultation et administration.

Terraform, moteur d’infrastructure as code chargé de la création automatique des machines virtuelles sur Proxmox.

Ansible, utilisé pour la configuration post-déploiement des VM (durcissement, rôles, services).

Le cluster Proxmox, plateforme de virtualisation haute disponibilité assurant l’exécution des environnements.

Le stockage distribué Ceph, garantissant la résilience, la réplication et la performance des données.

Les outils de supervision et de journalisation, dont Graylog, permettant la collecte centralisée des logs et le suivi de l’infrastructure.

Figure 47 Diagramme d'architecture technique global

Figure 48 Tableau d'architecture technique global

Figure 49 Récapitulatifs des rôles des outils

B. Stratégie de sécurité globale

La sécurité du système d’information repose sur une approche multicouche, combinant protection réseau, contrôle des accès et surveillance continue. Cette stratégie vise à réduire les risques tout en garantissant un environnement de travail fiable pour les utilisateurs.

B.1 Authentification forte (MFA, mTLS)

Dans le cadre du renforcement de la sécurité du système d’information, une authentification forte a été mise en place pour les accès sensibles.

L’accès à l’interface d’administration du pare-feu OPNSense ainsi qu’aux services critiques est restreint aux comptes autorisés. Des politiques de mots de passe robustes ont été appliquées, incluant une longueur minimale et des exigences de complexité.

Un mécanisme de double authentification (MFA) a été déployé pour les connexions à distance via le VPN. Cette mesure réduit significativement les risques liés au vol d’identifiants, puisqu’un second facteur de validation est nécessaire pour accéder au réseau interne.

Concernant les communications sécurisées, l’utilisation de certificats numériques permet de chiffrer les échanges et de garantir l’authenticité des services exposés.

Objectif : empêcher les accès non autorisés et protéger les ressources critiques de l’entreprise.

Figure 50 MFA / Mtls

B.2 Segmentation réseau

Dans le cadre du renforcement de la sécurité du système d’information, une segmentation réseau a été mise en œuvre à l’aide de VLANs. Cette approche permet d’isoler les différents environnements, de mieux contrôler les flux et de limiter la propagation d’une attaque.

L’infrastructure s’appuie sur le pare-feu OPNSense, qui assure le routage inter-VLAN ainsi que le filtrage des communications grâce à des règles de sécurité strictes.

L’organisation du réseau sur Proxmox est la suivante :

VLAN 10 – Cluster Proxmox (PBS, PDM)
Ce réseau est dédié à l’infrastructure de virtualisation. Il isole les hôtes et les services de gestion afin d’empêcher tout accès direct depuis les réseaux utilisateurs.

VLAN 20 – Réseau CEPH (OSD, MON, MGR)
Ce VLAN est réservé au stockage distribué. La séparation garantit des performances optimales tout en protégeant les données contre les accès non autorisés.

VLAN 30 – Automatisation & Services internes
Il regroupe les services nécessaires au fonctionnement interne (scripts, outils d’administration, services techniques). L’accès y est strictement contrôlé.

VLAN 40 – VPN (Wireguard)
Ce segment est destiné aux connexions distantes sécurisées. Les utilisateurs nomades accèdent au système d’information via ce réseau, avec des droits limités uniquement aux ressources nécessaires.

VLAN 50 – Production
Ce VLAN héberge les services métiers et les ressources utilisées quotidiennement par l’entreprise. Il constitue une zone prioritaire en matière de sécurité.

Des règles de filtrage ont été configurées afin d’appliquer le principe du moindre privilège, seuls les flux indispensables entre les VLANs sont autorisés, tandis que toute communication non explicitement permise est bloquée par défaut.

Cette architecture présente plusieurs avantages :

Réduction de la surface d’attaque.

Meilleure isolation des services critiques.

Amélioration des performances réseau.

Administration plus claire et structurée.

Ainsi, en cas de compromission d’un segment, cette organisation empêche un attaquant de se déplacer latéralement dans le réseau, renforçant ainsi la posture globale de la sécurité.

Conclusion

La segmentation par VLAN constitue donc un élément central de l’architecture mise en place. Elle permet de concilier sécurité, performance et évolutivité, tout en s’adaptant aux besoins actuels et futurs de l’entreprise.

B.3 Journalisation et SOC

Dans le cadre du projet, une architecture de journalisation centralisée a été mise en place afin d’améliorer la visibilité, la traçabilité et la détection des incidents de sécurité.

Les postes Windows transmettent leurs événements via NXLog, tandis que les systèmes Linux utilisent RSyslog, un logiciel open source permettant de transférer les messages de journalisation sur un réseau IP. Les logs sont ensuite collectés et analysés afin de faciliter l’exploitation et le diagnostic.

Pour renforcer la capacité de détection des menaces, l’infrastructure intègre également Filebeat, un agent léger conçu pour collecter et transmettre les fichiers de logs vers une plateforme d’analyse. Ces journaux alimentent Wazuh, une plateforme de sécurité open source dédiée à la détection des intrusions, à la surveillance des systèmes et à l’analyse des journaux.

Figure 51 Centralisation des logs

Cette approche permet :

Une corrélation des événements de sécurité.

Une détection proactive des comportements anormaux.

Une réduction du temps de réaction en cas d’incident et une meilleure conformité aux bonnes pratiques de cyber sécurité.

L’ensemble constitue une base technique proche des principes d’un SOC (Security Operations Center), adaptée à une infrastructure de cloud privé.

Figure 52 Graylog - Logs pve01

B.4 Gestion des vulnérabilités

Afin de garantir la protection des données et la continuité de service, une stratégie de sauvegarde conforme aux bonnes pratiques du secteur a été définie. Elle s’appuie notamment sur le principe 3-2-1, reconnu comme une approche efficace pour limiter les risques de perte de données.

Figure 53 Stratégie de sauvegarde 3-2-1

Cette règle recommande de disposer d’au moins trois copies des données, stockées sur deux supports différents, dont une copie externalisée afin de se prémunir contre les sinistres majeurs (incendie, vol, catastrophe naturelle).

La stratégie mise en œuvre repose sur plusieurs niveaux de protection :

Sauvegarde sur le stockage de Proxmox Backup Server permettant une restauration rapide des machines virtuelles.

Stockage locale (Ceph), assurant une redondance native des données et une meilleure tolérance aux pannes.

Externalisation des sauvegardes critiques vers un site distant afin de garantir la reprise d’activité en cas d’incident majeur.

Concernant l’externalisation des sauvegardes, NovaTechSolutions a fait le choix d’externaliser une partie de ses sauvegardes auprès du fournisseur cloud Scaleway, afin de disposer d’une copie des données hors site.

Scaleway propose des services cloud complets (stockage, réseau, IAM, observabilité) permettant de répondre à des projets d’infrastructures simples comme complexes.

L’un des avantages majeurs réside dans la possibilité de maintenir la souveraineté des données, celles-ci étant soumises aux lois européennes telles que le RGPD lorsqu’elles sont hébergées sur ce cloud. Par ailleurs, le fournisseur dispose d’installations conformes à des standards reconnus comme ISO 27001, garantissant la mise en place de mesures visant la disponibilité, la confidentialité et l’intégrité des informations.

Les mécanismes de sauvegarde permettent notamment l’automatisation des backups des instances, la définition de politiques de rétention (quotidienne, hebdomadaire, mensuelle), la restauration rapide via des snapshots sécurisés, la recréation rapide d’une instance en cas d’incident.

Ce choix s’inscrit dans une logique de PRA/PCA, en complétant la règle de sauvegarde 3-2-1 mise en place dans l’infrastructure :

Copies locales pour la restauration rapide.

Stockage redondé interne,

Copie externalisée pour faire face à un sinistre majeur (incendie, ransomware, perte du site).

Ainsi, l’externalisation vers Scaleway contribue directement à renforcer la résilience globale du système d’information tout en répondant aux exigences réglementaires et aux bonnes pratiques de sécurité.

Objectifs opérationnels

Cette approche permet de :

Réduire le RPO (Recovery Point Objective) grâce à des sauvegardes régulières.

Diminuer le RTO (Recovery Time Objective) en facilitant la restauration rapide des services.

Renforcer la résilience globale de l’infrastructure face aux défaillances matérielles, erreurs humaines ou cyberattaques.

C. Plan de continuité (PCA) et reprise d’activité (PRA)

Le Plan de Continuité d’Activité (PCA) et le Plan de Reprise d’Activité (PRA) ont pour objectif de garantir le maintien ou le redémarrage rapide des services essentiels en cas d’incident majeur (cyberattaque, panne matérielle, sinistre).

Le PCA prévoit des mesures préventives permettant d’assurer le fonctionnement minimal de l’entreprise, tandis que le PRA définit les procédures à suivre pour restaurer l’infrastructure dans les meilleurs délais. Il repose notamment sur des indicateurs tels que le RTO (Recovery Time Objective) et le RPO (Recovery Point Objective), qui déterminent respectivement le temps maximal d’interruption acceptable et la quantité de données pouvant être perdue.

Dans le cadre de ce projet, la stratégie de continuité s’appuie sur plusieurs mécanismes structurants :

Haute disponibilité du cluster Proxmox permettant la bascule automatique des machines virtuelles.

Stockage distribué Ceph assurant la redondance des données.

Sauvegardes externalisées vers un cloud public afin de garantir une restauration en cas de sinistre majeur.

Segmentation réseau et redondance des équipements critiques pour limiter les impacts d’une panne.

Supervision centralisée permettant une détection rapide des incidents et une réduction du temps de reprise.

Figure 54 PCA / PRA

Cette approche s’inscrit dans une logique de résilience conforme aux bonnes pratiques de continuité d’activité, telles que celles portées par la norme ISO 22301, qui définit les exigences d’un système de management destiné à protéger l’organisation, réduire la probabilité d’incident et assurer une reprise efficace.

------------------------------------------------

Budget détaillé

Budget détaillé

VIII.1 Introduction et objectifs budgétaires

Dans le cadre de la mise en place d’un cloud privé pour NovaTechSolutions, une analyse budgétaire détaillée a été réalisée afin d’anticiper les coûts liés à l’infrastructure, aux licences, aux prestations techniques et aux exigences de conformité.

L’objectif de cette estimation est de garantir la maîtrise des coûts, la pérennité de l’infrastructure, un retour sur investissement mesurable et une solution évolutive, reposant majoritairement sur des technologies open source.

Le budget matériel regroupe l’ensemble des équipements physiques nécessaires à la mise en place du cloud privé NovaTechSolutions : serveurs Proxmox, disques Ceph, infrastructure réseau et éléments de sécurité.

Figure 55 Budget (estimation)

Figure 56 Répartition des grandes dépenses

VIII.2 Budget logiciel

Le projet repose majoritairement sur des solutions open-source matures, ce qui permet de réduire fortement les coûts logiciels. Seules les licences Proxmox Enterprise (optionnelles) ou certains outils de supervision commerciaux peuvent générer un coût additionnel.

Figure 57 Budget Logiciels

VIII.3 Coût de main d’œuvre

Le coût de la main d’œuvre permet d’évaluer le temps réellement investi par les différentes équipes impliquées, infrastructure, automatisation, sécurité, développement et support et de traduire cet effort en valeur financière.

Dans le cadre de ce projet, plusieurs facteurs influencent le coût de la main d’œuvre :

La diversité des compétences mobilisées

Administrateurs systèmes et virtualisation

Ingénieurs réseau et sécurité

Experts DevOps / IaC (Terraform, Ansible, Jenkins)

Développeurs Flask/Python

Équipe de support et documentation.

Chacune de ces compétences correspond à un niveau d’expertise différent, et donc à un coût journalier spécifique.

La répartition du travail par phases projet

Analyse fonctionnelle et conception technique

Installation et configuration du cluster Proxmox / Ceph

Développement du dashboard Flask

Intégration Terraform et Ansible

Sécurisation et tests

Documentation et mise en production.

Un modèle de calcul transparent et justifiable

Le coût de main d’œuvre est calculé à partir du nombre de jours/homme nécessaires, du taux journalier moyen (TJM) associé à chaque rôle et des charges liées à la conduite de projet (coordination, réunions, suivi de recette).

L’intégration de ces coûts humains permet ensuite de comparer le coût total de possession (TCO) d’un cloud privé à celui d’une solution cloud public, d’estimer la rentabilité à moyen terme (ROI) et de démontrer la pertinence économique du choix réalisé par l’entreprise.

Ainsi, cette section met en évidence non seulement l’effort technique engagé, mais aussi la valeur ajoutée créée par l’ensemble des équipes du projet, comme illustré dans l’organigramme fonctionnel des interventions.

Figure 58 Organigramme des services IT sollicités

Figure 59 Coût de main-d’œuvre

Figure 60 Gains annuels estimés

VIII.4 Analyse financière

L’analyse TCO/ROI montre que la mise en place du Cloud Privé apporte non seulement une modernisation profonde de l’infrastructure, mais aussi des gains financiers significatifs.

L’analyse financière du projet de cloud privé met en évidence une rentabilité significative sur un horizon de trois ans.

Avec un investissement global estimé à 22 850 €, le projet permet de générer des gains opérationnels évalués à environ 68 400 €, principalement grâce à l’automatisation des déploiements, à la réduction des incidents et à l’abandon de solutions propriétaires coûteuses.

Le bénéfice net est estimé à 45 550 €, ce qui correspond à un retour sur investissement d’environ 200 %. Le délai de rentabilité est évalué à 18 mois, démontrant la pertinence économique du choix d’un cloud privé automatisé et basé sur des technologies open source.

Ce résultat démontre que la solution retenue est non seulement pertinente techniquement, mais également extrêmement profitable économiquement pour NovaTechSolutions.

Figure 61 Analyse financière PowerBI

VIII.5 Analyse comparative : Cloud public vs Cloud privé

Afin de justifier le choix d’une architecture en cloud privé, une analyse comparative a été réalisée entre une solution de cloud public et l’infrastructure proposée dans le cadre de ce projet.
Cette comparaison met en évidence les différences majeures en termes de coûts, de souveraineté des données, de flexibilité et de dépendance vis-à-vis des fournisseurs.

Le cloud public présente l’avantage d’une mise en œuvre rapide, mais repose sur un modèle financier essentiellement basé sur des coûts récurrents (OPEX) et une forte dépendance au fournisseur. À l’inverse, le cloud privé mis en place offre un meilleur contrôle budgétaire sur le long terme, une personnalisation complète de l’infrastructure et une maîtrise totale des données, répondant ainsi aux exigences de sécurité et de conformité de l’entreprise.

Grâce à l’utilisation de technologies open source et à l’automatisation des déploiements (Terraform, Ansible, Jenkins), le cloud privé permet d’atteindre un retour sur investissement significatif tout en garantissant une haute disponibilité et une évolutivité maîtrisée.

VIII.6 Devis

Figure 62 Devis

VIII.7 Dispositifs d’accompagnement et aides à la transformation numérique

Dans le cadre de sa démarche de modernisation de l’infrastructure informatique, NovaTechSolutions a bénéficié d’un accompagnement proposé par Bpifrance, visant à soutenir les PME dans leurs projets de transformation numérique et de renforcement de la cyber sécurité.
Cet accompagnement s’inscrit dans une logique de diagnostic et d’aide à la structuration du projet, permettant d’identifier les axes prioritaires d’amélioration et de sécuriser les choix techniques retenus.

Le projet présenté, axé sur la haute disponibilité, l’automatisation des déploiements, la sécurisation des accès et la supervision centralisée, répond pleinement aux objectifs de ce dispositif.
L’appui de Bpifrance contribue à réduire les risques liés à l’investissement initial, à améliorer la maîtrise des coûts et à favoriser un retour sur investissement plus rapide, sans remettre en cause l’autonomie technique et opérationnelle de l’entreprise.

Figure 63 BPI France

Le cout du budget total est donc de 15.995€ pour NovaTechSolutions.

-------------------------------------------

Analyse des résultats

Analyse des résultats

Cette section présente l’évaluation objective de la solution mise en place, au regard des objectifs définis dans le cahier des charges.
Les résultats ont été mesurés à travers des tests de performance, de stabilité, d’automatisation et de disponibilité, mais également via l’analyse du budget et du respect du planning initial.

Figure 64 Synthèse des indicateurs de succès PKI L’ensemble de ces éléments permet de déterminer si la plateforme répond pleinement aux exigences d’un cloud privé automatisé, scalable et sécurisé.

IX.1 Performance

Les tests réalisés sur les différentes briques techniques (Terraform, API Proxmox, Ansible, Dashboard Flask, Ceph) montrent que la solution répond aux attentes de rapidité et d’efficacité :

Déploiement automatisé

Temps moyen de déploiement d’une VM via Terraform : 1 min 45 s

Déploiement d’un groupe complet : 4 à 5 minutes selon le nombre de VMs

Temps d’initialisation Cloud-Init : ≈ 20 secondes

Monitoring

Actualisation du statut Proxmox : toutes les 5 secondes

Rafraîchissement logs : toutes les 3 secondes

Temps de réponse API Proxmox (8006) : < 50 ms

Interface utilisateur

Requête Flask → Terraform : quasi instantanée (10–20 ms)

Aucune dégradation notable même lors de tests en charge.

Conclusion

La solution atteint, voire dépasse, les objectifs du CDCF. Le déploiement est rapide, homogène et entièrement automatisé.

IX.2 Stabilité et disponibilité

Cluster Proxmox

3 nœuds opérationnels en redondance

HA fonctionnelle (selon configuration Proxmox VE)

Aucun crash constaté pendant la période de test

Stockage Ceph

Réplication OSD assurée (min. 3 copies)

Débit stable

Aucun incident lors des opérations d’écriture ou de lecture

Dashboard Flask

Disponibilité mesurée : 99,3 % sur la période de test

Mise en place d’un certificat HTTPS pour sécuriser l’accès (ADCS).

Pas de montée anormale du CPU et de la RAM.

Jenkins + Ansible

Exécution fiable de tous les playbooks (idempotence).

Aucun échec non justifié

Conclusion

La plateforme est stable, résiliente et opérationnelle pour un usage en production interne.

IX.3 Gains obtenus

La mise en place du cloud privé automatisé apporte des bénéfices clairs :

Gains techniques

Automatisation complète du provisioning → réduction massive des erreurs humaines

Templates cloud-init uniformisés → standardisation des environnements

Supervision centralisée via dashboard + Graylog → visibilité accrue

Gains organisationnels

Déploiement d’une VM réduit de 10-15 minutes manuelles à moins de 2 minutes automatisées

Réduction du temps de formation : < 30 minutes pour prendre en main l’outil

Gains financiers

Réduction des licences propriétaires en choisissant des solutions open source

Coût du cloud privé inférieur à une location d’infrastructure équivalente en cloud public

Amortissement du matériel sur plusieurs années (calculé dans le TCO)

Conclusion gains :

Le projet offre un ROI positif, améliore les performances internes et réduit les coûts opérationnels.

IX.4 Respect du budget et des délais

Délais

Le projet avait une prévision de 7 semaines, découpées en phases (analyse, développement, tests, documentation…).

Le planning a été respecté, avec un dépassement léger sur l’intégration Terraform (+2 jours) mais compensé par une avance sur la phase de tests automatisés.

Budget

Le budget logiciel est resté conforme grâce aux solutions open source.

Seules les licences Proxmox (VE + Backup + Data Manager) ont représenté un coût notable.

Le budget total final se situe dans l’enveloppe prévue.

Conclusion budget & délais

Projet livré dans les temps

Budget maîtrisé

Aucune dépense imprévue significative

Clôture du projet & Recette

Clôture du projet

Cette phase permet de vérifier que les objectifs initiaux ont été atteints, que les livrables sont complets et exploitables, et que la transition vers l’environnement de production s’est déroulée sans impact pour les utilisateurs.

Afin de synthétiser cette évaluation, le tableau ci-dessous présente une vision consolidée des principaux axes analysés lors de la clôture du projet :

La validation fonctionnelle via la recette

La conformité des livrables produits

Le niveau d’appropriation par les équipes grâce aux formations délivrées

La conduite du changement et l’adoption de nouveaux outils

La réussite de la mise en production

Le bilan global en termes de performance, stabilité et budget, ainsi que les pistes d'amélioration identifiées pour les évolutions futures.

Figure 65 Tableau synthèse de clôture du projet

X.1 Recette fonctionnelle

La recette fonctionnelle a permis de valider que la solution respecte le cahier des charges, tant sur les aspects techniques que fonctionnels.
Elle s’est déroulée en trois phases :

Tests unitaires : validation de chaque composant (API Proxmox, scripts Terraform, rôles Ansible, dashboard Flask).

Tests d’intégration : vérification du fonctionnement global du pipeline (déploiement → cloud-init → post-config Ansible → sauvegarde automatique).

Tests utilisateurs : simulation de scénarios réels (déploiement d’une VM, consultation des logs Proxmox, accès Graylog, usage de l’interface Web).

La recette a conclu à 100 % de conformité avec les objectifs initiaux

A. Livrables réalisés

L’ensemble des livrables prévus au début du projet a été produit :

A.1 Livrables techniques

- Dashboard Flask sécurisé (HTTPS + MFA)

- Infrastructure IaC complète (Terraform + Ansible)

- Scripts de déploiement CI/CD Jenkins

- Templates cloud-init Debian / Windows personnalisés

- Architecture réseau segmentée (VLAN 10/20/30/40/50)

- Cluster Proxmox 3 nœuds + stockage Ceph

- Centralisation des journaux avec Graylog/Syslog/Wazuh

A.2 Livrables documentaires

- Dossier projet complet

- Manuel d’utilisation du dashboard

- Documentation Terraform / Ansible

- Tableau d’adressage IP

- Diagrammes UML, pieuvre, bête à cornes

A.3 Formation du personnel

Une formation a été dispensée à trois profils internes :

Figure 66 Formation du personnel

La satisfaction globale est évaluée à 4,8/5.

A.4 Conduite du changement

La conduite du changement a consisté à :

Simplifier les processus internes pour éviter les erreurs de déploiement

Rédiger des guides simples pour techniciens non développeurs

Introduire progressivement l’IaC dans les pratiques quotidiennes

Réduire l’appréhension face à l’automatisation (communication interne + formations)

Un plan de transition a permis d’accompagner les équipes sans rupture d’activité.

A.5 Mise en production

La mise en production (MEP) s’est déroulée en 3 étapes :

Gel de l’infrastructure (validation finale, snapshots, backup Proxmox Backup Server)

Déploiement du dashboard Flask en HTTPS

Bascule progressive vers la nouvelle solution :

Migration des services internes

Déploiement des premières VM de production

Mise en service du monitoring et de la supervision Graylog

La MEP s’est déroulée sans incident majeur.

B. Bilan du projet

Afin de conclure l’analyse et d’évaluer objectivement la réussite du projet, un bilan synthétique a été réalisé.
Ce tableau regroupe les principaux axes d’évaluation définis lors du cahier des charges performance, disponibilité, budget, délais, automatisation et sécurité et permet de mesurer l’écart entre les objectifs initiaux et les résultats obtenus.

L’objectif de cette synthèse est de fournir une vision claire, factuelle et immédiatement lisible de la qualité du travail réalisé.
Chaque critère est associé à un indicateur observable et mesurable, garantissant une évaluation précise de la solution mise en place.

Ce bilan démontre que le projet atteint ses objectifs dans l’ensemble des domaines clés, tout en mettant en lumière les points forts techniques, organisationnels et méthodologiques.

Le tableau ci-dessous présente cette synthèse sous forme de KPI structurés, utilisés à la fois pour la validation interne du projet et pour la phase de recette finale.

Figure 67 Bilan du projet

Pistes d’améliorations futures

Pistes d’amélioration futures

XI.1 Contexte et démarche d’amélioration continue

Les pistes d’amélioration présentées ci-après s’inscrivent dans une logique d’évolution continue de l’infrastructure Cloud privé mise en place pour NovaTechSolutions.
Elles visent à accompagner la croissance future de l’entreprise, à anticiper les besoins métiers émergents et à renforcer la maturité technique et organisationnelle du système d’information.

Ces évolutions ne remettent pas en cause l’architecture actuelle, qui répond pleinement aux objectifs initiaux du projet, mais constituent des axes d’optimisation et d’industrialisation à moyen et long terme.

Figure 68 Améliorations futures

XI.2 Montée en maturité DevOps

Une première piste d’amélioration concerne la montée en maturité DevOps de l’infrastructure.

Si le projet intègre déjà des principes DevOps tels que l’automatisation des déploiements via Terraform et Ansible, ainsi que l’orchestration par Jenkins, plusieurs axes peuvent être approfondis :

Mise en place de pipelines CI/CD plus avancés intégrant des contrôles qualité (tests automatisés et validation des configurations).

Mise à jour régulière de l’infrastructure (Infrastructure as Code) avec gestion des environnements (Dev, test, production).

Standardisation des workflows de déploiement pour réduire les erreurs humaines et améliorer la reproductibilité.

Cette évolution permettrait d’améliorer la fiabilité des mises en production tout en réduisant les délais de déploiement.

XI.3 Mise en place d’une observabilité avancée

Le projet actuel intègre déjà des mécanismes de supervision et de centralisation des journaux.
Une amélioration future consisterait à mettre en œuvre une observabilité avancée couvrant l’ensemble de l’infrastructure.

Cette observabilité pourrait s’appuyer sur :

La collecte centralisée des métriques système et applicatives (CPU, mémoire, latence, disponibilité).

La corrélation des logs et des événements afin de faciliter le diagnostic des incidents.

La mise en place de tableaux de bord décisionnels permettant une vision en temps réel de l’état de l’infrastructure.

L’objectif est de passer d’une supervision réactive à une supervision proactive, capable d’anticiper les incidents avant qu’ils n’impactent les utilisateurs.

XI.4 Automatisation du patch management

Une autre piste d’amélioration concerne l’automatisation complète du patch management.

Bien que les mises à jour puissent déjà être exécutées manuellement ou via Ansible, une industrialisation plus poussée permettrait :

Le déploiement automatique des correctifs de sécurité selon des fenêtres de maintenance définies.

La validation des mises à jour dans un environnement de test avant déploiement en production.

La génération de rapports de conformité et de traçabilité des correctifs appliqués.

Cette approche renforcerait la sécurité globale du système d’information tout en garantissant une meilleure conformité aux bonnes pratiques et aux exigences réglementaires.

XI.5 Évolutivité et industrialisation de l’architecture

À moyen terme, l’architecture pourrait évoluer vers une industrialisation accrue, notamment par :

L’intégration de solutions de conteneurisation et d’orchestration (Docker, Kubernetes).

La standardisation des services applicatifs sous forme de catalogues de services.

L’extension du cluster Proxmox et du stockage Ceph pour accompagner la montée en charge.

Ces évolutions permettraient à NovaTechSolutions de disposer d’un cloud privé plus flexible, plus scalable et capable de s’adapter rapidement aux nouveaux besoins métiers.

XI.6 Bénéfices attendus des améliorations futures

La mise en œuvre de ces pistes d’amélioration apporterait plusieurs bénéfices :

Amélioration de la disponibilité et de la résilience de l’infrastructure.

Réduction des risques opérationnels et de sécurité.

Gain de temps pour les équipes IT grâce à une automatisation accrue.

Meilleure capacité d’anticipation et de pilotage du système d’information.

Ces évolutions positionnent le cloud privé comme un levier stratégique pour l’entreprise, au-delà d’un simple projet technique.

Compétences couvertes par le projet

Compétences couvertes par le projet

Le tableau ci-dessous présente la correspondance entre le référentiel d’activités et de compétences (REAC) et les réalisations concrètes du projet de Cloud Privé NovaTechSolutions.
Il met en évidence la manière dont chaque activité professionnelle attendue est traduite en actions techniques réelles, mesurables et documentées à travers la conception, le déploiement et l’exploitation d’un cloud privé automatisé.

Ainsi, chaque compétence identifiée dans le REAC est associée à des activités effectivement réalisées, ainsi qu’à des preuves et livrables concrets (architectures, configurations, scripts, procédures, journaux), garantissant la traçabilité et la validation des acquis professionnels.

Figure 69 Correspondances REAC – Projet

Tests de production

Tests de production

Avant la mise en production définitive de l’infrastructure, une phase de tests a été réalisée afin de valider le bon fonctionnement des services déployés et de s’assurer de leur conformité aux exigences définies en amont du projet.

Ces tests ont permis de vérifier la stabilité de l’environnement, la fiabilité des mécanismes d’automatisation, ainsi que la tolérance aux pannes des composants critiques. Ils ont également servi à évaluer le comportement de l’infrastructure dans des conditions proches de l’exploitation réelle, en identifiant d’éventuelles anomalies avant la mise en service opérationnelle.

L’objectif principal de cette phase est de garantir une infrastructure fonctionnelle, sécurisée et conforme aux attentes du client, tout en limitant les risques lors du passage en production.

XIII.1 Tests fonctionnels et techniques

Test 1 : Déploiement automatique d’une machine virtuelle

Acteur : un administrateur
Objectif : créer une VM complète en quelques clics

Étapes :

Sélectionnez un Template (par exemple Debian préparée pour Docker) et renseignez les caractéristiques souhaitées.

Cliquez sur Terraform Apply pour Déployer.

Terraform crée automatiquement la VM sur Proxmox.

Ansible configure le système (mises à jour, packages, users…).

Jenkins orchestre le pipeline et renvoie l’état dans le dashboard.

L’utilisateur voit la VM prête à l’emploi dans l’interface.

Bénéfice et gain de temps énorme, suppression des tâches manuelles répétitives

Résultat : Déploiement d’une VM en > 2min.

Figure 70 Dashboard Déploiement

Test 2 : Visualisation et supervision du cluster Proxmox

Acteur : administrateur
Objectif : surveiller l’état global de l’infrastructure

Étapes :

Le dashboard interroge l’API Proxmox (CPU, RAM, stockage, VM…).

L’utilisateur visualise les charges, les VMs actives, les ressources Ceph.

Il peut arrêter, redémarrer ou supprimer une VM depuis l’interface.

Résultat : Dashboard opérationnel, centralisé et sécurisé.

Figure 71 Dashboard - Déploiement

Test 3 : Déploiement d’un environnement complet

Acteur : formateur, apprenant avancé
Objectif : déployer automatiquement un environnement complet.
Étapes :

L’utilisateur choisit un groupe de déploiement.

Terraform crée toutes les VM nécessaires.

Ansible configure le cluster (web, base de données…).

Jenkins gère l’enchaînement.

Le dashboard affiche l’ensemble des composants déployés.

Résultat : Déploiement d’un environnement de formation ou de test en quelques minutes.

Figure 72 Groupe de déploiement – Dashboard

Test 4 : Exécution de tâches de maintenance

Acteur : administrateur
Objectif : appliquer des actions sur des VM depuis le dashboard

Étapes :

Choix d’une action (Mise à jour (upgrade/update) ou Test de connectivité (Ping).

Le dashboard exécute l’action via les pipelines Jenkins correspondants.

L’état final est affiché dans l’interface.

Bénéfice : maintien de la conformité et gestion simplifiée.

Figure 73 Dashboard – Ansible

Test 5 : Déploiement d’une solution applicative via le dashboard (Ansible)

Acteur : administrateur
Objectif : Déployer une solutions sur une VM depuis le dashboard

Étapes :

Sélection d’une machine virtuelle cible ainsi que de la solution applicative à déployer depuis la fenêtre dédiée du dashboard. (Par exemple Apache2).

Le dashboard déclenche automatiquement l’exécution du playbook Ansible correspondant à la solution sélectionnée.

Le déroulement et l’état final du déploiement (succès ou échec) sont affichés directement dans l’interface du dashboard.

Bénéfice :
Ce test démontre la capacité du dashboard à centraliser et automatiser le déploiement de services applicatifs, garantissant une configuration homogène et une gestion simplifiée des machines virtuelles.

Figure 74 Dashboard - Déploiement logiciels

Conclusion

Ces contraintes et scénarios d’utilisation permettent de cadrer précisément le projet tout en démontrant son utilité pratique : automatiser, simplifier et unifier la gestion d’un cloud privé grâce à un dashboard personnalisé.

XIII.2 Test de sécurité et de conformité

Avant la mise en production définitive, des tests de sécurité ont été réalisés afin de valider l’efficacité des mécanismes de protection mis en œuvre et de vérifier l’alignement de l’infrastructure avec les bonnes pratiques de sécurité identifiées lors de la phase d’audit.

Ces tests ont permis de s’assurer que les contrôles d’accès, la journalisation et les mécanismes de sécurisation fonctionnent conformément aux exigences définies dans le cadre du projet.

Test 6 : Authentification forte au dashboard (MFA) avec certificat client (mTLS)

Acteur : administrateur
Objectif : vérifier l’application de l’authentification forte à l’accès au dashboard

Étapes :

L’utilisateur tente de se connecter au dashboard via un navigateur.

Il saisit son identifiant et son mot de passe.

Un code temporaire (TOTP) est demandé via une application d’authentification.

En cas de code valide, l’accès est autorisé.

En cas de code invalide ou absent, l’accès est refusé.

Figure 75 Identification Dashboard (MFA)

Résultat :
L’accès au dashboard est impossible sans la validation complète des deux facteurs d’authentification.

Bénéfice :
Réduction significative du risque de compromission des comptes administrateurs.

Test 7 : Accès au dashboard sans certificat client (mTLS)

Acteur : utilisateur non autorisé / poste non conforme
Objectif : vérifier le blocage de l’accès sans certificat client valide

Étapes :

Tentative d’accès au dashboard depuis un poste ne disposant pas du certificat client.

Le navigateur établit une connexion HTTPS.

Le serveur exige la présentation d’un certificat client valide.

L’accès est immédiatement refusé.

Figure 76 Accès au dashboard refusé - Mtls absent

Résultat :
La connexion au dashboard est impossible sans certificat client installé sur le poste.

Bénéfice :
Mise en œuvre d’un contrôle d’accès fort de type Zero Trust, empêchant tout contournement même avec des identifiants valides.

Test 8 : Accès distant via VPN sécurisé

Acteur : administrateur
Objectif : vérifier la sécurisation des accès distants

Étapes :

L’utilisateur établit une connexion VPN Wireguard vers l’infrastructure.

Les flux sont filtrés par le firewall OPNSense.

L’utilisateur accède uniquement aux ressources autorisées (dashboard, administration).

Figure 77 Connexion VPN au dashboard

Résultat :
L’accès aux ressources internes est possible uniquement après établissement du VPN.

Bénéfice :
Isolation des services sensibles et réduction de la surface d’exposition de l’infrastructure.

Test 9 : Journalisation et traçabilité des actions

Acteur : administrateur
Objectif : vérifier la centralisation et la traçabilité des événements

Étapes :

Connexion au dashboard.

Déploiement d’une VM et exécution d’une tâche de maintenance.

Génération d’événements système et applicatifs.

Consultation des logs centralisés via Graylog.

Figure 78 Centralisation des logs - Graylog

Résultat :
Les événements sont correctement collectés, centralisés et horodatés.

Bénéfice :
Amélioration de la visibilité, de la capacité d’audit et de la détection d’incidents de sécurité.

Test 10 : Résilience et tolérance à la panne

Acteur : administrateur
Objectif : vérifier le comportement de l’infrastructure en cas de défaillance

Étapes :

Arrêt volontaire d’un nœud Proxmox.

Observation de l’état du cluster.

Vérification du redémarrage automatique des machines virtuelles sur les autres nœuds.

Résultat :
Les machines virtuelles restent disponibles grâce aux mécanismes de haute disponibilité.

Bénéfice :
Validation de la suppression des principaux SPOF identifiés lors de l’audit initial.

Conclusion des tests de sécurité et de conformité

L’ensemble des tests réalisés confirme que l’infrastructure déployée répond aux exigences de sécurité, de disponibilité et de conformité définies en amont du projet.
Les mécanismes d’authentification forte, de contrôle d’accès, de journalisation et de haute disponibilité permettent de réduire significativement les risques identifiés lors de la phase d’audit et garantissent une exploitation sécurisée de l’environnement en production.

-------------------------------------------------------------

Glossaire

Glossaire

2

2FA, 8, 41, 45, 49, 51, 55, 75, 76, 78, 82, 89, 92

A

ACL, 9, 18, 22

Active Directory, 10, 19, 20, 21, 37, 74

Administrateur, 1, 11, 12, 18, 30, 82

Ansible, 1, 8, 9, 12, 13, 18, 25, 27, 31, 34, 37, 41, 45, 46, 47, 49, 50, 51, 53, 55, 57, 60, 64, 65, 74, 75, 78, 79, 80, 82, 83, 88

API, 6, 9, 31, 41, 47, 49, 50, 55, 57, 63, 64, 65, 74, 75, 79, 82, 83, 84, 85, 86, 88, 90

Applications, 57

Automatisation, 18, 37, 44, 45, 47, 48, 49, 57, 75

AWS, 63

B

besoin, 4, 23, 24, 26, 29, 31, 45, 48, 63, 86, 93

bête à cornes, 4, 29, 76

budget, 4, 39, 46, 54, 61, 63, 69

C

CARP, 19, 20, 21, 76

CD, 9, 18, 25, 31, 37, 41, 57, 65, 74

CDCF, 4, 44, 49

CDCT, 4, 49

Ceph, 1, 4, 9, 13, 18, 26, 27, 34, 36, 37, 41, 46, 47, 53, 54, 55, 57, 58, 60, 61, 66, 74, 75, 79, 81

charges, 18, 22, 44, 79

CI, 9, 18, 25, 31, 37, 41, 57, 65, 74

cloud, 1, 9, 11, 12, 14, 16, 18, 24, 25, 26, 27, 28, 31, 32, 33, 34, 36, 37, 39, 41, 53, 54, 55, 59, 60, 61, 63, 64, 65, 66, 75, 76, 80, 81, 83, 91

cluster, 9, 18, 20, 21, 24, 26, 27, 34, 36, 37, 41, 45, 47, 49, 57, 60, 63, 64, 65, 66, 74, 75, 79, 81

Conception, 21, 27, 53, 55, 56

D

Dashboard, 7, 8, 9, 18, 26, 31, 47, 49, 50, 57, 60, 78, 79, 80, 82, 89, 92

DHCP, 20, 21

DMZ, 20, 21

DNS, 9, 20, 21

Docker, 13, 27, 37, 41, 74, 78, 87, 88

F

Flask, 4, 6, 9, 11, 12, 13, 18, 19, 26, 27, 31, 36, 37, 41, 46, 47, 49, 50, 53, 55, 57, 60, 64, 65, 66, 74, 75, 78, 82, 87

flux, 21, 31, 66, 76, 81

G

Graylog, 13, 31, 60, 75, 82, 87, 88

H

HA, 9, 19, 20, 21, 26, 27, 41, 74, 76

Harvester, 63

I

infrastructures, 11, 13, 14, 17, 23, 53, 63, 66

Ishikawa, 4, 7, 27

Isolation, 21, 22, 57

J

Jenkins, 9, 10, 12, 13, 18, 25, 27, 31, 37, 41, 46, 47, 53, 55, 57, 64, 65, 74, 78, 79, 80, 82, 83, 88

K

KPI, 7, 48

Kubernetes, 49, 63

KUKA, 11

L

Linux, 9, 11, 18, 27, 36, 37, 49, 57, 74, 75, 76

logiciel, 16, 61

logs, 19, 20, 22, 41, 45, 47, 48, 49, 50, 55, 60, 65, 76, 83, 86, 87, 92

M

Mail, 20

MON, 9, 37, 41, 57, 74

N

nœuds, 9, 18, 19, 27, 31, 36, 37, 41, 45, 47, 49, 50, 64, 82

NovaTechSolutions, 16

Nutanix, 63

O

OpenStack, 47, 63, 64

opérationnels, 7, 13, 26, 27, 29, 32, 33, 34

OSD, 9, 18, 27, 37, 41, 57, 74

P

pieuvre, 4, 7, 30, 76

ping, 50, 82, 84, 85, 87, 88

Pipeline, 9, 37, 41

PME, 15, 16, 27, 63, 64

Postfix, 13

projet, 7, 9, 11, 12, 13, 17, 18, 19, 22, 24, 25, 26, 27, 29, 31, 32, 33, 34, 36, 37, 38, 39, 40, 41, 46, 47, 48, 49, 51, 52, 53, 54, 61, 63, 64, 65, 66, 70, 80, 91, 92

Proxmox, 1, 4, 9, 10, 12, 13, 14, 18, 19, 20, 21, 26, 27, 31, 34, 36, 37, 41, 45, 46, 47, 48, 49, 50, 51, 53, 54, 55, 57, 58, 60, 61, 63, 64, 65, 66, 74, 75, 76, 78, 79, 81, 82, 83, 84, 85, 86, 87, 91

Python, 6, 11, 12, 13, 18, 19, 26, 41, 49, 64, 65, 74, 75, 82

Q

QQQQCCP, 4, 26

R

RACI, 4, 7, 39, 76

RDS, 19, 20, 21

Réseaux, 11, 20, 30, 76

retest, 94

risques, 4, 7, 18, 24, 25, 28, 39, 40, 52, 76

S

schémas, 4, 22

SIEM, 49, 83, 90

stratégiques, 7, 24, 27, 29, 32, 33, 34, 35

SYNC, 20

SysML, 7, 46

T

TCO / ROI, 4, 7, 52

Templates, 27, 28, 37, 41, 47, 49, 50, 90

Terraform, 1, 9, 12, 13, 18, 19, 25, 26, 27, 31, 34, 36, 37, 41, 45, 46, 47, 48, 49, 50, 51, 53, 55, 57, 60, 64, 65, 74, 75, 78, 79, 82, 83, 87, 88, 91, 92, 93

test index, 78

topologie, 22

V

vCloud, 63

VLAN, 9, 19, 20, 21, 22, 26, 27, 53, 76

VM, 9, 18, 19, 20, 21, 25, 27, 41, 45, 47, 48, 49, 55, 57, 60, 65, 78, 79, 80, 82, 83, 85, 86, 91, 92

VMware, 14, 63, 64

VoIP, 19, 20, 21

VPN, 10, 20, 26, 37, 47, 53, 57

vSphere, 63, 64

W

WAN, 9, 20, 21

WDS, 20, 21

Web, 19, 20, 21, 49, 63, 75

Wifi, 20

Windows, 10, 11, 18, 27, 36, 37, 49, 57, 74, 76, 83, 87

WireGuard, 10, 37

WSUS, 20, 21

Bibliographie & Webographie

Bibliographie

Ayari, K. (2015). Active Directory et Windows PowerShell en action. Éditions ENI.

Bonnet, N. (2023). Windows Server 2022 – Installation, gestion du stockage et des traitements. Éditions ENI.

Deffaix Rémy, C. (2022). Programmation Shell sous Unix/Linux – ksh, bash, norme POSIX (avec exercices corrigés) (7ᵉ éd.). Éditions ENI.

Espolin, M. (2024). Terraform – Le P’tit Guide. Éditions Independently published.

Wittouck, J. (2024). L’infrastructure as Code avec Terraform – Déployez votre infrastructure sur le Cloud. Éditions ENI.

Lemesle Romain. (2018). PowerShell Core et Windows PowerShell – Les fondamentaux du langage (2ᵉ éd.). Éditions ENI.

Perrin Damien. (2022). Automatiser les réseaux avec Ansible : Guide technique pour l'administrateur. Edition Independently published.

Cloux Pierre-Yves. (2022). Docker et conteneurs (3ᵉ éd.) : Architectures, développement, usages et outils. Éditions ENI.

Perré Yannig. (2023). Ansible – Gérez la configuration de vos serveurs et le déploiement de vos applications (3ᵉ éd.). Éditions ENI.

Chazallet Sébastien. (2024). Python 3 – Traitement de données et techniques de programmation (2ᵉ éd.). Éditions ENI.

Reed Amélia. (2025). Maîtrise de Jenkins : Jobs, Pipelines, CI/CD et DevOps pour les débutants absolus. Éditions ENI.

Webographie

Classée par Technologies

Virtualisation & Infrastructure Proxmox VE

Documentation officielle Proxmox

https://pve.proxmox.com/pve-docs/

Wiki Proxmox VE

https://pve.proxmox.com/wiki/Main_Page

API REST Proxmox

https://pve.proxmox.com/pve-docs/api-viewer/

HA & Clustering

https://pve.proxmox.com/wiki/High_Availability_Cluster_4.x

Utilisé pour : configuration du cluster, gestion HA, gestion des VMs, API appelée par ton dashboard Flask.

Stockage Distribué Ceph

Documentation Ceph

https://docs.ceph.com/en/latest/

Architecture RADOS (OSD, MON, MGR)

https://docs.ceph.com/en/latest/rados/

Best practices Ceph sur Proxmox

https://pve.proxmox.com/wiki/Ceph_Server

Utilisé pour : stockage distribué, réplication, tolérance aux pannes, choix de l’architecture Ceph dans ton cluster.

Infrastructure as Code (IaC) – Terraform

Documentation Terraform

https://developer.hashicorp.com/terraform/docs

Provider Proxmox (Telmate)

https://registry.terraform.io/providers/Telmate/proxmox/latest/docs

Syntaxe HCL

https://developer.hashicorp.com/terraform/language

Meilleures pratiques Terraform

https://developer.hashicorp.com/terraform/cloud-docs/best-practices

Utilisé pour : déploiement automatisé des VMs, modules personnalisés, gestion du cycle de vie des machines (plan/apply).

Automatisation & Configuration – Ansible

Documentation Ansible

https://docs.ansible.com/

Ansible Galaxy

https://galaxy.ansible.com/

Bonnes pratiques Ansible

https://docs.ansible.com/ansible/latest/tips_tricks/index.html

Ansible Vault (sécurisation secrets)

https://docs.ansible.com/ansible/latest/user_guide/vault.html

Utilisé pour : automatisation post-déploiement, exécution de playbooks depuis ton dashboard, sécurisation SSH.

Développement Web – Flask & Python

Documentation Flask

https://flask.palletsprojects.com/

Documentation Jinja2

https://jinja.palletsprojects.com/

Werkzeug (serveur HTTP Flask)

https://werkzeug.palletsprojects.com/

Python Standard Library

https://docs.python.org/3/library/

Utilisé pour : développement du dashboard, communication API, mise en place du HTTPS, génération du frontend dynamique.

Supervision, Logs & Sécurité

Graylog – Documentation officielle

https://go2docs.graylog.org/

GELF (Graylog Extended Log Format)

https://docs.graylog.org/docs/gelf/

Sécurité TLS / HTTPS – Mozilla SSL Guidelines

https://ssl-config.mozilla.org/

CIS Benchmarks Linux (durcissement)

https://www.cisecurity.org/cis-benchmarks/

2FA Standards

https://authy.com/what-is-2fa/

Utilisé pour : supervision centralisée, intégration des logs Proxmox, durcissement du dash, mise en place HTTPS/2FA.

Réseaux & Sécurité – OPNSense, VLAN, Firewalling

Documentation OPNSense CE

https://docs.netgate.com/OPNsense/en/latest/

VLAN : Concepts & segmentation réseau (Cisco)

https://www.cisco.com/c/en/us/solutions/enterprise-networks/what-is-a-vlan.html

Firewall Best Practices

https://www.sans.org/white-papers/firewalls/

Utilisé pour : segmentation réseau (VLAN 10/20/50/99), HA CARP, synchronisation OPNSense, sécurisation des flux.

Méthodologie & Gestion de Projet

Cycle en V

https://www.commentcamarche.net/contents/595-cycle-en-v

Gantt – Référence méthodologique

https://asana.com/fr/resources/gantt-chart

AMDEC – Analyse des risques

https://fr.wikipedia.org/wiki/Analyse_des_modes_de_d%C3%A9faillance_et_de_leurs_effets

Diagrammes – UML

https://www.uml-diagrams.org/

Outil de modélisation (utilisé dans ton dossier)

https://www.diagrams.net/

Utilisé pour : analyse fonctionnelle (bête à cornes, pieuvre), WBS, RACI, Gantt, étude des risques, architecture globale.

Systèmes d’exploitation (Linux & Windows)

Debian Documentation

https://www.debian.org/doc/

Ubuntu Server Guide

https://ubuntu.com/server/docs

Windows Server 2022 Documentation

https://learn.microsoft.com/en-us/windows-server/

Windows 11 Pro – Admin Guide

https://learn.microsoft.com/en-us/windows/

Utilisé pour : templates Linux/Windows, configuration ADDS/ADCS, intégration des OS dans ton cloud privé.

Annexe

Annexe

XVII.1 Rapports d’audit de l’infrastructure initiale de NovaTechSolutions

Figure 79 Résultats audit initiale

XVII.2 Certificats de formations.

Les certificats présentés dans cette annexe correspondent à des formations complémentaires suivies en parallèle du cursus principal, principalement durant les week-ends et en autonomie.

Ces formations avaient pour objectif de renforcer mes compétences techniques sur des thématiques directement liées à la mise en œuvre du projet de cloud privé, notamment la virtualisation, l’automatisation, les réseaux et la sécurité des systèmes.

Elles m’ont permis d’approfondir certains concepts techniques abordés dans le cadre de la formation, d’acquérir des compétences pratiques directement applicables au projet et de garantir une mise en œuvre cohérente, fonctionnelle et réaliste de l’infrastructure présentée.

Figure 85 ANSSI MOOC Figure 84 Docker avancé Figure 81 Programmez des applications avec Flask Figure 80 Python - La formation complète 2025 Figure 83 L'essentiel de Windows Server 2025 Figure 82 Kubernetes - Installation & Configuration Ces apprentissages complémentaires s’inscrivent dans une démarche personnelle de montée en compétences continue, indispensable dans les métiers de l’informatique et plus particulièrement dans les domaines de l’administration systèmes, du cloud et du DevOps.

XVII.3 Annexe – Matérielles utilisés pour la mise en place du cloud privé

Les images suivantes présentent l’infrastructure physique mise en place par le porteur du projet afin de concevoir et tester le cloud privé de NovaTechSolutions dans un environnement représentatif d’une situation réelle en entreprise.

Cette infrastructure personnelle a été conçue comme une plateforme de travail professionnelle, reproduisant les contraintes techniques, organisationnelles et sécuritaires d’un environnement de production.

Elle comprend notamment les serveurs Proxmox VE, les équipements réseau ainsi que les dispositifs de sécurité nécessaires pour garantir la disponibilité, la performance et la sécurité de la plateforme.

Figure 86 Inventaire matériels

Figure 87 Cluster - Serveur Proxmox VE. (3 nœuds)

Figure 92 Serveur Proxmox Datacenter Figure 91 Serveur Proxmox Backup – SRV ADDS Figure 90 Serveur Proxmox Backup Figure 89 Postes utilisateurs Figure 88 Cluster OPNSense & Switch

XVII.4 Annexe techniques du Dashboard

Les annexes suivantes présentent des extraits ciblés du code source du dashboard Cloud Privé développé dans le cadre du projet NovaTechSolutions. Les extraits ont été volontairement sélectionnés afin d’illustrer les mécanismes clés de sécurité, d’automatisation et d’orchestration, sans alourdir le dossier par l’intégralité du code.

Annexe A – Sécurisation de l’accès au Dashboard (Authentification MFA)

Objectif : Garantir un accès sécurisé au Dashboard d’administration du cloud privé.

Le Dashboard implémente une authentification forte reposant sur une double étape :

Authentification par identifiant et mot de passe.

Validation par second facteur (2FA) via un code TOTP (Time-based One-Time Password).

Cette approche permet de réduire significativement les risques d’accès non autorisés, même en cas de compromission des identifiants.

ADMIN_USERNAME = "nebtech_admin"

ADMIN_PASSWORD = "********"

TOTP_SECRET = pyotp.random_base32()

@app.route("/login", methods=["GET", "POST"])

def login():

if request.method == "POST":

if (

request.form.get("username") == ADMIN_USERNAME

and request.form.get("password") == ADMIN_PASSWORD

):

session["pre_2fa"] = True

return redirect("/2fa")

return render_template("login.html")

@app.route("/2fa", methods=["GET", "POST"])

def twofa():

totp = pyotp.TOTP(TOTP_SECRET)

if request.method == "POST":

if totp.verify(request.form.get("code")):

session["user"] = ADMIN_USERNAME

return redirect("/")

Valeur ajoutée au projet : sécurité renforcée, conformité aux bonnes pratiques entreprise, maîtrise des accès administrateurs.

Annexe B – Supervision du cluster Proxmox via API REST

Objectif : Fournir une supervision centralisée et en temps réel du cluster Proxmox.

Le dashboard interroge l’API REST Proxmox afin de collecter les métriques essentielles (CPU, mémoire, disponibilité des nœuds). Cette approche évite toute manipulation manuelle sur les hyperviseurs.

response = requests.get(

f"https://{node_ip}:8006/api2/json/nodes/{node_name}/status",

headers=HEADERS_PVE,

verify=False,

timeout=4,

)

Valeur ajoutée au projet : supervision temps réel, centralisation des informations, réduction des opérations manuelles.

Annexe C – Orchestration de la configuration via Ansible

Objectif : Automatiser la configuration post-déploiement des machines virtuelles.

Après la création des VM, le dashboard permet d’exécuter des playbooks Ansible à la demande afin d’assurer le durcissement, l’installation de services ou les opérations de maintenance.

result = subprocess.check_output(

[

"ssh",

"root@192.168.1.134",

"ansible-playbook /etc/ansible/playbooks/deploy.yml -i /etc/ansible/inventory.ini",

],

stderr=subprocess.STDOUT,

text=True,

)

Valeur ajoutée au projet : homogénéité des configurations, réduction des erreurs humaines, automatisation complète du cycle de vie.

Annexe D – Provisioning des machines virtuelles avec Terraform

Objectif : Mettre en œuvre le principe d’Infrastructure as Code (IaC).

Terraform est utilisé pour créer dynamiquement les machines virtuelles sur le cluster Proxmox à partir de templates standardisés. Les déploiements sont éphémères et entièrement automatisés.

output = ""

output += run(["terraform", "init", "-upgrade"])

output += run(["terraform", "apply", "-auto-approve"])

Valeur ajoutée au projet : déploiement rapide, reproductible et traçable des environnements.

Annexe E – Sécurisation HTTPS du dashboard

Objectif : Protéger les échanges entre les utilisateurs et le dashboard.

Le dashboard Flask est configuré pour fonctionner exclusivement en HTTPS, garantissant le chiffrement des flux et la confidentialité des données échangées.

if __name__ == "__main__":

app.run(

host="0.0.0.0",

port=443,

ssl_context=("dashboard.pem", "dashboard.key")

)

Valeur ajoutée au projet : conformité aux standards de sécurité, protection contre les attaques de type interception (MITM).

Annexe F – Extraits de code du Dashboard Cloud (Python / Flask)

Extrait 1 – Initialisation du Dashboard Flask et sécurité

from flask import Flask

from flask_login import LoginManager

from flask_talisman import Talisman

app = Flask(__name__)

app.secret_key = os.environ.get("FLASK_SECRET_KEY")

Talisman(app, content_security_policy=None)

login_manager = LoginManager()

login_manager.init_app(app)

login_manager.login_view = "login"

Cet extrait illustre l’initialisation du dashboard Cloud développé en Python avec Flask.
L’application est sécurisée par HTTPS grâce à Flask-Talisman et repose sur une gestion des sessions utilisateurs via Flask-Login.
Cette approche garantit un accès contrôlé au dashboard, condition indispensable pour une interface pilotant des déploiements d’infrastructure critiques.

Extrait 2 – Route de déploiement automatisé via Terraform

@app.route("/deploy", methods=["POST"])

@login_required

def deploy_vm():

subprocess.run(

["terraform", "apply", "-auto-approve"],

cwd="/opt/terraform",

capture_output=True,

text=True

)

return redirect(url_for("status"))

Cette route illustre le cœur du projet : le déclenchement automatisé du provisioning des machines virtuelles via Terraform.
L’utilisateur, authentifié, initie le déploiement depuis le dashboard. Le provisioning est entièrement automatisé, reproductible et traçable, conformément aux principes de l’Infrastructure as Code.

Extrait 3 – Intégration Ansible / Jenkins pour la post-configuration

@app.route("/ansible/run/<playbook>")

@login_required

def run_playbook(playbook):

subprocess.Popen(

["ansible-playbook", f"{playbook}.yml"],

cwd="/opt/ansible"

)

return "Playbook lancé"

Après la création des machines virtuelles, Ansible est utilisé pour assurer la configuration automatique : durcissement, installation de services et standardisation des environnements.
Cette séparation claire entre provisioning (Terraform) et configuration (Ansible) garantit la maintenabilité et la robustesse de la solution.

Extrait 4 – Récupération des logs et supervision

@app.route("/logs")

@login_required

def logs():

result = subprocess.run(

["journalctl", "-n", "50", "--no-pager"],

capture_output=True,

text=True

)

return render_template("logs.html", logs=result.stdout)

Cet extrait montre l’intégration de la supervision directement dans le dashboard.
Les journaux systèmes sont consultables sans accès SSH, ce qui améliore la visibilité opérationnelle tout en limitant les risques de manipulation directe sur les serveurs. Ces extraits démontrent la cohérence globale du projet, la maîtrise des outils DevOps et des bonnes pratiques de sécurité, ainsi que la capacité à concevoir une infrastructure cloud privée moderne, automatisée et sécurisée.

Annexe G – Organisation et arborescence des outils d’automatisation

Cette annexe a pour objectif de présenter l’organisation des répertoires utilisés pour l’automatisation du cloud privé NovaTechSolutions.
Elle permet au lecteur de comprendre rapidement la structuration du projet, la séparation des rôles entre les différents outils (Terraform, Ansible, Jenkins, Dashboard Flask) et la logique d’industrialisation retenue.

La structuration des fichiers est un élément essentiel pour garantir la maintenabilité du projet, faciliter les évolutions futures et assurer une exploitation claire et sécurisée.

G.1 Arborescence globale du projet

/opt/cloud-dashboard/

│

├── flask/

│ ├── app.py

│ ├── requirements.txt

│ ├── templates/

│ │ ├── index.html

│ │ ├── login.html

│ │ ├── dashboard.html

│ │ └── logs.html

│ └── static/

│ ├── css/

│ └── js/

│

├── terraform/

│ ├── main.tf

│ ├── provider.tf

│ ├── variables.tf

│ ├── terraform.tfvars

│ ├── outputs.tf

│ └── modules/

│ └── vm_proxmox/

│ ├── main.tf

│ ├── variables.tf

│ └── outputs.tf

│

├── ansible/

│ ├── inventories/

│ │ └── production.ini

│ ├── playbooks/

│ │ ├── deploy_apache.yml

│ │ ├── deploy_docker.yml

│ │ ├── maintenance.yml

│ │ └── ping.yml

│ ├── roles/

│ │ ├── common/

│ │ ├── hardening/

│ │ └── webserver/

│ └── ansible.cfg

│

├── jenkins/

│ └── Jenkinsfile

│

├── logs/

│ ├── terraform.log

│ ├── ansible.log

│ └── dashboard.log

│

└── README.md

Description par composant

Dashboard Flask (Python)

Le dossier flask/ contient l’interface web du cloud privé.

Il centralise les interactions utilisateurs et déclenche les actions d’automatisation.

app.py : cœur applicatif, routes, sécurité, orchestration

Templates/ : vues HTML du dashboard

static/ : styles CSS et scripts JavaScript

Rôle : point d’entrée unique, sécurisé et ergonomique.

Terraform – Infrastructure as Code

Le dossier terraform/ regroupe l’ensemble des fichiers nécessaires au provisioning automatisé des machines virtuelles sur le cluster Proxmox.

provider.tf : configuration du provider Proxmox

main.tf : définition des ressources (VM, réseaux, stockage)

variables.tf / terraform.tfvars : paramétrage dynamique

modules/ : factorisation et réutilisation du code

Rôle : création, modification et suppression reproductibles des VM.

Ansible – Configuration et déploiement applicatif

Le dossier Ansible/ est dédié à la configuration post-déploiement.

inventories/ : définition des hôtes cibles

playbooks/ : scénarios d’installation et de maintenance

roles/ : standardisation des configurations

ansible.cfg : paramètres globaux d’exécution

Rôle : automatiser les configurations, assurer l’homogénéité et le durcissement.

Jenkins – Orchestration CI/CD

Le dossier Jenkins/ contient les pipelines d’orchestration.

jenkinsfile : enchaînement Terraform → Ansible → validation

Rôle : assurer la cohérence des déploiements et la traçabilité.

Logs & traçabilité

Le dossier logs/ centralise les journaux d’exécution :

Retours Terraform

Exécution des playbooks Ansible

Événements du dashboard

Rôle : supervision, audit et diagnostic.

Cette structuration permet une séparation claire des responsabilités, une lecture rapide pour un nouvel intervenant, une évolutivité naturelle du projet ainsi qu’une industrialisation conforme aux bonnes pratiques DevOps.

------------------------------------------------------------