Claude Code et Cursor : comment l'ingénierie de contexte transforme la mémoire de l'IA en outil de travail

Les assistants IA pour le développement sont nettement plus puissants, mais un problème de fond demeure : presque chaque nouvelle session commence par la perte du contexte accumulé. Le modèle ne sait pas quelle stack utilise l'équipe, quelles conventions s'appliquent au projet, pourquoi le port est passé depuis longtemps du 8501 au 8505 ni quels composants se sont déjà révélés un mauvais choix. Résultat : le développeur reformule sans cesse les mêmes données de départ.

L'article sur l'ingénierie de contexte propose de voir là non pas un défaut inévitable, mais un problème d'ingénierie : la mémoire peut être déplacée dans une couche distincte et intégrée au processus de travail.

La distinction essentielle oppose mémoire à court terme et mémoire à long terme. La première vit dans une seule fenêtre de contexte : le chat en cours, les fichiers ouverts, les actions récentes. Une fois la session terminée, cette mémoire disparaît. C'est pourquoi, sans réglages supplémentaires, l'assistant peut d'abord proposer un tableau de bord en React, passer à Streamlit après une correction, puis ne tenir compte d'Altair et des autres exigences qu'à la troisième tentative. Chaque itération semble anodine, mais à la longue elle devient une « taxe de répétition » permanente. Plus l'équipe compte de projets et de membres, plus l'absence de contexte durable coûte cher.

Le premier niveau de solution, et le plus pratique, consiste en des fichiers de règles explicites dans le projet. Selon l'outil, il peut s'agir de CLAUDE.md, d'AGENTS.

md ou de répertoires de fichiers de règles. Il est judicieux d'y consigner la stack, les conventions d'interface et de style de code, les commandes de lancement, de test et de linting, ainsi que les décisions historiques importantes, difficiles à réexpliquer à chaque session. Si l'équipe préfère les icônes Material aux emojis, une mise en page large dans Streamlit, Altair pour les graphiques et des mécanismes de cache précis, mieux vaut tout décrire une fois, à côté du code.

L'avantage de cette approche est qu'elle vit dans le système de gestion de versions : un nouveau développeur clone le dépôt et l'assistant reçoit du même coup un jeu de règles prêt à l'emploi.

La couche suivante est celle des règles globales, qui ne portent pas sur un projet précis mais sur le style de travail de l'utilisateur ou de l'équipe. Inutile ici d'une liste de bibliothèques et de ports ; il importe plutôt de définir le format des réponses, les exigences de complétude du code, le rapport aux commentaires, l'approche de l'optimisation et l'arbitrage entre concision et lisibilité. L'idée est de séparer le contexte technique du contexte comportemental. Les détails technologiques doivent résider dans le projet, les préférences durables au niveau global.

Le texte note aussi un format de compétences plus portable, où l'on donne à l'assistant non seulement des règles de comportement, mais aussi des procédures pour exécuter des tâches types. Cela rapproche les outils IA du fonctionnement d'un vrai employé : on lui fournit non seulement des données de départ, mais aussi des façons standard d'agir.

Les niveaux plus avancés touchent à la mémoire implicite et à l'infrastructure externe. On y trouve des systèmes qui collectent eux-mêmes les traces du travail : fragments de code, activité dans l'IDE, historique du navigateur, conclusions de débogage et schémas de projet. L'article cite en exemples Pieces, la mémoire automatique de Claude Code et des mécanismes cloud comme ChatGPT Memory. Le Model Context Protocol, ou MCP, joue ici un rôle important : il offre un moyen unique de connecter l'assistant à des sources de données externes, au lieu de bâtir des intégrations uniques pour chaque outil.

Pour les équipes qui veulent une véritable couche de mémoire organisationnelle, il existe une voie encore plus lourde : des services comme Mem0, Zep et Supermemory, ou une infrastructure RAG maison reposant sur Pinecone et Weaviate. Mais il ne s'agit plus d'un réglage « d'une soirée » : c'est un système d'ingénierie à part entière, avec ses propres coûts d'embeddings, de recherche, de déduplication et de résolution des contradictions dans les données.

La conclusion principale reste terre à terre : la plupart des équipes n'ont pas besoin d'emblée d'un memory stack complexe. Il suffit de commencer par un fichier de règles à la racine du projet, d'y consigner la stack, les commandes et les conventions, puis de transférer peu à peu les habitudes récurrentes vers les réglages globaux. Si, après une session productive, on demande à l'assistant de résumer brièvement ce qu'il a appris, cette couche de connaissances grandira sans chaos.

Au 11 avril 2026, l'auteur de l'article notait déjà que de grands acteurs comme Anthropic avaient commencé à intégrer de fait la mémoire dans leurs outils, mais que les modèles eux-mêmes restent stateless. C'est là le principal changement de perspective : le problème n'est pas que les LLM soient « mauvais », mais que le contexte doit être conçu avec autant de soin que le code, les pipelines et la documentation. Les équipes qui le comprendront avant les autres obtiendront non pas de la magie, mais une accélération durable du développement.