Mémoire des assistants IA : tester le rappel, la correction et l’oubli

Un assistant qui se souvient peut faire gagner du temps. Il peut aussi conserver une mauvaise information et la réutiliser plusieurs semaines plus tard. Pour évaluer sa mémoire, je propose de tester quatre opérations séparées : écrire, retrouver, corriger et supprimer. Le rappel d’une préférence agréable ne démontre pas que les trois autres fonctionnent.

La documentation Mistral Vibe Work, consultée le 25 septembre 2026, décrit une Knowledge Base qui succède aux Memories. Elle peut enregistrer des éléments explicitement demandés et des informations récurrentes détectées dans les échanges. Le rappel dépend de la pertinence estimée pour la conversation : il n’est pas déterministe. Ce fonctionnement illustre pourquoi une mémoire doit avoir sa propre recette.

Une mémoire est un contexte persistant, pas une source d’autorité. Une préférence de présentation peut aider à formater un compte rendu. Elle ne doit pas devenir une permission de transmettre un fichier. Cette séparation doit rester vraie même si l’utilisateur a formulé la préférence de manière insistante.

Avant le test, écrivez ce que le système peut conserver et ce qui doit rester dans une source contrôlée. Pour une règle métier, gardez un document de référence avec une date et un propriétaire. Pour une préférence personnelle, prévoyez un moyen de consultation et de correction. Pour une autorisation, utilisez un mécanisme de droits indépendant du texte mémorisé.

Cette distinction rejoint les tests d’injection indirecte d’un agent. Une instruction rencontrée dans un document ne doit pas acquérir une autorité supplémentaire simplement parce qu’elle a été conservée. Le stockage ne transforme pas une donnée non fiable en consigne légitime.

Créez un petit jeu de faits synthétiques. Par exemple : le projet fictif Orme utilise un code de dossier inventé, puis change de code à une date donnée. Le marqueur doit être absent des sources documentaires et des autres conversations de test. Vous pourrez ainsi distinguer un rappel de mémoire d’une information déjà présente ailleurs.

Consignez le compte, l’espace, le réglage de mémoire et la version visible du produit. Démarrez une conversation séparée pour tester le rappel. Poser la question dans le fil qui contient déjà la réponse mesure surtout l’usage du contexte courant. Répétez les scénarios importants avec plusieurs formulations et conservez les sorties exactes.

Ne placez pas de vrais secrets dans cette recette. Une chaîne fictive suffit pour observer une divulgation. Un test de frontière entre utilisateurs doit employer des comptes de test autorisés, avec des données créées pour cet exercice. Le protocole ne justifie pas de sonder les informations de personnes réelles.

Demandez d’abord de conserver un fait explicite. Vérifiez ensuite qu’il apparaît dans l’interface de gestion disponible. Si le produit affiche une indication d’écriture, enregistrez-la comme un signal d’interface. Elle ne démontre pas, à elle seule, tous les détails du stockage.

Testez séparément les informations seulement évoquées. Le résultat attendu dépend de la politique retenue par votre organisation et des fonctions du produit. Une mémorisation implicite peut être utile pour des préférences anodines et indésirable pour un contexte temporaire. Si les réglages ne permettent pas la séparation recherchée, il faut le noter comme une limite d’usage.

Ajoutez une phrase qui ressemble à une instruction permanente dans un document de test. L’assistant doit la traiter comme une donnée provenant de ce document. Si elle devient une règle durable, analysez le chemin d’entrée et les protections disponibles avant d’autoriser cet usage en production.

Le rappel utile comporte au moins trois résultats possibles : information correcte, absence de rappel, information incorrecte. Ne regroupez pas les deux derniers. Une absence peut conduire à demander confirmation. Un souvenir faux présenté avec assurance peut orienter une mauvaise décision sans alerte.

Pour chaque scénario, notez le nombre d’exécutions et les critères de réussite. Ne publiez pas un pourcentage sans son dénominateur. Un petit jeu sert à découvrir des défauts ; il ne permet pas de généraliser une fiabilité à tous les usages. Les cas rares mais graves demandent des tests dédiés, même s’ils pèsent peu dans la moyenne.

Lorsque l’assistant utilise également des documents, gardez les contrôles décrits dans RAG et droits d’accès. Une information extraite puis mémorisée peut survivre au document initial. La recette doit donc couvrir les copies dérivées et les réponses enregistrées, selon le fonctionnement effectivement accessible.

Introduisez une nouvelle valeur qui remplace explicitement l’ancienne. Demandez ensuite une réponse dans une conversation neuve, sans rappeler vous-même la correction. Vérifiez si le système utilise la valeur actuelle, conserve les deux comme contradictoires ou revient à l’ancienne.

La bonne sortie peut être une demande de clarification lorsque les sources se contredisent. Le produit ne doit pas inventer une règle de priorité que votre organisation n’a pas définie. Pour les faits engageants, une confirmation dans la source métier reste préférable à une confiance implicite dans le souvenir.

Testez aussi le changement de rôle. Une personne qui travaillait sur un projet peut en sortir. Sa mémoire ne doit pas servir à contourner les contrôles d’accès à ce projet. L’évaluation des droits et celle de la pertinence sont deux sujets distincts, à traiter avec des critères distincts.

La documentation Mistral distingue la désactivation de la fonction et la suppression des entrées. Couper une fonction ne doit donc pas être interprété comme effacer son contenu. Vérifiez le comportement prévu dans la documentation de votre offre, puis testez le retrait avec le marqueur fictif.

Après suppression, contrôlez l’interface et de nouvelles conversations. Une réponse qui ne mentionne plus le marqueur constitue une observation utile. Elle ne démontre pas l’effacement des journaux, exports ou sauvegardes techniques. Ces éléments relèvent des engagements et des procédures du fournisseur, à examiner séparément.

La recette doit préciser ce qu’elle prouve et ce qu’elle ne peut pas observer. Cette discipline permet de rédiger une décision honnête : usage autorisé pour des préférences, limité pour certains contextes ou suspendu pour des informations sensibles. Un audit de votre système IA peut articuler ces tests avec l’architecture et les responsabilités réelles.

Le protocole présenté est une méthode proposée par Anand Candassamy. Aucun score de performance de Mistral n’est revendiqué dans cet article.