OKF Agent Memory a fait son entrée sur Hacker News, mais la mémoire native de Git doit encore faire ses preuves

OKF Agent Memory est arrivé sur Hacker News avec 11 points et deux commentaires, en présentant un dépôt comme mémoire durable pour les agents d’IA dédiés à la programmation. Son enjeu central apparaît immédiatement. Les connaissances importantes d’un projet peuvent vivre à côté du code, mais les agents doivent pouvoir les récupérer et les mettre à jour sans les corrompre.

Le projet open source stocke les décisions, les faits et les relations sous forme de fichiers Markdown avec un front matter YAML. Il ajoute une recherche locale, une validation, des métadonnées de cycle de vie et un serveur Model Context Protocol. L’ensemble se situe entre les fichiers d’instructions familiers et les services de mémoire adossés à une base de données.

Ce positionnement compte, car les assistants de programmation disposent déjà de plusieurs moyens de conserver le contexte. Claude Code prend en charge les instructions de projet et la mémoire automatique locale. Codex peut utiliser des instructions limitées au dépôt, tandis que les systèmes d’agents émergents maintiennent leurs propres magasins de mémoire. OKF Agent Memory soutient plutôt que la mémoire partagée d’un projet doit résider dans Git.

La présence sur Hacker News ne démontre ni l’adoption ni la validité des revendications du projet en matière de benchmarks. Elle met toutefois en lumière un débat opportun sur la propriété. La mémoire d’un agent doit-elle rester privée à un outil, ou devenir une infrastructure de projet révisable qui accompagne le dépôt ?

Ce que Hacker News a trouvé dans OKF Agent Memory

OKF Agent Memory regroupe un format de connaissances, une convention d’exploitation, un outil de recherche et une interface MCP dans un système centré sur le dépôt.

La mémoire native de Git du projet se trouve dans un répertoire knowledge/. Chaque concept peut occuper un fichier Markdown doté de métadonnées structurées, tandis que des fichiers d’index exposent les sujets disponibles. Les agents parcourent la collection avant d’ouvrir des fiches détaillées.

Cette organisation repose sur la divulgation progressive, c’est-à-dire le chargement d’un petit index avant la récupération de documents plus volumineux. Un agent n’a pas besoin de recevoir chaque décision d’architecture, guide d’exploitation et définition métier dans chaque prompt. Il peut consulter le catalogue et ne demander que les éléments liés à la tâche en cours.

Le dépôt comprend également un outil en ligne de commande Go. Ses commandes documentées initialisent des bundles, créent des concepts, mettent à jour des fiches, recherchent du texte et valident les relations. Une commande d’amorçage peut ajouter le répertoire de connaissances, des consignes pour les agents et des fichiers de projet de support à un autre dépôt.

Un serveur MCP intégré expose la mémoire aux clients compatibles. MCP est un protocole qui permet à une application d’IA de se connecter à un contexte externe et à des outils exécutables. La spécification MCP officielle distingue les ressources, les prompts et les outils invoqués par le modèle.

Cette combinaison est plus importante qu’un simple modèle de fichier de mémoire. Un modèle définit où placer les notes. OKF Agent Memory cherche aussi à définir comment les agents effectuent leurs recherches, évaluent la confiance, consignent les sources, détectent l’obsolescence et évitent les concepts en double.

Le projet fonde ses fiches sur l’Open Knowledge Format de Google, ou OKF. Google décrit OKF comme un format neutre vis-à-vis des fournisseurs, utilisant Markdown et un front matter YAML. Les producteurs et les consommateurs n’ont pas besoin d’utiliser le même fournisseur de modèles, framework d’agents ou système de service.

OKF Agent Memory étend cette base vers le développement logiciel. Sa structure d’exemple couvre les décisions, l’architecture, les opérations et les faits du projet. Le dépôt contient également des instructions destinées à apprendre à un agent quand rechercher ou mettre à jour le bundle.

Le fil Hacker News du 6 septembre est resté modeste dans l’instantané fourni, avec 11 points et deux commentaires. Ces chiffres constituent un signal précoce, et non une validation large par la communauté. L’actualité intéressante est le choix d’implémentation, pas le nombre de votes.

Le projet transforme la mémoire en éléments que les développeurs peuvent examiner avec des éditeurs ordinaires. Les équipes peuvent également revoir les modifications via des pull requests et comparer les révisions avec Git. Il s’agit d’un modèle de confiance différent de l’acceptation de tout ce qu’un service de mémoire privé récupère.

Il crée aussi un contrat de maintenance exigeant. Dès qu’un dépôt qualifie un document de « mémoire », les développeurs peuvent supposer qu’il reflète le système actuel. Une note d’architecture obsolète peut induire un agent en erreur plus efficacement que l’absence totale de note.

Cette tension explique pourquoi le lancement mérite un examen attentif. OKF Agent Memory facilite la visibilité et la circulation du contexte persistant. Il doit encore démontrer que les équipes et les agents peuvent maintenir ce contexte exact.

Pourquoi la mémoire native de Git pour les agents arrive maintenant

Les agents de programmation de longue durée transforment la gestion du contexte en composante de l’infrastructure logicielle plutôt qu’en commodité d’interface de chat.

Une courte session de programmation peut s’appuyer sur la conversation en cours et les fichiers voisins. Les travaux plus longs révèlent les limites de cette approche. L’agent perd son raisonnement antérieur après une compaction, démarre une nouvelle session ou transmet le travail à un autre processus disposant d’un contexte différent.

Les fichiers d’instructions du dépôt répondent à une partie du problème. Ils peuvent décrire les commandes de build, les standards de programmation, les limites entre répertoires et les avertissements récurrents. Leur faiblesse tient à l’échelle, car chaque instruction chargée largement consomme de l’attention et du contexte.

Anthropic documente désormais deux formes distinctes de mémoire Claude Code. Les développeurs maintiennent des fichiers CLAUDE.md, tandis que l’outil peut également écrire des notes de mémoire automatique. L’index de mémoire automatique documenté comporte des limites au démarrage, avec des fichiers thématiques supplémentaires lus si nécessaire.

Cette architecture reconnaît un point important. La mémoire persistante ne peut pas être un seul prompt qui s’étend indéfiniment. Elle a besoin d’un index, de règles de récupération, de limites de portée et d’un moyen de séparer les conseils à forte valeur des détails occasionnels.

Le dépôt public Codex d’OpenAI contient également des composants liés à la mémoire et des modèles de stockage gérés par Git. Ces implémentations diffèrent, mais elles pointent vers le même impératif opérationnel. Les agents ont besoin de continuité entre les sessions sans envoyer l’historique complet d’un projet dans chaque appel au modèle.

OKF Agent Memory arrive à cette transition. Il considère le dépôt comme la frontière partagée entre les humains, les agents, les machines et les fournisseurs. Ce choix offre aux équipes un lieu familier pour la revue, la synchronisation et le contrôle des accès.

Git enregistre déjà qui a modifié un fichier, quand il a été modifié et en quoi il diffère des versions antérieures. L’aperçu de Git de GitHub met en avant le clonage, les branches, les commits, les fusions et la comparaison des modifications. Ces fonctionnalités peuvent également encadrer les connaissances rédigées par des agents.

Cette dynamique reflète aussi l’intérêt croissant pour un contexte portable. Les entreprises utilisent de plus en plus d’un assistant de programmation, parfois au sein du même dépôt. Un système de mémoire lié au répertoire privé d’un seul client peut fragmenter ce que les agents savent.

Un format local au dépôt offre une réponse plausible. Claude Code, Codex, Cursor et un autre client compatible MCP pourraient consulter les mêmes connaissances approuvées. Les développeurs n’auraient pas à traduire chaque décision dans plusieurs magasins propriétaires.

Le format est important, car Markdown seul ne communique pas suffisamment de structure. Un document a besoin d’identifiants, de types, de relations, de provenance et de signaux de fraîcheur si des machines doivent le maintenir. Sans cela, la récupération devient une recherche parmi des notes aux intitulés imprécis.

Google a introduit OKF pour normaliser cette couche. Sa mise à jour de juillet 2026 a ajouté des fonctionnalités orientées confiance après que des contributeurs ont soulevé des questions sur les corpus rédigés par des agents. Le modèle de confiance OKF inclut des notions telles que la provenance et l’état du cycle de vie.

OKF Agent Memory adopte cette orientation et lui ajoute des outils pour les développeurs. Le projet indique que les fiches peuvent distinguer le contenu généré du contenu vérifié. Il prend également en charge des champs qui indiquent le statut et le moment où un concept devient obsolète.

Ces champs ne garantissent pas la vérité. Ils fournissent des points d’ancrage pour les processus de revue et les vérifications automatisées. Leur véritable valeur dépend de l’application cohérente qu’en font les équipes et du respect qu’en ont les agents lors de la récupération.

C’est pourquoi la mémoire native de Git est devenue crédible aujourd’hui. Les agents de programmation accomplissent des tâches plus longues, le contexte devient coûteux et les équipes veulent des connaissances portables. La question restante est de savoir si un système fondé sur des fichiers peut rester fiable sous une écriture automatisée continue.

La principale opposition porte sur la mémoire révisable face à la récupération privée

L’argument le plus fort d’OKF Agent Memory n’est pas une recherche plus rapide. C’est que la mémoire partagée devrait passer par le même système de revue que le code.

Les services de mémoire adossés à une base de données optimisent généralement le rappel. Ils peuvent intégrer des conversations, des documents ou des observations sous forme de vecteurs et récupérer des contenus sémantiquement similaires. Cette approche aide lorsqu’une requête emploie des mots différents de ceux du texte stocké.

OKF Agent Memory utilise BM25, une méthode de classement lexical qui évalue les documents selon les termes correspondants et leur importance relative. Le dépôt indique que sa recherche en mémoire s’exécute en moins de 300 microsecondes. Il revendique également une faible empreinte mémoire et l’absence de service de récupération externe.

Ces chiffres proviennent de benchmarks fournis par le projet. Ils n’ont pas été validés indépendamment dans les éléments disponibles pour ce rapport. Les comparaisons avec d’autres systèmes peuvent aussi refléter des différences de matériel, de taille des corpus, d’étapes d’indexation et d’hypothèses réseau.

Il est peu probable que la rapidité tranche le débat plus large. L’inférence du modèle et l’orchestration des outils prennent souvent beaucoup plus de temps qu’une recherche de texte locale. Gagner quelques millisecondes importe dans des boucles répétées, mais la qualité de récupération et la gouvernance comptent davantage lorsqu’un agent modifie du code de production.

Le modèle natif de Git fait de chaque fiche mémoire un artefact inspectable. Un développeur peut voir quand un agent a ajouté une affirmation, en contester la source, demander une correction ou annuler la modification. Une équipe peut exiger une revue pour les fiches architecturales importantes.

La récupération privée offre un autre avantage. Elle peut conserver des observations personnelles, des détails conversationnels et des hypothèses de travail sans les ajouter à un dépôt partagé. Cette séparation peut être utile lorsque les notes sont provisoires, sensibles ou sans intérêt pour les autres contributeurs.

Les deux modèles répondent donc à des portées différentes. La mémoire automatique locale peut conserver les préférences d’un utilisateur et les enseignements propres à une machine. La mémoire du dépôt peut transporter des connaissances de projet approuvées entre les contributeurs et les outils.

OKF Agent Memory devient particulièrement utile lorsqu’il refuse de tout absorber. Une commande de test ayant échoué peut mériter une note de session temporaire. Une contrainte de déploiement confirmée, une décision d’authentification ou une dépendance de migration peut mériter une fiche de projet revue.

Cette distinction rappelle une gestion des connaissances plus large. Capturer l’information n’est que la première étape. Un système utile doit l’organiser, la récupérer au bon moment et exposer assez de contexte pour en évaluer la fiabilité.

Prenons une migration de service. Un agent découvre qu’un client historique dépend d’un champ de réponse non documenté. Il enregistre cette dépendance avec une source, un statut et les composants concernés. Un autre agent retrouve ensuite cette fiche avant de modifier l’API.

Dans le meilleur des cas, la mémoire évite une régression. Le développeur qui examine la modification finale peut relier l’avertissement à des éléments probants. La connaissance accompagne la branche et reste disponible pour un autre agent compatible.

Dans le pire des cas, le premier agent interprète mal la dépendance. L’enregistrement devient alors une fausseté durable, dotée de métadonnées d’apparence professionnelle. Les agents futurs le récupèrent, évitent une modification pourtant sûre et renforcent l’erreur par des références répétées.

Une base de données vectorielle peut subir le même échec. Son opacité peut toutefois rendre la chaîne plus difficile à inspecter. Git rend l’erreur visible, mais cette visibilité n’aide que lorsqu’une personne examine la modification concernée.

Le projet traite la duplication au moyen d’une convention de recherche avant écriture. Les agents doivent interroger les concepts existants avant de créer un nouvel enregistrement. Cela peut réduire les notes parallèles qui décrivent la même décision avec une formulation contradictoire.

La recherche lexicale introduit toutefois sa propre limite. BM25 favorise les mots partagés et peut donc manquer des enregistrements liés sur le plan conceptuel qui emploient une terminologie différente. Un document sur la « rotation des identifiants » peut ne pas être bien classé pour une requête formulée autour du « renouvellement des secrets ».

Les équipes peuvent réduire cet écart de vocabulaire avec des conventions de nommage, des alias et des liens croisés. Elles peuvent aussi ajouter plus tard une couche de récupération sémantique. Le corpus natif de Git n’empêche pas une indexation plus riche, car le matériau source reste accessible.

Cette flexibilité renforce l’argument central du projet. Le dépôt constitue le système d’enregistrement, tandis que BM25 n’est qu’une méthode d’accès remplaçable. Les équipes ne sont pas tenues de confier la mémoire canonique à un index particulier.

L’enjeu n’oppose donc pas les fichiers aux bases de données dans l’absolu. Il oppose un matériau source révisé et portable à une mémoire enfermée dans un unique service de récupération. OKF Agent Memory parie que les connaissances durables doivent rester lisibles même lorsque la pile d’agents environnante évolue.

Une recherche rapide ne peut pas résoudre la dégradation de la mémoire

Le problème le plus difficile consiste à décider ce qui mérite de devenir mémoire, qui le vérifie et à quel moment un agent doit cesser de lui faire confiance.

Les affirmations de performance du projet attirent l’attention parce qu’elles sont faciles à mesurer. Son dépôt cite une recherche en moins de 300 microsecondes, une validation de graphe d’environ quatre millisecondes et une réduction de 80 % de l’utilisation des tokens. Il s’agit toujours d’affirmations du projet fondées sur sa configuration de benchmark fournie.

La réduction des tokens dépend de la base de comparaison. Un index structuré devrait utiliser moins de tokens que le chargement d’un seul document volumineux, mais le pourcentage varie selon le corpus et la tâche. Il change également lorsque la récupération manque un concept nécessaire et impose des recherches supplémentaires.

La latence de recherche pose un problème similaire. Comparer BM25 en local à une API d’embeddings distante mélange les différences algorithmiques et la surcharge réseau. Une évaluation équitable isolerait l’indexation, le traitement des requêtes, la taille du corpus, la pertinence, les démarrages à froid et la réussite des tâches de bout en bout.

Le test le plus important concerne les résultats. La mémoire aide-t-elle les agents à accomplir les tâches du dépôt avec moins de corrections ? Empêche-t-elle les erreurs architecturales répétées ? Réduit-elle le temps passé à redécouvrir les contraintes de build ?

Un benchmark devrait aussi mesurer les récupérations nuisibles. Un agent peut trouver rapidement un ancien document et prendre malgré tout une moins bonne décision. Une fausse confiance dans un enregistrement structuré peut créer davantage de risques qu’un aveu explicite d’absence de contexte.

OKF v0.2 fournit des champs utiles pour ce problème. La provenance peut identifier l’origine d’une affirmation. Les états de confiance peuvent séparer le contenu généré du contenu vérifié. Les métadonnées d’expiration peuvent avertir qu’un enregistrement doit être revérifié.

Ces mécanismes ont besoin d’être appliqués. Un agent doit traiter les notes générées comme des hypothèses, et non comme des faits. La validation doit détecter les structures défectueuses, tandis que la revue humaine doit traiter le sens. Aucun schéma ne peut déterminer si une décision architecturale correspond toujours au logiciel déployé.

Les branches créent une autre complication. Deux agents peuvent mettre à jour des mémoires liées sur des branches distinctes tout en modifiant le même système. Git peut révéler le conflit textuel, mais il ne peut pas réconcilier automatiquement les interprétations sous-jacentes.

La mémoire du dépôt peut également contenir du matériel sensible. Les agents peuvent enregistrer accidentellement des informations client, des endpoints internes, des identifiants ou des conclusions de sécurité. Une fois validé et poussé, supprimer ce contenu des fichiers actuels n’efface pas toutes les copies historiques.

Les équipes ont donc besoin des mêmes règles d’analyse des secrets et de traitement des données que pour le code. Les modifications de mémoire doivent identifier leurs sources sans copier de données restreintes. La mémoire personnelle sensible doit rester en dehors d’un dépôt partagé.

L’injection de prompt représente une menace associée. Un document malveillant ou compromis pourrait contenir du texte cherchant à rediriger le comportement d’un agent. Le front matter structuré ne neutralise pas les instructions cachées dans le contenu.

MCP ajoute une autre frontière à examiner. Le protocole permet aux serveurs d’exposer du contexte et des outils, mais l’hôte reste responsable des autorisations et de l’isolation. Un serveur de mémoire local ne devrait recevoir que les accès dont il a besoin et ne devrait pas devenir une autorité incontestée.

Le positionnement sans dépendances du projet mérite également d’être précisé. Son module Go peut éviter les paquets d’exécution tiers, et la récupération locale peut éviter une base de données externe. Les utilisateurs dépendent toujours de Git, d’un client d’agent, des contrôles du système d’exploitation et du service de modèle qu’ils ont choisi.

De même, la neutralité vis-à-vis des fournisseurs est une propriété architecturale, non un résultat d’adoption. Un format devient portable lorsque plusieurs outils indépendants le lisent et l’écrivent de manière cohérente. Les affirmations de compatibilité nécessitent des tests sur les versions réelles de Claude Code, Codex, Cursor et d’autres clients.

L’historique public du dépôt était extrêmement récent au moment de l’examen. Cela limite les preuves relatives à la gouvernance des contributeurs, à la stabilité des versions, au comportement des migrations et au maintien de la compatibilité. Un code précoce peut néanmoins offrir une conception utile, mais les équipes ne doivent pas confondre exhaustivité et maturité.

Une évaluation pratique devrait commencer avec un corpus restreint. Les équipes pourraient enregistrer des décisions architecturales révisées, des contraintes opérationnelles et des problèmes de build récurrents. Elles devraient exclure les transcriptions brutes et les spéculations non vérifiées.

Les réviseurs peuvent ensuite vérifier si les agents récupèrent les bons enregistrements lors de tâches réelles. Ils devraient suivre les concepts manqués, les indications obsolètes, les entrées dupliquées et l’utilisation inutile de tokens. Ces résultats comptent davantage qu’un microbenchmark pris isolément.

Cette approche protège également le dépôt contre sa transformation en dépôt fourre-tout. La mémoire persistante mérite sa place lorsqu’elle réduit la confusion future. Si les développeurs ne peuvent pas expliquer pourquoi un enregistrement devrait perdurer, il relève probablement du contexte de travail temporaire.

Git donne aux équipes responsabilité et capacité de récupération. Il ne fournit pas de jugement éditorial. OKF Agent Memory ne réussit que lorsque ses conventions transforment ce jugement en un workflow reproductible.

Trois signaux détermineront si le lancement sur Hacker News compte réellement

L’adoption, les résultats indépendants sur des tâches et le comportement de gouvernance montreront si OKF Agent Memory devient une infrastructure ou reste un dépôt intéressant.

Le premier signal est l’utilisation entre clients. Il faut observer si des développeurs exécutent un même bundle OKF partagé via plusieurs agents de codage sans réécrire les enregistrements. Des intégrations confirmées et des tests de compatibilité renforceraient l’affirmation de portabilité.

Une interface MCP est utile, car les clients compatibles peuvent accéder à la même surface serveur. Pourtant, la compatibilité de protocole ne garantit pas la cohérence des comportements. Un agent peut chercher avant de modifier, tandis qu’un autre peut ignorer la mémoire sans prompt explicite.

Les tests utiles devraient indiquer quels clients ont été employés, comment leurs instructions étaient configurées et s’ils respectaient les métadonnées de confiance. Ils devraient aussi décrire les échecs. Un badge de compatibilité sans preuve de récupération n’apporterait guère de confiance.

Le deuxième signal est une évaluation indépendante sur de véritables tâches de codage. Des testeurs externes devraient comparer l’exécution des tâches sans mémoire, avec des instructions monolithiques, une mémoire automatique native et le bundle OKF. Ils devraient mesurer les corrections, la précision de récupération, l’utilisation des tokens, le temps écoulé et les régressions.

De tels résultats pourraient confirmer le mécanisme du projet même si ses chiffres phares évoluent. Une réduction moindre des tokens associée à moins d’erreurs répétées resterait significative. Une récupération rapide sans amélioration de la qualité des tâches affaiblirait l’argument.

La taille du corpus sera importante. Un bundle contenant 50 concepts diffère fortement d’un dépôt mature avec des années de décisions et d’historique opérationnel. Les performances et la pertinence devraient rester utiles à mesure que la terminologie, les équipes et les architectures évoluent.

Le troisième signal est la qualité des modifications de mémoire. Il faut observer si les contributeurs révisent les enregistrements rédigés par des agents, marquent correctement les affirmations incertaines et retirent les connaissances obsolètes. Les dépôts sains devraient montrer des corrections et des suppressions, plutôt qu’une accumulation sans fin.

Ce signal de gouvernance pourrait être plus difficile à intégrer dans un benchmark. Il est aussi le plus proche de la promesse centrale du projet. Une couche de mémoire devrait rendre l’incertitude visible et améliorer la décision suivante, plutôt que simplement conserver davantage de texte.

La réaction sur Hacker News elle-même doit être lue avec prudence. Onze points et deux commentaires montrent que le projet est entré dans une communauté techniquement engagée. Ils ne révèlent ni une utilisation durable, ni une fiabilité en production, ni un consensus autour de la mémoire native de Git.

Une discussion plus large deviendrait significative si les mainteneurs faisaient état de déploiements concrets et de cas d’échec. Les retours les plus précieux expliqueront où la recherche a manqué du contexte, où les enregistrements ont dérivé et où la revue a empêché une erreur d’agent.

Les développeurs qui évaluent le projet devraient examiner les fichiers avant d’adopter ses affirmations. Ils peuvent reproduire les benchmarks inclus, examiner la convention de mémoire et tester un petit bundle sur des tâches de dépôt récurrentes. Ils devraient conserver les enregistrements générés visiblement non vérifiés jusqu’à ce qu’une personne ou un processus de confiance les contrôle.

Les équipes qui maintiennent déjà de longs fichiers d’instructions disposent d’une expérience claire. Déplacez les connaissances détaillées et spécifiques aux tâches dans des enregistrements indexés tout en gardant les règles essentielles concises. Comparez ensuite le comportement des agents avant et après ce changement.

Les organisations utilisant plusieurs assistants de codage ont une question encore plus précise. Un corpus de mémoire révisé peut-il réduire la duplication propre à chaque outil sans créer une nouvelle charge de maintenance ? Ce résultat soutiendrait l’approche native de Git plus fortement que la vitesse de recherche.

Le projet s’inscrit également dans une évolution plus large des connaissances d’ingénierie. Les agents de codage ont besoin d’accéder aux décisions et au contexte opérationnel, et pas seulement aux fichiers source. Les équipes ont besoin que ce contexte reste consultable, attribuable et corrigeable.

OKF Agent Memory propose une réponse précoce cohérente. Stocker les connaissances durables du projet dans des fichiers ouverts, les suivre avec Git, les exposer via MCP et ne récupérer les détails qu’en cas de besoin. Chaque élément s’appuie sur une technologie que les développeurs comprennent déjà.

Son problème non résolu est autant social que technique. Quelqu’un doit décider ce qui entre dans la mémoire, vérifier les affirmations importantes, résoudre les enregistrements concurrents et retirer les connaissances obsolètes. Une recherche BM25 plus rapide ne peut pas assumer seule ces responsabilités.

Les un à trois prochains mois devraient clarifier si les mainteneurs attirent des contributeurs indépendants, publient des résultats reproductibles entre clients et démontrent une revue disciplinée des connaissances. Ces signaux renforceraient l’histoire Hacker News. Leur absence laisserait le projet au stade de prototype réfléchi doté de benchmarks internes ambitieux.

Pour les développeurs, l’action immédiate n’est pas de migrer toutes les notes. Sélectionnez une source récurrente de confusion pour les agents et représentez-la comme une connaissance révisée et versionnée. Testez ensuite si un autre agent peut la trouver, comprendre sa provenance et apporter une meilleure modification.

Cette expérience pose la bonne question finale : la mémoire persistante aide-t-elle la prochaine session de codage à prendre une décision plus exacte, ou préserve-t-elle simplement les hypothèses d’hier ?