Installer Proxmox VE 9 sur une Debian 13 existante

Proxmox VE n'est pas un système d'exploitation séparé : c'est un ensemble de paquets posés sur une Debian, et vous pouvez donc l'installer sur une Debian 13 déjà en place. Cette voie s'impose quand vous ne maîtrisez pas l'amorçage de la machine, chez un hébergeur qui vous livre un système préinstallé ou dans un lab monté depuis une image cloud (une image disque préconfigurée, démarrée telle quelle). Elle est aussi reproductible, sans console graphique à piloter. En échange, elle vous demande quatre gestes que l'installateur ISO fait sans le dire : rendre le nom du nœud résoluble, ajouter le dépôt et vérifier sa clé, installer le noyau avant les paquets, et créer le pont vmbr0 pour y déplacer l'adresse du serveur. L'image cloud du banc de cette leçon (la machine de test sur laquelle la procédure a été rejouée) y ajoute quatre pièges dont aucun ne nomme sa cause.

Ce que vous allez apprendre

Niveau : Intermédiaire

À la fin de cette leçon, vous saurez :

• Décider si la voie Debian convient à votre situation, ou s'il vaut mieux l'ISO
• Ajouter le dépôt pve-no-subscription en vérifiant sa clé de signature au lieu de la recopier
• Installer le noyau Proxmox, redémarrer dessus, puis installer les paquets
• Monter le pont vmbr0 et y déplacer l'adresse du serveur sans perdre la main
• Reconnaître les quatre pièges d'une image cloud et appliquer leur parade

Prérequis

Cette leçon suppose une Debian 13 trixie sur laquelle vous avez un accès root ou sudo, et un accès de secours indépendant du réseau que vous allez modifier, console série ou console de l'hyperviseur hôte. Elle suppose aussi que vous savez ce qu'est un pont réseau : comprendre le réseau Proxmox le pose, et choisir son stockage vous aide à décider où iront les disques des machines virtuelles.

Les versions de cette page ont été relevées sur un banc le 28 octobre 2026 : Debian 13 trixie, noyau Proxmox 7.0.14-26-pve, proxmox-ve 9.2.0, pve-manager 9.2.24, ifupdown2 3.3.0-1+pmx12.

Faut-il choisir cette voie, ou l'ISO ?

L'ISO reste la voie normale, et cette page ne la remplace pas. L'installateur officiel partitionne, pose le noyau, crée le pont et génère le certificat en une passe : tout ce que cette leçon vous fait faire à la main, il le fait sans vous le dire. Choisissez donc la voie Debian quand l'ISO est impossible ou inutilisable, pas quand elle est simplement moins commode.

Votre situation	La voie à prendre
Serveur physique dont vous contrôlez l'amorçage	l'ISO officielle
Hébergeur qui livre une Debian préinstallée, sans console d'amorçage	cette page
Machine virtuelle montée depuis une image cloud	cette page
Besoin d'un partitionnement que l'installateur ne propose pas	cette page
Installation reproductible sur un serveur physique	l'entrée Install Proxmox VE (Automated) de l'ISO

Glissez pour voir

La documentation de Proxmox est explicite sur ce point : elle recommande l'installateur et ne décrit la voie Debian que pour les cas particuliers. Gardez-le en tête si vous hésitez, et faites au moins une fois l'installation par l'ISO : c'est celle que vous retrouverez devant un vrai serveur.

Qu'est-ce qui change avec une image cloud ?

Une image cloud n'est pas une Debian installée à la main, et c'est la source des quatre pièges de cette page. C'est une image disque préparée pour démarrer sans intervention, que le service cloud-init configure au démarrage. Elle fait donc des choix que la procédure officielle ne connaît pas. Voici ce que montre un relevé du 28 octobre 2026 sur l'image cloud Debian 13 du banc, avant toute installation (une autre image peut différer) :

Ce que l'image du banc fait	Ce que Proxmox attend
le réseau est confié à systemd-networkd	la configuration dans /etc/network/interfaces, lue par ifupdown
/etc/network/interfaces n'existe pas du tout	ce fichier, que l'interface web lit et écrit
cloud-init réécrit /etc/hosts à chaque démarrage	une entrée stable qui résout le nom du nœud
grub-cloud-amd64 sert à la fois les machines BIOS et UEFI	un chargeur d'amorçage sans ambiguïté

Glissez pour voir

Ces écarts, auxquels s'ajoute un nom de machine qui résout vers une adresse de lien local, produisent quatre pannes, et elles partagent un trait qui vaut d'être dit avant de les lire : aucune ne nomme sa cause. Le message affiché désigne à chaque fois autre chose que le problème réel, et deux d'entre elles se cachent derrière les premières. Les parades sont données au fil de la procédure, à l'endroit exact où le piège se déclenche.

Étape 1 : rendre le nom du nœud résoluble

Le nom de la machine doit résoudre (se traduire en adresse IP) vers une adresse routable, sinon pve-cluster ne démarrera pas, et le message d'erreur ne parlera pas de résolution de noms. C'est le prérequis que la documentation de Proxmox place en tête, et sur l'image cloud du banc il n'est pas satisfait : le nom pointe vers une adresse de boucle locale.

hostname --ip-address
# 127.0.1.1    <- refusé par Proxmox

Regardez aussi ce que rend le nom court, car c'est celui que Proxmox utilisera pour son certificat :

getent ahosts "$(hostname -s)"
# fe80::5054:d5ff:feb0:10 pve    <- une adresse IPv6 de lien local

Cette réponse en fe80:: est le quatrième piège, et il frappera à l'étape 7. Sur le banc, /etc/nsswitch.conf portait hosts: files myhostname resolve [!UNAVAIL=return] dns, qui consulte files puis myhostname : faute d'entrée dans /etc/hosts pour le nom court, c'est myhostname qui répond, et il rend l'adresse de lien local de l'interface.

Écrivez donc une entrée qui porte l'adresse, le nom qualifié et le nom court, les trois sur la même ligne :

ADRESSE=$(ip -4 -brief addr show enp1s0 | awk '{print $3}' | cut -d/ -f1)
COURT=$(hostname -s)
cat > /etc/hosts <<EOF
127.0.0.1  localhost
$ADRESSE  $COURT.lab $COURT

::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
EOF

Remplacez .lab par votre domaine réel, et enp1s0 par le nom de votre interface. Vérifiez ensuite les trois résultats, pas seulement le premier :

hostname --ip-address        # doit rendre l'adresse du serveur
hostname -f                  # doit rendre le nom qualifié, sans domaine répété
getent ahosts "$(hostname -s)"   # ne doit plus rendre d'adresse fe80::

Avec cloud-init, cette correction ne survivra pas au redémarrage

Sur l'image du banc, /etc/hosts portait un en-tête qui l'annonçait, manage_etc_hosts as True : cloud-init réécrit le fichier à chaque démarrage, et la procédure vous fera redémarrer à l'étape 3. La parade est donnée à l'étape 4, parce qu'elle se vérifie après le redémarrage. Si votre Debian a été installée à la main, ce piège ne vous concerne pas.

Étape 2 : ajouter le dépôt en vérifiant sa clé

Comparer une empreinte recopiée depuis une page web ne vérifie rien : il faut contrôler le fichier que vous venez de télécharger contre une somme publiée, puis laisser apt vérifier les signatures. Téléchargez la clé, puis comparez sa somme SHA-256 à celle que publie la documentation de Proxmox.

wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg \
     -O /usr/share/keyrings/proxmox-archive-keyring.gpg

sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg
# 136673be77aba35dcce385b28737689ad64fd785a797e57897589aed08db6e45

Cette somme a été vérifiée le 28 octobre 2026 et elle correspondait. Si la vôtre diffère, arrêtez-vous : n'ajoutez pas le dépôt et reprenez le téléchargement depuis la documentation officielle.

Déclarez ensuite le dépôt au format deb822, celui que Debian 13 utilise. Le champ Signed-By lie le dépôt à cette clé précise, ce qui vaut mieux qu'une clé acceptée globalement :

cat > /etc/apt/sources.list.d/pve-install-repo.sources <<'EOF'
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

apt update && apt full-upgrade

Le apt update doit récupérer les métadonnées du dépôt sans erreur de signature. S'il se plaint d'une clé, c'est le chemin de Signed-By qu'il faut relire, pas la clé qu'il faut réimporter.

Étape 3 : installer le noyau, puis redémarrer dessus

L'ordre compte, et c'est le geste que l'on saute le plus souvent : le noyau Proxmox s'installe seul, on redémarre dessus, et seulement ensuite on installe les paquets. Les installer d'affilée laisse la machine sur le noyau Debian, donc sans les modules dont QEMU et LXC ont besoin.

apt install proxmox-default-kernel

C'est ici que le premier piège se déclenche sur une image cloud. Sur le banc, l'installation du noyau a tiré grub-pc en dépendance automatique, le chargeur des machines BIOS, et sa configuration échoue parce qu'aucun disque ne lui est désigné :

You must correct your GRUB install devices before proceeding:
  DEBIAN_FRONTEND=dialog dpkg --configure grub-pc
dpkg: error processing package grub-pc (--configure)

Ne vous arrêtez pas à l'apparence de l'échec. Le noyau Proxmox, lui, est installé et configuré : GRUB a été régénéré, les entrées de menu créées, et la machine redémarrera bien sur le noyau Proxmox. Ce qui est cassé, c'est l'état de dpkg : grub-pc reste en échec de configuration, et tous les apt suivants refuseront de travailler avant qu'on s'en occupe.

dpkg -l | grep '^iF'
# iF  grub-pc    <- un paquet installé mais non configuré

La parade consiste à installer le chargeur EFI véritable, qui remplace grub-pc :

# Uniquement si la machine démarre en UEFI : /sys/firmware/efi existe
apt install grub-efi-amd64
dpkg -l | grep '^iF'   # ne doit plus rien afficher

Sur une machine réellement en BIOS, ne faites pas cela : grub-pc y est le bon paquet, et il faut au contraire lui désigner son disque avec dpkg-reconfigure grub-pc. Notez que grub-cloud-amd64, le paquet qui crée l'ambiguïté, est resté installé sur le banc : il n'a pas été nécessaire de le retirer pour que l'installation aboutisse.

Quand dpkg -l | grep '^iF' ne rend plus rien, redémarrez, puis vérifiez que la machine tourne bien sur le noyau Proxmox :

systemctl reboot
# après la reconnexion
uname -r    # doit se terminer par -pve

La documentation demande ensuite de retirer le noyau Debian, ce qui évite de redémarrer dessus par accident :

apt remove linux-image-amd64 'linux-image-6.12*'
update-grub

La commande update-grub suppose que vous démarrez avec GRUB : la documentation la déclare inutile avec systemd-boot, une voie que cette page ne traite pas.

La documentation recommande aussi de retirer os-prober (apt remove os-prober), qui scanne toutes les partitions de l'hôte. Sur l'image du banc, ce paquet n'était pas installé : si c'est aussi votre cas, la commande répondra qu'il n'y a rien à retirer, et c'est normal.

Étape 4 : reprendre la résolution de noms après le redémarrage

Le redémarrage que l'étape 3 impose vient de défaire le prérequis de l'étape 1. Vérifiez-le avant toute chose, parce que l'erreur qu'il provoque n'apparaîtra qu'à l'étape 5 :

hostname --ip-address
# 127.0.1.1    <- revenu, alors que vous l'aviez corrigé

Si la bonne adresse est toujours là, cloud-init ne gère pas votre /etc/hosts et vous pouvez passer à l'étape 5. Sinon, c'est le deuxième piège : cloud-init a réécrit /etc/hosts au démarrage, à partir d'un gabarit qu'il rejoue chaque fois. Modifier /etc/hosts ne sert donc à rien : c'est le gabarit qu'il faut corriger.

cat /etc/cloud/templates/hosts.debian.tmpl
# 127.0.1.1 {{fqdn}} {{hostname}}

Deux détails de ce gabarit expliquent la panne de l'étape 7, et ils ne se devinent pas. D'abord, les deux variables ne contiennent pas le nom court : sur le banc, {{fqdn}} valait pve.lab.lab et {{hostname}} valait pve.lab, si bien que le nom pve n'apparaissait dans aucune entrée. Ensuite, c'est /etc/hosts qui détermine la réponse de hostname -f : avec cette ligne, le nom qualifié devenait pve.lab.lab, le domaine en double.

Écrivez donc le gabarit avec les trois formes, en clair :

ADRESSE=$(ip -4 -brief addr show enp1s0 | awk '{print $3}' | cut -d/ -f1)
COURT=$(hostname -s)
cat > /etc/cloud/templates/hosts.debian.tmpl <<TMPL
## template:jinja
127.0.0.1 localhost
$ADRESSE $COURT.lab $COURT

::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
TMPL

# Appliquer sans attendre un redémarrage
cloud-init single --name update_etc_hosts --frequency always

Contrôlez de nouveau les trois résultats de l'étape 1. Le nom court doit rendre l'adresse du serveur, et hostname -f un nom qualifié sans domaine en double. Une autre voie existe, poser manage_etc_hosts: false, mais elle est sans effet quand le user-data du fournisseur d'image impose la valeur contraire : dans la priorité documentée de cloud-init, le user-data l'emporte sur /etc/cloud/cloud.cfg.d. Le gabarit, lui, reste lu tant que manage_etc_hosts est actif.

Étape 5 : installer Proxmox VE

Avec un nom résoluble et un noyau Proxmox au démarrage, l'installation des paquets se déroule sans surprise.

apt install proxmox-ve postfix open-iscsi chrony

postfix vous demandera un type de configuration : choisissez Local only si la machine n'envoie pas de courrier, ou Satellite system si vous avez déjà un serveur de messagerie. chrony tient l'horloge, ce qui compte dès qu'un cluster entre en jeu.

Vérifiez les trois services qui portent l'interface et l'API, puis la version obtenue :

systemctl is-active pve-cluster pvedaemon pveproxy
# active
# active
# active

pveversion
# pve-manager/9.2.24/66bc407c6d90a67a (running kernel: 7.0.14-26-pve)

Si pve-cluster refuse de démarrer sur ipcc_send_rec[1] failed: Connection refused, reprenez l'étape 1, et l'étape 4 si cloud-init réécrit votre /etc/hosts : la documentation de Proxmox renvoie à /etc/hosts pour ce message, et la résolution du nom est la première cause à écarter.

Étape 6 : monter le pont vmbr0

Proxmox raccorde les machines virtuelles au réseau par un pont, et l'adresse du serveur doit vivre sur ce pont, pas sur la carte physique. Une installation posée sur Debian garde son adresse sur la carte tant qu'on ne fait rien, et aucune machine virtuelle ne pourra sortir.

Écrivez la configuration ifupdown complète, en remplaçant le nom de la carte, l'adresse et la passerelle par ceux de votre machine. La carte physique passe en manual et devient un port du pont :

/etc/network/interfaces

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

iface enp1s0 inet manual

auto vmbr0
iface vmbr0 inet static
    address 10.10.113.11/24
    gateway 10.10.113.1
    bridge-ports enp1s0
    bridge-stp off
    bridge-fd 0

proxmox-ve installe ifupdown2 (dépendance de pve-manager), qui sait appliquer une nouvelle configuration à chaud, sans redémarrer. C'est précisément ce qu'il faut ici, car un redémarrage qui se passe mal vous laisserait sans réseau.

ifreload -a
ip -brief a show vmbr0

Lisez le code de retour de ifreload -a et la sortie d'ip, pas le fichier : si vmbr0 est absent, la configuration est écrite mais n'a jamais été appliquée.

C'est ici que le troisième piège se déclenche, et son message est franchement trompeur :

error: Another instance of this program is already running.

Aucune instance ne tourne. ifupdown2 pose son verrou dans /run/network/.lock, et sur le banc ce répertoire n'existait pas (l'image confie le réseau à systemd-networkd, mais ce qui crée d'ordinaire ce répertoire n'a pas été établi). Dans le code d'ifupdown2, l'échec d'ouverture du verrou est rapporté comme un conflit, ce qui envoie chercher un processus concurrent inexistant. La parade tient en une commande :

mkdir -p /run/network
ifreload -a        # rend 0, et le pont monte

Basculez ensuite le gestionnaire de réseau, après avoir constaté que le pont porte bien son adresse et jamais avant :

ip -4 -brief a show vmbr0     # doit afficher l'adresse du serveur
systemctl disable --now systemd-networkd.socket systemd-networkd
systemctl enable --now networking

Ne coupez jamais le gestionnaire de réseau avant la preuve

Couper systemd-networkd avant que vmbr0 ne porte son adresse rend la machine injoignable, et il faut alors la console de secours pour la récupérer. L'ordre est donc : écrire la configuration, appliquer à chaud, vérifier, puis basculer. Sur une machine distante, gardez une session ouverte pendant l'opération : elle peut survivre à la bascule, et vous donner de quoi revenir en arrière.

Étape 7 : ouvrir l'interface web

L'interface répond en HTTPS sur le port 8006, avec un certificat que Proxmox génère lui-même au nom du nœud.

curl -sk -o /dev/null -w '%{http_code}\n' https://127.0.0.1:8006/
# 200

Si le port est ouvert mais que la réponse vaut 000, le premier suspect est le quatrième piège, celui annoncé à l'étape 1, qui s'est refermé sur le banc. Le journal le dit, à condition de le lire :

journalctl -u pveproxy -n 20
# /etc/pve/local/pve-ssl.pem: failed to use local certificate chain

Sur le banc, la cause était une chaîne en trois maillons, qui mérite d'être comprise une fois pour toutes : le nom court du nœud résout vers une adresse IPv6 de lien local, Proxmox la place dans le SAN du certificat (Subject Alternative Name, la liste des noms et adresses que le certificat déclare valides) avec son identifiant de portée, et openssl la refuse.

bad ip address:value=fe80::5054:d5ff:feb0:10%vmbr0
unable to generate pve certificate request

Le certificat n'est donc jamais produit, pveproxy démarre quand même, écoute sur son port, et ne sert rien. Corrigez la résolution du nom court comme aux étapes 1 et 4, puis demandez la régénération :

pvecm updatecerts --force
systemctl restart pveproxy

Connectez-vous enfin sur https://ADRESSE:8006, avec le royaume PAM et le compte root de la machine. Le navigateur signalera un certificat auto-signé : c'est normal à ce stade, et servir l'interface en HTTPS vérifié relève de la leçon suivante sur l'interface web.

Dépannage

Les quatre pannes de cette page ont en commun de désigner autre chose que leur cause, et ce tableau les relie à leur parade. Il compte sept symptômes, dont certains sont des conséquences ou des voisins de ces quatre pannes. Lisez la colonne du milieu avant d'agir : chaque correction tient en une ou deux commandes, à condition de viser la cause réelle et non le message affiché.

Symptôme	Cause réelle	Correction
You must correct your GRUB install devices	proxmox-default-kernel a tiré grub-pc, sans disque désigné	apt install grub-efi-amd64 en UEFI, dpkg-reconfigure grub-pc en BIOS
Un apt refuse de travailler après l'installation du noyau	un paquet est resté en échec de configuration	dpkg -l | grep '^iF' pour le nommer, puis traiter ce paquet
ipcc_send_rec[1] failed: Connection refused	le plus souvent, le nom du nœud ne résout pas vers une adresse routable	corriger /etc/hosts, ou le gabarit de cloud-init s'il le réécrit, puis cloud-init single --name update_etc_hosts --frequency always
hostname --ip-address est revenu à 127.0.1.1	cloud-init a réécrit /etc/hosts au démarrage	corriger /etc/cloud/templates/hosts.debian.tmpl, pas /etc/hosts
error: Another instance of this program is already running	sur le banc, /run/network/ n'existait pas et le verrou ne pouvait pas être posé	mkdir -p /run/network, puis ifreload -a
Le port 8006 est ouvert et la réponse vaut 000	sur le banc, le certificat n'a pas pu être généré, SAN en fe80::	corriger la résolution du nom court, puis pvecm updatecerts --force
vmbr0 absent après un ifreload qui a échoué	la configuration est écrite mais jamais appliquée	vérifier le code de retour de ifreload -a, ne pas se fier au fichier

Glissez pour voir

Mettre en pratique

Le lab du catalogue ne vous livre pas un Proxmox prêt à l'emploi : il vous remet une Debian 13 nue, conforme au cahier des charges, et c'est vous qui installez l'hyperviseur dessus en suivant cette leçon. Il note l'état de la machine, poste par poste, et non les commandes que vous avez tapées : une installation menée autrement que par le chemin décrit ici, mais qui atteint le même résultat, passe tout aussi bien.

Les six postes notés sont la présence de Proxmox, sa version majeure, les trois services, la réponse de l'interface web, le pont vmbr0 porteur de l'adresse, et le dépôt sans abonnement. Les quatre pièges de cette page se dressent tous sur ce parcours : c'est leur raison d'être.

Lab guidé Pratique

Apprendre à faire

Vérifier votre installation de Proxmox face au cahier des charges

$ dsoxlab run verifier-son-installation

Environnement : VM·Durée : ~30 min

Vérification : l'état de la machine est vérifié, pas la commande tapée.

Première fois ? Qu'est-ce que DSOXLab et comment l'installer

DSOXLab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Il faut Python 3.11 ou plus récent, uv ou pipx, et git. Le guide d'installation détaille ces prérequis ; sous Windows, ou sur un Mac sans Python, passez plutôt par l'appliance.

Ce lab démarre des machines virtuelles : il demande en plus ansible-playbook, un hyperviseur (KVM ou Incus), Terraform et la virtualisation matérielle (/dev/kvm), c'est-à-dire, dans une VM VirtualBox, la virtualisation imbriquée. La première fois, dsoxlab start verifier-son-installation vérifie tout cela avant de créer les machines. Préparer le poste pour les labs vm.

Installer la CLI et brancher le catalogue, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
dsoxlab catalog add https://github.com/stephrobert/proxmox-dsoxlab-training

Avant de lancer le lab, vérifiez :

• DSOXLab installé
• catalogue disponible
• environnement compatible (shell isolé ou VM)

Pour le vérifier, rien n'est sondé depuis cette page : lancez dsoxlab doctor. Lire le diagnostic

Lancer ce lab, puis valider votre travail :

dsoxlab run verifier-son-installation
dsoxlab check verifier-son-installation

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress. Le guide complet de dsoxlab détaille le calcul du score et les pièges.

À retenir

Ces points résument la voie Debian et les quatre pièges qu'une image cloud y ajoute, chacun vérifié sur un banc le 28 octobre 2026.

1. L'ISO reste la voie normale : la voie Debian sert quand l'amorçage ne vous appartient pas, ou quand vous voulez un partitionnement particulier
2. Le nom du nœud doit résoudre vers une adresse routable, nom qualifié et nom court, sinon pve-cluster échoue sur un message qui ne parle pas de résolution
3. La clé du dépôt se vérifie par sa somme SHA-256, comparée à celle de la documentation, et Signed-By la lie à ce seul dépôt
4. L'ordre est noyau, redémarrage, puis paquets : les enchaîner laisse la machine sur le noyau Debian ; et grub-pc peut arriver avec le noyau Proxmox et rester en échec de configuration, ce qui bloque les apt suivants sans empêcher le noyau de s'installer
5. cloud-init réécrit /etc/hosts à chaque démarrage : on corrige le gabarit /etc/cloud/templates/hosts.debian.tmpl, jamais le fichier
6. L'erreur de verrou de ifreload ne parle pas de verrou : sur le banc, /run/network/ manquait, et mkdir -p a suffi
7. Un port ouvert ne prouve pas un service servi : une réponse 000 sur 8006 peut venir d'un certificat absent, à cause d'une adresse de lien local dans le SAN
8. L'adresse vit sur le pont, et on ne coupe le gestionnaire de réseau qu'après avoir vu vmbr0 porter cette adresse

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

8 questions

8 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →