Comment je travaille

Documentation par projet

Notion est la source de vérité produit : vision, roadmap, décisions actées, questions en suspens. Rien n'est codé avant que le plan soit validé.

Dans le dépôt, cinq fichiers Markdown vivent avec le code et sont mis à jour à chaque étape. Ils donnent à l'IA la mémoire qu'elle n'a pas d'une session à l'autre.

• PLAN : objectifs, fonctionnalités, étapes, stack, points à trancher.
• ARCHITECTURE : organisation du code, choix et justifications, flux de données.
• FUNCTIONS : les fonctions clés, leurs paramètres, où elles vivent.
• COMMANDS : toutes les commandes du projet, la mise en ligne pas à pas, l'état des migrations par environnement.
• PATTERNS : les techniques rencontrées, avec leur intérêt et leurs compromis.

Partage des rôles avec l'IA, en solo

J'ai codé à la main pendant des années (Node.js, Haxe, Python, Go, SQL) et je lis tout ce que l'IA produit. Sur mes projets personnels, Claude Code fait le travail de fond : le code, la documentation, une relecture de son propre code et l'analyse statique (format, lint, typecheck). Je définis ce qui est attendu, je relis, je teste avec de vraies données et de vrais parcours, et je valide. Le cycle :

1. L'IA code, documente, livre un code qui compile et passe l'analyse.
2. Je teste en local, avec de vraies données.
3. Je valide ou je remonte ce qui ne va pas, et on itère.
4. Commit sur la branche de l'IA, seulement après validation.

Des règles pensées pour un développeur seul qui est aussi son propre utilisateur :

• Pas de tests écrits par l'IA sans demande, mais du code testable : logique en fonctions pures, dépendances injectables.
• Pas de commentaires dans le code : ce qui mérite une explication va dans la documentation.
• Pas d'outillage installé juste pour que l'IA se vérifie elle-même, pas de revues multi-agents en cascade. Deux minutes d'essai réel disent plus.
• Les actions manuelles se font une étape à la fois, chacune avec son résultat attendu.

En équipe

Seul, je suis le seul relecteur et le seul utilisateur. En équipe, le code doit pouvoir être lu, repris et maintenu par d'autres, donc le cadre change :

• Revue de code : toute PR est relue par un humain avant merge, code écrit à la main ou avec l'IA. La relecture sert aussi à faire progresser : on explique le pourquoi, pas seulement le quoi.
• Conventions partagées : style, nommage, structure et usage de l'IA écrits dans le dépôt et décidés ensemble. Format et lint vérifiés en CI, pas à la main.
• Tests : tests automatisés sur la logique métier et les flux de données, lancés en CI, bloquants pour le merge. La règle « pas de tests sans demande » ne vaut que pour mes prototypes.
• Commentaires : la convention de l'équipe prime. Au minimum, le pourquoi d'un choix non évident est écrit à côté du code.
• Transmission : les fichiers PLAN, ARCHITECTURE et COMMANDS servent de base d'onboarding. Décisions consignées, binômage sur les sujets critiques, personne n'est seul à connaître une partie du système.

Git et environnements

• dev : la branche de travail. Pour les projets qui ont un site de dev (dev.litterbox.redev.fr par exemple), un push sur dev le met en ligne, avec sa propre base ou son propre schéma.
• main : la production. Un push déploie automatiquement.
• L'IA travaille sur une branche claude/<sujet> qu'elle commite et pousse elle-même. Les merges sont à moi : PR vers dev, puis PR dev → main.
• Jamais de push forcé ni de réécriture d'historique sur dev ou main. Des branches plutôt que des worktrees.

Base de données et migrations

Un seul Supabase auto-hébergé sur le VPS, partagé entre les projets : une base Postgres, un schéma par projet, comptes utilisateurs et stockage communs. RLS activé sur toute table exposée à l'API : la clé publique finit dans le bundle, la sécurité vient des règles par ligne.

Tout changement de schéma tient en deux fichiers :

• schema.sql : l'état complet et à jour. Sert à créer une base neuve et à lire le modèle, jamais rejoué sur une base existante.
• migrations/AAAA-MM-JJ_sujet.sql : la différence seule. Le seul script exécuté, une fois par environnement, dev puis prod. Additif par défaut, toute suppression est annoncée.

pg_dump complet chaque nuit, gardé quatorze jours, restaurable schéma par schéma.

Hébergement et déploiement

Un VPS Ubuntu : nginx et certbot devant tout, Docker Compose pour les services, un utilisateur deploy sans sudo. Les services partagés (Supabase, n8n, blocs nginx) vivent dans un dépôt d'infrastructure à part, référence de tous les projets. Deux modèles de déploiement, un par type de dépôt :

• Infrastructure (compose, nginx, données vivantes sur le serveur) : clone sur le VPS avec une deploy key GitHub en lecture seule. Déployer = git pull --ff-only puis docker compose up -d, à la main. GitHub ne peut rien sur le serveur.
• Applications (build Vite ou Flutter, ce site) : GitHub Actions construit à chaque push sur main et envoie le résultat par rsync dans le dossier servi par nginx. Rien à installer sur le VPS, le serveur ne porte pas le code source.

Chaque projet garde dans son dépôt ce qui lui est propre : workflow, bloc nginx, migrations, .env.example. Les secrets GitHub portent les mêmes noms dans tous les dépôts. Une instance n8n unique, avec des workflows [dev] et [prod] par projet, versionnés dans le dépôt du projet et importés par son déploiement.

Suivi

Jira pour les tickets (epics, stories, bugs) et les versions, GitHub pour le code et les PR, Notion pour la connaissance et les décisions. Les retours utilisateurs sont collectés directement dans les apps.

Stack technique

Data

BigQuerydbtTrinoPostgreSQLMySQLSQL ServerMongoDB

Data visualisation

SupersetTableauPower BI

Développement

PythonNode.jsJavaScript / TypeScriptReactFlutter / DartGoHaxePHPC#API REST

Automatisation et IA

n8nClaude CodeGeminiHugging Face

Infrastructure

UbuntuDocker ComposenginxcertbotSupabaseGitHub ActionsGCP (Cloud Run)

Organisation

NotionJiraGitHubSlackClickUp