Gestion des tâches dans Claude Code

Problème : Les boucles autonomes de Claude Code nécessitaient avant des hacks à la Ralph Wiggum. Des fichiers de plan externes, des stop hooks, et des promesses de complétion maintenaient les longues exécutions en vie. Ça marchait. Ça demandait aussi beaucoup de scotch pour tenir le contexte entre les sessions.

Gain rapide : Anthropic a lancé la gestion des tâches comme fonctionnalité de premier ordre. Lance des tâches persistantes avec des dépendances :

claude "add user authentication - break into tasks with dependencies"

Appuie sur Ctrl+T pour afficher la liste des tâches dans ton terminal. Les tâches restent en vie entre les sessions. Tu n'as jamais à réexpliquer ce que tu faisais.

Les tâches : des todos améliorés

Anthropic a déployé le nouveau système de tâches le 23 janvier 2025. Ce qui était des listes plates est maintenant un suivi de projet avec des dépendances, des bloqueurs, et une synchronisation en direct entre les sessions.

L'ancien outil TodoWrite tenait une liste simple en mémoire. Le système actuel répartit le travail sur quatre outils dédiés :

Outil	But
TaskCreate	Créer des tâches avec sujet, description et affichage du statut
TaskGet	Récupérer les détails complets d'une tâche, y compris les dépendances
TaskUpdate	Mettre à jour le statut, ajouter des bloqueurs, modifier les détails
TaskList	Lister toutes les tâches avec leur état actuel

Ce qui change

Ancien comportement : les todos vivaient dans la mémoire de Claude et mouraient à la réinitialisation du contexte. Nouveau comportement : les tâches sont stockées dans ~/.claude/tasks/ dans ton répertoire home (pas dans le repo) et les mises à jour sont envoyées à chaque session ouverte.

Les leçons des anciens todos tiennent toujours. Les tâches ne valent que ce que valent tes instructions, et tout décalage pointe directement sur un problème de briefing. La nouveauté, c'est tout ce qui est en dessous : la persistance et les dépendances intégrées dans l'outil.

Tâches vs Ralph Wiggum : ce qui change

Ralph Wiggum est arrivé en premier. Il maintenait Claude Code en marche toute la nuit avec des stop hooks, des fichiers de plan sur disque, et un prompt qui promettait la complétion. La recette fonctionnait. Elle s'appuyait aussi beaucoup sur des bricolages.

Ces bricolages ont maintenant des remplaçants natifs :

Bricolage Ralph	Solution native Tasks
Fichiers plan.md externes pour le suivi	Stockage intégré dans `~/.claude/tasks/` (répertoire home)
Stop hooks pour vérifier la complétion	Cycle de statut : `pending → in_progress → completed`
Sessions fraîches pour combattre la dégradation du contexte	Les tâches persistent à travers les compactions de contexte
Promesses de complétion ("complete")	`TaskUpdate` explicite avec statut
Coordination manuelle de fichiers de progression	`CLAUDE_CODE_TASK_LIST_ID` pour la synchronisation multi-session

La même leçon fondamentale tient : la vérification est ce qui porte tout l'édifice. Ralph nous a montré que Claude a besoin d'une règle stricte pour ce que "terminé" signifie. Les tâches natives gardent cette idée et déplacent le câblage dans l'outil lui-même.

Tu fais encore tourner des boucles Ralph ? Tu n'as pas à les supprimer. Les tâches te donnent simplement les primitives que la communauté assemblait à la main. Anthropic a regardé ce que les développeurs faisaient et l'a rendu natif.

Dépendances et bloqueurs de tâches

Les dépendances, c'est là que les tâches deviennent intéressantes. Une tâche peut en bloquer une autre :

Task 1: Design database schema
Task 2: Create API endpoints (blocked by Task 1)
Task 3: Build frontend components (blocked by Task 2)

Claude gère la comptabilité. Termine la Tâche 1 et la Tâche 2 se déverrouille toute seule. Les travaux parallèles arrêtent de se marcher dessus.

Créer des tâches dépendantes

Quand Claude découpe un grand travail en morceaux, il câble la chaîne de dépendances au fur et à mesure :

TaskCreate(subject="Design auth schema", description="...")
TaskCreate(subject="Implement auth API", description="...")
TaskUpdate(taskId="2", addBlockedBy=["1"])

L'enchaînement se fait via le paramètre addBlockedBy. Son opposé, addBlocks, te permet de dire ce qu'une tâche bloque à la place.

Collaboration multi-session

C'est là que l'outil prouve sa valeur. Une variable d'environnement permet à plus d'une session de partager la même liste de tâches :

CLAUDE_CODE_TASK_LIST_ID=my-project claude

Maintenant chaque session Claude pointée vers cet ID travaille à partir de la même liste. Termine une tâche dans la Session A et la Session B voit la mise à jour immédiatement. Tu obtiens :

Flux de travail parallèles : sessions frontend et backend partageant des bloqueurs
Reprendre n'importe où : ferme ton laptop, rouvre-le demain, les tâches sont exactement là où tu les as laissées
Coordination d'équipe : plusieurs développeurs partageant l'état des tâches

Workflow multi-session pratique

Ouvre ta session principale et donne un nom à la liste de tâches :

CLAUDE_CODE_TASK_LIST_ID=feature-auth claude 2. Découpe le travail en tâches et définis les dépendances

Ouvre une deuxième session avec le même ID pour le travail en parallèle :

CLAUDE_CODE_TASK_LIST_ID=feature-auth claude # Same ID 4. Les deux sessions voient et mettent à jour la liste de tâches partagée

L'Agent SDK respecte la même liste, donc les sous-agents peuvent reprendre et terminer des tâches à côté de toi.

Cycle de vie du statut des tâches

pending → in_progress → completed

Passe une tâche à in_progress dès que tu commences à travailler dessus. Un spinner apparaît dans la liste des tâches, et les autres sessions savent que le travail est en cours. Ne passe à completed que quand le travail est vraiment terminé.

Les tâches survivent aux compactions de contexte. Même dans les longues sessions où la mémoire de Claude est compressée, l'état des tâches est toujours là.

Raccourcis clavier

Ctrl+T ouvre et ferme la liste des tâches dans le terminal. Ce que tu vois :

Tâches en attente (jusqu'à 10 à la fois)
Tâches en cours avec spinner
Tâches terminées avec coche

Tu peux aussi dire à Claude "montre-moi toutes les tâches" ou "efface toutes les tâches" si tu préfères piloter en langage naturel.

Quand utiliser les tâches

Utilise les tâches pour les gros travaux. Une demande simple n'a besoin de rien de tout ça.

Utilise les tâches quand :

Implémentation en plusieurs étapes avec des dépendances
Travail qui s'étend sur plusieurs sessions
Coordination de sous-agents en parallèle
Projets où tu vas faire des pauses et reprendre

Passe les tâches quand :

Modifications d'un seul fichier
Questions rapides
Commandes one-shot

Configurer le comportement des tâches

Mets des règles de tâches dans ton fichier CLAUDE.md :

## Task Management
 
- Use TaskCreate for multi-step work
- Set dependencies with addBlockedBy for sequential phases
- Update status to in_progress before starting each task
- Mark completed only after verification

Pour les projets qui s'étendent sur plusieurs sessions, tu peux aussi mettre la variable d'environnement dans ton profil shell :

# In .bashrc or .zshrc
export CLAUDE_CODE_TASK_LIST_ID=my-project

Migration depuis les todos

Tu as encore des règles TodoWrite dans ta config ? Réécris-les :

Ancienne approche :

Keep session checklists in TodoWrite

Nouvelle approche :

Use TaskCreate for each checklist item
Update status via TaskUpdate (pending → in_progress → completed)
Set dependencies with addBlockedBy parameter

La commande /todos existe toujours comme alias. Sous le capot, le moteur est maintenant Tasks.

À retenir : Ralph nous a montré l'idée. Tasks la rend native. Garde la rigueur de vérification, laisse l'outil gérer la plomberie, et retire les fichiers d'état faits à la main.

Gestion des tâches dans Claude Code

On this page