Agent IA vs chatbot classique — vu depuis le terrain

« Ce qu’il nous faut, c’est un chatbot ou un agent ? » J’entends cette question chaque semaine en réunion client. Ça ressemble à un choix de vocabulaire, mais c’est en fait la décision qui détermine l’architecture, le coût et le risque opérationnel. Voici comment je tranche concrètement.

Commençons par les définitions

Mélanger les deux mots casse le design. Voici comment je les distingue.

Un chatbot prend une entrée utilisateur, appelle le LLM une fois, renvoie la réponse. Quasi pas d’état, flux linéaire, pas d’écriture sur les systèmes externes. Bot FAQ, premier niveau de support, Q&A simple : c’est ici.

Un agent IA reçoit un objectif et exécute plusieurs étapes en autonomie. Il appelle des outils, observe les résultats, décide de la prochaine action. Il maintient un état et écrit pour de vrai dans des systèmes externes. Pipeline contrats, bot de revue de code, certains assistants internes : ce sont de vrais agents.

Les deux différences clés : l’autonomie et l’existence d’une boucle.

La différence vue sur des projets réels

Un cas où le chatbot suffisait

Un client SaaS européen voulait « automatiser le support avec un agent IA ». J’ai sorti 3 mois de tickets et lu : 80 % relevaient de FAQ simples. Conclusion : un seul chatbot RAG, point.

• Entrée : question client
• Traitement : recherche de chunks pertinents dans la doc interne → Claude génère la réponse
• Sortie : réponse + sources

Pas d’outils, pas de boucle. Et pourtant, 45 % des tickets résolus automatiquement, ROI atteint en 3 mois. Ici, le chatbot était la bonne réponse. Pousser un agent aurait fait exploser le coût par deux ou trois.

Un cas où l’agent était indispensable

Un autre client voulait « recevoir un PDF de contrat, extraire les clauses obligatoires et les pousser dans Salesforce ». Là, plusieurs étapes clairement distinctes :

1. Extraction du texte depuis le PDF
2. Classification des clauses (paiement, résiliation, responsabilité, etc.)
3. Ajout de métadonnées sur chaque clause
4. Vérification de cohérence avec les contrats existants
5. Appel API Salesforce pour créer l’enregistrement
6. Escalade humaine en cas d’échec

Faire ça avec un chatbot, le code devient un patchwork. Le LLM doit appeler des outils, observer, brancher. Implémenté avec Claude Agent SDK, le système traite aujourd’hui plusieurs centaines de contrats par jour.

La différence vue côté implémentation

En code, la différence saute aux yeux.

Chatbot : fonction linéaire

async function handleMessage(query: string, userId: string) {
  const chunks = await retrieve(query, userId);
  const answer = await claude.messages.create({
    model: "claude-sonnet-4-5",
    max_tokens: 1024,
    messages: [
      { role: "user", content: buildPrompt(query, chunks) },
    ],
  });
  return answer;
}

Un appel LLM, une requête DB. Fini. Le debug est trivial.

Agent : boucle + outils + état

async function runAgent(goal: string, userId: string) {
  const state = { messages: [{ role: "user", content: goal }], done: false };

  while (!state.done && state.messages.length < MAX_STEPS) {
    const response = await claude.messages.create({
      model: "claude-sonnet-4-5",
      max_tokens: 2048,
      tools: AVAILABLE_TOOLS,
      messages: state.messages,
    });

    state.messages.push({ role: "assistant", content: response.content });

    if (response.stop_reason === "tool_use") {
      const toolResults = await executeTools(response.content, userId);
      state.messages.push({ role: "user", content: toolResults });
    } else {
      state.done = true;
    }
  }

  return state;
}

Boucle, exécution d’outils, nombre d’étapes max, gestion d’échec, logs d’audit. La complexité prend un ordre de grandeur. Le coût opérationnel suit.

Quand éviter l’agent

Trois pièges fréquents.

Quand un arbre de décision suffit. L’agent coûte 5 à 10 fois plus cher et reste imprévisible. Un système à règles ou un simple chatbot fait mieux le job.

Quand un seul appel suffit. Pour « résume-moi ce document », l’agent est un luxe inutile. Un appel LLM direct suffit.

Pour les transactions temps réel à fort coût d’échec. Paiement, action à valeur juridique : ce n’est pas un agent autonome qu’il faut, c’est un workflow où un humain valide en dernier. Pas de compromis là-dessus.

Quand l’agent vaut son prix

À l’inverse, quand ces conditions sont réunies, l’agent gagne clairement :

• La tâche se décompose en plusieurs étapes, et celles-ci varient selon l’entrée.
• Il faut orchestrer plusieurs systèmes externes.
• Tu peux te permettre que l’exécution prenne plusieurs minutes.
• L’échec est rattrapable : retry, ou passage à un humain.

Traitement de contrats, tâches de recherche, automatisation de revue de code, migrations de données complexes : c’est ce profil.

Conseil pratique

Tranche tôt. Étendre un chatbot en agent, c’est facile. Réécrire un agent mal conçu en chatbot, c’est une refonte complète.

Et même quand tu fais un agent, ne mets pas tout dans le LLM. Un bon système d’agent sépare clairement le code déterministe (les flux qu’on maîtrise) et les appels LLM (les points qui demandent du jugement). À chaque étape, je me demande : « Un if/else suffit ? » Si la réponse est oui, c’est un if/else. C’est la clé d’un agent qu’on peut faire tourner en prod.

Si tu hésites à passer à l’agent, je propose 30 minutes de consult gratuite pour regarder ton use case ensemble.