Ce que le système Task de Claude Code révèle sur l'ingénieur AI-natif

La semaine dernière, Claude Code a discrètement renommé Todo en Task. On dirait un simple changement de terminologie, mais c’est en réalité le début d’un système fondamentalement différent.

Todo était une liste que Claude maintenait seul - la mémoire personnelle d’un agent unique. Task est une unité de travail partagée entre plusieurs agents. Cette distinction change le paradigme des outils de codage IA.

Autrement dit, une nouvelle unité d’abstraction nécessaire aux essaims d’IA vient de voir le jour.

Le cœur du sujet, c’est la délégation, pas l’automatisation

L’ancien Claude Code était un cerveau unique. Confiez-lui un projet complexe et il oubliait les étapes précédentes en cours de route, vous obligeant à repartir de zéro aux alentours des 60%, encore et encore.

Le nouveau système Task repose sur une architecture fondamentalement différente :

• Vous vous adressez à un chef d’équipe. Le chef n’écrit pas de code directement. Il planifie, délègue et synthétise.
• Une fois le plan approuvé, des agents spécialisés sont créés et travaillent en parallèle.

Ce n’est pas de l’automatisation - c’est de la délégation. La nuance compte. Automatiser, c’est scripter une séquence connue. Déléguer, c’est définir des objectifs et faire confiance à une équipe structurée pour trouver le chemin d’exécution.

Le graphe de dépendances est la vraie arme

La fonctionnalité centrale du système Task, ce sont les dépendances inter-tâches (blockedBy). La tâche 3 ne peut pas démarrer tant que les tâches 1 et 2 ne sont pas terminées.

Pourquoi est-ce si important ?

Auparavant, Claude devait garder l’intégralité du plan en mémoire. Plus le contexte s’allongeait, plus il en oubliait des morceaux. Plus la session durait, plus la dérive s’accumulait.

Désormais, le plan lui-même est externalisé et structuré. Même quand le contexte est compressé ou qu’un agent est remplacé, le plan survit. Le graphe de dépendances agit comme une couche de coordination persistante qui transcende la mémoire de chaque agent individuel.

Le traitement parallèle vient gratuitement

Assignez sept à dix tâches et le système ne les traite plus séquentiellement. Les tâches sans dépendances s’exécutent simultanément. Les recherches rapides vont à Haiku, l’implémentation à Sonnet, les jugements complexes à Opus - l’allocation des modèles se fait automatiquement selon les caractéristiques de chaque tâche.

C’est une conséquence directe d’une conception structurée des tâches. Plus la décomposition est propre et les dépendances bien définies, plus le système extrait de parallélisme. Vous n’optimisez pas explicitement le parallélisme - vous l’obtenez comme effet secondaire d’une bonne architecture de tâches.

Le travail devient de l’orchestration

La documentation Swarm révèle des patterns clairs :

• Parallel Specialists : plusieurs experts révisent simultanément - sécurité, performance, vérification de types, tout en même temps.
• Pipeline : recherche → planification → implémentation → tests - des étapes séquentielles où chacune dépend de la précédente.
• Self-Organizing Swarm : les agents piochent dans un pool de tâches partagé, prenant ce qui est débloqué et non assigné.

Le travail n’est plus d’écrire du code. Le travail consiste à concevoir quels agents font quoi, dans quel ordre, avec quelles dépendances entre eux.

L’efficacité du Swarm repose sur la conception des tâches

Trois leviers permettent d’optimiser les performances d’un Swarm :

• Granularité des tâches : des tâches plus petites augmentent le taux de parallélisation, mais le coût de communication inter-agents croît à chaque découpage.
• Séparation des rôles : la spécialisation améliore la qualité, mais crée des goulots d’étranglement potentiels sur les agents surchargés.
• Conception des dépendances : structurer ce qui doit être terminé avant que la suite puisse se lancer sans blocage - c’est la topologie de votre workflow.

D’après mes propres expérimentations, le troisième levier a l’impact le plus significatif. La granularité et la séparation des rôles sont relativement intuitives. La conception des dépendances exige de réfléchir à la forme même du travail - ce que j’appelle la conception de topologie de dépendances.

C’est la vraie compétence de l’ère Swarm. Il ne s’agit pas d’écrire du code plus vite ni de choisir de meilleurs modèles. Il s’agit de structurer le flux de travail pour qu’un maximum d’agents puissent opérer sans attendre.

De l’écriture de code à la conception du travail lui-même

La progression est limpide :

D’abord, nous écrivions du code. Puis, nous avons conçu des systèmes. Maintenant, nous concevons la manière dont le travail s’organise.

Vous n’utilisez pas des outils IA. Vous dirigez une équipe IA. La personne qui comprend cette distinction en premier dominera l’année à venir du développement logiciel.

Le passage de Todo à Task semble anodin en surface. En dessous, c’est l’échafaudage d’un monde où la production principale de l’ingénieur n’est plus du code - c’est l’architecture de la collaboration entre machines.