Dotfiles + Claude Code = mon petit atelier de config

💻 Nouvelle machine, nouvelles habitudes

Comme je le racontais dans mon article précédent (n’hésite pas à le lire avant si ce n’est pas déjà fait), je me suis pris un nouveau laptop en août 2025. Une nouvelle machine, c’est toujours une bonne occasion de revoir ses outils, ses habitudes, et d’en découvrir de nouvelles.

J’ai changé pas mal de choses, et entre autres, je suis passé de zsh à fish. Plusieurs collègues l’utilisaient, l’autocomplétion avait l’air sympa, traite-moi de fashion victim si tu veux, mais j’avais envie d’essayer.

Parmi les nombreuses différences entre fish et zsh, il y a la façon de définir ses propres commandes. Fish gère les alias, mais il a surtout un système de fonctions bien plus riche : tu peux ajouter une description, personnaliser l’autocomplétion, et ainsi de suite.

Par exemple, voici le petit alias zsh gb que j’avais pour passer d’une branche git à l’autre :

alias gb='git branch'

Et voici la fonction fish gb que je me suis créée :

# Now I have a description
function gb --description "List branches or switch to branch"
  if test (count $argv) -eq 0
    # Without argument: list branches
    git branch
  else
    # With argument, switch.
    git switch $argv
  end
end

# Autocompletion branches, sorted by most recently used
complete -c gb -f -a '(git for-each-ref --sort=-committerdate refs/heads --format="%(refname:short)")'

Voilà, c’est subtil, mais franchement agréable. Une fois lancé, j’ai voulu convertir tous mes autres alias en fonctions fish. Avec des descriptions, de l’autocomplétion, des paramètres. Toutes ces petites choses qui allaient me rendre plus productif, ou au moins m’en donner l’illusion : la satisfaction d’un setup taillé sur mesure.

Sauf qu’entre mes alias git, mes alias système et tout ce que j’avais accumulé au fil des années, ça faisait plus de 80 trucs à migrer. Hors de question de faire ça à la main.

🤖 Au secours Claude Code

À cette époque, j’utilisais Claude Code de plus en plus. J’ai eu mon petit moment « eurêka » en réalisant que Claude Code était bien plus qu’un assistant de code pour projets logiciels. Une fois ouvert dans un dossier, il peut se servir de tout ce qui traîne sur ta machine : lancer des commandes, lire et écrire des fichiers, utiliser d’autres outils. Ce n’est pas qu’une histoire de code, c’est un compagnon d’automatisation à tout faire. Migrer mes alias zsh vers des fonctions fish, c’était le boulot parfait pour lui.

Une fois que ça a été fait, j’en ai voulu plus. Je me suis mis à penser à toutes les autres configs que je pourrais gérer comme ça : mon terminal, mon éditeur, mon setup git. Une chose me chiffonnait quand même : où ouvrir Claude Code pour ce genre de boulot ?

Quand je bosse sur un projet, c’est simple, je l’ouvre dans le dossier du projet. Mais pour des trucs système, des configs, des fonctions shell, je vais où ? Dans ~/.config ? Pas bête, mais pas pratique : certaines configs, comme celle de git, se trouvent directement dans le dossier personnel. J’ai donc essayé d’ouvrir Claude Code dans mon ~, et il m’a affiché un avertissement :

Je crois qu’il affiche cet avertissement pour n’importe quel projet aujourd’hui, mais à l’époque, je suis quasi sûr qu’il y en avait un spécifique au dossier personnel. Ouvrir un agent IA dans mon dossier personnel, c’est lui donner accès en lecture et en écriture à tout : mes clés SSH, mes tokens, mes projets pro, mes photos… Même si je faisais totalement confiance à cet outil (et soyons honnêtes, ce n’est pas le cas), ça fait beaucoup trop.

🦸 Les dotfiles à la rescousse

Je me suis souvenu de ce truc dont j’entendais parler depuis tant d’années : les dotfiles.

Jusque-là, ça n’avait jamais vraiment fait tilt. J’avais toujours cru que c’était pour les gens qui veulent installer une nouvelle machine vite fait, ou synchroniser leurs configs entre plusieurs ordis. Je n’ai qu’une seule machine, et je fais des sauvegardes complètes régulières, donc je n’ai jamais vraiment eu ce besoin.

Mon cas d’usage était différent : je voulais un endroit dédié pour travailler la configuration de mon système. Un dossier que je peux ouvrir avec Claude Code sans lui donner accès à tout le reste. Un dossier que je peux publier sur GitHub, en m’assurant avant qu’il n’y a rien de sensible dedans.

C’est en gros ce que sont les dotfiles : rassembler toutes tes configs au même endroit, versionner le tout avec git et le publier en ligne.

Sauf qu’il y a un hic : ces fichiers doivent se trouver à des endroits bien précis pour fonctionner. Ma config git doit être dans ~/, mes fonctions fish dans ~/.config/fish/, mes réglages Claude dans ~/.claude/.

📁 Coucou Stow

C’est là qu’intervient GNU Stow, un gestionnaire de liens symboliques qui existe depuis 1993. Ce truc est plus vieux que certains des outils que je configure avec.

L’idée est simple : tu ranges tes configs par outil dans des sous-dossiers, et dans chaque sous-dossier, tu recrées l’arborescence que tu veux dans ton dossier personnel, comme ça :

dotfiles/
├── fish/
│   └── .config/
│       └── fish/
│           ├── conf.d/
│           │   └── 30_keybinding_alt_h_help.fish
│           └── functions/
│               └── gb.fish
├── ghostty/
│   └── .config/
│       └── ghostty/
│           └── config
├── git/
│   ├── .gitconfig
│   └── .gitignore_global
└── vscode/
    └── .config/
        └── Code/
            └── User/
                └── keybindings.json

Chaque dossier d’outil reproduit l’arborescence dont cet outil a besoin dans ton dossier personnel. Par exemple, fish/ contient .config/fish/... parce que c’est là que fish s’attend à trouver sa config.

Quand tu lances stow *, il crée dans ton dossier personnel des liens symboliques qui pointent vers tes dotfiles :

~/
├── .config/
│   ├── fish/
│   │   ├── conf.d/
│   │   │   └── 30_keybinding_alt_h_help.fish -> ../../../../dotfiles/fish/.config/fish/conf.d/30_keybinding_alt_h_help.fish
│   │   └── functions/
│   │       └── gb.fish -> ../../../../dotfiles/fish/.config/fish/functions/gb.fish
│   ├── ghostty/
│   │   └── config -> ../../../dotfiles/ghostty/.config/ghostty/config
│   └── Code/
│       └── User/
│           └── keybindings.json -> ../../../../dotfiles/vscode/.config/Code/User/keybindings.json
├── .gitconfig -> dotfiles/git/.gitconfig
└── .gitignore_global -> dotfiles/git/.gitignore_global

Il existe d’autres outils comme chezmoi ou yadm qui font des choses similaires, avec plus de fonctionnalités. Je n’ai pas pris le temps de les regarder, la méthode GNU me suffisait largement.

⚡ Mon nouveau workflow

Avec ce setup, j’ai découvert petit à petit, et assez naturellement, un nouveau workflow.

Maintenant, dès que j’ai besoin d’améliorer mon installation, j’ouvre Claude Code dans mon dossier dotfiles et je prompte. La plupart du temps, le modèle Haiku suffit largement pour ces petites tâches.

✨ Quelques exemples tout bêtes

Crée une fonction fish gb qui liste les branches quand on l’appelle sans argument, et qui bascule sur une branche quand on lui en passe une. Ajoute une autocomplétion qui liste les branches triées par ordre d’utilisation récente.

Quelques secondes plus tard, j’obtiens exactement ce que je te montrais plus haut.

Ajoute des raccourcis clavier dans VS Code pour gérer le multi-curseur, alt+r pour ajouter, alt+shift+r pour enlever.

Il modifie keybindings.json, c’est réglé. Je n’ai pas besoin de connaître le nom que VS Code donne à cette fonctionnalité, je lui fais confiance pour trouver. Si ça part en vrille, je reviens en arrière avec git.

Ajoute à Ghostty les mêmes raccourcis clavier que dans VS Code pour découper les panneaux horizontalement et verticalement.

Comme Claude Code a accès à toutes mes configs, il peut en lire une et appliquer la même logique à une autre.

💭 Ce que ça change

Avant tout ça, créer une fonction shell, c’était un micro-projet : trouver la doc, écrire le truc, tester, débugger. Maintenant, j’ouvre mon petit atelier de config, je décris ce que je veux et paf, je l’ai. Et c’est encore plus fluide depuis que j’utilise Handy pour dicter mes prompts. Fini les « je le ferai plus tard », je le fais tout de suite, parce que je sais que ce sera simple et rapide.

Résultat : je me crée beaucoup plus de raccourcis, de fonctions et d’outils qu’avant. Et mes raccourcis clavier sont bien plus cohérents d’un outil à l’autre.

Même pour des configs qui ne sont pas dans mes dotfiles, j’ouvre quand même Claude Code depuis ce dossier. Besoin de changer un raccourci GNOME ? Je prompte, il utilise gsettings, c’est réglé.

La plupart du temps, pour les choses simples, ça marche et je ne me pose pas de questions. C’est un piège, cela dit. Les modèles d’IA se trompent. Pour les trucs plus complexes, je prends le temps de relire le code généré, mais en général, il n’y en a pas des tonnes. Et comme je publie tout sur GitHub, j’essaie de ne pas commiter n’importe quoi, ce qui m’oblige à rester vigilant.

🧰 Sers-toi dans l’atelier

Depuis que je m’y suis mis, j’ai eu plein d’occasions de partager des bouts de config avec des collègues. Avant, je copiais-collais la config dans Slack. Et quand quelqu’un demandait sur les réseaux sociaux, partager du code était encore plus pénible. Maintenant, j’envoie juste un lien vers le fichier sur mon GitHub.

Et avec cet article, j’ai enfin l’occasion de partager avec toi aussi. Rien de révolutionnaire, juste une poignée de petits trucs que je trouve amusants et pratiques. Sers-toi, c’est cadeau.

🆘 Alt+h dans fish : l’aide instantanée

Au lieu de taper --help, d’appuyer sur entrée, de lire la sortie, puis de remonter avec la flèche du haut pour enlever --help, j’appuie sur Alt+h. Ça lance la commande courante avec --help à la fin, affiche la sortie, et me remet sur ma ligne de commande avec ce que j’avais tapé, intact.

🔗 fish/.config/fish/conf.d/30_keybinding_alt_h_help.fish

L’idée me vient du raccourci intégré Alt+s, qui ajoute ou enlève sudo au début d’une commande. J’en ai fait quelques autres sur le même principe, pour ajouter ou enlever des choses à la fin d’une commande :

• Alt+j pour -F json : 🔗 fish/.config/fish/conf.d/30_keybinding_alt_j_json.fish
• Alt+k pour | jless : 🔗 fish/.config/fish/conf.d/30_keybinding_alt_k_jless.fish
• Alt+l pour | less : 🔗 fish/.config/fish/conf.d/30_keybinding_alt_l_less.fish

⭐ Mon prompt de terminal avec Starship

J’ai passé pas mal de temps sur mon prompt de terminal avec Starship. Je suis daltonien, donc j’essaie de choisir des couleurs qui marchent pour moi et qui ont un bon contraste. J’ai aussi fait attention à prendre ces caractères de coins arrondis et de chevrons qui le rendent un peu plus stylé.

Mes derniers ajouts : des indicateurs sur la droite qui montrent si je suis en mode sudo et si mon 1Password est déverrouillé.

🔗 starship/.config/starship.toml

📊 La statusline de Claude Code

Claude Code te laisse personnaliser la barre de statut tout en bas. Il te donne quelques infos sur la session en cours, de quoi être créatif. La mienne affiche le dossier courant et la branche git, dans un style proche de mon prompt de terminal. J’y ai ajouté le modèle utilisé.

Et récemment, après avoir vu cette vidéo, j’y ai mis le pourcentage de remplissage de la fenêtre de contexte. Bonus : au-dessus de 59 %, il passe en rouge. Les gens appellent ça la « dumb zone », parce que Claude a tendance à devenir moins fiable quand le contexte est aussi rempli. Certains disent même qu’il faudrait repartir sur une nouvelle conversation dès 40 %.

🔗 claude/.claude/statusline.js

🕐 git reflog dans un TUI

Quand je me plante avec Git (ce qui arrive plus souvent que je ne voudrais l’avouer), git reflog est là pour me sauver la mise. Sauf que sa sortie par défaut est assez pénible à parcourir. Du coup, j’ai fait une fonction grf qui la transforme en CSV et l’envoie à tw, un TUI bien pratique pour naviguer dans des données tabulaires.

🔗 fish/.config/fish/functions/grf.fish

Ce ne sont que quelques exemples. Parcours le dépôt, fouille, sois curieux.

🔒 Petit point sécurité

Au début, je n’étais pas super chaud pour publier mes dotfiles. Je me demandais si certaines choses n’étaient pas trop personnelles ou trop sensibles.

Ce qui m’a rassuré, c’est que des gens font ça depuis quinze ans. Il suffit de faire attention à ce que tu commites et de rester organisé.

Pour git, j’ai une config privée à part (avec mon email, etc.) qui n’est pas dans le dépôt. Et j’ai aussi des fonctions fish qui restent en local, pour des trucs liés au boulot que je ne veux pas partager. Je les mets directement dans ~/.config/fish/functions/.

🏁 Conclusion

J’ai ignoré les dotfiles pendant 15 ans parce que je croyais que c’était réservé aux power users avec plusieurs machines. En fait, c’est surtout une bonne excuse pour se monter un petit atelier de config.

Ce qui a commencé comme un moyen d’utiliser Claude Code sur mes configs sans tout lui ouvrir est devenu quelque chose que j’ai vraiment plaisir à utiliser et entretenir. Le workflow est tellement fluide qu’il pousse à créer et à améliorer ses propres petits utilitaires. J’ai appris des choses que je n’aurais jamais explorées autrement : les descriptions de fonctions fish, la personnalisation de l’autocomplétion, les modules du prompt Starship… Ça m’a aussi poussé à rationaliser mes raccourcis clavier d’un outil à l’autre, à unifier les comportements, à réfléchir plus sérieusement à mon installation.

Se créer des configs et des raccourcis sur mesure, c’est une super façon de creuser des outils qu’on utilise tous les jours sans jamais vraiment les comprendre. Et une fois qu’on a commencé, c’est difficile de s’arrêter.

Si tu hésites comme j’ai hésité, commence par un seul fichier de config et regarde où ça te mène.

Voici les miens : github.com/hsablonniere/dotfiles

Pique sans complexe, propose sans retenue.