TP1 — Reprendre l'infrastructure de Cyclo-Nord

En équipe de 1, 2 ou 3 · 40 points · Dates de remise à venir

Le mandat

Vous êtes le service informatique de Cyclo-Nord, une boutique de vélos. À la semaine 4, vous construisez son infrastructure réseaux sur vos serveurs Proxmox, puis vous la sauvegardez. Entre-temps, Cyclo-Nord rachète Cycles Pignon Sud, un concurrent de la Rive-Sud. Ses deux serveurs, un site web et un serveur de fichiers, tournent sur un hôte VMware ESXi dont la licence est échue. À la semaine 5, vous restaurez Cyclo-Nord, puis vous y faites entrer ces deux serveurs.

Le travail se fait dans les exercices. Le TP le vérifie, à partir de ce que vous déposez dans GitLab et sur place en classe.

Ce que vous apprenez

• Relier des serveurs Proxmox par un switch, et séparer les réseaux de l'entreprise avec des VLAN.
• Isoler un service exposé dans une DMZ, derrière un pare-feu qui n'ouvre que le strict nécessaire.
• Sauvegarder une infrastructure complète, et la reconstruire sur des serveurs effacés.
• Migrer des VM d'un hyperviseur VMware vers Proxmox, et les remettre en service dans un nouveau réseau.
• Documenter une infrastructure pour qu'une autre personne puisse la comprendre et la reprendre.

Le déroulement

Séance	Exercice	Ce qui existe à la fin	Vérifié au
Semaine 4	1 — Switch Cisco	le switch sw-cyclonord transporte les VLAN 10, 20, 30, 460 et 700	jalon 1
Semaine 4	2 — Template cloud-init	le template 9000 sur chaque serveur	jalon 1
Semaine 4	3 — Réseau de Cyclo-Nord	le pare-feu, la base de données et la caisse, une vente encaissée	jalon 1
Semaine 4	4 — Sauvegarde	quatre archives dans le dossier OneDrive de l'équipe	jalon 1
entre les deux	—	les serveurs sont remis à zéro	—
Semaine 5	1 — Remettre Cyclo-Nord en service	les trois VM de Cyclo-Nord restaurées, les ventes retrouvées	jalon 2
Semaine 5	2 — Importer les VM de Pignon Sud	srv-web dans la DMZ, srv-fichiers dans le LAN	jalon 2

Chaque exercice a besoin du précédent. Le pare-feu passe par le switch, les VM sortent du template, et la sauvegarde porte sur ces VM. Un retard sur le switch retarde donc toute la séance.

La remise à zéro entre les deux semaines est sans doute une source de frustration au sein de votre équipe. Je vous invite plutôt à voir cela comme une opportunité de tester et de reconstruire votre infrastructure suite à une panne. Par la répétition, vous ganez en expérience et vous pourrez réutiliser ces techniques une fois en entreprise.

Jalon	Ce qui est évalué	Points
Jalon 1 · semaine 4	dans GitLab : le dépôt, la configuration du switch, le lien vers les sauvegardes de VMs (caisse, db, firewall)	25
Jalon 2 · semaine 5	dans GitLab : la configuration des VM migrées · en classe : le fonctionnement de toute l'infrastructure	15

Le réseau, couche par couche

Un réseau se décrit en couches, comme dans le modèle OSI.

Couche 1 · le câblage

La couche 1, ce sont les câbles et les ports : ce qui est branché où. Votre switch d'équipe, sw-cyclonord, a trois sortes de liens :

• un câble par serveur Proxmox. Un seul suffit, même si le serveur héberge des VM de plusieurs réseaux : c'est la couche 2 qui s'en charge ;
• un câble vers le poste d'un membre, par sa seconde carte réseau. C'est par là que l'équipe entre dans le réseau de l'entreprise ;
• un câble d'uplink vers le switch de la salle, dit top of rack parce qu'il est installé en haut de l'armoire. C'est lui qui relie votre switch au réseau du collège et à Internet.

Les numéros de port sont une suggestion : branchez sur les ports de votre choix, et reportez-les fidèlement dans votre configuration. L'exercice 1 de la semaine 4 en utilise d'autres (uplink sur Gi1/0/1, serveurs sur Gi1/0/2 à 1/0/4, poste sur Gi1/0/5). Ce qui compte, c'est que chaque port soit configuré pour ce qui y est réellement branché.

Le poste a deux cartes, et chacune a son rôle. La carte 1 reste sur la prise du collège : elle porte votre accès à Internet et à l'interface web de Proxmox. La carte 2 est branchée sur le switch de l'équipe : c'est elle qui vous place à l'intérieur du réseau de Cyclo-Nord.

Couche 2 · les VLAN

La couche 2 dit quels réseaux circulent sur chaque câble. Un VLAN découpe un même switch en plusieurs réseaux séparés : une trame du VLAN 20 ne sort jamais par un port réservé au VLAN 30.

Un port se configure de deux façons :

• en trunk, il transporte plusieurs VLAN sur le même câble. Chaque trame porte une étiquette (tag) avec le numéro de son VLAN, pour que l'équipement d'en face sache où la ranger. C'est le cas des câbles vers les serveurs : un seul câble transporte les VLAN 10, 20, 30 et 460 ;
• en accès, il ne transporte qu'un seul VLAN, sans étiquette. L'appareil branché ne sait même pas qu'il est dans un VLAN. C'est le cas du poste, qui ne voit que le LAN.

Lisez la matrice ligne par ligne. Par exemple, la ligne Gi1/0/1 à 1/0/3 dit : ces ports sont en trunk, ils transportent les VLAN 10, 20, 30 et 460 avec une étiquette (T), et le VLAN 700 sans étiquette (U). Chaque case vient d'une ligne précise de configuration :

Ce que dit la matrice	Sur le switch	Dans Proxmox
port en trunk	switchport mode trunk	vmbr0 coché VLAN Aware
VLAN autorisés, étiquetés (T)	switchport trunk allowed vlan 10,20,30,460,700	bridge-vids 10,20,30,460
VLAN natif, sans étiquette (U)	switchport trunk native vlan 700	—
port en accès dans un VLAN	switchport mode access et switchport access vlan 20	le champ VLAN Tag de la carte de la VM

Le VLAN 700 mérite une attention particulière. C'est le VLAN natif : ses trames circulent sans étiquette. C'est grâce à lui que l'interface web de Proxmox reste joignable quand les ports passent en trunk. C'est aussi pourquoi une carte de VM dont le champ VLAN Tag est vide se retrouve dans le réseau de gestion du collège : aucune VM de Cyclo-Nord ne doit y être.

Couche 3 · le réseau logique

La couche 3, ce sont les adresses IP et le routage. Chaque VLAN y devient un segment : un sous-réseau avec sa plage d'adresses. Une machine parle directement aux machines de son segment. Pour atteindre un autre segment, elle passe obligatoirement par sa passerelle.

Le pare-feu fw-cyclonord a une interface dans chacun des trois segments :

Interface	Segment	Adresse	Rôle
vtnet0	WAN · VLAN 460	206.167.46.#/24	la patte Internet, avec l'adresse publique de l'entreprise
vtnet1	LAN · VLAN 20	192.168.20.1/24	la passerelle du LAN
vtnet2	DMZ · VLAN 30	192.168.30.1/24	la passerelle de la DMZ

Comme il est la passerelle de tous les segments, tout ce qui passe d'un segment à l'autre le traverse. C'est ce qui lui permet de décider, avec ses règles, de ce qui passe et de ce qui ne passe pas.

Suivez le trajet d'une vente pour vous en convaincre. Votre navigateur, sur le poste dans le LAN, ouvre la caisse en 192.168.30.10, dans la DMZ : la demande traverse le pare-feu, que la règle du LAN laisse passer. La caisse écrit ensuite la vente sur srv-donnees, en 192.168.20.10:3306, dans le LAN : elle traverse encore le pare-feu, qui n'ouvre que ce port-là vers cette machine-là.

La carte 2 du poste reçoit son adresse du serveur DHCP du pare-feu, avec une passerelle 192.168.20.1. Le poste a alors deux routes par défaut : celle du collège et celle du pare-feu. La métrique de 500 donnée à la carte 2 garantit que la carte 1 reste la sortie par défaut, et une route ajoutée à la main (route -p add 192.168.30.0 ...) envoie vers le pare-feu seulement ce qui va vers la DMZ.

Le plan d'adressage

Les VLAN

VLAN	Nom	Sous-réseau	Passerelle	Qui s'y trouve
10	bureaux	192.168.10.0/24	aucune pour l'instant	personne : prévu pour les postes des employés
20	serveurs (LAN)	192.168.20.0/24	192.168.20.1	srv-donnees, srv-fichiers, votre poste
30	dmz	192.168.30.0/24	192.168.30.1	caisse, srv-web
460	publique	206.167.46.0/24	206.167.46.1	la patte Internet du pare-feu
700	gestion	10.70.0.0/16	fournie par le collège	les serveurs Proxmox, l'hôte ESXi, les iDRAC

Le VLAN 10 existe dans le switch depuis l'exercice 1, mais le pare-feu n'a aucune interface dedans. Un switch se câble une fois pour toute l'entreprise : le VLAN est prêt pour le jour où les postes des employés y seront branchés.

Les adresses suivent une convention simple, la même dans chaque segment : .1 pour la passerelle, .10 et .20 pour les serveurs, .100 à .199 pour les adresses distribuées par DHCP. Une adresse se lit alors d'un coup d'œil : 192.168.30.1, c'est forcément le pare-feu dans la DMZ.

Les machines

Machine	ID	Serveur	VLAN	Adresse	Naît à
sw-cyclonord	—	—	700 natif	aucune, console série	S4 ex. 1
Serveurs Proxmox	—	—	700	10.70.44.#	—
fw-cyclonord	401	serveur 1	460 / 20 / 30	206.167.46.#, 192.168.20.1, 192.168.30.1	S4 ex. 3
caisse	402	serveur 3	30	192.168.30.10/24	S4 ex. 3
srv-donnees	403	serveur 2	20	192.168.20.10/24	S4 ex. 3
srv-web	404	serveur 2	30	192.168.30.20/24	S5 ex. 2
srv-fichiers	405	serveur 2	20	192.168.20.20/24	S5 ex. 2
tmpl-debian13	9000	chaque serveur	—	aucune, jamais démarré	S4 ex. 2
Votre poste · carte 1	—	—	collège	10.80.X.Y, en DHCP	—
Votre poste · carte 2	—	—	20	DHCP du pare-feu, .100 à .199	S4 ex. 3

Les VM sont réparties sur les serveurs de l'équipe, et c'est volontaire : le trafic entre elles traverse réellement le switch que vous avez configuré. Une équipe de deux serveurs place caisse sur le serveur 2. Une équipe d'un seul serveur place toutes les VM sur ce serveur.

Les deux machines de Pignon Sud avaient une autre adresse avant l'import. Comparer l'avant et l'après montre ce qu'une migration doit changer :

Machine	Chez Pignon Sud	Chez Cyclo-Nord	Pourquoi ce déplacement
srv-web	VLAN 460, 206.167.46.29, directement sur Internet	DMZ, 192.168.30.20	un site public est la machine la plus exposée : elle rejoint la caisse, derrière le pare-feu
srv-fichiers	réseau 10.0.0.0/24, qui n'existe pas chez Cyclo-Nord	LAN, 192.168.20.20	le partage contient les clients et la comptabilité : il rejoint la base de données, à l'abri

Qui a le droit de parler à qui

Un pare-feu applique une règle simple : tout ce qui n'est pas écrit est interdit. Chaque autorisation est donc une décision, et la plus étroite possible. C'est le principe du moindre privilège.

De	Vers	Autorisé ?	Pourquoi
LAN	partout	oui	le réseau des employés et des données, considéré comme sûr
DMZ	192.168.20.10, port 3306	oui	la caisse lit sa base de données, et rien d'autre
DMZ	le reste du LAN	non	règle « dmz ne parle pas au lan » : srv-web ne voit pas srv-fichiers
DMZ	Internet	oui	règle « dmz vers internet », pour les mises à jour
Internet	quoi que ce soit	non	la liste des règles WAN est vide

L'ordre des lignes de la DMZ compte : OPNsense lit les règles de haut en bas et applique la première qui correspond. L'ouverture du port 3306 doit donc se trouver au-dessus du blocage vers le LAN, et le blocage au-dessus de l'autorisation vers Internet.

L'intérêt de la DMZ apparaît le jour où une de ses machines est piratée. Un attaquant qui prend le contrôle du site web se retrouve dans un réseau d'où il ne peut atteindre ni le partage de fichiers, ni la base de données, sauf par le seul port que la caisse utilise.

Les notations

Notation	Ce qu'elle désigne	Exemple
#	le numéro d'un serveur Proxmox de l'équipe	serveur 12 : 10.70.44.12
206.167.46.#	l'adresse publique du pare-feu : # est le numéro du serveur qui héberge le pare-feu	pare-feu sur le serveur 12 : 206.167.46.12
10.80.X.Y	l'adresse de la carte 1 de votre poste, donnée par le collège	vous n'y touchez jamais
serveur 29	l'hôte ESXi de Pignon Sud, commun à toute la classe	10.70.44.29, en lecture seule

---

Jalon 1 — Mettre le travail à l'abri

Les serveurs seront remis à zéro avant la semaine 5. Le jalon 1 consiste à sortir d'eux tout ce qu'il faut pour repartir, et à le déposer là où votre équipe et votre enseignant peuvent le retrouver.

Trois choses ne survivraient pas à la remise à zéro : la configuration du switch, les VM, et la mémoire de ce que vous avez construit. Chacune a sa place : le texte de configuration et la documentation dans GitLab, les archives des VM dans OneDrive.

Élément	Points
Le dépôt GitLab et ses accès	5
La configuration du switch Cisco	10
Les sauvegardes et le lien OneDrive	10

1. Le dépôt GitLab

Une équipe informatique travaille dans un dépôt, pas dans une conversation de clavardage. Le dépôt garde chaque version des fichiers, dit qui a changé quoi et quand, et reste accessible à toute l'équipe. C'est là que vit la documentation de l'infrastructure, et c'est là que votre enseignant ira la chercher.

Créez un projet privé sur gitlab.com, avec un compte ouvert à votre adresse du collège. Un seul membre le crée, et les autres y sont ajoutés. Nommez-le tp1-cyclonord-prenom1-prenom2-prenom3, avec les prénoms des membres de l'équipe.

• Settings > General > Visibility : Private. Un dépôt public exposerait le plan de votre réseau au monde entier. La configuration d'une infrastructure ne se publie jamais.
• Manage > Members : tous les membres et votre enseignant, avec le rôle Owner. Votre enseignant vous donne son compte GitLab en classe.

Important

Un dépôt privé auquel votre enseignant n'a pas accès est un dépôt qui n'existe pas. Vérifiez la liste des membres avant de considérer le jalon terminé.

Au jalon 1, le dépôt contient exactement ceci :

Texte

tp1-cyclonord-prenom1-prenom2-prenom3/
├── README.md
└── jalon1/
    ├── README.md
    └── running-config.txt

Le README.md de la racine est la première page que lit quelqu'un qui découvre votre infrastructure. Il donne le nom de chaque membre, les numéros des serveurs de l'équipe, et les VM qui tournent sur chaque serveur. Par exemple :

Markdown

# TP1 — Cyclo-Nord

| Membre | Serveur | Adresse de gestion |
|---|---|---|
| Hakim | serveur 12 | 10.70.44.12 |
| Miguel | serveur 13 | 10.70.44.13 |

| Serveur | VM |
|---|---|
| serveur 12 | 401 fw-cyclonord · 9000 tmpl-debian13 |
| serveur 13 | 403 srv-donnees · 402 caisse · 9000 tmpl-debian13 |

2. La configuration du switch

Le switch est le seul élément de votre infrastructure qui ne se sauvegarde pas avec vzdump. C'est un équipement physique, et sa configuration ne vit que dans sa mémoire : si elle est effacée, personne ne pourra la reconstruire à votre place. Le fichier que vous déposez ici est la seule copie qui existera.

Reprenez la console série du switch, comme à l'exercice 1, et passez en mode privilégié.

Bash

terminal length 0

Bash

show running-config

La première commande empêche le switch de découper sa sortie en pages, qu'il faudrait autrement faire défiler une à une. Copiez toute la sortie dans jalon1/running-config.txt. Dans PuTTY, le clic droit sur la barre de titre donne Copy All to Clipboard, ce qui évite de sélectionner trois écrans à la souris.

Le fichier doit être du texte, pas une capture d'écran. Une configuration en texte se relit, se cherche, se compare d'une version à l'autre, et surtout se recolle dans un switch : c'est exactement ce que vous ferez à la semaine 5 si le switch a été remis à zéro. Une image ne permet rien de tout cela.

Relisez-le avant de le déposer. Il doit contenir :

• les cinq VLAN, avec leur nom : 10 bureaux, 20 serveurs, 30 dmz, 460, 700 ;
• les ports des serveurs en switchport mode trunk, avec native vlan 700 et allowed vlan 10,20,30,460,700 ;
• l'uplink vers la salle des serveurs, en trunk, limité aux VLAN du collège (460,700) ;
• le port du poste en switchport mode access sur le VLAN 20 ;
• le nom du switch, sw-cyclonord.

Chaque port y apparaît sous la forme d'un bloc interface. Celui d'un port de serveur ressemble à ceci :

Texte

interface GigabitEthernet1/0/1
 description serveurs proxmox
 switchport trunk native vlan 700
 switchport trunk allowed vlan 10,20,30,460,700
 switchport mode trunk
 spanning-tree portfast trunk

3. Les sauvegardes et le lien

Une sauvegarde ne compte que si elle existe ailleurs que sur la machine qu'elle protège. Les archives de vzdump sont créées sur le disque des serveurs, qui va être effacé : il faut les en sortir. L'exercice 4 vous a fait les réunir dans un dossier OneDrive partagé. Ce dossier est votre livrable, et le dépôt GitLab en porte le lien.

Le dossier doit contenir les quatre archives suivantes. Vos identifiants de VM peuvent différer.

Machine	ID	Fichier
fw-cyclonord	401	vzdump-qemu-401-<date>.vma.zst
caisse	402	vzdump-qemu-402-<date>.vma.zst
srv-donnees	403	vzdump-qemu-403-<date>.vma.zst
tmpl-debian13	9000	vzdump-qemu-9000-<date>.vma.zst

Chaque archive doit contenir la configuration finale de la VM, celle qui fonctionne. À la semaine 5, vous restaurez ces archives telles quelles : une VM sauvegardée à mi-chemin revient à mi-chemin, et tout ce que vous avez corrigé après la sauvegarde est perdu.

Si vous avez pris des sauvegardes intermédiaires, refaites une sauvegarde une fois la configuration terminée et vérifiée. C'est cette dernière archive qui va dans le dossier OneDrive. Retirez les archives intermédiaires du dossier, pour que personne dans l'équipe ne restaure la mauvaise.

Partagez le dossier avec tous les membres et avec votre enseignant, au minimum en lecture. Si la personne qui détient l'archive du pare-feu est absente la semaine prochaine, le reste de l'équipe doit pouvoir la récupérer.

Écrivez ensuite jalon1/README.md. Il contient le lien, l'inventaire des archives, et la preuve que vous en avez testé une. Par exemple :

Markdown

# Jalon 1 — Sauvegardes

Dossier partagé : <le lien de partage OneDrive>

| Machine | ID | Taille | Date |
|---|---|---|---|
| fw-cyclonord | 401 | 676 Mo | 2026-09-22 |
| caisse | 402 | 1,1 Go | 2026-09-22 |
| srv-donnees | 403 | 1,3 Go | 2026-09-22 |
| tmpl-debian13 | 9000 | 273 Mo | 2026-09-22 |

Restauration testée : la caisse (402) a été détruite puis restaurée,
et la vente d'avant la destruction était toujours dans la base.

Les fichiers .vma.zst ne vont pas dans GitLab. Ils pèsent des centaines de mégaoctets, et un dépôt git est fait pour du texte, pas pour des disques de machines.

Un lien inaccessible équivaut à un livrable manquant

Testez votre lien depuis une fenêtre de navigation privée. Un partage limité à votre seul compte s'ouvre chez vous, et chez personne d'autre.

Avant de remettre le jalon 1

• Le projet GitLab est Private, et tous les membres et l'enseignant sont Owner
• L'arborescence du dépôt est celle demandée
• Le README.md de la racine nomme les membres et donne la répartition des VM
• jalon1/running-config.txt est du texte, complet, et contient les cinq VLAN
• Le dossier OneDrive contient les quatre archives, et son lien s'ouvre en navigation privée
• Chaque archive a été prise après la configuration finale, et la VM fonctionnait à ce moment
• jalon1/README.md contient le lien et l'inventaire des archives

---

Jalon 2 — Migrer et faire fonctionner

Les exercices 1 et 2 de la semaine 5 vous ont fait restaurer Cyclo-Nord, puis importer les deux VM de Pignon Sud. Le jalon 2 vérifie ce travail : une petite partie dans le dépôt, l'essentiel sur place, en classe.

Une migration réussie ne se juge pas à l'import lui-même : l'assistant de Proxmox fait la copie pour vous. Elle se juge au résultat. Les VM tournent-elles sur le bon matériel, dans le bon réseau, et rendent-elles le service qu'elles rendaient chez Pignon Sud, sans ouvrir de brèche dans celui de Cyclo-Nord ?

Élément	Points
Le dépôt à jour	3
La configuration des VM migrées	3
Le fonctionnement, vérifié en classe	9

4. Le dépôt à jour

Le dépôt contient en plus un dossier jalon2/ :

Texte

tp1-cyclonord-prenom1-prenom2-prenom3/
├── README.md
├── jalon1/
│   ├── README.md
│   └── running-config.txt
└── jalon2/
    ├── qm-config-404.txt
    └── qm-config-405.txt

Mettez aussi à jour le README.md de la racine. Il décrit maintenant l'infrastructure complète, avec les deux VM de Pignon Sud : leur ID, leur serveur, leur VLAN et leur adresse. Une documentation qui décrit encore l'état d'avant la migration est pire que pas de documentation : la prochaine personne qui la lira se fiera à des adresses qui n'existent plus.

5. La configuration des VM migrées

La configuration d'une VM dit, en quelques lignes, sur quel matériel virtuel elle tourne et dans quel réseau elle est branchée. C'est la preuve la plus directe que la migration est allée au bout.

Dans le Shell du serveur qui héberge les deux VM :

Bash

qm config 404

Bash

qm config 405

Copiez chaque sortie dans jalon2/qm-config-404.txt et jalon2/qm-config-405.txt. Le Shell du nœud permet de sélectionner le texte et de le copier, contrairement à la console d'une VM.

Chaque fichier doit contenir, entre autres, des lignes comme celles-ci :

Texte

agent: 1
net0: virtio=00:0c:29:69:48:3e,bridge=vmbr0,tag=30
scsi0: local-lvm:vm-404-disk-0,size=2G
scsihw: virtio-scsi-single

Ligne	Ce qu'elle prouve
scsihw: virtio-scsi-single	le contrôleur de disque VMware (pvscsi) a été remplacé par VirtIO
net0: virtio=...	la carte réseau VMware (vmxnet3) a été remplacée par VirtIO. L'adresse MAC commence par 00:0c:29, le préfixe de VMware : c'est bien la VM d'origine
tag=30 ou tag=20	la carte est dans le bon VLAN : la DMZ pour srv-web, le LAN pour srv-fichiers
agent: 1	l'agent QEMU est activé, à la place des outils de VMware
scsi0 et scsi1	pour 405 seulement : le disque système et le disque de données du partage

6. La vérification en classe

Votre enseignant vérifie votre infrastructure sur place, avec vous, à la fin de la séance de la semaine 5. Toute l'équipe doit être présente, et les cinq VM doivent tourner. C'est l'élément qui compte le plus : une infrastructure bien documentée qui ne fonctionne pas ne rend aucun service à l'entreprise.

Chaque vérification prouve une chose précise. Faites-les toutes vous-mêmes avant de faire venir votre enseignant.

Ce qui est vérifié	Comment le répéter avant	Ce que cela prouve
Le site de Pignon Sud répond dans la DMZ	ouvrir http://192.168.30.20 depuis votre poste	srv-web a la bonne adresse, dans le bon VLAN, et nginx tourne
Le partage est accessible depuis le LAN	sur srv-donnees : sudo mount -t nfs 192.168.20.20:/srv/partage /mnt, puis cat /mnt/LISEZMOI.txt	srv-fichiers est dans le LAN, et /etc/exports autorise le nouveau réseau
La DMZ n'atteint pas le partage	dans la console de srv-web : ping -c 2 -W 2 192.168.20.20 doit rester sans réponse	le pare-feu isole la DMZ du LAN, même pour la nouvelle VM
Cyclo-Nord fonctionne toujours	encaisser une vente sur http://192.168.30.10, puis la retrouver dans la base sur srv-donnees	la restauration est complète, et la migration n'a rien cassé
L'agent QEMU répond	l'adresse des VM 404 et 405 apparaît dans leur panneau Summary	les outils de VMware ont été remplacés, et Proxmox communique avec les VM

Pendant la vérification, chaque membre doit pouvoir montrer et expliquer une partie de ces résultats.

Avant la vérification

• Le README.md de la racine décrit l'infrastructure complète, avec srv-web et srv-fichiers
• jalon2/qm-config-404.txt et jalon2/qm-config-405.txt montrent VirtIO, le bon tag et l'agent
• Les cinq VM tournent : fw-cyclonord, caisse, srv-donnees, srv-web et srv-fichiers
• Vous avez fait vous-mêmes chacune des cinq vérifications, et chaque membre sait en expliquer une
• Le stockage ESXi a été retiré de Proxmox