Quand ne PAS utiliser un agent
Le fichier le plus utile de la section. La plupart des tâches qu'on confie à un agent seraient mieux traitées par vingt lignes de Python.
Temps de lecture : 13 min | Niveau : Débutant
Ce que tu sauras faire après
- Reconnaître en dix secondes une tâche qui ne mérite pas d'agent.
- Appliquer une grille de décision à 6 questions avant de lancer quoi que ce soit.
- Nommer les trois coûts cachés : latence, imprévisibilité, débogage.
- Remplacer un agent mal placé par un script, une requête ou une macro.
- Défendre ton choix en réunion, chiffres à l'appui.
1. Le principe directeur
Anthropic ouvre sa page d'ingénierie sur les agents par une recommandation qui va à contre-courant du marketing ambiant : chercher la solution la plus simple possible, et n'augmenter la complexité que lorsque c'est nécessaire. Ce qui peut vouloir dire ne pas construire de système agentique du tout.
Et cette phrase, à afficher au-dessus de ton écran :
« For many applications, optimizing single LLM calls with retrieval and in-context examples is usually enough. »
Autrement dit : un bon prompt avec les bons exemples règle la majorité des besoins. L'agent est l'exception, pas la règle.
Le compromis est toujours le même. Les systèmes agentiques échangent de la latence et du coût contre de la performance sur la tâche. Si tu ne gagnes pas en performance, tu ne perds que de l'argent et du temps.
Ce n'est pas une lubie d'Anthropic. Microsoft écrit la même chose dans la documentation de son Agent Framework :
« If you can write a function to handle the task, do that instead of using an AI agent. »
Enfin, Anthropic est direct sur les risques : les agents autonomes impliquent « higher costs, and the potential for compounding errors » et demandent « extensive testing in sandboxed environments ». Une erreur au tour 3 contamine les tours 4 à 12.
2. Les cinq familles de tâches où l'agent perd
Famille 1 — La tâche est déterministe
Si la même entrée donne toujours la même sortie par une règle connue, écris la règle.
| ❌ Agent | ✅ À la place | Gain |
|---|---|---|
« Renomme la colonne mt_ht en montant_ht dans tous mes modèles dbt » | grep -rl 'mt_ht' models/ | xargs sed -i 's/mt_ht/montant_ht/g' | Gratuit, instantané, reproductible, versionnable |
| « Convertis ces 200 CSV en Parquet » | Une boucle pandas ou duckdb | Aucune variabilité, aucun coût de token |
| « Formate tout mon SQL » | sqlfluff fix | Déterministe, intégrable en pre-commit |
Le test : est-ce que je peux écrire la règle en une phrase sans ambiguïté ? Si oui, c'est un script.
Famille 2 — Une requête SQL fait le travail
Le piège le plus fréquent chez les data analysts. On demande à un agent ce qu'une requête calcule directement.
❌ "Agent, analyse mes commandes et dis-moi quels clients ont baisse
leur volume d'achat ce trimestre."-- ✅ Trente secondes d'ecriture, resultat exact, rejouable, auditable
WITH par_trimestre AS (
SELECT client_id,
DATE_TRUNC('quarter', date_cmd) AS trimestre,
SUM(montant_ht) AS ca
FROM commandes
WHERE date_cmd >= DATE '2025-10-01'
GROUP BY 1, 2
)
SELECT c.client_id,
p.ca AS ca_trimestre_precedent,
a.ca AS ca_trimestre_actuel,
a.ca - p.ca AS variation
FROM par_trimestre a
JOIN par_trimestre p
ON p.client_id = a.client_id
AND p.trimestre = a.trimestre - INTERVAL '3 months'
WHERE a.ca < p.ca
ORDER BY variation ASC;Le bon usage de l'IA ici : te faire écrire cette requête. Un appel LLM, pas un agent. Puis tu l'exécutes toi-même, et tu la commites.
Différence essentielle : la requête est auditable. Dans six mois, tu relis le SQL et tu sais exactement d'où vient le chiffre. Le raisonnement d'un agent, lui, n'existe plus.
Famille 3 — Le volume est élevé et la tâche bien comprise
Classification de tickets, extraction de champs d'une facture, catégorisation de produits. Le nombre d'étapes est toujours un. Il n'y a rien à décider.
# ❌ Un agent par ticket : 10 000 boucles, latence enorme, cout x4 minimum
# ✅ Un appel LLM par ticket, en parallele, avec sortie structuree
categories = ["donnees_fausses", "performance", "acces", "autre"]
resultats = traiter_en_parallele(tickets, prompt_classification, categories)L'agent n'apporte rien : il n'y a pas d'exploration, pas d'outils à choisir, pas de correction de trajectoire.
Famille 4 — Les sous-tâches dépendent les unes des autres
Anthropic l'a constaté sur son propre système : le multi-agents est mal adapté aux domaines où tous les agents auraient besoin du même contexte, et à ceux où les agents dépendent les uns des autres. Son exemple :
« most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time »
Concrètement : si l'agent B a besoin de ce que l'agent A a décidé, tu n'as pas de parallélisme. Tu as une chaîne avec du surcoût d'orchestration.
Famille 5 — L'erreur est coûteuse ou irréversible
| Situation | Pourquoi jamais d'agent autonome |
|---|---|
DELETE ou UPDATE sur une base de production | Pas de Ctrl+Z |
git push --force sur main | L'historique de l'équipe |
| Envoi d'emails à des clients | La réputation |
| Modification d'un droit d'accès | La sécurité |
| Écriture dans une table financière | L'audit |
La règle : un agent propose, un humain dispose. Mode plan, ou sortie sous forme de diff que tu appliques toi-même.
3. Les trois coûts cachés
Ce sont eux qui font qu'un projet d'agent « presque fini » ne se termine jamais.
💸 Coût caché 1 — La latence
Un agent, c'est N allers-retours avec le modèle. Chaque tour attend la réponse du tour précédent.
Script Python : 200 ms
Une requete SQL : 400 ms
Un appel LLM : 3 s
Un agent (8 tours) : 45 s a 3 min
Un fan-out de 30 agents : 2 a 10 minSur une tâche que tu fais trois fois par jour, ces minutes s'additionnent. Et surtout : tu ne peux pas travailler pendant ce temps si tu dois relire le résultat.
🎲 Coût caché 2 — L'imprévisibilité
Le même prompt peut produire un chemin différent d'une fois sur l'autre. C'est la contrepartie directe de la liberté de décision.
Conséquences concrètes :
- Tu ne peux pas écrire un test qui vérifie que l'agent « fait bien X ».
- Le coût varie d'une exécution à l'autre, parfois du simple au triple.
- Un agent qui a marché lundi peut échouer jeudi sur la même tâche.
- Tu ne peux pas mettre ça dans un pipeline critique sans filet.
Les workflows, eux, « offer predictability and consistency for well-defined tasks ». C'est exactement la propriété que tu perds en passant à l'agent.
🔍 Coût caché 3 — Le débogage
Quand un script échoue, tu as une stack trace et un numéro de ligne. Quand un agent échoue, tu as un transcript de quarante tours et une question : à quel moment est-ce parti de travers ?
Pire : la compaction. La documentation du SDK prévient que quand le contexte approche de sa limite, l'historique ancien est résumé, et « specific instructions from early in the conversation may not be preserved ». Ton agent a donc pu oublier une contrainte que tu avais posée au début. Bon courage pour le reproduire.
C'est aussi pour ça qu'Anthropic recommande des tests poussés en environnement isolé avant tout usage réel.
4. La grille de décision
Imprime-la. Six questions, dans l'ordre. Tu t'arrêtes à la première réponse qui te fait sortir.
Q1. Une requete SQL, un script ou une commande shell suffit-il ?
OUI -> Ecris-le. Utilise l'IA pour t'aider a l'ECRIRE, pas pour l'executer. STOP.
NON -> Q2
Q2. Un seul appel LLM avec un bon prompt et 2-3 exemples suffit-il ?
OUI -> Fais ca. C'est le cas le plus frequent. STOP.
NON -> Q3
Q3. Est-ce que je connais les etapes A L'AVANCE, toujours les memes ?
OUI -> Workflow scripte. Mon code tient le plan. STOP.
NON -> Q4
Q4. Existe-t-il un SIGNAL DE VERITE automatique ?
(test qui passe, requete qui s'execute, linter, schema valide)
NON -> N'utilise PAS d'agent : il tournera a l'aveugle. Redefinis
le probleme jusqu'a avoir un signal. STOP.
OUI -> Q5
Q5. Une erreur est-elle reversible et peu couteuse ?
NON -> Agent en mode lecture seule ou mode "plan" UNIQUEMENT.
Tu appliques les changements toi-meme. STOP.
OUI -> Q6
Q6. Le gain justifie-t-il ~4x le cout d'une conversation
(~15x en multi-agents) et 1 a 5 minutes d'attente ?
NON -> Conversation classique, tu pilotes. STOP.
OUI -> AGENT. Avec max_turns, max_budget_usd et outils restreints.La même chose en tableau
| Question | Si NON | Si OUI |
|---|---|---|
| Q1 — Un script suffit ? | Continuer | Script |
| Q2 — Un appel LLM suffit ? | Continuer | Appel LLM |
| Q3 — Étapes connues d'avance ? | Continuer | Workflow |
| Q4 — Signal de vérité automatique ? | Ne pas faire d'agent | Continuer |
| Q5 — Erreur réversible ? | Agent en lecture seule / plan | Continuer |
| Q6 — Le gain paie le surcoût ? | Conversation classique | Agent |
5. AVANT / APRÈS : quatre cas réels
Cas 1 — Contrôle qualité quotidien
❌ AVANT
Chaque matin, un agent verifie la qualite de mes tables.Coût : ~4 × une conversation, tous les jours. Résultat différent chaque matin. Impossible de tracer une régression.
✅ APRÈS
# dbt : des tests declaratifs, executes par le scheduler
models:
- name: mart_ca_mensuel
columns:
- name: mois
tests: [not_null, unique]
- name: montant_ht
tests:
- not_null
- dbt_utils.accepted_range:
min_value: 0Pourquoi c'est mieux : gratuit, déterministe, versionné, et l'échec pointe la table et la colonne exactes. L'IA a servi une seule fois : à t'aider à écrire ces tests.
Cas 2 — Documenter 30 modèles dbt
❌ AVANT
Agent, documente tous mes modeles dbt.L'agent lit tout, sature son contexte, compacte, et la qualité s'effondre sur les derniers fichiers.
✅ APRÈS
Fan-out : un sous-agent par modele, contexte isole.
Chaque agent lit UN fichier + ses dependances directes, et rend
un bloc YAML de description au format dbt. Maximum 15 lignes.
Puis un agent de synthese assemble les 30 blocs en un schema.yml.Pourquoi c'est mieux : contexte propre pour chacun, qualité homogène du premier au trentième, résultat exploitable directement.
Cas 3 — Un DAG Airflow qui échoue
❌ AVANT
Ecris-moi un script qui detecte pourquoi mon DAG echoue.Impossible : la cause est différente à chaque fois. Un script déterministe ne peut pas couvrir des causes inconnues.
✅ APRÈS
Agent, mode enquete, lecture seule.
Perimetre : dags/daily_sales/ et logs/daily_sales/.
Signal de verite : la commande `airflow dags test daily_sales 2026-09-22`
doit passer.
Critere d'arret : cause racine identifiee + diff propose.
Tu ne modifies aucun fichier.Pourquoi c'est un vrai cas d'agent : nombre d'étapes imprévisible, signal de vérité automatique, périmètre fermé, aucun risque.
Cas 4 — Classer 10 000 tickets
❌ AVANT
Un agent qui lit chaque ticket et le classe.10 000 boucles d'agent. Latence et coût démesurés pour une tâche à une seule étape.
✅ APRÈS
# Un appel LLM par ticket, parallelise, sortie contrainte a 4 valeurs
prompt = """Classe ce ticket dans EXACTEMENT une categorie.
Categories : donnees_fausses | performance | acces | autre
Reponds par le seul nom de la categorie, rien d'autre.
Ticket : {texte}"""Pourquoi c'est mieux : une étape, donc un appel. Coût divisé, latence divisée, et tu peux mesurer la précision sur un échantillon annoté.
6. Template : justifier ton choix
Quand on te demande « pourquoi tu n'as pas fait un agent ? », remplis ceci.
TACHE
[DESCRIPTION_EN_UNE_PHRASE]
SOLUTION RETENUE
[SCRIPT / REQUETE SQL / APPEL LLM / WORKFLOW / AGENT]
POURQUOI PAS PLUS SIMPLE
[CE_QUE_LA_SOLUTION_INFERIEURE_NE_SAIT_PAS_FAIRE]
POURQUOI PAS PLUS COMPLEXE
[CE_QUE_LA_SOLUTION_SUPERIEURE_COUTERAIT_SANS_RIEN_APPORTER]
SIGNAL DE VERITE
[COMMENT_ON_SAIT_QUE_C_EST_REUSSI, DE FAÇON AUTOMATIQUE]
COUT ESTIME PAR EXECUTION
Latence : [DUREE]
Tokens / euros : [ESTIMATION]
Frequence : [X_FOIS_PAR_JOUR_OU_SEMAINE]
RISQUE SI ÇA RATE
[REVERSIBLE_OU_NON] — [QUI_EST_IMPACTE]
GARDE-FOUS POSES
- Outils autorises : [LISTE]
- max_turns : [N] | max_budget_usd : [MONTANT]
- Mode de permission : [plan / lecture seule / acceptEdits]
- Relecture humaine : [OUI_A_QUELLE_ETAPE / NON_ET_POURQUOI]7. Le résumé en une image
Complexite
^
| [AGENT]
| rare, cher, puissant
| nombre d'etapes inconnu
| ^
| [WORKFLOW] |
| etapes connues d'avance |
| ^ |
| [APPEL LLM] | |
| le cas le plus | |
| frequent | |
| ^ | |
| [SCRIPT] | | |
| gratuit, | | |
| determin. | | |
+-------------+--------------+---------------+------> Valeur ajoutee
de l'IA
Tu montes d'un cran SEULEMENT quand le niveau du dessous echoue.
Jamais par principe. Jamais parce que c'est a la mode.À retenir
- La consigne d'Anthropic est de commencer par la solution la plus simple et de ne complexifier que si c'est nécessaire — quitte à ne pas construire d'agent du tout.
- « Optimizing single LLM calls with retrieval and in-context examples is usually enough » : c'est vrai pour la majorité de tes besoins.
- Un agent se justifie quand le nombre d'étapes est imprévisible et qu'il existe un signal de vérité automatique. Sans signal, pas d'agent.
- Les trois coûts cachés : latence (minutes), imprévisibilité (pas de test possible), débogage (transcript de 40 tours + compaction qui efface des instructions).
- Erreur irréversible → agent en lecture seule ou mode
plan. Toujours. - Pour le déterministe, le SQL et le volume élevé : script, requête, ou un simple appel LLM. Utilise l'IA pour écrire l'outil, pas pour le remplacer.