arkalabsHier, quelqu'un m'a affirmé savoir ce que j'avais dit trois semaines plus tôt.
Je me souvenais de la conversation. J'avais partagé une intuition : un élément finirait forcément par avoir un impact. Lui se souvenait d'une formulation plus forte : « Tu avais dit que cela allait tout casser. »
Cette version me paraissait exagérée. Comme il consultait ses notes, je lui ai demandé si la phrase y apparaissait. Non. Il en avait le souvenir.
Le plus intéressant n'était pas de savoir qui avait raison. C'était de voir comment chacun de nous avait reconstruit un souvenir différent à partir de la même conversation. Et combien cette reconstruction avait pu influencer ses décisions pendant trois semaines.
Ce problème, je le rencontre tous les jours avec les agents IA.
Le modèle n'est pas l'agent
Quand on parle d'intelligence artificielle, on confond le modèle et l'agent. Ce ne sont pas les mêmes objets.
Un modèle comme GPT ou Claude est un moteur de raisonnement. Il reçoit un contexte, produit une réponse, puis s'arrête. Ses paramètres ne changent pas parce qu'une conversation s'est bien passée.
L'agent est le système construit autour de ce moteur : outils, permissions, fichiers, règles, mémoire. Le même modèle peut participer à des agents très différents. Donnez-lui un autre contexte et son comportement change, même si le moteur reste identique.
J'ai déjà utilisé plusieurs modèles dans une même session de travail sur Cortex.deck. Ils ne raisonnaient pas pareil, mais je n'ai jamais eu l'impression de changer de collaborateur. Le moteur changeait. Le système restait.
Cela m'a conduit à une distinction qui structure tout le reste : l'expérience peut appartenir au système, pas au modèle.
Pourquoi un fichier mémoire ne suffit pas
La première idée paraît évidente : conserver les échanges dans un fichier. Beaucoup d'agents ont un fichier de mémoire ou un historique complet qu'ils relisent au démarrage.
Imaginez que vous preniez des notes après chaque réunion pendant une année. Deux mois plus tard, au démarrage d'un nouveau projet, allez-vous relire l'ensemble de vos carnets ? Probablement pas.
Pourtant, c'est exactement ce qu'on demande aux agents. On injecte le fichier complet dans le contexte. Les informations importantes se retrouvent au milieu de décisions dépassées et de détails hors sujet. Le coût n'est qu'une partie du problème. Le bruit modifie le raisonnement.
J'ai d'abord cru que passer au JSON réglerait tout. Le gain a été net. Mais le problème de fond revient vite : le contenu reste figé dans des fichiers, et l'agent qui écrit dedans peut détruire la matière qui expliquait comment une conclusion s'était construite.
Il me fallait une base de données. J'ai choisi SurrealDB parce qu'elle fonctionne directement dans Cortex et réunit plusieurs capacités dans un seul moteur : stockage structuré, recherche par mots et par proximité de sens, et représentation native d'un graphe.
L'enquête et le tableau de fils
Un graphe, c'est simple à imaginer. Prenons une enquête policière. Un témoin affirme avoir vu une voiture rouge quitter les lieux à 22 heures. Les enquêteurs identifient le propriétaire. Une première hypothèse apparaît.
Le lendemain, une caméra montre que la plaque a été mal lue. Une autre preuve place le propriétaire ailleurs.
Dans un fichier, on remplacerait l'ancienne conclusion par la nouvelle. Mais une partie de l'enquête disparaîtrait avec elle. Pourquoi cette personne était-elle suspecte ? Qu'est-ce qui semblait crédible ? Qu'est-ce qui a invalidé la piste ?
Dans un graphe, rien n'a besoin d'être effacé. Le témoignage reste relié à la première hypothèse par « soutient ». La vidéo est reliée par « contredit ». Chaque lien possède une date et un statut.
Cortex utilise ce principe. Quand une nouvelle preuve arrive, le système ne réécrit pas silencieusement le passé. Il complète la chaîne.
Quand une conversation devient une expérience
Une conversation commence quand on ouvre un chat et se termine quand on le ferme. Le travail suit rarement cette frontière.
J'ai trouvé une image plus utile dans les séries. Chaque tour de conversation ressemble à une scène. Une scène de découverte fait apparaître un problème. Une autre pose l'intrigue. Une décision est prise, une action suit, puis une scène ultérieure montre le résultat. Regardée seule, la scène du milieu perd son sens si la scène initiale a disparu.
L'assemblage de ces scènes forme ce que j'appelle un Épisode. Un Épisode relie une situation de départ, un objectif, les décisions prises, les actions et le moment où la compréhension a changé. Il ne fabrique pas un récit plus cohérent que les sources. Chaque élément reste relié aux échanges qui l'ont fondé.
Plusieurs Épisodes composent une saison et construisent une compréhension plus large. La saison suivante peut révéler qu'une ancienne interprétation était incomplète. L'histoire grandit sans exiger l'effacement de ses versions précédentes.
Le voyant du cockpit
Imaginez un avion. Un voyant d'avarie s'allume dans le cockpit. Le commandant de bord possède une information, mais pas une conclusion.
Est-ce une alerte isolée ? Une panne confirmée ? Le signal visible reste le même. Selon la manière dont il est interprété, la liste de vérification à consulter et les actions autorisées ne seront pas identiques.
La liste de vérification ne change pas l'information. Elle encadre le pouvoir qu'on lui donne.
J'ai rencontré le même problème avec les Épisodes. Un échec peut produire plusieurs interprétations : « ne jamais utiliser X », « X échoue quand Y manque » ou « l'outil était indisponible ce jour-là ». Ces phrases ne décrivent pas la même chose. La première propose une règle générale. La dernière rapporte une observation locale.
Si tout est stocké sous l'étiquette « apprentissage », un incident unique devient une interdiction générale. L'agent rencontre une difficulté une fois et finit par éviter la situation partout.
C'est ainsi qu'un agent devient superstitieux.
Conserver une erreur sans la laisser agir
Tôt ou tard, une nouvelle preuve contredit ce que le système avait appris.
Supprimer l'ancienne croyance évite son retour, mais détruit ce qui l'avait rendue plausible. Tout conserver avec la mention « ne pas utiliser » préserve l'histoire, mais la garantie est faible. Si le texte revient dans le contexte, le modèle peut encore le mélanger à la correction.
Il faut séparer la conservation et l'autorisation.
L'ancienne liste de vérification de notre avion reposait sur une mauvaise interprétation. Elle ne doit plus guider l'équipage, mais sa disparition effacerait les incidents qui semblaient la confirmer. Elle reste dans les archives. Elle n'est plus disponible parmi les procédures autorisées en vol.
J'emploie le mot « révocation » pour désigner ce retrait du pouvoir. La croyance reste reliée à ce qui l'avait soutenue et à ce qui l'a remise en cause, mais son statut lui retire la capacité de gouverner une situation future.
Cette distinction paraît sémantique jusqu'au moment où l'agent peut agir. Écrire dans un prompt « n'utilise pas les informations invalides » revient à confier la règle au modèle. Or le modèle est précisément l'élément que la règle doit encadrer. Une garantie qui dépend de sa bonne volonté n'est pas une séparation technique.
Cortex fait déjà une partie de ce travail : un apprentissage révoqué est écarté au moment du rappel, puis revérifié au moment de l'usage. Le refus est nommé, horodaté et conservé. Mais je dois être honnête sur la limite actuelle : tant que l'interdiction est déclarée au modèle plutôt qu'imposée par le code, elle reste une consigne, pas une garantie. C'est précisément ce que je cherche à durcir.
Le souvenir est un briefing, pas une archive
Avant un vol, le commandant de bord ne reçoit pas toutes les archives de la compagnie. Il reçoit un briefing préparé pour ce vol : destination, météo, état de l'appareil, contraintes connues.
Le souvenir fonctionne de la même manière. Le système sélectionne les apprentissages admissibles et rattache les Épisodes nécessaires pour les comprendre. Il retire les doublons, conserve les sources et rend visibles les contradictions. Si dix éléments sont pertinents mais que la place n'en accepte que cinq, la sélection doit l'indiquer plutôt que de dépasser silencieusement la capacité du modèle.
Le souvenir n'est pas la mémoire entière. C'est la partie autorisée à prendre place sur le bureau pour cette mission.
Une question ouverte
Ce travail sur le souvenir devait en précéder un autre.
Avant Cortex, j'avais tenté de construire un agent doté de garde-fous inspirés de la peur, de la honte, de la culpabilité et de la responsabilité. La peur devenait une anticipation du risque, la honte une invalidation d'un résultat incompatible, la culpabilité une dette de réparation et la responsabilité un verrou sur la libération d'une action.
Cette expérience s'est arrêtée. Pour qu'une dette survive à une session, qu'un incident passé modifie une décision future ou qu'une réparation reste due, il fallait d'abord une mémoire capable de porter cette continuité.
J'avais cherché les garde-fous avant d'avoir construit la matière qui devait les nourrir.
Le travail sur le souvenir fournit maintenant cette matière. Il ne répond pas encore à la question suivante, mais il permet enfin de la poser correctement : des expériences passées peuvent-elles créer et nourrir une responsabilité artificielle ?
Je construis Cortex.deck, un système qui donne aux agents IA de la continuité et de l'expérience. Ce texte est issu d'un essai plus long, sourcé et révisé selon un protocole de collaboration IA explicite.