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.

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