07 - Mon workflow complet : du setup au deploy
Ce que tu vas apprendre
- Le workflow complet utilise pour construire paltemps.fr
- Une session de travail type, du matin au deploy
- Les commandes de survie : /cost, /compact, /checkpoint, /rewind
- Les habitudes qui font la différence sur la duree
Prerequisites
Tous les articles précédents, idealement. Mais tu peux lire celui-ci en standalone pour avoir la vue d'ensemble.
Le contexte : paltemps.fr
paltemps.fr est un ecosysteme multi-subdomaines que j'ai construit en mars 2026. Un API Bun/Elysia qui sert tout : le site pro, un blog statique généré depuis du Markdown, un panel admin, un webmail complet avec IMAP/SMTP, un outil de benchmark, et un lecteur de flux RSS avec scraping Puppeteer. Le tout tourne dans Docker Compose (app + Caddy + mailserver + Chrome headless) sur un VPS OVH, avec deploy automatique via GitLab CI.
C'est le genre de projet avec assez de surface (6 sous-domaines, du mail, de l'IA, du scraping) pour que l'assistant IA fasse une vraie différence. Voici comment le setup a rendu ca possible.
Étape 1 : le CLAUDE.md
Avant d'écrire la moindre ligne de code, j'ai créé le CLAUDE.md du projet. Stack technique, commandes de build, conventions de nommage, fichiers a ne pas toucher. Ca prend 15 minutes et ca évité des heures de corrections par la suite.
J'ai aussi configure le ~/.claude/CLAUDE.md utilisateur avec les instructions RTK (cf article 02 et article 06). A partir de ce moment, chaque commande lancee par Claude passe par RTK.
Étape 2 : les MCP servers
Pour ce projet, j'ai active deux serveurs MCP dans le .mcp.json :
- Playwright : pour tester visuellement les pages du front. Claude ouvrait la page, prenait un screenshot, detectait les problèmes de layout.
- Filesystem : pour les opérations de fichiers avancees.
Pas de GitHub MCP ici (le projet est sur GitLab). Pas de database MCP non plus (les donnees sont dans des fichiers JSON et du Markdown, pas dans une base relationnelle). On garde le setup minimal.
Étape 3 : les hooks
Deux hooks actifs pendant tout le développement :
json{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"command": "prettier --write \"$CLAUDE_FILE_PATH\" 2>/dev/null || true"
}
],
"PreToolUse": [
{
"matcher": "Edit|Write",
"command": "bash .claude/hooks/protect-files.sh \"$CLAUDE_FILE_PATH\""
}
]
}
}
Auto-format apres chaque édition, protection des fichiers sensibles. Pas de notification desktop parce que je travaillais sur un seul ecran avec le terminal visible.
Étape 4 : les skills
J'ai créé un skill /generate-article pour les articles du blog intégré au site. Un autre skill /test-visual qui lancait Playwright MCP sur les pages cibles et reportait les problèmes. Ces skills m'ont fait gagner du temps sur les taches repetitives, pas sur le code métier.
Une session type
Voici a quoi ressemble une session de travail typique avec ce setup :
8h30 - J'ouvre le terminal, je lance claude dans le répertoire du projet. Claude charge le CLAUDE.md, les MCP servers demarrent. Je commence par une demande large : "Je veux ajouter le scraping d'articles. L'utilisateur clique sur un article dans le feed, et le contenu est scrape et affiche dans une modale."
8h35 - Claude est en mode plan. Il me propose une architecture : un service de scraping avec Puppeteer, un endpoint API, un composant React modale. Je valide le plan, il commence a coder.
8h50 - Le service de scraping est écrit. Claude lance les tests (rtk vitest run). Deux échecs. Il corrige. Les tests passent.
9h00 - Le frontend est en place. Je demande a Claude de tester visuellement. Il navigue vers localhost:3000 via Playwright MCP, prend un screenshot. Le texte deborde de la modale. Il ajuste le CSS, reprend un screenshot. C'est bon.
9h10 - /cost : 0.47$. Raisonnable pour 40 minutes de travail.
9h15 - /checkpoint avant de passer au deploy. Si le deploy casse quelque chose, je peux /rewind.
9h20 - Commit, push, le CI GitLab deploie. Je vérifié en prod. Tout marche.
40 minutes pour une feature complète : backend, frontend, tests, vérification visuelle, deploy. Sans l'IA, j'aurais passe la matinee entière dessus.
Les commandes de survie
Ces commandes te sortent des situations delicates :
/cost : vérifié régulièrement. Si une session dépassé 2-3$ sans résultat, c'est que ta demande est trop vague ou que Claude tourne en boucle. Reformule.
/compact : quand la session devient longue et que Claude commence a oublier des choses ou a ralentir, compacte le contexte. Ca résumé la conversation et libéré de la place. Avec RTK, tu atteins le seuil de compaction beaucoup plus tard.
/checkpoint : créé un snapshot git avant une opération risquee. Refactoring majeur, changement de schema de base, migration. Toujours checkpoint avant.
/rewind : revient au dernier checkpoint. Claude a fait n'importe quoi sur ton refactoring ? Un /rewind et c'est comme si rien ne s'etait passe. Pas besoin de faire un git reset --hard a la main.
/fast : toggle le mode accéléré. Meme modèle Opus, mais la sortie est streamee plus rapidement. Je l'active quand je fais du scaffolding ou des taches simples.
Utilise le mode plan pour les gros changements
Mon erreur des premières semaines : lancer Claude en mode auto-accept sur des refactorings complexes. Il partait dans une direction, modifiait 15 fichiers, et le résultat ne correspondait pas a ce que je voulais. Deux heures perdues a comprendre et defaire ses changements.
Maintenant, pour tout changement qui touche plus de 3 fichiers, je commence en mode plan (/plan). Claude analyse, propose, et attend ma validation. Je corrige le plan avant l'exécution. Ca prend 5 minutes de plus mais ca évité les catastrophes.
Pour les taches simples (écrire un test, formater un fichier, ajouter un import), le mode par défaut ou auto-accept fonctionne tres bien.
Le coût réel
Sur paltemps.fr, j'ai depense environ 15$ en tokens Claude sur les cinq jours de développement. Avec RTK, c'est probablement 30-40% moins que sans. 15$ pour un projet complet déployé en prod. Compare ca a cinq jours de ton taux journalier. Le retour sur investissement n'est pas discutable.
Le poste de depense principal : les sessions de debug ou Claude explore beaucoup de fichiers. C'est la que /compact et RTK font la différence. Sans eux, la meme exploration aurait coûte le double.
Ce que j'aurais fait differemment
J'aurais configure les hooks des le jour 1. Je les ai ajoutes au jour 3, apres avoir corrige manuellement le formatage une dizaine de fois. 15 minutes de configuration qui m'auraient epargne une heure de corrections.
J'aurais aussi créé le skill /test-visual plus tot. Les deux premiers jours, je testais visuellement a la main (ouvrir le navigateur, rafrachir, regarder). Playwright MCP faisait ca mieux et plus vite.
Le setup final
Pour recapituler, voici les composants du workflow :
- CLAUDE.md avec les conventions du projet et les instructions RTK
- .mcp.json avec Playwright pour les tests visuels
- settings.json avec hooks de formatage et protection de fichiers
- Skills personnalises pour les taches repetitives
- RTK prefixe sur toutes les commandes via le CLAUDE.md utilisateur
- /checkpoint avant les opérations risquees
- /cost toutes les 30 minutes
- Mode plan pour les gros changements, auto-accept pour les petits
Ce stack (Claude Code + RTK + MCP + CLAUDE.md bien configure) est l'environnement de dev le plus productif que j'ai utilise en 10 ans de carriere. Pas parce que l'IA écrit tout le code. Parce qu'elle supprime les frictions qui prennent 60% du temps : le boilerplate, le debug de configs, les tests repetitifs, les allers-retours navigateur-terminal.
Si tu n'as lu qu'un article de cette serie, j'espere que c'est celui-ci. Et que tu vas configurer au moins le CLAUDE.md et RTK ce soir.
Article précédent : 06 - RTK et les outils compagnons
Suivant : 08 - Glossaire
Premier article : 00 - Introduction