Windows 11 Pro pour développeurs

Choisissez WSL 2 ou une machine virtuelle complète selon vos besoins

Pour un environnement de développement principalement sous Linux, déterminez si vous avez besoin d’applications Linux intégrées à Windows ou d’un système d’exploitation invité géré de manière indépendante. WSL 2 exécute un noyau Linux dans une machine virtuelle gérée et convient à de nombreux outils en ligne de commande, environnements d’exécution de langages et conteneurs Linux. Une machine virtuelle Hyper-V complète vous offre un contrôle plus précis sur la configuration du système invité, le réseau virtuel et les points de contrôle. Privilégiez cette solution si la reproduction de serveurs complets ou le test de modifications du système d’exploitation compte davantage que la simplicité d’intégration au système hôte.

La compatibilité des conteneurs est une question distincte du choix de l’édition de Windows. Les conteneurs Linux nécessitent un environnement Linux ; les conteneurs Windows dépendent de la compatibilité entre les versions de l’hôte Windows et des images, avec des exigences variables selon le mode d’isolation. Un projet utilisant Docker Desktop avec son moteur WSL 2 ne nécessite pas automatiquement le rôle Hyper-V complet. Consultez également les conditions d’abonnement propres à Docker Desktop : l’achat de Windows Pro n’accorde aucun droit d’utilisation commerciale de Docker Desktop et ne supprime pas ses exigences de licence liées à votre organisation.

• Vérifiez si les images de conteneurs de votre projet ciblent Linux ou Windows.
• Utilisez une machine virtuelle complète pour tester la configuration de démarrage, le réseau du système invité ou des déploiements de serveurs complets.
• Conservez les dépôts utilisés principalement sous Linux dans le système de fichiers WSL lorsque les outils Linux effectuent la majorité des opérations sur les fichiers.
• Vérifiez les exigences actuelles de Docker Desktop en matière de plateforme et d’abonnement, indépendamment des licences Windows.

Vérifiez le matériel et installez l’environnement de développement avant la migration

Avant d’acheter une mise à niveau vers une autre édition, vérifiez la configuration de votre ordinateur plutôt que de supposer que toutes les fonctionnalités de virtualisation fonctionneront. Dans le Gestionnaire des tâches, ouvrez Performances et sélectionnez Processeur pour vérifier si la virtualisation est activée. Dans les paramètres du micrologiciel, l’option correspondante peut s’appeler Intel Virtualization Technology ou AMD SVM. Hyper-V nécessite également un processeur compatible avec la traduction d’adresses de second niveau et d’autres fonctionnalités matérielles. Exécutez systeminfo pour consulter les exigences Hyper-V indiquées ; lorsqu’un hyperviseur est déjà actif, le résultat peut simplement signaler sa détection.

Pour une nouvelle installation de WSL sur une installation Windows 11 prise en charge, ouvrez un terminal en tant qu’administrateur et exécutez wsl --install, puis redémarrez si vous y êtes invité. Créez le compte utilisateur Linux au premier lancement de la distribution. Exécutez wsl --update et consultez les résultats de wsl --status et wsl --list --verbose avant d’installer vos outils de développement. Si Windows s’exécute lui-même dans une autre machine virtuelle, vérifiez que l’hyperviseur hôte expose la virtualisation imbriquée ; changer uniquement l’édition de Windows ne peut pas fournir les fonctionnalités de processeur virtuel manquantes.

• Sauvegardez les dépôts, les clés SSH et les bases de données locales avant toute modification majeure de l’environnement.
• Vérifiez l’espace de stockage disponible pour les distributions, les images de conteneurs, les caches de compilation et les disques des machines virtuelles.
• Vérifiez que la virtualisation est activée dans le micrologiciel avant de rechercher un problème dans les fonctionnalités Windows.
• Utilisez wsl --list --online pour consulter les distributions disponibles.
• Testez le VPN, le DNS et l’accès aux registres de paquets privés avant de migrer votre travail quotidien.

Configurez des environnements de test jetables sans exposer les identifiants des développeurs

Windows Sandbox est utile pour les tests en environnement jetable, mais sa configuration par défaut n’équivaut pas à un laboratoire hors ligne d’analyse de logiciels malveillants. Le réseau et la redirection du presse-papiers sont activés par défaut : vérifiez donc ces paramètres avant d’ouvrir un exécutable non fiable. Un fichier de configuration .wsb permet de désactiver le réseau et la redirection du presse-papiers, ainsi que de mapper un dossier de l’hôte en lecture seule. Évitez d’exposer votre profil utilisateur, votre copie de travail du code source ou les répertoires contenant des identifiants. La fermeture de Sandbox supprime son état interne, mais ne peut pas annuler les modifications effectuées via des dossiers de l’hôte mappés avec un accès en écriture.

Le chiffrement des disques répond à une autre menace : l’exposition des données en cas de perte ou de vol d’un appareil ou d’un disque. Il n’empêche pas les logiciels exécutés sous votre compte connecté de lire les fichiers auxquels ce compte a accès. Pour les ordinateurs portables des développeurs, conservez les informations de récupération en lieu sûr, séparément de l’appareil chiffré, et vérifiez où se trouve la clé de récupération avant de modifier le micrologiciel ou la configuration de démarrage. Ne placez pas les identifiants d’accès aux dépôts ni les clés de signature dans des environnements jetables, et remplacez tout secret exposé accidentellement pendant les tests.

• Utilisez un dossier d’entrée dédié contenant uniquement les fichiers nécessaires au test.
• Configurez les dossiers mappés en lecture seule, sauf si l’accès en écriture est indispensable.
• Désactivez le réseau de Sandbox lorsque le test ne nécessite pas d’accès à Internet.
• Ne collez pas de jetons de production, de mots de passe ni d’éléments de signature dans les sessions de test.
• Traitez le chiffrement, les sauvegardes et la gestion des secrets comme des mesures de protection distinctes.

Distinguez l’activation de l’hôte, les licences Windows des machines virtuelles et les droits d’utilisation de l’IDE

Une licence Windows Pro ne couvre pas automatiquement toutes les machines virtuelles Windows que vous créez. Selon les conditions standard de Microsoft pour les licences Windows vendues au détail, la licence autorise une instance sur l’appareil sous licence, qu’elle soit physique ou virtuelle ; les instances Windows supplémentaires nécessitent généralement leurs propres licences, sauf si un autre contrat accorde les droits nécessaires. Les règles de transfert dépendent également du canal d’acquisition : un logiciel autonome acheté au détail peut généralement être transféré dans les limites prévues par les conditions, tandis qu’un logiciel préinstallé ne peut généralement être transféré qu’avec l’appareil auquel sa licence est liée. La réussite de l’activation ne prouve pas, à elle seule, que vous disposez des droits d’utilisation.

Les licences Visual Studio sont distinctes des licences Windows, et Professional n’est pas obligatoire pour tous les projets commerciaux. Visual Studio Community permet aux développeurs individuels de créer des applications gratuites ou payantes. Pour les organisations, ses conditions distinguent l’utilisation hors des grandes entreprises de l’utilisation au sein de celles-ci, avec des exceptions spécifiques pour des activités telles que l’enseignement en classe, la recherche universitaire et la contribution à des projets open source. Vérifiez les conditions en vigueur au regard de votre organisation, et pas seulement de la taille de votre équipe. Un abonnement Visual Studio peut inclure des avantages pour le développement et les tests, mais ceux-ci sont soumis à des restrictions distinctes.

• Consultez les conditions de licence Windows applicables sur microsoft.com/useterms.
• Déterminez si la licence envisagée est une licence vendue au détail, préinstallée/OEM ou fournie dans le cadre d’un contrat d’organisation.
• Recensez les systèmes invités Windows ainsi que les installations physiques lorsque vous vérifiez la couverture des licences.
• Ne considérez pas les droits de développement et de test comme une autorisation d’exécuter des charges de travail en production.
• Vérifiez votre éligibilité à Visual Studio Community avant de supposer qu’un IDE payant est nécessaire.
• Distinguez une licence Visual Studio autonome d’un abonnement offrant des avantages supplémentaires.

Comparatif des éditions Windows 11 pour un poste de développement