Claude Code est devenu un levier de productivité sérieux pour les équipes d’ingénierie. Les gains des premières semaines sont généralement évidents. Ce qui l’est moins, c’est ce qui se passe une fois que votre équipe commence à l’utiliser pour un travail plus long et plus ambitieux : refactorisations multi-fichiers, audits importants, développement de fonctionnalités de bout en bout. À cette échelle, la qualité de sortie et le coût cessent de suivre la manière dont ils l’ont fait au début, et les raisons ne sont pas toujours faciles à voir d’un point de vue de leadership.
La réponse n’est presque jamais le modèle. C’est l’architecture autour du modèle. Les équipes qui tirent 5x à 10x de Claude Code n’utilisent pas une version différente de Claude. Elles utilisent la même version avec des sous-agents Claude intégrés, ce qui maintient les sessions longues et précises au lieu de les laisser se dégrader. Cet article s’adresse aux personnes qui décident où investir le temps de l’ingénierie : il examine les cinq goulots d’étranglement qui limitent silencieusement le débit de votre équipe, les modèles de sous-agents qui corrigent chacun d’eux, et quand passer aux équipes d’agents Claude Code. À la fin, vous saurez quoi demander à votre responsable de l’ingénierie et comment repérer si votre configuration actuelle laisse de l’argent réel sur la table.
Ce que sont réellement les sous-agents Claude
Un sous-agent Claude est une instance isolée de Claude Code avec sa propre fenêtre de contexte d’environ 200 000 jetons, son propre prompt système, sa propre liste d’outils autorisés et ses propres permissions. La session principale lui délègue une tâche. Le sous-agent effectue le travail en isolation, puis ne renvoie qu’un résumé. Tout ce qui est bruyant et s’est produit à l’intérieur du sous-agent reste à l’intérieur du sous-agent.
La vraie valeur ici n’est pas le parallélisme, bien que cela aide. C’est l’isolation. Lorsqu’un sous-agent lit quarante fichiers pour trouver un modèle, la session principale ne voit jamais ces quarante fichiers. Elle voit un paragraphe : « J’ai trouvé le modèle, il se trouve ici, il ressemble à ceci. » Cela maintient le fil principal concentré tout au long d’une longue session.
Trois types sont à connaître. Les sous-agents intégrés comme Explore et Code sont livrés avec Claude Code et s’exécutent automatiquement. Les sous-agents personnalisés résident dans votre dossier .claude/agents/ et vous permettent de définir des spécialistes pour la sécurité, les tests ou la documentation. Et si une session ne peut vraiment pas gérer le travail, les équipes d’agents Claude Code vous permettent de coordonner plusieurs sessions en leur envoyant des messages.
Claude Code s’inscrit dans un paysage plus large de cadriciels d’IA multi-agents tels que LangChain, le SDK Agents d’OpenAI et Google ADK, chacun avec des compromis différents en matière d’orchestration, de mémoire et d’accès aux outils. Les sous-agents sont la réponse d’Anthropic au même problème de coordination que ces cadriciels tentent de résoudre, intégrés directement dans le runtime Claude Code au lieu d’être ajoutés comme une couche séparée.
Les cinq goulots d'étranglement qui brisent les longs flux de travail Claude Code
Les responsables d’ingénierie décrivent généralement les ralentissements de Claude Code en termes vagues : « le modèle se dégrade », « il oublie des choses », « les sessions deviennent chères ». Ce sont des observations réelles mais elles ne sont pas aléatoires. Chacune correspond à une cause architecturale spécifique dans la manière dont une session à contexte unique gère le travail au fil du temps, et chacune a un modèle de sous-agent qui la résout sans nécessiter un modèle différent ou un outil différent.
Les cinq modèles ci-dessous couvrent la majorité de ce qui ralentit les longues sessions. Savoir lequel touche votre équipe fait la différence entre jeter plus de jetons sur le problème et réellement corriger le flux de travail.
La dégradation du contexte est le lent déclin de la qualité de sortie à mesure que la fenêtre de contexte se remplit. Elle se manifeste bien avant la limite stricte de jetons. Plus le modèle détient de contexte, moins vos instructions initiales ont de poids. Après trois heures, le plan architectural que vous aviez défini au départ est enfoui sous les sorties d’outils, les contenus de fichiers et le raisonnement antérieur, et le modèle commence effectivement à l’ignorer.
La solution consiste à déléguer le travail bruyant à un sous-agent. Tout ce qui lira plus de cinq fichiers, analysera de grands diffs ou traitera des logs ira à un sous-agent Explore. La session principale ne voit jamais la sortie brute. Elle voit les résultats.
Vous saurez que cela fonctionne lorsque la qualité de votre troisième heure correspondra à celle de votre première heure.
Freinage séquentiel sur le travail indépendant
Lorsqu’un long flux de travail exécute tout via une seule session principale, les éléments de travail indépendants finissent par attendre les uns les autres sans bonne raison. La revue de sécurité attend les tests, les tests attendent la documentation, la documentation attend la refactorisation. Le travail lui-même n’a jamais été séquentiel. L’architecture l’a rendu séquentiel.
Le modèle « diviser pour mieux régner » dissout cela. Les flux de travail indépendants sont répartis sur des sous-agents parallèles et les résultats reviennent à un seul endroit. Là où les équipes se trompent, c’est en envoyant des sous-agents avec des instructions génériques, ce qui produit un travail qui se chevauche, des modifications sur les mêmes fichiers et un désordre de fusion à la fin. Les équipes qui font cela correctement donnent à chaque sous-agent un rôle nommé, un livrable défini et des limites claires sur ce qu’il peut toucher. Cette précision est ce qui transforme l’exécution parallèle en un véritable débit au lieu de trois agents qui se marchent sur les pieds.
Contamination inter-domaines
La dégradation du contexte concerne ce qui s’estompe avec le temps. La contamination inter-domaines concerne ce qui entre en compétition au moment présent. Lorsqu’une session est chargée de contenir les règles backend, les règles frontend et les conventions SDK simultanément, ces ensembles de règles interfèrent les uns avec les autres. Le modèle ne manque pas de place. Il est tiré dans trois directions à la fois.
L’échec visible : les modèles backend fuient dans les composants React, ou les conventions frontend apparaissent dans les objets de transfert de données. Le code semble plausible à première vue mais viole les conventions que vous avez définies pour chaque couche. C’est le résultat de demander à un contexte d’être expert en trop de choses en même temps.
La solution est un sous-agent par domaine. Le sous-agent backend charge uniquement les instructions backend. Le sous-agent frontend charge uniquement les modèles de composants. L’orchestrateur coordonne entre eux mais n’essaie jamais de détenir toutes les règles lui-même. Le même principe sous-tend l’architecture propre dans le développement logiciel, et cela fonctionne pour la même raison : la séparation des préoccupations empêche la dérive.
L'effondrement des quatre heures
L’effondrement des quatre heures se produit lorsqu’une des étapes du flux de travail échoue et que tout le pipeline s’arrête, ou lorsque la session manque de place à mi-chemin et que l’état accumulé est perdu. La plupart des flux de travail à contexte unique sont fragiles de cette manière car rien n’est sauvegardé entre les étapes.
La solution est un pipeline structuré d’exploration, de planification et d’exécution. Chaque phase est une invocation de sous-agent distincte avec une transmission propre à la suivante. Le seuil de revue humaine se situe entre la planification et l’exécution, là où le coût de détection d’une erreur est le plus bas.
Cela est important à grande échelle. La version Dynamic Workflows d’Anthropic du 28 mai 2026 a montré Claude Code effectuant des migrations de bases de code sur des centaines de milliers de lignes, avec la suite de tests existante comme barre de validation. Des exécutions à cette échelle ne survivent pas sans transmissions structurées entre les phases.
Surcharge de l'orchestrateur
Les quatre autres goulots d’étranglement se situent au niveau des travailleurs. La surcharge de l’orchestrateur est ce qui se passe au niveau du coordinateur une fois que les travailleurs fonctionnent. Vous avez des sous-agents parallèles produisant des résumés clairs, mais l’agent parent se noie maintenant sous le trafic d’arrivée : dix résumés à lire, dix ensembles de recommandations à réconcilier, dix fils à maintenir cohérents. Le débit ralentit non pas parce que les travailleurs sont lents, mais parce que rien en aval ne peut synthétiser leur sortie assez rapidement.
La solution est la retenue au sommet. L’orchestrateur doit coordonner et rien d’autre. Le parallélisme doit correspondre à l’indépendance réelle des tâches, pas seulement à la capacité disponible. Un sous-agent de revue en lecture seule à un ratio de 1:3 ou 1:4 permet de maintenir la qualité élevée sans ajouter à la charge de fusion. La lecture seule est importante car un réviseur ayant des droits d’écriture commencera à corriger les problèmes lui-même, ce qui créera des conflits avec les sous-agents implémenteurs. La même logique sous-tend le bon fonctionnement de la revue de code dans une équipe humaine : le réviseur signale, l’implémenteur corrige. Cinq sous-agents parallèles est la limite pratique pour la plupart des équipes au sein d’une session.
Sous-agents vs. Équipes d'agents
Les sous-agents sont des travailleurs au sein d’une session Claude Code. Les équipes d’agents Claude Code coordonnent plusieurs sessions, chacune avec son propre contexte, communiquant par messages entre coéquipiers. Le choix entre les deux n’est pas académique. Faites le mauvais choix et vous dépenserez de l’argent en équipes d’agents alors que des sous-agents suffiraient, ou vous étirerez les sous-agents au-delà de ce qu’une session peut gérer.
Utilisez des sous-agents lorsque vous avez un flux de travail qui nécessite des aides en dessous. Exploration parallèle, délégation limitée, lectures isolées à contexte lourd. Utilisez des équipes d’agents lorsque le travail lui-même se divise en plusieurs sessions plus longues, que les coéquipiers doivent se parler, ou que le contexte total dépasse ce qu’une session peut raisonnablement supporter.
Portée
Une session, délégation limitée
Plusieurs sessions coordonnent
Communication
Retour d’un résumé unique au parent
Messages entre coéquipiers
Idéal pour
Exploration parallèle, lectures isolées
Travail de plusieurs jours, flux distincts
Profil de coût
Plus léger
Plus lourd par coéquipier
Taille d’équipe pratique
Jusqu’à 10 en parallèle
5 coéquipiers, le point idéal
La plupart des équipes s’étendent trop pour les équipes d’agents. Commencez par les sous-agents. Passez aux équipes d’agents uniquement lorsqu’une session ne peut réellement pas coordonner le travail.
Les erreurs qui transforment les sous-agents en passif
Les sous-agents sont puissants, et il est aussi facile de les utiliser à mauvais escient. Voici les modèles que nous voyons tuer la productivité au lieu de l’aider :
- Déléguer trop de tâches simples. Une lecture d’un fichier ne nécessite pas de sous-agent. La surcharge de coordination dépasse l’économie. Utilisez la session principale pour tout ce qui tient confortablement dedans.
- Spécifier insuffisamment les sorties. Les prompts de dispatch vagues produisent des résumés vagues. Énoncez toujours la forme du livrable : « renvoyer un tableau markdown avec les colonnes X, Y, Z » est mieux que « résumer ce que vous trouvez ».
- Parallélisme factice. Enchaîner les sous-agents séquentiellement alors que le travail n’a pas de dépendances réelles. Si deux sous-agents ne dépendent pas l’un de l’autre, exécutez-les en parallèle.
- Réviseurs avec droits d’écriture. Vient à l’encontre de l’isolation. Un réviseur qui peut modifier commencera à corriger des choses, ce qui crée des conflits de fusion et annule le travail que vos autres sous-agents viennent de faire.
- Prolifération des permissions. Chaque outil supplémentaire élargit votre surface d’attaque. Notre article sur la gouvernance des agents IA explique pourquoi l’hygiène des permissions est plus importante que ce que la plupart des équipes réalisent, surtout après que l’incident de ClawBank a réinitialisé ce à quoi ressemble la sécurité IA en entreprise.
Si vous vous trompez sur ces points, les sous-agents vous coûteront plus de jetons, plus de temps et plus de retravail que si vous aviez tout exécuté dans une seule session.
La configuration minimale de sous-agent qui survit
Si vous partez de zéro, voici la plus petite configuration de production qui survit à une session Claude Code de quatre heures sans effondrement de qualité :
- Un orchestrateur sur Opus. Coordonne seulement. N’implémente jamais.
- Un sous-agent Explore sur Haiku. Lit, résume, renvoie les découvertes. Peu coûteux et rapide.
- Un sous-agent Code sur Sonnet. Implémente par rapport au résumé d’Explore.
- Un réviseur en lecture seule sur Opus. S’exécute après chaque tâche terminée. La sortie est constituée de découvertes structurées, bloquantes et non bloquantes.
- Ne passez aux équipes d’agents que lorsqu’une session ne peut vraiment pas gérer le travail.
La répartition des modèles est importante car elle contrôle le coût. L’analyse de McKinsey sur les gains de productivité de l’IA en 2026 souligne que la valeur de l’IA réside dans la transformation de l’organisation du travail, pas seulement dans l’exécution plus rapide du travail existant. Les sous-agents sont exactement ce type de transformation. Vous cessez de traiter Claude comme un seul modèle faisant tout et commencez à le traiter comme une équipe d’ingénierie.
Cette configuration est la plus importante pour les équipes qui livrent des produits SaaS à grande échelle, où une session Claude Code de quatre heures n’est pas inhabituelle et où le coût de la dégradation du contexte s’accumule tout au long du cycle de publication.
Même modèle, meilleure architecture
Les équipes qui tirent 10x de Claude Code n’utilisent pas un meilleur modèle. Elles utilisent le même modèle avec la bonne structure autour. Les goulots d’étranglement sont prévisibles. Les modèles sont documentés. La différence entre les équipes qui obtiennent un coup de pouce incrémental de Claude et celles qui changent leur manière de livrer est de savoir si elles traitent l’outil comme un agent unique ou comme une équipe d’ingénierie.
Construisez l’architecture avant d’en avoir besoin, pas après l’effondrement des quatre heures. Si vous souhaitez de l’aide pour assembler cela pour un flux de travail réel, contactez-nous.
FAQ
Que sont les sous-agents Claude ?
Les sous-agents sont des instances isolées de Claude Code auxquelles la session principale délègue des tâches. Chacun possède sa propre fenêtre de contexte, ses propres outils et ses propres instructions. Le sous-agent effectue le travail et renvoie un résumé. Le bruit intermédiaire reste à l’intérieur du sous-agent, ce qui maintient la session principale concentrée.
Pourquoi Claude Code ralentit-il avec le temps ?
Dégradation du contexte. Au fur et à mesure que la fenêtre de contexte se remplit, les premières instructions ont moins de poids, de sorte qu’après trois heures, le modèle ignore effectivement le plan défini au début de la session. Les sous-agents corrigent cela en maintenant le travail bruyant hors de la session principale.
Combien de sous-agents peuvent s'exécuter en parallèle ?
Jusqu’à dix en parallèle au sein d’une session Claude Code, avec cinq comme point idéal pratique avant que le coordinateur ne devienne le goulot d’étranglement. Les Dynamic Workflows sur Opus 4.8 relèvent considérablement le plafond pour les travaux très importants.
Quand devrais-je utiliser les équipes d'agents Claude Code au lieu des sous-agents ?
Lorsque le travail lui-même se divise en plusieurs sessions plus longues, lorsque les coéquipiers doivent communiquer, ou lorsque le contexte total dépasse ce qu’une session peut contenir. Pour une délégation strictement délimitée au sein d’un flux de travail, restez-en aux sous-agents.
Quelle est la plus grosse erreur que les équipes commettent avec les sous-agents ?
La sur-délégation. Envoyer des lectures d’un fichier ou des tâches triviales à un sous-agent coûte plus cher en surcharge de coordination que ce que cela rapporte. Utilisez des sous-agents pour le travail qui polluerait autrement le contexte principal.
Découvrez comment Redwerk a reconstruit l'architecture de Sentient Ascend pour alimenter la solution de croissance numérique n°1 basée sur l'IA.
