Arrêtez de développer des agents IA, utilisez plutôt des workflows LLM plus intelligents

• Dans la plupart des équipes qui construisent des systèmes basés sur des LLM, tout le monde essaie de commencer par des agents, mais la plupart de ces projets s’effondrent rapidement à cause de la complexité, du manque de contrôle et de la difficulté du débogage
• Les véritables patterns d’agents, qui nécessitent mémoire, RAG, usage d’outils et contrôle du workflow, sont en réalité rares, et la plupart des problèmes se résolvent plus efficacement avec des workflows simples (chaining, parallélisation, routing, etc.)
• Il est recommandé d’appliquer d’abord 5 patterns de workflow LLM réellement utiles en pratique, et de n’utiliser des agents qu’avec prudence lorsque c’est vraiment nécessaire
  • Prompt chaining, parallélisation, routing, orchestrator-worker, evaluator-optimizer
• Même lorsqu’un agent est nécessaire, l’essentiel reste l’intervention humaine, un contrôle explicite et l’observabilité (Observability)

---

Les agents IA sont-ils vraiment nécessaires ?

• Les réflexions de Hugo Bowne-Anderson, qui fournit du conseil et de la formation sur la construction de systèmes LLM à divers ingénieurs et équipes, notamment chez Netflix, Meta et l’US Air Force
  • Il anime la formation Building LLM Applications for Data Scientists and Software Engineers

Un mauvais point de départ : pourquoi tout le monde s’obsède avec les agents

• De nombreuses équipes, au démarrage d’un projet LLM, introduisent d’abord des structures complexes comme les agents, la mémoire, le routing, l’usage d’outils et les personas
• En pratique, une fois le système mis en place, des comportements anormaux et des échecs récurrents apparaissent fréquemment dans la collaboration entre agents, le choix des outils ou la mémoire long terme
• Exemple : sur un projet d’agent de recherche basé sur CrewAI, chaque rôle (chercheur, résumeur, coordinateur) n’a pas coopéré comme prévu et l’ensemble s’est effondré sans recours

Qu’est-ce qu’un agent ?

• Les 4 caractéristiques d’un système LLM : mémoire, recherche d’information (RAG), usage d’outils et contrôle du workflow
• Le dernier point, le contrôle du workflow (le fait que le LLM décide lui-même de l’étape suivante ou de l’usage d’un outil), est appelé une caractéristique agentique
• Dans la plupart des tâches réelles, des workflows simples (chaining, routing, etc.) offrent une meilleure stabilité

Les patterns de workflow LLM à utiliser à la place des agents, vraiment utiles en pratique

1. Prompt Chaining

• Description : découper plusieurs tâches en une série d’étapes (une chaîne), afin que le LLM traite chaque étape séquentiellement
• Exemple : extraire le nom, le poste et l’entreprise depuis un profil LinkedIn → ajouter des informations complémentaires sur l’entreprise (mission, recrutement, etc.) → rédiger un e-mail personnalisé à partir du profil + des informations sur l’entreprise
• Avantages : chaque étape étant clairement séparée, il est facile d’identifier et de corriger la cause d’un bug ; c’est favorable au débogage et à la maintenance
• Lignes directrices :
  • adapté aux tâches reliées de manière séquentielle
  • si une seule étape échoue, toute la chaîne peut s’effondrer
  • en divisant en petites unités de travail, on obtient des résultats plus prévisibles et un débogage plus simple

2. Parallélisation (Parallelization)

• Description : exécuter simultanément plusieurs tâches indépendantes pour accélérer l’ensemble du processus
• Exemple : extraire en parallèle, depuis plusieurs profils, différents éléments comme la formation, l’expérience ou les compétences afin de réduire le temps total de traitement
• Avantages : efficace à grande échelle pour l’extraction ou le traitement de données indépendantes, et bien adapté aux environnements de traitement distribué
• Lignes directrices :
  • lorsque les tâches sont mutuellement indépendantes, l’exécution simultanée améliore fortement la vitesse globale
  • attention aux cas d’exception comme les race conditions ou les timeouts pendant l’exécution parallèle
  • adapté au traitement de gros volumes de données et à l’analyse simultanée de plusieurs sources

3. Routing

• Description : le LLM classe les données d’entrée pour les diriger automatiquement vers le workflow approprié
• Exemple : dans un outil de support client, classer le contenu entrant entre demande produit, problème de paiement ou demande de remboursement, puis l’acheminer automatiquement vers le bon workflow ; si le type est ambigu, transmettre à un handler par défaut
• Avantages : appliquer une logique de traitement spécialisée selon le type d’entrée et séparer proprement les différents cas
• Lignes directrices :
  • utile lorsqu’un traitement distinct est nécessaire selon les types d’entrée ou les situations
  • sur les cas limites ou exceptionnels, le routing peut échouer ou omettre certains cas
  • il faut impérativement concevoir un handler catch-all pour les cas non classés ou exceptionnels

4. Orchestrator-Worker

• Description : un LLM jouant le rôle d’orchestrateur décompose la tâche et prend les décisions, puis délègue les sous-tâches à des workers (LLM d’exécution) tout en contrôlant directement le flux global et son ordre
• Exemple : classer un profil cible en tech/non-tech → s’il est tech, déléguer la génération d’e-mail à un worker spécialisé ; s’il est non-tech, déléguer à un autre worker
• Avantages : sépare la prise de décision (classification/jugement) de l’exécution (traitement individuel), ce qui facilite le contrôle dynamique du flux et l’extension
• Lignes directrices :
  • adapté quand chaque tâche nécessite un traitement spécialisé, avec des branchements complexes et une coordination étape par étape
  • si l’orchestrateur décompose mal la tâche ou délègue incorrectement, des erreurs apparaissent dans tout le flux
  • garder une logique explicitement simple, et définir clairement les règles de délégation, l’ordre et les conditions d’arrêt

5. Evaluator-Optimizer

• Description : le LLM évalue le résultat (score/feedback) et, s’il n’atteint pas le seuil attendu, le corrige et l’améliore de façon itérative
• Exemple : générer un brouillon d’e-mail → l’évaluateur fournit un score de qualité et un feedback → arrêt si un certain seuil est atteint ou si le nombre maximal d’itérations est dépassé, sinon nouvelle révision
• Avantages : permet d’améliorer itérativement la qualité du livrable final jusqu’au niveau visé, et se prête bien à l’usage de critères quantitatifs
• Lignes directrices :
  • adapté aux situations où la qualité prime sur la vitesse, et aux workflows nécessitant une optimisation itérative
  • sans condition d’arrêt, on peut tomber dans une boucle infinie
  • il est indispensable de définir des critères de qualité clairs et une limite d’itérations

Les cas où un agent est vraiment nécessaire

• Les agents révèlent toute leur valeur dans des environnements où l’intervention humaine en temps réel (Human-in-the-loop) est garantie
  • Exemple 1 : assistance en data science — requêtes SQL, visualisation, recommandations d’analyse de données, etc. ; le LLM tente des approches créatives, puis l’humain évalue et corrige le résultat
  • Exemple 2 : partenaire créatif — idées de copywriting, propositions de titres, recommandations de structure de texte, etc. ; l’ajustement de direction et la validation qualité par un humain sont essentiels
  • Exemple 3 : assistant de refactoring de code — propositions de design patterns, détection d’edge cases, optimisation de code, etc. ; le développeur approuve et complète
• Caractéristique : l’agent ne fait pas « tout tout seul » ; il est surtout efficace dans un environnement où un humain corrige les erreurs et ajuste la direction en temps réel

Les cas où les agents ne conviennent pas

• Systèmes enterprise et mission-critical (finance, santé, droit, etc.) :
  • la fiabilité de l’automatisation et le comportement déterministe étant essentiels, une architecture où un agent LLM prend les décisions est risquée
  • il faut utiliser des patterns de contrôle explicites comme l’orchestrateur ou le routing
• Toutes les situations où la stabilité et la prévisibilité sont cruciales
  • cas typiques : l’agent choisit de façon répétée les mauvais outils sans contexte ni mémoire, ou bien la division du travail et la coordination échouent, ce qui fait s’effondrer tout le flux
• Facteurs d’échec fréquents des systèmes d’agents en production
  • absence de conception explicite d’un système de mémoire, provoquant des pertes de contexte
  • contraintes insuffisantes sur le choix des outils (usage d’outils inutiles ou erronés)
  • dépendance à une structure de délégation trop libre, entraînant un échec de coordination entre agents

Enseignements pour la conception en pratique

• Même en introduisant des agents, il faut impérativement mettre en place une conception, une observabilité et des mécanismes de contrôle dignes d’un système logiciel abouti
• Plutôt qu’un framework d’agents complexe, il est plus rapide et plus sûr de concevoir avec de l’observabilité (Observability), des boucles d’évaluation claires et une structure directement contrôlable

Conclusion (TL;DR)

• Les agents sont souvent surévalués et surutilisés
• Pour la plupart des cas d’usage réels, des patterns de workflow simples sont plus adaptés
• Les agents révèlent leur vraie valeur dans des environnements où l’humain intervient directement
• Dans les systèmes stables, ils peuvent au contraire devenir un facteur de risque
• Concevoir avec de l’observabilité, un contrôle explicite et une structure d’évaluation itérative

• Plutôt qu’un framework d’agents complexe, le vrai secret pour développer des services LLM plus vite et plus sûrement consiste à concevoir avec de l’observabilité, des boucles d’évaluation claires et une structure directement contrôlable

[samdo103]

Il y a un mois, pour apprendre ce qu’était le codage avec l’IA en utilisant CURSOR, j’ai lancé le développement d’un framework de développement.

Pendant environ trois semaines, j’ai enchaîné les réussites puis les moments où du code source pourtant validé par l’AI Agent se retrouvait cassé, et j’ai tenté par tous les moyens de contrôler l’AI Agent, sans succès.

J’ai alors compris qu’avant de développer ce framework, la priorité était de développer le code source permettant de contrôler l’AI Agent.

Au final, exactement un mois après avoir commencé à vouloir comprendre ce qu’était vraiment l’IA, j’ai réussi à achever le développement d’un logiciel pouvant être implémenté à 100 % et exploité à 100 % par l’IA, avec un contrôle parfait de l’AI Agent — ou, plus précisément, sans avoir besoin de LLM externes ni d’AI Agent.

En ce moment, cela fait 14 jours que je poursuis le processus d’amélioration supplémentaire en réentraînant cette META AI et en élaborant des règles d’exploitation qu’elle doit respecter. En parallèle, je mène simultanément la migration, l’amélioration et la standardisation de trois systèmes MES que des humains avaient auparavant conçus de manière incomplète, et j’en suis désormais à la phase finale.

Et je prépare maintenant une autre évolution.

[spilist2]

Mais alors, dans le prompt chaining, n’est-il pas acceptable d’appeler chacun d’eux un agent — le LLM qui exécute les prompts individuels, le worker d’exécution, le worker orchestrateur, le LLM évaluateur, etc. ?

[spilist2]

Ah, il y a donc cette idée que « le contrôle final du workflow (le fait que le LLM décide lui-même de l’étape suivante ou de l’utilisation d’un outil) est qualifié de caractéristique agentique ». J’ai compris. C’était donc un texte qui visait les autonomous agents. Je ne connais pas encore très bien les agents, donc...

[GN⁺]

Avis Hacker News

• Développer des agents était vraiment amusant, mais il est clair qu’il y a un problème sérieux de « context engineering ». Même en augmentant la fenêtre de contexte, il faut quand même organiser les éléments que l’agent peut voir, et j’ai l’impression qu’il manque un filtre efficace capable de ne sélectionner que les informations vraiment importantes. Du coup, il faut l’aider en éparpillant des fichiers *.md un peu partout, et l’attribution des rôles est aussi importante. Ce système en *.md est une sorte de système de mémoire primitif, qui pourrait évoluer vers quelque chose de bien plus robuste. Je pense aussi qu’il est possible de générer en temps réel des programmes ou des modèles fondés sur le langage naturel à partir des interactions de l’utilisateur. En utilisant Claude Code, j’ai réalisé qu’« piloter » un agent avec une suite de tests est un mécanisme de renforcement vraiment puissant, et comme cette boucle fonctionne la plupart du temps avec succès, j’espère voir émerger de nouvelles idées pour faire des agents des collaborateurs plus intelligents
  • J’ai l’impression de passer plus de temps à me battre avec les outils qu’à faire le vrai travail
  • Je me demande s’il existe de bonnes pratiques pour organiser les fichiers .md dans ce type de système. Je crains qu’ajouter beaucoup de balisage pour les rendre lisibles par des humains ne pose problème au LLM. J’aimerais savoir si créer des fichiers .md conçus pour la lecture humaine gêne ou non leur utilisation par un LLM
  • D’après mon expérience, la gestion du contexte est au cœur de presque tous les problèmes. Par exemple, il faut construire le bon contexte pour des tâches parallèles/récursives, exclure certaines étapes (par ex. l’édition d’une réponse précédente) pour ne montrer que le résultat modifié, faire en sorte que l’agent relie mes commentaires à sa propre sortie quand j’en ajoute, etc. En pratique, il y a toutes sortes de situations
  • Le point sur le fait de renforcer l’agent avec une suite de tests est intéressant ; je serais curieux d’avoir plus de détails sur la procédure concrète
• Je ne suis pas encore certain que les agents IA seront utilisés massivement comme on l’entend dire sur LinkedIn, mais je laisse cette possibilité ouverte. Aujourd’hui, j’utilise Claude Code et Cursor en gardant un fort contrôle sur l’IA. Ce n’est pas parce que le modèle est insuffisant, mais parce que je veux souvent donner moi-même le « goût » et la direction. Donner plus d’autonomie à l’IA ne m’attire pas vraiment ; j’ai besoin d’intervenir pour ressentir un lien avec l’identité du résultat. Peut-être que mon avis changera si les méthodes de travail évoluent ou si une nouvelle UX apparaît, mais pour l’instant je ne veux pas d’une IA trop agentique
  • Je me demande si, avec le temps, à mesure qu’on comprendra mieux le comportement des modèles, le fait de leur fournir davantage de contexte et de consignes de meilleure qualité suffira à satisfaire en partie ces exigences de goût et de direction. D’après mon expérience, un prompt engineering bien fait permet déjà dans beaucoup de workflows d’amener l’IA à se comporter comme on le souhaite, au point qu’on n’a souvent plus besoin d’intervenir souvent
  • Je suis exactement d’accord. J’ai laissé un commentaire similaire ailleurs : le vieil adage selon lequel « il n’y a pas de repas gratuit » reste vrai. Si un LLM pouvait résoudre des problèmes sans intervention humaine, cela voudrait dire que tout le monde pourrait construire le même système sophistiqué avec quelques lignes de prompt, et dans ce cas chaque système perdrait sa différenciation et sa valeur. Si le prompt est un nouveau niveau d’abstraction, alors quand on demande par exemple à Claude « crée-moi une application de prise de notes », des millions de personnes vont entrer le même prompt à faible coût, et on peut alors se demander ce que le prompteur apporte réellement
  • À mon avis, avec le temps, chacun de ces éléments de « goût » pourra lui aussi être de plus en plus formalisé en prompts. Par exemple, un prompt peut guider les modifications de code pour éviter une variabilité inutile et favoriser l’immutabilité quand c’est possible. Un autre peut poser une règle personnalisée pour éviter les logs inutiles, selon une définition précise que j’ai donnée. Quand je relis des changements de code, j’exécute tous ces prompts séparément et je les rassemble dans une sortie MCP structurée. J’applique ensuite ces éléments à l’agent de code pour obtenir des itérations de review automatisée. Si une situation exige d’ajouter du contexte manuellement, je crée un nouveau prompt ou j’étends un prompt existant pour renforcer le système
• Je trouve amusant de voir apparaître des « autorités » dans un domaine qui semble n’avoir que 1 à 2 ans d’existence. C’est un peu comme la version inversée du mème « 10 ans d’expérience dans un langage vieux de 2 ans »
  • Je construis ce qu’on appelle aujourd’hui des « ai agents » depuis la sortie de GPT-3, et beaucoup d’autres ont le même parcours. Cela fait déjà 5 ans, et si aucun expert n’émerge au bout de 5 ans, on peut considérer qu’il n’y a simplement pas d’expert. Cela dit, le mot « agent » est en train de devenir un buzzword, donc son sens s’érode
  • Quand on lit des témoignages du type « j’ai travaillé avec des dizaines d’équipes… », ça paraît tout de même un peu dramatique
• Résumé essentiel : s’il existe une solution prédéfinie, il n’y a pas vraiment besoin d’un agent (par ex. les « patterns » mentionnés dans l’article). En général, les programmeurs recommandent une solution plus simple et plus fiable pour les problèmes qu’un programme peut résoudre. À l’avenir, l’IA deviendra peut-être assez intelligente pour tout résoudre en brute force, mais pour l’instant elle ne fait qu’ajouter de la complexité. Je pense que si les gens s’enthousiasment autant pour les agents, c’est aussi parce qu’ils ont surtout découvert les LLM sous la forme d’assistants de chat. Dans ce contexte, il n’existe souvent pas de solution préétablie et l’interaction est complexe, donc les agents révèlent davantage leur valeur. Exemple : « Trouve le vendredi soir le plus proche et envoie un message à Bob pour lui demander s’il est disponible pour se voir » — il y a une limite à tout préprogrammer pour ce genre de cas. Comme les modes d’interaction avec un assistant deviennent presque infinis, les agents sont alors adaptés
  • Cela fonctionne très bien quand la vérification est plus rapide que le faire soi-même. En revanche, j’ai du mal à faire confiance à l’IA sans validation
• Je me demande pourquoi tant d’exemples finissent par se résumer à « comment envoyer du spam plus vite et mieux »
  • J’ai eu exactement cette impression. On scrape LinkedIn pour trouver des gens, puis on leur envoie du spam par email « personnalisé »
  • On pourrait comparer ça au fait qu’une roue ne tourne pas sans graisse
• C’était vrai fin 2023 ~ début 2024, mais à présent, vers mi-2025, je pense que cela ne s’applique plus à beaucoup de tâches quand on utilise des LLM SOTA. Avant, on appelait surtout les LLM comme des fonctions, mais c’était aussi dû à un mauvais choix d’outil. Aujourd’hui, les LLM de tout premier plan (Gemini 2.5 Pro, Claude 4, etc.) sont vraiment intelligents, avec d’excellentes capacités de « instruction following » et de sélection d’outils. On a toujours besoin d’outils de checklist, de commandes de délégation, de découpage des tâches, etc. Mais la logique qui consiste à écrire des consignes et à définir des commandes — surtout si l’environnement UI permet d’assigner facilement des commandes aux outils — est plus flexible qu’un workflow et constitue un niveau d’abstraction supérieur. Les workflows visuels restent au fond une forme de programmation fragile et difficile à ajuster. C’était impossible il y a 6 à 12 mois, mais cela reste faux si le LLM n’est pas bon. Globalement, il n’y a qu’un petit nombre de modèles qui excellent à la fois en instruction following et en intégration d’outils, ce qui rend l’application d’agents à ces modèles particulièrement avantageuse. Dans les 1 à 2 prochaines années, on verra émerger une tendance de fond autour des agents capables d’utiliser le navigateur et l’ordinateur. Ils s’appuieront aussi sur de bons systèmes de mémoire et sur un « mode démonstration/observation » pour apprendre en enregistrant la manière dont l’utilisateur se sert de l’interface, ainsi que sur des procédures optimisées apprises à partir d’instructions orales ou écrites données par des humains
  • L’arrivée récente des modèles d’agents les plus puissants (Claude Opus 4, etc.) a complètement changé la donne. Il faut toujours un bon contexte, mais leur précision dans le choix des outils est réellement remarquable
  • Les techniques de l’article original consistent pour la plupart à « modéliser le problème comme un graphe de flux de données et à le suivre tel quel ». Aller au-delà de la modélisation et partir du principe que « ça va se débrouiller », ce n’est pas de l’ingénierie, c’est de la foi
• J’ai essayé pendant les trois dernières semaines de faire fonctionner des agents de manière fiable, mais j’ai fini par revenir à des patterns bien plus simples. Les agents actuels donnent l’impression d’être à un stade très précoce de leur évolution, comme une « main à six doigts »
• Quand on voit des choses comme « le coordinateur abandonne si la définition de la tâche n’est pas claire » et qu’on en conclut « dans ce cas, il faut aussi abandonner le coordinateur et revenir à une logique impérative », je pense qu’il est possible qu’un problème de ce type se résolve simplement en écrivant des prompts ou des descriptions d’outils plus précis, et en ajoutant des étapes comme des résumés intermédiaires ou de la compression de contexte LLM. Sans exemple concret de descriptions d’outils/prompts longs et réellement exploitables dans l’article, il est difficile de trancher. Intuitivement, utiliser l’orchestration adaptée à la tâche est la bonne réponse, mais je crois qu’en pratique une orchestration agentique peut être utilisée efficacement sur bien plus de tâches qu’on ne le pense
• Je suis moi aussi d’accord à 100 %. Les agents sont vraiment amusants et parfaits pour expérimenter, mais pour améliorer la productivité réelle, l’essentiel est de bien orchestrer des workflows et des processus spécifiques, et de se concentrer sur les parties que seule l’IA peut faire. Au passage, je recommande aussi l’article d’ai.intellectronica.net sur les workflows IA
• Ce qu’on voit souvent en ce moment, c’est l’intégration des LLM dans des outils d’orchestration de workflows existants afin de construire des systèmes beaucoup plus facilement. L’essentiel de la complexité vient de a) le modèle lui-même (les labos de pointe fournissent désormais des modèles faciles à utiliser), b) la mise en production du workflow (rendue plus simple par les outils de workflow). Comme ces workflows reposent sur des processus métier existants, leur valeur est facilement perceptible et mesurable. Ce pattern devenant fréquent, j’ai même publié un SDK empaqueté spécifiquement pour Airflow (un outil de workflow très populaire).
  https://github.com/astronomer/airflow-ai-sdk

[sto1111]

J’utilise moi aussi actuellement UseDesktop

https://youtu.be/aBkbsvMxP_A?si=uaugxKQEu4ZEz7jq

usedesktop.com

pour créer un agent de type Computer-use, et je suis d’accord sur la plupart des points.

Cet article traite davantage d’une vue d’ensemble que d’astuces vraiment pratiques, donc si je devais ajouter quelques conseils pour développer des agents / workflows agentiques basés sur des LLM : au final, les LLM reposent sur les transformers (c.-à-d. un raisonnement probabiliste ; à partir du token / état actuel, ils ne « comprennent » pas sémantiquement le mot suivant dans le contexte avant de le produire, ils génèrent une sortie de manière probabiliste). Donc, même avec un très bon sys prompt, il arrive souvent qu’ils ne donnent pas la réponse voulue (par ex. on leur demande une réponse au format JSON, mais il leur arrive d’oublier un }), d’où la nécessité d’ajouter systématiquement plusieurs fonctions de repli basées sur des regex.

Et lorsqu’on écrit un sys prompt pour obtenir une sortie structurée, on utilise généralement un modèle non reasoning ; plus le contexte est long, plus les hallucinations surviennent fréquemment, donc il vaut souvent mieux créer plusieurs sys prompt et les chaîner.

Quand on développe un service, divers types d’erreurs peuvent survenir ; l’essentiel est donc de concevoir l’architecture du service de façon modulaire et fault tolerant (par ex. un supervisor agent en async et les autres agents en sync), surtout pour les systèmes agentiques / agents où les sorties inattendues sont fréquentes.
C’est pourquoi, dès le départ, il vaut mieux écrire le code en respectant autant que possible le SRP et de façon déclarative ; je dirais qu’une approche fonctionnelle est préférable (= pas d’effets de bord et un flux intuitif).

Ensuite, selon que vous utilisez les LLM via API ou que vous servez directement le modèle, l’approche diffère. Mais si vous allez servir directement un SLM ou un LLM, il vaut mieux ne pas faire tourner le model serving sur le même serveur que celui qui héberge le backend ; il est préférable, pour la tolérance aux pannes, de séparer les tâches IO bound et les CPU bound tasks (c.-à-d. les tâches nécessitant un GPU, des multiplications matricielles, etc.) sur des serveurs différents (par ex. héberger les CPU bound task sur Runpod).

Il y a encore pas mal d’autres conseils de dev, mais je vais m’arrêter là pour éviter que ce soit trop long.

J’espère que cela pourra être utile à quelqu’un.

[jypark]

Merci beaucoup d’avoir partagé votre précieuse expérience et votre point de vue. L’avis de quelqu’un qui travaille sur le terrain est vraiment d’une grande aide.