Un agent IA n'est pas un chatbot avec des outils, ni un workflow déguisé. Voici la définition claire et la distinction qui change vos choix techniques.
Un agent IA est un système qui décide lui-même des étapes à suivre pour atteindre un objectif, en choisissant ses outils au fur et à mesure, contrairement à un workflow automatisé où chaque étape est fixée à l'avance par un humain. La distinction paraît évidente sur le papier. Elle explique pourtant la moitié des malentendus qu'on croise depuis deux ans autour de ce mot.
Le terme "agent IA" est aujourd'hui collé sur à peu près tout : un chatbot avec quelques function calls, un pipeline n8n avec un appel LLM au milieu, une vraie boucle décisionnelle autonome. Ce flou n'est pas anodin. Il pousse des équipes à construire (ou acheter) le mauvais outil pour le mauvais problème. Cet article prend position sur où tracer la ligne, avec un exemple concret et les erreurs qu'on voit revenir en production.
Le problème : personne n'a la même définition
Il n'existe pas de définition unique et consensuelle du mot "agent" dans l'industrie. Une étude menée par Simon Willison, développeur reconnu dans la communauté tech, a recensé auprès de praticiens de l'IA une multitude de définitions différentes et parfois contradictoires du terme, certains l'utilisent pour désigner n'importe quel système qui appelle un outil, d'autres réservent le mot aux systèmes capables de planifier plusieurs étapes sans supervision humaine.
Résultat : deux entreprises peuvent vendre exactement le même produit. L'une l'appelle "assistant automatisé". L'autre l'appelle "agent IA autonome nouvelle génération". Le prix change du simple au triple.
Cette absence de standard n'est pas qu'un problème marketing. Elle a des conséquences techniques réelles quand vient le moment de choisir une architecture.
Agent vs workflow : la distinction qui compte vraiment
Voici la ligne de démarcation la plus utile en pratique : dans un workflow, le chemin d'exécution est écrit à l'avance par un développeur, des conditions, des branches, un ordre fixe. Le LLM, s'il intervient, ne fait qu'exécuter une tâche ponctuelle dans une étape prédéfinie.
Dans un agent, c'est le modèle lui-même qui décide de la prochaine action : quel outil appeler, dans quel ordre, quand s'arrêter. La boucle est ouverte. Personne n'a écrit à l'avance la séquence exacte des étapes.
Cette différence change tout en termes de prévisibilité, de coût et de debug.
| Critère | Workflow automatisé | Agent IA |
|---|---|---|
| Séquence des étapes | Fixée par un humain | Décidée par le modèle en temps réel |
| Prévisibilité | Élevée, comportement déterministe | Variable, dépend du raisonnement du modèle |
| Coût en tokens | Prévisible, borné | Peut exploser (boucles, retries) |
| Debug en cas d'erreur | Simple, on rejoue l'étape qui a échoué | Complexe, il faut reconstituer le raisonnement |
| Cas d'usage typique | Facturation, extraction de données, notifications | Recherche multi-étapes, résolution de bugs, support avec contexte variable |
On avait détaillé la mécanique de connexion entre un agent et ses outils dans l'article sur comment créer un serveur MCP pour Claude. Le protocole MCP standardise justement la façon dont un agent découvre et appelle des outils externes, mais il ne rend pas un système "agent" en soi. On peut très bien câbler MCP sur un simple workflow.
Un exemple concret : le SOC agentique
Un cas bien documenté illustre la différence : les centres d'opérations de sécurité (SOC) agentiques décrits par Harvey. Le système y opère à travers un cycle continu, recherche de menaces, ingénierie de détection, ajustement des alertes, où chaque étape informe la suivante de façon autonome, sans script préétabli pour chaque scénario d'attaque.
C'est un vrai agent, pas un workflow déguisé. Le modèle ajuste sa stratégie de détection en fonction de ce qu'il découvre à l'étape précédente. Un script classique aurait dû anticiper chaque cas de figure à l'avance.
Mais voilà la limite honnête : cette autonomie a un prix. Plus la boucle est longue, plus la facture en tokens grimpe et plus le risque de dérive augmente. On l'avait chiffré dans l'article sur le prix réel de l'API Claude, un agent qui boucle 15 fois sur un problème peut coûter dix fois plus cher qu'un workflow qui traite le même cas en trois appels fixes.
Anthropic elle-même pousse une vision où le travail ressemble de plus en plus à une collaboration "multi-joueurs" entre humains et systèmes autonomes plutôt qu'à une simple automatisation de tâches répétitives. Mais cette vision suppose des cas d'usage où l'imprévisibilité du raisonnement apporte une vraie valeur, pas n'importe quel formulaire à remplir.
Pourquoi cette confusion coûte cher en production
On voit trois erreurs revenir régulièrement chez des équipes qui se lancent.
La première : construire une boucle agentique complète pour un besoin qui aurait suffi avec un pipeline à trois étapes. Le résultat est plus lent, plus cher, et plus difficile à débugger, pour un gain de flexibilité que personne n'utilise vraiment.
La deuxième erreur est inverse. Certaines équipes appellent leur produit "agent" par pur argument marketing, alors qu'il s'agit d'un chatbot avec du function calling basique. Le client s'attend à une autonomie qu'il n'obtient jamais.
La troisième, plus insidieuse : sous-estimer le coût de supervision d'un vrai agent en prod. Sans observabilité fine sur chaque décision prise par le modèle, une dérive de comportement peut passer inaperçue pendant des semaines. On en parlait déjà en creusant les options gratuites et open source pour monter un agent IA sans exploser son budget : la gratuité du modèle ne dit rien du coût de la supervision.
Si votre équipe compte moins de cinq développeurs et que le cas d'usage est répétitif, un workflow bien structuré fera souvent le travail mieux qu'un agent mal supervisé.
Conclusion
Trois points à retenir. Un agent décide de sa séquence d'actions en temps réel, un workflow l'exécute selon un plan fixé à l'avance, la différence n'est pas cosmétique, elle change le coût et la prévisibilité du système. Le mot "agent" n'a pas de définition consensuelle dans l'industrie, ce qui en fait un argument marketing autant qu'un terme technique. Et l'autonomie a un prix réel en tokens et en effort de supervision, qui rend le workflow préférable dans une majorité de cas concrets.
Avant de vous lancer dans la construction d'un agent IA, posez-vous une question simple : est-ce que votre problème a vraiment besoin d'un modèle qui improvise, ou juste d'un enchaînement fiable d'étapes ? Si vous voulez qu'on regarde ça ensemble sur votre cas précis, l'équipe fstck.co est joignable pour en discuter.
Questions fréquentes
Comment savoir si mon projet a besoin d'un agent IA ou juste d'un workflow automatisé ?
Posez-vous la question de la variabilité : si les étapes et leur ordre sont toujours les mêmes, un workflow suffit. Si le nombre d'étapes et leur nature varient selon le contexte de chaque requête, un agent devient pertinent.
Quelle est la différence entre un agent IA et un chatbot avec function calling ?
Un chatbot avec function calling exécute un outil ponctuel sur demande explicite, dans une conversation guidée par l'utilisateur. Un agent enchaîne plusieurs appels d'outils de façon autonome, sans validation humaine à chaque étape, jusqu'à atteindre l'objectif fixé.
Le protocole MCP d'Anthropic est-il nécessaire pour construire un agent IA ?
Non. MCP standardise la connexion entre un modèle et des outils externes, ce qui simplifie l'intégration, mais un agent peut fonctionner avec des appels d'API classiques. MCP facilite la maintenance, il ne définit pas ce qu'est un agent.
Un agent IA peut-il fonctionner sans mémoire persistante ?
Oui, pour des tâches courtes limitées à une session. Mais dès que l'agent doit se souvenir d'un contexte entre plusieurs interactions séparées dans le temps, une mémoire persistante, base vectorielle ou stockage structuré, devient nécessaire pour éviter de tout réexpliquer à chaque appel.
Pourquoi un agent IA coûte-t-il plus cher qu'un workflow classique ?
Parce que la boucle de décision consomme des tokens à chaque itération de raisonnement, y compris quand le modèle se trompe et doit recommencer. Un workflow fixe appelle le modèle un nombre de fois connu à l'avance, ce qui rend son coût prévisible et généralement plus bas.
