Veille
Fil conducteur
Tous les articles01 · Comprendre02 · Relier03 · Décider04 · Transmettre
Lecture
Publications

OAM : après plusieurs années de recherche, nous ouvrons l’après-RAG

Le RAG a rendu les connaissances externes accessibles aux modèles. Avec OAM, Organic Augmented Memory, Koperateur Consulting développe une architecture de mémoire relationnelle, évolutive et indépendante du modèle, conçue pour maintenir une continuité dans le temps.

OAM : après plusieurs années de recherche, nous ouvrons l’après-RAG
Partager
LinkedIn ↗WhatsApp ↗Courriel
Plus
Ma lectureCommencer la lectureSources et vérifications
Nature
Analyse éditoriale
Mis à jour
04/09/2026
Méthode, sources et limites ↓
Ma lectureReprendre, écouter et annoter localementDonnées conservées sur cet appareil · sans compte
Ouvrir
Vos repères restent sur cet appareilComment ça marche

Favoris, progression, repères et préférences de lecture restent dans ce navigateur. Kachouri ne crée pas de profil de lecture distant pour ces données. Vous pouvez les exporter pour les conserver ou les effacer depuis Ma lecture. Comme pour toute page web, la consultation de la page reste visible par le serveur.

Dans cet article 5 repères

Le problème à comprendre

Le RAG a profondément amélioré la manière dont les intelligences artificielles accèdent à l’information. En associant un modèle de langage à une base documentaire externe, il est devenu possible de retrouver des passages pertinents, d’exploiter des connaissances qui ne figurent pas dans les paramètres du modèle et de produire des réponses mieux ancrées dans les données disponibles. Depuis le travail fondateur publié en 2020 par Patrick Lewis et ses coauteurs, cette logique s’est imposée dans une grande partie des architectures d’IA appliquées à l’entreprise. Un corpus est préparé, découpé, indexé, puis interrogé afin de sélectionner les éléments susceptibles d’aider le modèle à répondre. Cette avancée a ouvert une voie essentielle et continue de répondre à de nombreux besoins.

Mais elle ne répond pas, à elle seule, à une autre question qui devient centrale dès que l’IA cesse d’être un outil ponctuel pour s’inscrire dans la durée : comment construire une continuité lorsque les informations, les décisions et les contextes évoluent ? Une organisation ne travaille pas seulement avec des documents. Elle travaille avec des arbitrages, des exceptions, des changements de version, des contraintes, des incidents, des personnes, des dépendances, des engagements et des informations dont la valeur peut changer avec le temps. Une décision parfaitement exacte en janvier peut être devenue obsolète en juin sans pour autant devenir fausse historiquement. Un fournisseur peut avoir été sélectionné puis remplacé, une architecture peut avoir été validée puis abandonnée, une règle peut avoir été assouplie, une personne peut changer de fonction, tandis que tout ce qui précède demeure utile pour comprendre l’histoire du projet.

Dans ces situations, le problème ne consiste plus seulement à retrouver le fragment le plus proche d’une question. Il consiste à déterminer ce qui est encore vrai, ce qui a changé, ce qui reste pertinent, ce qui doit être replacé dans son contexte historique et ce qui mérite d’être rappelé au moment précis où une nouvelle demande apparaît. La différence est importante parce qu’elle déplace le centre de gravité de l’architecture : on ne cherche plus uniquement à améliorer la récupération, on cherche à maintenir une représentation cohérente d’un contexte qui évolue.

C’est précisément sur ce problème que Koperateur Consulting travaille depuis plusieurs années. Les premiers besoins sont apparus de manière très concrète : les projets s’allongeaient, les corpus devenaient plus riches, les interactions avec différents modèles se multipliaient et la continuité se cassait facilement lorsque l’on changeait de conversation, d’outil ou de moteur. Une IA pouvait produire une excellente réponse dans une session, puis perdre quelques heures plus tard une décision essentielle, une contrainte structurante ou l’historique qui permettait de comprendre pourquoi une option avait été écartée. Ajouter davantage de documents, augmenter la fenêtre de contexte ou multiplier les embeddings améliorait certaines recherches, mais ne réglait pas le problème de fond.

Nous ne cherchions donc plus seulement un système capable de retrouver. Nous cherchions une architecture capable de conserver, relier, réviser et restituer. Après plusieurs années de recherche, d’expérimentation, d’itérations et d’utilisation sur des corpus réels, cette architecture a pris une forme suffisamment stable pour être utilisée dans nos propres environnements et intégrée dans des dispositifs déployés pour des clients. Par confidentialité, ces environnements ne sont pas identifiés publiquement et les éléments présentés ici décrivent les principes de l’architecture, pas les implémentations propres à chaque contexte client.

Nous lui avons donné un nom : OAM, Organic Augmented Memory. OAM est une technologie propriétaire de Koperateur Consulting. Elle a été conçue comme une couche de mémoire relationnelle et évolutive qui ne dépend pas d’un modèle de langage particulier. Son objectif n’est pas de remplacer mécaniquement tous les mécanismes de RAG, mais de traiter une question plus large : comment maintenir une continuité exploitable par différents modèles sans enfermer cette continuité dans une session, une fenêtre de conversation ou un fournisseur ? Le terme "Organic" ne signifie pas que le système imite biologiquement la mémoire humaine. Il décrit une propriété d’architecture : la mémoire peut être enrichie, révisée, pondérée, reliée à de nouveaux éléments et, lorsque c’est nécessaire, corrigée ou oubliée.

Une architecture système, pas un mécanisme isolé

OAM ne correspond pas à un algorithme unique ajouté entre une base documentaire et un modèle de langage. Il s’agit d’une architecture dans laquelle plusieurs responsabilités sont séparées afin que la mémoire puisse évoluer indépendamment du moteur chargé de raisonner sur elle.

À un niveau volontairement simplifié, son fonctionnement peut être représenté ainsi :

Sources autorisées
      ↓
Mémoire brute
      ↓
Qualification + provenance
      ↓
Consolidation / relations / temporalité
      ↓
Mémoire durable
      ↓
Reconstruction contextuelle
      ↓
Modèle interchangeable
      ↓
Nouvelle information à qualifier

Les sources autorisées peuvent produire différentes formes d’information : conversations, documents, événements applicatifs, décisions, médias ou données issues d’autres systèmes. Elles alimentent d’abord une mémoire brute. Cette étape est importante car une information nouvellement reçue n’est pas automatiquement considérée comme une connaissance durable.

Une étape de qualification permet ensuite d’associer à l’information des éléments nécessaires à son interprétation : son origine, son contexte, sa temporalité, sa nature ou son niveau de validité. Ces métadonnées permettent notamment de distinguer un fait d’une hypothèse, une décision d’une proposition, un état courant d’un état historique ou une information directement observée d’une synthèse produite ultérieurement.

La consolidation organise ensuite les éléments qui méritent de participer à la mémoire durable. Elle ne consiste pas simplement à résumer du texte. Elle doit permettre de maintenir des relations, de représenter des évolutions dans le temps et de conserver suffisamment de provenance pour que les informations importantes puissent être comprises, révisées ou auditées.

Lorsque le système doit traiter une nouvelle demande, il ne réinjecte pas mécaniquement l’ensemble de cette mémoire. Une étape de reconstruction contextuelle sélectionne et assemble les éléments utiles à la situation présente. La similarité sémantique peut participer à cette sélection, mais elle peut être complétée par d’autres signaux comme la récence, les relations entre éléments, le statut d’une décision, la provenance, les contradictions ou le périmètre auquel appartient l’information.

Le contexte ainsi reconstruit peut ensuite être utilisé par un modèle interchangeable. Cette séparation est fondamentale : le modèle raisonne à partir de la mémoire, mais il n’en constitue pas nécessairement le propriétaire ni la source de vérité. Plusieurs modèles peuvent ainsi exploiter une même continuité, sous réserve d’adapter la restitution à leurs capacités respectives.

Enfin, le résultat d’une interaction peut produire de nouvelles informations. Celles-ci ne sont pas automatiquement incorporées comme vérités permanentes : elles rejoignent à leur tour le cycle de qualification, de relation et, lorsque cela est justifié, de consolidation.

Cette représentation reste volontairement générale. Les stratégies précises de qualification, de consolidation, de pondération, de résolution des relations ou de reconstruction du contexte dépendent des cas d’usage et constituent une partie du savoir-faire associé à l’architecture. L’idée essentielle est ailleurs : la mémoire devient un système gouverné, évolutif et indépendant du modèle, et non un simple stock de fragments destinés à être recherchés au moment d’une requête.

Ce que le terrain montre

La première nuance est indispensable : dire que le RAG ne possède aucune mémoire serait faux. Le papier original de Lewis et al. parle explicitement de mémoire paramétrique et de mémoire non paramétrique. Dans cette famille d’architectures, un index externe constitue donc bien une forme de mémoire accessible au modèle. La différence avec OAM ne repose pas sur un changement de vocabulaire, mais sur le rôle donné à cette mémoire. Dans un RAG classique, l’objectif principal est généralement de récupérer des éléments pertinents pour une requête. Dans OAM, la récupération reste nécessaire, mais elle s’inscrit dans une logique plus large de continuité, d’évolution et de relation entre les éléments du corpus.

Cette distinction rejoint d’ailleurs une évolution plus générale de l’écosystème. Anthropic a montré avec son approche de "Contextual Retrieval" qu’un fragment isolé de son document d’origine peut perdre une partie des informations nécessaires à sa bonne indexation. Microsoft, avec GraphRAG, explore l’extraction d’entités, de relations et de communautés afin de structurer autrement le contexte disponible. Les travaux sur les "Generative Agents" de Joon Sung Park et de ses coauteurs introduisaient déjà une mémoire des expériences combinée à des mécanismes de réflexion et de récupération, tandis que MemGPT proposait une gestion hiérarchique de plusieurs niveaux de mémoire pour dépasser la limite pratique des fenêtres de contexte. Ces travaux ne prouvent pas qu’OAM serait supérieur à l’ensemble de ces approches. Une telle affirmation demanderait des protocoles de comparaison communs, des corpus de référence, des métriques et des résultats reproductibles que nous ne publions pas ici. Ils montrent en revanche que la question du contexte ne se résume plus depuis longtemps à une simple recherche de similarité.

La différence la plus utile peut être formulée simplement. Un système de RAG est très efficace lorsqu’il doit répondre à une question du type : "Dans quel document cette information apparaît-elle ?" OAM cherche à répondre à une question plus large : "Comment cette information s’inscrit-elle dans tout ce que le système connaît déjà, dans ce qui a changé depuis, dans les relations qui l’entourent et dans le contexte actuel de la demande ?" Le problème n’est donc pas uniquement le volume de données accessibles. Il concerne la manière dont la mémoire est organisée, consolidée, reliée et réutilisée dans le temps.

Collecter sans transformer immédiatement chaque information en vérité durable

OAM peut recevoir des conversations, des documents, des événements, des décisions, des médias, des données applicatives ou des signaux provenant d’autres systèmes autorisés. Cette matière première constitue la mémoire brute, mais elle ne doit pas être confondue avec une vérité définitive. Une conversation longue contient des répétitions, des hésitations, des corrections, des options finalement abandonnées et parfois des erreurs. Tout conserver sans distinction ne signifie donc pas mieux se souvenir. Cela peut au contraire augmenter le bruit et rendre les futurs rappels moins fiables.

La première responsabilité de l’architecture consiste à qualifier ce qui entre dans la mémoire. La provenance compte, tout comme la date, la nature de la source, le contexte d’origine et le statut de l’information. Une observation n’a pas le même poids qu’une décision formellement validée. Une préférence personnelle ne doit pas être traitée comme une règle universelle. Une hypothèse ne doit pas devenir un fait simplement parce qu’elle a été répétée plusieurs fois. Cette distinction est essentielle car une mémoire persistante peut amplifier une erreur : une réponse ponctuelle disparaît souvent avec la conversation, tandis qu’une information mal consolidée peut réapparaître des semaines plus tard et influencer de nouvelles décisions.

Consolider pour maintenir un corpus exploitable

La consolidation constitue la deuxième étape. Son objectif n’est pas d’accumuler toujours plus de texte mais de maintenir un corpus cohérent, structuré et actualisable. Les informations durables peuvent être distinguées des éléments temporaires, les événements séparés des décisions, les entités rapprochées de leurs relations et les changements significatifs identifiés comme tels. Une nouvelle information peut confirmer une ancienne conclusion, la compléter, la contredire ou la rendre obsolète. La mémoire doit donc être capable de représenter ces évolutions sans effacer mécaniquement l’histoire précédente.

Cette capacité de consolidation comporte une difficulté importante : la synthèse elle-même peut être erronée. OAM ne fait donc pas disparaître le besoin de provenance. Lorsqu’un cas d’usage l’exige, une mémoire consolidée doit pouvoir rester reliée aux éléments qui ont conduit à sa constitution. Cette relation est déterminante pour l’auditabilité, la correction et la confiance. Une architecture mémoire qui produirait des résumés permanents sans possibilité de revenir aux sources pourrait transformer une erreur d’interprétation en erreur structurelle.

Relier plutôt que classer dans des silos indépendants

La mémoire d’un projet ne suit presque jamais une structure parfaitement compartimentée. Une décision commerciale peut dépendre d’une contrainte technique apparue plusieurs mois auparavant. Une information issue d’un document peut expliquer une conversation ultérieure. Un incident peut modifier une règle qui concernait jusque-là plusieurs projets. Un événement professionnel peut aussi avoir un effet sur une disponibilité, une priorité ou une relation qui ne se trouve pas dans la même catégorie documentaire. OAM conserve cette transversalité en considérant que les relations entre les informations ont elles-mêmes une valeur.

Cette logique relationnelle ne signifie pas nécessairement que toute la mémoire repose sur un graphe de connaissances unique. Le principe est plus général : les éléments ne doivent pas être considérés comme des fragments indépendants simplement parce qu’ils ont été enregistrés séparément. Une information peut appartenir à plusieurs contextes, changer de statut avec le temps ou prendre une importance nouvelle lorsqu’un événement ultérieur apparaît. C’est aussi ce qui permet d’éviter qu’une mémoire ne se transforme en simple chronologie ou en collection de catégories étanches.

Rappeler le bon contexte plutôt que tout réinjecter

Une mémoire persistante ne doit pas être injectée entièrement à chaque requête. Cette stratégie serait coûteuse, lente et souvent contre-productive. Le rappel contextuel consiste au contraire à reconstruire un contexte adapté à la situation présente. La pertinence sémantique reste utile, mais elle n’est plus le seul signal possible. Selon le cas d’usage, la récence, la relation avec un projet, l’état d’une décision, la provenance, le niveau de confiance, la hiérarchie d’une contrainte ou la présence d’une contradiction peuvent influencer la sélection du contexte.

C’est ici que la différence de philosophie devient la plus lisible. Le RAG demande principalement quels éléments doivent être récupérés pour répondre à une requête. OAM ajoute une seconde question : quels éléments doivent être rappelés maintenant pour reconstruire correctement la situation ? La formulation est volontairement pédagogique et ne doit pas être interprétée comme une frontière absolue. Les architectures RAG les plus avancées peuvent intégrer une partie de ces logiques. OAM place simplement la continuité au centre du système plutôt qu’en périphérie.

Faire de la réponse une étape de la mémoire, pas nécessairement sa fin

La dernière partie de la boucle concerne l’évolution. Une nouvelle interaction peut compléter, préciser ou réviser la représentation existante. La réponse produite par un modèle ne constitue donc pas toujours la fin d’une requête. Elle peut devenir une nouvelle information à examiner, à relier ou à consolider si les règles du système l’autorisent. Cette boucle donne son sens au terme "Organic" : la mémoire se transforme au fur et à mesure que le corpus s’enrichit.

Cette évolution doit néanmoins rester gouvernée. Une mémoire utile ne doit pas seulement savoir ajouter. Elle doit pouvoir réviser, déclasser, représenter une contradiction et, lorsque cela est nécessaire, oublier. Cette dernière capacité est moins spectaculaire qu’une démonstration d’IA, mais elle est essentielle. Une mémoire permanente qui ne sait jamais supprimer devient rapidement un risque technique, organisationnel et juridique. La persistance augmente la valeur du système, mais elle augmente également la responsabilité liée aux données qui y sont conservées.

Ce que cela change

La première conséquence est architecturale. Pendant plusieurs années, une grande partie de la discussion autour des LLM s’est concentrée sur le choix du modèle : fournisseur, taille, coût, benchmark, fenêtre de contexte, vitesse et capacités de raisonnement. Ces critères restent importants, mais ils ne suffisent plus lorsqu’un système doit accompagner une personne, une équipe ou une organisation dans la durée. Une autre question prend de la valeur : où réside la continuité ? Si une organisation utilise trois modèles différents mais doit reconstruire son histoire pour chacun, elle dispose de plusieurs moteurs de génération, mais pas nécessairement d’une mémoire cohérente.

OAM inverse cette dépendance. Le modèle devient un moteur de raisonnement interchangeable, tandis que la mémoire reste une couche autonome et persistante. Cette séparation permet d’envisager l’évolution du modèle sans perdre l’historique, l’utilisation de plusieurs moteurs sur un même corpus, l’adaptation du niveau de raisonnement à la tâche ou le passage à un modèle local sans reconstruire l’ensemble de la mémoire. Il serait exagéré de parler d’une transparence totale entre modèles : les tailles de contexte, les formats, les capacités de raisonnement et les comportements varient, et la restitution doit donc être adaptée. L’objectif est plus réaliste : éviter que la valeur accumulée disparaisse lorsque le moteur change.

Cette logique est aussi une question de maîtrise. Une organisation peut changer d’IA sans vouloir changer d’histoire. Si toute la continuité est enfermée dans les conversations d’un fournisseur, le changement de modèle peut devenir un projet de migration de mémoire. À l’inverse, lorsque la mémoire reste autonome, les modèles peuvent être choisis selon leurs qualités du moment, leurs coûts, leur localisation, leur politique de confidentialité ou leurs capacités spécialisées. Le modèle reste important, mais il ne porte plus seul l’actif contextuel.

La deuxième conséquence concerne la gouvernance. Une mémoire opérationnelle contient plus que des documents : elle contient des relations, des évolutions, des décisions, des dépendances et parfois la manière dont ces informations ont été utilisées. Cette couche peut être beaucoup plus sensible qu’une simple base documentaire. Une entreprise peut accepter qu’un document commercial soit exploité par un moteur d’IA sans accepter que l’ensemble de ses arbitrages internes ou de ses relations organisationnelles le soit. La mémoire doit donc être pensée selon les mêmes exigences que les autres actifs critiques : contrôle d’accès, séparation des périmètres, provenance, correction, suppression, journalisation et protection contre les contenus malveillants.

Ce dernier point mérite une attention particulière. Une source injectée dans un système de mémoire peut contenir une information erronée, manipulée ou volontairement conçue pour influencer le comportement futur du modèle. Le risque de prompt injection ne disparaît pas lorsque l’on ajoute une mémoire persistante, il peut au contraire devenir plus sérieux si un contenu hostile réussit à modifier durablement une représentation. Les règles qui déterminent ce qui peut écrire dans la mémoire, ce qui nécessite une validation et ce qui doit rester temporaire deviennent alors aussi importantes que la qualité du retrieval lui-même.

La troisième conséquence concerne l’évaluation. Dire qu’un système "se souvient" n’est pas une métrique. Une architecture mémoire doit être testée sur sa capacité à retrouver une décision ancienne lorsqu’on demande son historique, à privilégier une décision plus récente lorsqu’on interroge l’état actuel, à distinguer un fait d’une hypothèse, à conserver la provenance lorsque celle-ci est nécessaire, à détecter qu’une information a été remplacée et à supprimer ou invalider une donnée sans casser l’ensemble des relations. Elle doit également démontrer qu’elle respecte les droits d’accès et qu’une information provenant d’un périmètre ne peut pas être rappelée dans un autre par simple proximité sémantique.

Cette exigence d’évaluation rejoint les recommandations plus générales du NIST sur la gestion des risques liés à l’IA générative, notamment en matière de gouvernance, de provenance, de confidentialité, de sécurité et d’évaluation tout au long du cycle de vie. Pour une architecture mémoire, ces principes prennent une dimension particulière : une erreur ponctuelle peut disparaître avec une réponse, tandis qu’une erreur devenue mémoire peut réapparaître plus tard et être prise pour un élément établi. La persistance augmente donc simultanément la valeur et le risque.

La quatrième conséquence est économique. OAM assume un choix qui peut sembler contre-intuitif dans une industrie souvent obsédée par la compression du contexte et le coût unitaire d’une requête. Consolider des informations, maintenir des relations, réévaluer certains états et préparer un contexte plus riche peut demander davantage de stockage, de calcul ou d’appels de modèles qu’un retrieval minimal fondé sur quelques voisins sémantiques. Selon les cas, le système peut également consommer davantage de contexte. Ce coût existe et il ne doit pas être masqué.

Mais l’équation économique ne peut pas se réduire au prix d’un token. Il faut aussi compter le temps passé à réexpliquer un projet, les incohérences produites entre deux sessions, les décisions prises à partir d’un contexte incomplet et la dépendance créée lorsqu’une mémoire reste enfermée dans un outil. Une IA moins chère à la requête peut devenir plus coûteuse à l’usage si l’utilisateur doit reconstruire son historique en permanence. L’inverse est également vrai : une architecture mémoire sophistiquée n’a aucun intérêt pour un besoin ponctuel, un corpus simple ou un service qui doit volontairement oublier entre deux interactions. OAM n’a pas vocation à devenir une couche systématique partout. La mémoire doit rester proportionnée au besoin.

Cette architecture a été pensée dès le départ comme une fondation générale. Elle peut servir à des assistants personnels, des agents métiers, des plateformes de connaissance, des outils de recherche, des environnements de développement, des systèmes d’accompagnement longitudinal ou des architectures multi-modèles. Le principe reste le même : permettre à une intelligence artificielle de s’appuyer sur une mémoire durable et transférable, sans faire dépendre toute la continuité d’une fenêtre de conversation ou des poids d’un modèle précis.

Ma lecture

Je ne pense pas que nous soyons entrés dans "l’après-RAG" au sens où la récupération documentaire deviendrait obsolète. Le retrieval restera une fonction fondamentale, et OAM en a besoin sous différentes formes. Il faudra toujours sélectionner, rechercher, filtrer et reconstruire du contexte. En revanche, je pense que le RAG seul ne suffit plus à décrire la totalité du problème dès que l’intelligence artificielle s’inscrit dans le temps long. La question ne porte plus seulement sur la pertinence d’un fragment, mais sur la continuité, l’état, la temporalité, les relations, la provenance, la contradiction, la révision, l’oubli et la gouvernance.

C’est aussi la raison pour laquelle la mémoire pourrait devenir un actif plus durable que le modèle lui-même. Les modèles vont continuer à changer. Certains deviendront moins chers, d’autres meilleurs sur des tâches spécifiques, certains seront exécutés localement, d’autres disparaîtront ou seront remplacés pour des raisons juridiques, économiques ou techniques. Le contexte construit autour d’une organisation peut, lui, représenter plusieurs années de décisions et de connaissances. Il doit donc pouvoir être conservé, audité, corrigé, déplacé et supprimé lorsque cela est nécessaire. La dépendance au modèle ne devrait pas se transformer en dépendance à sa mémoire.

OAM est né de cette conviction et d’un problème rencontré sur le terrain. Koperateur Consulting utilise cette approche dans ses propres environnements et dans des dispositifs clients, sans publier l’identité ni l’architecture détaillée de ces déploiements. Cette expérience constitue un retour de terrain, pas une validation scientifique indépendante. Nous ne publions pas aujourd’hui de benchmark permettant d’affirmer qu’OAM serait globalement supérieur à RAG, GraphRAG, MemGPT ou à toutes les autres architectures mémoire. Nous ne prétendons pas non plus que chacun des mécanismes qui composent OAM n’a jamais été exploré séparément ailleurs. Ce que nous présentons est l’architecture cohérente que nous avons développée, utilisée et perfectionnée pendant plusieurs années pour atteindre un objectif précis : donner aux systèmes d’IA une continuité qui ne disparaisse pas lorsqu’un modèle, une conversation ou un outil change.

Cette approche s’inscrit aussi dans une logique plus large portée par l’écosystème Quaric, incubé par Koperateur Consulting autour d’une recherche d’indépendance technologique et de réduction des dépendances de bout en bout. Dans ce cadre, la mémoire n’est pas seulement une fonctionnalité supplémentaire. Elle devient une couche stratégique qui doit rester maîtrisable, portable et gouvernable, au même titre que les autres composants critiques d’une architecture numérique.

La question qui me paraît désormais la plus importante est donc la suivante : que se passe-t-il lorsque l’intelligence artificielle cesse d’être une conversation et devient un système qui accompagne réellement une organisation dans le temps ? À ce moment-là, la qualité du modèle ne suffit plus. Il faut être capable de préserver l’histoire, d’en comprendre les évolutions, de distinguer ce qui était vrai de ce qui l’est encore, de relier une décision à ce qui l’a provoquée et de reconstruire le contexte pertinent sans réinjecter mécaniquement toute la mémoire.

C’est là que commence, pour nous, l’après-RAG. Le RAG a rendu les connaissances externes accessibles aux modèles. OAM cherche à ajouter la continuité nécessaire pour transformer cette accumulation d’informations en mémoire exploitable dans le temps. Le premier retrouve. Le second cherche à inscrire ce qui est retrouvé dans une histoire, à le relier au reste du corpus et à permettre à cette compréhension d’évoluer.

OAM, Organic Augmented Memory : apprendre, relier, évoluer. Cette architecture est développée par Koperateur Consulting dans l’écosystème Quaric.

Sources et références

Source institutionnelle sur Koperateur Consulting. Les informations relatives à OAM, à son développement, à son usage interne et à ses déploiements dans des environnements clients relèvent du retour d’expérience communiqué par Koperateur Consulting. Les clients concernés ne sont pas identifiés publiquement.

Présentation de l’écosystème Quaric, porté et incubé par Koperateur Consulting, et de sa logique d’indépendance technologique de bout en bout.

Publication fondatrice décrivant les modèles RAG comme une combinaison de mémoire paramétrique et non paramétrique pour la génération augmentée par récupération.

Travaux décrivant une architecture d’agents qui conserve des expériences, produit des réflexions de plus haut niveau et récupère dynamiquement des souvenirs pour guider le comportement.

Proposition d’une gestion hiérarchique de la mémoire et du contexte pour étendre les interactions au-delà de la fenêtre de contexte d’un modèle.

Présentation d’une méthode visant à conserver davantage de contexte lors de l’indexation et de la récupération des fragments dans une architecture RAG.

Architecture structurée de Retrieval-Augmented Generation qui extrait notamment des entités, des relations et des communautés à partir de données non structurées.

Référentiel de gestion des risques appliqué à l’IA générative, utile pour les questions de gouvernance, de provenance, de confidentialité, de sécurité et d’évaluation du cycle de vie.

Dossier de vérification

Sources et vérifications

La bibliographie de l’article reste visible juste au-dessus. Ce dossier ajoute une couche structurée pour retrouver la provenance, suivre les références et faciliter une future mise à jour, sans transformer leur présence en validation automatique de leur contenu.

8 références
Références structurées8URLs conservées explicitement
Domaines distincts6Origines documentaires différentes
Sources externes8Références hors de Kachouri
Liens Kachouri0Contexte et analyses internes reliés
Consulter le dossier des sourcesProvenance structurée, domaine et dates disponibles8 entrées
webKoperateur Consulting

koperateur.com

Ouvrir
webQuaric, Fondation pour l’indépendance technologique

quaric.org

Ouvrir
webPatrick Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", 2020

arxiv.org

Ouvrir
webJoon Sung Park et al., "Generative Agents: Interactive Simulacra of Human Behavior", 2023

arxiv.org

Ouvrir
webCharles Packer et al., "MemGPT: Towards LLMs as Operating Systems", 2023

arxiv.org

Ouvrir
webAnthropic, "Introducing Contextual Retrieval", 19 septembre 2024

www.anthropic.com

Ouvrir
webMicrosoft Research, GraphRAG, documentation officielle

microsoft.github.io

Ouvrir
webNational Institute of Standards and Technology, "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile", NIST AI 600-1, 26 juillet 2024

www.nist.gov

Ouvrir

Prolonger la lecture

Du constat à une action maîtrisable

Reliez cette analyse à votre situation : un besoin à cadrer, une architecture à éprouver ou un outil à tester. Ces projets montrent les prolongements possibles de la démarche.

Parler d’un problème concretExplorer l’écosystème
Koperateur ConsultingCadrer, bâtir, opérer, mesurer RoastMyURLAuditer les fondations d’un site ItylosCollaborer sans exposer les données 0blaLa privacy utile, pas cosmétique

Continuer la lecture

Veille & analyseLa prochaine faille peut être entre les experts : la cybersécurité comme problème de connaissance04/10/2026 Web, audit & visibilitéRoastMyUrl affiche 68/100. Non, cela ne veut pas dire que le site est sécurisé à 68 %04/10/2026 IA & systèmesComplexiance : penser l'IA en complexité pour mieux décider03/10/2026