Cet article pose les fondations. Il s’adresse aux professionnels IT qui veulent comprendre les concepts du cloud avant de choisir une plateforme. Pour les aspects pratiques, voir nos tutoriels Proxmox VE et nos articles sur OpenStack.
Le cloud : une question d’architecture, pas de localisation
Le mot cloud désigne un ensemble d’environnements capables d’exploiter du calcul et du stockage, quelle que soit la taille des datacenters concernés. Un cloud peut offrir un très grand nombre de services grâce aux machines virtuelles qui le composent. Ces environnements se regroupent en trois catégories principales.
L’IaaS (Infrastructure as a Service) permet à l’utilisateur de sous-traiter au fournisseur la partie basse de l’environnement : le réseau, le stockage, l’infrastructure matérielle et la virtualisation. Le client conserve le système d’exploitation, la gestion des données et les applications. C’est le modèle qui intéresse directement les équipes infrastructure, car il délimite précisément ce qui reste sous leur responsabilité.
Le PaaS (Platform as a Service) va plus loin : le client sous-traite également le système d’exploitation et les données au fournisseur. Il ne gère plus que ses applications. Le SaaS (Software as a Service) pousse la logique à son terme : l’utilisateur sous-traite l’ensemble du système au fournisseur, y compris ses applications.
Cette hiérarchie n’est pas théorique. Elle détermine la frontière de responsabilité entre l’équipe IT et le fournisseur, et donc le niveau de contrôle que l’organisation conserve sur son infrastructure.
Les classes de datacenters
Les environnements réseau de nouvelle génération sont constitués de datacenters de tailles variées — grands, moyens, petits ou très petits — qui exécutent des machines virtuelles en guise de routeurs ou de commutateurs. Ces datacenters sont reliés entre eux par des canaux de communication à très haut débit : fibre optique dans les centres importants, liaisons hertziennes à la périphérie.
On distingue quatre classes, de la périphérie vers le cœur :
- Skin : les plus petits datacenters, situés au plus près des utilisateurs.
- Fog : capables de gérer de cinquante à mille utilisateurs.
- MEC (Mobile Edge Computing) : capables de gérer de mille à dix mille utilisateurs, placés à proximité des antennes 4G et 5G.
- Cloud : les très grandes infrastructures, capables de gérer simultanément plus de dix mille utilisateurs et pouvant en gérer des millions.
Ces classes ne sont pas normalisées — les définitions varient selon les acteurs — mais elles représentent les grandes tendances architecturales depuis les années 2020. Ce qui les relie toutes, c’est la virtualisation.
La virtualisation : le socle technique du cloud
La virtualisation n’est pas une technique nouvelle. Elle a été introduite sur les premiers gros ordinateurs dans les années 1960, qui utilisaient une mémoire virtuelle — une mémoire qui, au lieu d’être en RAM, se trouvait sur un disque dur. L’astuce était de ramener les pages de mémoire du disque dur sur la mémoire RAM juste avant que l’unité centrale en ait besoin.
La virtualisation du stockage a connu un succès considérable en permettant de regrouper plusieurs serveurs de stockage sur une machine unique, chaque utilisateur ayant pourtant l’impression de disposer d’un serveur distinct. La virtualisation de réseau tient du même principe : plusieurs réseaux virtuels se partagent une même infrastructure physique.
L’avantage de la virtualisation réside dans la possibilité d’implémenter plusieurs systèmes d’exploitation réseau sur une même machine à l’aide d’un hyperviseur. L’architecture d’un serveur de virtualisation se présente en couches : le matériel à la base, l’hyperviseur au-dessus, puis les machines virtuelles qui hébergent chacune leur propre système d’exploitation et leurs applications.
Trois approches de la virtualisation
On compte trois grands types de solutions pour réaliser des systèmes virtuels : la paravirtualisation, la virtualisation de système d’exploitation et l’isolation par conteneur.
La paravirtualisation (hyperviseur de type 1) place l’hyperviseur directement sur le matériel. Les systèmes d’exploitation invités sont modifiés pour s’exécuter directement sur le processeur de l’infrastructure. Dans cette catégorie, on trouve Citrix Xen Server, VMware vSphere, VMware ESX, Microsoft Hyper-V Server, Bare Metal et KVM. L’avantage est une exécution rapide, mais à la condition de modifier certains éléments du système d’exploitation.
L’hyperviseur de type 2 n’est pas placé directement sur le matériel. Il fonctionne comme un logiciel au-dessus du système d’exploitation hôte. Dans cette catégorie : Microsoft VirtualPC, Oracle VM VirtualBox, Parallels Desktop, VMware Workstation, VMware Fusion et QEMU. La performance est moindre, mais la compatibilité est meilleure puisque le système invité n’a pas besoin d’être modifié.
La troisième approche repose sur les conteneurs. Le conteneur contient en lui-même un environnement complet, avec ses pilotes, ses fichiers binaires et ses bibliothèques. Il permet d’isoler l’exécution des applications dans des contextes ou des zones d’exécution séparées. Dans cette catégorie : Docker, Linux-Vserver, chroot, BSD Jail et OpenVZ.
Le réseau virtuel : l’isolation comme principe fondamental
Les ressources d’un même réseau virtuel doivent être totalement isolées des autres réseaux virtuels. L’isolation interdit qu’un paquet puisse passer d’un réseau virtuel à un autre, pour éviter qu’un problème sur un réseau puisse affecter un autre réseau. Le passage ne peut être permis qu’au travers de passerelles externes robustes.
Cela implique une sécurité rigoureuse dans les logiciels de virtualisation : si l’une des machines virtuelles tombe en panne, non seulement cela ne doit pas affecter les autres réseaux, mais les autres machines ne doivent pas même s’en apercevoir.
Des VLANs aux overlays
Le mécanisme historique de segmentation réseau est le VLAN (Virtual LAN). Les VLANs rassemblent des machines dispersées géographiquement dans un réseau et leur permettent de communiquer comme si elles étaient dans un même réseau local. La trame Ethernet est étendue avec un champ TPID (Tag Protocol Identifier) et un champ TCI (Tag Control Information) qui comprend notamment le VLAN ID sur 12 bits — soit 4 096 VLANs possibles au maximum.
Cette limite de 4 096 est devenue un obstacle pour les grands environnements cloud. La réponse est venue avec VXLAN (Virtual eXtensible LAN), qui ajoute un identifiant de 24 bits permettant d’atteindre plus de seize millions de segments virtuels. La trame Ethernet originale est encapsulée dans un message UDP, lui-même transporté dans une trame Ethernet extérieure. Cette surcharge de 50 octets est le prix à payer pour passer de 4 096 à 16 millions de réseaux virtuels.
Le SDN : séparer le contrôle du transport
Le SDN (Software-Defined Networking) correspond à une approche centralisée des réseaux qui consiste à découpler le plan de données et le plan de contrôle. Le plan de données contient les nœuds de transfert qui servent à router ou à commuter les trames. Le plan de contrôle calcule les tables de routage et prend les décisions.
Jusqu’au début des années 2010, ces deux fonctions étaient solidaires et placées dans les nœuds de transfert eux-mêmes. Le SDN les sépare : le plan de contrôle est centralisé dans un contrôleur — une machine physique ou virtuelle dans le cloud — qui dispose d’une puissance de calcul supérieure et d’une vue globale du réseau. Le protocole OpenFlow a été le premier à standardiser cette communication entre le contrôleur et les nœuds de transfert.
Cette séparation est à l’origine des réseaux cloud modernes. OpenStack utilise Neutron pour le réseau, qui repose sur des mécanismes SDN. Proxmox VE 9 propose son propre SDN intégré avec des zones VLAN, VXLAN et EVPN.
Les plateformes de cloud privé
Pour les organisations qui souhaitent conserver le contrôle de leur infrastructure tout en bénéficiant de l’agilité du cloud, deux plateformes open source dominent le paysage du cloud privé.
OpenStack est une plateforme logicielle modulaire déployée comme une IaaS. Elle a débuté en 2010 comme un projet commun de Rackspace et de la NASA. Son architecture repose sur des composants interdépendants : Nova pour le calcul, Neutron pour le réseau, Cinder pour le stockage bloc, Swift pour le stockage objet, Keystone pour l’identité, Glance pour les images, et Horizon pour le tableau de bord. OpenStack s’adresse aux environnements de grande taille (100 à 10 000 nœuds et au-delà) qui nécessitent une multi-tenancy native et une API complète.
Proxmox VE est un hyperviseur KVM avec une couche de gestion intégrée. Il cible les environnements de 1 à 100 nœuds, avec une administration simplifiée et un stockage distribué via Ceph. Proxmox VE ne fournit pas de multi-tenancy native ni de réseau aussi complet que Neutron, mais sa simplicité d’exploitation le rend accessible à des équipes de 1 à 2 administrateurs Linux.
Le choix entre ces deux plateformes dépend de la taille du parc, de la complexité réseau, de l’équipe disponible et du niveau d’automatisation requis. Ce n’est pas un choix technique pur — c’est un choix d’organisation.
Ce que cet article ne traite pas
- La comparaison détaillée entre OpenStack et Proxmox VE (article dédié sur le blog).
- La migration depuis VMware vers une plateforme de cloud privé.
- Le cloud public (AWS, Azure, GCP) et ses modèles de coût.
- La configuration pratique de Proxmox VE ou d’OpenStack (couverts dans nos tutoriels et dans notre programme de formation).
- Le dimensionnement matériel pour un cloud privé (couvert par notre prestation de cloud privé).
Sources : Guy Pujolle, Les Réseaux, 9e édition, Eyrolles. Proxmox VE 9 Administration Guide, pve.proxmox.com. OpenStack Documentation, docs.openstack.org. EC INTELLIGENCE, Formation Administration Proxmox VE 9, janvier 2026.
