La différence entre le « buzz » autour des agents autonomes et les agents IA qui fonctionnent réellement en production

• Contrairement aux attentes selon lesquelles le boom des agents IA arriverait en force en 2025, il existe dans les environnements de production réels des limites très concrètes
• En raison de l’accumulation des erreurs et du problème de coût des tokens, l’automatisation complète de workflows à plusieurs étapes est actuellement impossible
• La plupart des systèmes d’agents qui réussissent reposent impérativement sur un domaine strictement limité ainsi que sur une approbation humaine ou un processus de vérification
• La vraie difficulté n’est pas tant la performance de l’IA elle-même, mais la conception des outils et des systèmes de feedback que l’agent peut utiliser efficacement
• En 2025, les startups/entreprises qui mettront en avant des agents entièrement autonomes devraient se heurter à de gros obstacles lors du déploiement réel et de la montée en charge

---

Pourquoi je parie qu’il n’y aura pas d’agents IA en 2025 (alors même que j’en développe)

• Le battage médiatique autour de l’idée que 2025 sera l’année des agents IA est omniprésent
• L’auteur a directement construit, au cours de l’année écoulée, divers systèmes d’agents IA fonctionnant dans de vrais environnements de production
• C’est à partir de cette expérience de terrain qu’il adopte une position sceptique face à la supposée « révolution des agents »

Expérience de construction de divers systèmes d’agents

• Agents de développement : génération de composants React à partir du langage naturel, refactorisation de code legacy, gestion automatisée de documentation API, génération de fonctions à partir de spécifications, etc.
• Agents data & infrastructure : traitement de requêtes complexes et de migrations, automatisation DevOps multi-cloud
• Agents qualité & processus : correction automatique du lint, génération de code de test, automatisation de code reviews et de Pull Requests détaillées
• Ces systèmes apportent une vraie valeur et font gagner du temps, mais cette expérience est aussi à l’origine d’un regard critique sur le battage médiatique

Résumé clé : trois vérités froides sur les agents IA

1. Accumulation du taux d’erreur : plus il y a d’étapes, plus le taux de réussite chute de manière exponentielle. Il est difficile d’atteindre les standards de production (99,9 % et plus)
2. Fenêtre de contexte et coûts : à mesure que la conversation s’allonge, le coût des tokens augmente de façon quadratique, ce qui fait s’effondrer la viabilité économique
3. Difficulté de conception des outils et du feedback : plus que les limites techniques, le principal défi est la conception d’outils et de systèmes de feedback utilisables par l’agent

La réalité mathématique de l’accumulation des erreurs

• Les workflows autonomes à plusieurs étapes sont irréalisables à l’échelle réelle de l’exploitation à cause de l’accumulation des erreurs
• Par exemple, même avec 95 % de fiabilité à chaque étape, sur 20 étapes le taux de réussite final n’est que de 36 % (exigence de la production : 99,9 % ou plus)
• Même en supposant une fiabilité élevée, la probabilité d’échec augmente fortement à mesure que le nombre d’étapes grandit
• En pratique, on ne cherche pas à tout automatiser entièrement : on conçoit plutôt des systèmes avec validation indépendante et points de rollback à chaque étape, ainsi que vérification humaine
• Schéma typique des systèmes d’agents qui réussissent : contexte clairement limité, tâches vérifiables, implication humaine dans les points de décision importants

Structure des coûts des tokens et limites économiques

• Le coût en tokens nécessaire pour maintenir la fenêtre de contexte et la conversation devient une réalité non économique à mesure que le système passe à l’échelle
• Les agents conversationnels doivent à chaque fois traiter tout l’historique de la conversation, ce qui fait grimper les coûts de façon quadratique à mesure que les tours s’accumulent
• Une conversation sur 100 échanges peut coûter à elle seule 50 à 100 dollars en tokens, ce qui fait s’écrouler l’économie du système à grande échelle
• À l’inverse, une approche stateless avec un agent de génération fonctionnelle à slot unique, sans besoin de contexte, est plus avantageuse en termes de coûts et de scalabilité
• Les agents de production les plus efficaces ressemblent davantage à des outils intelligents à objectif clair qu’à des systèmes « conversationnels »

Le mur de la conception des outils et des systèmes de feedback

• Le vrai obstacle dans le développement d’agents hautement productifs, c’est la capacité de conception d’outils, largement sous-estimée par les équipes existantes
• La précision du tool calling s’est améliorée, mais l’enjeu décisif reste la manière de résumer efficacement des états et résultats complexes pour les renvoyer en feedback à l’agent
• Exemples :
  • lorsqu’une tâche ne réussit que partiellement, il faut déterminer quelle quantité d’information et quel type de résumé sont nécessaires
  • par exemple, si un résultat de requête contient 10 000 lignes, il faut concevoir une abstraction de type « succès, 10 000 lignes, seulement les 5 premières » pour permettre à l’agent de comprendre l’état
  • en cas d’échec d’un outil, il faut ajuster la quantité d’informations de récupération et éviter de polluer le contexte
• Le cœur des agents de base de données qui ont réellement réussi : fournir un feedback structuré permettant à l’agent de prendre de vraies décisions
• Dans la réalité, l’IA ne fait qu’environ 30 % du travail ; les 70 % restants relèvent des compétences d’ingénierie traditionnelles, comme le feedback des outils, la reprise, et la gestion du contexte

Les limites de l’intégration aux systèmes réels

• Même si les problèmes de fiabilité et de coût étaient résolus, l’intégration avec le monde réel constituerait encore un autre mur
• Les systèmes d’entreprise réels ne présentent pas des API cohérentes ; ils embarquent une complexité imprévisible liée au legacy, aux erreurs exceptionnelles, aux mécanismes d’authentification qui changent, aux limites variables et aux exigences de conformité
• Un véritable agent de base de données nécessite toujours de la programmation classique : gestion du pool de connexions, rollback de transactions, respect des réplicas en lecture seule, timeouts de requêtes, logs, etc.
• La promesse selon laquelle « l’IA intégrera toute la stack de manière totalement autonome » se heurte à la réalité dès qu’on passe à la mise en œuvre

Les schémas qui fonctionnent réellement

• Principes communs aux systèmes d’agents qui réussissent
  1. Agent de génération d’UI : l’expérience utilisateur est relue en dernier ressort par un humain (l’IA ne gère que la complexité de la conversion langage naturel → React)
  2. Agent de base de données : les opérations destructrices sont toujours validées par un humain (l’IA ne fait que la conversion SQL, le contrôle de la préservation des données reste humain)
  3. Agent de génération de fonctions : comportement limité à des spécifications claires (pas d’état, pas d’effets de bord, pas d’intégrations complexes)
  4. Automatisation DevOps : l’IA génère le code d’infrastructure, mais le déploiement, la gestion de version et la reprise restent dans les pipelines existants
  5. Agent CI/CD : chaque étape est conçue avec des critères de réussite clairs et des mécanismes de rollback
• Résumé du pattern : l’IA gère la complexité, l’humain conserve le contrôle, et la fiabilité est assurée par l’ingénierie traditionnelle

Perspectives de marché et prévisions

• Les startups qui misent sur des agents entièrement autonomes seront les premières à se heurter à des problèmes de rentabilité
• Même si un workflow en 5 étapes donne une excellente démo, les entreprises réelles en exigent souvent plus de 20, et se retrouvent donc face à une limite mathématique
• Les entreprises qui se contentent d’ajouter un agent IA à un logiciel existant risquent de connaître une stagnation de l’adoption faute d’intégration réelle
• Les véritables gagnants seront les équipes qui, dans un domaine clairement limité, n’appliquent l’IA qu’aux tâches difficiles et gardent les décisions importantes ainsi que les conditions de garde-fou côté humain
• Le marché devrait apprendre, à travers une expérience coûteuse, la différence entre une « IA qui marche bien en démo » et une « IA réellement fiable »

Principes souhaitables pour construire un système d’agents

• Définir des frontières claires : délimiter précisément le rôle de l’agent et les zones de handoff vers l’humain ou les systèmes existants
• Concevoir pour l’échec : en cas d’erreur de l’IA, une structure de rollback et de reprise est indispensable
• Vérifier la viabilité économique : concevoir la structure en tenant compte du coût par interaction et de la montée en charge (le stateless est plus économique que le stateful)
• Privilégier la fiabilité à l’autonomie : un système cohérent inspire plus confiance aux utilisateurs qu’un système qui accomplit parfois des miracles
• Construire sur des bases solides : ne confier à l’IA que les parties difficiles (interprétation de l’intention, génération, etc.), et laisser le reste (exécution, gestion des erreurs, etc.) au logiciel traditionnel

Les vraies leçons tirées de l’expérience de terrain

• L’écart entre « ça fonctionne en démo » et « ça tient à grande échelle en production » est immense
• La fiabilité des agents, l’optimisation des coûts et la complexité d’intégration restent des problèmes majeurs encore non résolus dans toute l’industrie
• L’expérience concrète de construction et le partage honnête des retours terrain sont essentiels au progrès du secteur
• Plus il y aura de praticiens pour discuter de méthodologies raisonnables et de cas d’échec réalistes, plus les chances de succès globales augmenteront

[GN⁺]

Avis Hacker News

• J’ai déjà discuté avec un ingénieur en production IA chez Amazon, et selon lui, aucune entreprise n’utilise aujourd’hui uniquement de l’IA générative dans les interactions directes avec les clients ; toutes les réponses automatiques reposent sur des technologies plus anciennes, non génératives, car les problèmes de fiabilité de l’IA générative sont encore trop importants pour mettre en jeu la réputation d’une entreprise

  • Avant, je m’intéressais beaucoup aux agents qui combinaient des techniques symboliques de « vieille IA » et du machine learning traditionnel, mais j’ai surtout travaillé sur des réseaux neuronaux d’avant les transformers ; au final, on commence toujours par construire un système avec intervention humaine, puis on collecte des données d’évaluation et d’entraînement ; ensuite, le système prend en charge une partie du travail, ce qui améliore aussi la qualité du reste ; en particulier pour les tâches « subjectives », il faut absolument évaluer aussi les systèmes symboliques ; si un système doit être entraîné, alors l’évaluation est inévitable

  • En réalité, beaucoup d’entreprises tech déploient déjà de l’IA générative dans le support client en chatbot temps réel ; je connais par exemple Sonder et Wealthsimple ; si le LLM ne parvient pas à répondre à une requête, la conversation est immédiatement transférée à un agent humain

• Un point qui n’a pas encore été abordé concerne la fenêtre de contexte (context window) ; dans leur domaine d’expertise, les humains peuvent gérer un contexte pratiquement « quasi infini » ; les modèles peuvent en partie dépasser leurs limites avec des données d’entraînement plus vastes et plus diverses, mais je ne pense pas que ce soit une vraie solution ; aujourd’hui, les gens doivent compresser leur propre contexte dans le prompt, ce qui, dans une langue souple comme l’anglais, ressemble plus à de l’incantation ou à de la divination qu’à de l’ingénierie ; j’ai l’impression qu’on perd une grande partie de l’information au lieu d’avoir une approche déterministe

  • Chez l’humain, « contexte » et « poids » ne sont pas séparés de manière fixe ; avec le temps, les expériences et leurs résultats modifient continuellement mes propres « poids », alors que dans l’architecture des LLM, les poids sont en lecture seule, donc c’est impossible

  • Je suis sceptique sur l’idée que les humains disposent vraiment d’une fenêtre de contexte aussi immense ; quand je résous des problèmes complexes, je me heurte souvent à cette limite proprement humaine de « fenêtre de contexte » ; je me demande s’il existe des exemples concrets du contraire

• Mon expérience avec les outils d’IA a été globalement positive ; c’est très utile pour déléguer de petites tâches quand j’ai besoin de souffler, ou pour structurer et lancer le travail ; mais le sujet du coût arrive très vite ; par exemple, utiliser Claude Code sur une grosse codebase revient à environ 25 $ pour 1 à 2 heures, et si on ajoute de la correction automatisée, on monte jusqu’à 50 $/h ; il y a un arbitrage entre vitesse, précision et coût ; les agents récents se situent encore à un point mal défini de ce triangle, donc les expérimentations sont intéressantes, mais il reste selon moi un vrai risque

  • En étant un peu cynique, le modèle où le LLM se re-prompt en permanence pour corriger ses propres erreurs, ainsi que l’approche « pas besoin de RAG ! balancez simplement tout le code dans une fenêtre de contexte d’1M de tokens », correspond au fond parfaitement à un business model facturé au token

  • Une idée à laquelle je réfléchis en ce moment consiste à faire produire dès le départ plusieurs brouillons de commits par l’IA, puis à filtrer et retoucher manuellement ou automatiquement les résultats ; plus le travail est important, plus un petit écart initial a des chances de ruiner le résultat global ; donc même avec le SOTA actuel, laisser des agents tenter plusieurs pistes en parallèle réduit le temps de refactor manuel ; j’ai déjà écrit à ce sujet sur GitHub

  • J’ai envie de demander si c’est un service par abonnement

• Les workflows humains en plusieurs étapes comportent généralement des checkpoints de validation, parce que même les humains ne sont pas précis à plus de 99 % ; à l’avenir, les agents auront eux aussi des procédures de vérification intégrées à leurs sorties, et seront entraînés à les franchir avant de passer à l’étape suivante ; on pourra aussi faire en amont une évaluation des risques du type « ici, il faut au moins 99 % de précision »

  • Claude Code s’interrompt constamment avant de poursuivre une tâche pour demander à l’utilisateur s’il faut continuer, et affiche aussi à l’avance les modifications proposées ; c’est efficace pour éviter le gaspillage de tokens et le travail inefficace

  • Beaucoup d’applications devront aussi être repensées pour correspondre à cette structure ; à mon avis, l’architecture microservices va redevenir populaire parce qu’elle se marie bien avec les LLM

• Je suis d’accord avec l’idée que « le vrai problème n’est pas la capacité de l’IA, mais la conception d’outils et de systèmes de feedback que les agents peuvent réellement utiliser efficacement » ; je restais en observation sans trop y croire, faute de savoir comment le marché allait réagir, puis j’ai rejoint une toute petite startup spécialisée dans la création d’agents ; en 5 mois, je suis passé du scepticisme à l’adhésion puis à la conviction ; en limitant très fortement le périmètre du sujet et en se concentrant sur le tooling nécessaire au travail du modèle, on obtient des taux d’achèvement élevés ; il y a une réticence naturelle face au caractère non déterministe, mais avec un excellent tooling et un périmètre toujours plus étroit, ça devient en pratique tout à fait exploitable ; le tooling paraît difficile en soi, mais je pense qu’on peut le résoudre correctement ; je suis optimiste pour l’avenir

• Je pense que tous ces problèmes peuvent être résolus ; simplement, beaucoup de startups ne s’y concentrent pas parce qu’elles sont en compétition pour atteindre rapidement de l’ARR ; l’idée que les agents soient moins utiles que promis n’est pas totalement fausse, mais en pratique c’est un problème d’ingénierie ; avec un autre angle d’attaque, je pense que ça peut fonctionner (personnellement, je suis plutôt du côté du RL) ; par exemple, il faut un bon vérificateur (verifier) ; pour beaucoup de tâches, vérifier est plus facile que faire directement ; même avec 5 résultats générés en parallèle à 80 % de précision, on a 99,96 % de chances qu’au moins un soit correct, et le vérificateur peut le choisir ; même en situation multi-étapes, cela devient mathématiquement avantageux ; c’est une approche différente de celles vues jusqu’ici, et l’article mentionne aussi le paradigme du workflow en 3 à 5 étapes, ce qui colle bien à la réalité ; il faut voir apparaître davantage de modèles de ce type

  • Je pense qu’on peut objecter que, dans beaucoup de tâches, la vérification est en réalité plus difficile que la tâche elle-même ; dans le QA logiciel notamment, ce raisonnement a souvent servi de justification à des réductions d’effectifs, avec pour résultat une baisse de qualité ; le vérificateur devient extrêmement difficile à construire parce que le nombre de combinaisons possibles entre le système et les états du monde extérieur explose ; dans ce type d’environnement complexe, les LLM sont séduisants pour prendre en charge le travail répétitif et pénible, comme mocker des dépendances ou préremplir des données, mais dès qu’on veut un test de validation vraiment significatif, on exige qu’il soit toujours correct à 100 %, ce qui finit par nécessiter un autre vérificateur pour chaque précondition ; si au final chaque étape doit être à 100 %, la probabilité cumulée diminue ; les humains, eux, testent surtout prudemment certains cas précis sans chercher à tout vérifier parfaitement (le white-box testing est bien plus courant que le black-box) ; si les LLM produisent beaucoup de code, l’opérateur doit au final comprendre l’ensemble du code pour faire une vérification white-box, et donc le temps gagné se réduit à nouveau ; pour l’instant, c’est le LLM qui produit, et c’est moi qui dois corriger toutes les erreurs, ce qui réduit ma confiance et me fait perdre davantage de temps ; dans certains cas, on peut contourner le problème en adaptant l’interface aux attentes du LLM, mais ce n’est pas généralisable ; hors du logiciel, la vérification est souvent tout simplement impossible (par exemple : « sélectionner les 5 startups de jeux vidéo les plus prometteuses »), car il n’existe pas de validation objective ; si on confie aveuglément ce genre de domaines à une machine plutôt qu’à une personne, on s’expose à des dégâts irrattrapables

  • Je me demande s’il est légitime de supposer que les cinq générations seraient indépendantes les unes des autres

  • C’est vrai ; en pratique, il est efficace de laisser plusieurs agents essayer, de répéter plusieurs fois et d’appliquer diverses solutions ; j’ai moi-même vu des cas où une méthode recevait un feedback négatif, puis une autre approche réussissait

• Il est surprenant qu’une seule personne (ou une équipe minuscule) ait réussi à créer plus de 12 agents IA réellement en production pour le développement, le DevOps, les data operations, etc. ; vu le taux d’échec des startups, il est déjà difficile de créer « un » bon produit, alors 12, c’est impressionnant ; de notre côté aussi, il nous a fallu deux ans pour qu’un outil data stack + agent IA comme Definite commence à vraiment tenir la route, et cela ne date que d’il y a six mois, Definite

  • En réalité, cela ne veut pas dire 12 produits indépendants ; cela signifie plutôt avoir construit 12 outils à usage très spécifique, utilisés au travail selon les besoins ; comme le dit le thème général de l’article, un agent n’est utile que s’il se concentre sur un objectif très simple et très clair

  • Le fait d’en avoir construit plus de 12 tout en gardant un poste à temps plein pendant trois ans paraît tout de même un peu étrange

• Moi aussi, je développe des automatisations agentiques/IA pour mon travail ; les agents de coding open-ended sont juste une mauvaise idée ; des checkpoints de validation humaine, un espace de recherche réduit, et des questions/prompts très spécifiques (par exemple : cet e-mail contient-il une facture OUI/NON ?) sont bien plus réalistes ; je comprends le désir d’avoir des agents entièrement autonomes, mais la technologie n’en est pas encore là ; personnellement, je ne touche pas à la génération de contenu (texte, images, code), parce que ça finira forcément par exploser

  • Moi aussi, avec des frameworks d’agents et du chat coding (codage basé sur la communication), j’ai réduit ma charge de travail d’environ 50 % ; j’ai constaté des gains réels avec GPT ; mais il y a inévitablement une erreur environ une fois sur dix ; à mon avis, tant qu’on ne changera pas fondamentalement l’architecture des LLM, ce taux d’erreur ne sera pas corrigé ; à ce stade, j’espère simplement que la hype n’érodera pas la confiance des développeurs, car je suis convaincu que des systèmes bien plus robustes finiront par émerger ; les gains de productivité sont déjà assez visibles pour qu’on puisse recruter beaucoup moins qu’avant dans une équipe ; la courbe d’apprentissage sur des sujets variés a aussi énormément baissé parce que les LLM compensent la dégradation de la qualité de Google Search ; dans les workflows automatisés, l’élément le plus important est un orchestration framework capable de faire prendre en charge certaines tâches humaines par les LLM ; le LLM devrait aussi signaler son propre niveau de confiance, et si le pourcentage de confiance est faible, la tâche devrait immédiatement revenir à un humain ; avec de bons tests, des garde-fous, etc., le remplacement de l’humain est tout à fait envisageable au moins sur les tâches non critiques ; l’objectif n’est pas de remplacer les personnes, mais d’automatiser le travail pour réduire la taille des équipes ; par exemple, je suis convaincu qu’un jour, dans le grand e-commerce, les LLM traiteront les descriptions produit, la vérification d’images, les fautes de frappe, les incohérences entre image et texte, autant de tâches aujourd’hui faites par des humains

  • Je suis globalement d’accord, mais en procédant ainsi, ce qu’il reste au final pourrait n’être qu’un « simple système de workflow très cher » ; on peut se demander si les LLM sont vraiment nécessaires pour faire des choses qui étaient déjà possibles avec les technologies précédentes

  • Je suis d’accord aussi ; aujourd’hui, le meilleur terrain pour les agents, c’est « un périmètre étroit, peu de risque, des tâches répétitives et ennuyeuses » ; comme exemple, j’ai partagé ici mon expérience d’usage d’agents pour des tâches d’assistance autour de markdown de dev-log

  • Il est vrai que la validation humaine est la plus fiable pour créer des checkpoints, mais il existe aussi d’autres méthodes, comme les tests unitaires ou la validation ad hoc de l’ensemble du système

• Je pense en réalité que l’auteur devrait être encore plus optimiste sur les agents autonomes qu’il ne l’est aujourd’hui ; 90 % de ce qu’on fait maintenant était impossible début 2024 ; il ne faut pas sous-estimer la courbe de progrès

• Je pense pareil ; il y a aussi ce billet de blog connexe ; la différence essentielle est que le HITL (Human in the loop) réduit bien les erreurs, alors que le HOTL (Human out of the loop) crée au contraire des problèmes