Ventoy transforme une clé USB en support multiboot : vous installez l’outil une seule fois, puis vous copiez vos fichiers ISO dessus comme de simples fichiers. Là où Rufus écrit une seule image et reformate la clé à chaque changement, Ventoy affiche au démarrage un menu listant toutes les images présentes. Sous Linux, l’installation passe par le script Ventoy2Disk.sh exécuté en root.
Ce guide couvre l’installation en ligne de commande, mais aussi deux points que la documentation francophone laisse de côté : ce que le mode Secure Boot de Ventoy fait réellement, et la question de confiance soulevée par les binaires précompilés du projet.
L’essentiel
Commande clé :sudo sh Ventoy2Disk.sh -i /dev/sdX
Prérequis : une clé USB (son contenu sera effacé), un accès root, l’archive officielle
Version traitée : Ventoy 1.1.17, publiée le 24 juillet 2026
Couverture : toutes les distributions — l’archive officielle ne dépend d’aucun gestionnaire de paquets
Vérifié le 14 septembre 2026 : commandes exécutées sur Ventoy 1.1.17, sauf mention contraire
Prérequis
| Élément | Détail |
|---|---|
| Clé USB | 8 Go minimum en pratique, davantage selon le nombre d’images. Tout son contenu sera effacé en installation standard |
| Droits | Accès root (sudo) |
| Archive | ventoy-1.1.17-linux.tar.gz, 19 Mo |
| Temps | 10 minutes pour l’installation, plus la copie des images |
| Connaissances | Savoir identifier un périphérique disque et accéder au menu de démarrage de votre machine |
Étape 1 : télécharger l’archive et vérifier son empreinte
Le site officiel signale que son hébergement est sous-dimensionné et renvoie vers SourceForge. Quelle que soit la source, contrôlez l’empreinte SHA-256 du fichier reçu : Ventoy s’exécute avant le système d’exploitation, et une archive altérée s’exécuterait avec ce niveau de privilège.
Téléchargez ventoy-1.1.17-linux.tar.gz depuis la page de téléchargement officielle, puis vérifiez-le :
# Contrôler qu'il s'agit bien d'une archive, et non d'une page HTML
file ventoy-1.1.17-linux.tar.gz
# Calculer l'empreinte SHA-256
sha256sum ventoy-1.1.17-linux.tar.gz
La commande file doit répondre gzip compressed data. Si elle répond HTML document, votre navigateur a enregistré une page web au lieu du fichier : recommencez le téléchargement.
L’empreinte publiée par le projet pour cette version est :
7fb4ed08cef6a6b4d39dd19260d8c80291a78dfdf9af7d461571e23cbbc43805
Les deux chaînes doivent être identiques, caractère pour caractère. Si elles diffèrent, n’allez pas plus loin et retéléchargez l’archive.
# Décompresser
tar -xzf ventoy-1.1.17-linux.tar.gz
cd ventoy-1.1.17
Étape 2 : identifier la bonne clé USB
C’est l’étape où une erreur coûte cher. Le script écrit directement sur le périphérique que vous lui désignez, sans deuxième chance.
Avertissement
Se tromper de périphérique à l’étape suivante écrase la table de partition du disque désigné et détruit les données qu’il contient. Un disque système ou un disque de sauvegarde branché au même moment est une cible aussi valide qu’une clé USB aux yeux du script. Vérifiez deux fois, et débranchez les disques externes dont vous n’avez pas besoin.
La méthode fiable consiste à comparer la liste des périphériques avant et après avoir branché la clé.
# Clé débranchée
lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,MODEL
Branchez la clé, attendez deux secondes, relancez la même commande. La ligne apparue est votre clé. Sa taille doit correspondre à celle annoncée sur l’emballage, à la conversion près.
Voici à quoi ressemble la sortie, à titre d’exemple — les noms et modèles diffèrent forcément chez vous :
NAME SIZE TYPE MOUNTPOINT MODEL
sda 238,5G disk Samsung SSD 860
├─sda1 1G part /boot/efi
└─sda2 237,5G part /
sdb 28,9G disk SanDisk Ultra
└─sdb1 28,9G part /media/vasco/CLE
Ici, la clé est /dev/sdb — le disque entier, pas la partition /dev/sdb1. C’est bien le périphérique sans numéro que le script attend.
Si la clé est montée automatiquement, démontez-la avant de continuer :
sudo umount /dev/sdb1
Étape 3 : installer Ventoy sur la clé
Le script s’exécute en root et prend une commande, éventuellement des options, puis le périphérique.
sudo sh Ventoy2Disk.sh -i /dev/sdb
Le script demande deux confirmations successives avant d’écrire, la seconde étant libellée Double-check. Une mise à jour par -u n’en demande qu’une. Voici les commandes et options que la documentation officielle expose :
| Commande | Effet |
|---|---|
-i |
Installe Ventoy. Échoue si la clé contient déjà Ventoy |
-I |
Force l’installation, que Ventoy soit déjà présent ou non |
-u |
Met à jour Ventoy sur la clé, sans toucher aux fichiers |
-l |
Affiche les informations Ventoy de la clé |
| Option | Effet |
|---|---|
-s |
Active explicitement la prise en charge du Secure Boot. Déjà active par défaut depuis la version 1.0.76 |
-S |
Désactive la prise en charge du Secure Boot. Absente de la page « Get Started » du site officiel |
-g |
Utilise une table de partition GPT au lieu de MBR. À l’installation uniquement |
-r TAILLE_MIO |
Réserve un espace non alloué (en Mio) en fin de disque. À l’installation uniquement |
-L |
Définit le nom de la première partition exFAT. « Ventoy » par défaut |
-n |
Tente une installation non destructive. À l’installation uniquement |
Sur une machine récente en UEFI, vous pouvez demander une table de partition GPT :
sudo sh Ventoy2Disk.sh -i -g /dev/sdb
Inutile d’ajouter -s : la prise en charge du Secure Boot est déjà active par défaut. Lisez la section qui lui est consacrée avant d’installer sur une machine où le Secure Boot est activé : son comportement par défaut n’est pas celui que l’on attend.
Une fois l’installation terminée, la clé porte deux partitions : une grande partition de données en exFAT, et une petite partition VTOYEFI de 32 Mo qui contient les fichiers de démarrage. Vous pouvez reformater la partition de données en NTFS, FAT32, UDF, XFS ou Ext2/3/4 si exFAT ne vous convient pas.
Étape 4 : copier les fichiers ISO
Il n’y a rien de particulier à faire : vous copiez les images sur la première partition, comme sur n’importe quelle clé. Ventoy parcourt récursivement tous les répertoires et liste alphabétiquement les images trouvées.
# Monter la partition de données si l'environnement ne l'a pas fait
sudo mkdir -p /mnt/ventoy
sudo mount /dev/sdb1 /mnt/ventoy
# Copier une image
sudo cp ~/Téléchargements/linuxmint-22.2-cinnamon-64bit.iso /mnt/ventoy/
# Vider les tampons avant de débrancher
sync
Les formats acceptés sont ISO, WIM, IMG, VHD(x) et EFI. Vous pouvez organiser les fichiers en sous-dossiers sans rien configurer.
Si vous hésitez sur les images à embarquer, notre comparatif des distributions Linux passe en revue les principales familles et leurs usages. Pour une première clé de dépannage, Linux Mint constitue un point de départ sûr, à compléter éventuellement par une distribution légère si vous intervenez sur des machines anciennes.
Étape 5 : démarrer sur la clé
Redémarrez en sélectionnant la clé dans le menu de démarrage de la machine. La touche varie selon le constructeur : F12 chez Dell et Lenovo, F9 chez HP, F8 ou Échap ailleurs. Le menu Ventoy s’affiche alors et liste vos images.
Sélectionnez une image avec les flèches, validez avec Entrée : Ventoy démarre l’image comme si elle avait été écrite seule sur la clé.
Vérifier que tout fonctionne
Trois contrôles suffisent à confirmer que l’installation est correcte :
# 1. Ventoy est bien détecté sur la clé
sudo sh Ventoy2Disk.sh -l /dev/sdb
# 2. Les deux partitions existent
lsblk /dev/sdb
Le troisième contrôle est le seul qui compte vraiment : démarrez effectivement une image depuis le menu. Une clé qui affiche le menu mais échoue à lancer une image signale généralement une image corrompue, pas un problème de Ventoy.
Ce que le Secure Boot de Ventoy fait vraiment
C’est le point le plus souvent survolé dans les tutoriels, et celui qui mérite votre attention.
Ventoy prend en charge le Secure Boot depuis la version 1.0.07 selon la FAQ officielle, mais c’est depuis la 1.0.76 que cette prise en charge est active par défaut : vous n’avez rien à ajouter à la commande d’installation. L’option -s ne fait que l’activer explicitement ; c’est -S, en majuscule, qui la désactive.
Un avertissement s’impose ici, car la documentation officielle se contredit. La page « Get Started » indique encore default is disabled et ne mentionne pas -S : elle n’a pas suivi le changement. La page consacrée au Secure Boot, elle, écrit correctement que la prise en charge existe par défaut depuis la 1.0.76. C’est le code du script d’installation qui tranche : la variable interne passe de désactivée à activée entre les étiquettes 1.0.75 et 1.0.76 du dépôt, et reste activée en 1.1.13 comme en 1.1.17.
Vous pouvez le constater sur votre propre clé. Après une installation faite sans aucune option, interrogez-la :
sudo sh Ventoy2Disk.sh -l /dev/sdb
La sortie affiche Secure Boot Support : YES. Relancez l’installation avec -S, et la même commande affichera NO.
Techniquement, Ventoy s’appuie sur un shim emprunté à Rocky Linux, signé par les autorités de certification UEFI 2011 et 2023. GRUB2, sur lequel Ventoy repose, est sous licence GPL et ne peut pas être signé directement.
Au premier démarrage sur une machine où le Secure Boot est actif, le shim ne reconnaît pas le GRUB de Ventoy et lance MokManager. Vous devez alors enrôler manuellement la clé de Ventoy, opération à faire une seule fois par machine. Le certificat ENROLL_THIS_KEY_IN_MOKMANAGER.cer se trouve à la racine de la partition VTOYEFI.
Depuis Ventoy 1.1.13, vous devez enrôler une nouvelle clé en raison du changement d’autorité de certification UEFI CA 2023. Une clé enrôlée avec une version antérieure ne suffit plus.
Vient ensuite le point décisif, écrit noir sur blanc dans la documentation officielle mais rarement repris :
La politique par défaut de Ventoy contourne totalement le Secure Boot.
Une fois la clé enrôlée, Ventoy démarre n’importe quel fichier EFI sans aucune vérification de signature. Autrement dit, un Secure Boot activé dans le firmware ne protège plus rien tant que vous démarrez via Ventoy.
Ce comportement est délibéré : il permet à Ventoy de démarrer des images non signées, ce qui est précisément l’usage attendu. Mais il faut le savoir, en particulier sur une machine d’entreprise où le Secure Boot est censé constituer une garantie.
Pour rétablir la vérification, définissez VTOY_SECURE_BOOT_POLICY à 1 dans le plugin de contrôle global — 0 correspond au contournement, 1 à l’application de la politique UEFI. Certaines fonctions de Ventoy cessent alors de fonctionner, puisque seules les images signées par les autorités officielles démarrent.
Ce réglage se place dans le fichier /ventoy/ventoy.json, sur la première partition de la clé. L’emplacement compte, et la documentation est stricte : le fichier doit se trouver dans le répertoire ventoy de la première partition, sans sous-répertoire, et les noms de répertoires et de fichiers sont sensibles à la casse. Un fichier placé ailleurs n’est tout simplement pas lu, rien ne vous le signale avant le démarrage, et vous croiriez avoir rétabli la vérification alors que le contournement resterait actif. Le menu F5 Tools de Ventoy permet de contrôler le fichier une fois la clé démarrée.
{
"control": [
{ "VTOY_SECURE_BOOT_POLICY": "1" }
]
}
L’utilitaire VentoyPlugson, fourni par le projet, génère ce fichier graphiquement si vous préférez éviter l’édition manuelle.
Deux cas particuliers à connaître : certaines machines exigent d’activer l’option « Allow Microsoft 3rd Party UEFI CA » dans le firmware. Et si, au lieu de l’écran bleu d’enrôlement, vous obtenez un écran d’erreur, la solution de Ventoy n’est pas compatible avec votre matériel : il faut alors réinstaller Ventoy avec l’option -S, qui désactive sa prise en charge du Secure Boot, puis désactiver le Secure Boot dans le firmware.
Peut-on faire confiance à Ventoy ?
La question mérite d’être posée pour un outil qui s’exécute avant le système d’exploitation, et elle fait l’objet d’un débat réel dans la communauté. Elle reste rarement traitée en français ; voici les faits, datés.
Le 3 avril 2024, dans la foulée de la porte dérobée découverte dans XZ Utils, un contributeur ouvre l’issue #2795, « Remove BLOBs from the source tree ». Il y relève que le dépôt de Ventoy contient plus de binaires précompilés que de code source, et que les instructions de compilation fournies ne garantissent pas d’obtenir les mêmes exécutables. Le point sensible tient à ce que Ventoy s’exécute au niveau de l’amorçage : un binaire compromis y disposerait d’un privilège maximal.
Le mainteneur du projet a pris le sujet à son compte. C’est lui qui a ouvert, le 7 mai 2025, l’issue #3224 « About the BLOBs in Ventoy » — non pas comme réponse défensive, mais comme inventaire de transparence, treize mois après l’alerte initiale. L’issue #2795 a depuis été close comme doublon de celle-ci. Il y recense les fichiers binaires du projet : busybox, cryptsetup, dmsetup, fichiers EFI, pilotes noyau FreeBSD, exécutables graphiques. Sa position est que Ventoy est intégralement open source et qu’« everything is transparent », ces binaires provenant d’autres projets open source.
Le 14 mai 2025, une mise à jour de cette même issue annonce l’ajout du fichier BLOB_List.md au dépôt. Il documente, pour chaque binaire, son origine — compilé localement ou récupéré en amont — et les instructions de compilation ou le lien de téléchargement avec vérification d’empreinte. Il recense 182 entrées au 14 septembre 2026.
Où en est-on en septembre 2026 ? Le dossier n’est pas clos. La traçabilité s’est nettement améliorée grâce à BLOB_List.md : 162 entrées y sont assorties d’instructions de compilation, et 20 correspondent à des binaires repris tels quels à des projets amont — BusyBox, imdisk, memdisk de Syslinux, 7-Zip, un noyau TinyLinux, dmsetup issu de DragonFly BSD. Pour la plupart, l’URL et l’empreinte sont consignées. L’exception notable est la chaîne d’amorçage UEFI 32 bits (BOOTIA32.EFI, grubia32.efi, mmia32.efi), reprise du projet tiers Super-UEFIinSecureBoot-Disk avec une simple URL et sans empreinte documentée. Documenter n’est d’ailleurs pas reconstruire : rien n’établit que ces compilations aient été rejouées et qu’elles redonnent les binaires distribués. Aucun calendrier n’a été annoncé.
Ce que cela implique concrètement, selon votre usage :
| Situation | Recommandation |
|---|---|
| Usage personnel, installation de distributions, dépannage | Le risque est théorique et non démontré. Vérifiez l’empreinte SHA-256 à chaque téléchargement et utilisez Ventoy sans inquiétude particulière |
| Environnement professionnel avec politique de sécurité stricte | Faites valider l’outil par votre équipe sécurité. L’impossibilité de reconstruire tous les binaires depuis les sources est un point bloquant dans certains référentiels |
| Machine traitant des données sensibles | Écrivez une image unique avec un outil dont la chaîne de compilation est entièrement reproductible, plutôt qu’un multiboot |
Aucun incident de sécurité public lié à ces binaires n’est connu à ce jour. Il ne s’agit pas d’une vulnérabilité, mais d’un défaut de vérifiabilité — une distinction qui compte.
Ventoy ou Rufus : lequel choisir
Les deux outils répondent à des besoins différents, et le choix ne se joue pas sur la qualité.
| Critère | Ventoy | Rufus |
|---|---|---|
| Nombre d’images par clé | Plusieurs, limitées par la capacité | Une seule |
| Ajout d’une image | Copie de fichier, sans reformatage | Réécriture complète de la clé |
| Disponible sous Linux | Oui, natif | Non, Windows uniquement |
| Clé utilisable comme stockage | Oui, la partition reste accessible | Non en pratique |
| Options spécifiques Windows | Limitées | Nombreuses, dont le contournement des prérequis Windows 11 |
| Secure Boot | Contournement total par défaut | Respecte la signature de l’image écrite |
| Traçabilité des binaires du projet | Dossier ouvert, documenté depuis mai 2025 | Pas de dossier équivalent connu |
Le verdict par usage. Si vous jonglez entre plusieurs distributions, dépannez des machines ou testez régulièrement des systèmes, Ventoy fait gagner un temps considérable et c’est le bon choix. Si vous préparez une installation Windows unique depuis Windows, en particulier avec des ajustements de prérequis, Rufus reste plus adapté. Si vous travaillez sous Linux, la question ne se pose pas vraiment : Rufus n’y est pas disponible.
Installer Ventoy sans effacer la clé
L’installation standard formate la clé. Si elle contient déjà des données que vous ne voulez pas déplacer, Ventoy propose une installation non destructive avec l’option -n, à combiner avec -i ou -I.
sudo sh Ventoy2Disk.sh -i -n /dev/sdb
Cette option n’apparaît pas dans le bloc d’aide de la page d’installation, mais elle est documentée sur la page dédiée. Elle impose plusieurs conditions sous Linux :
- une entrée libre dans la table de partition — quatre partitions déjà présentes en MBR, ou 128 en GPT, rendent l’opération impossible ;
- une première partition démarrant à 1 Mo ;
- une première partition en NTFS, ce qui suppose le paquet
ntfs-3g, ou en Ext2/3/4, ce qui supposee2fsprogs; - de l’espace libre dans cette première partition, ou au moins 32 Mo non alloués juste après elle.
Le secteur d’amorçage et le premier mégaoctet du disque sont malgré tout réécrits. N’utilisez donc pas cette option sur un disque portant un chargeur d’amorçage, et sauvegardez les données importantes avant de commencer : la documentation elle-même qualifie cette fonction d’expérimentale.
Les variantes : interface graphique et interface web
Si la ligne de commande ne vous convient pas, Ventoy fournit deux interfaces graphiques sous Linux.
L’interface native, disponible depuis la version 1.0.52, se lance directement depuis le dossier décompressé :
./VentoyGUI.x86_64
Des variantes existent pour i386, ARM64 et MIPS64. Ventoy choisit automatiquement entre GTK et QT selon les bibliothèques présentes sur le système.
L’outil a besoin des droits root pour écrire sur la clé. La documentation officielle donne la commande sans sudo — lancer une application graphique avec sudo échoue d’ailleurs sur certaines sessions Wayland. Si le programme ne démarre pas ou refuse d’écrire, revenez au script Ventoy2Disk.sh, que la documentation présente elle-même comme la solution de repli en cas de problème.
L’interface web, disponible depuis la version 1.0.36, convient notamment aux serveurs sans environnement graphique :
sudo bash VentoyWeb.sh
Ouvrez ensuite http://127.0.0.1:24680 dans un navigateur. Vous pouvez écouter sur une autre adresse avec -H, et changer de port avec -p en minuscule, pour piloter l’installation depuis une autre machine. Attention : la documentation officielle écrit -P en majuscule, mais le script ne reconnaît que -p. Passer -P 8080 ne provoque aucune erreur et laisse le serveur sur le port 24680. Quittez avec Ctrl+C dans le terminal.
Sous Windows, l’équivalent est Ventoy2Disk.exe, fourni dans l’archive ventoy-1.1.17-windows.zip. L’interface propose les mêmes options, dont le Secure Boot via le menu Option.
Mettre à jour Ventoy sans perdre ses images
La mise à jour ne touche pas aux fichiers de la première partition. Téléchargez la nouvelle archive, vérifiez son empreinte, puis :
sudo sh Ventoy2Disk.sh -u /dev/sdb
Si vous utilisez le Secure Boot et que vous passez à une version 1.1.13 ou supérieure depuis une version antérieure, prévoyez de réenrôler la clé au prochain démarrage.
Désinstaller Ventoy et récupérer la clé
Ventoy ne fournit pas de commande de désinstallation : les commandes documentées se limitent à l’installation, la mise à jour et l’affichage d’informations. Pour rendre la clé à un usage normal, vous effacez les signatures de système de fichiers et vous recréez une partition, avec les outils standard de Linux.
Avertissement
wipefs -aefface les signatures présentes sur le périphérique que vous désignez — ici la table de partition de la clé, ce qui rend ses partitions et leurs données inaccessibles. Se tromper de périphérique inflige exactement cela au disque visé par erreur. Revérifiez la sortie delsblkjuste avant d’exécuter la commande.
# Démonter toutes les partitions de la clé
sudo umount /dev/sdb*
# Effacer les signatures
sudo wipefs -a /dev/sdb
# Recréer une table de partition et une partition unique
sudo parted /dev/sdb --script mklabel msdos mkpart primary fat32 1MiB 100%
# Formater
sudo mkfs.vfat -F 32 -n CLE /dev/sdb1
Erreurs courantes
La clé n’est pas détectée par l’outil d’installation
Un processus occupe le périphérique. Démontez toutes ses partitions avec sudo umount /dev/sdb* et fermez les gestionnaires de fichiers ou utilitaires de disque ouverts. Sous Windows, la documentation cite nommément Paragon ExtFS et DiskGenius comme sources de blocage.
Le menu Ventoy ne s’affiche pas, un shell GRUB apparaît
La documentation officielle retient deux causes : une clé USB défaillante, ou une limitation d’accès mémoire du BIOS en mode Legacy. Testez la clé sur une autre machine pour départager. Si elle fonctionne ailleurs, la limitation du firmware est en cause.
« secure boot violation, invalid signature detected »
Cette erreur signale que l’enrôlement de la clé n’a pas abouti. Vérifiez d’abord que Ventoy n’a pas été installé avec l’option -S, qui désactive la prise en charge du Secure Boot : par défaut, celle-ci est active. Vérifiez ensuite que le fichier ENROLL_THIS_KEY_IN_MOKMANAGER.cer est bien à la racine de la partition VTOYEFI. Si l’écran d’enrôlement ne s’affiche jamais, le matériel n’est pas compatible avec la solution : désactivez le Secure Boot dans le firmware.
Une image Windows 7 ne démarre pas
Il manque généralement le pilote USB 3.0 dans l’image, sans lequel l’installateur ne reconnaît pas le support. Le problème vient de l’image, pas de Ventoy.
Le menu met longtemps à s’afficher
Trop de fichiers sur la partition ralentissent le balayage. Limitez la recherche à un répertoire précis via le fichier /ventoy/ventoy.json de la première partition, plutôt que de laisser l’outil parcourir toute la clé.
La persistance : garder ses modifications d’une session à l’autre
Ventoy permet de conserver les modifications faites dans une session live, sans créer de partition dédiée. Le principe repose sur un fichier image de persistance associé à une image donnée.
La création du fichier passe par un script fourni dans l’archive :
sudo bash CreatePersistentImg.sh -s 4096 -t ext4 -l casper-rw
Le fichier obtenu se place sur la première partition, puis s’associe à l’image concernée dans /ventoy/ventoy.json — le même emplacement imposé que pour le plugin de contrôle, et la même sanction silencieuse en cas d’erreur de chemin. L’utilitaire graphique VentoyPlugson simplifie nettement cette configuration.
Le libellé dépend de la distribution : casper-rw pour Ubuntu et ses dérivées, d’autres valeurs ailleurs. Ubuntu, Linux Mint, MX Linux, elementary OS, Kali, Fedora, CloneZilla et Kaspersky Rescue Disk figurent parmi les systèmes pris en charge. À noter : seul ext4 permet de réduire le fichier sans le détruire, XFS ne le permet pas.
Questions fréquentes
Ventoy est-il gratuit ?
Oui. Ventoy est un logiciel libre et gratuit, sans version payante ni fonctionnalité réservée.
Quelle taille de clé USB faut-il prévoir ?
Comptez la somme de vos images plus une marge. Une clé de 32 Go accueille confortablement quatre à six distributions et un outil de dépannage. En dessous de 8 Go, l’intérêt du multiboot s’amenuise.
Ventoy accepte-t-il les images Windows ?
Oui, aux formats ISO et WIM, au même titre que les images Linux. Les deux types cohabitent sur la même clé.
Peut-on continuer à utiliser la clé comme stockage normal ?
Oui. La première partition reste une partition de données classique : vous y copiez des fichiers quelconques sans perturber le fonctionnement de Ventoy.
Ventoy fonctionne-t-il depuis un Mac ?
Le projet ne fournit pas d’outil d’installation pour macOS. Vous pouvez préparer la clé depuis Linux ou Windows, puis démarrer dessus sur un Mac Intel. Sur les Mac à puce Apple, le démarrage sur un support externe de ce type n’est pas pris en charge.
Conclusion
Une clé Ventoy correctement installée remplace une pile de clés à usage unique : vous copiez une image, elle apparaît au menu, et la clé reste utilisable comme stockage. Sous Linux, l’opération tient en une commande, et la mise à jour ultérieure ne détruit rien.
Deux points méritent votre vigilance, et ils sont rarement énoncés. La prise en charge du Secure Boot, active par défaut, n’est pas une protection : elle permet à Ventoy de démarrer malgré le Secure Boot du firmware, puis de ne plus vérifier aucune signature. Et la question des binaires précompilés, si elle reste théorique pour un usage personnel, justifie un examen sérieux en environnement professionnel.
Une fois la clé prête, reste à choisir ce que vous y mettez : notre guide pour remplacer Windows 10 ou 11 par une distribution Linux aide à cadrer ce choix, et CachyOS mérite une place sur la clé si vous voulez évaluer une distribution orientée performances.
Comment ces commandes ont été vérifiées
| Élément | Niveau | Vérification |
|---|---|---|
| Empreinte SHA-256 de l’archive 1.1.17 | Testé | Archive officielle téléchargée le 14/09/2026 et empreinte recalculée avec sha256sum : elle correspond caractère pour caractère à la valeur publiée |
Commandes et options de Ventoy2Disk.sh |
Testé | Sortie de sh Ventoy2Disk.sh -h exécutée sur la version 1.1.17 réelle le 14/09/2026. Elle expose -S et -n, tous deux absents de la page « Get Started » |
Secure Boot actif par défaut, rôle de -s et -S |
Testé | Installation sans option, puis -l : « Secure Boot Support : YES ». Réinstallation avec -S : « NO ». Le code du script situe la bascule à la version 1.0.76, comparé aux étiquettes 1.0.75, 1.0.76, 1.1.13 et 1.1.17 |
| Installation et structure de la clé | Testé | Installation exécutée le 14/09/2026 sur un périphérique bloc de test : deux partitions créées, la première en exFAT nommée « Ventoy », la seconde nommée VTOYEFI de 33 554 432 octets, soit exactement 32 Mio |
Option -g et style de partition par défaut |
Testé | Réinstallation avec -g puis -l : « Disk Partition Style : GPT ». Sans l’option, MBR |
Certificat ENROLL_THIS_KEY_IN_MOKMANAGER.cer |
Testé | Présent à la racine de la partition VTOYEFI après installation, 1 420 octets, listé le 14/09/2026 |
Commandes wipefs -a, parted et mkfs.vfat de la désinstallation |
Testé | Exécutées le 14/09/2026 : wipefs -a efface la signature MBR, parted recrée une table msdos avec partition démarrant à 1 Mio, et mkfs.vfat -F 32 -n CLE produit un FAT32 confirmé par blkid |
Format de sortie de lsblk et contrôle par file |
Testé | Exécutées le 14/09/2026 : les colonnes correspondent à l’exemple donné, et file distingue bien gzip compressed data d’un HTML document |
Option de port de VentoyWeb.sh |
Testé | Exécuté le 14/09/2026 : -p 9999 démarre le serveur sur http://127.0.0.1:9999, tandis que -P 9999 le laisse sur 24680 sans aucun message. La documentation officielle écrit pourtant -P |
| Nombre de confirmations à l’installation | Testé | Exécuté le 14/09/2026 : deux invites successives, Continue? (y/n) puis Double-check. Continue? (y/n). Une seule réponse laisse la clé intacte. La mise à jour par -u n’en demande qu’une |
Emplacement /ventoy/ventoy.json |
Conforme à la documentation officielle | Pages « Plugin Entrypoint » et « Global Control Plugin », lues le 14/09/2026 |
| Contournement du Secure Boot par la politique par défaut | Conforme à la documentation officielle | Page « About Secure Boot » et fichier SecureBoot.md du dépôt, lus le 14/09/2026 |
| Enrôlement d’une nouvelle clé depuis la 1.1.13 | Conforme à la documentation officielle | Page « About Secure Boot », lue le 14/09/2026 |
| Conditions de l’installation non destructive | Conforme à la documentation officielle | Page « Non-destructive Installation », lue le 14/09/2026. Option non exécutée |
| Causes des erreurs courantes | Conforme à la documentation officielle | FAQ officielle et forum Ventoy, consultés le 14/09/2026 |
| Dossier des binaires précompilés | Sources primaires | Issue GitHub #3224 et fichier BLOB_List.md, consultés le 14/09/2026. Le fichier compte 182 entrées à cette date, dont 162 assorties d’instructions de compilation et 20 reprises à des projets amont |
| Démarrage réel sur une machine, écran MokManager, enrôlement | Non testé | Ces étapes exigent une clé USB physique et un redémarrage. Elles reproduisent la documentation officielle |
Les lignes marquées « testé » ont été réellement exécutées sur la version 1.1.17, un périphérique bloc de test tenant lieu de clé USB. Ce banc ne permet pas de redémarrer une machine : tout ce qui relève du démarrage effectif reste établi sur la documentation. Si vous constatez un écart avec le comportement observé sur votre matériel, signalez-le : la correction sera apportée et datée.
