Le mot « agent » est devenu un fourre-tout. On l’emploie pour un chatbot, pour un script qui appelle une API, pour un assistant autonome qui passe des commandes. Avant de construire quoi que ce soit, il faut poser une définition nette — parce que de cette définition découle toute l’architecture, et surtout la décision la plus importante : faut-il vraiment un agent ?
Un LLM n’est pas une architecture
Un grand modèle de langage est une fonction : du texte entre, du texte sort. Il est sans état, sans mémoire, sans capacité d’action. Posez-lui deux fois la même question, il ne se souviendra pas de la première fois. Demandez-lui le solde d’un compte, il inventera un nombre plausible.
Une architecture agentique, c’est tout ce qu’on construit autour de ce modèle pour le rendre utile : la mémoire, les outils, la boucle de décision, l’orchestration. Le modèle est le moteur ; l’architecture est la voiture.
Le spectre : du workflow figé à l’agent autonome
Entre l’appel LLM unique et l’agent pleinement autonome, il existe un continuum. Le situer correctement est la moitié du travail de conception.
| Niveau | Qui décide du chemin ? | Exemple |
|---|---|---|
| Appel simple | Personne, un seul pas | Résumer un texte |
| Chaîne (chain) | Le développeur, à l’avance | Traduire puis résumer |
| Workflow | Le développeur, avec des branches | Router un e-mail selon son type |
| Agent | Le modèle, à l’exécution | Décider quels outils appeler, et combien de fois |
La frontière décisive passe entre workflow et agent. Dans un workflow, vous écrivez les chemins possibles ; le LLM ne fait que remplir des cases. Dans un agent, le modèle choisit le chemin à l’exécution — il décide d’appeler un outil, d’en rappeler un autre, de boucler ou de s’arrêter.
Les quatre briques d’un agent
Quel que soit le framework, un agent se décompose toujours en quatre briques. Tout le reste de ce parcours consiste à les construire une à une.
- Le modèle — le cœur qui raisonne et décide. On le choisit, on le configure, on le prompt.
- Les outils — les fonctions que l’agent peut invoquer pour percevoir et agir sur le monde (chercher, calculer, écrire en base, appeler une API).
- La boucle — le mécanisme qui exécute les décisions du modèle et lui renvoie les résultats, jusqu’à ce que la tâche soit résolue. C’est elle qui rend le système « agentique ».
- La mémoire — ce qui permet à l’agent de se souvenir, au sein d’une conversation (court-terme) et au-delà (long-terme).
La question qu’on oublie : faut-il un agent ?
C’est la décision la plus importante, et la plus négligée. L’autonomie a un coût : elle rend le système moins prévisible, plus cher (plusieurs appels LLM par requête) et plus difficile à déboguer. On ne la paie que si on en a besoin.
Une règle simple, défendue aussi bien par Anthropic que par les équipes qui opèrent des agents en production :
Cherchez la solution la plus simple possible, et n’augmentez l’autonomie que lorsque les approches plus déterministes ne suffisent plus.
Un test de décision rapide, à passer avant de coder :
| Question | Si « oui » → | Si « non » → |
|---|---|---|
| Le nombre d’étapes est-il inconnu d’avance ? | piste agent | workflow suffit |
| Le chemin dépend-il de résultats intermédiaires ? | piste agent | chaîne suffit |
| La variété des cas interdit-elle de tout câbler ? | piste agent | code classique |
| Une erreur coûte-t-elle cher (argent, données) ? | + human-in-the-loop | autonomie OK |
Un agent se justifie quand le nombre d’étapes est inconnu à l’avance, le chemin dépend de résultats intermédiaires, et la tâche est trop variée pour être câblée en dur. Pensez « assistant de recherche » ou « résolution de tickets », pas « traduire ce paragraphe ».
Le coût caché de l’autonomie
Donner la main au modèle, c’est accepter trois contreparties qu’il faut budgéter dès la conception :
- Le coût — un agent fait plusieurs appels LLM par requête (un par tour de boucle). Une tâche qui boucle cinq fois coûte cinq fois un appel.
- La latence — chaque tour ajoute un aller-retour réseau vers le modèle. Un agent est intrinsèquement plus lent qu’une chaîne.
- L’imprévisibilité — puisque le chemin n’est pas fixé, deux exécutions de la même requête peuvent différer. D’où l’importance capitale de l’observabilité, qu’on abordera en fin de parcours.
Ces coûts ne sont pas une raison d’éviter les agents — ce sont les paramètres à surveiller pour qu’un agent reste viable en production.
Pourquoi LangGraph et LangFuse
Construire les quatre briques à la main est instructif (on le fera en partie), mais fastidieux et fragile à l’échelle. Ce site fait un choix assumé de deux outils complémentaires :
- LangGraph structure la boucle et la mémoire : il modélise l’agent comme un graphe d’état explicite — lisible, persistable, interruptible.
- LangFuse apporte l’observabilité : il rend visible chaque décision de l’agent, son coût et sa qualité. Sans elle, un agent en production est une boîte noire qu’on ne peut ni déboguer ni améliorer.
Orchestration d’un côté, observabilité de l’autre : ces deux outils couvrent l’essentiel du cycle de vie d’un agent.
Ce qu’il faut retenir
- Un LLM est une fonction sans état ; l’architecture est tout ce qu’on bâtit autour pour le rendre utile.
- Un système est agentique quand le modèle contrôle le flux à l’exécution — sinon, c’est un workflow.
- Tout agent se ramène à quatre briques : modèle, outils, boucle, mémoire.
- La meilleure architecture est souvent la moins autonome qui résout le problème. Ne payez l’autonomie que si vous en avez besoin.
Maintenant que le vocabulaire est posé, passons au modèle mental concret qui sous-tend tout LangGraph : penser son application comme un graphe d’état.