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

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.

Le cas typique : 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 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.

On commence toujours par l'enchaînement déterministe. S'il couvre le besoin, on s'arrête là. 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 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.

Les systèmes qui atteignent la production sont ceux dont le périmètre est le plus étroit, et 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.

Un agent consomme un nombre d'appels très variable selon les cas, ce qui rend la moyenne inutilisable comme prédicteur budgétaire. L'écart entre pilote et production est régulièrement d'un facteur trois à cinq.

La raison tient aux cas difficiles : ceux qui font tenter plusieurs approches, boucler, consommer dix fois 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é.

Les tâches où l'espace de recherche est large et le critère de succès vérifiable justifient un agent ; les autres gagnent à être écrites. 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, le mécanisme décrit dans le risque croît avec la durée sans contrôle.

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.

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.