Agents IA : comment ça marche, pourquoi ça change tout

TL;DR

Un chatbot repond. Un agent agit : il observe, raisonne, utilise des outils, et boucle jusqu'au resultat.

Les 4 piliers d'un agent : raisonnement, outils, memoire, autonomie.

Le multi-agent permet de decomposer des problemes complexes entre agents specialises.

Les protocoles MCP, A2A et AG-UI structurent l'ecosysteme.

Les risques sont reels : hallucinations amplifiees, injection de prompt, couts incontroles.

Un chatbot repond. Un agent agit.

C'est la difference fondamentale, et c'est ce qui est en train de changer le metier de developpeur.

Depuis fin 2024, on est passe d'une ere ou l'IA generait du texte a une ere ou l'IA execute des taches. Les LLM n'ont pas juste gagne en puissance : ils ont appris a utiliser des outils, a planifier, a verifier leur propre travail. Le mot "agent" est partout. Et pour une fois, ce n'est pas que du marketing.

Cet article est le troisieme de la serie "Comprendre l'IA en 2026". Apres avoir pose les bases des LLM, on attaque le sujet qui change concretement notre quotidien de devs.

Chatbot vs Agent : la vraie difference

Un chatbot, c'est simple : tu lui donnes un input, il te renvoie un output. Une question, une reponse. Il n'a pas de memoire entre les echanges, pas d'acces au monde exterieur, pas de capacite a verifier ce qu'il produit.

Un agent, c'est un LLM entoure d'une boucle de controle. Il recoit un objectif, decompose le probleme, choisit ses outils, agit, verifie le resultat, et recommence si necessaire.

Exemple concret : tu demandes a ChatGPT de corriger un bug. Il te donne un bout de code. C'est a toi de le coller au bon endroit, de lancer les tests, de verifier que ca marche. Tu demandes a Claude Code de corriger le meme bug : il lit ton code source, identifie le fichier concerne, edite la fonction, lance les tests, et si un test casse, il corrige et relance. C'est pas la meme chose.

La boucle agentique

Tout agent repose sur le meme schema fondamental :

       ┌──────────────────────────────┐
       │                              │
   Observe → Raisonne → Agit → Verifie
       │                              │
       └──── Echoue ? Recommence ─────┘

La boucle agentique

Chaque etape a un role precis :

Observer : l'agent collecte le contexte. Il lit des fichiers, interroge une API, analyse un message d'erreur. Il ne part jamais de zero, il commence par comprendre la situation.

Raisonner : c'est la ou le LLM intervient. A partir du contexte, il planifie une approche. Quel outil utiliser ? Dans quel ordre ? Quels sont les risques ? C'est du chain-of-thought applique a des actions reelles.

Agir : l'agent execute. Il appelle une API, modifie un fichier, lance une commande. C'est le moment ou il touche au monde reel, pas juste au texte.

Verifier : l'agent evalue le resultat de son action. Le test passe-t-il ? L'API a-t-elle renvoye le bon code ? Le fichier est-il dans l'etat attendu ? Si non, il retourne a l'etape d'observation avec ce nouveau contexte.

Cette boucle peut tourner plusieurs fois. C'est ca qui differencie un agent d'un simple appel a un modele. L'agent persiste jusqu'a atteindre l'objectif ou detecter qu'il ne peut pas avancer.

Les 4 capacites d'un agent

Raisonnement

Un agent ne se contente pas de predire le prochain token. Il decompose un probleme en etapes, maintient un plan, et ajuste sa strategie en cours de route. Les techniques comme le chain-of-thought ou le tree-of-thought permettent au LLM de "reflechir avant d'agir".

En pratique, ca se traduit par un agent capable de raisonnement : face a un bug, il va d'abord lire les logs, puis formuler une hypothese, puis la tester, plutot que de proposer un correctif a l'aveugle.

Outils (tools/functions)

C'est ce qui donne a un agent ses "mains". Sans outils, un LLM ne peut que generer du texte. Avec des outils, il peut lire et ecrire des fichiers, interroger des bases de donnees, appeler des API REST, lancer des tests, executer du code.

Le mecanisme est standardise : le modele recoit une liste de fonctions disponibles avec leur schema. Quand il decide d'utiliser un outil, il genere un appel structure (nom de la fonction + parametres). C'est le mecanisme de tool use. Le systeme hote execute la fonction et renvoie le resultat au modele.

Memoire

Deux types de memoire coexistent :

Court terme : le contexte de la conversation en cours. L'agent se souvient de ce qu'il a fait, des erreurs rencontrees, des fichiers lus. C'est la fenetre de contexte du LLM.

Long terme : la persistance entre sessions. Un agent peut stocker des informations sur un projet, des decisions architecturales, des patterns recurrents. Il retrouve ce contexte au demarrage d'une nouvelle session.

La memoire long terme est encore un chantier ouvert. Les solutions vont du simple fichier texte aux bases vectorielles, en passant par des systemes de memoire structures. Aucune approche ne domine clairement.

Autonomie

Un agent decide quoi faire sans qu'on lui dicte chaque etape. Tu lui donnes un objectif ("corrige ce bug", "implemente cette feature"), et il determine lui-meme la sequence d'actions.

L'autonomie a des degres. Un agent de code va agir dans le perimetre de ton projet. Un agent de recherche va explorer le web de maniere autonome. Le niveau d'autonomie depend de la confiance qu'on accorde a l'agent et des guardrails mis en place.

Multi-agent : quand un agent ne suffit pas

Certains problemes sont trop complexes pour un seul agent. La solution : plusieurs agents specialises qui collaborent.

Le principe est le meme qu'une equipe de devs. Un agent recherche et collecte de l'information. Un autre planifie l'architecture. Un troisieme implemente. Un quatrieme revoit le code. Chacun a son role, ses outils, son perimetre.

Plusieurs frameworks structurent cette approche :

CrewAI : definit des agents avec des roles, des objectifs et des outils. Les agents collaborent selon un workflow defini ou de maniere autonome.

Anthropic Agent SDK : fournit une base pour construire des agents avec handoff entre agents specialises. Un agent "coordinateur" delegue a des agents specialises selon la tache.

LangGraph : modelise les workflows multi-agents comme des graphes, avec des noeuds (agents) et des aretes (transitions). Permet des workflows complexes avec des boucles et des conditions.

Systeme multi-agent

En pratique, le multi-agent est encore jeune. La coordination entre agents introduit de la complexite, des latences, et des modes d'echec specifiques. Mais sur des problemes bien definis, les gains sont reels.

Les agents qu'on utilise deja

Si tu codes en 2026, tu utilises probablement deja des agents sans forcement les appeler comme ca.

Claude Code : un agent de terminal qui lit ton codebase, edite des fichiers, lance des commandes, et boucle sur les erreurs. Ce n'est pas de l'autocompletion : c'est un agent avec une boucle observe-raisonne-agit-verifie complete.

Cursor : un IDE qui integre un agent capable de naviguer dans ton projet, de comprendre le contexte multi-fichiers, et de proposer des modifications coherentes a travers plusieurs fichiers.

GitHub Copilot Workspace : un agent qui part d'une issue GitHub, analyse le code, propose un plan d'implementation, et genere les modifications. L'humain valide avant le merge.

Devin : un agent de developpement autonome avec son propre terminal, son editeur, son navigateur. Il peut travailler sur des taches de bout en bout avec une supervision humaine minimale.

La difference avec un simple autocomplete, c'est la boucle. Copilot classique predit la prochaine ligne. Un agent Copilot Workspace lit l'issue, analyse le code existant, planifie les changements, et genere un diff multi-fichiers. Deux mondes differents.

Les protocoles qui structurent tout

L'ecosysteme agent se structure autour de protocoles ouverts. Trois meritent qu'on les connaisse.

MCP (Model Context Protocol)

Cree par Anthropic, MCP standardise la maniere dont un agent se connecte a des outils externes. C'est un protocole client-serveur : l'agent (client) decouvre les outils disponibles sur un serveur MCP, et les appelle selon un format uniforme.

L'interet : un outil ecrit une fois fonctionne avec n'importe quel agent compatible MCP. Pas besoin de recoder l'integration pour chaque modele ou chaque framework.

A2A (Agent-to-Agent)

Propose par Google, A2A standardise la communication entre agents. Quand un agent a besoin d'un autre agent pour completer une tache, A2A definit comment ils se decouvrent, negocient les capacites, et echangent des messages.

C'est l'equivalent du HTTP pour les agents : un protocole de communication universel entre agents de fournisseurs differents.

AG-UI (Agent-User Interaction)

AG-UI standardise la maniere dont un agent interagit avec une interface utilisateur. Comment un agent affiche sa progression ? Comment l'utilisateur intervient en cours de route ? Comment on visualise la boucle agentique ?

Ces questions semblent secondaires, mais elles sont critiques pour l'adoption. Un agent opaque qui tourne pendant 5 minutes sans feedback, personne ne lui fait confiance.

Pourquoi la standardisation compte

Sans protocoles communs, chaque fournisseur construit son silo. Les outils ne sont pas portables, les agents ne communiquent pas entre eux, et les developpeurs reecrivent les memes integrations en boucle. Les protocoles ouverts cassent ce schema.

Les risques reels

Les agents ne sont pas magiques, et l'autonomie amplifie les problemes existants des LLM.

Hallucinations en boucle : un LLM qui hallucine dans un chat, c'est embetant. Un agent qui hallucine et agit sur cette hallucination, c'est dangereux. Il peut modifier du code sur la base d'une comprehension fausse, et la boucle agentique risque de propager l'erreur au lieu de la corriger.

Injection de prompt : un agent qui lit des donnees externes (emails, pages web, fichiers utilisateur) est vulnerable aux instructions malveillantes cachees dans ces donnees. L'agent peut etre manipule pour executer des actions non prevues.

Couts incontroles : chaque iteration de la boucle agentique consomme des tokens. Un agent qui boucle sur un probleme insoluble peut generer des couts importants sans produire de resultat. Sans limites explicites, la facture peut surprendre.

Le besoin de guardrails : l'humain doit rester dans la boucle pour les operations sensibles. Les meilleurs systemes agents implementent des niveaux de permission : l'agent agit librement pour les operations sans risque, demande une confirmation pour les operations sensibles, et refuse les operations dangereuses.

Ce n'est pas du pessimisme. C'est de l'ingenierie. On ne deploie pas un systeme autonome sans mecanismes de controle, que ce soit un avion, une voiture, ou un agent IA.

Ce que ca change pour nous

Les agents ne sont pas une feature. C'est un changement de paradigme dans la facon dont on construit des logiciels.

En tant que devs, notre role evolue. On passe moins de temps a ecrire du code ligne par ligne, et plus de temps a definir des objectifs, a concevoir des architectures, a evaluer des resultats. Le dev devient superviseur, architecte, et juge de qualite.

Ca ne veut pas dire que le code disparait. Ca veut dire que la maniere dont on le produit change fondamentalement. Et c'est probablement le plus grand shift dans notre metier depuis l'open source.