Pack développeurWindows 11 developer pack

Un poste Windows propre pour le web, le backend et le mobile.

Une configuration pratique pour les développeurs Windows 11 qui ont besoin de PowerShell, Windows Terminal, Git, VS Code, Cursor, Node.js, pnpm, Docker Desktop, WSL 2 et, si nécessaire, d’Android ou Flutter sans transformer la machine en collection d’outils aléatoires.

Retour aux téléchargements

Scripts Windows Windows Systems Linux Systems Container Tooling Node.js & TypeScript

Installer depuis des sources fiables

Utiliser WinGet et les pages éditeur officielles pour garder le poste auditable et facile à reconstruire.

Supporter les projets hybrides

Préparer les outils natifs Windows, WSL 2, Docker Desktop et les workflows Node.js pour un vrai usage projet.

Garder Windows propre

Éviter les installateurs inconnus, runtimes dupliqués et scripts utilitaires non relus qui deviennent difficiles à maintenir.

Ordre recommandé

Construire le poste par couches

La configuration Windows la plus sûre commence par le shell système, puis Git et les éditeurs, ensuite les runtimes, les conteneurs, la compatibilité Linux et les outils mobiles optionnels.

01 · Mettre Windows à jour

Lancer Windows Update avant les outils développeur pour que WSL, la virtualisation et les composants de sécurité soient à jour.

02 · Préparer Terminal et PowerShell

Utiliser Windows Terminal avec un profil PowerShell récent plutôt que multiplier les raccourcis de consoles.

03 · Installer Git et les éditeurs

Installer Git, VS Code et Cursor depuis des sources fiables, puis limiter les extensions aux projets réellement maintenus.

04 · Installer Node.js et pnpm

Utiliser une version LTS de Node.js et Corepack ou pnpm directement, puis vérifier les deux avant d’ouvrir un monorepo.

05 · Ajouter Docker Desktop et WSL 2

Docker Desktop et WSL 2 doivent être configurés volontairement car ils influencent la mémoire, le disque et le réseau.

06 · Ajouter le mobile seulement si nécessaire

Android Studio et Flutter sont utiles pour le mobile, mais ajoutent des SDK, émulateurs et services en arrière-plan.

Commandes WinGet

Installations Windows de base

Ces commandes forment un point de départ pratique. Vérifier chaque ID de package et sa source dans WinGet avant de l’exécuter sur une machine professionnelle.

winget source update

Actualise les sources WinGet avant de rechercher ou d’installer des outils développeur.

winget install --id Microsoft.WindowsTerminal -e

Installe Windows Terminal lorsqu’il n’est pas déjà disponible sur la machine.

winget install --id Microsoft.PowerShell -e

Installe le package PowerShell multiplateforme actuel pour une expérience shell cohérente.

winget install --id Git.Git -e

Installe Git for Windows, y compris les outils CLI utilisés par les éditeurs et scripts projet.

winget install --id Microsoft.VisualStudioCode -e

Installe VS Code depuis l’entrée Microsoft plutôt qu’un miroir de téléchargement inconnu.

winget search Cursor

Rechercher d’abord, puis installer Cursor uniquement depuis une entrée éditeur vérifiée ou la page officielle.

winget install --id OpenJS.NodeJS.LTS -e

Installe Node.js LTS, adapté à la plupart des projets Next.js, NestJS et TypeScript.

winget install --id pnpm.pnpm -e

Installe pnpm directement si le poste ne s’appuie pas sur Corepack pour gérer les package managers.

winget install --id Docker.DockerDesktop -e

Installe Docker Desktop, à configurer ensuite avec l’intégration WSL 2 si elle est utile.

WSL et conteneurs

WSL 2, Docker Desktop et workflows Linux

Windows peut supporter un développement sérieux orienté Linux, mais la frontière entre chemins Windows, systèmes de fichiers WSL et volumes Docker doit rester claire.

wsl --install

Active WSL et installe une distribution Linux par défaut sur les machines où WSL n’est pas déjà configuré.

wsl --status

Affiche la version WSL par défaut et aide à confirmer que la machine utilise WSL 2.

wsl --list --verbose

Liste les distributions installées et leur version pour repérer les environnements incohérents.

Docker Desktop WSL integration

Activer l’intégration seulement pour les distributions réellement utilisées par les projets.

Fichiers projet dans WSL si possible

Les projets très orientés Linux sont souvent plus rapides quand les dépendances et node_modules restent dans le système de fichiers WSL.

Sources officielles

Sources éditeur à privilégier

Un poste Windows est plus simple à supporter quand les outils clés viennent de WinGet ou de pages éditeur vérifiables.

Documentation Microsoft

Utiliser les guides Microsoft pour Windows Terminal, PowerShell, WSL 2, la virtualisation et les réglages développeur Windows.

Git for Windows

Utiliser le package officiel Git for Windows ou une entrée WinGet vérifiée pour l’installation de Git.

VS Code et Cursor

Installer les éditeurs depuis leurs canaux éditeur et limiter les extensions à la stack projet.

Node.js et pnpm

Préférer Node.js LTS et une stratégie pnpm documentée, via Corepack ou un package vérifié.

Docker Desktop

Installer depuis le package éditeur et vérifier les contraintes de licence ou d’usage en organisation.

Android Studio et Flutter

Utiliser les sources mobiles officielles lorsque le poste doit valider Android, les émulateurs ou le cross-platform.

Mobile optionnel

Android Studio et Flutter quand le projet l’exige

Le tooling mobile est utile pour Android ou la validation cross-platform, mais il ne doit pas être installé seulement pour compléter la liste.

winget install --id Google.AndroidStudio -e

Installe Android Studio pour gérer le SDK Android, les émulateurs et le debugging mobile.

winget search Flutter

Vérifier la source actuelle du package Flutter, puis installer depuis un canal officiel ou vérifié.

Android SDK location

Documenter les chemins SDK pour que les shells, éditeurs et scripts retrouvent les mêmes outils.

flutter doctor

À utiliser après installation de Flutter pour repérer les réglages Android, licences ou périphériques manquants.

Hygiène système

Garder le poste maintenable

Une machine Windows professionnelle doit rester prévisible : sources claires, outils connus, scripts relus et vérifications reproductibles.

Éviter les outils d’optimisation aléatoires

Ne pas installer de nettoyeurs de registre, packs de drivers ou boosters de performance impossibles à auditer.

Préférer une source par outil

Mélanger MSI, WinGet et archives pour le même outil rend les mises à jour difficiles à comprendre.

Documenter les installateurs manuels

Si un outil ne passe pas par WinGet, noter sa source et la raison de son installation.

Relire les scripts avant élévation

Exécuter des scripts administrateur seulement après lecture des commandes et compréhension des fichiers, services ou réglages touchés.

Contrôles finaux

Vérification après installation

Ne pas continuer à installer des outils si les contrôles de base échouent. Corriger l’environnement tant que la cause reste facile à isoler.

$PSVersionTable.PSVersion

Confirme la version PowerShell disponible dans le terminal courant.

git --version

Vérifie la disponibilité de Git avant de cloner ou ouvrir des dépôts.

code --version

Confirme l’intégration CLI de VS Code si l’éditeur a été installé avec le support shell.

node -v && pnpm -v

Vérifie le runtime JavaScript et le package manager utilisés par les projets.

docker --version && docker compose version

Vérifie que Docker et Compose répondent avant de démarrer les services locaux.

wsl --list --verbose

Confirme les distributions Linux installées et leur exécution éventuelle en WSL 2.

Boîte à outils vivante

Cette section sera enrichie progressivement avec des outils réels.

Les packs, scripts et expérimentations seront documentés avec prudence, usage concret et limites claires.

Discuter d’un outil Voir le Tech Lab