Les 5 Patterns d'Architecture d'Agents IA avec Claude

Workflows vs Agents : La Distinction Fondamentale

Avant de plonger dans les patterns, une distinction essentielle :

• →Workflows : Les LLM et outils sont orchestrés via des chemins de code prédéfinis. Le développeur contrôle le flux.
• →Agents : Les LLM dirigent dynamiquement leurs propres processus et l'utilisation des outils. L'IA décide de la marche à suivre.

La brique de base de tout système agentique est le LLM Augmenté : un LLM enrichi par la récupération d'informations (retrieval), des outils et de la mémoire. Pour approfondir la brique retrieval, consultez notre guide sur les fondamentaux du RAG.

Quels patterns d'agent shippent vraiment en production (et lesquels non)

La taxonomie des patterns d'agent vient du post « Building Effective Agents » d'Anthropic et est devenue le vocabulaire partagé du domaine. Les threads sur r/LocalLLaMA, r/MachineLearning, r/ExperiencedDevs et r/LangChain suivent la vraie expérience opérationnelle : la plupart des équipes shippent des workflows, pas des agents autonomes, et les patterns qui paraissent simples sur papier sont ceux qui atteignent la production.

Patterns qui shippent :

• →Prompt chaining. Le pattern le plus commun en production. Déterministe, debuggable, échoue de façon prévisible. LangChain, LlamaIndex et les pipelines Python custom l'implémentent tous bien.
• →Routing avec classifieurs. Un modèle bon marché décide quel modèle cher ou quel prompt spécialisé traite la requête. Marche parce que la tâche de routing est étroite.
• →Parallélisation pour sous-tâches indépendantes. Traitement batch, résumé multi-aspect, robustesse basée sur vote. Simple à implémenter et tester.
• →Boucles évaluateur-optimiseur avec terminaison dure. Le générateur propose, l'évaluateur score, la boucle termine à N itérations ou seuil. Sûr en production parce que la boucle est bornée.

Patterns qui échouent discrètement :

• →Agents autonomes avec usage d'outils ouvert dans des domaines non fiables. Le papier Voyager a montré des démos impressionnantes ; les équipes d'ingénierie en production rapportent que les agents autonomes dans des codebases réels désordonnés, systèmes clients, ou environnements légaux échouent de façons chères à debug.
• →Orchestrateur-workers avec beaucoup de workers. Marche avec 2-3 workers ; se défait à 10+ parce que l'overhead de coordination et la dérive de contexte dominent.
• →Agents avec mémoire qui « apprend » dans le temps. Ca sonne bien ; le problème pratique est que l'état appris est opaque, dur à version-controller, et tend à dériver de façons que l'équipe ne peut pas expliquer.

Ce que les équipes de production réussies font constamment :

• →Démarrer avec des workflows, gradués aux agents seulement quand justifié. La guidance d'Anthropic est explicite : si un workflow déterministe marche, ne saisissez pas un agent.
• →Instrumenter tout. LangSmith, Langfuse, Arize et Helicone sont table stakes. Si vous ne pouvez pas voir ce que l'agent a fait, vous ne pouvez pas l'améliorer.
• →Écrire les évals avant d'écrire l'agent. Construire des agents sans évals est le pattern le plus commun dans les projets échoués.
• →Fixer des budgets durs. Budgets de tokens, plafonds d'itérations, limites de timeout. Les agents sans budgets trouveront des façons de dépenser des ressources infinies.
• →Utiliser des sorties structurées. La validation JSON schema, Pydantic ou Instructor rendent les échecs explicites.

Frameworks à connaître (et leurs tradeoffs) :

• →LangGraph est le framework d'orchestration le plus production-ready ; aussi le plus complexe.
• →CrewAI est plus sympathique ; aussi opinionnant de façons qui ne correspondent pas à toutes les équipes.
• →AutoGen est la réponse de Microsoft ; fort sur les patterns conversation-driven.
• →Les sub-agents Claude Code et l'API OpenAI Assistants sont les options first-party.
• →Python brut + SDK Anthropic/OpenAI. Souvent le meilleur choix. Aucun framework n'est un fit propre pour chaque problème, et la plupart des frameworks finissent par devenir le bug.

Le cadrage honnête : les « patterns d'agent » qui comptent en production sont principalement les simples. Pipelines séquentiels, routing, parallélisation, boucles d'évaluateur bornées. Les patterns d'agent autonome excitants sont territoire de recherche et démo, pas de fiabilité de production. Shippez le workflow qui marche, instrumentez-le bien, ajoutez des capacités d'agent seulement là où le déterminisme d'un workflow ne peut pas résoudre le problème.

Pattern 1 : Prompt Chaining (Chaîne Séquentielle)

La tâche est décomposée en étapes séquentielles, où chaque appel LLM traite la sortie du précédent. Des portes programmatiques peuvent être ajoutées entre les étapes pour vérifier la qualité.

Quand l'utiliser : Quand la tâche se décompose naturellement en sous-tâches fixes et séquentielles.

Exemples concrets :

# Exemple : Chaîne de rédaction avec gate de vérification
def prompt_chain(input_text):
    # Étape 1 : Générer le brouillon
    draft = call_claude("Rédige un résumé de : " + input_text)
    
    # Gate : Vérifier la longueur et la pertinence
    if len(draft.split()) > 200:
        return "Draft trop long, retenter avec contrainte"
    
    # Étape 2 : Améliorer le style
    polished = call_claude("Améliore le style : " + draft)
    
    return polished

Pour un guide complet sur ce pattern, consultez notre article dédié sur le prompt chaining et les pipelines.

Pattern 2 : Routing (Classification et Redirection)

L'entrée est classifiée, puis redirigée vers un processus spécialisé. Cela permet une séparation des préoccupations : chaque branche a son propre prompt optimisé.

Quand l'utiliser : Quand il existe des catégories distinctes qui sont mieux traitées séparément.

Exemples concrets :

# Exemple : Router les requêtes par complexité vers différents modèles
def route_query(query):
    # Classifier la complexité
    category = call_claude(
        "Classe cette requête : SIMPLE, MOYEN, COMPLEXE\n" + query,
        model="haiku"
    )
    
    # Router vers le bon modèle
    model_map = {
        "SIMPLE": "haiku",
        "MOYEN": "sonnet", 
        "COMPLEXE": "opus"
    }
    
    return call_claude(query, model=model_map.get(category, "sonnet"))

Pour approfondir ce pattern, découvrez notre guide sur le routing conditionnel de prompts.

Pattern 3 : Parallélisation

Les sous-tâches sont exécutées simultanément, puis les résultats sont agrégés. Deux variantes principales :

1. →Sectioning : Sous-tâches indépendantes en parallèle
2. →Voting : La même tâche exécutée plusieurs fois pour obtenir un consensus

Quand l'utiliser : Quand les sous-tâches peuvent être parallélisées OU quand plusieurs perspectives sont nécessaires.

Exemples concrets :

import asyncio

# Exemple : Code review parallélisé (sectioning)
async def parallel_code_review(code):
    security, performance, style = await asyncio.gather(
        call_claude_async("Analyse la sécurité de ce code :\n" + code),
        call_claude_async("Analyse la performance de ce code :\n" + code),
        call_claude_async("Analyse le style de ce code :\n" + code),
    )
    
    # Agrégation des résultats
    return call_claude(
        f"Synthétise ces 3 analyses en un rapport unifié :\n"
        f"Sécurité: {security}\nPerformance: {performance}\nStyle: {style}"
    )

Notre article sur les patterns map-reduce explore en détail les stratégies de décomposition et d'agrégation parallèle.

Pattern 4 : Orchestrateur-Workers

Un LLM central (l'orchestrateur) décompose dynamiquement la tâche, délègue à des workers, puis synthétise les résultats. La différence clé avec la parallélisation : les sous-tâches ne sont pas prédéfinies, l'orchestrateur les détermine à la volée.

Quand l'utiliser : Quand les sous-tâches ne peuvent pas être prédites à l'avance (ex : modification de code sur plusieurs fichiers).

Exemples concrets :

# Exemple : Orchestrateur-workers pour du refactoring
def orchestrator_workers(task):
    # L'orchestrateur analyse et planifie
    plan = call_claude(
        "Analyse cette tâche et décompose-la en sous-tâches.\n"
        "Retourne un JSON avec les sous-tâches.\n" + task,
        model="sonnet"
    )
    
    subtasks = json.loads(plan)
    
    # Les workers exécutent en parallèle
    results = []
    for subtask in subtasks:
        result = call_claude(subtask["prompt"], model="haiku")
        results.append(result)
    
    # L'orchestrateur synthétise
    return call_claude(
        "Synthétise ces résultats en une réponse cohérente :\n"
        + "\n".join(results),
        model="sonnet"
    )

Pattern 5 : Évaluateur-Optimiseur

Un LLM génère une réponse, un second l'évalue et fournit du feedback, puis le premier raffine. Ce cycle continue jusqu'à ce que la qualité soit satisfaisante.

Quand l'utiliser : Quand il existe des critères d'évaluation clairs ET que le raffinement itératif apporte une valeur mesurable.

Exemples concrets :

# Exemple : Boucle évaluateur-optimiseur
def evaluator_optimizer(task, max_iterations=3):
    response = call_claude("Génère : " + task)
    
    for i in range(max_iterations):
        # Évaluation
        evaluation = call_claude(
            f"Évalue cette réponse sur 10.\n"
            f"Tâche: {task}\nRéponse: {response}\n"
            f"Si score < 8, donne un feedback précis pour améliorer."
        )
        
        if "score: 8" in evaluation or "score: 9" in evaluation or "score: 10" in evaluation:
            return response  # Qualité suffisante
        
        # Raffinement avec le feedback
        response = call_claude(
            f"Améliore cette réponse en tenant compte du feedback.\n"
            f"Réponse précédente: {response}\n"
            f"Feedback: {evaluation}"
        )
    
    return response

Pour évaluer systématiquement les sorties de vos prompts, consultez notre guide sur les évaluations Claude.

Agents Autonomes : Quand le LLM Prend les Commandes

Au-delà des workflows structurés, les agents autonomes laissent le LLM décider dynamiquement de chaque prochaine action. C'est essentiellement un LLM qui utilise des outils dans une boucle, guidé par le feedback de l'environnement.

Principes clés pour les agents autonomes :

1. →Ground truth à chaque étape, L'agent doit vérifier le résultat réel de ses actions (ex : exécuter les tests, pas deviner s'ils passent)
2. →Conditions d'arrêt, Définir un nombre maximal d'itérations pour éviter les boucles infinies
3. →Intervention humaine, Prévoir un mécanisme pour que l'agent demande de l'aide quand il est bloqué
4. →Bac à sable, Exécuter dans un environnement contrôlé avec des permissions limitées

Quand utiliser un agent autonome :

• →Problèmes ouverts où le nombre d'étapes est imprévisible
• →Environnements fiables avec feedback clair (ex : tests automatisés)
• →Tâches où l'humain accepte de déléguer le contrôle

Quand NE PAS utiliser un agent autonome :

• →Tâches avec un chemin d'exécution prévisible → utilisez un workflow
• →Environnements à haut risque sans rollback possible
• →Quand la latence ou le coût sont critiques

Pour approfondir le pattern d'agent autonome, lisez notre guide sur la méthode ReAct qui détaille la boucle Pensée→Action→Observation.

Concevoir l'Interface Agent-Ordinateur (ACI)

Tout comme on investit dans l'interface humain-ordinateur (HCI/UX), il faut soigner l'Agent-Computer Interface (ACI), la façon dont l'agent interagit avec ses outils.

Principes de Design ACI

# ❌ Mauvais design ACI : noms cryptiques, pas d'exemples
tools = [{
    "name": "q",
    "description": "Query",
    "input_schema": {"query": "string"}
}]

# ✅ Bon design ACI : noms clairs, exemples, cas limites
tools = [{
    "name": "search_knowledge_base",
    "description": "Search the knowledge base for relevant articles. "
                   "Returns top matches with title and excerpt. "
                   "Example: search_knowledge_base('comment configurer MCP') "
                   "Returns empty array if no matches. Max 20 results.",
    "input_schema": {
        "type": "object",
        "properties": {
            "query": {
                "type": "string",
                "description": "Natural language search query. Be specific."
            },
            "max_results": {
                "type": "integer",
                "default": 10,
                "description": "Maximum number of results (1-20)"
            }
        },
        "required": ["query"]
    }
}]

Pour en savoir plus sur le design d'outils pour agents, consultez notre guide sur le tool use avec Claude et notre article sur les skills personnalisés Claude Code.

Arbre de Décision : Quel Pattern Choisir ?

Bonnes Pratiques Universelles

1. →Commencez simple, Un prompt bien écrit résout souvent le problème sans orchestration
2. →Ajoutez de la complexité progressivement, Chaque couche doit apporter une valeur mesurable
3. →Priorisez la transparence, Montrez les étapes de planification de l'agent (pas de boîte noire)
4. →Soignez l'ACI, Investissez autant dans le design des outils que dans les prompts
5. →Testez extensivement, Exécutez des centaines d'exemples, itérez sur les définitions d'outils

Pour Aller Plus Loin

• →Méthode ReAct : Comment les agents IA pensent et agissent, La boucle fondamentale Pensée→Action→Observation
• →Prompt Chaining et Pipelines, Approfondissement du pattern 1
• →Routing Conditionnel de Prompts, Approfondissement du pattern 2
• →Patterns Map-Reduce, Techniques de décomposition parallèle
• →Tool Use avec Claude, Donner des outils à vos agents
• →Évaluations Claude, Mesurer la qualité de vos systèmes agentiques