● Journal du Net 📅 16/04/2026 à 10:51

Data Science 👤 Olga Dudko

🏷️ Tags : rag rte

Les promesses des agents IA sont partout. Avant de vous lancer, trois problèmes concrets que les démonstrations ne dévoilent pas — et qui peuvent coûter très cher. Les vidéos se multiplient. Sur LinkedIn, YouTube, dans les newsletters tech : les agents IA font tout à votre place. Claude Cowork en est l'exemple le plus visible en ce moment — et les promesses sont séduisantes. Gérer vos emails. Trier vos fichiers. Générer un rapport complet à partir d'un enregistrement vocal. Remplir un tableur. Piloter votre ordinateur depuis votre téléphone pendant que vous êtes en réunion. Chercher des informations sur le web, les synthétiser, les mettre en forme. Tout ça, de façon autonome, sans intervention humaine. L'effet est réel. La puissance aussi. Et le réflexe qui suit est naturel : identifier sa propre tâche répétitive et tenter de l'automatiser. C'est exactement là que les choses se compliquent. Avant l'agent, comprendre ce qu'est une automatisation Déployer un agent IA sans avoir jamais construit une automatisation simple, c'est conduire sur autoroute sans avoir appris à passer les vitesses. Ce n'est pas une question de niveau technique — c'est une question de compréhension du mécanisme. Une automatisation, dans sa forme la plus simple, c'est une série d'instructions conditionnelles : si ceci se produit, alors faire cela. Un email reçu déclenche une action. Un fichier déposé dans un dossier génère une notification. Un formulaire rempli alimente un tableur. Ces mécanismes de base sont accessibles à n'importe quel professionnel non-technique, avec des outils comme Zapier ou Make. Et les construire, même une seule fois, change profondément la façon dont on envisage ce qu'un agent peut — ou ne peut pas — faire. Parce qu'un agent IA, c'est une automatisation qui raisonne. Il prend des décisions à chaque étape, choisit le chemin, adapte ses actions au contexte. C'est ce qui le rend puissant. C'est aussi ce qui le rend imprévisible — et coûteux — quand on ne comprend pas ce qui se passe sous le capot. Premier problème : le coût qui s'emballe Ce que les démonstrations ne montrent jamais, c'est la facture. Un agent IA traite une quantité importante d'informations pour décider quoi faire à chaque étape. Chaque action — lire un fichier, analyser une page, rédiger une ligne, vérifier un résultat — consomme des tokens, l'unité de base qui détermine le coût d'utilisation du modèle. Et parce que les agents travaillent étape par étape, en enchaînant des dizaines de micro-décisions pour accomplir une tâche apparemment simple, les coûts s'accumulent rapidement — souvent bien au-delà de ce qu'on avait anticipé. C'est un peu comme un assistant personnel qui facture chaque pensée. Plus vous lui confiez de tâches complexes, plus la note monte. Des utilisateurs de Claude Cowork ont ainsi vu leurs crédits s'épuiser en quelques heures, sur des workflows qu'ils pensaient anodins — simplement parce qu'ils n'avaient pas mesuré le volume réel de traitement impliqué. Avant de déployer un agent, la bonne question n'est pas « est-ce que ça marche ? » — c'est « combien d'actions va-t-il enchaîner, et à quel coût unitaire ? » Deuxième problème : la latence invisible Le deuxième problème est moins visible, mais tout aussi concret : les agents sont lents. Pas parce que le modèle est limité — mais parce que la nature même du raisonnement séquentiel prend du temps. Chaque étape attend la précédente. Chaque décision est précédée d'une analyse. Imaginez une équipe d'assistants qui se passent des notes pour chaque petite décision : même si chaque note ne prend que quelques secondes, l'enchaînement peut transformer une tâche de deux minutes en un processus de vingt. Le JDN l'a documenté dans ses propres tests : sur le cas du bilan comptable dans Google Sheets, l'agent a peiné quinze minutes là où un humain aurait été plus rapide. Ce n'est pas une anomalie — c'est le comportement normal d'un agent qui navigue par vision écran dans une application web non connectée, capturant l'écran à chaque étape, inférant une structure, agissant prudemment. Un autre exemple parlant : demander à un agent de réserver un billet d'avion. La tâche semble simple. En pratique, l'agent doit ouvrir un navigateur, charger le site, analyser la page, remplir les champs un par un, vérifier chaque résultat, gérer les pop-ups, naviguer entre les étapes de paiement. Ce que vous feriez en cinq minutes peut lui en prendre vingt-cinq — avec un risque d'échec à chaque maillon. La latence n'est pas un bug. C'est une caractéristique structurelle qu'il faut avoir intégrée avant de décider ce qu'on confie à un agent. Troisième problème : l'agent n'est pas toujours le bon outil C'est peut-être le problème le plus sous-estimé : parfois, une automatisation simple suffit — et déployer un agent est non seulement inutile, mais contre-productif. Prenons un cas concret. Vous recevez chaque semaine un fichier Excel de votre équipe commerciale. Vous voulez que les données soient automatiquement intégrées dans votre CRM. Un agent IA peut techniquement faire ça — en lisant le fichier, en analysant les colonnes, en décidant comment mapper les données, en effectuant les appels nécessaires. Mais une automatisation classique, configurée une fois en vingt minutes, fait exactement la même chose — plus vite, sans coût de tokens, sans latence, sans risque d'erreur de raisonnement. La règle est simple : quand la tâche est répétitive, prévisible et bien définie, l'automatisation traditionnelle est presque toujours plus efficace. L'agent apporte de la valeur là où il y a de la variabilité, de l'ambiguïté, des décisions à prendre. Le confondre avec un outil universel, c'est utiliser un marteau-piqueur pour enfoncer un clou. Ce qui change quand on comprend avant de déployer Un dirigeant qui demande à son équipe de déployer un agent IA sans comprendre comment il interagit avec les systèmes existants ne pilote pas un projet. Il signe un chèque en blanc — en temps, en ressources de calcul, en crédibilité interne quand le projet accroche. Ce n'est pas une question de compétence technique. C'est une question de compréhension des mécanismes fondamentaux : comment un agent perçoit son environnement, par quelle interface il agit, ce que chaque action lui coûte réellement. Des distinctions qui ne s'apprennent pas en regardant des démonstrations — parce que les démonstrations ne montrent jamais les conditions dans lesquelles elles ont été préparées. Comprendre le système, c'est savoir qu'un agent desktop excelle sur les fichiers locaux mais n'est pas conçu pour manipuler une application web en direct. Que Zapier ou Make s'appuient sur des connexions stables là où la navigation par écran tâtonne pixel par pixel. Qu'un script simple insère une ligne dans un tableur sans consommer un seul token. Ces distinctions existent. Elles sont accessibles. Mais elles supposent qu'on ait pris le temps de comprendre ce qu'on utilise — avant de commencer, pas après trois heures de murs. Le chèque en blanc a une alternative. Comprendre ce qu'on signe avant de le signer.

🔗 Lire l'article original 👁️ 0 lecture