Je vais dire tout haut ce que tout le monde pense : si votre système se contente de chercher des documents et de paraphraser les résultats, ce n’est pas un agent. C’est un moteur de recherche avec une interface en langage naturel.
Vous avez sacrifié la précision pour la généralisation, et gagné en échange l’excitante possibilité d’hallucinations. Mais il n’y a pas d’agentivité, pas d’autonomie, aucune capacité à vraimentfairequoi que ce soit au-delà de retourner un texte qui peut même être faux.
Soyons clairs : j’ai construit des tas de systèmes RAG. J’en ai encore une douzaine en production dans des entreprises du Fortune 500 en ce moment même. Ils ont leur utilité. Ils sont utiles.
Mais les appeler agents, c’est comme appeler une calculatrice un mathématicien. On passe complètement à côté de ce qui fait qu’un système est un agent : l’agentivité.
La vraie différence
Les vrais agents agissent. Ils ne vous parlent pas de votre agenda : ils planifient le rendez-vous. Ils ne trouvent pas juste le rapport de bug : ils créent l’issue GitHub. Ils n’analysent pas seulement vos dépenses : ils soumettent la note de frais.
Le saut technique du RAG vers de vrais agents n’est pas anodin :
Les systèmes RAG ont besoin de :
- Bases de données vectorielles
- Algorithmes de récupération
- Modèles d’embedding
- Une prière pour que la fenêtre de contexte soit assez grande
Les agents ont besoin de :
- Infrastructure d’appel d’outils
- Systèmes d’authentification
- Environnements d’exécution
- Gestion d’état
- Une gestion des erreurs qui ne consiste pas à s’excuser
Les systèmes RAG échouent proprement en renvoyant « Je n’ai pas trouvé cette information. » Les agents, eux, échouent en envoyant le mauvais e-mail à la mauvaise personne à 3h du matin.
Pourquoi cette distinction compte
Ce n’est pas du pinaillage sémantique. Cela change fondamentalement notre façon de construire.
Les systèmes RAG peuvent tourner en boucles requête-réponse simples. Question, réponse, tout le monde rentre chez soi content.
Les agents ont besoin d’architectures sophistiquées capables de gérer :
- Workflows de longue durée
- Exécution concurrente d’outils (et oui, l’exécution parallèle aussi, c’est différent, et ça m’agace qu’on confonde les deux)
- Arbres de décision complexes
- Persistance d’état entre les sessions
- Mécanismes de rollback quand les choses déraillent
Je vois des équipes perdre des mois à essayer d’étirer des systèmes RAG pour leur faire faire le travail d’un agent. Elles voulaient ce qu’un agent peut faire, et se sont retrouvées avec un moteur de recherche avec des étapes en plus.
Elles ajoutent des « fonctionnalités » comme :
- Retourner des URLs que l’utilisateur peut cliquer (en espérant qu’il est connecté dans ce navigateur)
- Générer du code que l’utilisateur peut copier-coller
- Rédiger des e-mails que l’utilisateur devra envoyer manuellement
Ce ne sont pas des comportements d’agent. Ce sont des contournements pour des systèmes incapables d’agir réellement.
Ce qu’il faut pour passer du RAG aux agents
Ce changement exige une refonte architecturale profonde :
Plutôt que de simplement récupérer du contexteil faut la découverte et la sélection d’outils. Votre agent doit comprendre non seulement quelles informations sont pertinentes, mais aussi quelles actions sont possibles.
Plutôt que de simplement générer du texteil faut parser et exécuter des appels d’outils. La logique vient des objectifs métier, pas seulement des patterns linguistiques.
Plutôt que des opérations unitairesil faut de la gestion de workflows. Les agents prennent des décisions, gèrent les branches, se relèvent des échecs.
Plutôt que des tokens de service avec accès totalil faut une authentification et une autorisation multi-tenant. Chaque action doit être délimitée au bon utilisateur avec les bonnes permissions.
Surtout, acceptez que les agents soient d’une complexité sans commune mesure avec les systèmes RAG. Vous ne gérez plus des hallucinations corrigeables avec un meilleur prompt. Vous gérez des systèmes capables de prendre des actions irréversibles dans le monde réel.
Ils exigent du vrai génie logiciel, pas seulement du prompt engineering. Ils ont besoin de :
- Des frameworks de test qui dépassent le « est-ce que ça sonne bien ? »
- Des pipelines de déploiement qui gèrent plus que des poids de modèle
- Des systèmes de monitoring qui suivent les actions, pas seulement les réponses
- Des stratégies de rollback pour quand votre agent décide d’être créatif
La récompense
Bonne nouvelle : une fois ce cap franchi, les possibilités explosent.
Votre IA ne dit plus aux utilisateurs quoi faire : elle le fait à leur place. C’est la différence entre une recherche utile et un vrai assistant.
- Votre agent support ne trouve pas juste la politique de remboursement : il traite le remboursement
- Votre agent DevOps ne se contente pas d’identifier le service défaillant : il le redémarre
- Votre agent commercial ne remonte pas juste des leads : il envoie les e-mails de suivi
C’est ce qui arrive, et c’est franchement génial.
Mais s’il vous plaît, arrêtons d’appeler les systèmes RAG des agents. Les deux ont de la valeur. Les deux sont nécessaires. Mais ce n’est pas la même chose.
Construisez du RAG quand vous avez besoin d’une meilleure recherche. Construisez des agents quand vous avez besoin que les choses se fassent.
Sam Partee est CTO et co-fondateur d’Arcade.dev, où il construit l’infrastructure qui permet aux agents d’agir concrètement. Il a implémenté plus de 100 applications LLM et a des opinions bien tranchées sur chacune d’elles.
Vous voulez construire des agents qui agissent plutôt que de simplement converser ? Commencez avec Arcade.dev ou venez me contredire sur Twitter.
