Les sessions se terminent.
La mémoire reste.

Les connaissances qu'un agent IA peut utiliser dans une autre session que celle où il les a acquises. Pour un agent de codage, la plus utile est la mémoire de projet : décisions, pièges et conventions qui ne figurent nulle part dans le code source, stockés hors de l'agent et restitués quand le travail porte sur le code qu'ils régissent.

Un appel au modèle n'a pas de mémoire propre, mais les produits peuvent conserver des connaissances hors de la fenêtre de contexte. Les mémoires locales de Codex, la mémoire automatique de Claude Code et les fichiers d'instructions versionnés aident tous d'une session à l'autre. Reste à savoir ce qui est stocké, qui peut s'en servir et quand cela arrive. Pour aller plus loin : pourquoi les assistants de codage IA oublient votre base de code d'une session à l'autre.

Non, et la différence tient au moment de la transmission. Une API de mémoire répond quand on l'interroge, ce qui fonctionne quand vous maîtrisez le point d'appel dans votre propre produit. Un agent de codage ne sait pas ce qui lui manque : une contrainte sur laquelle il n'a jamais pensé à se renseigner ne lui parvient jamais. Une mémoire de projet lit le chemin où l'agent s'apprête à travailler et transmet les connaissances correspondantes avant le premier appel d'outil.

Pour un petit dépôt, un court fichier d'instructions suffit souvent. Claude Code prend en charge des règles liées à des chemins et le chargement conditionnel d'AGENTS.md ; Codex prend en charge les AGENTS.md imbriqués et les mémoires locales. Pathrule devient utile quand les mêmes connaissances d'espace de travail doivent atteindre différents agents, avec une sélection propre à chaque tâche et des exigences que l'on peut faire respecter. Comparaison détaillée : Pathrule vs fichiers d'instructions.

Les deux répondent à des questions différentes. Un index de votre dépôt peut dire à l'agent ce que dit actuellement le code, ce qui est utile quand la réponse existe mais que personne ne se souvient où. Il n'a rien à renvoyer pour une décision prise en revue et consignée nulle part, et c'est l'essentiel de ce que contient une mémoire de projet. Les deux coexistent : la recherche pour les fichiers, la mémoire pour le raisonnement. Pour aller plus loin : RAG vectoriel vs contexte lié aux chemins.

C'est l'appartenance qui décide. Mémoires, règles et skills vivent dans un graphe partagé indexé par chemin, avec un accès à l'espace de travail contrôlé côté serveur plutôt que dans le client. Voir rôles et permissions.

Pas nécessairement. Pathrule n'envoie pas automatiquement le code source de votre dépôt. En mode local, il n'y a pas de compte et les connaissances restent sur votre machine. En mode cloud, Pathrule Cloud stocke les mémoires, règles et skills rédigées par votre équipe, le début de chaque prompt est envoyé pour classer ce qui s'applique, et pathrule snapshot, lorsque vous ou votre agent le lancez, envoie l'arborescence de fichiers, les manifestes, de courts extraits de documentation et des métadonnées git récentes. Le détail complet figure sur la page Sécurité.

Rien, et c'est tout l'intérêt de la stocker hors de l'agent. Les mêmes mémoires parviennent à Claude Code, Codex, Cursor, GitHub Copilot, Windsurf et à tout autre client connecté via MCP : changer d'agent ne remet pas à zéro ce que l'équipe a consigné. Pour aller plus loin : la mémoire d'équipe ne devrait pas changer quand les outils d'IA changent.

Vous oubliez quand même, et l'agent aussi. En solo, ce que la mémoire vous apporte n'est pas le partage, c'est la version de vous-même d'il y a quatre mois : la raison pour laquelle vous avez écarté une approche, que vous rediscuterez sinon avec un agent qui ignore que la question a déjà été tranchée. L'effet s'amplifie si vous utilisez plusieurs agents, puisqu'aucun ne peut lire les notes des autres. Pathrule est gratuit pour un usage individuel. Quelle approche choisir explique quand c'est vraiment superflu.