Le RAG est mort, vive l’Agent : Comment votre base de connaissance a appris à agir
Il est 2H14 du matin. Un endpoint de monitoring remonte un timeout HTTP 504 sur le site d’un client e-commerce. Quelque chose identifie la cause dans les logs Nginx, redémarre le pool PHP-FPM incriminé, vérifie que les pages répondent correctement, et envoie un rapport d’incident horodaté. Durée totale : moins de 90 secondes. Sans qu’on ait posé une seule question.
Ce « quelque chose », c’est un agent IA. Et il ne ressemble en rien au chatbot qu’on interroge depuis un navigateur. L’exemple est technique. Il pourrait être médical, financier, logistique. Ce qui change, c’est l’architecture.
Dans le premier volet de cette trilogie, on a vu comment on aligne un modèle : comment on lui infuse des valeurs pour qu’il se comporte de façon prévisible et utile. La question de ce second article est différente, et plus immédiate : maintenant qu’on dispose d’un modèle bien aligné, comment lui donne-t-on des mains ? Comment passe-t-on d’une IA qui répond à une IA qui agit ?
La réponse passe par une rupture avec l’architecture qui a dominé 2023 et 2024 (le RAG) et l’émergence d’un paradigme nouveau : l’agent.
Le RAG, ou la bibliothécaire brillante qui ne sort jamais de sa salle
Ce que le RAG a accompli, et pourquoi ce n’est plus suffisant
Le Retrieval-Augmented Generation a été une révolution réelle. Son pipeline complet mérite d’être compris dans le détail, mais la promesse centrale était simple : ancrer les réponses du modèle dans des documents réels, privés, actualisés, et diviser les hallucinations par deux à cinq selon les implémentations. En 2023, c’était exactement ce dont les entreprises avaient besoin pour commencer à faire confiance aux LLM sur leurs propres données.
Sauf que le RAG est structurellement passif. Il lit. Il récupère. Il synthétise. Mais il attend toujours qu’on lui pose une question. Et s’il manque une information dans la base vectorielle, il échoue ou invente, exactement le problème qu’il était censé résoudre.
La limite que personne ne formule clairement
Même avec des fenêtres de contexte massives (le Cache-Augmented Generation qui permet d’injecter des centaines de pages en une seule fois), le problème de fond reste entier. « Lire tout le manuel » n’est pas « savoir réparer la machine ». Connaître l’intégralité de la documentation Nginx ne suffit pas pour diagnostiquer pourquoi un pool PHP-FPM s’effondre en production à 23h47. Il faut interroger les logs en temps réel, formuler une hypothèse, tester, observer le résultat, ajuster. C’est une boucle, pas une recherche.
Le RAG est une bibliothèque extraordinairement bien indexée. L’agent est un collaborateur qui utilise cette bibliothèque parmi d’autres outils, et qui sait quand sortir du bâtiment.
Une précision s’impose ici, pour éviter le malentendu que le titre provocateur pourrait créer : le RAG n’est pas mort. Il est rétrogradé au rang d’outil parmi d’autres. Dans la plupart des agents en production, il subsiste sous forme d’une ressource MCP ou d’un outil de récupération de contexte que l’agent appelle quand il en a besoin, pas comme architecture centrale, mais comme composante. C’est cette bascule qu’il faut comprendre avant d’aller plus loin.
Anatomie d’un agent : ce qui se passe vraiment dans la boucle
Le pattern ReAct : Reason, Act, Observe
Le framework cognitif dominant des agents actuels s’appelle ReAct (Yao et al., 2022). Son principe est d’une élégance brutale : plutôt que de produire une réponse à une question, le modèle entre dans un cycle itératif de quatre temps qui se répète jusqu’à résolution de l’objectif.
Avant d’entrer dans le détail, une formule conceptuelle pour fixer les idées, dans l’esprit de l’équation DPO du premier article, mais sans les mathématiques :
Agent = LLM (Raisonnement)
+ Outils (Actions)
+ Mémoire (Contexte)
+ Planning (Boucle ReAct)
Supprimez l’un de ces quatre termes, et vous n’avez plus un agent : vous avez soit un chatbot, soit un script, soit une API. C’est leur combinaison qui crée quelque chose de qualitativement nouveau.
Pensée : le modèle raisonne à voix haute sur l’état du problème. Pas une réponse, une délibération interne. « Les logs signalent un timeout 504. Je dois identifier si c’est Nginx, PHP-FPM, ou la base de données avant d’agir. »
Action : le modèle appelle un outil. Pas une génération de texte, une fonction. nginx_read_logs(lines=200). L’outil peut être une API, une requête SQL, une commande shell, un endpoint REST.
Observation : le modèle reçoit le résultat et l’intègre à son contexte. Ce résultat devient une nouvelle donnée qui modifie le raisonnement suivant.
Pensée suivante : le cycle repart avec ce nouveau contexte, jusqu’à ce que la tâche soit résolue ou qu’une condition d’arrêt soit atteinte.
┌─────────────────────────────────────────────────┐
│ OBJECTIF │
└─────────────────────┬───────────────────────────┘
│
▼
┌───────────────┐
┌───▶│ PENSÉE │ Raisonnement interne
│ │ (Reason) │ "Que dois-je faire ?"
│ └───────┬───────┘
│ │
│ ▼
│ ┌───────────────┐
│ │ ACTION │ Appel d'outil MCP
│ │ (Act) │ get_logs() / restart() / ...
│ └───────┬───────┘
│ │
│ ▼
│ ┌───────────────┐
│ │ OBSERVATION │ Résultat réel
│ │ (Observe) │ retourné par l'outil
│ └───────┬───────┘
│ │
│ Tâche résolue ?
│ Non ──┘ Oui ──▶ RÉPONSE FINALE
│ + log horodaté
└────────────────────────────────────
Langage du code : PHP (php)Voici ce que donne ce cycle sur un cas réseau réel, un diagnostic de perte de connectivité sur le VLAN IoT d’un UniFi :
💭 PENSÉE "La plainte concerne le VLAN IoT depuis 18h.
Je vérifie l'état des ports sur le switch concerné."
⚡ ACTION unifi_get_port_status(switch="USW-Pro-24", vlan=20)
👁 OBS. Port 14 en erreur : taux de CRC élevé depuis 18h32.
💭 PENSÉE "CRC élevé suggère un problème physique ou un équipement
défaillant. Je vérifie quel appareil est sur ce port."
⚡ ACTION unifi_get_client(port=14)
👁 OBS. Serveur de fichiers, MAC xx:xx:xx:xx.
💭 PENSÉE "Je redémarre le port pour tester si le problème persiste
avant de conclure à une défaillance matérielle."
⚡ ACTION unifi_restart_port(switch="USW-Pro-24", port=14)
👁 OBS. CRC retombé à zéro. Connectivité restaurée.
✅ RÉPONSE Port 14 présentait des erreurs CRC depuis 18h32.
Redémarrage effectué, connectivité restaurée.
Surveiller le serveur de fichiers : défaillance matérielle possible.
Langage du code : PHP (php)Ce que cette séquence illustre : l’agent n’a pas cherché dans une base documentaire. Il a agi sur l’infrastructure, observé les effets réels, et construit sa réponse depuis le monde réel. Le RAG n’aurait rien pu faire ici : il n’y avait rien à récupérer, seulement quelque chose à diagnostiquer.
Du « Chat » au « Task » : la bascule mentale
La rupture que l’agent impose n’est pas technique en premier lieu, elle est cognitive. On ne pose plus des questions. On confie des objectifs.
Avant : « Explique-moi ce que signifie une erreur CRC dans un switch réseau. » Après : « Mon VLAN est instable depuis 18h. Trouve pourquoi et corrige. »
La première formulation appelle une réponse. La seconde appelle un plan d’action, une exécution, une vérification, et un rapport. Ce n’est plus une transaction, c’est une délégation.
C’est un changement de posture aussi profond que celui qui sépare « chercher une information sur Google » de « confier une mission à un collaborateur ». Et comme avec un collaborateur, la qualité du résultat dépend autant de la clarté de l’objectif que des capacités de l’agent.
La mémoire à long terme : apprendre de l’expérience
Un agent sans mémoire est condamné à réinventer la roue à chaque session. Les frameworks modernes comme LangGraph ou Mem0 permettent de stocker les succès, les échecs, et les patterns identifiés, dans une base vectorielle dédiée, distincte de la base de connaissances métier. C’est un principe que j’ai exploré en détail dans le contexte de la mémoire persistante de Claude Code : la mémoire long terme d’un agent n’est pas un luxe, c’est ce qui transforme un outil ponctuel en collaborateur qui progresse.
Concrètement : si l’agent a déjà diagnostiqué trois fois un pool PHP-FPM qui s’effondre sous charge sur le même serveur, il apprend à vérifier ce point en priorité la quatrième fois. Si une migration Odoo a échoué avec un message d’erreur particulier, il mémorise la séquence de rollback qui a fonctionné. C’est la différence entre un prestataire qui redécouvre votre infrastructure à chaque intervention et un collaborateur qui en connaît les habitudes, et les failles récurrentes.
MCP : le système nerveux qui connecte l’agent au monde
Le problème qu’il résout
Avant le Model Context Protocol, connecter un LLM à un système externe nécessitait d’écrire un connecteur sur mesure pour chaque API, dans chaque application, pour chaque modèle. OpenAI avait son format de function calling, Anthropic le sien, LangChain ses propres abstractions. Un connecteur SSH écrit pour GPT-4 ne fonctionnait pas avec Claude sans réécriture complète.
MCP, proposé par Anthropic fin 2024, dont la spécification technique est publique et rapidement adopté comme standard de facto par l’industrie (OpenAI, Google, Microsoft ont suivi dans les mois qui ont suivi), règle ce problème avec une analogie immédiate : c’est l’USB-C de l’IA. Un protocole standardisé qui permet à n’importe quel modèle compatible de se connecter à n’importe quel serveur MCP, sans adaptation spécifique à chaque paire modèle-outil.
Ce que ça change concrètement
Un serveur MCP expose deux types d’interfaces : des outils (des fonctions que l’agent peut appeler pour modifier le monde) et des ressources (des données qu’il peut lire pour observer l’état du monde). Cette distinction n’est pas anodine. Un outil agit. Une ressource informe. Et dans un déploiement responsable, on ne confie pas les mêmes niveaux de permission à ces deux catégories.
Dans un écosystème d’hébergement web ou d’administration système, un serveur MCP peut exposer de façon standardisée des fonctions comme nginx_read_logs(lines) pour lire les dernières entrées d’accès ou d’erreur, php_fpm_restart(pool) pour redémarrer un pool applicatif, mysql_kill_query(thread_id) pour interrompre une requête bloquante, wp_deactivate_plugin(slug) pour isoler un plugin WordPress fautif, ou odoo_restart_worker(pid) pour relancer un worker bloqué. L’agent n’a pas besoin de connaître la syntaxe exacte de chaque outil ni les chemins de chaque fichier de log. Il appelle des fonctions nommées en langage clair : le serveur MCP se charge de la traduction vers les commandes sous-jacentes.
WebMCP pousse cette logique jusqu’aux interfaces web elles-mêmes, ouvrant la voie à des agents capables d’interagir avec n’importe quel site comme le ferait un humain, sans scraping fragile, sans API dédiée, sans accord préalable avec le propriétaire du service. Le domaine reste cependant très mouvant en 2026 : les protections anti-bot s’adaptent rapidement, et l’efficacité réelle dépend fortement des capacités de vision du modèle utilisé. Claude 3.5/4, GPT-4o et leurs successeurs s’en sortent bien sur des interfaces stables et structurées. Sur des pages dynamiques ou fortement obfusquées, les résultats restent inégaux. C’est une promesse en cours de concrétisation, pas une solution clé en main.
L’agent comme chef d’orchestre
Ce qui émerge de cette architecture est fondamentalement nouveau : l’agent n’est plus un générateur de texte augmenté d’une base de connaissances. Il est un orchestrateur qui dispose d’une palette d’outils hétérogènes (lecture, écriture, calcul, communication, action système) et qui choisit lesquels appeler, dans quel ordre, en fonction de l’objectif qu’on lui a confié.
Ce n’est pas du function calling sophistiqué. C’est une architecture de délégation.
L’agent dans l’écosystème réel : du concept au cas d’usage
Le scénario du serveur planté : déroulé complet
Reprenons l’accroche de l’introduction et déroulons-la pas à pas, pour montrer chaque brique de l’architecture en action sur une infrastructure réelle.
Il est 2h14 du matin. Un endpoint de monitoring remonte un timeout HTTP 504 sur le site d’un client e-commerce. L’agent (tournant en arrière-plan sur le serveur de supervision) reçoit l’alerte et entre dans sa boucle.
💭 PENSÉE "Timeout 504 à 2h14. Nginx répond mais renvoie une erreur
de gateway. Probable problème PHP-FPM ou base de données.
Je vérifie les logs Nginx en premier."
⚡ ACTION nginx_read_logs(type="error", lines=50)
👁 OBS. Multiples "connect() to unix:/run/php/php8.2-fpm.sock
failed (11: Resource temporarily unavailable)"
💭 PENSÉE "PHP-FPM sature ou est planté. Je vérifie l'état du pool
avant de redémarrer."
⚡ ACTION php_fpm_status(pool="www")
👁 OBS. Pool saturé : 128/128 workers actifs, queue 47 requêtes
en attente. Aucun worker disponible depuis 4 minutes.
💭 PENSÉE "Saturation franche, pas un crash. Le redémarrage du pool
est une action réversible et justifiée. Je l'exécute."
⚡ ACTION php_fpm_restart(pool="www")
👁 OBS. Pool redémarré. 0/128 workers actifs, queue vidée.
⚡ ACTION http_probe(url="https://client.com", expected_status=200)
👁 OBS. HTTP 200. Temps de réponse : 312ms. Site opérationnel.
💭 PENSÉE "Incident résolu. Je documente et notifie."
📋 RAPPORT "Incident 2h14 : Timeout 504 résolu.
Cause : saturation pool PHP-FPM (128/128 workers).
Action : redémarrage pool www.
Durée d'interruption estimée : 4 minutes.
Site opérationnel depuis 2h16.
[Voir les logs complets]"
Langage du code : PHP (php)Durée totale : moins de 90 secondes depuis la détection initiale. L’agent a raisonné, agi, vérifié, documenté, et alerté, sans qu’on lui ait posé une seule question. C’est exactement ce que le RAG ne peut pas faire.
L’auto-correction de code : le cas du plugin WordPress
Un second cas d’usage, plus quotidien et peut-être plus révélateur encore de ce que l’agent change dans la pratique.
Une mise à jour automatique vient de casser la page d’accueil d’un site WordPress client. L’éditeur de thème ne signale aucune erreur YAML, mais le front est blanc. Dans un workflow classique : se connecter au serveur, consulter les logs PHP, identifier le plugin fautif, le désactiver via WP-CLI ou phpMyAdmin, vérifier le rendu, documenter. Une boucle manuelle qui peut prendre trente minutes à 3h du matin sur un site qu’on ne maintient pas quotidiennement.
Avec un agent disposant d’un accès aux logs PHP et d’un outil WP-CLI : il lit les erreurs des dix dernières minutes, identifie le plugin incriminé dans la stack trace, le désactive, sonde le front pour vérifier la restauration, et soumet un rapport avec le diff pour décision avant toute action irréversible (rollback complet, restauration de sauvegarde).
Ce dernier point n’est pas un détail. C’est l’architecture human-in-the-loop qui rend l’agent fiable en production. On y revient dans la section suivante.
Remarquez d’ailleurs dans le scénario du serveur planté la notification finale : elle ne se contente pas d’informer : elle propose un lien vers les logs complets et laisse ouverte la question de l’investigation post-incident. L’agent résout l’urgence, mais remet le contrôle à l’humain pour ce qui implique une décision consciente (comprendre pourquoi le pool a saturé, ajuster la configuration, investiguer une attaque potentielle). Le rapport devient une interface de handover, pas juste un log.
Les zones d’ombre : ce que personne ne dit sur les agents en production
Le coût réel : quand l’agent vide le portefeuille en tokens
C’est le tabou du domaine. Une boucle ReAct sur une tâche complexe génère des dizaines d’appels successifs, chacun avec un contexte qui s’accumule : les pensées précédentes, les observations reçues, les outils disponibles. Sur les API cloud (Claude, GPT-4o), une session d’agent non maîtrisée peut coûter plusieurs dizaines d’euros en quelques minutes sur une tâche mal définie.
Trois leviers pour contrôler ce coût. Le prompt caching, d’abord : dans une boucle ReAct, le système prompt, la liste des outils disponibles et les instructions de l’agent restent identiques d’un appel à l’autre, seul le contexte accumulé (pensées, observations) varie. Un agent bien architecturé qui met en cache ces parties stables peut diviser sa facture par dix sur les tâches longues, rendant l’économie du déploiement cloud réellement viable. Les modèles locaux ensuite, mais c’est précisément l’objet du troisième article de cette série. Les conditions d’arrêt explicites enfin : un budget de tokens maximum, un nombre d’itérations plafond, une validation humaine obligatoire au-delà d’un certain seuil d’action.
La règle pratique est simple : ne jamais laisser un agent tourner sans budget défini. C’est l’équivalent de laisser une carte bancaire sans plafond à un assistant zélé et enthousiaste.
Le risque de boucle infinie
Un agent peut se retrouver dans une impasse logique. L’action A échoue. L’agent tente B pour contourner. B échoue aussi. L’agent revient à A avec une légère variation. Et boucle, jusqu’à épuisement du budget ou timeout forcé.
Les frameworks modernes comme LangGraph gèrent ce risque via des compteurs d’itération, des détecteurs de répétition de pattern, et des états d’erreur explicites qui forcent l’agent à remonter l’échec plutôt que de persévérer. La logique est proche de celle des hooks dans Claude Code : des garde-fous d’exécution qui interceptent les comportements déviants avant qu’ils ne deviennent coûteux. Sur une orchestration maison sans ces mécanismes, la boucle infinie n’est pas un cas limite, c’est un scénario probable dès que la tâche sort des sentiers battus.
La sécurité : donner les clés du serveur à un agent
C’est la question que tout praticien doit se poser avant de connecter un agent à une infrastructure réelle. Un agent qui dispose d’un accès SSH, d’un accès en écriture au dépôt GitHub, d’une connexion à la base de données, c’est un vecteur d’attaque potentiel si le modèle est manipulé via une prompt injection indirecte : un log système contenant des instructions déguisées, une réponse d’API piégée, un fichier de configuration malveillant dans la base RAG. Contrairement à l’injection directe (un utilisateur qui tente de manipuler le modèle dans le prompt), l’injection indirecte arrive par les données que l’agent lit, et c’est précisément ce qui la rend dangereuse : l’agent fait confiance à ses sources par construction. Ce risque figure en bonne place dans l’OWASP LLM Top 10, et les LLM en production en sont déjà victimes dans des contextes moins critiques.
Les bonnes pratiques ne sont pas négociables. Principe du moindre privilège : chaque serveur MCP n’expose que les outils strictement nécessaires à l’agent concerné. Isolation réseau : les serveurs MCP sans accès direct à l’internet. Journalisation exhaustive : toutes les actions de l’agent horodatées et stockées. Et validation humaine obligatoire pour toute action irréversible : suppression de données, modification de règles firewall, rollback de base de données, communication externe.
Le sandboxing n’est pas une option. C’est l’architecture de base d’un déploiement qui ne finit pas en catastrophe.
L’alignement 2.0 : de la politesse à la fiabilité des actions
Dans le premier article de cette série, on a vu comment RLHF et DPO permettent d’aligner un modèle sur des valeurs, le triptyque HHH. Mais l’alignement d’un agent pose une exigence qualitativement différente et plus haute : on ne veut plus seulement qu’il soit poli, on veut qu’il soit fiable dans ses actions.
Un modèle sycophante qui invente une réponse textuelle est gênant. Un agent sycophante qui exécute une action pour valider l’enthousiasme de l’utilisateur (sans vérifier les prérequis, sans évaluer les effets de bord) peut supprimer une table de base de données parce qu’on lui a demandé « de nettoyer les données obsolètes ». La distinction entre intention et instruction n’a jamais été aussi critique.
La règle de classification qui fonctionne en pratique : distinguer les actions réversibles des actions irréversibles. Redémarrer un service, désactiver un plugin, recharger une configuration : réversible, l’agent peut agir avec log. Supprimer des données, modifier des règles firewall, envoyer une communication externe, effectuer un déploiement en production : irréversible, validation humaine explicite obligatoire, sans exception.
Ce n’est pas de la méfiance envers l’agent. C’est de l’ingénierie responsable. Et c’est d’ailleurs l’état de l’art en 2026 : les meilleurs agents en production ne sont pas fully autonomous, ils sont semi-autonomes. Ils agissent seuls sur ce qui est rapide, réversible et bien défini ; ils sollicitent une validation humaine sur ce qui est lent, irréversible ou ambigu. L’autonomie complète n’est pas un objectif en soi, c’est un point d’arrivée qu’on atteint progressivement, au fur et à mesure que la confiance dans l’agent se construit sur des cas d’usage maîtrisés.
La fin de l’interface chat, et la question qui reste
La thèse de cet article peut se résumer en une phrase : le chatbot est une interface de transition. On lui pose des questions parce qu’on n’a pas encore appris à confier des objectifs.
L’agent marque la bascule, non pas vers la science-fiction de l’IA consciente, mais vers quelque chose de plus immédiat et de plus profond : une IA qui s’intègre dans les processus plutôt que dans les conversations. À terme, l’interaction « ouvrir une fenêtre de chat, taper une question, lire une réponse » disparaîtra pour une grande partie des cas d’usage professionnels. L’agent sera un service d’arrière-plan qui surveille, anticipe, agit, et ne remonte à la surface que quand il a besoin d’une validation ou qu’il a produit un résultat. Comme le système électrique : présent partout, invisible tant qu’il fonctionne.
Mais cette vision soulève une question que le prochain article devra traiter frontalement. Si un agent a accès à tes logs serveur, à ton dépôt de code, à ta base de données, à ta messagerie, si c’est lui qui orchestre l’ensemble de tes processus critiques, fais-tu confiance à un service cloud américain pour faire tourner ce cerveau ? Ou préfères-tu qu’il tourne sur du hardware que tu contrôles, dans ta salle serveur, sous ta législation, sans que chaque requête parte traverser l’Atlantique ? C’est une question que Mistral et les armées françaises se sont posée avant toi, et que le mouvement open source est en train de rendre concrètement soluble.
C’est la question de l’open source local. Et elle est moins technique qu’elle n’y paraît. C’est une question de souveraineté.
Deuxième volet d’une trilogie sur l’IA moderne. Premier volet : Du RLHF au DPO, la quête de l’alignement parfait. Troisième volet à paraître : Le choix de l’indépendance, l’Open-Source local.