Quand ne pas utiliser d'agent IA (et quoi construire à la place)

Les bases 8 min de lecture

Un court script shell ouvert sur un ordinateur portable à côté d'un carnet fermé, préféré à un diagramme complexe
Parfois le projet terminé fait quarante lignes de code déterministe, et c'est un bon résultat.

Nous construisons des agents pour vivre, et c'est précisément pourquoi cette page existe. Le moyen le plus rapide d'abîmer la confiance d'une équipe est de mettre un agent sur une tâche qui n'en avait pas besoin, de le voir juste à 94 % là où un script faisait 100 %, et de passer le trimestre suivant à le défendre.

Voici les six situations où nous disons non, et ce que nous recommandons. Aucune ne parle des capacités des modèles : elles parlent des endroits où l'indéterminisme est un coût et non un atout.

1. Les étapes ne changent jamais#

Si la séquence est fixe — récupérer le fichier, valider les colonnes, transformer, charger, notifier — vous n'avez besoin de rien pour décider de la suite, puisque rien ne décide. Écrivez le pipeline. Si une étape demande du jugement, appelez le modèle pour cette étape et gardez le reste déterministe.

C'est le sur-dimensionnement le plus fréquent. Un appel de modèle dans un pipeline n'est pas moins noble qu'un agent : c'est la bonne chose.

2. La tâche est arithmétique ou correspondance exacte#

Totaux, rapprochements, fiscalité, règles d'éligibilité à seuils publiés : il existe une bonne réponse et des implémentations. Un modèle peut expliquer un calcul admirablement et se tromper de temps en temps, et de temps en temps est une catastrophe en finance. Calculez en code, puis laissez le modèle expliquer.

3. Budget de latence sous la seconde#

Un agent qui planifie, appelle deux outils et répond ne le fera pas de façon fiable sous la seconde, chaque appel ayant son plancher. Dans un tunnel d'achat, une recherche instantanée ou un routage d'appels, sortez le travail du chemin critique ou utilisez un classifieur et une requête. On pardonne une réponse lente demandée ; pas une page lente.

4. Personne ne sait à quoi ressemble une exécution correcte#

Si l'équipe ne peut pas produire vingt exemples de la tâche bien faite, vous n'avez pas de jeu d'évaluation — et sans lui, aucun moyen de savoir si un changement a aidé. Construisez d'abord les exemples. Souvent, les écrire révèle qu'il s'agit de trois tâches, deux triviales et une qui est le vrai problème.

Vingt exemples annotés est une barre volontairement basse. Ne pas l'atteindre signifie que la tâche n'est pas encore assez comprise.

5. Toute action est irréversible et à fort enjeu#

Virements, signatures de contrat, suppressions en production. Vous pouvez mettre un agent devant — comme rédacteur qui assemble le dossier et le remet à un humain. Ce qu'il ne faut pas faire, c'est donner à une boucle autonome un accès en écriture non surveillé sur de l'irréversible, en s'appuyant sur un taux issu d'un jeu de tests qui ne contenait pas votre pire semaine.

6. Les données nécessaires ne sont pas accessibles#

Un agent vaut ses outils, et ses outils valent vos API. Si l'information vit dans un système sans API de lecture, ou dans un tableur édité à la main par trois personnes, l'agent sera réduit à deviner. Réparez d'abord l'accès. Ce travail est ingrat et concentre l'essentiel de la valeur : ceux qui construisent l'API de lecture découvrent souvent que l'agent, ensuite, est un chantier de deux semaines.

Questions fréquentes

Quand un agent est-il clairement le bon outil ?

Quand l'étape suivante dépend vraiment de ce qu'a renvoyé la précédente, quand plusieurs outils peuvent être nécessaires dans un ordre non fixable, et quand aujourd'hui un humain fait cela en consultant puis en décidant.

Nous avons déjà un agent sur un pipeline fixe. Faut-il l'enlever ?

Pas nécessairement : mesurez d'abord. S'il est fiable et le coût acceptable, laissez-le. Remplacez-le quand vous pouvez pointer une douleur précise : latence imprévisible, coût par exécution ou pannes non reproductibles.

Un agent peut-il faire partie d'un système déterministe ?

Oui, et c'est souvent la meilleure conception. Gardez la colonne vertébrale déterministe et donnez à l'agent une zone bornée où le jugement est requis, avec un contrat clair sur ce qu'il peut renvoyer.

quand ne pas utiliser un agent iaagent ou workflowlimites automatisation llmcadrage projet iaalternatives aux agents

Tous les guides

Dernière mise à jour 2026-08-04 par aiagentdevelopment.info · À propos

Écrit par des praticiens

Chaque guide est écrit par des ingénieurs qui exploitent des agents en production, pas recyclé d’autres sites.

Relu régulièrement

Le domaine bouge vite. Chaque guide porte la date de sa dernière relecture, publiée même quand rien n’a changé.

Aucun placement payé

Aucun fournisseur de modèles, framework ou plateforme ne peut acheter une mention, un classement ou un lien.

Douze langues

Chaque guide est traduit, pas remplacé par une machine : chaque langue a son URL et sa date de relecture.

Limites nommées

Nous disons clairement quand une tâche n’a pas besoin d’agent et qu’un simple script serait moins cher et plus fiable.