Sous-agents (Subagents) : paralléliser le travail avec des agents secondaires

📚 Navigation dans la série : Le chapitre précédent 20 · Connecter des outils via le protocole Model Context Protocol (MCP) vous a montré comment associer des outils externes à Codex pour lire des documentations ou interagir avec des services. Ce chapitre propose une autre approche — non pas lui « ajouter des outils », mais déléguer des tâches en parallèle : les sous-agents (Subagents) sont des assistants spécialisés dotés de modèles, d'instructions et de permissions autonomes, travaillant de concert avant de synthétiser leurs conclusions dans un rapport final.

Messieurs, nous allons aborder aujourd'hui l'une des fonctionnalités les plus puissantes, mais aussi les plus mal comprises de Codex : les sous-agents.

Son nom évoque une organisation avancée, celle d'une « équipe d'agents en parallèle », comme si vous pilotiez une équipe de développement à vous seul. À mes débuts avec cette fonction, j'avais tendance à diviser chaque tâche entre cinq ou six agents distincts pour faire « professionnel ».

Mais soyons réalistes : les sous-agents de Codex ne fonctionnent pas de cette façon, et un comportement important est à connaître — par défaut, l'assistant ne divise jamais le travail de lui-même. La documentation officielle précise que Codex ne crée des sous-agents que si vous le demandez explicitement. Sans consigne du type « lance plusieurs agents en parallèle », il exécutera l'intégralité du traitement de manière séquentielle dans la session principale. Cette règle détermine comment et quand utiliser cette fonction.

Ce chapitre présente comment appeler les sous-agents, comment configurer des agents personnalisés, comment leur attribuer des modèles distincts, et surtout comment identifier la frontière : quelles tâches méritent d'être parallélisées, et lesquelles deviennent inutilement complexes ou coûteuses sous cette forme.

À la fin de ce chapitre, vous aurez en main :

• Le rôle des sous-agents — la différence entre répartir des tâches sur plusieurs agents spécialisés et laisser un agent unique traiter l'ensemble du sujet.
• Les deux problèmes majeurs résolus par cette approche : la pollution du contexte (context pollution) et l'altération du contexte (context rot), ainsi que les cas où il convient de ne pas diviser le travail.
• L'usage des trois agents intégrés par défaut (default / worker / explorer), utilisables sans configuration.
• La création d'agents personnalisés en plaçant un fichier TOML dans ~/.codex/agents/ ou .codex/agents/, et le rôle de ses trois clés obligatoires.
• L'attribution de modèles et de niveaux de réflexion (model_reasoning_effort) spécifiques pour chaque sous-agent, afin d'utiliser des modèles rapides pour l'analyse de fichiers et des modèles performants pour la validation.
• Un guide de configuration pratique pour créer un agent de lecture seule, l'exécuter et vérifier qu'il synthétise ses conclusions sans modifier vos fichiers.

---

01 Qu'est-ce qu'un sous-agent ?

En résumé : les sous-agents sont des assistants spécialisés créés temporairement par Codex. Ils s'exécutent au sein de fils d'exécution (threads) autonomes, et transmettent uniquement une synthèse de leurs conclusions à la session principale, sans y déverser l'intégralité des données analysées.

Analogie : Déléguer une enquête complexe à plusieurs détectives spécialisés. Vous êtes le détective principal (la session principale) chargé d'analyser une modification de code sous trois angles : sécurité, performance et tests. Ces trois analyses sont indépendantes et vous n'avez pas à les mener l'une après l'autre de façon séquentielle. Vous mobilisez donc trois détectives : l'un se concentre sur les failles de sécurité, le second sur les aspects de performance, et le troisième sur la couverture de tests. Ils travaillent en parallèle de manière autonome. Une fois leurs analyses terminées, they ne déposent pas des rapports de centaines de pages sur votre bureau, mais vous transmettent chacun une synthèse : « La sécurité présente deux risques aux points X et Y ». Vous obtenez ainsi un résumé consolidé par thématique.

Ces détecteurs disposent d'éléments propres, isolés de votre session principale. La documentation utilise ces termes :

Subagent (Sous-agent) : Agent délégué créé par Codex pour traiter une tâche spécifique. Agent thread (Fil d'agent) : Le fil d'exécution en console associé à un agent, consultable et accessible via la commande /agent.

Un sous-agent possède plusieurs attributs autonomes :

Dimension	Session principale	Sous-agent délégué
Fil / Contexte	Historique des échanges et décisions de votre session	Fil d'exécution autonome dédié à sa sous-tâche, préservant les détails d'analyse en local
Modèle / Réflexion	Modèle sélectionné pour votre session globale	Paramétrable individuellement (ex: modèle rapide pour l'analyse, performant pour la revue)
Instructions	Comportement par défaut de Codex	Instructions spécifiques (developer_instructions, ex: « analyser uniquement sans appliquer de modifications »)
Permissions de bac à sable	Stratégie de bac à sable active pour la session	Héritée par défaut, mais modifiable (ex: forcer le mode read-only sur un agent)

L'intérêt principal des sous-agents réside dans l'isolation des données intermédiaires de la session principale. La documentation officielle le résume ainsi : la session principale se concentre sur la définition des besoins, les choix stratégiques et le résultat final, tandis que les tâches d'analyse de fichiers, d'exécution de tests ou de lecture de logs (qui génèrent beaucoup de texte à l'écran) sont déléguées aux sous-agents, qui ne transmettent qu'un résumé des résultats.

Cette particularité détermine l'adéquation de la fonctionnalité avec vos besoins, comme décrit dans la section suivante.

Ce schéma présente le fonctionnement : l'agent de la session principale découpe et répartit un besoin complexe vers plusieurs sous-agents s'exécutant en parallèle. Chaque sous-agent travaille au sein d'un contexte isolé (sécurité, tests, documentation), ce qui évite les interférences. Une fois les analyses terminées, seule une synthèse condensée est retournée à la session principale, conservant ainsi la clarté du fil d'échange principal.

💡 En résumé : Un sous-agent est un assistant doté de son propre fil de discussion, de ses instructions, de son modèle et de ses permissions. Il effectue son travail en parallèle et transmet uniquement une synthèse à la session principale pour éviter d'encombrer votre historique de discussion.

---

02 Les problèmes résolus et les limites de la parallélisation

La documentation officielle met en évidence deux comportements indésirables résolus par l'usage des sous-agents.

Problème 1 : La pollution du contexte (context pollution)

Analogie : Mélanger des factures de restaurant avec vos documents de comptabilité officielle. Votre session principale contient des informations importantes — les spécifications du projet, les règles de design et les choix d'architecture. Si vous demandez à Codex d'exécuter une suite de tests volumineuse dans cette même session, l'écran va se remplir de centaines de lignes de logs de test. Les conclusions importantes (« deux tests ont échoué ») se retrouvent noyées sous des lignes de logs inutiles, vous obligeant à remonter l'historique pour les retrouver. C'est ce qu'on appelle la pollution du contexte : les données de traitement masquent les informations utiles.

La documentation officielle le définit ainsi :

Context pollution (Pollution du contexte) : Les informations utiles sont masquées par des sorties de logs ou données intermédiaires volumineuses.

Exemple concret : j'analysais l'intégration d'une API en affichant les réponses JSON à chaque tentative dans ma session. Après une quinzaine de messages, j'ai voulu vérifier une règle de structure définie au début des échanges. J'ai dû remonter l'équivalent de vingt écrans de logs JSON pour retrouver la phrase. Les tâches générant des données textuelles volumineuses doivent être déportées hors de la session principale.

Problème 2 : L'altération du contexte (context rot)

Analogie : L'allongement d'une réunion de travail nuit à la concentration. Au cours de la première heure, les participants restent concentrés sur l'ordre du jour. Après trois heures de débat, les digressions, détails techniques secondaires et sujets annexes accumulés nuisent à la clarté des décisions. La mémoire de travail d'un modèle d'IA réagit de la même manière : plus la session accumule de détails techniques secondaires ou de logs, plus sa performance sur les choix d'architecture ou de logique globale diminue.

La documentation officielle le décrit ainsi :

Context rot (Altération du contexte) : La performance globale du modèle diminue à mesure que la discussion accumule des détails secondaires ou déconnectés du sujet principal.

Les sous-agents apportent une réponse à ces deux dérives : ils confinent les logs et données intermédiaires dans des fils d'exécution secondaires, et ne transmettent qu'un résumé synthétique à la session principale. La session principale conserve ainsi sa clarté. La documentation cite l'exemple d'une analyse de documentation volumineuse : Codex peut la découper en sections et confier la lecture de chaque bloc à des sous-agents en parallèle, ces derniers ne retournant que les points clés à retenir.

Les cas où il convient de ne pas diviser le travail

La parallélisation n'est pas sans contrepartie. La documentation rappelle une règle de coût importante : chaque sous-agent exécute son propre modèle et appelle ses propres outils, ce qui rend l'usage des sous-agents plus consommateur de requêtes API (tokens) qu'une exécution séquentielle sur un agent unique.

De plus, l'écriture de code en parallèle comporte des risques d'interférences par rapport aux opérations de lecture :

Pour débuter, réservez les sous-agents à des tâches d'analyse et de lecture (recherche d'informations, exécution de tests, revue de code, synthèse). L'écriture de code en parallèle exige de la vigilance, car plusieurs agents modifiant simultanément les mêmes fichiers peuvent générer des conflits et complexifier la synchronisation.

Voici un guide pour vous aider à choisir d'utiliser ou non les sous-agents :

Type de tâche	Opportunité des sous-agents	Justification
Recherche d'infos, tests, logs, synthèses (lecture seule, volume important)	✅ Recommandé	Isole les données de traitement de la session principale
Recherches indépendantes (analyser la base de données, étudier un service API, lire une doc)	✅ Recommandé	Permet de mener ces analyses en parallèle pour gagner du temps
Modifications simples ou localisées de code	❌ À éviter	Consomme inutilement des jetons API pour des tâches rapides
Modifications simultanées sur les mêmes fichiers de code	⚠️ Déconseillé	Risque élevé de conflits de fichiers et de désynchronisation
Enchaînements séquentiels dépendants (l'action B exige le résultat de l'action A)	⚠️ Sans intérêt	La parallélisation n'apporte aucun gain de temps dans ce cas

Conseil pratique : évitez d'appeler un sous-agent pour des corrections de code localisées. Demander de modifier un nom de fonction via un sous-agent est plus lent et plus coûteux que de l'exécuter directement dans votre session. Réservez la parallélisation aux tâches d'analyse ou de recherche volumineuses.

💡 En résumé : Les sous-agents évitent la pollution et l'altération du contexte en isolant les logs intermédiaires. Utilisez-les pour les tâches de lecture et d'analyse en parallèle (tests, audits, recherches). Évitez-les pour les petites corrections ou les modifications de fichiers simultanées.

---

03 Les agents intégrés par défaut et leur activation

Codex propose trois agents configurés d'office, utilisables sans paramétrage préalable :

Agent intégré	Rôle	Cas d'usage recommandé
default	Assistant généraliste par défaut	Tâches de développement courantes sans spécificité
worker	Agent d'exécution (écriture de code, corrections)	Implémenter des fonctionnalités, corriger des bugs
explorer	Agent de recherche (analyse de code, lecture seule)	Parcourir le projet, localiser des fonctions, étudier des structures

Pour activer ces agents, rappelez-vous de cette règle de Codex : les sous-agents ne sont jamais lancés automatiquement, vous devez en formuler la demande dans votre consigne. La documentation officielle précise :

Codex ne crée pas de sous-agents de sa propre initiative. Ils ne s'activent que si vous demandez explicitement un travail en parallèle ou l'usage d'agents secondaires.

L'appel ne requiert pas de syntaxe complexe ; formulez simplement votre besoin de répartition du travail en décrivant la délégation, la synchronisation et le format de restitution. La documentation conseille des formulations comme « spawn two agents » (créer deux agents), « delegate this work in parallel » (déléguer ce travail en parallèle) ou « use one agent per point » (utiliser un agent par point). Une bonne consigne de délégation doit préciser : la répartition des rôles, la nécessité d'attendre la fin de tous les traitements (synchronisation) et le format de la synthèse finale.

Exemple de consigne de délégation à saisir dans le chat :

Délègue l'analyse de cette branche par rapport à main à des sous-agents en parallèle. Associe un agent à l'audit de sécurité, un autre à l'étude des performances et un troisième à la couverture de tests. Attends les résultats de chacun avant de synthétiser leurs conclusions par catégorie avec les fichiers concernés.

Codex gère ensuite l'orchestration : création des instances, transmission des consignes de travail, attente des retours de chaque fil d'exécution et consolidation des rapports sous une forme unique.

Disponibilité d'affichage : Les fils d'exécution des sous-agents sont visibles au sein de l'application de bureau Codex et du CLI. La prise en charge de cette visibilité au sein des extensions d'éditeurs (IDE) est signalée comme en cours de déploiement par l'éditeur. Privilégiez l'application de bureau ou le CLI pour suivre le traitement en parallèle.

💡 En résumé : Trois agents sont disponibles d'office (default, worker, explorer). L'assistant n'exécute le travail en parallèle que si vous le spécifiez dans votre invite en décrivant la répartition et le format de la synthèse.

---

04 Suivre et piloter les sous-agents actifs

Lorsque plusieurs sous-agents s'exécutent en arrière-plan, vous pouvez suivre leur progression ou interrompre un traitement. Codex met à disposition deux méthodes de suivi.

Commande de suivi /agent

Saisissez la commande /agent (au singulier) dans la console pour lister les fils d'exécution des agents actifs et basculer d'une console d'agent à une autre :

/agent

Cette commande permet de consulter le journal d'activité d'un sous-agent spécifique. La création et la délégation restent gérées par vos invites textuelles, la commande /agent servant uniquement à l'affichage et à la navigation.

Instructions textuelles de pilotage

Vous pouvez piloter les sous-agents en vous adressant directement à Codex. La documentation officielle indique que vous pouvez demander à l'assistant d'interagir avec un sous-agent spécifique, d'interrompre son exécution ou de fermer les fils d'agents terminés en utilisant le langage naturel, par exemple : « Arrête l'agent chargé de la recherche de fichiers ».

Analogie : Le poste de contrôle et le canal radio. Les sous-agents sont comme des équipes sur le terrain. La commande /agent vous permet de vous brancher sur la fréquence radio d'une équipe pour écouter ses échanges locaux. Les instructions textuelles vous permettent de donner des consignes de direction globale (« Équipe 3, cessez les recherches et rentrez au poste »). Vous conservez le contrôle des opérations à tout moment.

Une particularité concerne la validation des approbations (permissions) : dans l'interface console active (CLI), une demande d'approbation initiée par un sous-agent s'affichera à l'écran, même si vous consultez un autre fil. L'invite précise quel sous-agent sollicite la validation. Vous pouvez alors appuyer sur la touche o pour basculer sur le contexte de ce sous-agent afin d'analyser la commande avant de l'approuver. En mode d'exécution non interactif (scripts), toute demande d'approbation non résolue provoque l'échec de la tâche du sous-agent et renvoie l'erreur à la session principale.

💡 En résumé : Le pilotage des agents actifs s'appuie sur la commande /agent (pour naviguer entre les consoles d'exécution) et sur des instructions textuelles (pour interrompre ou modifier une tâche). L'appui sur o permet de consulter le contexte d'un sous-agent demandant une approbation.

---

05 Création d'agents personnalisés et affectation de modèles

Si vous effectuez régulièrement les mêmes revues de code (comme auditer le code selon des règles d'entreprise spécifiques), vous pouvez enregistrer un agent personnalisé sous la forme d'un fichier de configuration TOML, afin de pouvoir l'appeler facilement.

Le fichier TOML définissant l'agent se place dans l'un des deux répertoires suivants selon la portée souhaitée :

Répertoire de stockage	Portée	Usage
~/.codex/agents/	Global (tous vos projets)	Agent de revue générale disponible sur votre machine
.codex/agents/	Local (ce projet uniquement)	Agent de test ou de déploiement partagé via Git

Analogie : La fiche de poste d'un spécialiste. Les agents intégrés d'office sont des collaborateurs généralistes. Créer un fichier TOML revient à rédiger la fiche de poste d'un spécialiste — définir son titre, sa spécialité, ses consignes de travail et son équipement de travail (le modèle d'IA associé). Une fois la fiche enregistrée, vous pouvez mobiliser ce spécialiste par son nom.

Un fichier de configuration d'agent personnalisé comporte trois clés obligatoires :

name = "reviewer"
description = "PR reviewer focused on correctness, security, and missing tests."
developer_instructions = """
Review code like an owner.
Prioritize correctness, security, behavior regressions, and missing test coverage.
"""

Détail des paramètres (d'après les spécifications de l'éditeur) :

Clé TOML	Obligatoire	Rôle	Description
name	Oui	Identifiant unique de l'agent pour son appel	C'est le nom à utiliser dans vos invites pour appeler cet agent
description	Oui	Description textuelle du rôle de l'agent	Explique le but de l'agent pour l'équipe
developer_instructions	Oui	Consignes de comportement de l'agent	Le profil de consignes et règles à appliquer par l'agent
nickname_candidates	Non	Liste de pseudonymes pour l'affichage	Permet de distinguer visuellement les instances si plusieurs agents du même type s'exécutent simultanément

Les autres paramètres (model, model_reasoning_effort, sandbox_mode, mcp_servers, skills.config) sont optionnels. S'ils ne sont pas déclarés, le sous-agent hérite des valeurs de la session principale. De plus, ces fichiers TOML acceptant les clés classiques du fichier config.toml, vous pouvez y associer des restrictions d'accès spécifiques. Si vous nommez un agent personnalisé avec un nom existant (comme explorer), vos instructions locales remplaceront le comportement de l'agent par défaut.

Affectation de modèles et d'efforts de réflexion

Cette configuration permet d'associer un modèle et un niveau de réflexion adaptés à la spécialité de l'agent :

• Le modèle (model) : La documentation suggère d'utiliser des modèles rapides et économiques (comme les versions mini de type gpt-5.4-mini) pour les tâches d'exploration de fichiers, de recherche ou de logs en parallèle. Pour les tâches de revue de code critiques, de validation de sécurité ou de logique complexe, associez des modèles performants (comme les versions gpt-5.4 ou gpt-5.5). Les noms exacts de modèles évoluant avec les versions, utilisez les identifiants disponibles sur votre machine.
• L'effort de réflexion (model_reasoning_effort) : Il définit l'intensité d'analyse du modèle selon trois niveaux :

Niveau d'effort	Usage	Impact
high	Tâches de validation complexes, détection de bugs de logique, audits de sécurité	Temps de réponse plus long et coût supérieur, mais meilleure précision
medium	Configuration intermédiaire recommandée par défaut	Compromis standard
low	Tâches de lecture simples, exploration de fichiers, recherches d'adresses	Vitesse maximale et consommation réduite

Exemple d'agent personnalisé d'exploration configuré en lecture seule avec un modèle rapide :

# .codex/agents/explorer.toml
name = "pr_explorer"
description = "Read-only codebase explorer for gathering evidence before changes."
model = "gpt-5.4-mini"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"
developer_instructions = """
Stay in exploration mode.
Trace the real execution path, cite files and symbols, and avoid proposing fixes unless asked.
"""

La clé sandbox_mode = "read-only" garantit que ce sous-agent ne pourra pas modifier vos fichiers de projet, même s'il est sollicité pour une écriture. C'est une sécurité importante pour confiner les tâches de recherche.

Attention concernant les priorités : Les paramètres définis manuellement lors du lancement de votre session principale (comme les commandes /permissions ou l'option --yolo) écrasent les configurations statiques définies dans les fichiers TOML des sous-agents. La décision en cours d'exécution reste prioritaire.

De plus, des paramètres globaux de gestion des agents s'inscrivent dans votre fichier config.toml principal (section [agents]) :

• agents.max_threads : Limite le nombre de fils d'agents s'exécutant simultanément (valeur par défaut : 6).
• agents.max_depth : Limite la profondeur de création en cascade de sous-agents par d'autres sous-agents (valeur par défaut : 1, interdisant la création en cascade par défaut).
• agents.job_max_runtime_seconds : Définit le temps d'exécusion maximum alloué à un agent lors d'exécutions en lot (valeur par défaut : 1800 secondes).

La documentation conseille de maintenir la profondeur max_depth à 1 pour éviter que des délégations en cascade ne génèrent des consommations d'API incontrôlées ou n'encombrent les ressources de votre machine.

💡 En résumé : Un agent personnalisé s'enregistre dans un fichier TOML contenant les clés name, description et developer_instructions. Vous pouvez optimiser le fonctionnement de chaque agent en lui associant un modèle adapté (économique pour l'analyse, performant pour la revue), un niveau model_reasoning_effort et des permissions système dédiées.

---

06 En pratique : Rédiger et exécuter un agent personnalisé de recherche

Voici un exercice pour créer un agent de recherche en lecture seule, l'appeler pour auditer un fichier et vérifier qu'il ne modifie pas le code.

Étape 1 : Créer l'architecture de test

Créez un dossier temporaire et le sous-répertoire de configuration des agents sous macOS/Linux (ou sous Windows Git Bash) :

mkdir sub-demo
cd sub-demo
mkdir -p .codex/agents

Étape 2 : Écrire le fichier de configuration de l'agent

Créez le fichier .codex/agents/scout.toml et ajoutez les consignes suivantes :

name = "scout"
description = "Agent de recherche en lecture seule, analyse la structure d'un fichier et liste les améliorations sans le modifier."
sandbox_mode = "read-only"
model_reasoning_effort = "low"
developer_instructions = """
Tu es un agent de recherche en lecture seule. Ton rôle se limite à analyser le code sans le modifier.
Lorsque tu es appelé :
1. Lis le fichier spécifié par l'utilisateur.
2. Identifie les points d'amélioration selon trois critères : lisibilité, nommage et bugs potentiels.
3. Propose une piste d'amélioration pour chaque point, mais n'applique aucune modification sur les fichiers.
Transmets uniquement une synthèse claire, sans recopier l'intégralité du code.
"""

La clé sandbox_mode = "read-only" verrouille les droits d'écriture de cet agent, et model_reasoning_effort = "low" accélère son analyse.

Étape 3 : Créer un fichier de code à analyser

Créez un fichier de code contenant des variables peu explicites et une division potentielle par zéro pour donner de la matière à l'agent :

echo 'def f(a, b):
    return a / b' > calc.py

Étape 4 : Lancer la session et appeler l'agent

Ouvrez la session Codex :

codex

Demandez explicitement à Codex de déléguer la tâche à l'agent personnalisé :

Demande à l'agent scout d'analyser le fichier calc.py et d'afficher ses conclusions sous forme de synthèse, sans modifier le code.

Comportement attendu : Codex crée une instance de l'agent scout (visible à l'écran). L'agent s'exécute dans son fil autonome, lit calc.py et renvoie une synthèse dans le chat principal (pointant le nommage obscur des variables et l'absence de vérification sur la division par zéro). Quittez la session.

Étape 5 : Vérifier l'absence de modification du fichier

Affichez le contenu de calc.py pour vérifier que le code est resté intact :

cat calc.py

Comportement attendu : Le fichier calc.py est inchangé. La restriction read-only de l'agent a bloqué toute modification, garantissant la sécurité de la démarche.

Ce test valide le fonctionnement des sous-agents personnalisés et la restriction des droits associés.

💡 En résumé : L'exercice montre comment enregistrer un agent personnalisé dans .codex/agents/scout.toml, l'appeler pour analyser un code cible et s'assurer que le fichier reste inchangé grâce aux permissions de lecture seule.

---

07 Fonctionnalité avancée : Traitement en lot de fichiers CSV (expérimental)

⚠️ Cette fonctionnalité est expérimentale et sujette à modification. Considérez-la comme un aperçu technique plutôt que comme une fonction stable.

Si vous devez appliquer un même traitement d'analyse à un volume important d'éléments indépendants (auditer une liste de cinquante fichiers de code ou analyser une série de Pull Requests), Codex propose la fonction spawn_agents_on_csv. Elle charge une liste d'éléments depuis un fichier CSV et attribue chaque ligne à un sous-agent de traitement (worker) s'exécutant en parallèle, puis regroupe les rapports dans un fichier CSV consolidé.

Chaque sous-agent doit obligatoirement appeler l'outil de retour de résultat report_agent_job_result pour enregistrer ses conclusions, sous peine de marquer la ligne correspondante en erreur dans le rapport final. Fiez-vous aux structures décrites dans la documentation officielle pour la configuration des champs.

Voici les critères de choix pour cette fonction de traitement en lot :

Contexte	Pertinence de la fonction de lot CSV	Raison
Audit de sécurité ou revue de style sur de nombreux fichiers	✅ Adapté	Les traitements sont identiques et indépendants, maximisant le gain de temps du parallèle
Traduction de commentaires sur une liste de fichiers	✅ Adapté	Chaque traitement de fichier est autonome
Actions dépendantes d'un ordre d'exécution	❌ Inadapté	Les lignes du CSV sont traitées en parallèle sans garantie d'ordre
Analyse sur un nombre restreint d'éléments (2 ou 3)	❌ Inadapté	La configuration du CSV et des workers est plus longue que l'appel de sous-agents classiques
Traitements modifiant les mêmes répertoires de code	⚠️ Déconseillé	Risque de conflits d'écriture simultanés entre les agents

💡 En résumé : Le traitement en lot par CSV (spawn_agents_on_csv) s'adresse aux analyses répétitives indépendantes sur de grands volumes de données. Évitez cet outil pour des traitements ordonnés, des modifications de fichiers simultanés ou sur de petits volumes d'éléments.

---

08 Résumé

Ce chapitre a détaillé le fonctionnement et la configuration des sous-agents pour répartir les traitements volumineux et préserver la clarté de votre environnement de travail.

Voici les points clés à retenir :

Concept	Rôle	Recommandation
Définition	Assistants temporaires dotés de leur propre fil de discussion.	Permet d'isoler les logs et données de traitement de la session principale.
Problèmes résolus	Pollution et altération du contexte (context pollution & context rot).	Déporte les affichages volumineux (tests, audits) dans des fils secondaires.
Limites	Consommation accrue de requêtes API et risques de conflits en écriture.	À réserver aux tâches de lecture/analyse ; éviter pour les petites modifications de code.
Activation	Codex ne lance jamais d'agent de lui-même.	Précisez la répartition et le besoin de parallèle dans vos invites.
Pilotage	Commande /agent pour basculer de console ; touche o pour les approbations.	Vous conservez le contrôle et pouvez arrêter un agent en langage naturel.
Personnalisation	Fichier TOML dans agents/ (obligatoires : name, description, developer_instructions).	Configurez des modèles rapides pour les recherches et performants pour les revues.

Vous êtes désormais en mesure de évaluer l'opportunité d'utiliser des sous-agents pour vos tâches, d'appeler les agents intégrés par défaut, de naviguer entre les fils actifs avec /agent, de configurer un agent personnalisé TOML avec ses instructions et permissions dédiées, et d'auditer du code en toute sécurité en limitant les droits des agents de recherche.

---

Le chapitre suivant 22 · Définir des compétences réutilisables (Skills) présente l'organisation des compétences : comment packager un ensemble d'instructions, de scripts ou de ressources sous la forme d'une compétence (Skill) réutilisable par vos agents d'une session à l'autre ? Comment structurer une compétence et comment l'activer ? Nous verrons comment consolider les savoir-faire de nos assistants de programmation.

---

Lectures recommandées

• Connecter des outils via le protocole MCP
• Utilisation de l'ordinateur et navigateur (Computer Use)
• Tarification et gestion de la consommation d'API