RAG ou agents IA : quelle architecture choisir en entreprise ?

Demandez quelle architecture retenir pour un projet d’IA d’entreprise et l’on vous proposera généralement deux options : la génération augmentée par la recherche (RAG) ou les agents. Choisissez.

C’est une erreur de catégorie, et elle coûte cher.

Le RAG décrit la façon dont un modèle obtient des faits qu’il n’a jamais appris. On récupère les éléments pertinents, on les place dans la fenêtre de contexte, on génère une réponse ancrée dans ces éléments.

Un agent décrit la façon dont un modèle décide de l’étape suivante. On lui donne des outils, il les appelle, on lui renvoie les résultats, et l’on recommence jusqu’à ce que la tâche soit accomplie.

Ces deux notions répondent à des questions différentes. La plupart des systèmes de production qui méritent d’être construits sont soit un agent dont l’outil le plus sollicité se trouve être la recherche, soit un système de recherche qui n’avait besoin d’aucune boucle. La bonne question n’est pas quel motif d’architecture, mais cette tâche se termine-t-elle en lisant ou en agissant ?

Ce que chacun vous coûte

La différence qui compte en exploitation est celle du travail borné face au travail non borné.

Une requête RAG a une forme fixe : une recherche, une génération, parfois un reclassement. La latence reste dans une plage prévisible. Le coût par requête varie avec la longueur du contexte, mais demeure dans une fourchette que l’on sait anticiper. Lorsqu’elle échoue, elle échoue en un seul endroit : les mauvais passages ont été récupérés, et le modèle y a puisé une réponse assurée.

Un agent, lui, n’est borné par construction. Il s’exécute jusqu’à estimer qu’il a terminé. Une requête demandera deux appels de modèle ; une autre, avec le même code et une question plus difficile, en demandera quinze. La distribution des coûts a une longue traîne, et les équipes qui budgètent sur la moyenne le découvrent à la fin du premier mois. Lorsqu’il échoue, les erreurs se composent : un mauvais appel d’outil produit une mauvaise observation, qui justifie le mauvais appel suivant.

Rien de tout cela ne fait des agents une mauvaise idée. Cela en fait une chose que l’on adopte en connaissance de cause, et que l’on instrumente avant de la mettre à l’échelle.

La décision, en trois questions

1. La tâche peut-elle être accomplie à partir de documents que la personne a déjà le droit de lire ? Si oui, construisez un RAG. Arrêtez-vous là. Une large part des cas d’usage en entreprise — questions de politique interne, recherche de procédure, consultation de contrats, intégration des nouveaux arrivants — sont des problèmes de recherche dotés d’une interface en langage naturel.
2. L’accomplir suppose-t-il de modifier un état ailleurs ? Ouvrir un ticket, mettre à jour un enregistrement, envoyer quelque chose. C’est un appel d’outil, et les appels d’outils relèvent des agents.
3. Le nombre d’étapes est-il connu à l’avance ? Si le processus consiste à « récupérer, puis résumer », écrivez ces deux étapes. S’il est réellement impossible de le savoir avant que le modèle n’ait vu les résultats intermédiaires, il vous faut une boucle.

Une version plus directe, qui ne nous a jamais trompés : un nouvel arrivant compétent répondrait-il à cela en lisant, ou en faisant ?

La même organisation, deux réponses

Prenons deux demandes qui arrivent la même semaine.

« Quelle est notre politique sur le matériel des prestataires ? » — la réponse existe, écrite, dans un document que le demandeur a le droit de consulter. Il n’y a rien à décider et rien à modifier. Récupérez le passage, répondez avec une citation, laissez la personne ouvrir la source. Ajouter ici une boucle de raisonnement achète de la latence et du coût, et ne rapporte rien.

« Mon portable ne se connecte plus au VPN depuis la mise à jour. » — la réponse n’existe encore nulle part. Y parvenir suppose de vérifier la version installée sur l’appareil, de regarder si le certificat est valide, peut-être d’ouvrir un ticket. Le nombre d’étapes dépend de ce que révèle chacune d’elles. C’est un agent, et les outils dont il a besoin sont peu nombreux et précis.

Même organisation, même plateforme, même modèle d’identité. Architecture différente, parce que les tâches n’ont pas la même forme. L’erreur n’est pas de mal choisir entre les deux : c’est de supposer que l’organisation doit choisir une fois pour toutes.

Là où les entreprises se trompent réellement

Construire un agent parce qu’il fait une meilleure démonstration. Un agent qui raisonne visiblement étape par étape impressionne davantage un comité de pilotage qu’un encadré qui renvoie un paragraphe sourcé. C’est pourtant le paragraphe que le métier avait demandé.

Reprocher au modèle un problème de recherche. Quand les réponses sont mauvaises, le réflexe est de changer de modèle ou de réécrire le prompt. Bien plus souvent, le bon passage n’a jamais été récupéré : le découpage l’a coupé en deux, le document est absent de l’index, ou les termes de la requête ne correspondent pas au vocabulaire de la source. Mesurez la recherche séparément de la génération, sans quoi vous continuerez d’ajuster le mauvais composant.

Traiter les permissions comme une phase ultérieure. C’est ce qui arrête net les projets en revue de sécurité.

N’avoir aucun jeu d’évaluation. Sans un ensemble figé de questions aux réponses connues, personne ne peut dire si la modification de la semaine dernière a amélioré quoi que ce soit. Les changements de prompt deviennent de la superstition.

La différence de sécurité que personne ne chiffre correctement

Les deux approches exigent que la recherche respecte les permissions de la personne qui interroge. Cela suppose de capturer les droits d’accès au moment de l’indexation — les groupes Entra ID autorisés à voir chaque document — et de filtrer sur l’appartenance de l’utilisateur à ces groupes au moment de la requête. Un index qui l’ignore est un système qui citera volontiers le plan de restructuration à la personne qui y est nommée.

Les permissions de recherche ne sont pourtant que la moitié facile.

Prenons l’injection de prompt indirecte. Un document de votre index contient un texte qui se lit comme une instruction plutôt que comme un contenu. Peut-être est-il arrivé par courriel ; peut-être un fournisseur l’a-t-il glissé dans un PDF.

Dans un système RAG, le pire des cas est une mauvaise réponse. Borné, embarrassant, réversible.

Dans un agent doté d’outils, le pire des cas est une mauvaise action. L’instruction injectée n’a pas besoin de convaincre un humain : elle doit convaincre un modèle déjà autorisé à appeler une fonction. Si cette fonction écrit dans un système, la surface d’exposition n’est plus ce que le modèle peut dire, mais ce que l’outil peut faire.

Cela modifie trois décisions de conception :

• Sous quelle identité l’outil s’exécute-t-il ? Les permissions applicatives sont commodes et dangereuses : l’agent peut alors faire tout ce que l’application peut faire, pour n’importe qui. Les permissions déléguées, exercées au nom de l’utilisateur connecté, ramènent l’exposition à la taille des accès de cette seule personne.
• Quels outils écrivent ? Les outils en lecture seule sont simples à raisonner. Chaque outil en écriture mérite son propre modèle de menaces, et probablement sa propre validation.
• Où se place l’humain ? La validation humaine n’est pas un agrément d’interface réservé à la première version, que l’on optimisera ensuite. Pour les actions irréversibles, c’est le contrôle.

L’architecture que la plupart des organisations devraient réellement construire

Non pas un choix entre deux options. Une séquence.

Commencez par une recherche faite correctement : filtrée par permissions, évaluée, avec des citations que l’utilisateur peut ouvrir et vérifier. C’est peu spectaculaire, c’est l’essentiel de la valeur, et c’est ce qui détermine si quiconque fera confiance au système.

Ajoutez ensuite les outils un par un. Chacun avec sa portée de permissions, ses cas d’évaluation, et sa propre décision quant à la validation humaine. Un « outil » est souvent ici une action unique et bien définie ; un système qui en compte trois bons vaut mieux qu’un système qui en compte vingt approximatifs.

Ajoutez la boucle en dernier. Une fois que le modèle sait appeler les outils de façon fiable dans un ordre fixe, le laisser choisir cet ordre est un incrément, pas une réécriture. Les équipes qui commencent par la boucle finissent par déboguer simultanément la qualité de la recherche, la conception des permissions et la fiabilité des outils, à travers un flot de contrôle non déterministe — exercice exactement aussi agréable qu’il y paraît.

Les chiffrer honnêtement

Le RAG se budgète par requête avec une confiance raisonnable. Les agents se budgètent sur la traîne : mesurez le p95 des appels de modèle par tâche, pas la moyenne, et fixez un plafond ferme d’itérations pour qu’un cas pathologique ne puisse pas tourner tout l’après-midi.

Les deux profitent de la même discipline : une télémétrie des coûts imputée par cas d’usage dès le premier jour, pour que la question « combien coûte cet assistant par conversation ? » trouve une réponse autre qu’un haussement d’épaules. Un système incapable d’y répondre finira par être arrêté par quelqu’un à la finance, faute d’avoir pu l’évaluer autrement.

Ce qui détermine réellement l’issue

Pas le motif d’architecture.

Les systèmes d’IA d’entreprise qui survivent au contact des utilisateurs réels sont ceux où quelqu’un a tranché tôt :

• comment la qualité de la recherche est mesurée, séparément de la qualité des réponses
• sous quelle identité s’exécute chaque appel d’outil
• quelles actions exigent un humain, et de qui il s’agit
• ce que le système coûte par conversation, et qui détient ce chiffre

Réglez ces points et l’une ou l’autre architecture vous servira. Laissez-les en suspens, et plus votre conception sera autonome, plus vite elle trouvera la faille.