Aller au contenu principal

Module 13 — Flux de travail quotidiens : explorer, corriger, tester, revoir, livrer

Les modules précédents ont posé les briques : commandes slash, skills, permissions, hooks, sous-agents, MCP, plugin. Reste à les enchaîner. Ce module regroupe les recettes de la journée d'un développeur outillé pour Kiosque : comprendre une base inconnue, corriger un bug depuis une trace, faire du TDD, refactoriser, réviser, ouvrir une PR et la laisser se corriger seule. Le fil rouge est un seul ticket Kiosque, du matin au moment où la PR devient verte.

La règle des bonnes pratiques​

Toutes les recettes qui suivent obéissent à une même règle de best-practices.md : donnez à Claude un contrôle qu'il peut lancer lui-même, tests, build, lint, capture d'écran comparée. Sans ce contrôle, « ça a l'air fini » est le seul signal disponible et c'est vous qui devenez la boucle de vérification. Avec, la session s'arrête quand le contrôle passe au vert. Trois postures complètent : explorer, planifier, coder (mode plan quand la portée est floue, code direct pour un typo) ; donner du contexte précis (@fichier, capture collée, motif existant) ; corriger vite ou repartir (deux corrections sans effet valent mieux qu'un /clear suivi d'un prompt mieux écrit).

Comprendre Kiosque en un quart d'heure​

Vous arrivez sur le dépôt un lundi matin. Claude est plus rapide qu'un scan à la main :

cd kiosque
claude
donne-moi un aperçu de ce dépôt en une page :
technos, découpage, points d'entrée, dette visible.
puis explique le flux d'une commande, de la requête HTTP
au paiement, en pointant les fichiers et fonctions clés.

Suivez avec des questions étroites, comme à un ingénieur sénior : « comment notifications.py parle-t-il à Twilio ? », « pourquoi create_order appelle _lock_menu() ligne 87 ? ». Deux gestes techniques changent la vie sur une base plus grande : démarrer claude depuis le sous-dossier concerné (app/ pour l'API) pour ne charger que les CLAUDE.md pertinents, et déléguer l'exploration à un sous-agent (use a subagent to investigate ...) pour que les cinquante lectures ne remplissent pas votre contexte principal. large-codebases.md complète avec claudeMdExcludes, des règles Read(...) de refus sur dist/ ou build/, et un plugin de code intelligence quand le langage a un serveur LSP.

Corriger un bug à partir d'une trace​

Léa vous transfère une trace : le paiement échoue par intermittence sur les commandes à plus de 50 EUR. Ne dictez pas la solution, décrivez le symptôme, l'endroit probable et ce que « corrigé » veut dire :

symptôme : POST /commandes/{id}/payer renvoie 502 environ 1 fois sur 10
sur les paniers > 50 EUR. trace :
[coller la trace]

la piste est dans app/paiements.py, autour du timeout Stripe.
écris d'abord un test qui reproduit le problème, ensuite corrige,
puis relance make test. attaque la cause racine, ne masque pas l'erreur.

Trois éléments comptent : le test d'abord ferme la boucle (Claude a un contrôle à faire tourner), « cause racine » est explicite (sinon try/except autour du symptôme), le pointeur (paiements.py, timeout Stripe) épargne dix lectures inutiles. Trois raccourcis à connaître : Esc interrompt Claude en préservant le contexte, Esc Esc (ou /rewind) ouvre le menu de checkpoint pour restaurer conversation, code, ou les deux, /clear réinitialise entre deux tâches sans rapport.

TDD sur notifications.py​

Le mardi, vous ajoutez un canal SMS de secours. TDD signifie ici : test d'abord, code ensuite, contrôle exécutable pour valider. common-workflows.md en donne la trame — mêlez-la à la skill /tests-cibles du module 6 pour ne lancer que ce qui touche au diff :

ajoute une fonction envoyer_sms_secours(commande) dans app/notifications.py :
    déclenchée si Twilio timeout > 5 s, tombe sur un fournisseur B.
    d'abord, écris les tests unitaires dans tests/test_notifications.py
    (timeout Twilio, réponse OK B, deux échecs consécutifs).
    ensuite implémente, ensuite lance /tests-cibles jusqu'à ce que tout passe.

Claude écrit les tests, échoue exprès, code, relance. Vous ne regardez que la fin de la boucle. Sur un contrôle plus large — « la route doit répondre en moins de 200 ms sur 10 000 lignes » —, passez par /goal : un évaluateur séparé re-vérifie la condition après chaque tour jusqu'à résolution. Pour un contrôle qui doit se déclencher toujours, préférez un Stop hook qui bloque la fin de tour tant que make test est rouge (Claude Code lève le hook après huit blocages consécutifs).

Refactoriser sans casser​

Mercredi, Karim veut nettoyer commandes.py. Deux commandes se complètent :

  • /simplify est une skill de nettoyage : quatre agents parallèles cherchent des réutilisations, des simplifications, des gains d'efficacité et des mauvais niveaux d'abstraction — sans jamais chercher de bugs.
  • /code-review (alias /review) est une skill de revue de correction sur le diff courant ou une cible passée (pr#, branche, chemin). Elle accepte un niveau low, medium, high, xhigh, max ou ultra, et deux drapeaux : --fix pour appliquer les correctifs et --comment pour poster les remarques comme commentaires GitHub inline. Sans niveau, elle réutilise le dernier low..max tapé, même dans une session précédente ; ultra n'utilise ni ne modifie ce niveau.

Enchaînement type : /simplify app/commandes.py, validation des nettoyages, puis /code-review high --fix. Claude relit le diff, applique les correctifs qu'il juge fiables, et rend un rapport.

La revue par les pairs, façon Kiosque​

Nadia refuse de fusionner sans un second avis. Trois niveaux, du plus léger au plus lourd :

  1. /code-review local. Skill embarquée, tourne dans un sous-agent en tâche de fond avec sa propre fenêtre de contexte. Les correctifs --fix appliqués dans un sous-agent d'arrière-plan ne sont pas capturés par les checkpoints — utilisez git pour revenir en arrière, pas /rewind.
  2. /code-review ultra. Lance ultrareview dans un bac à sable cloud, comparant votre branche à la branche par défaut plus les changements locaux staged et unstaged. Sur une PR github.com, --post prépare la publication depuis votre compte GitHub. Nécessite un compte claude.ai et n'est pas disponible via Bedrock, Vertex AI ou Microsoft Foundry.
  3. Code Review managé (aperçu de recherche). Plans Team et Enterprise, indisponible si Zero Data Retention est activé. Une flotte d'agents analyse chaque PR et publie ses trouvailles en commentaires inline classés par sévérité (rouge Important, jaune Nit, violet Pre-existing). Déclencheurs par dépôt : Once after PR creation, After every push, Manual. Forcez avec @claude review (unique) ou @claude review always (abonne aux pushes). Personnalisez avec CLAUDE.md (contexte général, violations traitées en Nit) et REVIEW.md à la racine (instructions pour les agents de revue seulement).

Pour Kiosque, gardez /code-review high --fix en local avant chaque push, puis laissez le service managé traiter la PR. Le check run se termine toujours en conclusion neutre ; pour transformer « au moins un Important » en gate, parsez la ligne machine-lisible en fin d'output avec gh et jq.

Ouvrir la PR et la laisser se réparer seule​

common-workflows.md recommande de conclure une session par un commit et une PR. Deux formes possibles :

commit avec un message descriptif et ouvre une PR

Ou en étapes :

résume les changements que j'ai faits sur le module paiements
crée une pr

Claude Code lie la session à la PR quand la PR est créée avec gh pr create (ou glab mr create) ; vous retrouverez ensuite la session avec claude --from-pr 1234 — le picker /resume accepte aussi l'URL de la PR.

Une fois la PR ouverte, /autofix-pr spawn une session Claude Code sur le web qui surveille votre branche : à chaque échec de CI ou nouveau commentaire de revue, Claude enquête et pousse un correctif quand la voie est claire. La commande détecte la PR ouverte de la branche courante via gh pr view — pour surveiller une autre PR, checkoutez sa branche d'abord. Un prompt optionnel restreint le champ, par exemple /autofix-pr only fix lint and type errors. Il faut gh et un accès à Claude Code sur le web ; l'app GitHub Claude doit être installée sur le dépôt.

Comportements en cascade

Les réponses d'Auto-fix sont postées depuis votre compte GitHub et peuvent réveiller les automatismes déclenchés par issue_comment (Atlantis, Terraform Cloud, Actions personnalisées). Revoyez ce qui tourne sur cet événement avant d'activer sur un dépôt sensible.

Contrôle final : /verify et /run​

Deux skills embarquées ferment la journée : /verify construit l'app, la lance et observe le résultat — au-delà des tests et du typecheck ; /run la lance sans forcément vérifier. /run-skill-generator écrit un SKILL.md par projet qui apprend à /run et /verify à démarrer votre app depuis un environnement propre. Depuis la v2.1.215, /verify ne tourne que quand vous l'invoquez. Sur Kiosque : /run-skill-generator une fois, puis /verify clôt chaque PR.

L'IDE, le web et le navigateur​

Trois surfaces prolongent Claude Code au-delà du terminal :

  • VS Code. L'extension apporte panneau graphique, revue de plans avant approbation, @-mentions avec plage de lignes (Option+K / Alt+K insère @fichier#L5-L10), historique et onglets parallèles. Cmd+Esc / Ctrl+Esc bascule entre éditeur et prompt. La sélection est envoyée automatiquement — pour l'exclure sur un fichier sensible, ajoutez une règle Read en refus. Depuis un terminal externe, /ide connecte Claude Code à l'IDE ouvert.
  • JetBrains (IntelliJ, PyCharm, WebStorm, GoLand…). Le plugin Claude Code [Beta] lance claude dans le terminal intégré, ouvre les diffs dans le visualiseur natif, partage la sélection et lit les diagnostics via mcp__ide__getDiagnostics. Raccourcis : Cmd+Esc / Ctrl+Esc, Cmd+Option+K / Alt+Ctrl+K pour insérer @src/auth.ts#L1-99. En mode acceptEdits, restez prudent : le plugin peut modifier des fichiers de configuration IDE exécutables automatiquement.
  • Claude Code sur le web. claude --cloud "…" crée une session cloud qui clone la branche courante du remote GitHub — poussez vos commits d'abord. --teleport ou /teleport (alias /tp) rapatrie une session cloud dans le terminal après vérification (git propre, même dépôt, branche poussée, même compte claude.ai). /remote-control (alias /rc) expose la session locale au pilotage depuis claude.ai ou l'app mobile. Ne confondez pas : --cloud crée dans le cloud, --remote-control expose en local.

Pour tester le front de Kiosque, /chrome connecte Claude à Chrome, Edge ou un Chromium (Brave, Arc, Vivaldi, Opera) via l'extension Claude in Chrome 1.0.36+. Lancement direct avec claude --chrome, activation permanente via /chrome > Enabled by default. Signé avec /login sur un plan direct — fournisseurs tiers et WSL exclus. En mode plan, les appels lecture seule passent sans confirmation ; clic, saisie, navigation, enregistrement GIF demandent approbation.

Piège fréquent : la revue « sans ancre »​

Une revue trop ouverte (/code-review sans niveau, sans cible, sur un diff énorme) coûte cher et produit beaucoup de nits qui ne correspondent à rien du projet. Deux gestes : ancrer avec un niveau explicite (/code-review high la première fois d'une PR, pour poser le référentiel) ; cadrer avec REVIEW.md à la racine côté service managé — recalibrer la sévérité, plafonner les nits à cinq par revue, exclure ce que la CI enforce déjà, exiger une convergence après la première revue (« ne poster que les Important au-delà »).

En résumé​

  • Un contrôle exécutable ferme la boucle : tests, build, lint, capture — la différence entre une session qu'on regarde et une qu'on laisse tourner.
  • Le triptyque explorer, planifier, coder évite de résoudre le mauvais problème ; le mode plan est utile quand la portée est floue, inutile pour un typo.
  • La cause racine doit être demandée explicitement dans le prompt de bug, sinon Claude entoure le symptôme d'un try/except.
  • /code-review est la référence en local ; /simplify nettoie sans chercher de bugs ; ultra monte l'engin dans le cloud ; le service managé publie des commentaires classés par sévérité en aperçu de recherche.
  • /autofix-pr délègue la maintenance d'une PR au cloud, gh et l'app GitHub Claude requis.
  • Les surfaces IDE, web et Chrome prolongent la CLI : /ide connecte l'éditeur, --cloud et /teleport déplacent une session entre local et cloud, /chrome teste le front pour de vrai.

Module suivant : Mode non interactif, CI GitHub Actions et Agent SDK — sortir Claude du terminal pour le faire travailler la nuit, dans les Actions et en Python.