Installer Windows dans une VM sur MacBook M1

Vous cherchez à installer Windows VM M1 sur votre Mac Apple Silicon ? La virtualisation Windows sur processeurs ARM64 a beaucoup mûri, et il est désormais possible de faire tourner Windows 11 ARM dans une machine virtuelle performante. Ce tutoriel 2026 couvre les hyperviseurs disponibles, la configuration réseau, les limites concrètes et les alternatives serveur quand la VM locale ne suffit plus.
Comprendre la virtualisation avant d'installer Windows VM M1
Les puces Apple Silicon (M1, M2, M3, M4) reposent sur une architecture ARM64. Contrairement aux Mac Intel, elles ne peuvent pas exécuter nativement une image Windows x86_64. Vous devez donc utiliser Windows 11 on ARM, la seule édition compatible avec la virtualisation sur ce type de matériel.
Pourquoi la version ARM est obligatoire
Un hyperviseur comme le framework Virtualization.framework d'Apple s'appuie sur les instructions de virtualisation matérielle du SoC. Il ne fait pas d'émulation de jeu d'instructions complète. Résultat : lancer une ISO Windows x64 classique échouera ou nécessitera une émulation logicielle lente et instable. Windows 11 ARM, lui, tourne à vitesse quasi native.
Émulation applicative intégrée
Windows 11 ARM embarque une couche de traduction pour exécuter des applications x86 et x64. Cela couvre une large majorité des logiciels bureautiques et métier. En revanche, certains pilotes bas niveau, logiciels de sécurité ou applications utilisant des instructions spécifiques resteront incompatibles.
Ce dont vous avez besoin
- Un Mac Apple Silicon (M1 minimum) avec au moins 16 Go de RAM recommandés.
- 50 Go d'espace disque libre pour un usage confortable.
- Une image disque Windows 11 ARM (VHDX ou ISO officielle Microsoft).
- Un hyperviseur compatible Apple Silicon.
Conseil terrain : privilégiez toujours l'image officielle Microsoft. Les VHDX récupérées sur des sources tierces posent des problèmes d'intégrité et de licence.
Installer Windows VM M1 étape par étape
Il existe plusieurs approches pour installer Windows VM M1 : solutions commerciales clés en main, ou outils open source pour ceux qui veulent maîtriser chaque paramètre. Nous détaillons ici la méthode via un hyperviseur reposant sur QEMU, largement documentée et gratuite.
Étape 1 : récupérer l'image Windows 11 ARM
Téléchargez l'ISO Windows 11 ARM depuis le portail officiel Microsoft. Vérifiez systématiquement l'architecture indiquée (arm64) avant de continuer. La documentation Microsoft détaille les prérequis matériels et les éditions disponibles sur Source.
Étape 2 : installer un hyperviseur
Plusieurs options existent. Pour une approche libre, QEMU compilé pour ARM64 fonctionne parfaitement via Homebrew :
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew install qemu
qemu-system-aarch64 --version
Vous pouvez également passer par une solution avec interface graphique reposant sur le Virtualization.framework d'Apple, plus simple pour un premier essai.
Étape 3 : créer le disque virtuel
Créez un disque au format qcow2 dimensionné selon vos besoins :
qemu-img create -f qcow2 windows11-arm.qcow2 64G
qemu-img info windows11-arm.qcow2
Étape 4 : lancer l'installation
Le démarrage nécessite un firmware UEFI ARM (EDK2) et une déclaration correcte des périphériques. Voici un exemple de commande de boot minimaliste :
qemu-system-aarch64 \
-M virt -accel hvf -cpu host \
-smp 4 -m 8192 \
-bios edk2-aarch64-code.fd \
-drive file=windows11-arm.qcow2,if=virtio \
-cdrom Windows11_ARM.iso \
-device virtio-net-pci,netdev=net0 \
-netdev user,id=net0 \
-device virtio-gpu-pci \
-display default
L'accélérateur hvf active l'Hypervisor.framework d'Apple pour tirer parti de la virtualisation matérielle. Sans lui, les performances s'effondrent.
Étape 5 : configuration post-installation
Une fois Windows installé, appliquez les bonnes pratiques :
- Installez les pilotes virtio pour améliorer réseau et stockage.
- Activez Windows avec une licence valide.
- Créez un snapshot de l'état propre avant toute manipulation lourde.
# Depuis macOS, snapshot du disque qcow2
qemu-img snapshot -c clean-install windows11-arm.qcow2
qemu-img snapshot -l windows11-arm.qcow2
Sécuriser la VM
Même en local, appliquez une hygiène de base côté Windows : pare-feu actif, comptes limités, mises à jour automatiques. Depuis PowerShell dans la VM :
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True
Get-NetFirewallProfile | Select-Object Name,Enabled
Limites d'une VM Windows M1 et quand basculer vers un serveur
Installer Windows VM M1 en local convient parfaitement pour du test, du développement multiplateforme ou de la bureautique ponctuelle. Mais plusieurs limites apparaissent vite dès qu'on vise un usage professionnel continu.
Les contraintes techniques
| Contrainte | Impact |
|---|---|
| Architecture ARM64 uniquement | Certaines applications x86 legacy ne fonctionnent pas via la couche de traduction. |
| Ressources partagées avec macOS | La VM consomme la RAM et le CPU de la machine hôte, limitant le multitâche. |
| Pas de haute disponibilité | Si le Mac s'éteint, la VM tombe. Aucun uptime garanti. |
| Accès distant complexe | Exposer un RDP local en toute sécurité demande beaucoup de configuration réseau. |
| Sauvegardes manuelles | Pas de snapshot managé ni de restauration automatisée par défaut. |
Quand la VM locale ne suffit plus
Dès que vous avez besoin d'un environnement Windows accessible 24/7, joignable depuis plusieurs postes, avec une adresse IP fixe et une bande passante stable, la machine virtuelle sur poste Mac atteint ses limites. C'est typiquement le cas pour :
- Un environnement de build ou de CI Windows disponible en permanence.
- Un poste de travail distant partagé entre plusieurs collaborateurs.
- L'hébergement d'une application métier Windows accessible à distance.
- Des tests d'intégration nécessitant une IP publique stable.
L'alternative : un VPS Windows managé
Un VPS Windows OmegaCloud fournit un environnement RDP prêt à l'emploi avec licence Windows Server incluse, sans dépendre des ressources de votre Mac. Vous bénéficiez d'un stockage SSD SAS, d'un uplink redondant et d'un anti-DDoS volumétrique inclus par défaut au niveau de l'infrastructure, ce qui décharge complètement la mitigation réseau côté client.
La connexion se fait directement depuis le client RDP de macOS ou tout autre poste :
# Test de connectivité RDP depuis macOS
nc -vz mon-vps.omega-cloud.fr 3389
Comparatif neutre : VM locale vs VPS distant
| Critère | VM Windows M1 locale | VPS Windows managé |
|---|---|---|
| Disponibilité | Liée au Mac allumé | 24/7 |
| Ressources | Partagées avec l'hôte | Dédiées à la VM |
| Anti-DDoS | À votre charge | Inclus côté infrastructure |
| Snapshots managés | Manuels via qemu-img | En 1 clic via panel |
| Accès distant | Configuration réseau lourde | RDP prêt à l'emploi |
Automatiser le provisioning
Pour les équipes DevOps, un VPS distant s'intègre aux pipelines existants via les Integrations & API OmegaCloud : API REST, webhooks, et intégration CI/CD avec GitHub Actions ou GitLab CI. On passe alors d'une VM bricolée localement à une infrastructure reproductible et versionnée.
# Exemple d'appel API pour lister ses instances
curl -H "Authorization: Bearer $OMEGA_TOKEN" \
https://api.omega-cloud.fr/v1/instances
Pour des charges Linux annexes (bases de données, reverse proxy, runners), un VPS Linux OmegaCloud complète naturellement l'architecture. Vous retrouverez d'autres guides pratiques sur le Blog OmegaCloud.
Bonnes pratiques de gestion au quotidien
Snapshots et sauvegardes
Que vous restiez en local ou que vous passiez sur un serveur distant, ne travaillez jamais sans point de restauration. En local, scriptez vos snapshots qcow2. Sur un VPS, utilisez les snapshots du panel de gestion pour figer un état stable avant chaque mise à jour majeure.
Sécuriser l'accès RDP
Le port RDP exposé sur Internet est une cible constante. Quelques règles de base :
- Changez le port par défaut ou restreignez l'accès par IP.
- Activez le 2FA au niveau du panel de gestion.
- Utilisez des mots de passe forts et une politique de verrouillage de compte.
- Maintenez Windows à jour en permanence.
# Restreindre RDP à une IP via pare-feu Windows (PowerShell)
New-NetFirewallRule -DisplayName "RDP-Restreint" `
-Direction Inbound -Protocol TCP -LocalPort 3389 `
-RemoteAddress 203.0.113.10 -Action Allow
Surveiller les ressources
En local, surveillez la consommation via le Moniteur d'activité macOS. Sur un serveur distant, un dashboard temps réel CPU/RAM/SSD/réseau vous permet d'anticiper les saturations avant qu'elles n'impactent la production.
Conclusion
Installer Windows VM M1 est aujourd'hui accessible grâce à Windows 11 ARM et aux hyperviseurs compatibles Apple Silicon. Pour le test et le développement, la VM locale fait le travail. Dès que vous visez la disponibilité continue, l'accès distant stable et des sauvegardes fiables, un environnement Windows hébergé prend le relais et simplifie considérablement l'exploitation au quotidien.
FAQ
Peut-on installer Windows x64 classique sur un Mac M1 ?
Non, pas de manière fluide. Les puces Apple Silicon sont en ARM64 et ne virtualisent que Windows 11 ARM. Une ISO x64 nécessiterait une émulation complète du jeu d'instructions, ce qui donne des performances inutilisables. Utilisez toujours l'édition Windows 11 on ARM officielle Microsoft.
Combien de RAM allouer à une VM Windows sur M1 ?
Prévoyez au minimum 4 Go, mais 8 Go offrent une expérience nettement plus confortable. Gardez toujours assez de mémoire pour macOS hôte : sur un Mac 16 Go, allouer 8 Go à la VM reste un bon équilibre. Au-delà, un serveur distant avec ressources dédiées est plus pertinent.
Vaut-il mieux une VM locale ou un VPS Windows pour un usage professionnel ?
Pour un usage ponctuel et du test, la VM locale suffit. Pour un usage professionnel continu nécessitant disponibilité 24/7, IP fixe, RDP sécurisé et snapshots managés, un VPS Windows est plus adapté. Il libère aussi les ressources de votre Mac et intègre l'anti-DDoS côté infrastructure.
Prêt à mettre en pratique ce que vous venez de lire ?
Découvrir nos offres
