Accueil › Glossaire › Procedural Memory

Procedural Memory (Mémoire Procédurale)

La procedural memory (mémoire procédurale) est un type de mémoire à long terme qui stocke le savoir-faire d’un agent IA : procédures réutilisables, skills exécutables, workflows appris, et stratégies d’action éprouvées qui permettent à l’agent de résoudre des tâches sans repartir de zéro.

Qu’est-ce que la procedural memory en IA ?

En psychologie cognitive, la mémoire procédurale est celle du savoir-faire : faire du vélo, taper au clavier, jouer du piano. Ce sont des compétences acquises par la pratique, exécutées automatiquement sans effort conscient. Contrairement à la mémoire déclarative (épisodique et sémantique), la mémoire procédurale est implicite : vous ne pouvez pas facilement expliquer comment vous faites du vélo, mais votre corps le sait.

Transposée aux agents IA, la procedural memory représente les compétences opérationnelles de l’agent : les procédures qu’il a apprises pour accomplir des tâches, les workflows validés, les stratégies d’action qui fonctionnent, et le code réutilisable qu’il a accumulé. C’est la différence entre savoir que « PostgreSQL supporte les requêtes JSON » (semantic memory) et savoir comment écrire une migration qui restructure un schéma JSON en production sans downtime (procedural memory).

Dans le cadre CoALA (Cognitive Architectures for Language Agents), la mémoire procédurale peut résider à trois endroits : dans le code source de l’agent (les procédures codées en dur), dans les prompts et templates (les instructions qui guident le comportement), et dans les paramètres du LLM lui-même (les patterns appris durant l’entraînement). La tendance récente est d’externaliser cette mémoire pour la rendre modifiable sans ré-entraînement ni redéploiement.

Place dans la taxonomie CoALA

Le framework CoALA organise la mémoire d’un agent en quatre modules. La procedural memory occupe une place unique : elle est la seule qui soit directement exécutable.

La distinction fondamentale : l’episodic et la semantic memory sont déclaratives (elles stockent des informations que l’agent consulte), tandis que la procedural memory est opérationnelle (elle stocke des programmes que l’agent exécute). Un agent consulte sa semantic memory pour savoir quelles APIs sont disponibles, consulte sa episodic memory pour se rappeler comment un bug similaire a été résolu, et utilise sa procedural memory pour exécuter la séquence de commandes qui résout le bug.

Les formes de la procedural memory en IA

Skills comme code exécutable

La forme la plus concrète de procedural memory : des fonctions ou scripts que l’agent peut invoquer directement. C’est l’approche de Voyager, l’agent emblématique de cette catégorie. Voyager, développé chez NVIDIA et publié en 2023, est un agent qui explore le monde de Minecraft en accumulant une bibliothèque de skills sous forme de programmes JavaScript.

Chaque skill est une fonction exécutable (par exemple, craftIronPickaxe()) indexée par l’embedding de sa description. Quand l’agent rencontre une tâche similaire à une tâche déjà résolue, il récupère le skill correspondant par recherche sémantique et l’exécute directement. Les skills complexes sont composés de skills plus simples, ce qui permet une accumulation rapide de compétences. Voyager obtient 3,3x plus d’items uniques que les approches précédentes et généralise ses compétences à de nouveaux mondes Minecraft.

L’avantage clé de cette approche : les skills sont interprétables, réutilisables et composables. Contrairement aux poids d’un réseau de neurones, on peut lire, modifier et déboguer une fonction JavaScript. Et l’accumulation de skills évite le catastrophic forgetting, un problème récurrent des approches par fine-tuning.

Prompts, playbooks et context engineering

Une forme plus légère de procedural memory : les instructions textuelles qui guident le comportement de l’agent. Un fichier skills.md qui décrit les procédures à suivre, un system prompt qui encode les règles d’action, un playbook qui liste les étapes d’un workflow métier. L’agent ne génère pas de code, il suit des instructions en langage naturel.

Cette approche est utilisée en production par de nombreux frameworks. Le pattern « context playbook » consiste à extraire les apprentissages d’épisodes passés (ce qui a fonctionné, ce qui a échoué) et à les compiler dans un document injecté dans le contexte de l’agent à chaque exécution. Des benchmarks montrent que cette technique améliore les performances de l’agent de plus de 10% sur les tâches agentiques et de près de 9% sur les tâches domaine, sans aucun fine-tuning du LLM.

Paramètres du modèle

La forme la plus implicite : les compétences encodées dans les poids du LLM via l’entraînement ou le fine-tuning. Un LLM entraîné sur des millions de lignes de code « sait » programmer en Python, même si ce savoir-faire n’est pas stocké comme une procédure explicite. C’est l’équivalent computationnel de la mémoire musculaire chez l’humain.

Le problème : cette mémoire est figée après l’entraînement et non modifiable à l’exécution. Pour ajouter une nouvelle compétence, il faut ré-entraîner ou fine-tuner, ce qui est coûteux et risque le catastrophic forgetting (oublier des compétences existantes en en apprenant de nouvelles). C’est pourquoi la recherche se tourne vers des mémoires procédurales externes.

État de la recherche (2026)

LEGOMem : mémoire procédurale modulaire pour multi-agents

LEGOMem (AAMAS 2026, Microsoft) est un framework de mémoire procédurale conçu spécifiquement pour les systèmes multi-agents. Son innovation : décomposer les trajectoires de tâches passées en unités de mémoire réutilisables, puis les distribuer entre l’orchestrateur et les agents spécialisés.

LEGOMem répond à une question architecturale que les systèmes mono-agent n’ont pas : où placer la mémoire procédurale dans un système multi-agents ? Faut-il que l’orchestrateur mémorise les plans de haut niveau, les agents individuels les procédures d’exécution, ou les deux ? L’étude montre que la combinaison (mémoire orchestrateur + mémoire agent) réduit le nombre d’étapes d’exécution de plus de 16% sur les tâches complexes par rapport à l’absence de mémoire.

Le constat clé de LEGOMem : la plupart des systèmes de mémoire actuels (Mem0, A-MEM, MemGPT) sont conçus pour des agents individuels et stockent principalement de la mémoire épisodique/sémantique issue des conversations. Ils ne sont pas adaptés à l’apprentissage agentique ni à l’automatisation de workflows multi-agents. La mémoire procédurale modulaire comble cette lacune.

MACLA : mémoire procédurale hiérarchique avec sélection bayésienne

MACLA (AAMAS 2026) pousse le concept plus loin avec une mémoire procédurale à deux niveaux :

Procédures : des séquences d’actions réutilisables extraites des trajectoires passées. Chaque procédure est associée à un score de fiabilité via un postérieur bayésien, mis à jour après chaque utilisation. Ce scoring permet à l’agent de choisir la procédure la plus fiable pour une tâche donnée, pas seulement la plus similaire sémantiquement.

Méta-procédures : des compositions de procédures fréquemment co-occurrentes, avec des politiques de contrôle conditionnelles (continuer, sauter, répéter, abandonner). C’est l’équivalent de playbooks stratégiques pour les tâches à horizon long.

Le résultat : un taux de réutilisation de 78% des actions depuis la mémoire (contre 62% sans sélection bayésienne), avec un footprint mémoire de seulement 3,6 Mo. L’ablation montre que la sélection bayésienne est le composant le plus critique, et que les méta-procédures sont essentielles pour la généralisation à des tâches non vues (chute de 11,9 points sans elles).

AWM et SkillWeaver : découverte autonome de compétences

Agent Workflow Memory (AWM) identifie les séquences de sous-tâches fréquemment utilisées et les compile en skills réutilisables. Plutôt que de stocker des trajectoires complètes comme exemplaires (approche Synapse), AWM extrait les patterns récurrents et les abstrait en procédures généralisables.

SkillWeaver (2025) va encore plus loin : les agents web découvrent et affinent leurs propres compétences de manière autonome, sans intervention humaine. Le parallèle avec Voyager est direct, mais appliqué à la navigation web plutôt qu’à Minecraft.

Le programme de recherche CASCADE (Cumulative Agentic Skill Creation through Autonomous Development and Evolution) et MeMp (Exploring Agent Procedural Memory, 2025) explorent la frontière entre découverte de compétences et mémoire procédurale persistante.

Implémentation : construire une procedural memory

Architecture d’une skill library

Le pattern de base d’une mémoire procédurale est la skill library : un ensemble de procédures indexées par leur description sémantique. Voici l’architecture type :

from dataclasses import dataclass, field
from typing import Callable, Optional
import json

@dataclass
class Skill:
    """Une procédure réutilisable dans la mémoire procédurale."""
    name: str
    description: str       # description en langage naturel
    code: str              # code exécutable (Python, JS, etc.)
    embedding: list        # vecteur pour la recherche sémantique
    success_count: int = 0
    failure_count: int = 0
    dependencies: list = field(default_factory=list)  # skills requis

    @property
    def reliability(self) -> float:
        """Score de fiabilité bayésien simplifié."""
        total = self.success_count + self.failure_count
        if total == 0:
            return 0.5  # prior uniforme
        return self.success_count / total


class ProceduralMemory:
    def __init__(self, vector_store, llm, executor):
        self.skills = {}          # name -> Skill
        self.vector_store = vector_store
        self.llm = llm
        self.executor = executor  # runtime pour exécuter le code

    def learn_from_trajectory(self, trajectory: list[dict]) -> list[Skill]:
        """Extrait des skills réutilisables d'une trajectoire."""
        # Le LLM abstrait la trajectoire en procédures
        prompt = f"""Analyse cette trajectoire d'exécution et identifie
les sous-procédures réutilisables. Pour chacune, génère :
- un nom descriptif
- une description en langage naturel
- le code exécutable
- les dépendances (skills requis)

Trajectoire : {json.dumps(trajectory)}"""

        extraction = self.llm.generate(prompt)
        new_skills = []

        for skill_data in extraction.skills:
            embedding = self.vector_store.embed(skill_data.description)
            skill = Skill(
                name=skill_data.name,
                description=skill_data.description,
                code=skill_data.code,
                embedding=embedding,
                dependencies=skill_data.dependencies
            )
            # Vérifier si un skill similaire existe déjà
            existing = self.retrieve(skill_data.description, top_k=1)
            if existing and existing[0].reliability > 0.7:
                # Fusionner avec le skill existant (raffinement)
                self._refine(existing[0], skill)
            else:
                self.skills[skill.name] = skill
                self.vector_store.upsert(skill.name, embedding)
                new_skills.append(skill)

        return new_skills

    def retrieve(self, task_description: str,
                 top_k: int = 5) -> list[Skill]:
        """Récupère les skills les plus pertinents pour une tâche."""
        query_embedding = self.vector_store.embed(task_description)
        results = self.vector_store.search(query_embedding, top_k=top_k)

        skills = [self.skills[r.id] for r in results if r.id in self.skills]
        # Trier par pertinence * fiabilité (inspiration MACLA)
        skills.sort(
            key=lambda s: s.reliability * results[0].score,
            reverse=True
        )
        return skills

    def execute(self, skill: Skill, context: dict) -> dict:
        """Exécute un skill et met à jour son score de fiabilité."""
        try:
            result = self.executor.run(skill.code, context)
            skill.success_count += 1
            return {"success": True, "result": result}
        except Exception as e:
            skill.failure_count += 1
            return {"success": False, "error": str(e)}

    def _refine(self, existing: Skill, new: Skill):
        """Raffine un skill existant avec une nouvelle version."""
        # Le LLM compare les deux versions et produit une fusion
        prompt = f"""Deux versions d'un skill similaire existent.
Version existante (fiabilité {existing.reliability:.2f}) :
{existing.code}

Nouvelle version :
{new.code}

Produis une version améliorée qui combine les forces des deux."""
        refined_code = self.llm.generate(prompt)
        existing.code = refined_code

Ce code illustre les concepts clés : les skills sont du code exécutable indexé par embedding, la fiabilité est trackée via un score bayésien, et le raffinement fusionne les versions via LLM. En production, ajoutez la gestion de la composition (un skill peut appeler d’autres skills via ses dépendances) et le pruning des skills peu fiables.

Le pattern playbook

Pour les cas où la mémoire procédurale est textuelle plutôt qu’exécutable, le pattern playbook est plus adapté :

class PlaybookMemory:
    """Mémoire procédurale basée sur des instructions textuelles."""

    def __init__(self, llm, store):
        self.llm = llm
        self.store = store  # key-value store persistant

    def extract_learnings(self, episode: dict) -> str:
        """Extrait les apprentissages d'un épisode terminé."""
        prompt = f"""Analyse cet épisode et extrais les règles d'action
réutilisables. Formule-les comme des instructions concises.

Épisode : {json.dumps(episode)}

Format : une règle par ligne, commençant par "QUAND ... ALORS ..."."""
        return self.llm.generate(prompt)

    def update_playbook(self, new_learnings: str):
        """Met à jour le playbook avec de nouveaux apprentissages."""
        current = self.store.get("playbook", "")
        prompt = f"""Voici le playbook actuel et de nouveaux apprentissages.
Fusionne-les en éliminant les doublons et les contradictions.
Priorise les règles les plus récentes en cas de conflit.

Playbook actuel :
{current}

Nouveaux apprentissages :
{new_learnings}"""
        updated = self.llm.generate(prompt)
        self.store.set("playbook", updated)

    def get_playbook(self) -> str:
        """Retourne le playbook pour injection dans le contexte."""
        return self.store.get("playbook", "")

Le playbook est injecté dans le system prompt de l’agent à chaque exécution. Au fil du temps, il accumule les meilleures pratiques découvertes empiriquement. C’est une approche plus simple que la skill library, mais particulièrement efficace pour les agents conversationnels et les assistants métier.

Procedural memory vs les autres types

Les trois types se nourrissent mutuellement. Les épisodes passés (episodic) fournissent le matériau brut pour extraire des procédures (procedural). Les connaissances factuelles (semantic) informent les conditions d’application des procédures. Et l’exécution des procédures génère de nouveaux épisodes qui enrichissent les deux autres mémoires.

Cas d’usage concrets

Agent de développement

Un agent comme Replit Agent ou un agent basé sur Claude Code accumule une mémoire procédurale de patterns de code : comment structurer un endpoint REST, comment écrire une migration de base de données, comment configurer un pipeline CI/CD. Au fil des projets, la skill library de l’agent s’enrichit de procédures de plus en plus sophistiquées. Quand un nouveau projet exige une fonctionnalité similaire à une précédente, l’agent récupère le skill correspondant et l’adapte au contexte actuel.

Automatisation de workflows d’entreprise

Dans les systèmes multi-agents d’entreprise (approbation de factures, onboarding employé, gestion d’incidents), la mémoire procédurale stocke les workflows validés. L’orchestrateur mémorise les plans de haut niveau (quels agents impliquer, dans quel ordre), et chaque agent spécialisé mémorise ses procédures spécifiques (comment valider un document, comment interroger le SIRH, comment notifier les parties prenantes). C’est exactement le problème que LEGOMem adresse.

Agent de navigation web

Un agent web qui automatise des tâches sur des sites apprend progressivement les procédures spécifiques à chaque interface : comment remplir un formulaire sur le site X, comment naviguer dans le menu Y, comment gérer les popups de cookies du site Z. SkillWeaver permet à ces agents de découvrir et affiner leurs compétences de manière autonome, sans que le développeur code chaque interaction.

Agent incarné (robotique)

Le cas de Voyager dans Minecraft s’étend aux agents robotiques : un robot qui apprend à manipuler des objets accumule une bibliothèque de gestes et séquences motrices réutilisables. Chaque nouveau skill (saisir un verre, ouvrir une porte, empiler des boîtes) est stocké comme programme exécutable et peut être composé avec d’autres pour des tâches complexes.

Défis et limites

Qualité d’extraction : convertir une trajectoire brute en procédure réutilisable exige une abstraction qui n’est pas triviale. Le LLM doit identifier quelles étapes sont spécifiques au contexte (à ignorer) et lesquelles sont généralisables (à conserver). Les extractions de mauvaise qualité polluent la skill library avec des procédures non fiables.

Gestion de la croissance : une skill library qui grandit indéfiniment devient difficile à parcourir. Le retrieval par similarité retourne des résultats de moins en moins pertinents quand la bibliothèque contient des milliers de skills. Les mécanismes de pruning (suppression des skills peu utilisés ou peu fiables) et de consolidation (fusion de skills redondants) sont essentiels. MACLA montre que 73% des skills prunés ont un taux de succès inférieur à 0,5, validant l’approche.

Composabilité : composer des skills simples en procédures complexes est le Saint Graal de la mémoire procédurale. Voyager le fait dans Minecraft (combiner « miner du fer » et « crafter » pour produire une pioche en fer), mais la composabilité dans des environnements réels (naviguer sur le web + interagir avec des APIs + gérer des erreurs) reste un défi de recherche ouvert.

Transfert inter-domaines : un skill appris dans un contexte se transfère-t-il à un autre ? La recherche par similarité sémantique offre un transfert approximatif (une procédure de « déploiement sur AWS » peut être partiellement utile pour « déploiement sur GCP »), mais les détails divergent. MACLA montre un taux de réutilisation variant de 51% (SQL) à 78% (ALFWorld), indiquant que la transférabilité dépend fortement du domaine.

Sécurité du code exécutable : stocker et exécuter automatiquement du code généré par LLM pose des risques de sécurité. Un skill mal extrait ou malicieusement injecté pourrait exécuter des opérations dangereuses. Les sandboxes d’exécution et les revues de code automatiques sont indispensables en production.

Verdict

La procedural memory est le type de mémoire le moins mature mais potentiellement le plus transformateur. L’episodic et la semantic memory permettent à un agent de se souvenir et de savoir. La procedural memory lui permet de savoir faire, et de s’améliorer en faisant.

Pour une implémentation immédiate, commencez par le pattern playbook : extrayez les apprentissages de vos épisodes passés dans un document textuel injecté dans le contexte. C’est simple, efficace (+10% sur les benchmarks), et ne nécessite aucune infrastructure supplémentaire.

Pour une architecture plus ambitieuse, inspirez-vous de Voyager (skill library de code exécutable) ou de LEGOMem (mémoire procédurale modulaire pour multi-agents). Ajoutez un scoring de fiabilité à la MACLA pour ne pas réutiliser aveuglément des procédures non éprouvées.

Le principe directeur : gardez le LLM figé et externalisez l’apprentissage dans la mémoire procédurale. C’est plus efficace, plus interprétable, et plus sûr que le fine-tuning. La mémoire procédurale est ce qui transforme un agent réactif en agent qui s’améliore continuellement.