Les agents

Une équipe support demande « un agent » pour traiter les demandes de remboursement. Le processus tient en quatre étapes : lire la demande, retrouver la commande, rembourser si le montant est inférieur à 50 euros, sinon transmettre le dossier à un conseiller. Ces étapes ne changent jamais d'ordre. Ce n'est pas un agent qu'il faut à cette équipe : c'est un enchaînement fixe, avec un LLM (grand modèle de langage) pour lire la demande.

Enchaînement fixe ou agent

Dans un enchaînement fixe (workflow), le code définit d'avance l'ordre des étapes. Un LLM peut se charger de l'une d'elles, comme lire une demande ou rédiger une réponse, mais il ne choisit pas la suite. Dans un agent, c'est le modèle qui décide : quelle étape vient ensuite, quel outil appeler, quand s'arrêter. Un guide publié par Anthropic en décembre 2024 fait cette distinction. Il conseille de chercher la solution la plus simple et de n'ajouter de la complexité que si elle est nécessaire.

Les deux approches ne se comparent pas sur l'intelligence, mais sur trois points :

• la prévisibilité : un enchaînement fixe suit toujours le même chemin, alors qu'un agent peut en prendre un différent à chaque requête ;
• le coût : un agent envoie plusieurs requêtes au modèle pour une seule tâche, et leur nombre varie. Selon le même guide d'Anthropic, un agent accepte souvent plus de coût et un temps de réponse plus long en échange de meilleurs résultats ;
• le débogage : quand un enchaînement fixe se trompe, vous savez à quelle étape. Quand un agent se trompe, il faut relire tout son parcours pour comprendre où il a dévié.

Un agent se justifie quand les étapes ne se connaissent pas d'avance. Chercher pourquoi une facture client est fausse peut demander de consulter le contrat, puis l'historique des commandes, puis un ancien ticket, dans un ordre qui dépend de ce que l'on trouve. Personne ne peut écrire cet ordre à l'avance.

La boucle : planifier, agir, observer

Un agent tourne en boucle. Il planifie : à partir du but et de ce qu'il sait déjà, le modèle choisit la prochaine action. Il agit : il demande à appeler un outil. Il observe : il lit le résultat, puis repart au début de la boucle. Le guide d'Anthropic souligne ce dernier point : à chaque étape, l'agent doit vérifier où il en est à partir de résultats réels, pas de ce qu'il suppose.

Un outil est une fonction que l'application met à la disposition du modèle : chercher une commande, lire un document, créer un ticket, envoyer un e-mail. Chaque outil est décrit par un schéma, comme une sortie structurée. En octobre 2026, la documentation d'Anthropic le précise : le modèle n'exécute jamais rien lui-même. Il produit une demande d'appel. L'application exécute l'outil, ou l'éditeur pour certains outils intégrés, puis renvoie le résultat au modèle. Ce n'est donc pas le modèle qui décide de ce qu'il a le droit de faire, c'est l'application.

Pour brancher un agent sur les outils d'une entreprise, il existe un protocole commun : MCP (Model Context Protocol). En octobre 2026, son site le présente comme un standard open source pour connecter les applications d'IA à des systèmes externes. Le protocole facilite le branchement. Il ne fixe pas ce que l'agent a le droit de faire une fois branché.

Savoir s'arrêter

Un agent décide lui-même quand il a fini. Rien ne garantit qu'il le décide : c'est à vous de lui imposer des limites. Le guide d'Anthropic cite des conditions d'arrêt courantes, comme un nombre maximum de passages dans la boucle. En octobre 2026, le kit de développement d'agents d'OpenAI applique la même idée : au-delà du nombre maximum de passages fixé par le développeur, il arrête l'exécution et signale une erreur.

Un agent qui s'arrête sur un simple message, sans appel d'outil, n'a pas forcément fini. En octobre 2026, le guide d'Anthropic pour Claude Opus 5.5 demande de traiter ce message comme un compte rendu, pas comme la preuve que la tâche est faite. Énoncez dès le départ ce qui compte comme fini. Gardez l'état de la tâche hors de la conversation, dans une liste de contrôle ou un fichier de suivi que l'agent met à jour. S'il reste des points ouverts, relancez l'agent en les nommant, mais deux ou trois fois au plus : un agent vraiment bloqué doit s'arrêter pour qu'on examine ce qui coince. Pour un gros travail, répartissez-le entre plusieurs sous-agents, des agents que le premier lance chacun sur une partie de la tâche. Vérifiez alors les preuves de chacun (un résultat de test, un fichier, une source), pas seulement son récit. Selon Anthropic, un sous-agent vérificateur qui repart d'un contexte neuf vérifie mieux qu'un agent qui relit son propre travail.

Fixez aussi un budget. Chaque passage dans la boucle est une nouvelle requête qui renvoie au modèle tout l'historique de la tâche : les instructions, les définitions des outils et chaque résultat déjà obtenu. Chaque passage coûte donc plus cher que le précédent. Le cache de prompt réduit l'écart, sans le supprimer. La page Les tokens et le coût explique ce que coûte une requête. Un budget par tâche, en requêtes ou en euros, transforme une boucle sans fin en incident visible.

Enfin, prévoyez des points de contrôle humain. Avant une action irréversible, comme rembourser, écrire à un client ou supprimer une donnée, l'agent s'arrête et attend une validation. Le guide d'Anthropic mentionne ces pauses, et le kit d'OpenAI suspend l'exécution tant qu'un outil soumis à approbation n'a pas été approuvé.

Comment un agent échoue

Trois défauts reviennent souvent.

• Le surplace : l'agent tourne en rond et répète la même action sans avancer, par exemple la même recherche avec des mots à peine différents. Sans limite, il consomme du budget jusqu'à ce que quelqu'un s'en aperçoive.
• La dérive : une petite erreur au début oriente toutes les étapes suivantes. Le guide d'Anthropic parle d'erreurs qui se cumulent. L'agent finit par résoudre un autre problème que celui posé.
• L'excès de zèle : l'agent fait plus que ce qu'on lui demande. Chargé de préparer une réponse, il l'envoie. Chargé de corriger une fiche, il en corrige dix.

Ces défauts ne se voient pas dans la seule réponse finale. Une bonne réponse peut cacher un parcours de quarante appels d'outils, dont un a modifié une donnée qu'il ne devait pas toucher. Les évals (pour « évaluations ») d'un agent vérifient donc aussi son parcours : les outils appelés, leur nombre et les actions bloquées.

Faire cohabiter le déterministe et le probabiliste

Un enchaînement fixe est déterministe : la même entrée suit toujours le même chemin et donne le même résultat. Un LLM est probabiliste : il construit sa réponse par une suite de tirages au sort, comme l'explique la page sur le grand modèle de langage. La même demande peut donc recevoir deux réponses différentes. Un produit sérieux combine souvent les deux. La question n'est pas de choisir l'un ou l'autre, mais de décider où passe la frontière.

Trois formes

• Un enchaînement fixe avec un LLM sur une étape. Une entreprise trie les e-mails qu'elle reçoit. Le code reçoit l'e-mail, le LLM lui attribue une catégorie prise dans une liste fermée de valeurs (facture, réclamation, autre), puis le code l'aiguille vers la bonne équipe. Le modèle lit, mais ne décide pas de la suite.
• Un agent. C'est l'enquête sur la facture fausse, vue plus haut : l'agent choisit lui-même où chercher ensuite, selon ce qu'il vient de trouver.
• Un agent dans une étape d'un enchaînement fixe. Reprenons les remboursements. Pour les cas simples, l'enchaînement fixe suffit. Pour les cas douteux, une étape confie l'enquête à un agent : il consulte la commande, le suivi du transporteur et les échanges passés, puis propose une décision. L'enchaînement reprend ensuite la main. C'est lui qui vérifie la proposition, demande une validation humaine si besoin et déclenche le remboursement.

Dans la troisième forme, l'agent propose et l'enchaînement fixe dispose. Rien n'oblige à choisir une forme unique : le guide d'Anthropic présente ses architectures types comme des briques que les développeurs peuvent adapter et combiner.

La frontière entre les deux

Cinq éléments encadrent le moment où l'agent rend la main à l'enchaînement fixe.

• Une sortie structurée. L'agent ne rend pas un texte libre, mais une réponse au format fixé d'avance : une décision prise dans une liste fermée (rembourser, refuser, transmettre), un montant et un motif.
• Une validation dans le code. Le schéma garantit la forme, pas la justesse. Le code vérifie les règles métier : la commande existe, le montant ne dépasse pas celui de la commande, le seuil de 50 euros est respecté.
• Un comportement de repli. Quand la validation échoue, l'enchaînement fixe sait quoi faire : relancer l'appel une fois, puis transmettre le dossier à un conseiller. Un échec ne doit jamais bloquer la file d'attente ni passer inaperçu.
• Un point de contrôle humain. Avant une action irréversible, une personne valide la proposition de l'agent. Vous pouvez réserver cette validation aux montants qui dépassent un seuil.
• Des outils réduits au nécessaire. L'agent qui enquête reçoit des outils de lecture, rien d'autre. L'action qui modifie quelque chose reste dans l'enchaînement fixe. C'est le principe du moindre privilège, détaillé dans la page Outils et MCP : brancher un modèle sur vos systèmes.

Bonnes pratiques

• Choisir la forme étape par étape, pas pour tout le produit. Un même produit peut avoir dix étapes fixes et une seule étape confiée à un agent. Pour chaque étape, demandez-vous si vous savez décrire d'avance ce qu'elle doit faire.
• Rendre idempotente chaque étape qui agit. Une étape idempotente produit le même effet qu'on l'exécute une fois ou deux. En octobre 2026, la documentation de Stripe, un service de paiement en ligne, décrit ce mécanisme : une clé d'idempotence jointe à la requête permet de la relancer sans risquer de créer un second objet, par exemple un second remboursement.
• Garder une trace de chaque étape. Notez ce que chaque étape a reçu, ce qu'elle a rendu et le chemin choisi. Sans cette trace, vous ne saurez pas si une erreur vient du code ou du modèle.
• Limiter la partie agent. Le nombre maximum de passages, le budget et les conditions d'arrêt s'appliquent à l'étape confiée à l'agent. Le coût de l'enchaînement fixe se prévoit ; celui de l'agent, non.
• Tester séparément. L'enchaînement fixe se teste comme du code classique : la même entrée donne le même résultat. La partie agent se teste par des évals sur de nombreux cas réels, et se juge sur un taux de réussite, pas sur un simple oui ou non.

Points de vigilance

• Le non-déterminisme caché. Dès qu'un LLM choisit une branche, l'enchaînement fixe ne l'est plus tout à fait : le même e-mail peut partir vers une équipe un jour, vers une autre le lendemain. En octobre 2026, le glossaire d'Anthropic le rappelle : des entrées identiques peuvent produire des sorties différentes. Prévoyez une valeur « inconnu », aiguillée vers une personne, et testez chaque cas plusieurs fois.
• Les relances qui répètent une action. Une étape dépasse son délai et l'enchaînement la relance. Or le remboursement était déjà parti : le client est remboursé deux fois, ou reçoit deux e-mails. L'idempotence protège de ce double effet.
• Une sortie d'agent utilisée sans validation. Un numéro de commande inventé, au bon format, passe le schéma et file jusqu'à la comptabilité. Chaque sortie de l'agent est une proposition à vérifier, pas une donnée sûre.
• Le mot « agent » pour un enchaînement fixe. Un produit présenté comme un agent est parfois un enchaînement fixe avec une étape LLM. Ce n'est pas un défaut : c'est souvent le bon choix. Demandez quelles étapes le modèle choisit lui-même : la réponse dit ce que vous devez tester.

Ce que ça change pour vous

L'erreur classique

Autour du sujet