Mon workflow : Claude Code, WSL2 et Forgejo

Introduction

#

Un collègue m’a posé la question : « Tu utilises quoi comme IDE, ou comme workflow, quand tu travailles avec Claude ? »

La réponse est moins spectaculaire qu’on ne l’imagine : je n’ai pas d’IDE au centre. Je travaille dans un terminal, sous WSL2, avec Claude Code. VS Code reste à côté, pour relire et versionner.

C’est mon environnement de travail à Vienne Condrieu Agglomération, sur un poste Windows 11. Pour le parallèle, sur mon ordinateur portable personnel, un Framework 13, je suis sous Fedora 44, et c’est encore plus fluide ! Le système est installé directement sur la machine : il ne passe pas par la couche d’abstraction qu’ajoute WSL2 sous Windows 11.

Table des matières

#

• Les outils et leur rôle
• Configurer WSL2 avec une Debian 13 importée
• VS Code et WSL2
• Docker Desktop et l’intégration WSL
• Mon ~/.bashrc
• La boucle de travail
• Le contexte donné à Claude
• Les garde-fous
• Souveraineté et usages de l’IA, des pistes concrètes
• Et pour les dossiers SIG
• Conclusion

Les outils et leur rôle

#

Chaque outil a un rôle précis, et aucun ne cherche à faire le travail des autres.

%%{init: {"flowchart": {"nodeSpacing": 50, "rankSpacing": 50, "padding": 20}}}%%
graph TB
    subgraph WSL["WSL2 - Debian 13"]
        CC["Claude Code
terminal"]
        FS["Dépôts
~/code/forgejo"]
    end
    subgraph WIN["Windows 11"]
        DD["Docker Desktop"]
        VS["VS Code
relecture + Git"]
    end
    subgraph INT["Infrastructure interne"]
        FJ["Forgejo"]
        WP["Woodpecker CI"]
    end
    CC --> FS
    CC -->|"docker CLI"| DD
    FS <-->|"Remote WSL"| VS
    VS -->|"push"| FJ
    FJ -->|"déclenche"| WP
    style CC fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px,color:#000
    style VS fill:#bbdefb,stroke:#1565c0,stroke-width:2px,color:#000
    style DD fill:#bbdefb,stroke:#1565c0,stroke-width:2px,color:#000
    style FJ fill:#ffe0b2,stroke:#ef6c00,stroke-width:2px,color:#000
    style WP fill:#ffe0b2,stroke:#ef6c00,stroke-width:2px,color:#000

Configurer WSL2 avec une Debian 13 importée

#

WSL2 (Windows Subsystem for Linux 2) est une couche intégrée à Windows 11 qui fait tourner un vrai noyau Linux dans une machine virtuelle légère. Vous y utilisez une distribution Linux et ses outils directement depuis Windows, avec un accès croisé aux fichiers des deux systèmes.

Puristes de Linux, rangez vos fourches : cela ne remplace pas une bonne vieille distribution installée sur la machine, mais cela comble un peu le fossé entre le tout Windows et le tout Linux, surtout dans une collectivité territoriale, où une bonne partie du quotidien professionnel vit encore sous Windows.

1. Pourquoi importer plutôt qu’installer

#

La commande wsl --install est le chemin le plus simple : elle installe une distribution de la liste prédéfinie de Microsoft (wsl --list --online). Dans la majorité des cas, je préfère importer moi-même une archive, pour trois raisons :

• je choisis la version exacte de la distribution (ici Debian 13) ;
• je choisis où vit le disque virtuel de la distribution ;
• je peux recréer la même machine à l’identique, ou en monter plusieurs en parallèle (une par usage).

2. Récupérer l’archive

#

WSL sait importer une archive de système de fichiers racine. Pour Debian, j’utilise les images de conteneurs système du dépôt Proxmox : download.proxmox.com/images/system.

Je les range dans une arborescence dédiée côté Windows, avec un dossier pour les archives et un dossier pour les disques virtuels :

C:\Users\<utilisateur>\Documents\WSL\distro\
├── containers\   <- les archives téléchargées
│   └── debian-13-standard_13.6-1_amd64.tar.zst
└── storage\      <- les disques virtuels des distributions importées
    └── debian\

# Calculer l'empreinte de l'archive téléchargée
Get-FileHash C:\Users\<utilisateur>\Documents\WSL\distro\containers\debian-13-standard_13.6-1_amd64.tar.zst -Algorithm SHA512

3. Importer la distribution

#

Si WSL n’est pas encore présent sur votre poste, installez-le d’abord, sans distribution. Ouvrez un PowerShell en administrateur, puis redémarrez si Windows vous le demande :

# Installer WSL sans distribution par défaut
wsl --install --no-distribution

Mettez ensuite WSL à jour, puis importez l’archive depuis un PowerShell :

# Mettre WSL à jour
wsl --update

# Importer l'archive sous le nom "debian"
wsl --import debian C:\Users\<utilisateur>\Documents\WSL\distro\storage\debian C:\Users\<utilisateur>\Documents\WSL\distro\containers\debian-13-standard_13.6-1_amd64.tar.zst

# La définir comme distribution par défaut de la commande "wsl"
wsl --setdefault debian

# Se connecter en root dans le répertoire de base
wsl -d debian ~

La syntaxe générale est wsl --import <Nom> <Emplacement-Install> <Archive>.

4. Premier démarrage : locales et wsl.conf

#

Une fois dans la distribution (en root), configurez les locales :

dpkg-reconfigure locales
apt update && apt upgrade -y && apt install -y git

Le fichier /etc/wsl.conf règle le comportement de la distribution. Voici le mien :

cat > /etc/wsl.conf << 'EOF'
[boot]
systemd=true

[user]
default=<utilisateur>

[interop]
enabled=true
appendWindowsPath=true
EOF

Les modifications de wsl.conf ne sont prises en compte qu’au redémarrage de la distribution : nous y viendrons une fois l’utilisateur créé.

5. Initialiser la machine à la main

#

Une archive importée est une base minimale : il reste à créer votre utilisateur, à installer les outils de base, puis à configurer le shell, Vim et Claude Code. Remplacez <utilisateur> par votre propre nom d’utilisateur, ici comme dans wsl.conf.

Créer l’utilisateur et installer les outils de base. Toujours en root :

# Outils de base
apt install -y sudo git curl jq wget tar vim

# Utilisateur avec son dossier personnel et bash comme shell
useradd -m -s /bin/bash <utilisateur>
passwd <utilisateur>

# Droits d'administration via sudo
usermod -aG sudo <utilisateur>

Redémarrer la distribution. Depuis PowerShell, pour appliquer wsl.conf :

wsl --terminate debian
wsl -d debian

Vous arrivez directement avec votre utilisateur. Les commandes suivantes s’exécutent avec ce compte, sans sudo.

Configurer bash. Faites charger le ~/.bashrc par les shells de connexion :

cat > ~/.bash_profile << 'EOF_PROFILE'
if [ -f ~/.bashrc ]; then
    . ~/.bashrc
fi
EOF_PROFILE

Complétez ensuite ~/.bashrc avec vos alias et vos variables : le mien est détaillé plus bas, dans la section Mon ~/.bashrc.

Configurer Vim. Quelques réglages suffisent pour éditer confortablement :

cat > ~/.vimrc << 'EOF_VIM'
syntax on
set mouse=
set scrolloff=15
set autoindent
set tabstop=2
set shiftwidth=2
set expandtab
EOF_VIM

Installer Claude Code. L’installeur officiel place le binaire dans ~/.local/bin, à ajouter au PATH si besoin :

curl -fsSL https://claude.ai/install.sh | bash
export PATH="$HOME/.local/bin:$PATH"
claude --version

Ajouter la barre d’état. J’utilise ccstatusline, déclaré dans les réglages de Claude Code. Il passe par npx : Node.js doit donc être installé (j’utilise nvm).

mkdir -p ~/.claude
cat > ~/.claude/settings.json << 'EOF_CLAUDE'
{
  "statusLine": {
    "type": "command",
    "command": "npx -y ccstatusline@latest",
    "padding": 0
  }
}
EOF_CLAUDE

6. Configurer Git

#

git config --global credential.helper 'cache --timeout=1800' \
&& git config --global user.name "Votre Nom" \
&& git config --global user.email "vous@example.com" \
&& git config --global --list

7. Travailler dans le système de fichiers Linux

#

C’est la règle qui change le plus la vie : gardez vos dépôts dans le système de fichiers Linux (chez moi ~/code/forgejo), pas sous /mnt/c. Les accès aux fichiers Windows depuis WSL passent par une couche de traduction beaucoup plus lente, et Git comme les builds s’en ressentent.

mkdir -p ~/code/forgejo && cd ~/code/forgejo
git clone https://forge.example.fr/mon-compte/mon-projet.git

Pour ouvrir directement une session sur ce dossier depuis Windows :

wsl -d debian -u <utilisateur> --cd "/home/<utilisateur>/code/forgejo/"

8. Commandes wsl utiles au quotidien

#

VS Code et WSL2

#

VS Code est installé côté Windows. L’extension WSL de Microsoft lui permet d’ouvrir un dossier du système de fichiers Linux : l’éditeur reste dans Windows, mais les fichiers, le terminal et Git s’exécutent dans WSL.

Grâce à appendWindowsPath=true dans wsl.conf, les programmes Windows sont accessibles depuis WSL. J’ajoute malgré tout explicitement le dossier bin de VS Code au PATH dans mon ~/.bashrc, pour que la commande code soit toujours disponible :

# Intégration VS Code pour WSL
export PATH="$PATH:/mnt/c/Program Files/Microsoft VS Code/bin"

Ensuite, la routine est la suivante :

cd ~/code/forgejo/mon-projet
code .

VS Code s’ouvre sur le dépôt, connecté à WSL. Je m’en sers pour deux choses : relire ce que Claude a modifié, et le panneau Contrôle de code source pour suivre l’état Git, valider et pousser vers Forgejo.

Docker Desktop et l’intégration WSL

#

J’utilise Docker Desktop installé sur Windows, avec son intégration WSL. Le moteur Docker tourne côté Docker Desktop ; la commande docker est simplement disponible dans mon terminal WSL.

1. Activer l’intégration

#

Dans Docker Desktop : Settings → Resources → WSL Integration, puis activez votre distribution.

2. Vérifier depuis WSL

#

docker version
docker compose version
docker run --rm hello-world

Mon ~/.bashrc

#

Mon ~/.bashrc WSL part de ma configuration Linux habituelle, à laquelle j’ajoute quelques lignes propres à WSL et à mon poste. Voici l’essentiel :

# Alias de confort
alias ll='ls -alh'
alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'
alias g='git'
alias ga='git add'
alias gcm='git commit -m'
alias gpush='git push origin $(git rev-parse --abbrev-ref HEAD)'
alias gpull='git pull origin $(git rev-parse --abbrev-ref HEAD)'
alias dcup='docker compose up -d --no-build --remove-orphans'
alias dcd='docker compose down --remove-orphans'
alias z='zellij'
alias claude='claude --dangerously-skip-permissions'

# Éditeur
EDITOR=vim
VISUAL=$EDITOR
export EDITOR VISUAL

# Outils Python installés par pip --user
export PATH="$HOME/.local/bin:$PATH"

# Intégration VS Code pour WSL
export PATH="$PATH:/mnt/c/Program Files/Microsoft VS Code/bin"

# Plugins GDAL personnels
export GDAL_DRIVER_PATH="${GDAL_DRIVER_PATH:+${GDAL_DRIVER_PATH}:}$HOME/.gdal/plugins"

# Node : forcer IPv4 en priorité pour la résolution DNS
export NODE_OPTIONS="--dns-result-order=ipv4first"

# nvm
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"

La boucle de travail

#

Voici la boucle que j’applique sur un module, par exemple dans geo-api-v2 :

flowchart TD
    A["Besoin ou bug
(retour utilisateur, issue)"] --> B["Claude explore le code,
modifie, lance les tests"]
    B --> C["Génération du ZIP du module"]
    C --> D["J'importe le ZIP dans un vrai GEO
et je teste moi-même"]
    D --> E{"Ça fonctionne ?"}
    E -->|"Non"| B
    E -->|"Oui, feu vert"| F["Claude propose version
et message de commit"]
    F --> G["Je valide et je pousse
depuis VS Code"]
    G --> H["Tag poussé : Woodpecker
reconstruit le ZIP et crée la release"]
    style D fill:#ffe0b2,stroke:#ef6c00,stroke-width:2px,color:#000
    style G fill:#bbdefb,stroke:#1565c0,stroke-width:2px,color:#000

Les tests automatiques ne suffisent pas : beaucoup de problèmes n’apparaissent qu’une fois le module déployé dans GEO. C’est pourquoi l’étape de test réel reste la mienne.

En pratique, Claude écrit l’essentiel du code. Je garde le besoin, les choix, les tests réels et la décision de publier.

Le contexte donné à Claude

#

Ce qui compte le plus, c’est le contexte fourni, pour éviter de tout réexpliquer à chaque session.

• CLAUDE.md à la racine du dépôt : structure, conventions de commit, règles de version, pièges connus, règles de conduite. Il est chargé à chaque session.
• Un skill maison sur l’API GEO : la doc de l’API, plus un fichier de retours d’expérience. Quand il contredit la doc officielle, c’est lui qui prime, parce qu’il vient de ce que nous avons constaté sur le terrain.
• Une mémoire persistante : les décisions prises et ce qui reste à faire sur chaque module.
• Un serveur MCP pour piloter ma forge Forgejo (issues, dépôts, fichiers).
• BMAD pour les sujets qui demandent du cadrage (PRD, architecture, stories).

Les garde-fous

#

Un point doit être dit clairement : mon alias claude ajoute --dangerously-skip-permissions. Claude Code ne me demande donc pas de confirmation avant chaque action. C’est un choix assumé, pour la fluidité.

Mes règles sont écrites noir sur blanc dans le CLAUDE.md :

• Pas de commit sans essai dans GEO et sans mon accord.
• Rien sur GitHub sans accord explicite.
• Pas de force push.
• Claude dit clairement ce qui a été validé sur GEO et ce qui ne l’a pas été.

Deux protections techniques complètent ces règles écrites :

• Tout est versionné dans Forgejo, donc une modification malheureuse se rattrape avec Git.
• Le script de publication bloque les secrets et les IP internes avant qu’ils ne partent vers GitHub.

Souveraineté et usages de l’IA, des pistes concrètes

#

1. Fonctionnaire : entre souveraineté et indépendance

#

Je suis fonctionnaire, et cela change ma façon d’aborder la souveraineté numérique.

L’entrepreneur Christophe Casalegno défend une position opposée dans une vidéo au titre sans détour : il ne veut pas de la souveraineté numérique. Il y voit un concept politique, synonyme de contrôle étatique, et lui préfère l’indépendance : pouvoir changer de fournisseur, migrer ses données et résister aux pressions, d’où qu’elles viennent. Selon lui, la bonne question n’est pas « mon cloud est-il souverain ? », mais « si je fais ce choix, est-ce que je reste réellement libre et indépendant ? ».

Je retiens volontiers ce critère. Portabilité et réversibilité sont des arguments très concrets face à une solution tout-en-un propriétaire. C’est aussi ce que permettent déjà PostGIS, GeoServer, QGIS et les standards ouverts en géomatique publique.

Je ne peux pourtant pas reprendre sa conclusion telle quelle. Il parle en entrepreneur, il vise d’abord le domaine privé, et il indique lui-même que ces valeurs inspirent les produits qu’il vend. Une collectivité n’a pas la même liberté de choix : elle applique le Code de la commande publique et le RGPD. Elle gère aussi des données pour le compte des habitants : foncier, urbanisme, réseaux. La provenance d’un service n’y est donc pas un critère secondaire, car le droit auquel le fournisseur est soumis compte. Le CLOUD Act américain, par exemple, peut contraindre un fournisseur américain à livrer des données qu’il contrôle, même hébergées en Europe.

Voilà pourquoi je suis « à moitié convaincu » par les deux discours. L’indépendance me donne la grille de lecture opérationnelle. La souveraineté garde pour moi un sens légitime dans le service public. Et ma propre pratique n’est pas cohérente jusqu’au bout : appliquée à ce workflow, la grille montre que mon code et ma documentation restent portables, mais que je n’ai pas d’équivalent à l’outil lui-même.

2. Séparer les données et les outils

#

Pour y voir plus clair, il faut séparer deux choses.

Les données. Là, ma position est claire : je préfère qu’elles soient hébergées en France ou dans l’Union européenne. C’est la logique de mon infrastructure interne : Forgejo et Woodpecker plutôt que GitHub et GitHub Actions, services de l’américain Microsoft. Elle est cohérente avec mon travail à Vienne Condrieu Agglomération.

Les outils. C’est là que la souveraineté trouve ses limites. Pour l’IA, les outils qui fonctionnent vraiment au quotidien sont aujourd’hui hébergés hors de l’Union européenne : aux États-Unis (Claude, ChatGPT…) ou en Chine (DeepSeek, Qwen…). Il existe des alternatives européennes, comme Mistral. Mais pour mon usage, un agent qui lit un dépôt, modifie des fichiers et lance des tests, je n’ai pas encore trouvé d’équivalent au même niveau.

3. Assumer le shadow IA

#

Le shadow IA désigne l’usage d’un outil d’IA en dehors de tout cadre validé par l’organisation. Autant le dire franchement : le workflow décrit ici en relève. Je ne le présente pas comme un modèle à suivre. Je le décris parce que ces usages existent, que rien ne les remplace aujourd’hui, et qu’un sujet posé sur la table se traite mieux qu’un sujet que l’on tait.

À mon niveau, je limite le risque de trois façons :

• tout mon code vit dans mes dépôts Forgejo, hébergés sur mon infrastructure interne, donc rien n’est enfermé chez un fournisseur ;
• les secrets restent hors des dépôts (voir la section sur le .bashrc) ;
• j’essaie de cloisonner autant que possible l’outil pour qu’il ne parcoure pas de données sensibles.

Ces précautions individuelles ne remplacent pas un cadre collectif.

4. Cinq pistes pour en sortir

#

Voici les pistes que je mettrais sur la table pour une collectivité.

Faire un état des lieux sans chercher de coupables. Tant qu’un usage expose son auteur à un reproche, il reste caché. Demandez d’abord qui utilise quoi, et pour quel besoin.

Classer les données avant de choisir les outils. La bonne question n’est pas « a-t-on le droit d’utiliser l’IA ? », mais « quelle donnée peut aller vers quel outil ? ». Voici un exemple de grille, à adapter avec votre délégué à la protection des données (DPO) :

%%{init: {"flowchart": {"nodeSpacing": 40, "rankSpacing": 50, "padding": 16}}}%%
flowchart TD
    A["Quelle donnée
soumettre à l'IA ?"] --> B{"Personnelle
ou sensible ?"}
    B -->|"Oui"| C["Outil hébergé en interne
ou pas d'IA"]
    B -->|"Non"| D{"Publique ?"}
    D -->|"Non, interne"| E["Outil validé,
sous contrat"]
    D -->|"Oui"| F["Outil validé
par l'organisation"]
    style C fill:#ffcdd2,stroke:#c62828,stroke-width:2px,color:#000
    style E fill:#ffe0b2,stroke:#ef6c00,stroke-width:2px,color:#000
    style F fill:#c8e6c9,stroke:#2e7d32,stroke-width:2px,color:#000

Choisir les outils et fixer qui valide. Quels outils, sous quel contrat, avec quelles conditions sur la réutilisation des données ? Un agent doit pouvoir trouver la réponse sans mener l’enquête.

Proposer une alternative plutôt qu’interdire. Une interdiction sans solution risque de pousser les usages encore plus dans l’ombre. Si un besoin est réel, il lui faut un outil autorisé.

Prévoir des règles pour les agents autonomes. Un assistant conversationnel répond, alors qu’un agent comme Claude Code exécute des commandes. Les garde-fous décrits plus haut (historique Git, secrets hors des dépôts, validation humaine avant publication) peuvent servir de base de discussion.

Et pour les dossiers SIG

#

La même logique s’applique en dehors du développement, quand je traite un dossier avec le SIG : PostgreSQL/PostGIS pour les données, QGIS pour contrôler visuellement, et Claude Code pour écrire les requêtes et les scripts.

Pour ces dossiers, je pars toujours du même modèle de dépôt. Chaque projet y retrouve la même arborescence numérotée, qui suit le flux de la donnée : ni Claude ni moi n’avons à chercher où ranger un fichier.

<nom-du-projet>/
├── 00-DOCUMENTATION/        # specs, comptes-rendus, échanges prestataire
├── 01-PROJETS/
│   ├── 01-QGIS/             # projets QGIS
│   └── 02-FME/              # workbenches FME
├── 02-DATA/
│   ├── 01-GPKG/             # données géo brutes ou intermédiaires
│   └── 02-SHP/
├── 03-SQL/                  # requêtes SQL
├── 04-CSV-XLS/              # fichiers délimités
├── 05-SCRIPTS/              # orchestration et automatisation (Python)
├── 06-CONTROLE-QUALITE/     # scripts de contrôle qualité géospatial
├── 99-PUBLICATION/          # configurations de diffusion (WFS, styles)
├── README.md
├── CLAUDE.md
├── ENVIRONMENT.md
├── TOOLS.md
├── requirements.txt
└── .mcp.json.example

Les fichiers à la racine portent le contexte du projet :

Les conventions écrites dans CLAUDE.md s’appliquent à chaque session :

• documentation, README et commentaires en français ;
• système de coordonnées RGF93 / Lambert-93 (EPSG:2154) par défaut, tout écart étant à documenter ;
• toute nouvelle brique rangée dans le dossier existant qui correspond à sa nature ;
• commit et push uniquement sur demande.

Le principe reste celui de la boucle de travail : Claude produit, je vérifie le résultat sur la carte avant de le considérer comme valide.

Conclusion

#

Ce que vous retenez :

• Importez votre distribution WSL2 (ici Debian 13) pour maîtriser sa version et l’emplacement de son disque.
• Gardez vos dépôts dans le système de fichiers Linux de WSL2, pas sous /mnt/c.
• Ouvrez-les dans VS Code avec code . : l’éditeur est sous Windows, les fichiers et Git sont sous WSL.
• Avec Docker Desktop, activez l’intégration WSL plutôt que d’installer un second moteur.
• Documentez chaque piège dans CLAUDE.md ou dans un skill : c’est ce qui rend les sessions suivantes plus efficaces.
• Gardez pour vous les tests réels et la décision de publier.
• Distinguez la souveraineté des données (que l’on peut tenir) de la dépendance aux outils d’IA (qui reste, pour l’instant, hors Union européenne).
• Mettez les usages de l’IA sur la table : état des lieux, classement des données, outils validés, alternative à l’interdiction.