#0006 — WSL comme environnement de développement principal

#Contexte

• Windows reste le système hôte quotidien, notamment pour les usages non techniques et les outils natifs Microsoft.
• Les workflows de développement nécessitent un environnement Linux homogène pour rester compatibles avec les outils modernes (CLI, conteneurs, scripts shell).
• Les écarts de comportement entre Windows et Linux ont déjà généré des bugs difficiles à reproduire, ce qui impose un socle d'exécution unique.

#Décision

• Utiliser WSL comme environnement de développement principal pour tous les travaux liés au hub.
• Exploiter VS Code avec l'extension Remote WSL pour éditer, déboguer et exécuter le code directement dans l'instance Linux.
• Faire tourner Git, Bash, les langages et scripts d'automatisation exclusivement dans WSL afin d'aligner l'ensemble des outils.

#Raisons

• Offrir un environnement Linux standard sans quitter Windows ni perdre les applications natives.
• Garantir la compatibilité avec la majorité des outils de développement et des toolchains modernes.
• Rester cohérent avec Docker, les environnements de production et les scripts de déploiement Linux-first.
• Bénéficier d'une meilleure gestion des outils CLI (bash, package managers, utilitaires Unix) sans portages approximatifs.
• Éviter les problèmes de compatibilité spécifiques à Windows qui ralentissent les itérations.

#Conséquences

#Positives

• Environnement homogène et prévisible entre machines et sessions.
• Compatibilité accrue avec les outils modernes, notamment conteneurs et orchestrateurs.
• Séparation claire entre système hôte Windows et environnement de développement Linux, facilitant la maintenance.
• Reproductibilité améliorée pour les scripts, les tests et la documentation technique.

#Négatives

• Ajout d'une couche WSL à installer, configurer et maintenir.
• Gestion des chemins entre Windows et Linux à surveiller pour éviter les confusions (/mnt/x, chemins relatifs, etc.).
• Nécessité de comprendre le fonctionnement interne de WSL (montages, limites de compatibilité) pour diagnostiquer certains bugs.

#Alternatives considérées

• Développement natif Windows : rejeté pour éviter les incohérences d'outils, les ports incomplets et les scripts Bash non supportés.
• Machine virtuelle Linux complète : rejetée car plus lourde en ressources et moins intégrée aux fichiers locaux.
• Dual boot Windows/Linux : rejeté car peu pratique au quotidien et impose des redémarrages fréquents.

#Statut

Accepté.