Tout le monde parle d’IA agentique. La plupart des articles vous donnent la définition Wikipédia, un schéma avec des flèches, et trois cas d’usage inventés. Ce n’est pas ça. Voici ce que c’est vraiment — vu depuis la prod, pas depuis une démo YouTube.
Agent vs workflow : la distinction que personne n’explique vraiment
Un workflow Make ou n8n est un DAG — un graphe orienté acyclique. Traduction concrète : le chemin est écrit à l’avance. Si A alors B, si erreur alors C. Vous pouvez dessiner le flowchart complet avant d’exécuter quoi que ce soit. C’est déterministe. C’est fiable. C’est ce que font 80% des automatisations qu’on appelle à tort « agents ».
Un agent, c’est autre chose. Le LLM reçoit un objectif et une liste d’outils disponibles. Il décide lui-même quelle action faire à chaque étape, en fonction de ce qu’il a trouvé à l’étape précédente. Deux exécutions identiques — même prompt, même input, même modèle, température à 0 — peuvent emprunter des chemins différents et produire des résultats différents. Cette boucle de décision non déterministe, c’est ce qu’on appelle une agentic loop. Chaque tour consomme des tokens. L’agent ne « sait » pas combien de tours il va faire.
La clé pratique : si vous pouvez dessiner le flowchart complet avant l’exécution, vous n’avez pas besoin d’un agent. Un pipeline structuré avec deux appels LLM fera le même travail pour un quart du prix, avec dix fois moins de debugging.
Ce qui casse en production
Les démos sont propres parce qu’elles sont préparées. En prod, trois problèmes reviennent systématiquement.
Les boucles infinies
Un agent qui ne trouve pas l’information va retenter, reformuler, retenter encore. Il n’a pas conscience de tourner en rond. J’ai vu un agent consommer 200 000 tokens sur une tâche qui aurait dû en prendre 8 000. Sans circuit breaker — un mécanisme qui stoppe l’agent après N itérations ou au-delà d’un budget de tokens — vous avez une facture API imprévisible et un résultat inexistant. En prod, le circuit breaker n’est pas optionnel.
La dérive de contexte (context drift)
Sur une tâche en 12 étapes, l’agent « oublie » progressivement les contraintes définies au début. Les instructions placées au milieu de la fenêtre de contexte sont les plus vulnérables — le modèle leur accorde moins de poids que ce qui est au début et à la fin. Résultat : un agent parfaitement calibré sur les 6 premières étapes qui commence à improviser sur les suivantes.
L’hallucination d’outil
Le LLM invente des paramètres d’API qui n’existent pas, ou appelle un outil avec une syntaxe presque correcte — mais pas tout à fait. Le tool call échoue silencieusement, ou pire, produit un résultat absurde que l’agent accepte et continue à exploiter. Le debugging est cauchemardesque : relire 50 échanges tool-use pour trouver où ça a déraillé n’est pas l’équivalent du « cliquer sur le nœud rouge » de Make.
4 cas concrets — avec les vrais chiffres
Qualification de leads entrants — startup B2B SaaS
Déclencheur : webhook Typeform vers n8n. L’agent Claude Sonnet dispose de trois outils — recherche web via Serper API, enrichissement entreprise via Societeinfo, lecture de page web. Il visite le site de l’entreprise, estime la taille, croise avec le message du formulaire, et renvoie un JSON structuré : score 1 à 5, résumé en trois lignes, recommandation (appel immédiat / nurturing / disqualifié). n8n route ensuite vers le bon canal Slack selon le score.
Résultat : 2 heures de revue manuelle par jour ramenées à 15 minutes. Coût : 0,04 USD par lead, soit environ 6 000 tokens Sonnet. Taux de faux positifs : 12% contre 8% en manuel — acceptable pour le gain de temps.
Fiches produits depuis PDFs fournisseurs — e-commerce
3 000 SKUs, fiches techniques fournisseur en PDF dans des formats tous différents. Make détecte chaque nouveau fichier Drive, un script Python extrait le texte (PyMuPDF + OCR Tesseract si nécessaire). Premier appel Claude : extraction structurée vers JSON normalisé. Deuxième appel Claude : génération de la description marketing SEO. Validation automatique (titre sous 70 caractères, mot-clé présent), retry max 2 fois si invalide. Export CSV vers WooCommerce.
Résultat : 3 000 fiches produites en 3 jours au lieu de 6 semaines. Coût tokens : 180 USD. Taux de fiches acceptées sans retouche : 74%.
Ce cas est important pour une raison : ce n’est pas un agent au sens strict. Deux appels LLM en séquence avec validation par code — c’est un pipeline structuré. Un agent autonome aurait coûté trois fois plus pour le même résultat. C’est le meilleur exemple que j’ai de « workflow + LLM > agent ».
Veille concurrentielle SEO hebdomadaire
Cron lundi à 7h. L’agent Claude Sonnet dispose de quatre outils : scraping de sitemap XML, API SEMrush, recherche web, lecture de page. Il compare les sitemaps des concurrents avec le snapshot de la semaine précédente (stocké en JSON), lit les nouvelles pages, identifie les mots-clés cibles, et produit un rapport : nouvelles pages analysées, mouvements de positions, recommandations d’action.
Résultat : 1h30 de travail manuel ramenée à 8 minutes. Coût : 0,35 USD par rapport, soit environ 40 000 tokens Sonnet. Taux de capture des insights pertinents : 85%.
Réponses aux avis Google — réseau de 12 points de vente
80 à 120 avis par mois. Make reçoit le webhook, envoie à Claude Haiku (pas besoin de Sonnet pour ça). Premier appel : génération de la réponse en few-shot avec six exemples validés et le tone of voice du réseau. Deuxième appel Haiku en mode « juge » : longueur entre 40 et 150 mots, pas de promesse commerciale, cohérence avec la charte. Les avis 1 étoile partent en validation humaine — règle métier non négociable.
Résultat : 4 heures par mois ramenées à 30 minutes. Coût : 0,002 USD par avis. Taux d’acceptation sans modification : 91%.
Là encore : deux appels LLM en séquence. Pas un agent. Simple, peu coûteux, fiable.
Ce que « agentique » ne veut pas dire
Deux idées surévaluées reviennent dans presque tous les pitchs.
L’autonomie totale. En prod, un agent fiable est un agent supervisé. Le modèle human-in-the-loop — l’agent fait 80% du travail, un humain valide aux points critiques — n’est pas un aveu d’échec. C’est la seule architecture raisonnable dès qu’une décision est irréversible. Envoyer un email, créer une fiche client, modifier un prix : un agent ne devrait pas faire ça sans validation sur les cas ambigus.
Le multi-agent. Dans neuf cas sur dix, un seul agent avec un bon prompt système bat un système multi-agent. Chaque passage d’un agent à l’autre est une perte d’information et un coût supplémentaire. Un prompt structuré (« D’abord recherche, puis rédige, puis relis ») fait le même travail pour un quart du prix.
Trois autres réalités que personne ne mentionne volontiers : le coût est non prédictible (le nombre de tours de boucle varie — même tâche, 2 appels ou 15 selon le run), la latence est incompatible avec le temps réel (5 appels tool en séquence = 10 à 30 secondes minimum, l’agent est fait pour le batch et le back-office), et la reproductibilité est inexistante (même prompt, même input, même modèle, température à 0 — deux runs peuvent donner des résultats différents).
Enfin : LangChain ajoute une couche d’abstraction qui masque ce qui se passe réellement. Pour un agent simple, 50 lignes de Python avec l’API Claude directement sont plus lisibles, plus debuggables et plus maintenables.
Comment savoir si c’est fait pour vous
Trois critères concrets, sans vague.
Le volume. Le sweet spot réel se situe entre 50 et 500 tâches par jour. En dessous, le coût de mise en place ne se justifie pas. Au-dessus, les coûts d’API et la variabilité des outputs deviennent des problèmes à part entière.
La variabilité des cas. Si chaque tâche suit exactement les mêmes étapes, un workflow classique suffit — et coûtera dix fois moins cher à maintenir. L’agent apporte de la valeur quand les cas sont légèrement différents les uns des autres et nécessitent un jugement contextuel que vous ne pouvez pas coder sous forme de règles.
La tolérance à l’erreur. Un taux d’erreur de 5 à 15% est réaliste sur la plupart des agents en prod. Si chaque erreur a des conséquences graves (communication client, données financières, actions irréversibles), l’architecture doit prévoir un human-in-the-loop explicite — ce qui complexifie et ralentit.
Si les trois critères sont remplis, vous avez probablement un cas solide. Si le volume est faible ou la tolérance à l’erreur nulle, un pipeline structuré avec quelques appels LLM donnera de meilleurs résultats pour moins d’efforts.
La différence entre une démo et une prod sérieuse : la démo montre 1 exemple choisi à la main, sans gestion d’erreur, avec un prompt de 3 lignes. La prod sérieuse, c’est un jeu de test de 50 cas minimum (dont 20% de cas dégradés), un circuit breaker, un logging structuré de chaque tool call avec input/output/latence/coût, un versioning du prompt, et un eval régulier sur un jeu de données de référence. Les vrais praticiens passent autant de temps sur l’évaluation que sur le prompting.
La prochaine étape
Si vous avez une tâche répétitive qui prend plus de 2 heures par semaine, suit toujours les mêmes grandes étapes mais avec des variations de détail, et produit un output qui peut être vérifié — c’est probablement automatisable. La question n’est pas « est-ce que l’IA peut le faire » mais « quelle architecture choisir et comment la tester correctement ».
Pour comprendre les outils qui permettent de construire ces systèmes concrètement, le guide sur Make et n8n détaille les différences d’architecture et les cas où chaque outil est le bon choix. Si vous préférez partir d’un audit de vos process existants pour identifier les gains les plus rapides, travailler avec un expert IA permet d’éviter les erreurs de conception qui coûtent cher à corriger une fois le système en prod. Et si vous voulez une vue d’ensemble sur ce qu’on peut mettre en place concrètement côté automatisation, c’est par là.
0 commentaire