Bien démarrer son environnement de travail

Tu vas passer des milliers d'heures devant cette machine, littéralement. À six ou huit heures de code par jour, une année représente plus de 1500 heures les mains sur le clavier. Sur ce volume, la moindre friction se paie au centuple : deux secondes perdues à chaque fois que tu cherches un fichier à la souris, une commande que tu retapes en entier faute d'alias, un terminal illisible qui te fait relire trois fois la même ligne. Prises isolément, ces micro-pertes semblent ridicules ; cumulées sur une carrière, elles pèsent des semaines entières. Soigner son environnement, ce n'est pas de la coquetterie, c'est de l'hygiène professionnelle.

Un bon setup se juge sur cinq plans qui se renforcent. La productivité d'abord : des raccourcis, des automatisations, moins de clics pour la même action. Le confort ensuite : une police lisible et un thème reposant réduisent la fatigue oculaire sur de longues sessions. La reproductibilité, souvent négligée par les débutant·es : pouvoir remonter tout ton environnement en une heure sur une machine neuve, au lieu d'y passer trois jours. La confiance : savoir exactement ce qui tourne sur ta machine, d'où viennent tes outils et comment les mettre à jour. Et le plaisir, qu'on sous-estime : un terminal qui te ressemble donne envie de s'y installer, et la motivation fait partie de la productivité.

La reproductibilité mérite qu'on s'y arrête, car c'est elle qui sépare l'amateur du pro. L'idée maîtresse de ce cours tient en une formule : ta configuration est du code. Tout ce que tu installes et personnalises — outils, alias, réglages — doit pouvoir être décrit dans des fichiers versionnés, pas cliqué à la main puis oublié. Le jour où ton disque lâche, où tu changes d'ordinateur ou où tu veux aider un·e collègue à répliquer ton setup, tu ne repars pas de zéro : tu rejoues une poignée de commandes. On construira cet état d'esprit tout au long des chapitres, jusqu'aux dotfiles.

Méfie-toi cependant du piège inverse, très courant en début de parcours : passer une journée entière à peaufiner un thème ou une config avant d'avoir écrit la moindre ligne de code utile. C'est du yak shaving, une forme sophistiquée de procrastination. La bonne méthode, détaillée juste en dessous, consiste à installer le strict minimum, à coder, et à n'améliorer ta config que lorsque tu butes sur une vraie friction identifiée.

• Productivité : raccourcis, automatisations, moins de clics
• Confort : police lisible, thème reposant, ergonomie
• Reproductibilité : pouvoir réinstaller en 1 heure sur une autre machine
• Confiance : tu sais ce qui tourne sur ta machine
• Plaisir : un terminal qui te ressemble, c'est motivant

Ton éditeur, c'est l'atelier où tu passes le plus clair de ton temps : autant le connaître à fond. VS Code s'est imposé comme la référence pour de bonnes raisons — gratuit, rapide au démarrage, disponible sur les trois OS, et surtout extensible. Sa vraie force n'est pas ce qu'il fait par défaut, mais l'écosystème d'extensions qui l'adapte à ta stack. On peut lui préférer des alternatives (les IDE JetBrains, Neovim, Zed), mais pour démarrer, VS Code offre le meilleur rapport puissance/simplicité et une communauté immense où presque toute question a déjà sa réponse.

Installer VS Code nu ne suffit pas ; ce sont quelques extensions bien choisies qui le transforment en outil pro. Trois familles comptent avant tout. Le linter (ESLint) analyse ton code en direct et repère erreurs et mauvaises pratiques avant même que tu l'exécutes. Le formateur (Prettier) impose une mise en forme cohérente automatiquement, ce qui met fin aux débats stériles sur les espaces et les points-virgules. L'intégration Git (GitLens) affiche, ligne par ligne, qui a écrit quoi et quand, directement dans l'éditeur. S'y ajoutent EditorConfig, qui aligne l'indentation entre les membres d'une équipe, et Error Lens, qui montre les erreurs à côté du code plutôt que dans un panneau qu'on oublie de regarder.

Le réglage qui change le plus le quotidien, c'est le Format on Save : à chaque sauvegarde, Prettier reformate ton fichier. Tu arrêtes de penser à l'alignement et tu te concentres sur la logique ; les diffs Git deviennent propres parce que le style est identique pour tout le monde. Combine-le avec un ESLint réglé pour corriger automatiquement les problèmes simples, et une bonne partie du travail ingrat disparaît sans que tu y penses.

Deux détails paraissent cosmétiques mais comptent vraiment : la police et les raccourcis. Une police à ligatures pensée pour le code (Fira Code, JetBrains Mono, Cascadia Code) rend des symboles comme => ou !== plus lisibles et repose les yeux sur la durée. Quant aux raccourcis, prends l'habitude de garder les mains sur le clavier : le plus rentable de tous est la palette de commandes (Cmd/Ctrl + Shift + P), qui donne accès à absolument toutes les commandes de l'éditeur en tapant leur nom, sans fouiller dans les menus. Apprends-en deux ou trois par semaine plutôt que tout d'un coup.

Installation

Télécharge depuis code.visualstudio.com, ou via ton gestionnaire de paquets (voir chapitre suivant).

Les extensions essentielles

• ESLint : linter JavaScript / TypeScript
• Prettier : formattage automatique au save
• GitLens : git blame inline, historique d'une ligne
• EditorConfig : respect des conventions par projet (indentation, fin de ligne)
• Error Lens : affiche les erreurs inline (pas seulement dans le panneau Problems)

code --install-extension dbaeumer.vscode-eslint
code --install-extension esbenp.prettier-vscode
code --install-extension eamodio.gitlens
code --install-extension EditorConfig.EditorConfig
code --install-extension usernamehw.errorlens

Police à ligatures

• Fira Code : la référence open source, gratuite
• JetBrains Mono : excellente lisibilité
• Cascadia Code : la police de Windows Terminal, très propre

Raccourcis vitaux

• Cmd/Ctrl + P : aller à un fichier
• Cmd/Ctrl + Shift + P : palette de commandes (le raccourci le plus rentable)
• Cmd/Ctrl + D : sélection multiple de la même occurrence
• Cmd/Ctrl + B : afficher / cacher la sidebar
• Cmd/Ctrl + / : commenter / décommenter

Le terminal fait peur au début — un écran noir, un curseur qui clignote, aucune icône rassurante. Passé ce cap, c'est l'un des plus grands accélérateurs du métier. Là où l'interface graphique t'impose un chemin (ouvrir, cliquer, glisser), la ligne de commande te laisse composer : enchaîner des outils, automatiser une tâche répétitive, agir sur mille fichiers d'un coup. Investir trente minutes pour le rendre lisible et agréable, c'est un gain qui se répète chaque jour pendant des années.

Avant de configurer quoi que ce soit, distingue trois couches qu'on confond souvent. L'émulateur de terminal est la fenêtre elle-même (Warp, iTerm2, Windows Terminal, GNOME Terminal) : il gère l'affichage, les onglets, les polices. Le shell est le programme qui interprète tes commandes (bash, zsh, fish) : c'est lui qui comprend cd, ls ou un pipe. Le prompt, enfin, est la ligne d'invite affichée avant que tu tapes, que Starship va embellir. Tu peux changer chacune de ces couches indépendamment : un même shell zsh tourne dans n'importe quel émulateur, avec le prompt de ton choix.

Sur Mac, zsh est déjà le shell par défaut ; sur Linux et WSL, on l'installe en une commande. Ce qui le rend agréable, c'est son autocomplétion et son écosystème de plugins. Pour le prompt, Starship est la valeur sûre du moment : écrit en Rust, quasi instantané, il affiche automatiquement la branche Git, la version de Node du projet, la durée des commandes longues et le statut de la dernière. Fidèle à l'esprit « config as code », il se règle dans un unique fichier starship.toml que tu pourras versionner avec le reste de tes dotfiles.

Le vrai bond de productivité vient ensuite des alias et des plugins. Un alias, c'est un raccourci pour une commande que tu tapes cent fois par jour : gs au lieu de git status, ll au lieu de ls -lah. Trois lettres économisées à chaque fois finissent par compter. Côté plugins zsh, deux sont incontournables : zsh-autosuggestions, qui propose de compléter une commande à partir de ton historique, et zsh-syntax-highlighting, qui colore la commande en vert si elle est valide, en rouge si tu as fait une faute de frappe — tu repères l'erreur avant même d'appuyer sur Entrée.

Quel terminal selon ton OS

• Mac : Warp (moderne, AI-friendly) ou iTerm2 (référence historique)
• Windows : Windows Terminal avec WSL2 (Ubuntu) pour un environnement Linux complet
• Linux : le terminal natif (GNOME Terminal, Konsole) suffit

Shell : zsh par défaut

• Mac : zsh est le shell par défaut depuis macOS Catalina
• Linux / WSL : sudo apt install zsh puis chsh -s $(which zsh)
• Bash reste OK, mais zsh apporte autocomplétion, glob avancés, plugins

Prompt : Starship

Starship (starship.rs) est un prompt cross-shell ultra-rapide écrit en Rust. Affiche branche Git, version Node, durée d'exécution, statut, le tout configurable en TOML.

# Mac (via Homebrew) ou Linux / WSL
brew install starship          # ou: curl -sS https://starship.rs/install.sh | sh

# Ajouter à ~/.zshrc
echo 'eval "$(starship init zsh)"' >> ~/.zshrc

# Recharger
source ~/.zshrc

Alias persos : gagner 10 secondes par commande

# Git
alias gs="git status"
alias gco="git checkout"
alias gp="git pull"
alias gpush="git push"

# Navigation
alias ll="ls -lah"
alias ..="cd .."
alias ...="cd ../.."

# Quick edit du shell
alias zshrc="code ~/.zshrc"

Un gestionnaire de paquets, c'est l'équivalent d'un app store en ligne de commande : une seule commande télécharge un outil, l'installe au bon endroit, gère ses dépendances et te permet de le mettre à jour ou de le désinstaller proprement. Comparé au rituel « chercher le site officiel, télécharger un .dmg, glisser dans Applications, valider trois fenêtres de sécurité », c'est plus rapide, plus sûr — tu évites les sites douteux — et surtout reproductible : la commande qui t'a installé un outil peut être notée, partagée et rejouée à l'identique.

Chaque OS a le sien, mais le modèle mental est identique. Sur Mac, Homebrew est la référence : il installe aussi bien des outils en ligne de commande (brew install) que des applications graphiques (brew install --cask). Sur Windows, winget est désormais natif et couvre l'essentiel du catalogue. Sur Debian/Ubuntu et WSL, apt joue ce rôle depuis toujours. Retiens le geste plutôt que la commande exacte : « je veux tel outil » devient « j'installe tel paquet », d'une ligne, sans jamais quitter le terminal.

Le vrai gain arrive quand tu passes d'une installation manuelle à une installation déclarative. Avec Homebrew, brew bundle dump génère un Brewfile : un simple fichier texte qui liste tout ce que tu as installé. Commité dans tes dotfiles, il devient la recette de ta machine — brew bundle réinstalle tout à l'identique sur un poste neuf. winget propose l'équivalent avec winget export et winget import. C'est exactement l'idée qu'on répète depuis le début du cours : ne clique pas ce que tu peux décrire dans un fichier versionné.

Un mot de prudence, car ces commandes s'exécutent avec tes droits. Installe depuis les dépôts officiels du gestionnaire, méfie-toi des scripts d'installation copiés-collés depuis des sources inconnues, et prends l'habitude de lire ce qu'une commande va faire avant de la valider — surtout lorsqu'elle commence par sudo. Un gestionnaire de paquets bien utilisé rend ta machine plus sûre, pas moins.

Mac : Homebrew

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# Installer plein d'outils en une commande
brew install git node fzf bat exa ripgrep jq

Windows : winget (natif Windows 10/11)

winget install Git.Git
winget install Microsoft.VisualStudioCode
winget install OpenJS.NodeJS.LTS
winget install Microsoft.WindowsTerminal

Linux Debian / Ubuntu : apt

sudo apt update && sudo apt install -y \
  git curl build-essential \
  zsh ripgrep fzf bat jq

Dès que tu travailles sur plus d'un projet, un problème très concret apparaît : chacun peut exiger une version différente de Node. Un projet un peu ancien tourne en Node 18, celui de ton alternance en Node 20, ton side-project en Node 22. Installer une seule version « en dur » te condamne à la désinstaller-réinstaller à chaque changement de contexte, ou à voir surgir des bugs incompréhensibles parce qu'une dépendance n'aime pas ta version. La solution, c'est un gestionnaire de versions qui les fait cohabiter et bascule de l'une à l'autre à la demande.

Première règle, contre-intuitive pour les débutant·es : n'installe jamais Node directement en global, par exemple via brew install node. Ça pose une version unique, souvent à un endroit protégé du système, et tu te retrouves à batailler avec des erreurs de permissions dès le premier npm install -g. Le gestionnaire de versions, lui, installe Node dans ton dossier utilisateur, sans sudo, ce qui supprime d'un coup toute cette classe de problèmes.

Le choix recommandé aujourd'hui est fnm (Fast Node Manager) : écrit en Rust, nettement plus rapide que son ancêtre nvm, et disponible sur Mac, Linux et Windows. Sa fonctionnalité la plus agréable est l'auto-switch : en activant l'option --use-on-cd, fnm lit à chaque changement de dossier un fichier .nvmrc ou .node-version déposé à la racine du projet, et bascule tout seul sur la bonne version. Tu passes d'un projet en Node 20 à un autre en Node 22 simplement en faisant cd, sans jamais y penser. Si tu as déjà nvm et qu'il te convient, inutile de migrer ; mais pour un nouveau poste, fnm est le meilleur point de départ.

Bonne pratique d'équipe : commite un fichier .node-version (ou .nvmrc) à la racine de chaque projet. Il documente noir sur blanc la version attendue, coupe court aux « ça marche chez moi », et permet à quiconque clone le dépôt — y compris la chaîne d'intégration continue — d'utiliser exactement la même version que toi. Une ligne de texte qui épargne des heures de débogage.

fnm (recommandé en 2025)

• Écrit en Rust, beaucoup plus rapide que nvm
• Auto-switch via .nvmrc ou .node-version quand tu changes de dossier
• Multi-plateforme : Mac, Linux, Windows

# Installation
brew install fnm                                       # Mac
curl -fsSL https://fnm.vercel.app/install | bash       # Linux / WSL
winget install Schniz.fnm                              # Windows

# Activer dans le shell (à ajouter à ~/.zshrc)
echo 'eval "$(fnm env --use-on-cd)"' >> ~/.zshrc

# Installer et utiliser
fnm install 22
fnm install 20
fnm use 22
node -v       # v22.x

nvm : l'historique

nvm est plus ancien et plus répandu, mais plus lent. Si tu as déjà nvm, pas la peine de migrer. Si tu pars de zéro, prends fnm.

Ce chapitre reste volontairement court : commits, branches et pull requests sont traités en détail dans le cours Premiers pas avec Git et GitHub. Ici, on se concentre sur la configuration initiale — ce que tu fais une seule fois, juste après l'installation, et qui conditionne tout le reste. La bâcler, c'est risquer des commits signés du mauvais nom ou une authentification qui te redemande ton mot de passe à chaque push.

Commence par ton identité. user.name et user.email sont inscrits dans chacun de tes commits, de façon permanente. Détail qui a son importance : l'email doit correspondre à celui de ton compte GitHub, sinon tes contributions n'apparaîtront ni sur ton profil ni dans le graphe d'activité — un point que des recruteurs regardent parfois. Tu peux toujours surcharger cet email projet par projet (sans --global) quand tu travailles pour un client sous une autre adresse.

Vient ensuite l'authentification. Pour dialoguer avec GitHub, deux protocoles existent : HTTPS (qui réclame un token à chaque fois si tu ne le mets pas en cache) et SSH, plus confortable une fois configuré. Le principe de SSH : tu génères une paire de clés — une privée qui reste secrète sur ta machine, une publique que tu colles sur GitHub. Quand tu pousses, les deux se répondent sans jamais transmettre de mot de passe. Utilise le type ed25519 : plus court, plus rapide et au moins aussi sûr que les vieilles clés RSA. La clé privée ne quitte jamais ton ordinateur ; ne la partage sous aucun prétexte.

Profite de ce passage pour poser quelques réglages globaux qui t'éviteront des surprises. init.defaultBranch main nomme la branche par défaut main plutôt que master. core.editor "code --wait" ouvre VS Code pour rédiger tes messages de commit, au lieu de te retrouver bloqué dans Vim sans savoir en sortir. Beaucoup de dev ajoutent aussi une préférence de pull pour garder un historique propre. Ces quelques lignes se posent une fois et te suivent sur tous tes dépôts.

# Identité
git config --global user.name "Ton Nom"
git config --global user.email "toi@exemple.com"

# Branche par défaut
git config --global init.defaultBranch main

# Éditeur par défaut
git config --global core.editor "code --wait"

# Clé SSH (pour GitHub)
ssh-keygen -t ed25519 -C "toi@exemple.com"
cat ~/.ssh/id_ed25519.pub      # à coller sur GitHub

Les dotfiles, ce sont ces fichiers de configuration cachés dont le nom commence par un point : .zshrc pour ton shell, .gitconfig pour Git, les réglages de VS Code, la config de Starship… Pris séparément, ils semblent anodins ; ensemble, ils sont ton environnement. Tout ce que tu as patiemment réglé — alias, prompt, raccourcis, préférences — vit là-dedans. Les versionner dans un dépôt Git, c'est transformer des heures de personnalisation en un actif que tu ne perdras plus jamais et que tu remonteras en une heure sur n'importe quelle machine.

La mécanique est simple une fois comprise. Les vrais fichiers ne restent pas éparpillés dans ton dossier personnel : tu les déplaces dans un dossier ~/dotfiles/ versionné, puis tu crées des liens symboliques (ln -s) depuis les emplacements attendus (~/.zshrc) vers ces fichiers. Ainsi, quand tu modifies ta config, la modification est immédiatement dans ton dépôt, prête à être commitée. L'outil GNU Stow automatise la création de ces liens, mais un petit script bash suffit largement pour démarrer — ne te complique pas la vie trop tôt.

Une règle de sécurité absolue : jamais de secret dans tes dotfiles, surtout si le dépôt est public. Pas de clé privée SSH, pas de token d'API, pas de mot de passe. Ces éléments-là vivent dans ton gestionnaire de mots de passe, pas dans Git. Ce que tu versionnes, ce sont des configurations : alias, prompt, réglages d'éditeur, liste d'outils à installer. Dans le doute, mets ton dépôt en privé — mais garde le réflexe : un secret poussé sur GitHub, même supprimé ensuite, doit être considéré comme compromis.

Enfin, tu n'es pas obligé·e de tout faire à la main. VS Code intègre un Settings Sync : connecte ton compte GitHub et tes réglages comme tes extensions se synchronisent automatiquement entre tes machines. C'est parfait pour l'éditeur. Pour le reste — shell, Git, outils système — le dépôt dotfiles reste la méthode la plus universelle et la plus transparente. Beaucoup de dev combinent les deux : Settings Sync pour VS Code, dotfiles pour tout le reste.

Pourquoi

• Changement de machine sans perdre 3 jours de reconfiguration
• Reset propre quand tu casses ton shell
• Partage avec ton équipe (mêmes alias, mêmes raccourcis)
• Sauvegarde : tes dotfiles survivent à un crash disque

Setup minimal

# Créer un repo dotfiles
mkdir ~/dotfiles && cd ~/dotfiles
git init

# Copier les configs utiles
cp ~/.zshrc .
cp ~/.gitconfig .
cp -r ~/.config/starship ./starship  # si tu as customisé Starship

# Commiter
git add .
git commit -m "init dotfiles"

# Pousser sur GitHub (repo privé conseillé)
git remote add origin git@github.com:tonpseudo/dotfiles.git
git push -u origin main

Symlinks ou stow ?

Les vrais fichiers vivent dans ~/dotfiles/, et tu crées des liens symboliques (ln -s) vers les emplacements attendus (~/.zshrc). Ainsi, quand tu modifies une config, c'est versionné automatiquement. GNU Stow automatise ça, mais un simple script bash suffit pour démarrer.

Au-delà de l'éditeur et du terminal, une poignée d'outils transversaux fluidifient tout le reste de ta journée. Aucun n'est obligatoire, mais chacun supprime une friction récurrente, et une fois adoptés on n'y revient plus. L'idée n'est pas d'installer une longue liste d'un coup : ajoute-les un par un, quand tu ressens le besoin, pour que chaque outil corresponde à un vrai usage plutôt qu'à un effet de mode.

Le premier de tous, non négociable, est un gestionnaire de mots de passe (1Password, Bitwarden). Il stocke non seulement tes mots de passe mais aussi tes clés SSH et tes tokens d'API, chiffrés, synchronisés et remplis automatiquement. En tant que dev, tu manipules des dizaines de secrets : les garder en tête ou dans un fichier texte est la porte ouverte à l'incident. Viennent ensuite les outils de confort : un lanceur (Raycast sur Mac, PowerToys Run sur Windows) pour ouvrir une app ou faire un calcul en deux frappes, et un gestionnaire de fenêtres au clavier (Rectangle, FancyZones) pour organiser ton écran sans la souris.

Un dernier réflexe, moins technique mais décisif sur la durée : tiens un journal de dev. Un simple fichier journal.md ou un vault Obsidian où tu notes ce que tu apprends, les bugs que tu résous et comment, les commandes utiles, les liens à garder. Sur le moment ça paraît superflu ; dans six mois, quand tu retombes sur le même problème obscur, ton toi du passé t'aura laissé la solution. C'est aussi une mine d'or pour préparer un entretien ou un dossier de certification, et un excellent moyen d'apprendre en documentant plutôt qu'en oubliant.

Adapte enfin ta boîte à outils à ta stack. Un navigateur doté de bons DevTools (Chrome ou Firefox) et les extensions correspondant à ton framework — React DevTools, Vue DevTools — te feront gagner un temps fou au débogage, sujet traité dans le cours dédié à l'inspecteur du navigateur. L'objectif de tout ce chapitre reste celui du cours entier : réduire les frictions pour que ton énergie parte dans le code et l'apprentissage, pas dans la lutte contre ta propre machine.

• 1Password / Bitwarden : gestionnaire de mots de passe, clés SSH, tokens API. Indispensable.
• Raycast (Mac) / PowerToys Run (Windows) : lanceur d'applications, snippets, calculatrice, presse-papier
• Rectangle (Mac) / FancyZones (Windows) : gestion de fenêtres au clavier
• Obsidian / Bear / Notion : notes, veille technique
• Stats (Mac, gratuit) : monitoring CPU/RAM/réseau dans la barre de menus

Navigateur dev

Chrome ou Firefox avec les DevTools (voir le cours Déboguer avec l'inspecteur du navigateur). Installe l'extension React DevTools ou Vue DevTools selon ta stack.