Agent IA d’entreprise : RAG ou mémoire en 2026 ?

Vous voyez des réponses qui citent une procédure obsolète, mélangent la préférence d’un utilisateur avec une règle d’entreprise ou reprennent une tâche à la mauvaise étape.

La solution la plus sûre en 2026 est de ne pas opposer systématiquement RAG et Memory : utilisez le RAG pour les connaissances stables et gouvernées, la mémoire d’agent pour les préférences et expériences réutilisables, puis un état séparé pour les tâches en cours.

À qui s’adresse cette décision d’architecture ?

Cet article s’adresse aux architectes qui connectent une base de connaissances d’entreprise à un agent IA, aux équipes produit qui doivent conserver un état entre plusieurs conversations et aux responsables de plateforme qui veulent éviter la pollution de mémoire, les dépassements de droits et les informations périmées.

Il concerne aussi les équipes audio, vidéo et design : un agent qui doit retrouver une charte de marque, reprendre un montage interrompu ou mémoriser les préférences d’export ne manipule pas les mêmes types de données.

1. Commencez par séparer la source d’autorité du contexte réutilisable

Le RAG n’est pas simplement une recherche vectorielle. C’est une chaîne qui comprend l’interprétation de la requête, la récupération de contenus, la construction du contexte, la génération et, selon l’implémentation, la validation de la réponse. Une documentation officielle doit donc conserver son titre, sa version, sa date d’effet, son propriétaire, son périmètre d’accès et sa provenance.

Les travaux fondateurs sur le RAG ont précisément étudié la combinaison d’une mémoire paramétrique du modèle avec une mémoire externe non paramétrique, puis évalué cette approche sur 3 tâches de questions-réponses ouvertes. L’intérêt du RAG tient à l’accès à une connaissance externe et à la possibilité d’en montrer la provenance, pas à la seule présence d’un index vectoriel. Voir l’étude originale sur le RAG.

La mémoire d’agent répond à une autre responsabilité. Elle peut conserver une préférence utilisateur, une expérience utile ou un fait de profil, mais elle ne devrait pas automatiquement devenir une règle générale. Une documentation de référence sur la mémoire distingue notamment la mémoire à court terme, limitée à un fil de conversation, et la mémoire à long terme, réutilisable entre plusieurs sessions et organisée par espaces de noms. Consulter la documentation conceptuelle sur la mémoire des agents.

La première erreur de conception consiste donc à mettre les deux contenus dans la même collection, avec les mêmes droits et le même cycle de vie. Vous perdez alors la réponse à trois questions essentielles :

• cette information est-elle officielle ou seulement déclarée par un utilisateur ;
• qui peut la lire et la modifier ;
• que doit-il se passer lorsqu’elle devient fausse ?

2. Choisissez selon le type d’agent, pas selon la mode technique

Un assistant chargé de répondre à des questions sur les congés, les produits, les procédures qualité ou les règles d’installation doit d’abord disposer d’un RAG fiable. Il doit pouvoir retrouver la version applicable et signaler quand aucune source autorisée ne répond à la question.

Un agent de service client a davantage besoin d’une mémoire contrôlée. Le fait qu’un client préfère un format de facture, qu’il ait déjà effectué une étape de diagnostic ou qu’un incident ait été traité peut éviter une répétition inutile. Toutefois, cette mémoire doit rester liée au bon compte, être corrigible et ne pas être interprétée comme une politique commerciale générale.

Un agent d’automatisation doit surtout disposer d’un état récupérable. « Validation en attente », « fichier audio transcodé », « export vidéo échoué » ou « autorisation manquante » sont des états opérationnels ; les enfouir dans un document récupéré par similarité rend la reprise fragile. Le système métier ou l’orchestrateur doit rester responsable du statut officiel.

Ce tableau ne signifie pas qu’un seul composant suffit toujours. Il indique quelle couche doit avoir le dernier mot.

3. Appliquez une règle de propriété aux données

Avant d’implémenter une mémoire persistante, classez chaque donnée selon sa responsabilité. Cette étape est plus importante que le choix du fournisseur de recherche ou de la base de données.

Les préférences utilisateur ne doivent donc pas automatiquement être enregistrées dans votre index documentaire. Un index vectoriel peut retrouver des exemples proches, mais il ne garantit pas à lui seul qu’une préférence est actuelle, confirmée ou applicable au bon utilisateur.

Pour un agent de montage vidéo, par exemple, « exporter habituellement en ProRes » peut relever de la préférence. En revanche, « ce projet doit être livré dans le format imposé par le client » relève de l’état ou du cahier des charges du projet. La similarité sémantique ne doit pas décider à votre place.

4. Construisez une architecture en quatre couches

Une architecture de production combinant RAG et Memory doit rendre visibles les frontières entre les composants.

Le flux recommandé est le suivant :

1. Authentifiez la requête avant toute récupération, en associant l’utilisateur, l’organisation, l’équipe et les droits applicables.
2. Filtrez les sources avant le classement sémantique ; ne récupérez pas un document interdit pour ensuite demander au modèle de l’ignorer.
3. Interrogez séparément le RAG et Memory, avec deux contrats de données distincts.
4. Présentez au modèle les statuts des éléments, par exemple « source officielle », « préférence utilisateur » ou « hypothèse non validée ».
5. Écrivez l’état transactionnel dans le système responsable de l’opération, sans le transformer en souvenir libre.
6. Journalisez la décision finale, en conservant les sources, les souvenirs rappelés, les outils utilisés et les validations nécessaires.

Une documentation d’architecture pour les scénarios multipropriétaires recommande également de faire passer les demandes par une couche d’API qui applique les règles d’autorisation, filtre les données par organisation et conserve les journaux d’accès aux informations utilisées comme contexte. Voir les principes d’un RAG multipropriétaire sécurisé.

La séparation doit exister dans les schémas, les identifiants, les journaux et les procédures de suppression. Une simple convention de nommage dans une collection partagée ne constitue pas une isolation suffisante.

5. Dimensionnez le contrôle avant d’activer l’écriture automatique

La mémoire est utile lorsqu’elle réduit une répétition coûteuse, mais une écriture automatique sans gouvernance peut enregistrer une supposition, une information confidentielle ou une préférence temporaire comme si elle était permanente.

Utilisez au minimum ces contrôles :

• Portée : utilisateur, équipe, agent, projet ou organisation ;
• Origine : déclaration explicite, extraction de conversation, observation d’un outil ou validation humaine ;
• Confiance : confirmé, probable, à vérifier ;
• Expiration : date fixe, durée d’inactivité ou révision obligatoire ;
• Correction : interface permettant de consulter, modifier et supprimer ;
• Promotion : procédure distincte pour transformer une expérience en règle documentée ;
• Refus d’écriture : données sensibles, secrets, identifiants inutiles et affirmations non vérifiées.

Les guides actuels sur les agents distinguent aussi l’écriture « dans le chemin critique », avant la réponse, et l’écriture en arrière-plan. La première peut personnaliser immédiatement mais augmente le risque de mémoriser une erreur ; la seconde réduit la latence du dialogue mais impose une file de validation et une stratégie de concurrence. Comparer les modes d’écriture de mémoire.

Pour un service client, vous pouvez demander une confirmation avant d’enregistrer une préférence : « Souhaitez-vous que ce format soit utilisé lors de vos prochaines demandes ? » Pour une automatisation audio, vous pouvez mémoriser un profil d’export projet, mais le rendre inactif lorsque le projet change de client.

6. Testez les droits, la fraîcheur et la récupération

Un RAG correctement alimenté peut encore produire une réponse inexacte si la récupération est incomplète, si le découpage est mauvais, si les filtres d’accès sont absents ou si trop de passages concurrents sont envoyés au modèle. Les recommandations d’évaluation distinguent notamment la qualité de récupération, la pertinence de la réponse et son ancrage dans le contexte fourni. Certains évaluateurs utilisent une échelle de 1 à 5, avec un seuil de réussite fixé à 3 dans leur configuration par défaut. Consulter la documentation officielle sur l’évaluation des systèmes RAG.

Avant la mise en production, préparez un jeu de tests comprenant :

• une question dont la réponse se trouve dans la version actuelle d’un document ;
• une question concernant une version archivée ;
• une demande formulée avec le vocabulaire d’une autre équipe ;
• un utilisateur qui ne devrait voir qu’une partie du corpus ;
• une préférence corrigée depuis la conversation précédente ;
• une tâche interrompue après un échec d’outil ;
• une information supprimée qui ne doit plus être rappelée.

Vérifiez ensuite quatre sorties séparées : les passages récupérés, les souvenirs rappelés, l’action effectuée et la justification affichée. Si vous ne pouvez pas dire quelle couche a produit une information, le système est déjà trop difficile à auditer.

Pour les données structurées, un contrôle d’accès au niveau des lignes peut fournir un refus par défaut lorsqu’aucune politique n’autorise la visibilité ou la modification d’une ligne. Lire la documentation sur les politiques de sécurité au niveau des lignes. Cela ne remplace pas une architecture d’identité complète, mais cela permet d’éviter qu’une requête applicative retourne silencieusement toutes les données d’un espace partagé.

7. Utilisez ces conditions pour choisir une voie de déploiement

Choisissez RAG seul si les réponses doivent provenir de documents stables, versionnés et accessibles selon des droits précis, tandis que la personnalisation reste faible ou peut rester dans la session.

Choisissez Memory seule uniquement si le produit manipule principalement un contexte utilisateur ou un historique opérationnel limité, sans prétendre répondre à partir d’une base documentaire officielle. Cette voie convient à certains assistants personnels, mais elle est rarement suffisante pour un agent d’entreprise chargé d’expliquer des règles.

Choisissez RAG et Memory combinés si l’agent doit à la fois citer une source officielle, reprendre les habitudes d’un utilisateur et conserver une expérience utile entre plusieurs sessions. Dans ce cas, séparez les espaces, les contrats, les journaux et les droits d’écriture.

Choisissez aucune persistance longue durée si vous ne pouvez pas encore proposer une suppression vérifiable, une correction accessible, une politique d’expiration et une traçabilité des lectures. Un contexte de session temporaire est parfois préférable à une mémoire difficile à retirer.

Liste de contrôle avant la production

• [ ] Chaque donnée possède un propriétaire fonctionnel clairement identifié.
• [ ] Les documents officiels ont une version, une date d’effet et une source.
• [ ] Les préférences utilisateur ne peuvent pas écraser la base de connaissances.
• [ ] Les états de tâche sont écrits dans une couche capable de reprendre une transaction.
• [ ] Les requêtes RAG appliquent les droits avant la génération.
• [ ] Les souvenirs disposent d’une portée, d’une origine et d’une durée de conservation.
• [ ] L’utilisateur peut consulter, corriger et supprimer ce qui est mémorisé.
• [ ] Les documents récupérés et les souvenirs rappelés sont journalisés séparément.
• [ ] Les scénarios d’accès interdit, de document obsolète et de mémoire supprimée sont testés.
• [ ] Les données de test sont séparées des environnements de production.

Pour préparer cette validation, vous pouvez commencer par un environnement isolé et consulter le centre d’aide de ZavCloud, puis vérifier les règles applicables dans les conditions d’utilisation de ZavCloud. Si votre équipe doit exécuter des outils de développement, des tests audio ou des workflows vidéo sur un Mac distant, la page consacrée à la location de Mac mini au Japon peut servir de point de comparaison pour organiser un poste de validation séparé.

Questions fréquentes

Quelle est la différence entre RAG et Agent Memory dans une application d’entreprise ?

Le RAG récupère des informations depuis des sources gouvernées, telles que des procédures, contrats ou fiches produit, afin de produire une réponse traçable. L’Agent Memory conserve plutôt un contexte réutilisable : préférences, expériences passées ou état d’une tâche. Le premier répond à « quelle source fait foi ? », le second à « que faut-il retenir pour continuer correctement ? ».

Un agent IA d’entreprise doit-il toujours utiliser RAG et Memory ensemble ?

Non. Un assistant documentaire peut commencer avec un RAG bien contrôlé, sans mémoire persistante. À l’inverse, un agent de workflow peut d’abord utiliser un état de tâche et les données du système métier. Vous combinez RAG et Memory lorsque l’agent doit à la fois citer une connaissance officielle et personnaliser ou reprendre une interaction précédente.

Les préférences utilisateur doivent-elles être stockées dans un index vectoriel ou dans un système de mémoire ?

Une préférence stable, comme un format de rapport ou une langue de réponse, relève généralement d’une mémoire structurée et limitée. Un index vectoriel peut aider à retrouver des exemples ou des épisodes similaires, mais il ne doit pas devenir la source d’autorité pour une préférence sensible. Associez toujours la préférence à un utilisateur, une date, une origine et une possibilité de correction.

Une mémoire à long terme risque-t-elle de contaminer la base de connaissances de l’entreprise ?

Oui, si les deux flux d’écriture partagent le même espace sans distinction de statut. Une conversation peut contenir une hypothèse, une erreur ou une information personnelle qui ne mérite pas d’entrer dans la documentation officielle. Séparez les stockages, marquez les sources, imposez une validation avant promotion et empêchez la mémoire utilisateur d’écraser les documents gouvernés.

Comment organiser une architecture de production combinant RAG et Memory ?

Placez une couche d’identité et d’autorisation devant les sources, puis séparez le RAG, la mémoire et l’état transactionnel. Le RAG renvoie des passages avec leur provenance, la mémoire renvoie des éléments avec leur portée et leur date d’expiration, tandis que le système métier reste responsable des statuts officiels. Journalisez séparément la récupération, le rappel et la décision finale.

Dans la plupart des entreprises, le choix ne se résume donc pas à remplacer une base documentaire par une mémoire d’agent. Un RAG mal filtré peut exposer un document confidentiel ; une mémoire non bornée peut conserver une erreur ; un état placé dans des textes récupérables peut empêcher la reprise fiable d’une opération. La bonne approche consiste à attribuer une responsabilité différente à chaque donnée, puis à vérifier les frontières avec des scénarios réels.

Si votre équipe hésite encore sur la taille de l’environnement nécessaire, commencez par une plateforme de développement isolée, utilisez des données désensibilisées et mesurez séparément la récupération, le rappel de mémoire et l’exécution des outils. Louer un Mac auprès de ZavCloud peut alors être pertinent pour valider temporairement des chaînes de développement, des agents orientés audio ou vidéo et des intégrations Apple avant d’engager des ressources permanentes. En revanche, un achat local reste plus cohérent pour une charge stable de longue durée, un accès physique aux périphériques ou une exploitation entièrement maîtrisée en interne.