MEX : la mémoire d'équipe versionnée dans Git, du côté des agents de code

Le trou que MEX prétend boucher

Le problème est décrit sans détour dans le README : un ingénieur sait pourquoi une contrainte existe, un autre détient l'historique de débogage, et un agent de code a repéré un cas limite dans une session que personne ne lira. Le coût n'est pas le temps de recherche, c'est la reconstitution. MEX vise les équipes qui utilisent déjà Codex, Claude Code ou Cursor sur un dépôt partagé et qui constatent que le contexte utile meurt à la fin de la session. Le projet se présente comme une mémoire d'équipe pour les ingénieurs et leurs agents, et non comme un assistant de complétion. La nuance compte : le livrable n'est pas une réponse, c'est un artefact relu, commité et poussé.

Markdown dans le dépôt, index locaux à chacun

Le mécanisme central tient en une phrase du README : la mémoire canonique voyage avec les commandes Git ordinaires (commit, push, pull). Chaque coéquipier conserve ses propres index locaux, ses brouillons, sa sélection d'identité et son Hub. Autrement dit, le dépôt porte la source de vérité, les index sont un dérivé reconstructible. Le README précise qu'aucun service hébergé, ni Docker, ni proxy, ni compte MEX, ni clé de modèle détenue par MEX n'est nécessaire. Cette architecture a une conséquence directe sur les conflits : deux personnes qui modifient la même explication se retrouvent dans une fusion Git classique, pas dans une résolution opaque côté serveur. Les objets décrits sont nommés : Wiki pour l'architecture et les décisions, Inbox pour les propositions d'ajout ou de correction, Relays pour les passations, Specs et Workstream pour l'existant. Le graphe de code, construit avec tree-sitter d'après les sujets du dépôt, sert d'ancrage aux explications.

Le Hub local comme salle de relecture

Le Hub est l'endroit où l'on explore et où l'on approuve. Le README liste Home, Search, Context et Code pour relier explications et preuves d'implémentation ; le graphe Context affiche les entités de connaissance et leurs relations, et sélectionner une entité révèle ses ancrages de code directs. Inbox sert à proposer, Relays à conserver ce dont le prochain a besoin, Team/Members à l'attribution et au choix d'identité locale, Activity à l'historique des événements de workflow acceptés. Le point de vue à garder ici : c'est un outil de revue, pas de génération. Une connaissance n'entre pas dans la mémoire parce qu'un agent l'a produite, mais parce qu'un humain l'a validée. La note de version 0.8.1 ajoute au passage que le Hub peut continuer à répondre pendant la construction du graphe, ce qui indique que cette construction peut être longue sur un dépôt volumineux.

Installation et clés de configuration

Le paquet npm s'appelle mex-agent et le projet exige Node.js 22.5 ou plus récent, d'après les badges et package.json du dépôt. Le README renvoie à une section Quick start pour les commandes exactes, et cette section n'est pas reproduite dans le matériel fourni : je ne peux donc pas citer la commande d'initialisation ni le nom du binaire sans risquer d'inventer. Ce qui est nommé de façon fiable, ce sont les surfaces : un CLI, un Hub local, et un serveur MCP dont le badge indique source only, ce qui suggère qu'il faut le construire depuis les sources plutôt que l'installer comme binaire prêt à l'emploi. Les compétences destinées aux agents apparaissent sous forme de commandes comme $mex-relay dans l'exemple de passation. Côté configuration, le matériel fourni ne détaille pas de clés de configuration précises au-delà du fichier de serveurs MCP de votre client : vérifiez ce fichier dans votre clone avant de conclure quoi que ce soit sur l'intégration.

Le Relay ne transporte pas votre code

La limitation la plus importante est écrite noir sur blanc : le Relay transporte l'explication et l'état observé du dépôt, pas le code non commité. Publier écrit des fichiers dans votre copie de travail ; cela ne notifie personne et ne livre rien tant que le partage n'a pas lieu via Git. Si vous comptez sur MEX pour synchroniser un travail en cours entre deux machines, vous vous trompez d'outil. Le README renvoie à une section Relay boundaries pour le cycle de vie et la concurrence, ce qui laisse entendre que ces cas existent et sont documentés ailleurs. Deuxième réserve : le mode mémoire d'agent est présenté comme compatible, mais la documentation disponible ne permet pas de dire ce qu'il couvre réellement. Troisième : sur un dépôt déjà dense, la valeur dépend d'un graphe de code correctement construit, et rien dans le matériel fourni ne chiffre ce coût de construction.

Face à un simple fichier AGENTS.md

L'alternative la plus évidente n'est pas un concurrent commercial, c'est un fichier de contexte versionné à la main, du type AGENTS.md ou CLAUDE.md. La différence d'approche est nette. Un fichier unique est plat : il ne relie pas une décision à un fichier de code précis, il n'a pas de cycle de proposition et d'approbation, et il ne distingue pas une passation d'une règle permanente. MEX ajoute trois choses que le fichier plat n'a pas : un ancrage au code via le graphe, une file d'attente de propositions relues dans le Hub, et un objet de passation daté avec progression, décisions, blocages, preuves et prochaines actions. En contrepartie, vous héritez d'une chaîne d'outils Node, d'un serveur MCP à construire et d'un vocabulaire propre au projet. Pour une équipe de deux personnes sur un petit service, le fichier plat reste probablement le bon choix.

Coût de maintenance et portée de la licence MIT

Le rythme de publication est visible dans les données fournies : 0.7.3 le 26 août 2026, 0.8.0 le 2 septembre, 0.8.1 le 9 septembre. Trois versions en deux semaines sur une série 0.8, avec des notes qui parlent de performances de graphe et de récupération, puis d'exploration du contexte. Cela implique une relecture des notes de version à chaque montée, en particulier si vous dépendez du format des fichiers canoniques. La licence est MIT, ce qui autorise l'usage commercial et la modification ; le dépôt embarque un fichier LICENSE à la racine. Je ne donne pas d'avis juridique : si vous redistribuez MEX dans un produit, faites lire le texte de la licence par qui de droit, notamment sur la conservation de la mention de copyright. Le coût réel d'exploitation, lui, se situe dans la discipline humaine : approuver les propositions Inbox et publier les Relays, sinon la mémoire se remplit de brouillons que personne ne relit.

Conclusion éditoriale

À adopter si votre équipe perd du contexte entre deux sessions d'agent et que vous acceptez de relire des propositions de connaissances comme des pull requests. À éviter si vous cherchez une mémoire d'agent automatique et invisible : ici, l'approbation humaine est le mécanisme, pas une option. Avant de vous engager, vérifiez deux points dans votre clone : que le fichier de configuration des serveurs MCP correspond bien à votre client, et que la version de Node installée satisfait le prérequis du projet.

Sources officielles

1. License: MIT
2. mex-memory/mex on GitHub
3. Project website
4. README
5. Releases