Windows Terminal comme un pro : profils, polices et raccourcis

Un modèle mental pratique : Terminal est un hôte, les profils sont des contrats

Pensez à Windows Terminal comme à un multiplexeur bien élevé avec des opinions. Il ne « est » pas PowerShell ou WSL ; il les héberge. Votre travail est de définir les contrats : quel shell démarre, dans quel répertoire de travail, sous quel environnement, avec quelle police et quelles touches, et avec quelles barrières de sécurité.

Si vous traitez les profils comme décoratifs (« je cliquerai juste sur le menu déroulant »), vous finirez avec le même mode d’échec qu’un runbook SRE bâclé : ambiguïté sous pression. Les profils doivent répondre à ces questions sans que vous y réfléchissiez :

• Dans quel environnement suis-je : production, staging, personnel, astreinte ?
• Quelle identité j’utilise : utilisateur local, admin, clé SSH A ou B ?
• Quel est le répertoire par défaut et la chaîne d’outils par défaut ?
• Quelles fonctions de sécurité sont activées : confirmations, montages en lecture seule, avertissements ?

Ce n’est pas de l’esthétique. C’est de la justesse opérationnelle. Le terminal est le cockpit. Étiquetez vos commandes.

Faits intéressants et contexte à utiliser dans vos arguments

1. Windows Terminal est relativement récent : Microsoft l’a présenté publiquement en 2019, et il est devenu un défaut courant sur de nombreuses installations Windows 11 par la suite. Le point : il évolue encore ; votre souvenir « ça marchait avant » peut dépendre d’une version.
2. ConPTY a été un tournant : le pseudo-terminal de la console Windows (ConPTY) a permis aux applications de terminal modernes de parler aux programmes console d’une manière plus proche de l’univers Unix. Avant cela, l’émulation terminal sous Windows était… formatrice.
3. L’ancien Console Host (conhost.exe) est toujours là : Windows Terminal peut héberger des applications console classiques, mais elles peuvent toujours se comporter comme conçues pour une autre époque, parce que c’est le cas.
4. PowerShell a deux personnalités : Windows PowerShell (5.1) est la version héritée incluse ; PowerShell (7+) est multiplateforme et activement développé. Les mélanger sans étiqueter votre profil est une source d’erreur évitable.
5. WT prend en charge plusieurs moteurs de rendu : le rendu de texte accéléré par GPU peut être rapide, mais expose aussi des problèmes de police et de glyphes que vous n’aviez jamais vus dans les consoles plus anciennes.
6. Les onglets et les panneaux ne sont pas que du vernis UI : ils réduisent le changement de contexte. Mal utilisés, ils créent des erreurs « où suis-je ? ». Bien utilisés, ils transforment la réponse à un incident en un flux répétable.
7. Les paramètres ont évolué depuis le JSON seul : au début, Windows Terminal se configurait principalement via settings.json ; maintenant il y a une interface graphique, mais le JSON reste la source de vérité pour des configurations reproductibles.
8. Les NERD fonts ne sont pas « un thème » : ce sont des polices patchées avec des glyphes supplémentaires. Si vous n’avez pas besoin de ces glyphes, vous n’avez pas besoin de la police — et vous évitez toute une classe de bizarreries de rendu.

Profils : rendez les environnements volontairement ennuyeux

Règles de conception de profils qui empêchent les erreurs réelles

Voici les règles que j’applique en équipe :

• Nommez les profils comme vous nommez l’infrastructure : « WSL Ubuntu » va pour un laptop. Pour le travail sérieux : « WSL : ubuntu (staging tooling) », « PowerShell 7 (admin) », « SSH : bastion (prod-readonly) ».
• Le répertoire par défaut est une politique, pas une préférence. Démarrez dans un endroit sûr avec des scripts connus, pas dans le dernier répertoire aléatoire où vous avez fait un cd.
• Rendez la prod visuellement distincte. Différent schéma de couleurs, titre d’onglet différent, et même un style de curseur différent. Vous voulez que votre cerveau remarque.
• Privilégiez des commandlines explicites plutôt que « ce que le système trouve ». Épinglez pwsh.exe vs powershell.exe, et épinglez les distributions WSL par nom.
• Utilisez un seul endroit pour l’automatisation : conservez les scripts de profil dans des dotfiles versionnés quand possible. La magie locale uniquement crée des snowflakes.

Structure de paramètres qui reste maintenable

Les paramètres de Windows Terminal sont une fusion de valeurs par défaut et de vos remplacements. Vous n’avez pas besoin de réécrire le monde. Vous devez définir : profile par défaut, liste de profils, apparence par défaut et bindings. Traitez-le comme de l’infrastructure-as-code : minimal, explicite, relisible.

Champs clés que vous devriez comprendre et utiliser délibérément :

• defaultProfile : ce qui se lance quand vous ouvrez Terminal. Si vous ne le définissez pas, vous aurez des surprises après installations et mises à jour.
• profiles.list : vos définitions de profils triées.
• guid : l’identité stable d’un profil. Si vous modifiez les profils uniquement par nom, vous finirez par collisionner avec des profils auto-générés.
• commandline : exactement ce qui démarre. Privilégiez des chemins explicites pour les shells non inclus.
• startingDirectory : l’endroit où votre shell arrive en premier. L’ennui, c’est bien.
• tabTitle et name : l’un est l’étiquette d’affichage, l’autre le sélecteur de profil. Utilisez les deux.
• colorScheme, cursorShape, font : barrières visuelles de sécurité.

Schémas de profils qui fonctionnent en production

Schéma 1 : « Admin » est un profil séparé. Ne comptez pas sur « Exécuter en tant qu’administrateur » comme habitude. Vous voulez un profil qui affiche clairement « vous tenez la tronçonneuse ». Icône différente, schéma différent, titre différent. Utilisez-le intentionnellement.

Schéma 2 : « Prod » est en lecture seule par défaut. Si votre flux le permet, utilisez un profil SSH qui vous mène sur un bastion avec permissions restreintes, ou un shell qui exporte des variables d’environnement garde-fous. Faites du « break glass » un profil séparé avec un nom évident.

Schéma 3 : profils « Tooling » par contexte. Si vous avez des contextes Kubernetes, des profils AWS ou différents fichiers SSH, ne chargez pas tout au démarrage de chaque shell. Créez des profils qui chargent ce dont ils ont besoin. Le temps de démarrage compte ; la justesse aussi.

Polices : lisibilité, ligatures et la tyrannie des glyphes manquants

Choisissez une police comme vous choisissez un tableau de monitoring

La police de votre terminal n’est pas une déclaration de mode. C’est une interface. Votre choix de police affecte :

• La vitesse à repérer une faute de frappe dans une commande qui peut tout supprimer.
• Si les caractères de dessin d’interface (box-drawing) s’affichent correctement (pensez : tableaux, UI type tmux, CLI).
• Si les symboles Powerline ou Nerd Font apparaissent en carrés.
• Si le rendu GPU lutte (rare, mais réel sur des systèmes plus anciens).

Mon conseil sans compromis :

• Par défaut, utilisez Cascadia Mono ou une autre police monospace propre qui rend bien sur Windows. Restez sobre tant que vous n’avez pas de raison d’en changer.
• N’utilisez une Nerd Font que si vous avez besoin des glyphes. Si votre thème d’invite dépend d’icônes, ok. Si vous voulez juste un look moderne, non. Les glyphes manquants sont du bruit opérationnel.
• Désactivez les ligatures à moins d’avoir une forte préférence. Les ligatures peuvent faire mal lire des opérateurs comme !=, => ou == selon la police. Quand vous êtes fatigué, vous voulez du littéral.

Petite blague courte : les ligatures sont comme la caféine — merveilleuses jusqu’à ce qu’elles cachent la vérité et que vous ne puissiez plus dormir.

Problèmes de police qui ressemblent à « le système est maudit »

Si vous voyez des carrés, des points d’interrogation ou des symboles d’invite mal alignés, c’est presque toujours l’un de ces cas :

• Vous avez choisi une police sans les glyphes Unicode nécessaires.
• Votre shell émet des symboles Powerline mais votre police n’est pas patchée.
• Des polices de secours sont utilisées de manière incohérente parce que la police principale manque de caractères.
• La métrique de votre police provoque des problèmes de hauteur de ligne ; le curseur ne s’aligne pas ou le texte se chevauche.

La solution est rarement « réinstallez Windows Terminal ». C’est « choisissez une police qui correspond à votre invite ».

Raccourcis : la mémoire musculaire l’emporte sur la créativité

Lie pour la réponse aux incidents, pas pour le fun

Les raccourcis clavier font passer un bon utilisateur de terminal à un utilisateur rapide. Mais des raccourcis aléatoires sont pires que rien ; ils donnent une confiance trompeuse. Choisissez un petit ensemble et standardisez-les sur vos machines.

Ma philosophie recommandée pour les bindings :

• Conservez les valeurs par défaut quand elles sont sensées. Les valeurs par défaut de Windows Terminal sont globalement raisonnables pour onglets/panneaux.
• Standardisez les splits de panneaux sur les mêmes touches que celles que vous utilisez dans d’autres multiplexeurs si vous y vivez. La cohérence bat la nouveauté.
• Rendez « copier » et « coller » prévisibles. Décidez si la sélection copie automatiquement, si le clic droit colle, et ce que fait Ctrl+V. Puis appliquez-le.
• Ayez un comportement « fermeture panique » qui vous demande confirmation. Fermer accidentellement le mauvais onglet en plein incident est une douleur particulière.

Onglets, panneaux et le mode d’échec « mauvais panneau »

Les panneaux sont merveilleux jusqu’à ce qu’ils ne le soient plus. Le mode d’échec opérationnel central est d’exécuter une commande dans le mauvais panneau. Le remède n’est pas « soyez plus prudent ». Le remède est :

• Titres d’onglet distincts qui incluent des marqueurs d’environnement.
• Schémas de couleurs par environnement.
• Raccourcis clavier pour « focus pane » faciles et cohérents.
• Commandes de démarrage qui définissent une invite ou un titre visible par environnement.

Tâches pratiques : 12+ vérifications, commandes, sorties, décisions

Voici des tâches réelles que vous pouvez exécuter sur une machine Windows avec WSL installé. J’utilise WSL parce qu’il nous fournit un shell cohérent pour les commandes et les sorties, et parce que les utilisateurs modernes de Windows Terminal l’ont généralement. Chaque tâche inclut : la commande, ce que la sortie signifie, et la décision à prendre.

Task 1: Verify Windows Terminal is installed and identify the package

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-AppxPackage Microsoft.WindowsTerminal | Select-Object Name, Version, PackageFullName"
Name                          Version      PackageFullName
----                          -------      ---------------
Microsoft.WindowsTerminal     1.21.3471.0  Microsoft.WindowsTerminal_1.21.3471.0_x64__8wekyb3d8bbwe

Ce que cela signifie : Vous voyez le package Windows Terminal installé et sa version.

Décision : Si cela manque ou est ancien, arrêtez de déboguer les paramètres. Mettez à jour d’abord ; le comportement change selon les versions.

Task 2: Locate the settings file path you’re actually editing

cr0x@server:~$ powershell.exe -NoProfile -Command "$p = Join-Path $env:LOCALAPPDATA 'Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json'; Test-Path $p; $p"
True
C:\Users\cr0x\AppData\Local\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json

Ce que cela signifie : Le fichier de paramètres existe à l’emplacement canonique de l’application packagée.

Décision : Si Test-Path est False, vous êtes peut-être sur un autre canal d’installation ou le fichier n’a pas été créé. Ouvrez Terminal une fois, ou trouvez le dossier de package correct.

Task 3: Validate settings.json is valid JSON (catch trailing commas fast)

cr0x@server:~$ powershell.exe -NoProfile -Command "$p = Join-Path $env:LOCALAPPDATA 'Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json'; Get-Content $p -Raw | ConvertFrom-Json | Out-Null; 'JSON OK'"
JSON OK

Ce que cela signifie : Votre fichier de paramètres se parse. S’il ne le fait pas, Terminal peut silencieusement ignorer des parties ou revenir aux valeurs par défaut selon l’erreur.

Décision : Corrigez le JSON avant de toucher à autre chose. Un JSON invalide rend tous les autres symptômes aléatoires.

Task 4: List profiles and their GUIDs to avoid editing the wrong one

cr0x@server:~$ powershell.exe -NoProfile -Command "$p = Join-Path $env:LOCALAPPDATA 'Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json'; $j = Get-Content $p -Raw | ConvertFrom-Json; $j.profiles.list | Select-Object name, guid, source"
name                    guid                                   source
----                    ----                                   ------
PowerShell              {61c54bbd-c2c6-5271-96e7-009a87ff44bf} Windows.Terminal.PowershellCore
Windows PowerShell      {0caa0dad-35be-5f56-a8ff-afceeeaa6101} Windows.Terminal.Powershell
Ubuntu                  {2c4de342-38b7-51cf-b940-2309a097f518} Windows.Terminal.Wsl

Ce que cela signifie : Vous avez plusieurs variantes de PowerShell plus WSL. Les GUID sont les poignées stables.

Décision : Choisissez celui que vous voulez modifier et ciblez-le par GUID, pas à l’aveugle par nom.

Task 5: Check which profile is currently the default

cr0x@server:~$ powershell.exe -NoProfile -Command "$p = Join-Path $env:LOCALAPPDATA 'Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json'; (Get-Content $p -Raw | ConvertFrom-Json).defaultProfile"
{61c54bbd-c2c6-5271-96e7-009a87ff44bf}

Ce que cela signifie : Terminal ouvre PowerShell 7 par défaut (dans cet exemple GUID).

Décision : Définissez explicitement le profil par défaut pour correspondre à votre flux de travail sûr le plus courant. Ne laissez pas cela au hasard.

Task 6: Inspect where the profile starts (startingDirectory)

cr0x@server:~$ powershell.exe -NoProfile -Command "$p = Join-Path $env:LOCALAPPDATA 'Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json'; $j = Get-Content $p -Raw | ConvertFrom-Json; ($j.profiles.list | Where-Object name -eq 'PowerShell').startingDirectory"
C:\Users\cr0x

Ce que cela signifie : Votre profil PowerShell s’ouvre dans votre répertoire utilisateur.

Décision : Si vous faites de l’ops, envisagez de démarrer dans un C:\ops dédié ou un dossier de repo avec scripts et notes. Moins de moments « où est ce fichier ? ».

Task 7: Identify which shell you’re actually running (pwsh vs powershell)

cr0x@server:~$ powershell.exe -NoProfile -Command "$PSVersionTable.PSVersion.ToString()"
5.1.22621.2506

Ce que cela signifie : Cette commande s’est exécutée dans Windows PowerShell 5.1 (parce que nous avons invoqué powershell.exe).

Décision : Si vous pensez être sur PowerShell 7 mais que ce n’est pas le cas, les modules et les valeurs par défaut TLS peuvent différer. Utilisez pwsh.exe explicitement dans les profils qui en ont besoin.

Task 8: Confirm PowerShell 7 availability (and its path)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-Command pwsh | Select-Object Source, Version"
Source                         Version
------                         -------
C:\Program Files\PowerShell\7\pwsh.exe 7.4.1

Ce que cela signifie : PowerShell 7 est installé et détectable.

Décision : Pointez la commandline de votre profil PowerShell 7 directement vers ce chemin pour éviter les bizarreries de PATH.

Task 9: List installed WSL distributions (and choose a stable target)

cr0x@server:~$ powershell.exe -NoProfile -Command "wsl.exe -l -v"
  NAME            STATE           VERSION
* Ubuntu          Running         2
  Debian          Stopped         2

Ce que cela signifie : WSL contient Ubuntu et Debian. Ubuntu est par défaut (astérisque) et en cours d’exécution.

Décision : Si vous avez plusieurs distributions, créez des profils séparés épinglés avec wsl.exe -d Ubuntu etc. Ne comptez pas sur la distro par défaut.

Task 10: Measure startup time of a shell to detect “slow profile” scripts

cr0x@server:~$ powershell.exe -NoProfile -Command "Measure-Command { pwsh.exe -NoProfile -Command \"exit\" } | Select-Object TotalMilliseconds"
TotalMilliseconds
-----------------
142.8817

Ce que cela signifie : Démarrer PowerShell 7 sans charger de profil est rapide.

Décision : Si -NoProfile est rapide mais que le démarrage normal est lent, votre script de profil est coupable. Corrigez vos dotfiles, pas Terminal.

Task 11: Identify if your PowerShell profile is doing expensive work

cr0x@server:~$ pwsh.exe -NoProfile -Command '$PROFILE; Test-Path $PROFILE; Get-Content $PROFILE -TotalCount 20'
C:\Users\cr0x\Documents\PowerShell\Microsoft.PowerShell_profile.ps1
True
Import-Module posh-git
Import-Module oh-my-posh
oh-my-posh init pwsh --config "$env:POSH_THEMES_PATH\jandedobbeleer.omp.json" | Invoke-Expression

Ce que cela signifie : Le profil importe des modules et initialise un thème d’invite. Cela peut être lent, surtout si les modules sont sur un chemin réseau ou si l’antivirus est agressif.

Décision : Mettez en cache l’initialisation du prompt, chargez les modules paresseusement, ou créez un profil « minimal » pour l’astreinte.

Task 12: Check whether you’re accidentally loading network home paths (latency land)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-Item env:USERPROFILE, env:HOMEDRIVE, env:HOMEPATH, env:HOMESHARE | Format-Table -AutoSize"
Name        Value
----        -----
USERPROFILE C:\Users\cr0x
HOMEDRIVE   C:
HOMEPATH    \Users\cr0x
HOMESHARE

Ce que cela signifie : Aucune partagée réseau de profil utilisateur n’est configurée (dans cet exemple).

Décision : Si HOMESHARE pointe vers un chemin UNC, attendez-vous à des invites lentes si votre profil touche au répertoire utilisateur au démarrage.

Task 13: Verify font availability (catch “I set a font that isn’t installed”)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts' | Select-String -Pattern 'Cascadia|Nerd|Caskaydia' -SimpleMatch"
Cascadia Mono (TrueType)    REG_SZ    CascadiaMono.ttf
Cascadia Code (TrueType)    REG_SZ    CascadiaCode.ttf

Ce que cela signifie : Les polices Cascadia existent. Vos paramètres qui s’y réfèrent devraient fonctionner.

Décision : Si le nom de police choisi n’apparaît pas, installez-la ou cessez d’y faire référence. Terminal ne trouvera pas magiquement une police inventée.

Task 14: Detect binding conflicts by grepping for duplicated keys

cr0x@server:~$ powershell.exe -NoProfile -Command "$p = Join-Path $env:LOCALAPPDATA 'Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json'; $raw = Get-Content $p -Raw; ($raw | Select-String -Pattern '\"keys\"' | Measure-Object).Count"
24

Ce que cela signifie : Il y a 24 entrées de raccourcis dans le fichier (en comptant les occurrences du mot "keys").

Décision : Si vous avez expérimenté, vous avez probablement des collisions. Consolidez. Le meilleur ensemble de raccourcis est celui que vous pouvez expliquer à un collègue.

Task 15: Validate your SSH config is being used (profile correctness)

cr0x@server:~$ wsl.exe -d Ubuntu -- bash -lc "grep -nE '^(Host|  HostName|  User|  IdentityFile)' ~/.ssh/config | head -n 20"
1:Host bastion-prod
2:  HostName bastion.prod.example
3:  User ops
4:  IdentityFile ~/.ssh/id_ed25519_ops

Ce que cela signifie : Votre configuration SSH définit un bastion avec une clé spécifique.

Décision : Construisez un profil Terminal qui exécute ssh bastion-prod pour que les opérateurs ne tapent pas les hostnames à 3 h du matin.

Guide de diagnostic rapide : quoi vérifier en premier/deuxième/troisième

Voici le triage rapide quand Windows Terminal « semble lent », l’entrée de texte a du lag, les onglets mettent une éternité ou le copier/coller se comporte de façon incohérente. Vous cherchez le goulot, pas les sensations.

Première étape : isolez si c’est Terminal ou le shell

1. Démarrez un shell sans profil (PowerShell : pwsh -NoProfile). S’il est rapide, vos scripts de profil sont en cause.
2. Démarrez une session minimale type cmd (ou un profil PowerShell minimal). Si l’UI du terminal est toujours lente, examinez le rendu/la police et les facteurs GPU/Bureau à distance.
3. Essayez WSL avec une commande minimale (comme wsl -d Ubuntu -- echo ok). Si c’est lent, le démarrage WSL ou l’intégration du système de fichiers est impliqué.

Deuxième étape : vérifiez les trois principales sources de perte de temps

1. Scripts de profil accédant au réseau : import de modules depuis des chemins UNC, git status dans de gros repos, thèmes d’invite lisant des fichiers sur des dossiers synchronisés.
2. Antivirus en train d’analyser : surtout sur les répertoires de modules ou les dossiers utilisateurs synchronisés avec OneDrive.
3. Comportement de fallback des polices/glyphes : les polices patchées ou glyphes manquants peuvent causer des saccades de rendu et un désalignement du curseur.

Troisième étape : identifiez les multiplicateurs spécifiques à l’environnement

1. Sessions Bureau à distance : l’accélération graphique et l’intégration du presse-papiers se comportent différemment ; vous pouvez voir un lag d’entrée qui n’existe pas localement.
2. Historique d’affichage énorme et sorties lourdes : certaines CLI déversent des milliers de lignes ; le rendu devient le goulot. Réduisez la sortie ou ajustez le scrollback.
3. Cas limites ConPTY : des anciennes apps console peuvent mal se comporter ; essayez de les lancer dans la console classique comme vérification.

Si vous faites cela dans l’ordre, vous arrêtez de deviner. Vous arrêtez aussi d’« optimiser » la mauvaise chose.

Erreurs courantes : symptômes → cause racine → correctif

1) « Mon prompt est lent ; Terminal doit être lent. »

Symptômes : Nouveaux onglets prennent des secondes. Le curseur apparaît, mais vous ne pouvez pas taper pendant un moment. Pics CPU au démarrage.

Cause racine : Votre profil shell effectue des travaux coûteux : git status dans de gros dossiers, import de modules, initialisation de thème, vérifications réseau, appels d’outils cloud.

Correctif : Créez deux profils : « minimal » (astreinte) avec -NoProfile ou un profil léger, et « full » pour le dev quotidien. Chargez les modules à la demande et évitez les appels réseau dans le chemin du prompt.

2) « Mes icônes sont des carrés ; Windows Terminal est cassé. »

Symptômes : Séparateurs Powerline affichés en tofu (□). Dessin de boîtes incorrect. Alignement de l’invite décalé.

Cause racine : Police manquante de glyphes ou fallback incohérent. Parfois vous avez défini un nom de police qui n’est pas installé.

Correctif : Installez la bonne police et référencez son nom exact, ou cessez d’utiliser un prompt riche en icônes. Réglez aussi lineHeight si nécessaire pour éviter le chevauchement.

3) « Le copier/coller est incohérent et je colle dans la prod. »

Symptômes : La sélection copie parfois, parfois non. Le clic droit colle parfois. Ctrl+V se comporte différemment entre panneaux/apps.

Cause racine : Paramètres mélangés entre Terminal, shell et sessions distantes ; plus la mémoire musculaire d’autres terminaux.

Correctif : Décidez d’une politique et appliquez-la dans les paramètres : bindings de copier/coller cohérents et comportement de sélection uniforme. Rendez le profil prod visuellement distinct pour que vos yeux détectent le « mauvais panneau ».

4) « Les onglets se sont dupliqués ou les profils ont changé après une mise à jour. »

Symptômes : De nouveaux profils par défaut apparaissent ; vos noms soignés sont enterrés ; le profil par défaut bascule.

Cause racine : Profils auto-générés par les shells installés ; votre defaultProfile n’était pas fixé explicitement ; vous vous êtes fié au nom plutôt qu’au GUID.

Correctif : Définissez defaultProfile sur le GUID voulu. Élaborez profiles.list. Supprimez ou masquez les profils auto-générés que vous ne voulez pas exposer.

5) « WSL démarre, mais les opérations de fichiers sont douloureusement lentes. »

Symptômes : Git status ralenti. Installations Node interminables. Tout dans /mnt/c est lent.

Cause racine : Vous faites des charges de travail Linux sur le montage du système de fichiers Windows (/mnt/c), qui est plus lent que le système de fichiers ext4 de la distro WSL pour les tâches riches en métadonnées.

Correctif : Gardez les repos dans le système de fichiers WSL (par ex. ~/src). Utilisez un profil qui démarre là.

6) « Les raccourcis clavier ne fonctionnent pas dans les sessions distantes. »

Symptômes : Les raccourcis de split de panneau ne déclenchent pas ; certaines combinaisons sont interceptées.

Cause racine : Mappage de touches RDP/client, raccourcis au niveau OS ou interceptions par l’application.

Correctif : Réattribuez les combos conflictuels dans Terminal, et choisissez des raccourcis qui survivent à votre outil distant. Testez sur le chemin réel utilisé par les opérateurs.

Trois mini-récits d’entreprise (parce que la réalité a des rebondissements)

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Ils migraient une pipeline de build-and-release de Windows PowerShell legacy vers PowerShell 7. Localement, tout semblait correct. Dans Windows Terminal, l’ingénieur avait un profil « PowerShell » et supposait qu’il s’agissait du nouveau. Le nom correspondait à son modèle mental : PowerShell égal moderne.

Pendant un hotfix en production, ils ont ouvert un nouvel onglet et exécuté un script qui récupérait des dépendances en fonction des valeurs TLS par défaut. Ça fonctionnait sur leur laptop lorsqu’ils testaient en pwsh. Lors de l’incident, ça échouait dans leur onglet parce que c’était en fait Windows PowerShell 5.1 avec des valeurs par défaut et un comportement de module différents. Le message d’erreur n’était pas dramatique ; c’était pire : il était ambigu. Les gens ont commencé à blâmer le dépôt d’artefacts.

Ils ont « réparé » en réessayant et en contournant temporairement des validations d’une manière qui a mis la sécurité mal à l’aise. Le hotfix est parti, mais la revue post-incident a été pénible. La cause racine n’était pas le dépôt. C’était le mauvais profil de terminal. L’onglet ressemblait à tous les autres onglets.

La remediation a été ennuyeuse et efficace : noms de profils explicites (« PowerShell 7 » vs « Windows PowerShell »), commandlines épinglées et profil par défaut défini par GUID. Ils ont aussi changé le titre d’onglet pour inclure PS7 ou PS5. Après ça, le mode d’échec a cessé d’exister. Pas réduit. Éliminé.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une équipe voulait que leur prompt affiche tout : branche git, état dirty, contexte Kubernetes, compte cloud et l’ID du ticket d’incident en cours. Ça faisait de belles captures d’écran et démonstrations. Ça exécutait aussi une petite quantité de travail à chaque rendu de prompt — donc à chaque commande, chaque Enter, chaque complétion.

Pour accélérer, ils ont ajouté du caching. Bonne idée en théorie. Le cache vivait dans le répertoire de profil utilisateur, qui sur les machines d’entreprise était synchronisé et parfois redirigé. En conditions normales c’était ok. Sous jitter VPN, les lectures de cache sont devenues lentes, et taper est soudain devenu saccadé. Les gens ont blâmé le rendu de Windows Terminal.

Le vrai problème a émergé quand un ingénieur a essayé de réduire la sortie pendant un incident en ouvrant des panneaux et en tailant des logs. Le thème d’invite réévaluait constamment des contextes réseau ; le cache thrashait. Le terminal était réactif, le shell ne l’était pas, et l’opérateur se battait contre son propre prompt.

Ils sont revenus à un prompt minimal pour les profils ops : branche git seulement, pas de recherches réseau, pas de contexte cloud. Ils ont gardé le prompt sophistiqué pour les profils dev. L’optimisation n’était pas le méchant ; optimiser au mauvais endroit l’était. Deuxième blague courte : Le prompt le plus rapide est celui qui n’essaie pas de mériter une prime de performance.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre organisation avait l’habitude apparemment excessive de maintenir un fragment settings.json versionné pour les ingénieurs d’astreinte. Ce n’était pas obligatoire, mais fortement recommandé. Le fragment définissait un petit ensemble de profils : « On-call PowerShell (minimal) », « WSL tooling », « SSH bastion (prod) » et « SSH bastion (staging) ».

Le profil SSH prod faisait quelque chose sans glamour : il définissait un titre d’onglet bruyant, un schéma de couleurs plutôt rougeâtre et une commande de démarrage personnalisée qui affichait une courte bannière d’avertissement. Il appliquait aussi une forme de curseur différente. On en plaisantait jusqu’à la première fois où ça a empêché une erreur.

Pendant une panne, un ingénieur avait quatre panneaux ouverts : requête métrique, tail de logs, SSH vers staging, SSH vers prod. Il a failli coller une commande de nettoyage réservée à staging dans prod. Il a remarqué la forme du curseur et le titre d’onglet à la dernière seconde. Pas d’exploits, pas de drame — juste une barrière de sécurité qui a fait son travail.

La review postmortem a été presque anticlimaxtique : « On a failli faire quelque chose de mal, mais le profil de terminal nous a arrêtés. » C’est ce que vous voulez. La fiabilité, c’est surtout l’absence d’histoires excitantes.

Checklists / plan pas à pas

Plan A : Construire un ensemble de profils sensé en moins d’une heure

1. Inventoriez vos shells : PowerShell 5.1, PowerShell 7, distributions WSL, usages SSH.
2. Créez quatre profils de base :
   • PowerShell 7 (quotidien)
   • PowerShell 7 (minimal / on-call)
   • WSL (tooling) démarrant dans ~/src
   • SSH : bastion (prod) avec visuels bruyants
3. Épinglez defaultProfile sur l’option commune la plus sûre (souvent PS7 minimal).
4. Choisissez une police et tenez-vous-y. Si vous devez utiliser les Nerd Fonts, faites-le intentionnellement et vérifiez les glyphes.
5. Définissez 6–10 raccourcis que vous utilisez vraiment : nouvel onglet, fermer onglet (avec confirmation), split pane, focus pane, recherche, copier, coller.
6. Testez le scénario mauvais-panneau : ouvrez les profils prod/staging côte à côte et assurez-vous de pouvoir distinguer instantanément lequel est lequel.
7. Validez le JSON après modifications. Ne vous fiez pas à vos yeux.

Plan B : Corriger la lenteur sans casser votre flux

1. Mesurez : chronométrez le démarrage pwsh -NoProfile versus normal. S’il y a un écart, les scripts de profil sont coupables.
2. Minimisez : créez un profil minimal et utilisez-le quand la latence compte.
3. Supprimez les appels réseau des prompts et du démarrage. Pas de vérifications de contexte cloud, pas de checks auto-update, pas de git status dans les gros repos par défaut.
4. Vérifiez police et rendu seulement après avoir prouvé que le shell démarre vite.
5. Standardisez : gardez un settings baseline connu bon. La dérive est la façon dont « c’est lent sur ma machine » devient un sport d’équipe.

Plan C : Rendre cela reproductible en équipe

1. Définissez un fragment settings.json de base (profils, schémas, bindings).
2. Décidez ce qui est personnel : image d’arrière-plan, opacité, thèmes expérimentaux—gardez-les hors du baseline.
3. Documentez le contrat : ce que signifie le profil « On-call », ce qu’il charge et ce qu’il n’inclut volontairement pas.
4. Relisez les changements comme du code. Les raccourcis et visuels prod ne devraient pas être « n’importe quoi ».

Une idée de fiabilité à garder en tête

Idée paraphrasée (attribuée à John Allspaw) : « L’apprentissage sans blâme fonctionne mieux quand vous vous concentrez sur la façon dont le contexte local des personnes rendait les actions raisonnables à ce moment. »

Les erreurs de terminal sont souvent des erreurs de contexte : mauvais panneau, mauvaise identité, mauvais shell. Votre travail est de rendre l’action correcte facile et l’action erronée évidente.

FAQ

1) Dois-je modifier les paramètres via l’interface ou via settings.json ?

Utilisez l’interface pour des ajustements rapides ; utilisez le JSON pour tout ce que vous voulez reproduire, relire ou annuler. Si vous tenez à la cohérence, le JSON est la source de vérité.

2) Pourquoi ai-je plusieurs profils PowerShell ?

Parce que vous avez probablement Windows PowerShell (5.1) et PowerShell 7 installés, et Terminal peut les détecter automatiquement. Renommez-les clairement et épinglez les commandlines pour toujours savoir ce que vous exécutez.

3) Quelle est la meilleure police ?

La meilleure police est celle que vous pouvez lire à 3 h du matin et qui rend correctement vos symboles. Commencez par Cascadia Mono. Passez à une Nerd Font seulement si votre prompt a réellement besoin d’icônes.

4) Mon thème d’invite est beau mais lent. Que faire ?

Scindez en deux profils : un profil ops minimal et un profil dev complet. Supprimez les recherches réseau lors du rendu du prompt et évitez les opérations git coûteuses par défaut.

5) Comment arrêter de coller dans le mauvais panneau ?

Rendez les environnements visuellement distincts (schéma, titre, curseur). Attribuez des raccourcis focus-pane que vous pouvez atteindre sans réfléchir. Et gardez les profils prod volontairement « bruyants ».

6) Pourquoi WSL est rapide sur les chemins Linux mais lent sur /mnt/c ?

Parce que les charges de travail riches en métadonnées (git, npm, builds à petits fichiers) sont plus lentes sur le montage du système de fichiers Windows. Mettez les repos dans le système de fichiers WSL et démarrez votre profil WSL là-bas.

7) Pourquoi mon profil par défaut a-t-il changé ?

Les mises à jour et nouvelles installations de shells peuvent ajouter des profils. Si vous n’avez pas défini defaultProfile explicitement par GUID, vous avez laissé la décision au hasard. Épinglez-le.

8) Comment garder les raccourcis cohérents entre machines ?

Conservez un settings.json de base (ou un fragment) sous contrôle de version et appliquez-le sur les machines. Évitez la randomisation par appareil pour tout ce qui affecte la navigation et la sécurité.

9) L’accélération GPU cause-t-elle des problèmes ?

Généralement elle aide. Quand elle pose problème, cela se manifeste par des glitches de rendu avec certaines polices ou en sessions distantes. Prouvez d’abord que le shell est rapide ; puis testez avec une police plus simple et moins d’effets visuels.

Prochaines étapes que vous ferez réellement

1. Créez un profil on-call minimal (PowerShell 7 avec -NoProfile ou un script de profil léger). Faites-en le défaut pour le travail d’incident.
2. Renommez et épinglez vos profils pour ne plus jamais confondre PS5 vs PS7 ou staging vs prod.
3. Choisissez une police, vérifiez qu’elle est installée et arrêtez de courir après des glyphes inutiles.
4. Standardisez 6–10 raccourcis et entraînez-vous jusqu’à ce qu’ils deviennent automatiques. Sous stress, vos mains doivent connaître la route.
5. Exécutez le guide de diagnostic rapide la prochaine fois que Terminal « semble lent ». Mesurez d’abord. Puis corrigez le vrai goulot.

Si vous ne faites qu’une chose : rendez la prod visuellement bruyante et votre profil on-call ennuyeux. C’est du professionnalisme déguisé en esthétique.