Cours Agents — agents IA, boucle d'outils, sous-agents, limites et risques

Objectifs d'apprentissage

À la fin de ce cours, l'apprenant peut :

1. définir un agent et le distinguer d'un chatbot et d'un workflow ;
2. décrire la boucle « modèle, outil, résultat, modèle » et ses conditions d'arrêt ;
3. choisir un schéma d'orchestration (enchaînement, routage, parallélisation, orchestrateur et travailleurs, évaluateur) ;
4. expliquer ce qu'apporte un sous-agent et ce qu'il coûte ;
5. lister les risques d'un agent (erreurs cumulées, coût, injection de consignes, droits excessifs, actions irréversibles) et leurs garde-fous ;
6. concevoir sur papier un agent borné, avec permissions et vérification ;
7. appliquer la règle de confidentialité : ce qu'il ne faut pas confier à un agent connecté à un service hébergé.

Prérequis

• Avoir utilisé un assistant IA conversationnel.
• Notions de ligne de commande et de fichiers ; savoir lire un pseudo-code.
• Les cours Claude Code et Skills/agentique de cette section sont complémentaires.

Parcours et chapitres

1. Qu'est-ce qu'un agent ?

Définitions officielles (aucune n'est « la » définition) :

• Anthropic (« Building Effective Agents ») : les workflows orchestrent modèles et outils par des chemins de code prédéfinis ; les agents laissent le modèle « diriger dynamiquement son propre processus et son usage des outils », en gardant le contrôle de la manière de réaliser la tâche.
• OpenAI (guide développeur) : des systèmes qui peuvent planifier et accomplir des tâches avec des outils, collaborer avec d'autres agents et conserver du contexte entre les étapes.
• Claude Agent SDK : une application qui accomplit une tâche en planifiant ses propres étapes et en appelant des outils qui lisent des fichiers, exécutent des commandes ou modifient du code.

Point commun : un modèle + des outils + une boucle + un état/contexte. Un chatbot répond ; un agent agit et décide de la suite d'après les résultats.

2. La boucle d'outils

Le fonctionnement décrit pour Claude Code : trois phases qui se mélangent, rassembler du contexte, agir, vérifier, répétées jusqu'à ce que la tâche paraisse terminée ou que l'utilisateur interrompe. Le modèle raisonne ; les outils (fichiers, recherche, exécution, web, services externes) agissent ; chaque résultat d'outil revient dans le contexte et oriente le tour suivant.

Pseudo-code synthétique (non exécuté) :

contexte = [consigne, règles]
répéter jusqu'à arrêt:
    réponse = modèle(contexte, outils_disponibles)
    si réponse demande un outil:
        si l'action est autorisée (règles, confirmation humaine):
            résultat = exécuter(outil, arguments)
        sinon:
            résultat = "refusé"
        contexte += [demande, résultat]
    sinon:
        retourner réponse            # tâche jugée terminée
    si limite atteinte (tours, budget, temps): arrêter et rendre compte

Trois endroits où le contrôle s'exerce : avant l'outil (permissions, confirmation), dans l'outil (isolation, droits réduits), après (vérification du résultat). La documentation de Claude Code insiste sur le troisième : donner à l'agent un moyen de vérifier (tests, build, linter, capture d'écran) ; sans lui, « ça a l'air fini » est le seul signal et l'humain devient la boucle de vérification.

Le contexte est une ressource limitée : la documentation indique que les performances baissent quand la fenêtre se remplit et décrit compaction, nettoyage et sous-agents pour la gérer.

3. Schémas d'orchestration

Anthropic décrit cinq schémas de base (état de l'article consulté ; sa date de publication n'a pas été vérifiée ici) :

Conseil de l'article : commencer simple ; n'utiliser un agent autonome que pour les problèmes ouverts aux étapes imprévisibles, avec des critères de réussite mesurables, des essais en bac à sable et des garde-fous, car les agents coûtent plus et leurs erreurs se cumulent. Soigner la conception des outils (descriptions claires, paramètres difficiles à mal utiliser) autant que les consignes.

4. Outils et protocole MCP

Un outil est une fonction que le modèle peut demander d'appeler. Le protocole ouvert MCP (Model Context Protocol) standardise la connexion entre applications d'IA et systèmes externes : des hôtes (applications d'IA) ont des clients qui parlent à des serveurs exposant des outils, des ressources et des invites. La spécification (page consultée, version datée 2026-07-28) pose des principes : consentement et contrôle de l'utilisateur, confidentialité des données, et surtout « sûreté des outils » : les outils représentent une exécution de code arbitraire et doivent être traités avec prudence ; les descriptions d'outils sont non fiables sauf si le serveur est de confiance ; l'hôte doit obtenir un consentement explicite avant d'invoquer un outil. La spécification reconnaît que le protocole ne peut pas imposer ces principes lui-même.

Un serveur MCP local est un programme exécuté avec les droits de l'utilisateur ; un serveur distant reçoit ce que l'agent lui envoie. Les deux élargissent la surface d'attaque (voir le chapitre 7 et le cours Skills et approche agentique).

5. Sous-agents

Selon la documentation de Claude Code, un sous-agent est un assistant spécialisé qui travaille dans sa propre fenêtre de contexte, avec sa consigne propre, des outils éventuellement restreints, et ne renvoie qu'un résumé. Intérêts : garder la conversation principale propre, paralléliser, spécialiser, limiter les outils par rôle. Éléments documentés (état consulté) :

• défini par un fichier Markdown à en-tête (name, description, tools, model…) dans .claude/agents/ (projet) ou ~/.claude/agents/ (utilisateur) ;
• agents intégrés : Explore et Plan (lecture seule) et un agent généraliste ;
• le sous-agent ne reçoit pas l'historique de la conversation, mais le message de délégation, ses consignes et, selon les cas, les fichiers de contexte du projet ;
• profondeur d'imbrication limitée par défaut (3 niveaux, configurable) ;
• les sous-agents en arrière-plan ont un jeu d'outils restreint et un nombre d'exécutions simultanées plafonné (valeurs susceptibles de changer) ;
• les demandes comptent dans les mêmes limites d'utilisation que la conversation principale : un sous-agent ne rend pas l'exécution gratuite.

Limite à garder en tête : le sous-agent reste un modèle ; un relecteur indépendant n'est utile que s'il part d'un contexte neuf et d'un critère précis. La documentation avertit qu'un relecteur sommé de « trouver des lacunes » en trouvera, même sur un travail sain : borner la demande aux écarts qui touchent l'exactitude ou les exigences.

6. Évaluer un agent

Anthropic (article d'ingénierie sur les évaluations d'agents, connu ici par résumé de recherche, non ouvert directement) distingue : la tâche (cas de test avec critères de succès), l'essai (une tentative ; on en répète plusieurs car les sorties varient), le correcteur (logique qui note), la transcription (trace complète : sorties, appels d'outils, raisonnements). Idées à retenir : évaluer le résultat et la trajectoire ; répéter les essais ; garder des tâches réalistes ; lire des transcriptions.

Pour un usage personnel, un minimum : 5 à 10 tâches synthétiques, un critère vérifiable par tâche (test qui passe, fichier attendu), trois essais, un tableau des échecs et de leurs causes.

7. Limites et risques

Principe de ce corpus (non une citation) : le risque monte quand un même agent cumule accès à des données privées, lecture de contenu non fiable et moyen d'émettre vers l'extérieur ; casser l'un des trois réduit fortement l'exposition.

Les sources officielles consultées convergent : Claude Code (documentation Sécurité) recommande de relire les commandes avant approbation, d'éviter d'injecter directement du contenu non fiable, d'utiliser des machines virtuelles pour les appels externes, et reconnaît qu'aucune protection n'est infaillible ; OpenAI décrit des confirmations avant actions à conséquence et une surveillance contre l'injection ; la spécification MCP exige consentement et prudence sur les outils.

8. Concevoir un agent borné

Liste de contrôle avant de lancer un agent :

1. Objectif en une phrase, critère de réussite vérifiable.
2. Outils : liste minimale ; lecture seule d'abord.
3. Permissions : mode prudent ; règles de refus explicites ; confirmation pour écrire, supprimer, envoyer, dépenser.
4. Isolation : dossier de travail dédié, branche ou copie, conteneur ou VM pour les actions risquées.
5. Bornes : nombre de tours, budget, durée.
6. Données : exemples synthétiques ; aucune donnée sensible (chapitre 9).
7. Observabilité : journal des actions, transcription conservée localement.
8. Retour arrière : sauvegarde, git, plan de restauration testé.
9. Évaluation : mini-jeu de tâches avant d'étendre l'usage.
10. Revue humaine du résultat avant tout effet extérieur.

Cette ligne n'est pas exécutée par le cours.

9. Confidentialité : ce qu'il ne faut pas confier à un agent

Un agent branché sur un modèle hébergé envoie au service tout ce qu'il lit (fichiers, sorties de commandes, pages) et peut le renvoyer à des outils. Ne jamais lui faire lire ni transmettre : mots de passe, clés d'API, jetons, clés privées, fichiers .env, identifiants, noms d'hôtes ou détails d'infrastructure réelle, tickets privés, données de santé, données personnelles de tiers, documents confidentiels d'un employeur ou d'un client, contenus sous droits, sans autorisation et examen préalable. Protéger les fichiers sensibles par des règles de refus de lecture et par l'isolation, pas seulement par une consigne. Utiliser des exemples synthétiques (exemple.invalid, valeurs fictives).

Les agents sauvegardent souvent des transcriptions ou une mémoire : savoir où (par exemple, Claude Code stocke les transcriptions en clair sous ~/.claude/projects/, 30 jours par défaut selon sa documentation) et les purger quand elles ne sont plus utiles.

Exercices et vérifications de fin de cours

1. Vocabulaire : définir agent, workflow, outil, sous-agent, serveur MCP, en une phrase chacun, avec une source.
2. Boucle : pseudo-code complet d'un agent « relis ce texte » avec arrêts.
3. Choix de schéma : cinq besoins, schéma et justification.
4. Menace : scénario d'injection, trois barrières.
5. Mini-évaluation : cinq tâches de test avec critères exécutables.
6. Liste de contrôle appliquée à un agent réel de Stéphane décrit de façon abstraite.

Critères de réussite

• Distinguer chatbot, workflow, agent.
• Expliquer pourquoi la vérification externe est centrale.
• Citer au moins six risques et un garde-fou pour chacun.
• Dire ce qu'un sous-agent isole et ce qu'il ne règle pas (coût, fiabilité).
• Appliquer la règle « rien de sensible ».