Trois destinations pour 44 projets : comment j'organise mon code, mes fichiers et mes notes

En bref

Mon inventaire a compté 44 projets réels pour 11 déclarés. Je range aujourd'hui tout selon trois destinations : GitHub pour le code, OneDrive pour les binaires, Obsidian pour la connaissance. S'y ajoutent un sas de tri, une version tenue à trois endroits, un dossier pilotage/ par projet et des limites écrites pour mon agent de code.

---

Le constat : 44 projets pour 11 déclarés

Mon problème de fond tient en une phrase : je crée plus de projets que je n'en clôture. L'inventaire a donné ces chiffres :

• 44 projets réels
• 11 projets déclarés
• 16 projets dormants
• 22 projets sans sauvegarde

Le réel pesait donc quatre fois le déclaré, et la moitié des projets n'avait aucune sauvegarde. Les règles qui suivent vivent dans le fichier d'instructions global de Claude Code. Elles s'appliquent quel que soit le dossier où je lance l'agent.

Trois destinations, un type de contenu pour chacune

Chaque fichier a une seule place, déterminée par sa nature :

• GitHub : code source, documentation texte, configurations sanitisées, workflows n8n nettoyés. Le versionnage en fait la sauvegarde de mon code, restaurable partout.
• OneDrive : binaires, médias, livrables clients, archives de projets clos, PDF, exports. Tout ce que git gère mal.
• Obsidian : notes, décisions, méthode, fiches techniques, contexte client. La connaissance, pas les fichiers.

OneDrive contient environ 300 Go en mode fichiers à la demande, et ce mode est volontaire. Je le traite comme une destination, pas comme un périmètre de tri : je ne le scanne pas et je ne le rapatrie pas en masse. Je vérifie aussi qu'un fichier n'y existe pas déjà avant de le copier, parce que j'y ai déjà des doublons.

Ce qui ne franchit jamais la frontière

Quatre interdits protègent cette répartition :

• Le code vivant ne va pas sur OneDrive : la synchronisation corrompt un .git en édition, et GitHub couvre déjà ce besoin.
• Aucun secret dans git : ni fichiers d'environnement, ni clés, ni certificats, ni bases de données.
• Aucun média lourd dans git : il part sur OneDrive et le .gitignore l'écarte.
• Le vault Obsidian reste hors de OneDrive : une double synchronisation crée des conflits, et Obsidian mobile n'ouvre pas un vault placé dans l'app OneDrive. Il relève d'Obsidian Sync.

Je sauvegarde aussi par branche, jamais en bloc. Activer une synchronisation OneDrive sur mon espace de travail entier y ferait entrer le code et le vault d'un seul geste : cette option reste interdite.

Trois segments de dépôts et un sas

Mon dossier de développement se découpe en trois segments :

• Le travail professionnel : clients, SaaS, site vitrine, outils internes.
• Les jeux : une activité à part, avec son propre segment.
• Le personnel : side-projects et projets dormants.

Sur GitHub, le nom de chaque dépôt commence par le préfixe de son segment. Un topic donne son statut : actif, dormant ou archive. Tous les dépôts clients sont privés, sans exception.

Rien n'entre directement dans le dossier de développement ni dans le vault. Un élément entrant, qu'il vienne de OneDrive, d'un clone ou d'un transfert, passe d'abord par un dossier de sas, où je le trie avant de le classer.

Ce que git et les archives ignorent

Un dossier regénérable n'a rien à faire dans un dépôt ni dans une archive. Voici ma liste d'exclusion complète :

node_modules  .next  .nuxt  dist  build  out  .output
target  vendor  .venv  venv  __pycache__  .dart_tool
.gradle  Pods  DerivedData  .terraform  coverage
.cache  .turbo  bin  obj

Une version tenue à trois endroits

Un projet versionné porte son numéro à trois endroits qui doivent toujours concorder :

1. Le manifeste : package.json, pubspec.yaml, pyproject.toml ou composer.json.
2. L'entrée de tête du CHANGELOG.
3. Le tag git, préfixé par v.

Une skill Claude Code met à jour les trois d'un coup. Le semver est strict et les commits conventionnels déterminent le niveau de la version.

J'ai rendu ce bump proactif le 20 août 2026, parce que l'oubli était devenu la norme. Dès qu'un lot commité contient au moins un feat ou un fix, l'agent bumpe sans attendre ma demande. Il s'arrête ensuite et affiche la commande de push. Une montée de dépendance, par Renovate ou npm update, ne déclenche aucune version du projet.

Un dossier pilotage par projet

Chaque projet de dev doit tenir un dossier pilotage/ avec huit documents : roadmap, todo, done, work-log, pending-decision, decisions, bugs et quality-checklist. Le fichier docs/CONTEXT.md reste la porte d'entrée courte et renvoie vers ce dossier.

Avant d'intervenir, l'agent lit cet état, puis vérifie git status et git log. Si le dossier manque, il propose de le mettre en place. Un nouveau projet le reçoit dès le départ.

Trois règles gardent ce suivi fiable :

• Rien n'entre dans done.md sans preuve.
• L'agent ne tranche aucune décision métier à ma place.
• Les identifiants comme TASK-, BUG- ou DEC- ne servent jamais deux fois.

Ce pilotage se commite avec le lot de travail, et il ne part pas sur GitHub sans ma validation.

Les limites que je donne à mon agent

Sur mes projets et mes fichiers, l'agent travaille en lecture seule par défaut. Le bump et le pilotage forment deux exceptions d'écriture assumées. Les autres limites sont explicites :

• Dry-run avant tout déplacement : il montre le plan et attend ma validation.
• Jamais de suppression : il déplace vers une zone d'archive réversible.
• Jamais de git push sans ma validation.
• Jamais de réécriture d'historique git sans demande explicite.
• Aucun déplacement d'un projet qui contient des modifications non commitées.
• Inspection de la cible avant de l'écraser ou de la supprimer : si elle contredit sa description, il me le signale au lieu d'agir.

Pour l'autre versant de mon poste de travail, j'ai décrit à part la configuration de mon Mac.

Le chiffre reste la référence

Mes règles rangent les projets, elles ne les clôturent pas, et cet article n'annonce aucune baisse de ces chiffres. Je garde ce constat comme un constat, pas comme une condition de création : un 45e projet reste possible. Il recevra un préfixe, un topic de statut et son dossier pilotage/.