Agents IA vs pipelines LLM : quand choisir quoi ?

Beaucoup de projets d'intégration LLM démarrent avec un pipeline : étape 1, on extrait le contexte ; étape 2, on appelle le modèle ; étape 3, on formate la réponse. C'est prévisible, auditable, facile à tester. Mais pour les tâches complexes, ce modèle atteint rapidement ses limites.

Réponse directe : un pipeline LLM convient quand la structure du problème est connue à l'avance et que chaque étape peut être prédéfinie. Un agent IA convient quand la tâche nécessite de collecter de l'information dynamiquement, de raisonner sur plusieurs étapes et d'adapter sa stratégie en cours d'exécution. Pour la majorité des tâches métier complexes, les agents produisent de meilleurs résultats.

Qu'est-ce qu'un pipeline LLM ?

Dans un pipeline, c'est le développeur qui écrit le flux. Le LLM est appelé comme une fonction à des étapes prédéfinies.

# Pipeline classique : structure décidée par le développeur
def pipeline_rag(query: str) -> str:
    # Étape 1 : retrieval fixe
    chunks = vector_store.search(query, k=5)
    
    # Étape 2 : appel LLM avec contexte prédéfini
    context = "\n".join([c.content for c in chunks])
    response = llm.complete(f"Contexte : {context}\n\nQuestion : {query}")
    
    # Étape 3 : formatage fixe
    return response.text

Le pipeline ne peut récupérer que ce qui est défini dans l'étape 1. Si la réponse nécessite de croiser deux sources différentes, d'interroger une API supplémentaire ou de relancer une recherche avec d'autres termes, le pipeline échoue silencieusement.

Qu'est-ce qu'un agent IA ?

Dans un agent, c'est le LLM qui contrôle le flux. On lui fournit des outils et un objectif ; il décide comment les utiliser.

# Agent : le LLM décide de la stratégie
tools = [
    search_vector_store,
    call_external_api,
    read_file,
    execute_sql_query,
]
 
def run_agent(task: str) -> str:
    # Le LLM choisit quels outils appeler, dans quel ordre
    return agent.run(
        task=task,
        tools=tools,
        max_iterations=10
    )

L'agent peut relancer une recherche si les premiers résultats sont insuffisants, interroger une API externe pour enrichir le contexte, puis synthétiser l'ensemble. Le pipeline ne peut pas faire ça.

Le vrai problème du RAG classique

Le RAG traditionnel est un pipeline : récupérer N chunks via recherche vectorielle, puis générer. L'idée sous-jacente est que le retrieval peut être séparé de la génération.

Le problème : déterminer quelle information est pertinente nécessite la même intelligence que résoudre le problème lui-même. Un pipeline de RAG avec retrieval fixe oblige le développeur à prédéfinir ce qu'il faut chercher, ce qui revient à connaître la réponse avant de commencer.

Un agent RAG peut interroger plusieurs sources, reformuler la requête si les premiers chunks ne sont pas pertinents, et croiser les informations. C'est pour ça que Claude Code, Cursor et les outils de coding IA modernes sont des agents, pas des pipelines.

Quand les pipelines restent le bon choix

Les pipelines ne sont pas dépassés. Ils ont des avantages réels dans certains contextes :

Coûts prévisibles. Un pipeline effectue un nombre défini d'appels LLM. Un agent peut en faire 2 ou 20 selon la complexité de la tâche. Si vous avez un budget strict par requête, le pipeline est plus facile à contrôler.

Auditabilité totale. Dans un pipeline, chaque étape est explicite et logable. Un agent prend des décisions que vous ne voyez pas directement. Pour les contextes réglementés (finance, santé, RGPD), la traçabilité complète peut être une contrainte non négociable.

Fenêtres de contexte limitées. Certains modèles locaux open source ont des contextes de 4k-8k tokens. Les agents accumulent du contexte à travers les itérations. Sur des modèles contraints, un pipeline peut rester le seul choix viable.

Tâches dont la structure est vraiment fixe. Extraction de données dans un format standardisé, classification avec taxonomie prédéfinie, traduction en lot : ces tâches ont une structure si prévisible qu'un agent n'apporterait rien.

Quand les agents sont clairement meilleurs

Agents et sécurité : une idée reçue

On entend souvent que les agents sont plus risqués que les pipelines. C'est en partie vrai mais souvent exagéré. Les deux architectures nécessitent de valider les entrées utilisateur avant de les passer au LLM. La surface d'attaque (prompt injection, exfiltration de données) est similaire.

La vraie différence : un agent peut enchaîner des appels d'outils imprévus. C'est là que les permissions doivent être gérées : chaque outil doit être limité au minimum nécessaire. Un outil de lecture de fichiers ne doit pas avoir accès aux fichiers système ; un outil de recherche SQL doit opérer en lecture seule sur le schéma pertinent.

TL;DR

La règle pratique : commencer par un agent, revenir à un pipeline uniquement si les contraintes de coût, d'auditabilité ou de contexte le justifient.

Les outils d'IA les plus efficaces aujourd'hui (Claude Code, Cursor, les assistants de recherche) sont agentic parce que la complexité des tâches dépasse ce qu'un pipeline peut gérer. Pour les projets d'intégration LLM en entreprise, la même logique s'applique.

Vous souhaitez décider de la bonne architecture pour votre projet d'automatisation IA ? Discutons-en.