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

Les assistants IA pour le développement sont devenus significativement plus puissants, mais ils conservent un problème fondamental : presque chaque nouvelle session commence par une perte du contexte accumulé. Le modèle ne se souvient pas de quelle pile technologique l'équipe utilise, quelles conventions ont été adoptées dans le projet, pourquoi le port a été déplacé de 8501 à 8505 il y a longtemps, et quels composants se sont déjà avérés être de mauvais choix. En résultat, le développeur reproduit encore et encore les mêmes conditions initiales.

Un article sur l'ingénierie du contexte suggère de regarder cela non pas comme un défaut inévitable, mais comme un problème d'ingénierie : la mémoire peut être extraite vers une couche séparée et devenir partie du flux de travail. La distinction clé ici est entre mémoire à court terme et mémoire à long terme. La mémoire à court terme vit au sein d'une seule fenêtre de contexte : le chat actuel, les fichiers ouverts, les actions récentes.

Une fois que la session se termine, cette mémoire disparaît. C'est précisément pour cela que, sans configuration supplémentaire, un assistant pourrait d'abord suggérer un tableau de bord React, puis après révision passer à Streamlit, et seulement à la troisième tentative tenir compte d'Altair et d'autres exigences. Chaque itération de ce type semble un détail mineur, mais sur la distance devient une « taxe de répétition » constante.

Plus il y a de projets et de membres d'équipe, plus l'absence de contexte stable devient coûteuse. Le premier niveau et le plus pratique de solution sont les fichiers de règles explicites au sein du projet. Pour différents outils, cela peut être CLAUDE.

md, AGENTS.md, ou des répertoires avec des fichiers de règles. En eux, il y a lieu de fixer la pile, les conventions d'interface et de style de code, les commandes pour exécuter, tester et faire du linting, ainsi que les décisions historiques importantes qui sont difficiles à réexpliquer à chaque session.

Si l'équipe préfère les icônes Material à la place des emojis, une mise en page large dans Streamlit, Altair pour les graphiques, et des mécanismes de cache spécifiques, tout cela est mieux décrit une fois à côté du code. L'avantage d'une telle approche est qu'elle vit dans le contrôle de version : un nouveau développeur clone le référentiel, et avec lui l'assistant reçoit un ensemble prêt de règles du jeu. Le niveau suivant concerne les règles globales qui se rapportent non pas à un projet spécifique, mais au style de travail de l'utilisateur ou de l'équipe elle-même.

Ici, il n'y a pas besoin d'une liste de bibliothèques et de ports ; ce qui importe c'est de définir le format de réponse, les exigences de complétude du code, l'attitude envers les commentaires, l'approche d'optimisation, et le choix entre la brièveté et la lisibilité. L'idée est de séparer le contexte technique du contexte comportemental. Les détails technologiques doivent être dans le projet, tandis que les préférences stables doivent être au niveau global.

L'article note également un format plus portable pour les skills, quand l'assistant reçoit non seulement des règles de comportement, mais aussi des procédures pour exécuter les tâches typiques. Cela rapproche les outils IA du modèle de travail avec un véritable employé : on leur donne non seulement des matériaux de briefing, mais aussi des façons standard d'agir. Les niveaux plus avancés sont liés à la mémoire implicite et à l'infrastructure externe.

Cela inclut les systèmes qui collectent eux-mêmes les traces de travail : fragments de code, activité IDE, historique du navigateur, insights de débogage, et motifs de projet. L'article mentionne des exemples tels que Pieces, l'auto-mémoire de Claude Code, et des mécanismes en nuage comme ChatGPT Memory. Un rôle important commence à être joué par Model Context Protocol, ou MCP : il fournit un moyen unifié de connecter l'assistant à des sources de données externes, au lieu de construire des intégrations uniques pour chaque outil.

Pour les équipes qui ont besoin d'une couche complète de mémoire organisationnelle, il existe un chemin encore plus lourd — des services comme Mem0, Zep, et Supermemory, ou une infrastructure RAG propre basée sur Pinecone et Weaviate. Mais cela n'est plus une configuration d'une soirée, mais un système d'ingénierie séparé avec ses propres coûts pour les embeddings, la recherche, la déduplication, et la résolution des contradictions dans les données. La conclusion principale est plutôt pratique : la plupart des équipes n'ont pas besoin d'une pile de mémoire complexe immédiatement.

Il suffit de commencer par un fichier de règles à la racine du projet, fixer la pile, les commandes et les conventions, puis graduellement déplacer les habitudes récurrentes vers les paramètres globaux. Si après une session productive vous demandez à l'assistant de formuler brièvement ce qu'il a appris, une telle couche de connaissance se construira sans chaos. Le 11 avril 2026, l'auteur de l'article notait déjà que les grands acteurs comme Anthropic ont commencé à intégrer effectivement la mémoire dans leurs outils, mais les modèles eux-mêmes restent sans état.

Ceci est le principal changement de perspective : le problème n'est pas que les LLMs sont « mauvais », mais que le contexte doit être conçu aussi consciemment que le code, les pipelines et la documentation. Les équipes qui comprendront cela avant les autres n'obtiendront pas de magie, mais une accélération durable du développement.