IA agentique : Ce que signifie vraiment qu'une IA puisse naviguer sur le Web, exécuter du code et utiliser votre ordinateur

Pendant la majeure partie de sa vie commerciale, l'IA était une machine à questions-réponses. Vous entriez du texte ; vous obteniez du texte. Le modèle n'avait aucune mémoire au-delà de la conversation en cours, aucune capacité à agir sur le monde, et aucun moyen de vérifier si ce qu'il disait était vrai. Cette époque est révolue.

L'expression « IA agentique » est utilisée de manière vague — parfois pour désigner un chatbot doté de quelques outils, parfois pour désigner un logiciel totalement autonome capable d'effectuer des semaines de travail sans supervision. La réalité en 2026 se situe quelque part entre les deux, et comprendre où exactement nécessite de décomposer trois concepts distincts : l'utilisation d'outils (tool use), l'orchestration et l'autonomie.

Ce que fait réellement une IA utilisant des outils

Le changement fondamental a été de donner aux modèles de langage la capacité d'appeler des fonctions. Au lieu de générer uniquement du texte, un modèle peut émettre un appel structuré — « search the web for X », « run this Python snippet », « fetch the contents of this URL » — et recevoir le résultat avant de continuer sa réponse. C'est ce qu'OpenAI a formalisé sous le nom de « function calling » en 2023 et ce qu'Anthropic appelle « tool use » dans Claude.

La mécanique est simple : on présente au modèle un ensemble d'outils disponibles (décrits dans son system prompt), il génère un appel d'outil (tool call) dans sa sortie, et l'application hôte exécute cet appel et renvoie le résultat dans le contexte. Le modèle continue alors son raisonnement avec les nouvelles informations. De l'extérieur, on dirait que l'IA « navigue » ou « exécute du code » — de l'intérieur, il s'agit du même moteur de prédiction du prochain token, juste avec une fenêtre de contexte plus riche.

Les outils auxquels un modèle a accès déterminent ce qu'il peut affecter. Les agents de production actuels ont généralement accès à : la recherche web, des interpréteurs de code (environnements Python sandboxés), la lecture/écriture de fichiers, des API de calendrier et d'e-mail, des requêtes de base de données, et de plus en plus l'utilisation de l'ordinateur (computer use) — la capacité de contrôler une application GUI en générant des clics de souris et des actions clavier.

Orchestration : comment fonctionnent les tâches multi-étapes

Un seul appel d'outil n'est pas un agent. Un agent, c'est ce qui se produit lorsqu'un modèle peut planifier une séquence d'appels d'outils, observer les résultats à chaque étape et ajuster son plan en fonction de ce qu'il trouve. C'est ce qu'on appelle la boucle ReAct (Reason + Act), et c'est le modèle architectural derrière la plupart des systèmes d'agents de production en 2026.

En pratique, la boucle ressemble à ceci : le modèle reçoit un objectif de haut niveau (« réserver le vol le moins cher de Londres à Tokyo pour jeudi prochain »), génère un plan, exécute la première étape (recherche de vols), observe le résultat, affine son approche et continue jusqu'à ce que l'objectif soit atteint ou qu'il rencontre une impasse. Chaque itération consomme des tokens et du temps — une tâche complexe peut nécessiter 20 à 50 appels d'outils avant d'être terminée.

L'orchestration multi-agent va plus loin. Plutôt qu'un seul modèle fasse tout, un framework comme LangGraph, CrewAI ou le SDK agent d'Anthropic achemine les sous-tâches vers des sous-agents spécialisés : un agent cherche sur le web, un autre écrit du code, un troisième examine la sortie pour détecter les erreurs. L'agent orchestrateur — souvent appelé le « planificateur » — décide quel sous-agent invoquer, transmet le contexte et assemble le résultat final.

L'avantage pratique est le parallélisme et la spécialisation. Le coût pratique est la complexité : les erreurs se cumulent, le contexte se perd entre les limites des agents, et le débogage d'une trace multi-agent est nettement plus difficile que le débogage d'un seul appel API.

Computer Use : l'outil le plus ambitieux

Fin 2024, Anthropic a publié la capacité de computer use dans Claude, suivie par des fonctionnalités similaires dans d'autres modèles de pointe. L'idée : donner à l'IA une capture d'écran d'un bureau, lui permettre de générer un clic ou une pression de touche, prendre une nouvelle capture d'écran, répéter. Aucune API nécessaire — le modèle interagit avec le logiciel comme le ferait un humain.

C'est important car la plupart des logiciels professionnels n'ont pas été conçus avec des API à l'esprit. La capacité à faire fonctionner des systèmes ERP hérités, naviguer dans des portails gouvernementaux complexes ou interagir avec des applications de bureau sans couche d'intégration ouvre des opportunités d'automatisation qui étaient auparavant impossibles sans des outils RPA (Robotic Process Automation) personnalisés.

L'état actuel est capable mais fragile. Les modèles gèrent bien les tâches GUI courantes — remplir des formulaires, naviguer dans les menus, copier des données entre applications. Ils rencontrent des difficultés avec les dispositions dynamiques, les CAPTCHA, les flux d'authentification multi-facteurs et toute interface qui change de manière inattendue. La latence est également significative : une tâche qui prend 30 secondes à un humain peut prendre 3 à 5 minutes à un agent de computer use en raison de la boucle capture d'écran-action-capture d'écran.

Où l'autonomie échoue

Le véritable défi des systèmes agentiques n'est pas la capacité technique — c'est la fiabilité sur de longues périodes de tâches. Un modèle qui est précis à 95 % à chaque étape d'une tâche en 20 étapes terminera correctement la tâche complète seulement 36 % du temps (0,95²⁰). Ce problème de « cumul d'erreurs » est la principale raison pour laquelle les déploiements en production d'agents en 2026 nécessitent encore des points de contrôle humains pour tout ce qui a des conséquences.

L'autre problème difficile est l'autorisation. Lorsqu'un agent d'IA a simultanément accès aux e-mails, au calendrier, aux fichiers et aux API bancaires, le rayon d'explosion d'une erreur — ou d'une attaque par injection de prompt, où un contenu malveillant dans une page Web incite l'agent à entreprendre des actions non intentionnelles — devient considérable. La meilleure pratique actuelle est des permissions minimales : donner à l'agent uniquement l'accès nécessaire à la tâche spécifique, tout journaliser et exiger une confirmation humaine avant les actions irréversibles.

La mémoire est une troisième contrainte. La plupart des agents aujourd'hui fonctionnent dans une seule fenêtre de contexte — généralement de 128K à 1M tokens. Ils n'ont pas de mémoire persistante des sessions précédentes à moins que vous ne construisiez explicitement un système de récupération. Des solutions architecturales comme MemGPT et la fonction Memory d'OpenAI abordent ce problème au niveau de la couche applicative, mais il n'existe pas encore de solution générale.

Ce qui est réellement livré

Malgré les limitations, les agents sont en production à grande échelle. GitHub Copilot Workspace termine des tâches de codage multi-fichiers de manière autonome. Salesforce Agentforce traite les tickets de service client de bout en bout, y compris la consultation de l'historique des comptes et le traitement des remboursements. L'IA de Notion effectue des tâches de recherche — rassembler des sources, résumer, rédiger — sans que l'utilisateur reste dans la boucle à chaque étape.

Le modèle émergent de ces déploiements : les agents sont les plus fiables lorsque la tâche est bien définie, le domaine est étroit, les erreurs sont récupérables et le nombre d'étapes requises est limité. Ils sont les moins fiables dans les tâches ouvertes et exploratoires où l'objectif est ambigu ou l'environnement imprévisible.

La prochaine frontière est celle des agents persistants et multi-sessions — des systèmes qui se souviennent du contexte sur plusieurs semaines, gèrent leur propre planning et traitent des workflows récurrents sans être re-sollicités. Des entreprises comme Cognition (Devin), Reflection et plusieurs startups en mode furtif sont les plus avancées dans ce domaine. Que cela produise des travailleurs autonomes fiables ou une nouvelle classe de défaillances logicielles difficiles à déboguer dépend des décisions d'ingénierie prises en ce moment.