{"title":"Bonnes pratiques mémoire","slug":"memory-best-practices","category":"guides","summary":"Comment structurer les mémoires pour un rappel efficace — catégories, clés, tags, priorités.","audience":["human","llm"],"tags":["guide","memory","best-practices","patterns"],"difficulty":"intermediate","updated":"2026-06-27","word_count":729,"read_minutes":4,"lang":"fr","translated":true,"requested_lang":"fr","content_markdown":"\n# Bonnes pratiques mémoire\n\nLa façon dont vous structurez les mémoires détermine leur utilité. Ce guide couvre\nles schémas pour catégoriser, tagger et prioriser les mémoires afin que le LLM puisse\nrappeler la bonne information au bon moment.\n\n## Catégories : choisissez la plus spécifique\n\n| Catégorie | Utiliser pour | Exemple |\n|----------|---------|---------|\n| `identity` | Nom d'utilisateur, rôle, infos de contact | `\"user_name\": \"Michael Schäfer\"` |\n| `preference` | Goûts, aversions, style de travail | `\"communication\": \"Prefers concise responses\"` |\n| `fact` | Faits vérifiables | `\"office_location\": \"Berlin, Germany\"` |\n| `project` | Statut de projet, décisions | `\"project_synapse\": \"v1.5.0 deployed\"` |\n| `skill` | Compétences de l'utilisateur | `\"skill_python\": \"Advanced, 10+ years\"` |\n| `mistake` | Erreurs passées à éviter | `\"mistake_npm_version\": \"Always bump version\"` |\n| `context` | Contexte pertinent à la session | `\"current_focus\": \"Working on docs system\"` |\n| `note` | Notes diverses | `\"note_idea\": \"Try Redis for caching\"` |\n\n> [!TIP]\n> En cas de doute, utilisez `fact` pour les infos vérifiables et `note` pour tout le\n> reste. Ne sur-catégorisez pas — mieux vaut avoir un `fact` clair qu'un `context`\n> confus.\n\n## Clés : identifiants significatifs\n\nLe champ `key` est l'identifiant de la mémoire. Utilisez des clés significatives et\nstables :\n\n**Bonnes clés :**\n- `user_name`\n- `project_synapse_status`\n- `preference_communication_style`\n- `mistake_npm_version_bump`\n\n**Mauvaises clés :**\n- `mem_001` (non significative)\n- `temp` (non descriptive)\n- `2026-06-27-note` (la date n'aide pas le rappel)\n\n### Conventions de nommage des clés\n\n- `snake_case` (minuscules avec tirets bas)\n- Préfixez avec la catégorie : `preference_*`, `project_*`, `mistake_*`\n- Utilisez des noms descriptifs, pas des verbes\n- Gardez en dessous de 50 caractères\n\n## Tags : pour la recherche et le filtrage\n\nLes tags permettent le filtrage et la recherche rapides. Ajoutez 2-5 tags par mémoire :\n\n```json\n{\n \"category\": \"project\",\n \"key\": \"project_synapse_status\",\n \"content\": \"Synapse v1.5.0 deployed. Next: v1.6.0 with docs system.\",\n \"tags\": [\"synapse\", \"deployment\", \"status\", \"v1.5.0\"]\n}\n```\n\n### Schémas de tags\n\n- **Noms de projet** : `synapse`, `synapse-mcp`, `synapse-chat`\n- **Sujets** : `deployment`, `ci`, `database`, `auth`\n- **Statut** : `active`, `completed`, `blocked`\n- **Indicateurs de priorité** : `urgent`, `long-term`\n\n> [!NOTE]\n> Les tags sont insensibles à la casse. Utilisez des minuscules pour la cohérence.\n\n## Priorités : soyez réaliste\n\n| Priorité | Utiliser pour | % des mémoires |\n|----------|---------|---------------|\n| `critical` | Identité utilisateur, infos légales, décisions irréversibles | ~5 % |\n| `high` | Projets actifs, préférences importantes | ~20 % |\n| `normal` | La plupart des faits, notes, contexte | ~65 % |\n| `low` | Éphémère, utile à savoir | ~10 % |\n\n> [!WARNING]\n> Ne marquez pas tout `critical`. Si tout est critique, rien ne l'est. Réservez\n> `critical` pour ce qui causerait un réel préjudice si c'était oublié.\n\n## Quand stocker ou non\n\n### Toujours stocker\n\n- Identité utilisateur (nom, email, rôle)\n- Préférences longue durée\n- Décisions de projet et justification\n- Erreurs passées et leçons apprises\n- Engagements pris envers l'utilisateur\n\n### Ne pas stocker\n\n- État transitoire (utilisez plutôt des variables)\n- Historique de conversation verbatim (le système chat gère cela)\n- Données sensibles (mots de passe, clés API)\n- Faits facilement dérivables (date actuelle, contenu de fichiers)\n- Contexte éphémère (utilisez la catégorie `context` avec priorité basse)\n\n## Mettre à jour les mémoires\n\nPOST `/memory` avec la même `category` + `key` met à jour la mémoire existante :\n\n```python\n# Stockage initial\nstore(\"project\", \"project_synapse_status\", \"v1.4.0 deployed\", priority=\"high\")\n\n# Plus tard : mise à jour avec la même clé\nstore(\"project\", \"project_synapse_status\", \"v1.5.0 deployed. CI green.\", priority=\"high\")\n```\n\n> [!TIP]\n> Utilisez des clés stables pour pouvoir mettre à jour sans créer de doublons. Le LLM\n> doit re-POSTer la même clé quand les infos changent, pas créer de nouvelles mémoires.\n\n## Cycle de vie d'une mémoire\n\n```\nCreate → Active → Stale → Archive → Delete\n```\n\n- **Create** : POST /memory avec contexte complet\n- **Active** : Rappeler fréquemment, mettre à jour au besoin\n- **Stale** : Toujours pertinent mais pas activement utilisé (priorité plus basse ?)\n- **Archive** : Définir la priorité sur `low`, conserver pour référence historique\n- **Delete** : DELETE /memory/:id quand plus pertinent\n\n### Nettoyage périodique\n\n```python\n# Trouver les mémoires non mises à jour depuis 90 jours\nold_memories = requests.get(\n f\"{URL}/memory/search?q=*\",\n headers={\"Authorization\": f\"Bearer {KEY}\"}\n)\n\nfor mem in old_memories[\"results\"]:\n if is_stale(mem, days=90):\n # Soit supprimer, soit abaisser la priorité\n if is_obsolete(mem):\n delete_memory(mem[\"id\"])\n else:\n update_memory(mem[\"id\"], priority=\"low\")\n```\n\n## Schéma : héritage de mémoire\n\nPour un contexte hiérarchique (projet → sous-projet → tâche) :\n\n```python\n# Projet parent\nstore(\"project\", \"project_synapse\", \"Main Synapse project\", \n tags=[\"synapse\", \"parent\"], priority=\"high\")\n\n# Sous-projet (les tags lient au parent)\nstore(\"project\", \"project_synapse_docs\", \"Docs system for Synapse\",\n tags=[\"synapse\", \"docs\", \"synapse-parent\"], priority=\"high\")\n\n# Tâche spécifique (les tags lient au sous-projet)\nstore(\"project\", \"task_docs_loader\", \"Implement docs-loader.ts\",\n tags=[\"synapse\", \"docs\", \"task\"], priority=\"normal\")\n```\n\nLe LLM peut alors chercher `q=synapse+docs` pour trouver toutes les mémoires liées.\n\n## Schéma : journal de décisions\n\nStockez les décisions avec leur justification pour que le LLM ne les re-questionne\npas :\n\n```python\nstore(\"fact\", \"decision_postgres_over_sqlite\",\n \"Chose PostgreSQL over SQLite for production. Reason: concurrent writes, \"\n \"FTS5 native support, better backup story. Date: 2026-06-15. Decided by: Michael.\",\n tags=[\"decision\", \"database\", \"postgres\", \"sqlite\"],\n priority=\"high\")\n```\n\n## Schéma : évitement des erreurs\n\nStockez les erreurs avec des instructions d'évitement spécifiques :\n\n```python\nstore(\"mistake\", \"mistake_forget_version_bump\",\n \"Forgot to bump package.json version after changes. npm publish failed. \"\n \"FIX: Always run `npm version patch` before pushing. \"\n \"CI fails with 'version already exists' if you forget.\",\n tags=[\"npm\", \"ci\", \"publish\", \"version\"],\n priority=\"high\")\n```\n\n## Anti-schémas à éviter\n\n> [!WARNING]\n> - **Stocker les journaux de conversation** — le système chat gère cela\n> - **Stocker des fichiers entiers** — utilisez le script store ou le stockage externe\n> - **Stocker l'état éphémère** — utilisez des variables\n> - **Stocker des secrets** — utilisez des variables d'environnement\n> - **Dupliquer les mémoires** — utilisez des clés stables\n> - **Sur-tagger** — 2-5 tags par mémoire est idéal\n> - **Tout est critique** — soyez réaliste avec les priorités\n\n## Prochaines étapes\n\n- [API Memory](/docs/api/memory)\n- [Agent LLM persistant](/docs/guides/persistent-llm-agent)\n- [Stratégie de tagging mémoire](/docs/llm-cookbook/memory-tagging-strategy)\n","content_html":"

Bonnes pratiques mémoire

\n

La façon dont vous structurez les mémoires détermine leur utilité. Ce guide couvre\nles schémas pour catégoriser, tagger et prioriser les mémoires afin que le LLM puisse\nrappeler la bonne information au bon moment.

\n

Catégories : choisissez la plus spécifique

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
CatégorieUtiliser pourExemple
identityNom d'utilisateur, rôle, infos de contact"user_name": "Michael Schäfer"
preferenceGoûts, aversions, style de travail"communication": "Prefers concise responses"
factFaits vérifiables"office_location": "Berlin, Germany"
projectStatut de projet, décisions"project_synapse": "v1.5.0 deployed"
skillCompétences de l'utilisateur"skill_python": "Advanced, 10+ years"
mistakeErreurs passées à éviter"mistake_npm_version": "Always bump version"
contextContexte pertinent à la session"current_focus": "Working on docs system"
noteNotes diverses"note_idea": "Try Redis for caching"
\n
En cas de doute, utilisez `fact` pour les infos vérifiables et `note` pour tout le\nreste. Ne sur-catégorisez pas — mieux vaut avoir un `fact` clair qu'un `context`\nconfus.

Clés : identifiants significatifs

\n

Le champ key est l'identifiant de la mémoire. Utilisez des clés significatives et\nstables :

\n

Bonnes clés :

\n\n

Mauvaises clés :

\n\n

Conventions de nommage des clés

\n\n

Tags : pour la recherche et le filtrage

\n

Les tags permettent le filtrage et la recherche rapides. Ajoutez 2-5 tags par mémoire :

\n
{\n  "category": "project",\n  "key": "project_synapse_status",\n  "content": "Synapse v1.5.0 deployed. Next: v1.6.0 with docs system.",\n  "tags": ["synapse", "deployment", "status", "v1.5.0"]\n}

Schémas de tags

\n\n
Les tags sont insensibles à la casse. Utilisez des minuscules pour la cohérence.

Priorités : soyez réaliste

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
PrioritéUtiliser pour% des mémoires
criticalIdentité utilisateur, infos légales, décisions irréversibles~5 %
highProjets actifs, préférences importantes~20 %
normalLa plupart des faits, notes, contexte~65 %
lowÉphémère, utile à savoir~10 %
\n
Ne marquez pas tout `critical`. Si tout est critique, rien ne l'est. Réservez\n`critical` pour ce qui causerait un réel préjudice si c'était oublié.

Quand stocker ou non

\n

Toujours stocker

\n\n

Ne pas stocker

\n\n

Mettre à jour les mémoires

\n

POST /memory avec la même category + key met à jour la mémoire existante :

\n
# Stockage initial\nstore("project", "project_synapse_status", "v1.4.0 deployed", priority="high")\n\n# Plus tard : mise à jour avec la même clé\nstore("project", "project_synapse_status", "v1.5.0 deployed. CI green.", priority="high")
Utilisez des clés stables pour pouvoir mettre à jour sans créer de doublons. Le LLM\ndoit re-POSTer la même clé quand les infos changent, pas créer de nouvelles mémoires.

Cycle de vie d'une mémoire

\n
Create → Active → Stale → Archive → Delete
\n

Nettoyage périodique

\n
# Trouver les mémoires non mises à jour depuis 90 jours\nold_memories = requests.get(\n    f"{URL}/memory/search?q=*",\n    headers={"Authorization": f"Bearer {KEY}"}\n)\n\nfor mem in old_memories["results"]:\n    if is_stale(mem, days=90):\n        # Soit supprimer, soit abaisser la priorité\n        if is_obsolete(mem):\n            delete_memory(mem["id"])\n        else:\n            update_memory(mem["id"], priority="low")

Schéma : héritage de mémoire

\n

Pour un contexte hiérarchique (projet → sous-projet → tâche) :

\n
# Projet parent\nstore("project", "project_synapse", "Main Synapse project", \n      tags=["synapse", "parent"], priority="high")\n\n# Sous-projet (les tags lient au parent)\nstore("project", "project_synapse_docs", "Docs system for Synapse",\n      tags=["synapse", "docs", "synapse-parent"], priority="high")\n\n# Tâche spécifique (les tags lient au sous-projet)\nstore("project", "task_docs_loader", "Implement docs-loader.ts",\n      tags=["synapse", "docs", "task"], priority="normal")

Le LLM peut alors chercher q=synapse+docs pour trouver toutes les mémoires liées.

\n

Schéma : journal de décisions

\n

Stockez les décisions avec leur justification pour que le LLM ne les re-questionne\npas :

\n
store("fact", "decision_postgres_over_sqlite",\n      "Chose PostgreSQL over SQLite for production. Reason: concurrent writes, "\n      "FTS5 native support, better backup story. Date: 2026-06-15. Decided by: Michael.",\n      tags=["decision", "database", "postgres", "sqlite"],\n      priority="high")

Schéma : évitement des erreurs

\n

Stockez les erreurs avec des instructions d'évitement spécifiques :

\n
store("mistake", "mistake_forget_version_bump",\n      "Forgot to bump package.json version after changes. npm publish failed. "\n      "FIX: Always run `npm version patch` before pushing. "\n      "CI fails with 'version already exists' if you forget.",\n      tags=["npm", "ci", "publish", "version"],\n      priority="high")

Anti-schémas à éviter

\n

Prochaines étapes

\n\n","urls":{"html":"/docs/guides/memory-best-practices","text":"/docs/guides/memory-best-practices?format=text","json":"/docs/guides/memory-best-practices?format=json","llm":"/docs/guides/memory-best-practices?format=llm"},"translations_available":["en","zh","hi","es","fr","ar","pt","ru","ja","de","it","ko","nl","pl","tr","sv","vi","th","id","uk"]}