Agent d’IA Claude : Claude Code, sous-agents et délégation contrôlée

Vous dirigez une équipe technique, produit ou SI, et un agent construit sur Claude s'apprête à travailler sur une base de code réelle : lire des fichiers, les modifier, lancer des commandes. Cette page s'adresse à ceux qui doivent fixer ce que cet agent d'IA Claude a le droit de faire, comment le découper en sous-agents et à quoi reconnaître qu'il a terminé.

Elle permet de décider la politique de permissions valable pour tous les runs, le contrat de sortie qui rend chaque run relisible, et les indicateurs qui disent si l'équipe gagne du temps.

Ce qui distingue un agent Claude : contexte long et délégation

Un assistant rend du texte ; un agent agit sur un environnement, observe le résultat et recommence. Dès que le système écrit dans des fichiers et lance des commandes, vous ne décidez plus de la qualité d'une réponse mais d'un périmètre d'action, gradué selon les quatre niveaux de droits d'un agent d'IA. Sur les agents Claude, deux propriétés commandent ce périmètre : le contexte tenu en une seule fois, et la délégation à des sous-agents.

Si l'arbitrage entre familles d'outils n'est pas tranché chez vous, les critères de bascule sont réunis sur les plateformes d'agent IA. L'outil est ici supposé retenu.

Le contexte long est une ressource à arbitrer, pas un argument de vente

Une grande fenêtre de contexte ne rend pas un agent meilleur : elle vous donne une marge de manœuvre, à dépenser selon un arbitrage qui se pose dès la première tâche un peu large.

Ce choix se fait avant le premier run, pas quand les résultats se dégradent. Deux symptômes signalent une tâche trop large : l'agent redemande une information déjà reçue, ou contredit une décision prise plus tôt.

Une exécution longue change ce que vous devez surveiller

La seconde propriété tient à la durée : un agent Claude peut mener une tâche longue sans qu'on lui reprenne la main. Les durées qui circulent ne se comparent pas hors du modèle et du protocole mesurés : retenez la propriété, pas le plafond. Elle est une contrainte de supervision : personne ne regarde l'agent pendant qu'il travaille, vous relisez une trace après coup.

Ce déplacement du contrôle impose trois repères.

• Un budget, sans quoi rien n'arrête un agent qui tourne en rond.
• Un journal exploitable, sans quoi vous ne saurez pas ce qui s'est passé pendant les heures où vous n'étiez pas là.
• Un critère d'arrêt explicite, sans quoi l'agent décidera lui-même qu'il a terminé.

Claude Code : un agent qui agit sur le projet, pas dans une fenêtre

La différence entre un chat et un agent de développement tient à l'interface, pas au modèle. Dans une fenêtre de conversation, vous recevez du code, l'exécutez et revenez rapporter l'erreur : c'est vous la boucle. Avec Claude Code, l'agent opère depuis le terminal, sur le projet : il modifie les fichiers, lance les commandes et les tests, lit les erreurs et recommence.

L'outil est déjà présent dans les équipes : les développeurs utilisant Claude ou Claude Code sont estimés entre 41 et 68 % (Faros AI, 2026), ordre de grandeur à rapprocher de notre relevé de statistiques sur Claude. Un agent confiné à une fenêtre ne peut rien casser ; un agent Claude Code le peut.

La boucle plan, exécution, observation, correction

Un agent de développement fiable suit une boucle itérative explicite, et c'est cette boucle que vous cadrez, pas le code qu'il écrit. Imposez une sortie standard à chaque étape, sans quoi vous récupérez un résultat sans savoir comment il a été obtenu.

• Plan : étapes, fichiers touchés, hypothèses, critères d'arrêt.
• Exécution : liste des actions (créations, modifications), commandes lancées.
• Observation : résultats de tests, logs utiles, erreurs rencontrées.
• Correction : correctifs appliqués, justification, nouveau passage de tests.

L'étape la plus souvent négligée est la première. Un plan rendu avant toute modification vous donne un point d'arrêt gratuit : vous corrigez la consigne avant que l'agent ne touche au dépôt, seul moment du cycle où une erreur ne coûte rien.

Ce que la boucle produit vraiment sur un dépôt

Cette boucle tient sur les tâches dont le livrable se vérifie mécaniquement. Trois d'entre elles concentrent l'essentiel de l'usage.

• Refactorer ou migrer, c'est préserver un comportement : demandez une stratégie de preuve, tests avant et après, diff lisible, étapes incrémentales.
• Écrire des tests est le meilleur levier pour sécuriser un agent autonome : le critère de réussite se vérifie sans relecture humaine, l'agent corrige jusqu'au vert.
• Documenter obéit à une règle particulière, parce que rien n'y échoue visiblement : un texte faux se lit aussi bien qu'un texte juste.

Pour éviter la documentation purement plausible, forcez l'agent à ne citer que ce qu'il a réellement vu ou exécuté : chemins de fichiers, signatures de fonctions, sorties de commandes. Imposez aussi un format fixe, en six rubriques.

• Prérequis et installation.
• Commandes courantes.
• Résolution des problèmes fréquents.
• Exemples reproductibles.
• Ce que fait le module.
• Ce qu'il ne fait pas, la rubrique qui évite le plus d'erreurs d'usage en aval.

Les sous-agents : découper par livrables, et payer le découpage

Déléguer à des sous-agents spécialisés devient pertinent quand une tâche se parallélise réellement : front, back, tests, revue. Le déclencheur est la présence de morceaux indépendants, jugés chacun sur leur livrable, pas la taille du chantier.

Le second déclencheur est le contexte : une tâche qui sature la fenêtre se découpe même si elle est séquentielle. Au-delà de trois ou quatre sous-agents, vous cadrez une coordination, dont les patterns relèvent de l'orchestration d'agents d'IA.

Nommer chaque sous-agent par son livrable

Structurez vos sous-agents par livrables plutôt que par intentions vagues. Un sous-agent « qui améliore la qualité » ne rend rien de vérifiable et consomme du budget sans fin. Trois découpages fonctionnent presque toujours.

• Sous-agent tests : ajoute ou actualise la suite de tests, puis exécute la commande de test.
• Sous-agent migration : applique un plan fichier par fichier et fournit un diff.
• Sous-agent revue : liste les risques, les antipatterns et les impacts sécurité.

Si vous ne savez pas dire ce que le sous-agent doit rendre, il n'est pas prêt : écrivez son livrable avant son prompt, et donnez-lui un périmètre de fichiers explicite. Un sous-agent « revue » qui modifie du code a franchi sa frontière.

Ce qui transite entre deux sous-agents, et ce que le découpage coûte

Le point faible d'une délégation se situe au passage d'un sous-agent à l'autre. Ne laissez jamais transiter un contexte brut : imposez une synthèse courte et normée, toujours la même.

• Ce qui a été fait.
• Ce qui reste ouvert.
• Les décisions prises et leur justification en une ligne.
• Les fichiers touchés.

Ce format fixe permet de reconstituer l'enchaînement sans rouvrir chaque run. Le découpage a un prix : chaque sous-agent consomme son propre budget, car il repart d'un contexte vide, à réamorcer avec les consignes, les conventions du dépôt et l'état d'avancement.

Cet arbitrage se chiffre en fenêtre de contexte, rattachée à un modèle daté : 200 000 tokens pour Claude Opus 4.5 (llm-stats.com, 2026). Tant que la tâche tient largement dedans, un seul agent coûte moins cher ; dès qu'elle déborde, le surcoût d'amorçage paie la qualité de raisonnement en fin de chantier.

Le contrat de sortie : schémas, preuves et critères d'arrêt

Pour rendre un agent fiable, pensez « contrat » : un contexte, des contraintes et un objectif en entrée, un schéma stable en sortie. Un agent utile produit des artefacts auditables (diffs, logs, résultats de tests, listes de décisions), et la relecture se fait sur eux, jamais sur une prose de synthèse.

Cinq champs obligatoires, et un prompt qui pilote un processus

Le contrat de sortie d'une tâche de refactoring tient en cinq champs, et ils se demandent tous.

• files_changed : liste des chemins et type d'action (création, modification, suppression).
• diff_summary : résumé en 5 points maximum.
• commands_run : commandes et résultats.
• risks : points à relire manuellement.
• stop_reason : terminé, à relire, ou bloqué.

Le dernier champ rend un run classable sans être relu : vous triez cinquante exécutions en quelques minutes.

Tout cela suppose une consigne écrite en conséquence : le prompt doit piloter un processus, pas une réponse. Quatre éléments s'imposent à chaque tâche.

• Un format de sortie : structure balisée, sections, liste de contrôle.
• Des preuves attendues : diff, commande de test et son résultat, fichiers modifiés.
• Un critère d'arrêt : tests au vert, couverture minimale, ou escalade.
• Un budget : nombre d'itérations, temps maximum, coût maximum.

Sources de vérité et débogage : escalader plutôt qu'inventer

Un modèle génératif reste probabiliste : sans sources de vérité, il compensera avec du vraisemblable. Imposez donc une hiérarchie explicite, du plus fiable au moins fiable.

• Le code et les tests du dépôt, comme vérité opérationnelle.
• La documentation interne versionnée : décisions d'architecture, notes techniques, fichiers de mise en route.
• Les tickets et les demandes de fusion, comme historique des décisions.
• À défaut, l'escalade humaine au lieu d'inventer.

La même règle gouverne le débogage, qui échoue dès que l'agent corrige avant d'avoir reproduit. Imposez la séquence reproduction, hypothèses, correctif minimal, puis test qui échoue avant et passe après, détaillée sur l'agent d'IA dans VS Code. Ne demandez pas « d'être correct », demandez « d'être prouvable ».

Permissions, budgets et boucles : ce qui empêche l'agent de dériver

Un agent Claude Code manipule des fichiers, exécute des commandes et agit sur la gestion de version. La question n'est pas « peut-il le faire ? » mais « dans quel périmètre ? ». La réponse s'écrit une fois pour tous les runs, avec la preuve attendue, car une autorisation sans trace n'est pas contrôlée.

Cette grille décline sur un dépôt les trois premiers des quatre niveaux de droits du pilier : lecture seule, écriture contrôlée avec validation humaine, exécution supervisée. Chaque case se discute une seule fois avec l'équipe technique, et la grille vaut du premier agent au dixième.

Escalade et budgets : empêcher la boucle correctrice de tourner

L'humain dans la boucle est un accélérateur de fiabilité, pas un frein : l'agent fait le travail lourd, l'humain valide les points critiques. Le déclencheur de validation s'écrit en trois règles.

• Autonomie totale sur les tâches réversibles : formatage, documentation, tests.
• Validation obligatoire sur la sécurité, l'authentification, le paiement et les dépendances.
• Escalade si les tests échouent après N itérations ou en cas d'ambiguïté fonctionnelle.

Le risque propre aux agents qui itèrent est de tourner en rond : corriger un test en cassant un autre. La prévention passe par des budgets non négociables.

• Une limite d'itérations, par exemple trois cycles correctifs au maximum.
• Une limite de périmètre : répertoires et modules autorisés.
• Une limite de coût et de durée, arrêtée avant le lancement.
• Une vérification finale obligatoire : tests, plus synthèse des changements.

Secrets, environnement isolé et échecs propres

Un agent qui exécute des commandes voit ce que voit votre environnement, et aucune commande n'est sûre par nature : lancer les tests, le lint ou le build, c'est exécuter du code venu du dépôt (scripts d'installation, plugins, hooks) avec les droits de la session. On les autorise par défaut parce qu'elles sont réversibles, pas inoffensives. Quatre points se vérifient avant le premier run.

• Secrets hors de l'espace de travail : variables d'environnement limitées, coffre-fort.
• Environnement de test isolé, pour les commandes de routine comme pour les autres.
• Masquage des logs : jetons, clés d'API, données client.
• Branches de production protégées, avec demande de fusion obligatoire.

Un agent qui agit doit enfin savoir échouer proprement, sans action partielle irréversible ni répétition dangereuse. Quatre mécanismes couvrent l'essentiel.

Mesurer un agent sur un dépôt : logs, reproductibilité, indicateurs

Si votre agent échoue, vous devez pouvoir répondre à trois questions : qu'a-t-il fait, pourquoi, et avec quelles données ? Rejouer un run suppose d'avoir journalisé cinq éléments.

• Le prompt système, le prompt utilisateur et les paramètres : modèle, limites.
• La liste des fichiers consultés et modifiés.
• Les commandes exécutées et leurs sorties, en masquant les secrets.
• Les résultats de tests, de lint et de build.
• L'identifiant de run, l'horodatage, la durée et le coût estimé.

Vient ensuite la mesure, où beaucoup d'équipes se trompent d'unité : la qualité du code plutôt que le coût de sa relecture. Sur des tâches représentatives et un protocole constant, six indicateurs tiennent ensemble.

• La taille des diffs et le nombre de fichiers modifiés.
• Le taux de réussite des tests avant et après.
• Le nombre d'itérations nécessaires pour stabiliser.
• Le temps humain de relecture, en minutes, rapporté au temps agent.
• Le temps de stabilisation, du premier échec au vert.
• Le taux de régressions détectées après fusion.

Le quatrième tranche, à condition de le lire correctement : ce qui compte est la somme du temps agent et du temps de relecture, comparée au temps du même travail à la main. Dix minutes d'agent et quarante de relecture font cinquante minutes : face à plusieurs heures de travail manuel, l'opération reste rentable. Le signal d'alarme apparaît quand ce total rejoint la référence manuelle, et cette comparaison décide l'extension à d'autres équipes.

Le sixième mesure le coût réel : une régression détectée après fusion annule plusieurs runs réussis. Quant aux scores de référence, ils ne se citent que rattachés au modèle et au protocole qui les ont produits, et ne disent rien de votre dépôt. Votre critère d'acceptation s'écrit en tests au vert sur votre base de code.

Continuez votre lecture

Selon le point où votre projet bute, cinq articles prolongent celui-ci.

• Votre tâche porte sur des sites et des interfaces tierces, pas sur un dépôt : navigateur distant et reprise de contrôle sont le sujet de l'agent d'IA de ChatGPT.
• Vous cherchez la méthode avant l'outil, ou votre agent sort du périmètre du code : la démarche complète est déroulée dans le guide pour créer un agent d'IA.
• Vous butez sur le niveau d'autonomie lui-même : seuils, paliers de délégation et ce qu'on ne délègue jamais sont traités sur les agents d'IA autonomes.
• Votre sujet devient la chaîne de contribution plutôt que l'exécution locale : branches, revues et fusion relèvent de l'agent d'IA sur GitHub.
• Votre contrainte porte sur la localisation des traitements plus que sur l'outillage : les modèles ouverts sont le sujet de l'agent d'IA Mistral.

Si l'agent à cadrer porte sur vos données et vos règles métier plutôt que sur votre code, c'est le cadre d'une IA personnalisée pour votre entreprise.

FAQ sur les agents d'IA avec Claude

Qu'est-ce qu'un agent Claude ?

Un agent Claude est un système qui utilise les modèles Claude pour planifier et exécuter des tâches avec un degré d'autonomie, via des outils : fichiers, commandes, intégrations. Il se distingue d'un assistant parce qu'il agit sur un environnement, observe le résultat et recommence jusqu'à un critère d'arrêt fixé par vous.

Comment Claude se compare-t-il à ChatGPT ?

Les deux offrent des modèles conversationnels et une couche technique pour les appeler ; l'écart se joue sur l'écosystème agentique. Côté Claude, des outils orientés dépôt avec Claude Code, un contexte large et des sous-agents ; côté ChatGPT, un mode agent tourné vers le navigateur. Le bon critère est ce que votre agent doit toucher.

Comment créer un agent avec Claude ?

Suivez une séquence dans cet ordre : définir l'objectif et les indicateurs, puis les outils autorisés, imposer un schéma de sortie vérifiable, ajouter les garde-fous, et tester sur un périmètre pilote. L'erreur la plus fréquente est d'inverser les deux premières étapes.

Claude Code est-il indispensable pour construire un agent orienté développement ?

Non, mais c'est un accélérateur décisif si votre agent doit agir directement sur un dépôt. Dans un chat, vous êtes la boucle d'exécution ; un agent Claude Code opère sur tout le projet, lance les tests et itère seul. Si votre tâche ne touche pas de fichiers, l'intérêt tombe.

Comment structurer des sous-agents pour éviter la perte de contexte et les erreurs ?

Découpez par livrables, pas par rôles abstraits : un sous-agent doit pouvoir être jugé sur ce qu'il rend. Imposez entre eux une synthèse courte au format constant (fait, reste à faire, décisions, fichiers touchés). Réservez le découpage aux tâches parallélisables, car chaque sous-agent repart d'un contexte vide et consomme son budget.

Quels garde-fous mettre en place avant d'autoriser l'écriture de fichiers ou l'exécution de commandes ?

Appliquez une politique de permissions minimale : écriture sur une branche dédiée, commandes de routine en environnement isolé, secrets hors de l'espace de travail, demande de fusion obligatoire sur les branches protégées. Ajoutez des budgets d'itérations, de durée et de coût, et une preuve finale : tests au vert et liste des fichiers modifiés.

Comment évaluer la fiabilité d'un agent en conditions réelles ?

Mesurez sur des tâches représentatives, avec un protocole constant : tests, régressions après fusion, itérations consommées, temps agent et temps de relecture. L'indicateur qui décide d'une généralisation est la somme du temps agent et du temps de relecture, comparée au temps du même travail à la main ; tant qu'elle reste nettement inférieure, l'usage peut s'étendre.

Comment réduire les hallucinations et imposer des réponses vérifiables ?

Ne demandez pas « d'être correct », demandez « d'être prouvable » : chemins de fichiers, commandes exécutées, sorties de tests, et pour toute affirmation hors du dépôt, une référence explicite ou une escalade. Donnez aussi à l'agent ses sources de vérité, code et tests en premier.