C’est quoi, un agent IA ?

On voit passer beaucoup de promesses autour des agents IA. Le genre de discours qui raconte que “l’agent va faire tourner toute votre entreprise tout seul” et “remplacer dix personnes dans l’équipe”. Et évidemment, si vous ne l’utilisez pas dès demain matin, vous allez même perdre votre emploi la semaine prochaine. Influenceur, sors de ce corps.

Je force un peu le trait, mais il faut bien compenser un peu le discours de certains :). Le mot agent est devenu un mot magique. On le colle sur un produit, un workflow, une démo, un chatbot un peu amélioré, et hop, ça donne l’impression qu’on a remplacé un humain.

Sauf que si on veut comprendre ce que c’est, il faut retirer vernis marketing et influenceur. Un agent IA, ce n’est pas une usine autonome qui tourne 24h/24 dans un coin. Je le définirais plutôt comme ça : un agent est un système qui utilise un modèle d’IA pour observer une situation, décider des prochaines étapes, utiliser des outils si besoin, puis recommencer en fonction du résultat obtenu.

Observer, décider, agir, observer à nouveau. C’est cette boucle qui change beaucoup de choses. On ne demande plus seulement une réponse à un chat. On demande d’avancer dans une tâche, d’atteindre un objectif.

Revenons un peu en arrière

Au départ, il y a les modèles de langage (LLM). Les modèles GPT permettaient de “prédir la suite probable d’un texte” (je prends un raccourci, mais l’idée de base est là). Ça marchait bien, et on s’est aperçu qu’en ajoutant un peu de contexte avant, ça permettait d’influencer le fond et la forme de la réponse.

À partir de là, il n’a pas fallu longtemps pour voir arriver la naissance de ChatGPT. C’est encore un modèle GPT dans l’arrière-boutique, mais cette fois avec une interface web par-dessus et un gros prompt système pour créer ce semblant de conversation. Et c’était déjà impressionnant. On pouvait demander une explication, reformuler un texte, générer du code, résumer un document, etc. Mais le fonctionnement restait assez simple : une demande, une réponse. Puis une autre demande, une autre réponse.

Plus tard, on voit apparaitre de premières connexions avec des outils, et même un protocole pour standariser cela (MCP). Les agents arrivent.

Ce qui change avec un agent

Un agent IA ajoute trois choses fondamentales. La première, c’est la capacité à utiliser des outils. L’agent peut lire des fichiers, les modifier, lancer une commande, chercher une information, suivre une todo-list, … Ça dépend évidemment de l’environnement qu’on lui donne, mais l’idée est là : il ne produit plus seulement une réponse directe, il peut agir dans cet environnement.

Agent : Je vais récupérer tes rendez-vous de la journée sur ton Google Calendar.

La deuxième, c’est la capacité à enchaîner plusieurs étapes. On ne lui demande plus uniquement “réponds à cette question”, mais plutôt “atteins ce résultat”. Il peut inspecter un fichier, constater qu’il manque une information, lire un autre fichier, lancer un test, corriger une erreur, puis revenir avec le résultat.

Agent : Je met à jour l’outil que tu m’a demandé. C’est fait. Oh, ça ne compile plus. Ok je viens de voir qu’il faut modifier ce fichier pour l’adapter avec la nouvelle façon de faire. Cette fois, c’est bon.

La troisième, c’est une forme de mémoire de travail. Parfois, c’est simplement l’état de la tâche en cours : à quelle étape il est, ce qu’il a déjà essayé, ce qu’il a observé, les erreurs rencontrées. Mais cette mémoire suffit déjà à créer une différence importante avec un simple prompt isolé. L’agent peut suivre un plan.

Agent : Je viens de comparer trois sources, j’ai gardé les points communs en tête, je vais maintenant pour voir générer un résumé.

Dans un usage technique, c’est très parlant. On peut demander “corrige ce bug”. Un chat classique va souvent répondre avec des hypothèses et du code à copier. Un agent, lui, peut lire le code existant, modifier un fichier, exécuter les tests, voir que ça casse ailleurs, ajuster, recommencer cette boucle trois fois jusqu’à avoir des tests OK, puis expliquer ce qu’il a fait.

On passe de “je te réponds” à “je peux avancer dans la tâche avec toi”. L’agent décide quoi faire en fonction de l’état, et il agit.

Comment on utilise un agent, concrètement ?

Le premier contact, pour beaucoup de monde, peut venir des chats web comme ChatGPT, Claude, Perplexity et bien d’autres. Aujourd’hui, ils ne cherchent plus à seulement répondre tout de suite. Ils ont beaucoup plus d’outils et de capacités - des connecteurs, du raisonnement, de la recherche profonde, etc. Ils peuvent analyser un document, faire une multitude de recherches sur le web, puis produire une analyse détaillée.

La frontière entre un agent et un chat devient un peu plus floue d’ailleurs. Ce qui est intéressant à observer maintenant, c’est si le chat / le service permet de réaliser des tâches, d’atteindre des objectifs. Et dans quel environnement.

Là où ça prend davantage forme, à mon sens, c’est avec les outils qui ont accès à un environnement permettant une plus grande liberté. Cursor, Claude Code, OpenAI Codex, et d’autres outils du même genre peuvent lire un projet sur notre machine, chercher dans les fichiers, créer ou modifier du code, lancer des commandes, puis se corriger selon le résultat.

La différence est assez marquante. Dans un chat web classique, on peut demander : “explique-moi comment réorganiser ce projet” ou “écris-moi un script pour faire ça”, et on devra ensuite le faire manuellement. En espérant avoir donné tous les bons détails et fichiers. Avec un agent lancé dans le dossier du projet, on va directement lui demander d'effectuer l’action, et il cherchera les informations lui-même. Il ne travaille plus seulement sur une description du problème, il travaille dans le contexte réel.

Note : j’ai pris l’exemple d’un projet de code, mais on peut également imaginer un dossier avec un ensemble de fichiers de comptabilité, d’idées pour une chaîne YouTube, etc. Cela reste des fichiers et du texte, c’est très facilement manipulable par un agent.

Les avantages d’un agent

On a vu qu’un agent peut utiliser des outils, premier bon avantage. On pourra lui demander de lire ou envoyer des mails, chercher une information sur le web, lister les retours clients sur Zendesk, etc. A priori tout ce qu’on pouvait faire à la main et qui contient une interface web / api / cli.

Autre gros avantage que l’on a aussi vu, c’est la possibilité d’enchaîner des étapes. Même si elles ne sont pas très complexes, c’est un gain d’autonomie. On n’est plus obligé de micro-manager un chat en lui disant étape par étape quoi faire. Ici, l’agent peut atteindre un objectif en trouvant lui-même le chemin.

Dit autrement, on pourrait parler de travailler dans l’incertitude. Si on veut créer un script ou une automatisation, on doit connaitre chaque étape au moment de créer cette automatisation, et il faudra que ça se passe bien comme on l’a prévu, sinon ça casse. L’agent, lui, peut réussir à s’adapter en cours de route.

Au final, l’agent a cette capacité de s'adapter. Et c’est peut-être là son plus gros avantage. On en revient à la boucle : observer, décider, agir, observer à nouveau.

Les limites à garder en tête

Un agent peut coûter plus cher à utiliser, même si ce n’est pas une règle absolue. Un agent léger, avec peu d’outils et peu d’allers-retours, peut rester raisonnable. Mais dans l’idée, un agent est plus autonome, il décide quoi faire, il explore, utilise une commande, lit un fichier ou un résultat, etc. Et tout ça, eh bien ça consomme plus de tokens. Avant, une partie de ces actions étaient du côté de l’humain alors que maintenant, l’agent doit le verbaliser.

Il y a aussi un côté moins prévisible. Un agent peut décider de faire dix étapes au lieu de trois. De charger un énorme fichier que l’on avait pas prévu. De reboucler car il n’est pas encore satisfait d’après sa compréhension du succès. On n’est plus sur un simple une demande, une réponse.

Il faut donc surveiller le contexte, les quotas, les tokens, et parfois simplement la pertinence de le lancer pour une petite tâche. Sinon, à la fin on obtient une facture salée (si on passe par l’API) ou une limite atteinte prématurément (paie-t-on l’abonnement supérieur pour continuer ?). Sachant qu’en plus, tout ça bouge beaucoup. C’est par exemple au tour d’Anthropic de mettre le feu à la communauté en ce moment avec un abaissement des limites et des nouvelles contraintes autour l’exécution autonome des agents (claude -p pour ceux qui suivent).

À côté de cela, il y a également la question du contrôle. Plus on donne d’outils à un agent, plus il peut faire de choses utiles et plus il peut faire de bêtises : modifier le mauvais fichier, envoyer une requête au mauvais endroit, mal comprendre une consigne, ou bien pire. La suppression de la base de données de production et des backups d’une entreprise par exemple ?

Ce qu’un agent n’est pas

Un agent IA, en lui-même, ce n’est pas forcément un système qui tourne tout seul 24 h/24. Si vous voulez quelque chose qui se réveille tous les matins, surveille une boîte mail, lance une analyse, envoie un rapport et recommence demain, il faut quelque chose autour.

Ça peut être un serveur. Un cron. Un outil comme n8n. Un outil d’orchestration. Un setup avec OpenClaw. Un Agentic OS (sûrement le prochain mot à la mode). Peu importe la forme exacte, mais il faut un mécanisme qui déclenche le travail, garde l’état, gère les erreurs, relance si besoin, stocke les résultats.

L’agent peut être une brique dans ce système. Par exemple, n8n peut déclencher un workflow toutes les heures ou selon un événement, récupérer des données, puis appeler un modèle d’IA pour analyser. Là, l’agent ou le modèle intervient à une étape précise. Mais l’autonomie globale vient surtout de l’orchestration qu’il y a autour. Autre exemple avec OpenClaw, c’est lui qui maintient en vie les agents avec un système de heartbeat et une communication par les messageries type Telegram, Discord, etc.

C’est une distinction importante. Sinon on finit par appeler “agent” n’importe quel automatisme un peu sexy.

Est-ce qu’on en a vraiment besoin ?

Pas toujours. Justement parce que parfois on a besoin d’une automatisation plus que d’un agent IA. Un truc prédictif qui est un enchainement de tâches définies et d’outils selon un déclencheur, par exemple. C’est “moins vendeur”, “moins à la mode”, mais c’est ce qui réponds au besoin.

“À chaque fois qu’un retour client arrive sur notre outil de support, on veut répondre automatiquement qu’on s’en occupe, puis l’ajouter dans sur notre board d’équipe et nous notifier sur Teams”.

Nul besoin d’un agent ici, un workflow sur n8n ou similaire fera l’affaire. Et vraiment si besoin, on peut y glisser un noeud IA (pour analyser le message par exemple), ce qui coûtera moins cher que si un agent faisait tout.

Et je pense que c’est le point le plus pratique à garder en tête. Un agent IA est intéressant quand la tâche est moins prédictible, demande plus d’adaptation ou d’autonomie. Qu’on ne connait pas le chemin. L’exploration pour corriger un bug est un bon exemple qu’on a vu précédemment, une boucle d’écriture/critique/réécriture d’un script de vidéo YouTube pourrait en être un autre.

Et puis parfois, peut-être même qu’un simple prompt pourrait suffire. Si on garde une bibliothèque de côté et/ou quelques fichiers d’instructions, on pourrait dans certains cas revenir à un mode de chat demande/réponse plus classique quand il n’y a pas un long chemin à parcourir.

Plusieurs questions à se poser donc, sauf si on n’a aucun problème avec l’argent et l’énergie :

• est-ce qu’on connait le chemin ? est-ce qu’il faudra s’adapter ?
• est-ce qu’on est sur une boucle d’actions / observations ?
• est-ce qu’on veut de la reproductibilité ?
• est-ce qu’une simple demande sur un chat suffirait ?

Bref

Un agent IA, ce n’est pas un nouveau collègue virtuel totalement autonome. C’est d’abord un modèle d’IA placé dans un système qui lui permet d’observer, de décider, d’utiliser des outils, puis de réagir au résultat pour continuer.

C’est puissant, surtout quand la tâche dépasse le simple échange question-réponse. Mais ce n’est pas magiquement autonome, fiable, économique ou nécessaire. Il faut encore un cadre, des permissions, dans certains cas une orchestration, et surtout un peu de jugement.

Donc avant de mettre un agent partout, je trouve plus sain de comprendre ce que c’est, puis partir du besoin. C’est ma culture produit qui parle. Parfois, l’agent est exactement la bonne brique. Parfois, un prompt suffit. Parfois, un script ou workflow fera mieux le travail. Le besoin avant la solution.