Chaque feuille de route produit comporte une puce indiquant « Agent IA ». Le mot évoque le progrès. Il signale à la direction que votre équipe construit l'avenir, et pas seulement qu'elle maintient le présent. Mais voici la vérité dérangeante que la plupart des vidéos de démonstration ne vous montreront pas : un agent est le moyen le plus coûteux et le moins prévisible de terminer une tâche. Pour la majorité des tâches professionnelles, c'est tout simplement le mauvais outil. Les meilleurs ingénieurs ne sont pas ceux qui se précipitent pour en construire un. Ce sont ceux qui savent quand s'arrêter.
Le piège de la classification
Observez une équipe définir le périmètre de son premier agent, et vous verrez généralement quelque chose comme ceci. Un e-mail de support arrive. Un grand modèle de langage lit l'objet et le corps, décide s'il s'agit d'une question de facturation ou d'un bug technique, et le place dans la file d'attente appropriée. L'équipe appelle cela un agent. Ce n'en est pas un.
Ce qu'ils ont construit est un flux déterministe comportant un seul appel de modèle à l'intérieur. Les étapes sont fixes : ingérer l'e-mail, appeler le modèle, router vers la file d'attente. Il n'y a pas de boucle, pas d'utilisation d'outils, pas de moment où le système s'arrête pour reconsidérer son plan parce que la première tentative a échoué. Il ne parcourt pas une base de connaissances, n'écrit pas de code et ne vérifie pas le statut d'une commande en cours de route. Il prend une décision unique et passe à la suite. Envelopper cet appel unique dans un microservice n'en fait pas un agent.
Le coût réel de la confusion entre un flux et un agent n'est pas seulement l'infrastructure supplémentaire. C'est le non-déterminisme que vous avez introduit sans aucun gain. Le même e-mail peut être routé différemment le mardi matin par rapport au mercredi après-midi parce que la température n'est pas nulle ou que le prompt dérive. Vous payez le prix d'un agent pour la latence, les coûts de tokens et la charge d'évaluation, alors qu'un flux avec une seule étape de classification résout le problème plus rapidement et à moindre coût.
Travaillez en descendant l'échelle
La plupart des problèmes ont des cousins plus simples qui les résolvent tout aussi bien. Voyez cela comme une échelle, et commencez par le bas.
Corrigez le processus. Parfois, le travail n'existe que parce que deux systèmes sont en désaccord. Un enregistrement client dans votre CRM ne se synchronise pas avec votre plateforme de ticketing, de sorte qu'un humain doit combler manuellement l'écart chaque matin. N'automatisez pas ce pont avec un agent. Éliminez-le. Si le pipeline de données était sain, le travail disparaîtrait.
Utilisez une requête. Si la réponse est une simple recherche ou une agrégation, traitez-la comme telle. « Combien de remboursements avons-nous traités mardi dernier ? » ne nécessite pas de raisonnement. Cela nécessite du SQL. Un agent qui traduit le langage naturel en SQL semble élégant jusqu'à ce que vous réalisiez que la charge de maintenance dépasse l'écriture de trois requêtes documentées que votre équipe exécute depuis un tableau de bord.
Construisez un flux déterministe. Lorsque les règles sont fixes et que le résultat est reproductible, utilisez une logique explicite. Si la valeur d'une commande dépasse un seuil, transférez au service financier. Si un utilisateur est inactif pendant trente jours, envoyez un e-mail de réengagement. Le code gère cela avec une variance nulle et une observabilité totale. Vous pouvez le tester par des tests unitaires. On ne peut pas tester une « vibe » avec des tests unitaires.
Utilisez un flux avec un seul appel de modèle. C'est ici que se situent la classification, le marquage de sentiment ou l'extraction de données. Le modèle prend une décision unique à l'intérieur d'un script rigide. Vous ingérez un document, extrayez le numéro de facture et l'écrivez dans une base de données. Les étapes environnantes sont codées en dur. Le modèle ne choisit pas ce qu'il doit faire ensuite ; il se contente d'étiqueter ce qu'il voit. C'est un modèle puissant, mais cela reste un flux.
Construisez un agent en dernier recours. Réservez cette étape aux tâches où la prochaine action dépend réellement de ce que le modèle découvre en cours d'exécution. Si le système doit lire un e-mail, réaliser qu'il doit rechercher une expédition dans une API logistique, constater que l'expédition est retardée, puis rédiger une réponse personnalisée basée sur ces nouvelles données, vous entrez dans le territoire de l'agent. Le chemin ne peut pas être tracé à l'avance car le modèle décide de ce qu'il doit faire après chaque nouvelle information.
Le test du tableau blanc
Il existe un moyen rapide de trancher le débat lors d'une réunion. Demandez à votre équipe de dessiner les branches de décision sur un tableau blanc.
Si vous pouvez cartographier chaque chemin avant l'exécution du modèle, construisez un flux. Dessinez les losanges, écrivez les instructions if, et c'est terminé. La prévisibilité est une fonctionnalité, pas une limitation.
Si le modèle lui-même doit décider quelle est la prochaine étape, s'il choisit l'outil, définit les paramètres et boucle pour repenser, alors vous avez besoin d'un agent. Ce routage dynamique est la ligne de démarcation. Ne la franchissez pas par accident simplement parce que vous vouliez utiliser une nouvelle API.
La taxe cachée
Les démos font paraître les agents sans friction. La production révèle quatre taxes qui s'accumulent rapidement.
Le non-déterminisme. Le même