Quand ne PAS construire un agent IA

Table des matières

Publié en août 2026.

TL;DR : La plupart des idées d’agents IA sont le mauvais outil pour le travail. Avant d’écrire la moindre ligne de code d’agent, je vérifie cinq signaux disqualifiants — un processus instable, une faible fréquence, l’absence de test réussite/échec, un outil plus simple qui fonctionne déjà, ou un mode de défaillance irréversible que je ne peux pas encadrer à temps. Si l’un d’eux est vrai, je ne construis pas. Je descends à la place une échelle d’alternatives moins coûteuses, et je ne reviens à un agent sur mesure que si rien sur cette échelle ne tient la route.

[Point de vue de l’opérateur] Je gère plus de 30 agents en production pour une marque de conseil et Pickleland, une installation de pickleball à Pflugerville, TX. J’ai abandonné au moins autant d’idées d’agents que j’en ai déployé, et presque aucune n’est morte parce que l’idée était mauvaise — elles sont mortes parce qu’un agent était le mauvais outil pour ce travail précis. Cet article est le filtre que j’applique avant que « devrais-je construire ça » ne devienne « comment est-ce que je construis ça ».

La réponse par défaut est non

Le cadre de ROI que j’utilise vous indique si une automatisation rentabilise son coût de construction et de maintenance. C’est la bonne deuxième question. La première est plus simple et elle est constamment sautée : est-ce que ça a vraiment besoin d’être un agent ?

« Agent » est devenu l’étiquette par défaut pour tout ce qui implique un LLM, de la même façon qu’« application » est devenue l’étiquette par défaut pour tout ce qui impliquait un écran il y a quinze ans. Tout ce qui touche à un modèle n’a pas besoin d’un système permanent, autonome, capable d’appeler des outils, qui surveille des déclencheurs et agit tout seul. Ce que les gens appellent « construire un agent » est souvent en réalité « écrire un très bon prompt et l’exécuter à la main » — et ce n’est pas un échec, c’est souvent le bon état final.

Je considère « construire un agent sur mesure » comme l’option la plus coûteuse d’une échelle d’options, pas comme le premier échelon. Avant d’y recourir, je vérifie si la tâche se disqualifie elle-même.

Cinq signaux indiquant qu’un agent est le mauvais outil

N’importe lequel de ces signaux, à lui seul, suffit généralement à m’arrêter.

1. Le processus n’est pas encore stable. Si le flux de travail a changé deux fois au cours du dernier mois parce que l’entreprise elle-même est encore en train de définir ce qu’elle veut, un agent verrouille la version actuelle d’un processus qui est sur le point de changer à nouveau. Vous réécrirez le prompt, le schéma d’outils et l’ensemble d’évaluation à chaque évolution du processus — ce qui signifie que vous maintenez un agent au lieu de faire tourner une entreprise. Exécutez-le manuellement jusqu’à ce qu’il se stabilise pendant un trimestre, puis automatisez la version stabilisée.

2. Il s’exécute trop rarement pour se rentabiliser. Une tâche qui se produit deux fois par an n’accumule pas assez d’exécutions pour justifier le temps de construction, le temps de test et un ensemble d’évaluation, aussi bien performerait-il une fois construit. Faible fréquence et effort de construction élevé forment à peu près le pire quadrant pour l’automatisation — vous payez l’intégralité du coût de construction et vous n’en récupérez presque aucune économie.

3. Vous ne pouvez pas écrire de test réussite/échec pour ça. Si vous ne pouvez pas décrire à l’avance à quoi ressemble un résultat correct, avec assez de précision pour le vérifier de façon programmatique, vous ne pouvez pas construire de harnais d’évaluation pour cette tâche — et un agent que vous ne pouvez pas évaluer est un agent que vous pilotez à l’aveugle. Les tâches qui relèvent du pur goût (« est-ce que ça sonne comme moi ? ») ou du pur jugement sans grille cohérente derrière restent manuelles, ou restent révisées par un humain à chaque fois — ce qui annule l’intérêt de les automatiser.

4. Un outil plus simple fait déjà le travail. Avant de cadrer un agent, demandez-vous ce qu’une formule de tableur, un workflow Zapier/Make/n8n avec une seule étape LLM, ou un prompt enregistré vous permettrait d’obtenir. Si la réponse honnête est « ça couvre déjà 90 % du chemin », les 10 % restants justifient rarement de mettre en place un agent avec sa propre infrastructure, sa surveillance et sa taxe de maintenance. J’ai cadré des agents pour des tâches qu’une vue filtrée et un rappel de calendrier récurrent auraient tout aussi bien résolues.

5. Le mode de défaillance est irréversible et vous n’avez pas le temps de construire correctement la porte de validation. Certaines actions — un envoi d’e-mail de masse, un remboursement, une publication publique — ne peuvent pas être annulées. Les portes de validation humaine existent précisément pour ça, mais une porte bâclée que personne ne relit vraiment est pire que pas d’automatisation du tout : elle crée une apparence de supervision sans la substance. Si vous n’avez pas le temps de construire et de faire fonctionner correctement cette porte, c’est un signal pour ralentir, pas une raison de la sauter.

Si aucun des cinq ne s’applique — le processus est stable, il s’exécute assez souvent, vous pouvez définir ce qu’est un résultat correct, aucun outil plus simple ne couvre le besoin, et le mode de défaillance est soit réversible soit correctement encadré — alors ça vaut la peine de faire tourner le calcul du ROI dessus.

L’échelle que je gravis avant de construire

Quand une tâche échoue à l’une des cinq vérifications — ou avant même d’en arriver là — je descends cette liste dans l’ordre, et je m’arrête au premier échelon qui résout vraiment le problème.

1. Demandez directement au modèle. Pas de surcouche, pas d’appels d’outils, pas d’infrastructure permanente. Ouvrez Claude, collez le contexte, posez la question, utilisez la réponse. Ça règle plus de tâches ponctuelles et occasionnelles qu’on ne le pense, parce que le réflexe « agent » se déclenche même pour des choses qui n’arrivent qu’une seule fois.

2. Un prompt enregistré ou des instructions de projet. Si le même type de demande revient régulièrement mais que chaque instance a encore besoin d’un humain pour rassembler les données d’entrée et relire le résultat, enregistrez le prompt comme modèle — instructions de projet, jeu d’instructions personnalisé, snippet — plutôt que d’automatiser le déclencheur. Vous obtenez le bénéfice de cohérence d’un agent sans l’infrastructure.

3. Un outil d’automatisation no-code avec une seule étape LLM. Pour les tâches qui ont vraiment besoin d’un déclencheur (une nouvelle soumission de formulaire, une nouvelle ligne dans une feuille) mais dont la logique elle-même est simple, un outil de workflow avec un seul appel de modèle au milieu est nettement moins cher à construire et à maintenir que du code sur mesure. J’y recours avant l’infrastructure sur mesure dès que le déclencheur est standard et que le volume est faible à modéré.

4. Un modèle exécuté manuellement. Certains processus bénéficient davantage d’une checklist que d’une automatisation, parce que la valeur réside dans le fait qu’un humain réfléchisse à chaque étape, pas dans la vitesse. N’automatisez pas la réflexion sur les tâches où la réflexion est justement le but.

5. L’externalisation. Pour tout ce qui comporte une véritable ambiguïté ou du jugement, et où vous n’avez pas le temps de construire et de maintenir un ensemble d’évaluation, une personne — un assistant virtuel, un spécialiste, un prestataire de service productisé — est souvent plus rapide à mettre en route et plus facile à corriger en cours de route qu’un agent que vous êtes encore en train de calibrer.

6. Seulement alors : un agent sur mesure. Si vous avez descendu toute l’échelle et que rien ne tient — le déclencheur exige un vrai jugement sous charge, le volume est trop élevé pour un traitement manuel ou externalisé, et le calcul du ROI passe — c’est là qu’un agent conçu sur mesure avec sa propre pile de fiabilité mérite son coût de construction.

Le test à blanc de deux semaines

Pour tout ce qui se trouve à la limite — ça passe les cinq vérifications mais je ne suis toujours pas sûr — je fais tourner un test à blanc de deux semaines avant de m’engager dans une construction. Je fais la tâche moi-même, en utilisant le modèle comme copilote plutôt que comme système autonome : le même prompt que je finirais par donner à l’agent, les mêmes données d’entrée, mais je lis chaque résultat avant qu’il n’aille où que ce soit.

Deux choses ressortent de ce test. D’abord, si le modèle est réellement bon sur la tâche, au niveau de qualité dont j’ai besoin — si je réécris la moitié de son résultat à la main, la tâche n’est pas prête à être automatisée, peu importe le reste. Ensuite, un vrai ensemble d’évaluation : deux semaines de données d’entrée et les résultats que j’ai jugés corrects sont exactement ce dont un harnais d’évaluation a besoin, et je l’ai généralement déjà collecté gratuitement au moment où je décide de construire.

Le test à blanc fait aussi remonter les cas limites avant qu’ils ne soient en production. C’est bien moins coûteux de découvrir pendant un essai manuel que 15 % des entrées nécessitent un traitement particulier que de le découvrir via une réclamation client après le lancement de l’agent.

Une règle que j’applique après avoir abandonné une idée

Abandonner une idée d’agent n’est pas la même chose qu’abandonner le problème sous-jacent. Si une tâche se disqualifie elle-même pour l’instant — le processus continue de bouger, le volume est trop faible — j’écris pourquoi et je fixe un point de réexamen approximatif (généralement lié à un déclencheur précis : « réexaminer une fois que les réservations dépassent 50/semaine », pas juste une date). Les idées d’agents abandonnées une fois et jamais réexaminées se transforment discrètement en travail manuel permanent dont plus personne ne se souvient avoir évalué deux fois.

La discipline inverse compte tout autant : une idée qui passe les cinq vérifications et le calcul du ROI n’est pas automatiquement construite aujourd’hui. Elle rejoint la même file d’attente que tout le reste, classée par rapport aux automatisations déjà prouvées rentables. Passer le filtre donne à une tâche une place dans la file, pas une exemption de priorisation.

FAQ

N’est-ce pas juste un argument contre l’automatisation ?

Non — c’est un argument contre le fait de recourir par défaut à la forme d’automatisation la plus coûteuse. La plupart des alternatives de l’échelle ci-dessus restent de l’automatisation ; elles sont juste plus légères. Je fais tourner des dizaines d’agents en production. L’objectif n’est pas d’éviter de construire, c’est d’arrêter de sauter directement à « construire un agent sur mesure » quand un prompt enregistré ou un workflow no-code obtient le même résultat pour une fraction du coût de construction et de maintenance.

Et si le volume de la tâche va clairement augmenter plus tard ?

C’est une raison légitime de construire en avance sur les chiffres actuels — je couvre cette exception dans le cadre de ROI. Ça ne l’emporte pas pour autant sur les cinq signaux ci-dessus. Si le processus est encore instable ou que vous ne pouvez pas encore définir un résultat correct, un volume croissant signifie simplement que vous maintiendrez un agent défaillant à plus grande échelle. Réglez d’abord l’instabilité et la testabilité ; l’échelle est une raison de construire plus tôt une fois ces points résolus, pas une raison de les sauter.

Comment savoir si une étape d’outil no-code est « suffisante » ou s’il faut du code sur mesure ?

Essayez-la d’abord et mesurez-la par rapport à votre ensemble d’évaluation, même informel. Les étapes LLM no-code gèrent bien les tâches à objectif unique et à entrée unique. Elles commencent à peiner dès que vous avez besoin d’un usage d’outils en plusieurs étapes, d’un état persistant entre les exécutions, ou d’une logique conditionnelle que le constructeur de l’outil ne peut pas exprimer proprement. Si vous heurtez ce mur, c’est un vrai signal pour passer à une infrastructure sur mesure — pas une raison d’y commencer.

Est-ce que ça s’applique différemment aux outils internes et à ceux destinés aux clients ?

Les cinq signaux s’appliquent de la même façon, mais les enjeux diffèrent. Un outil interne avec un processus instable ne fait que gaspiller le temps de votre propre équipe quand il casse. Un outil destiné aux clients avec un processus instable érode la confiance de personnes qui n’ont pas signé pour être votre ensemble d’évaluation. Je tiens les automatisations destinées aux clients à une version plus stricte du signal cinq en particulier — la barre du « correctement encadré » est plus haute quand c’est un inconnu, et non un collègue, qui se trouve de l’autre côté d’une erreur.

Quelle est la raison la plus courante pour laquelle vous abandonnez une idée d’agent ?

Le signal trois — l’absence de test réussite/échec clair. C’est le plus facile à manquer pendant le cadrage, parce que la tâche semble bien définie jusqu’au moment où l’on essaie d’écrire à l’avance à quoi ressemble vraiment un résultat correct. Si je ne peux pas le faire en une ou deux phrases, je sais que l’agent sera inévaluable, donc inaméliorable, donc qu’il ne sera pas construit pour l’instant.