Donnez une mémoire durable à vos agents IA : le pattern LLM Wiki appliqué dans Symfony

Pour résoudre cette amnésie chronique sans dépendre d'une infrastructure lourde de RAG (Retrieval-Augmented Generation), de serveurs MCP complexes ou d'un historique propriétaire cloud, il existe une méthode sobre, universelle et particulièrement efficace : la combinaison d'un socle AGENTS.md global et du pattern LLM Wiki popularisé par Andrej Karpathy, l’ancien directeur de l'IA chez Tesla et cofondateur d'OpenAI.

Le piège du contexte jetable dans le développement PHP

Lorsqu'on demande à un agent IA d'implémenter un composant, par exemple un système de cache sur un client HTTP externe, le premier réflexe est de fournir un prompt descriptif exhaustif. Sans contexte préexistant, la tâche exige de spécifier la version de PHP, la convention d'injection de dépendances, le composant de cache Symfony retenu (cache.app, Redis, Adapter personnalisé) et la structure des tests PHPUnit à produire.

Multipliée par des dizaines d'interactions quotidiennes, cette lourdeur nuit à la productivité. L'enjeu consiste donc à fournir à l'agent une mémoire persistante, portable et découplée du modèle sous-jacent.

Étape 1 : Structurer les instructions avec la double couche AGENTS.md

Le format AGENTS.md s’impose comme le : standard pour guider les assistants de code à la racine d’un dépôt. Il décrit la stack, les commandes de test et les règles propres à l’équipe. Cependant, restreindre ce fichier à un seul projet ne résout pas la question du contexte personnel du développeur.

La première étape consiste à exploiter deux niveaux d'instructions distincts :

• Le niveau Projet (./AGENTS.md) : propre à l'application Symfony sur laquelle vous travaillez. Il peut contenir les conventions du projet, les préférences de langue, les règles d’intégration continue de l'équipe etc..

Exemple : 

## Stack
- Symfony 7, PHP 8.3, Doctrine, Twig, PostgreSQL.

## Conventions
- Contrôleurs fins, logique dans des services autowirés.
- Migrations Doctrine ; jamais de schema:update.

## Qualité
- Tout passe par le Makefile : make test, make stan.
- PHPStan niveau 8, php-cs-fixer. Zéro warning.

• Le niveau Utilisateur (les fichiers d’instructions globaux de vos agents) : commun à tous vos projets. transverse à tous vos projets. Chaque agent possède son propre point d’entrée  ~/.codex/AGENTS.md, ~/.claude/CLAUDE.md ou ~/.gemini/GEMINI.md 

C'est ici que vous définissez vos exigences personnelles, exemple : utilisation des attributs PHP 8, préférences pour les types de retours stricts (declare(strict_types=1)), conventions Git, ou obligation pour l'agent de vous demander confirmation avant d’exécuter une commande d'altération en base de données (doctrine:schema:drop).

## Moi
- Clément, lead technique. Réponds-moi en français.

## Par défaut, partout
- Rédige le code et la doc en anglais.
- PHP/Symfony, monolithe simple. PHPStan niveau 4 minimum.
- Jamais de push git sans mon GO.

Mais ces fichiers peuvent tous être des liens symboliques vers une même source maintenue une seule fois, par exemple :

➜  ls -l ~/.codex/AGENTS.md ~/.claude/CLAUDE.md ~/.gemini/GEMINI.md

/Users/cb/.claude/CLAUDE.md -> /Users/cb/.config/AGENTS.md
/Users/cb/.codex/AGENTS.md  -> /Users/cb/.config/AGENTS.md
/Users/cb/.gemini/GEMINI.md -> /Users/cb/.config/AGENTS.md

Néanmoins, une limite technique survient rapidement : la fenêtre de contexte. Il s’agit de la quantité limitée d’informations qu’une IA peut garder en tête simultanément pour comprendre et répondre à une demande. Les recommandations d'Anthropic et d'OpenAI suggèrent de maintenir ces fichiers d'instructions AGENTS.md sous le seuil des 200 à 300 lignes pour éviter la saturation du modèle ou le risque d'hallucination par surcharge d'instructions.

Étape 2 : Passer à l'échelle avec le pattern LLM Wiki

Pour stocker un volume d'informations plus conséquent sans engorger le fichier d'instructions principal, Andrej Karpathy a formalisé le pattern LLM Wiki.

L'idée fondamentale repose sur la création d'une base de connaissances en Markdown structurée sous forme de Wiki, stockée en local, maintenue et consultée par l'agent lui-même. Il ne s'agit pas d'un nouvel outil à installer, mais d'une arborescence de fichiers textes que vous pouvez versionner avec Git.

Ce pattern s’applique très bien à l'échelle d’un projet Symfony, mais aussi pour une base de connaissance personnelle d’un développeur. Elle pourrait s'organiser naturellement ainsi :

~/knowledge/

├── projects/      # Contexte des applications (ProjetA, API-Core, Legacy-App)

├── tech/          # Conventions PHP 8, bonnes pratiques Symfony, patterns de test

├── people/        # Contacts, équipe, rôles des interlocuteurs

├── index.md       # Cartographie et point d'entrée universel

└── log.md         # Journal des modifications daté et géré par l'IA

Exemple index.md

# Personal Knowledge Index

Durable personal base, maintained as a lightweight LLM Wiki-style knowledge layer. **Do not load the whole directory** -- read this index, then open only the files relevant to the question.

## Profile
- `profile/about-me.md` -- who I am, background, side projects.
- `profile/roles-and-context.md` -- SensioLabs roles, client missions, mandates, durable context.

## Projects
- `projects/index.md` -- map of local projects and repositories, mostly under `~/Sites/`.

## People
- `people/contacts.md` -- durable professional relationship context, contact importance signals, and domain heuristics for calendar/mail prioritization.

## Tech
- `tech/php-symfony-style.md` -- durable PHP/Symfony preferences, patterns I like/refuse, architectural posture.
- `tech/code-review-preferences.md` -- recurring review criteria.
- `tech/makefile-task-runner.md` -- preference for self-documented Makefiles as project task runners and operational maps.
- `tech/docs-methodology.md` -- index of documentation surfaces (ADR, plans, audits, wiki, handoffs, articles) and where each goes; read this first, it points to the richer plan doc below.
- `tech/agent-executable-plans.md` -- global convention for where to store agent execution plans, how to number them, and how to track them with lightweight indexes.
- `tech/agentic-tools.md` -- cross-project inventory of agent-accessible tools, integrations, MCP endpoints, and usage conventions.
…

Orchestration : l'injection à la demande

Pour que vos assistants tirent parti de ce Wiki local, une seule ligne d'instruction dans votre ~/.config/AGENTS.md suffit :

- Durable personal context: `~/knowledge/` (read the index before opening anything else).

Lors du démarrage d'une nouvelle session, l'agent lit d'abord l'index du Wiki (~/knowledge/index.md). Cet index joue le rôle de table d'orientation. En fonction de votre besoin immédiat, l'agent charge uniquement les deux ou trois fichiers nécessaires, sans jamais saturer sa mémoire de travail avec l'ensemble du dossier.

Un autre avantage majeur réside dans la maintenance de cette base. À l'issue d'une session de refactoring ou de la résolution d'une problématique d'architecture complexe, l'agent peut mettre lui-même à jour la fiche technique correspondante dans ~/knowledge/tech/ et consigne sa modification dans log.md. Vous conservez le contrôle total via des commits Git.

En pratique : la puissance d'un prompt minimaliste

Une fois ce système en place, la rédaction de vos commandes change radicalement. Un prompt laconique devient compréhensible pour l'assistant :

Grâce au parcours automatique dans votre Wiki local, l'agent résout chaque contexte. Pour chaque élément dans le prompt, l'agent trouve le contexte dans le fichier indiqué :

🔵 Projet1 / Projet2 -> knowledge/projects/index.md

🟢 Préférences Symfony -> knowledge/tech/php-symfony-style.md

🟡 To do du contre-audit -> knowledge/todo/index.md

🟣 Mon CTO -> knowledge/people/contacts.md

🔴 Jira / email -> configuration partagée, skills et MCP

Une mémoire sur mesure pour un code plus propre

En combinant la clarté d'un fichier AGENTS.md global avec la souplesse du pattern LLM Wiki, vous offrez à vos assistants une véritable mémoire long terme, sans mettre en péril la souveraineté de vos données.

Cette approche s’inscrit pleinement dans la philosophie de rigueur et de maintenabilité prônée dans l’écosystème Symfony : pas de boîte noire, pas de dépendances cachées, uniquement du texte brut versionable, lisible par l'humain et exploitable par n'importe quel modèle de langage actuel ou futur.