Agent ou simple appel : la question qu'on ne pose pas

Un simple appel de modèle exécute une tâche définie en une requête, avec un contexte construit et un format de sortie strict, alors qu’un agent IA boucle, décide lui-même de ses étapes et appelle des outils. Entre les deux se trouve l’enchaînement déterministe : plusieurs appels dans un ordre fixé par le code.

Depuis deux ans, presque toutes les demandes qui m’arrivent sont formulées comme des projets d’agent. Dans la majorité des cas, le besoin décrit se résout par un appel unique, avec un contexte bien construit et un format de sortie strict.

La différence n’est pas cosmétique. Un agent boucle, décide de ses propres étapes, appelle des outils. Il est donc plus lent, plus coûteux, moins prévisible et beaucoup plus difficile à superviser.

Un agent coûte plus cher qu’un enchaînement d’appels parce qu’il consomme un nombre d’appels très variable selon les cas, ce qui rend la moyenne inutilisable comme prédicteur budgétaire. Sur les projets que j’ai suivis, l’écart entre le coût mesuré en pilote et le coût constaté en production a souvent atteint un facteur trois à cinq ; c’est un constat de terrain, pas une loi.

La raison tient aux cas difficiles : ceux qui font tenter plusieurs approches, boucler, consommer bien au-delà de la moyenne. Ils sont absents d’un échantillon choisi.

Deux réglages s’imposent dès le prototype : un plafond de dépense appliqué par le système, et une surveillance au quantile élevé. La méthode figure dans mesurer le coût par fonctionnalité.

Un enchaînement, lui, fait un nombre d’appels fixe par demande. Son coût se calcule avant la mise en service, ce qui simplifie le budget autant que la discussion avec la direction financière.

Quand on construit un agent là où un enchaînement suffit, on obtient un système plus lent, plus cher et moins prévisible, qui exécute en réalité toujours la même séquence. Le cas que j’ai traité le plus souvent ressemble à celui-ci.

Il s’agissait d’un « agent de traitement de commandes » qui, dans les faits, exécutait toujours la même séquence : lire le message, extraire les références, vérifier le stock, rédiger la réponse.

Écrit comme un agent, il coûtait dans ce cas cinq fois plus cher, mettait quinze secondes au lieu de trois, et produisait de temps en temps une étape en plus dont personne ne comprenait la raison. Réécrit comme un enchaînement déterministe avec un appel de modèle à chaque étape, il est devenu ennuyeux et fiable.

Ennuyeux et fiable est le bon résultat.

Un agent IA est justifié pour les tâches où l’espace de recherche est large et le critère de succès vérifiable ; les autres gagnent à être écrites comme des enchaînements. Ce critère suffit à trancher.

Trois familles fonctionnent : la recherche documentaire exhaustive où le résultat se vérifie par les citations, le traitement d’un lot d’éléments indépendants vérifiables séparément, et la production d’un livrable testable automatiquement.

Ce qui les rend viables est la vérifiabilité, pas la difficulté. Un agent qui travaille longtemps sur une tâche dont personne ne peut vérifier le résultat produit un objet inutilisable. C’est le mécanisme décrit dans le risque croît avec la durée sans contrôle.

Prenons une direction juridique qui veut repérer, dans plusieurs centaines de contrats, les clauses de résiliation non conformes à une nouvelle politique. Le nombre de documents à ouvrir et l’ordre de lecture varient d’un contrat à l’autre, et chaque conclusion se vérifie par la clause citée : c’est un vrai cas d’agent. Le même service qui veut résumer chaque contrat entrant selon un modèle fixe n’a besoin que d’un appel.

Pour réécrire un projet d’agent en enchaînement d’appels, on décrit le parcours réel sur des cas concrets, on fige les étapes qui se répètent dans le code, et on ne laisse au modèle que les décisions locales. La méthode tient en six étapes.

1. Dérouler à la main une vingtaine de demandes réelles et noter les étapes effectivement suivies.
2. Si le parcours est le même pour toutes, l’écrire en code : chaque étape devient une fonction, avec un appel de modèle là où il faut comprendre ou rédiger.
3. Imposer à chaque appel un format de sortie strict, ce que permettent les sorties structurées.
4. Écrire des instructions stables par étape plutôt qu’un prompt unique qui couvre tout, selon les principes d’un prompt système qui tient six mois.
5. Tester chaque étape séparément sur un jeu de cas connus, construit comme dans construire un jeu de tests en une journée.
6. N’introduire une boucle bornée qu’aux endroits où le chemin varie réellement, avec nombre d’étapes, budget et actions limités.

L’enchaînement obtenu se journalise naturellement étape par étape, ce qui facilite l’observabilité et le diagnostic.

En cadrage, on commence par l’enchaînement d’appels le plus simple qui puisse fonctionner, et on ne passe à un agent que sur constat d’échec documenté. Cette règle inverse le réflexe habituel et elle donne de meilleurs systèmes.

Le réflexe habituel part de l’agent parce que c’est le format dont on parle, puis simplifie éventuellement. Il produit des systèmes surdimensionnés dont personne ne sait dire quelle part de la complexité était nécessaire.

Partir du simple a trois avantages. Le système fonctionne plus vite, donc il est mis entre les mains d’utilisateurs plus tôt. Son coût est prévisible dès le départ. Et le constat d’échec, quand il survient, désigne précisément ce qui manque, ce qui donne la spécification de l’agent à construire. S’il bute sur des cas où le chemin doit varier, on introduit une boucle bornée : nombre d’étapes maximal, budget maximal, périmètre d’actions fermé.

Cette progression évite aussi l’erreur inverse, plus rare mais réelle : forcer un enchaînement rigide sur un problème qui demande de l’exploration. Le périmètre reste la question centrale, développée dans le périmètre avant l’autonomie.

Dans la majorité des cas que j’ai traités, ce constat d’échec n’est jamais venu : l’enchaînement simple suffisait, et il tourne encore. C’est cohérent avec les traits communs des systèmes qui aboutissent, décrits dans sortir du prototype, les cinq verrous. Pour un projet déjà lancé sous l’étiquette d’agent, un audit IA permet de vérifier si la boucle apporte réellement quelque chose.

Trois ans de projets confirment que les systèmes qui atteignent la production sont ceux dont le périmètre est le plus étroit, et que beaucoup auraient pu être de simples enchaînements d’appels. Le mot « agent » a coûté cher.

Un enchaînement d’appels déterministe se teste intégralement, se diagnostique pas à pas, et son coût est prévisible. Un agent qui décide de son propre parcours ne présente aucune de ces trois propriétés.

La question à poser reste la même : le parcours est-il connu à l’avance ? S’il l’est, l’écrire coûte moins cher et donne un système meilleur. Le constat détaillé figure dans agents en entreprise : où s’arrêtent les projets.