Une structure de collaboration créée pour mener des projets de long terme en passant d’un modèle d’IA à l’autre

Dans la collaboration avec l’IA, la mémoire ne doit pas être dans le chat, mais dans le dépôt

Ces derniers mois, j’ai souvent alterné entre plusieurs modèles d’IA pour travailler sur du développement, comme les modèles de la famille GPT-5, Claude, Copilot ou Gemini. Autrefois, un seul outil suffisait, mais aujourd’hui il est devenu naturel de choisir le modèle le plus adapté selon le type de tâche.

Par exemple, pour la conception d’architecture, de grands modèles comme GPT-5.4 sont plus stables ; pour l’écriture de code, les modèles de la famille Claude Sonnet / Opus sont parfois plus précis ; et pour le design frontend ou l’exploration d’idées, il peut être plus efficace d’utiliser d’autres modèles. De plus, comme le rythme des mises à jour des modèles est très rapide, on finit par changer régulièrement d’outil selon la situation plutôt que de rester fixé sur un seul.

C’est là que les problèmes commencent.
À chaque changement de modèle, à chaque nouvelle session, l’IA ne se souvient absolument plus du projet. Au final, il faut répéter les mêmes explications à chaque fois. Ce qu’est ce projet, jusqu’où il a avancé, quelles décisions ont déjà été prises, quelle structure doit être conservée, ce qu’il ne faut pas faire : tout ce contexte de base doit être retransmis en permanence.

Au début, ce n’était qu’une gêne, mais à mesure que la taille du projet augmentait, ce coût est devenu de plus en plus visible. Surtout lorsqu’on passe d’un modèle à l’autre, j’ai eu l’impression de consacrer plus de temps à réexpliquer le contexte qu’au développement lui-même. J’en suis donc naturellement arrivé à cette question :

« Dans une collaboration avec l’IA, la mémoire doit-elle être dans le chat, ou le projet lui-même doit-il porter cette mémoire ? »

Un problème que le Prompt Engineering ne résout pas

On parle beaucoup de Prompt Engineering comme méthode pour mieux utiliser l’IA. Mais quand on travaille sur des projets de long terme, il existe un problème plus important encore que le prompt : l’absence de persistance du contexte.

Le prompt est une manière de bien formuler une requête ponctuelle, tandis qu’un projet est un processus composé d’une succession de travaux. Pour faire avancer un projet de manière stable, il faut au minimum conserver en continu les informations suivantes :

• les exigences actuelles
• l’historique des décisions prises jusqu’ici
• le plan de travail
• les tâches terminées
• l’historique des changements
• ce qu’il reste à faire

Si ces informations ne sont pas conservées, même le meilleur modèle répétera les mêmes erreurs. C’est pourquoi, au lieu de chercher à mieux rédiger les prompts, j’ai commencé à mettre en place une méthode pour gérer le contexte lui-même. On appelle souvent cette approche le Context Engineering, et comme j’ai rencontré un problème similaire, j’ai commencé à appliquer ce concept à une collaboration à l’échelle du projet.

Ce n’est pas le chat, c’est le dépôt qui doit porter la mémoire

La première chose que j’ai changée a été l’endroit où le contexte est stocké. Auparavant, tout le contexte se trouvait dans le chat, mais le chat disparaît à la fin d’une session. J’ai donc mis en place une structure qui stocke le contexte à la racine du projet.

J’ai créé un dossier .cowork/ pour y enregistrer l’état du projet. On y trouve par exemple les requirements, les architecture decision records, la liste des tâches, les journaux de tests, les notes de release ou encore les logs de session.

Au démarrage d’une session, on suit toujours le même flux : lire l’état actuel, établir un plan, le faire valider, exécuter, puis consigner le résultat. La conversation est éphémère, mais les documents restent. Ainsi, même si le modèle change, le projet continue.

La règle Plan → Approve → Execute

L’un des problèmes que j’ai rencontrés le plus souvent dans la collaboration avec l’IA, c’est lorsque le modèle modifie directement le code. Il ignorait parfois des décisions précédentes, cassait la structure, ou introduisait des changements en contradiction avec une direction déjà validée.

J’ai donc défini une règle de travail : toujours respecter l’ordre Plan → Approve → Execute. On élabore d’abord un plan, un humain le vérifie, puis seulement ensuite on exécute. À elle seule, cette règle a fortement réduit les erreurs dans les projets de long terme.

Artifact is Memory

Le principe le plus important de ce framework peut se résumer par la formule « Artifact is Memory ». La mémoire ne doit pas être dans le chat, mais dans les artefacts du projet.

C’est ce qui permet de préserver l’état du projet même si le modèle change, si la session change, si l’outil change ou même si l’IDE change. Dans un environnement où plusieurs modèles sont utilisés en parallèle, ce principe joue un rôle bien plus important qu’on ne pourrait le penser.

Par artefacts, je ne parle pas uniquement de documents rédigés dès le départ. Même dans les échanges avec l’IA, des informations qui doivent réellement rester dans le projet apparaissent en permanence : affinage des exigences, décisions de conception, plans de travail, résultats de revue, etc. Le problème est que tant que ces éléments restent dans le chat, ils risquent d’être consommés comme un contexte jetable.

C’est pourquoi j’accorde beaucoup d’importance à une méthode qui classe et enregistre automatiquement le contenu significatif des conversations avec l’IA, puis le réutilise comme artefacts du projet. Il ne s’agit pas simplement d’accumuler des logs de discussion, mais de transformer les points essentiels issus des échanges en documents réutilisables, sous la forme de traces de décision, de documents d’exigences, de plans de travail ou de logs de session.

De cette manière, la conversation ne reste pas une interface éphémère : elle devient une matière de travail qui fait réellement avancer le projet. Au fond, ce qu’il faut mémoriser, ce n’est pas la conversation elle-même, mais les résultats structurés qui en sont extraits.

Les problèmes qui apparaissent lorsqu’on travaille en passant d’un modèle à l’autre

Aujourd’hui, il est rare de n’utiliser qu’un seul modèle. Chaque modèle a ses points forts, donc on finit par en utiliser différents selon les étapes du travail, et par répéter des tâches comme la conception, la modification de code, la revue ou l’analyse de contexte à travers plusieurs sessions et plusieurs modèles.

Dans ce cas, si le contexte ne vit que dans le chat, il faut réexpliquer tout le projet à chaque changement de modèle. C’est pour cela que j’ai conçu une structure où le contexte n’est pas dans le chat, mais dans le dépôt.

Ce que j’ai créé : cowork-context-framework

J’ai rassemblé tout ce processus dans un framework. Il s’agit d’une structure qui stocke le contexte dans le projet, restaure les sessions, enregistre les décisions, suit les tâches, et permet de reprendre le travail même lorsque le modèle change.

• GitHub : https://github.com/lim8603/cowork-context-framework

Je l’avais d’abord utilisé sous forme de template et je l’ai appliqué à de vrais projets, ce qui m’a permis de le valider dans une certaine mesure. Sur cette base, j’ai ensuite réorganisé la structure pour l’élever au format framework. Je pense que c’est la forme minimale de structure de collaboration nécessaire pour mener des projets de long terme avec l’IA.

Je me demande si d’autres ont déjà tenté quelque chose de similaire

• des personnes ayant déjà utilisé plusieurs modèles d’IA ensemble
• des personnes qui ont dû répéter les mêmes explications à cause d’une session interrompue
• des personnes qui ont déjà construit une structure de type agent / workflow / harness
• des personnes qui ont déjà géré séparément le contexte d’un projet

Si vous avez vécu une expérience similaire, j’aimerais beaucoup connaître votre avis.