Claude d'Anthropic : révolution des flux de travail IA

Une nouvelle ère pour la gestion des tâches complexes

Anthropic a récemment introduit une approche novatrice pour gérer les tâches complexes avec Claude, leur modèle d'intelligence artificielle. Pour la plupart de 2024 et 2025, la réponse par défaut était simple : confier la tâche à un agent, utiliser la plus grande fenêtre de contexte disponible, et attendre. Parfois, cela fonctionnait. Souvent, le modèle perdait discrètement le fil en cours de route.

Anthropic a directement abordé ce problème : les tâches à long terme nécessitent que les agents maintiennent une cohérence à travers de nombreuses étapes, souvent au-delà de ce qu'une fenêtre de contexte peut soutenir de manière fiable. Bien que l'agrandissement des fenêtres de contexte ait apporté une aide, il n'a pas résolu le problème fondamental.

Pour pallier ces problèmes, Anthropic a développé plusieurs outils comme les sous-agents, les compétences et les équipes d'agents. Ces outils permettaient de déléguer des tâches secondaires à des travailleurs isolés, chacun avec son propre contexte frais, et de rassembler les résumés dans la conversation principale. Les compétences, quant à elles, emballaient des flux de travail répétables dans des fichiers Markdown, une recette que Claude pouvait suivre à la demande. Les équipes d'agents allaient encore plus loin : plusieurs sessions indépendantes de Claude, chacune avec sa propre fenêtre de contexte, coordonnant à travers une liste de tâches partagée et se communiquant directement.

Limites des outils existants

Malgré ces avancées, chaque outil avait encore le même plafond structurel. Avec les sous-agents, la session orchestratrice de Claude détient toujours le plan. Chaque résultat renvoyé par un travailleur atterrit dans la fenêtre de contexte de la conversation principale. Avec les sous-agents, les compétences et les équipes d'agents, Claude est l'orchestrateur : il décide tour à tour quoi générer ou assigner ensuite, et tous les résultats s'accumulent dans le contexte. Cela signifie que le contexte orchestrateur s'élargit à mesure que le nombre d'agents augmente, atteignant finalement ses limites. En conséquence, l'orchestration se dégrade, et les mêmes modes d'échec apparaissent.

Anthropic a identifié trois modes d'échec qui apparaissent systématiquement lorsqu'une fenêtre de contexte — qu'elle appartienne à un seul agent ou à un orchestrateur dirigeant une petite équipe — est responsable d'une tâche trop vaste pour être suivie proprement. C'est là que les trois modes d'échec communs se manifestent.

• Laziness agentique — Il commence la tâche mais ne la termine pas complètement. Il peut s'arrêter tôt, sauter certains fichiers, ou supposer que le travail restant est suffisamment similaire. Puis il déclare avec confiance que la tâche entière est terminée. C'est comme une personne qui vérifie seulement une partie d'un long tableau Excel mais marque l'ensemble comme examiné.

• Biais auto-préférentiel. L'IA n'est pas très stricte lorsqu'il s'agit de juger sa propre sortie. Si vous lui demandez : « Avez-vous suivi les instructions ? », elle répond souvent oui, car elle a tendance à se donner le bénéfice du doute. Elle peut manquer ses propres erreurs ou surestimer la qualité de sa réponse.

• Dérive des objectifs. Au cours d'une longue tâche, l'IA perd lentement de vue l'objectif initial. Elle peut se souvenir de la tâche principale, mais oublier des détails importants comme « ne pas inclure X », « ne pas sauter de fichier » ou « utiliser uniquement ce format ». Plus la conversation ou la tâche s'allonge, plus cette dérive est probable.

Ce ne sont pas des bugs. Ce sont les conséquences lorsque le plan est une pensée, et que les pensées se dégradent.

Un cas d'étude révélateur

Le coût est devenu difficile à ignorer début 2026, lorsque Jarred Sumner, créateur de Bun, a dû porter, fichier par fichier, environ 750 000 lignes de Zig vers Rust. Dans le passé, une tâche comme celle-ci aurait pris des mois à une équipe. Le schéma de Sumner était simple : réaliser une unité de travail, effectuer une révision adversariale, puis appliquer les changements. Il a ensuite qualifié les flux de travail dynamiques de « l'état de l'art aujourd'hui pour utiliser de manière fiable des agents pour compléter des projets de taille moyenne à grande ». Le résultat : 750 000 lignes de Rust, 99,8 % de la suite de tests existante réussie, et seulement 11 jours entre le premier commit et la fusion.

L'idée clé est que Claude n'a pas besoin de garder l'ensemble du plan en tête. Le flux de travail déplace le plan dans le code. Le script contient la boucle, les branches et les résultats intermédiaires. Claude n'a besoin de gérer que l'étape actuelle et la synthèse finale. Le plan devient un fichier JavaScript. Il n'oublie pas, ne dérive pas, et ne s'arrête pas à mi-chemin en déclarant le travail terminé.

C'est le problème que les flux de travail dynamiques ont été conçus pour résoudre. Et c'est ce dont cet article traite.

Qu'est-ce qu'un flux de travail dynamique ?

Un flux de travail dynamique est comme remplacer une personne épuisée par une petite équipe ciblée.

Au lieu de demander à une IA de gérer l'ensemble du projet du début à la fin, vous divisez le travail en morceaux clairs. Un agent gère une tâche. Un autre vérifie le résultat. Un autre fait avancer le travail. En conséquence, personne ne se fatigue en cours de route et ne commence à couper les coins ronds. Personne ne se donne une note parfaite simplement parce qu'il a écrit la réponse. Et personne n'oublie le brief original, car chaque agent n'a qu'à gérer un morceau clair du travail.

Le flux de travail dynamique de Claude vous aide à faire cela. Il divise le travail entre une équipe de Claudes avec un contexte frais. Chacun gère une petite partie, une autre couche vérifie le travail, et les résultats sont fusionnés en une seule réponse pour vous.

Le mot clé ici est harnais. Un harnais est l'échafaudage autour du modèle : la partie qui décide comment une tâche est planifiée, divisée, vérifiée et exécutée. Le harnais par défaut de Claude Code est principalement conçu pour des tâches de codage. L'équipe d'Anthropic a découvert que ces harnais dynamiques sont « parfois même plus utiles pour des travaux non techniques ». Ils l'ont ensuite créé sur le champ, façonné autour de la tâche que vous lui donnez.

Avant d'aller plus loin, il est utile de séparer un flux de travail de quelques autres mots qui sont souvent mélangés. Outils, agents, harnais et flux de travail sont souvent utilisés comme s'ils signifiaient la même chose. Ce n'est pas le cas. La manière la plus claire de les séparer — je m'inspire de cette formulation d'AlphaSignal — est de poser une question : qui détient le plan ?

Un sous-agent est un aide que le Claude principal envoie pour un travail spécifique. Le plan reste toujours avec le Claude principal. Le sous-agent fait sa part, renvoie le résultat, et ce résultat apparaît dans votre discussion. C'est principalement du fire-and-forget. Comme le montre le tableau ci-dessous, un sous-agent ne peut pas créer ses propres aides ou parler à d'autres sous-agents.

Une équipe d'agents est différente. C'est un groupe de Claudes travaillant côte à côte, coordonnant en tant que pairs. Le plan ne se trouve pas à l'intérieur d'un Claude. Il vit entre eux. Ils peuvent s'envoyer des messages, s'ajuster au fur et à mesure que le travail se déroule, et continuer sur une tâche partagée plus large. C'est plus comme confier un projet à une petite équipe.

Un flux de travail dynamique est encore différent. Claude écrit un petit programme JavaScript pour la tâche elle-même. Dans ce cas, le plan vit dans le code. Les agents effectuent leur travail à côté, leurs sorties sont stockées dans des variables, et seule la réponse finale fusionnée vous revient.

Une équipe d'agents et un flux de travail dynamique semblent similaires. Cependant, ils sont totalement distincts. Vérifiez le tableau ci-dessous pour voir cela.

| Sous-agent | Équipe d'agents | Flux de travail dynamique | |------------|------------------|--------------------------| | Qui détient le plan | le Claude principal (orchestrateur), dans sa tête | les pairs, entre eux | un programme JavaScript | | Cycle de vie | fire-and-forget, un travail | long, en cours | s'exécute une fois, retourne une réponse | | Peut communiquer entre eux ? | non — l'orchestrateur dirige tout, et un sous-agent ne peut même pas générer ses propres sous-agents | oui — ils coordonnent en tant que pairs au fil du temps | non — les agents travaillent à côté dans des variables de script ; seule la réponse finale revient | | Ressenti | un stagiaire à qui vous confiez une tâche | des collègues sur un projet partagé | une chaîne de montage que vous avez conçue |

Et vous pourriez poser une autre question. Qu'est-ce que dynamique ? Quelles sont les différences entre dynamique et statique ?

Vous pourriez toujours construire un harnais vous-même. Vous pourriez connecter le SDK Agent, ou exécuter claude -p dans une boucle, et créer un système fixe que vous utilisez encore et encore. C'est un harnais statique : utile, répétable, mais conçu à l'avance.

Un harnais dynamique est l'inverse. Claude écrit le harnais sur le moment, façonné autour de la tâche que vous venez de lui donner. Il planifie la structure, divise le travail, exécute les agents, vérifie les sorties, puis jette le harnais une fois le travail terminé — à moins que vous n'appuyiez sur s pour le sauvegarder.

Les harnais statiques sont polyvalents ; les dynamiques sont sur mesure et jetables.

Claude est désormais capable de construire des flux de travail dynamiques car Opus 4.8 est suffisamment performant pour créer le bon harnais à la volée — comme l'a dit l'équipe d'Anthropic, « assez intelligent pour écrire un harnais personnalisé adapté à votre cas d'utilisation ».

Le véritable test

Modèles qui rendent les flux de travail dynamiques utiles

Il existe 6 flux de travail qu'Anthropic introduit, et j'ai effectué quelques tests avec eux pour vous montrer intuitivement comment ils fonctionnent. Ils sont :

• Fan-out-and-synthesize — diviser le travail, puis les fusionner. Chaque pièce obtient son propre agent et un contexte clair ; un synthétiseur final attend tous avant de combiner les résultats.

• Vérification adversariale — pour chaque découverte, générer un agent séparé dont le seul travail est de la contredire. Un sceptique vérifiant l'optimiste.

• Classify-and-act — utiliser un agent classificateur pour trier chaque élément d'abord, puis le diriger vers le bon gestionnaire. Un bureau d'accueil.

• Generate-and-filter — brainstormer largement, puis filtrer selon un critère : dédupliquer, vérifier, ne garder que ce qui résiste à l'examen.

• Tournament — générer N agents qui tentent chacun la même tâche différemment, puis faire comparer un agent juge en paires jusqu'à ce qu'un gagne. Bon pour le goût et le nommage.

• Loop-until-done — pour des travaux de taille inconnue, continuer à générer des agents jusqu'à ce qu'une condition d'arrêt soit remplie (aucune nouvelle découverte, plus d'erreurs) plutôt qu'un nombre fixe de passages.

Cependant, il est crucial de noter que les flux de travail dynamiques consomment considérablement plus de tokens qu'une session standard, et les utiliser pour la mauvaise tâche constitue une forme d'échec en soi.