Dernière révision : mai 2026
Une référence concise des modèles d'architecture évalués par l'examen CCA-F. Lisez de haut en bas ou sautez à une section.
Choisir entre un agent unique et un essaim multi-agents pour un workflow complexe.
Commencez avec un agent unique + outils. Ne divisez en plusieurs agents que lorsque les limites des tâches sont claires, que les fenêtres de contexte débordent, ou que différents niveaux de modèle sont nécessaires par sous-tâche.
Pourquoi: Le multi-agent ajoute de la latence, une surface d'erreur et des coûts d'orchestration. La plupart des charges de travail de production réussissent avec un agent bien outillé.
L'agent doit raisonner sur les observations avant d'agir à nouveau.
Implémentez une boucle ReAct (Raisonner + Agir) : le modèle génère une pensée, sélectionne un outil, reçoit le résultat et répète jusqu'à ce qu'une condition d'arrêt soit remplie.
Pourquoi: ReAct rend le raisonnement intermédiaire visible, améliorant la débogabilité et vous permettant d'auditer la chaîne de pensée.
L'agent doit interagir avec des systèmes externes (API, bases de données, systèmes de fichiers).
Définissez des outils via l'API tool_use. Le modèle émet un bloc tool_use ; votre code l'exécute et renvoie un tool_result. Le modèle continue ensuite.
L'orchestrateur doit distribuer des sous-tâches hétérogènes (revue de code, recherche web, analyse de données).
Utilisez un agent superviseur qui décompose l'objectif, délègue à des sous-agents spécialistes et agrège les résultats. Chaque sous-agent a son propre prompt système et son propre ensemble d'outils.
Plusieurs sous-agents doivent se coordonner sans communication directe de pair à pair.
Acheminez tous les messages inter-agents via un superviseur. Le superviseur décide quel sous-agent s'exécute ensuite, transmet le contexte et applique les contraintes d'ordonnancement.
Pourquoi: La messagerie directe entre pairs crée des cycles et rend l'état difficile à suivre. Un superviseur central maintient le DAG d'exécution explicite.
L'agent doit se souvenir du contexte tout au long d'une session multi-tours.
Passez l'historique complet de la conversation (système + tours utilisateur/assistant précédents) dans le tableau de messages. Pour les sessions longues, résumez les tours plus anciens pour rester dans la fenêtre de contexte.
L'agent a besoin de persistance entre les sessions ou entre les utilisateurs.
Stockez les faits dans une couche de mémoire externe (base de données vectorielle, magasin clé-valeur, fichier). Récupérez les souvenirs pertinents via RAG et injectez-les dans le prompt système à chaque tour.
L'équipe utilise par défaut l'architecture agentique pour chaque fonctionnalité LLM.
N'utilisez pas d'agents lorsqu'un seul prompt + une sortie structurée suffisent. Les agents ajoutent de la latence, des coûts et des modes de défaillance. Réservez les boucles agentiques pour les tâches nécessitant une itération ou l'utilisation d'outils.
Une tâche de raisonnement complexe nécessite plus de délibération interne avant la réponse.
Activez la réflexion étendue avec un paramètre budget_tokens. Le modèle utilise un bloc de pensée avant de répondre, améliorant la précision sur les problèmes à plusieurs étapes.
Pourquoi: La réflexion étendue échange la latence contre la qualité. Définissez budget_tokens proportionnellement à la complexité de la tâche ; plafonnez-le pour contrôler les coûts.
L'appel d'outil renvoie une erreur ; l'agent doit se récupérer gracieusement.
Renvoie l'erreur en tant que tool_result avec is_error: true. Le modèle voit l'échec et peut réessayer avec des paramètres corrigés, essayer un outil alternatif ou expliquer l'échec à l'utilisateur.
Défaillances transitoires de l'API (429, 529) pendant une boucle agentique.
Implémentez une attente exponentielle avec jitter. Pour les 429 (limite de débit), respectez l'en-tête retry-after. Pour les 529 (surchargé), attendez plus longtemps. Ne réessayez jamais les erreurs de classe 400 aveuglément.
Mesurer si un système agentique s'améliore réellement au fil du temps.
Construisez une suite d'évaluation : définissez des paires entrée-sortie, exécutez l'agent, notez les sorties (correspondance exacte, LLM en tant que juge, révision humaine). Suivez le taux de réussite par version.
Pourquoi: Sans évaluations, les ajustements de prompt sont des suppositions. La détection de régression nécessite une notation automatisée et reproductible.
L'agent produit une sortie de mauvaise qualité au premier passage.
Ajoutez une étape de réflexion : après avoir généré une réponse, invitez le modèle à critiquer sa propre sortie et à la réviser. Utilisez un tour de message séparé ou une réflexion étendue.
Le workflow agentique effectue des actions irréversibles (suppression de ressources, envoi d'e-mails).
Insérez un point de contrôle avant les opérations destructrices. Présentez l'action prévue à l'utilisateur, attendez l'approbation, puis exécutez. Enregistrez la décision pour l'audit.
Plusieurs fichiers CLAUDE.md dans un monorepo ; la priorité n'est pas claire.
Trois niveaux : ~/.claude/CLAUDE.md (utilisateur), CLAUDE.md à la racine du projet (projet), CLAUDE.md enfant de l'espace de travail (espace de travail). Tous sont fusionnés ; l'espace de travail prévaut sur le projet, qui prévaut sur l'utilisateur.
L'équipe souhaite des prompts réutilisables invoqués comme /ma-commande.
Créez un fichier .claude/commands/<nom>.md contenant le modèle de prompt. Invoquez avec /<nom>. Utilisez $ARGUMENTS pour la saisie utilisateur. Les commandes de portée projet résident dans le dépôt.
Exécuter un linter automatiquement après que Claude a modifié un fichier.
Configurez un hook PostToolUse dans settings.json qui correspond à l'outil Écrire/Éditer. Le script du hook s'exécute après l'achèvement de l'outil ; une sortie non nulle bloque le changement.
Claude Code demande la permission à chaque commande shell ; ralentissant l'itération.
Utilisez des motifs de liste d'autorisation dans settings.json sous permissions.allow. Trois modes : par défaut (demande pour chaque), liste d'autorisation (approbation automatique des motifs correspondants), et yolo (approbation automatique de tout — non recommandé pour la production).
Le développeur souhaite des overrides personnels non commis au dépôt.
settings.json est commis (paramètres par défaut de l'équipe). settings.local.json est ignoré par git (overrides personnels). Les paramètres locaux fusionnent au-dessus des paramètres du projet.
Exécuter Claude Code dans un pipeline CI sans terminal interactif.
Utilisez `claude -p "prompt" --output-format json` en mode sans tête. Passez l'entrée via stdin, analysez la sortie structurée. Définissez ANTHROPIC_API_KEY comme secret CI.
Claude Code a besoin d'accéder à un serveur MCP personnalisé (base de données, API interne).
Ajoutez le serveur à mcpServers dans settings.json avec la commande et les arguments. Claude Code lance le serveur MCP en tant que processus enfant et découvre les outils au démarrage.
Claude Code travaille sur une branche de fonctionnalité pendant que vous développez sur main.
Utilisez les worktrees git. Claude Code opère dans le répertoire du worktree ; votre checkout principal reste intact. Évite les conflits d'index et la jonglerie avec les stashes.
Claude Code génère des modifications, mais vous voulez des commits atomiques et propres.
Claude Code suit les modifications de fichiers et peut créer des commits avec des messages. Révisez le diff avant de commettre. Préférez la mise en scène de fichiers spécifiques plutôt que `git add -A` pour éviter les fuites de secrets.
Utilisation de Claude Code depuis VS Code ou JetBrains.
Installez l'extension Claude Code. Elle intègre la CLI en tant que panneau dans l'IDE, partageant les mêmes CLAUDE.md, hooks et paramètres. Les sessions basées sur le terminal et celles basées sur l'IDE sont interchangeables.
Prompt long avec plusieurs sections ; le modèle confond les instructions avec les données.
Enveloppez les sections dans des balises XML : <instructions>, <context>, <examples>. Claude est entraîné à respecter les limites XML comme délimiteurs structurels.
Définir un comportement persistant sur tous les tours (ton, contraintes, persona).
Placez les instructions invariantes dans le prompt système. Gardez-le concis : rôle, contraintes, format de sortie. Les messages utilisateur portent le contexte par tour ; le système porte les règles de la session.
Forcer le modèle à commencer sa réponse par un préfixe spécifique (par exemple, accolade ouvrante JSON).
Ajoutez un message assistant partiel à la fin du tableau de messages. Claude continue là où vous vous êtes arrêté. Utile pour faire respecter le format de sortie.
Le format de sortie du modèle est incohérent malgré des instructions détaillées.
Ajoutez 2-3 exemples "few-shot" sous forme de paires de tours utilisateur/assistant avant la requête réelle. Les exemples ancrent le format, le ton et le style de raisonnement de manière plus fiable que les instructions en prose.
Le modèle saute des étapes de raisonnement sur des problèmes logiques à plusieurs étapes.
Invitez avec "Pensez étape par étape" ou utilisez la réflexion étendue. Pour la production, utilisez la réflexion étendue (budget_tokens) plutôt que d'inviter à une chaîne de pensée visible pour garder la sortie propre.
Choisir entre des sorties déterministes et créatives.
temperature=0 pour les tâches déterministes (classification, extraction). temperature=0.5-0.7 pour l'écriture créative. temperature=1.0 pour une diversité maximale. Remarque : la réflexion étendue nécessite temperature=1.
Besoin d'une sortie JSON valide garantie du modèle.
Définissez un outil avec le schéma JSON souhaité comme input_schema. Définissez tool_choice pour forcer cet outil. Le modèle renvoie du JSON structuré dans le bloc tool_use, validé par rapport au schéma.
L'application front-end nécessite un faible temps de premier jeton.
Utilisez stream=true sur l'API Messages. Traitez les événements envoyés par le serveur de manière incrémentielle : content_block_start, content_block_delta, message_stop. Affichez les jetons au fur et à mesure de leur arrivée.
Traitement de milliers de prompts où la latence n'est pas critique.
Utilisez l'API Message Batches. Soumettez jusqu'à 100 000 requêtes par lot. Les résultats arrivent dans les 24 heures avec une réduction de coût de 50%. Interrogez ou utilisez un webhook pour l'achèvement.
Extraire des données de documents numérisés ou d'images.
Passez les images sous forme de blocs de contenu base64 (type : image) ou de pages PDF (type : document) dans le message utilisateur. Claude traite jusqu'à 20 Mo par requête. Préférez les PDF natifs aux captures d'écran pour les documents à forte densité de texte.
Choisir entre Opus, Sonnet et Haiku pour une charge de travail.
Opus : capacité la plus élevée, raisonnement complexe, tâches agentiques. Sonnet : performance/coût équilibrés, utilisation générale en production. Haiku : le plus rapide et le moins cher, classification, routage, extraction simple.
Des appels répétés partagent le même long prompt système ; vouloir réduire les coûts.
Marquez le contenu cacheable avec cache_control: { type: "ephemeral" }. Les préfixes mis en cache sont réutilisés entre les appels pendant 5 minutes maximum (extension automatique en cas de succès). Le coût d'écriture est 25 % plus élevé ; le coût de lecture est 90 % moins élevé.
Définir un outil pour l'API Claude Messages.
Chaque outil a un nom, une description et un input_schema (schéma JSON). La description indique à Claude quand l'utiliser ; le schéma valide les paramètres. Gardez les descriptions orientées action et concises.
Outil exécuté avec succès ; besoin de retourner le résultat à Claude.
Envoyez un message utilisateur avec role: "user" et un bloc de contenu tool_result. Incluez le tool_use_id pour corréler. Retournez les données sous forme de texte ou de contenu structuré ; gardez les charges utiles sous 100 000 jetons.
L'agent doit récupérer des données de trois sources indépendantes simultanément.
Claude peut émettre plusieurs blocs tool_use dans une seule réponse. Exécutez-les en parallèle, puis renvoyez tous les blocs tool_result dans un seul message utilisateur. Réduit les allers-retours.
Comprendre le modèle de composants du Protocole de Contexte de Modèle (MCP).
Trois rôles : Hôte (application comme Claude Code), Client (gestionnaire de protocole par serveur), Serveur (expose les outils/ressources/prompts). Les clients maintiennent des connexions 1:1 avec les serveurs.
Choisir comment un client MCP se connecte à un serveur.
stdio : processus local, configuration la plus simple. SSE : basé sur HTTP, hérité. HTTP streamable : standard actuel pour les serveurs distants, prend en charge la reprise et les messages initiés par le serveur.
Décider quelle primitive MCP exposer.
Ressources : données en lecture seule (fichiers, lignes de base de données) que le client extrait. Outils : actions que le modèle invoque (écrire, calculer, interroger). Prompts : modèles de prompt réutilisables que l'utilisateur sélectionne. Les outils sont contrôlés par le modèle ; les ressources sont contrôlées par l'application.
Créer un serveur MCP personnalisé pour exposer des API internes.
Utilisez le SDK MCP (TypeScript ou Python). Implémentez des gestionnaires d'outils avec des schémas d'entrée. Enregistrez via server.tool(). Transport : stdio pour le local, HTTP streamable pour le distant.
L'agent doit interagir avec une application GUI (cliquer, taper, captures d'écran).
Activez les outils d'utilisation de l'ordinateur : computer_20250124 (capture d'écran + souris + clavier), text_editor_20250124, bash_20250124. Le modèle reçoit des captures d'écran et émet des actions basées sur des coordonnées.
Le modèle doit toujours appeler un outil spécifique plutôt que de répondre avec du texte.
Définissez tool_choice à { type: "tool", name: "my_tool" }. Le modèle est forcé d'appeler cet outil. Utilisez type: "any" pour exiger un appel d'outil, ou type: "auto" (par défaut) pour laisser le modèle décider.
L'application atteint la limite de contexte en milieu de conversation.
Les modèles Claude prennent en charge 200 000 jetons. Surveillez l'utilisation via response.usage. Lorsque vous approchez de la limite, résumez les tours plus anciens ou tronquez. Ne jamais supprimer silencieusement des messages.
Traitement d'un document de 150 pages qui remplit la majeure partie de la fenêtre de contexte.
Placez le document tôt dans le prompt (après le système). Mettez les questions en dernier. Utilisez la mise en cache des prompts pour éviter de les renvoyer lors des suivis. Pour les tâches multi-documents, utilisez RAG pour sélectionner les morceaux pertinents.
La base de connaissances est trop grande pour tenir dans le contexte ; le modèle a besoin d'y accéder au moment de la requête.
Intégrez et indexez les documents dans un magasin vectoriel. Au moment de la requête, récupérez les k meilleurs morceaux, injectez-les dans le message utilisateur. Citez les documents source dans la sortie pour la traçabilité.
Le modèle énonce avec assurance des faits incorrects.
Ancrez les réponses dans le contexte fourni (RAG). Demandez au modèle de dire "Je ne sais pas" lorsque les preuves sont insuffisantes. Utilisez des citations. Validez les affirmations factuelles par rapport aux documents source de manière programmatique.
L'application reçoit des réponses 429 (limite de débit atteinte) ou 529 (surchargé).
429 : vous avez atteint votre limite de débit de niveau. Faites une pause et réessayez ; respectez retry-after. 529 : l'API Anthropic est surchargée. Faites une pause plus longue. Les deux sont transitoires. Ne jamais réessayer les 400 ou 401.
Les dépenses mensuelles de l'API sont plus élevées que prévu.
Utilisez la mise en cache des prompts pour les préfixes répétés (90 % de réduction de lecture). Dirigez les tâches simples vers Haiku. Utilisez l'API Batch pour les charges de travail asynchrones (50 % de réduction). Surveillez l'utilisation des jetons par endpoint. Réduisez le contexte inutile.
Besoin de visibilité sur la consommation de jetons par requête.
Chaque réponse de l'API Messages inclut usage.input_tokens, usage.output_tokens et (si mis en cache) usage.cache_read_input_tokens. Enregistrez-les par appel, agrégez-les par endpoint, définissez des alertes budgétaires.