Le contexte du projet peut suivre les sessions
Une application continue d’évoluer après sa mise en ligne. Un écran change, une équipe reprend le travail et certaines décisions deviennent moins évidentes. Pourquoi cette date est-elle conservée ? Pourquoi ce bouton reste-t-il à cette place ? La réponse se trouve parfois dans une ancienne conversation.
Le 28 octobre 2026, GitHub a annoncé la disponibilité générale de Copilot Memory sur les offres Copilot payantes. L’outil peut conserver des préférences personnelles et des faits propres à un projet entre plusieurs sessions. Cette évolution figure dans l’annonce officielle de GitHub.
Notre lecture : la continuité du travail mérite autant d’attention que la première version produite. La mémoire peut aider à retrouver le contexte utile, à condition de savoir ce que l’on souhaite transmettre.
Retrouver la raison derrière une règle
Imaginons une application fictive de suivi d’interventions. Une intervention terminée conserve sa date de clôture, même lorsqu’un autre collaborateur reprend le dossier. Cette règle permet à l’équipe de comprendre l’historique de son activité.
Quelques mois plus tard, une demande vise à simplifier l’écran. Sans connaître la raison de cette date, quelqu’un pourrait la remplacer par la dernière modification et effacer une distinction utile.
Nous préparerions une note courte : ce que représente chaque date, pourquoi l’équipe a choisi cette organisation et quel parcours permet de la vérifier. La personne qui reprend le projet disposerait alors d’un point de départ compréhensible pour discuter du changement.
Rendre les décisions importantes visibles dans le projet
La documentation de Copilot Memory distingue les faits du dépôt, c’est-à-dire du dossier de code partagé, des préférences d’une personne. Elle précise aussi qu’un fait mémorisé n’est pas une garantie de respect systématique d’une règle. Les instructions écrites et la relecture restent nécessaires.
Dans notre application d’interventions, nous conserverions donc la règle sur les dates dans une documentation accessible à l’équipe. Un exemple de dossier et un résultat attendu rendraient la décision plus facile à discuter.
Cette préparation sert aussi au client : il doit pouvoir comprendre l’effet d’une évolution sans lire le code. Une décision explicite peut être confirmée, corrigée ou remplacée avec lui.
Dreaming propose d’entretenir ce contexte
GitHub présente également Copilot Dreaming, en préversion publique et sur activation. Il analyse des sessions et des retours de revue pour entretenir les mémoires. Les modifications proposées aux fichiers d’instructions passent par une demande de modification à relire avant leur intégration, comme l’explique la documentation de Dreaming.
Pour notre équipe fictive, l’intérêt serait de repérer une consigne devenue obsolète après une évolution. Nous comparerions alors la proposition au fonctionnement actuel et aux décisions validées. Une formulation plus récente ne suffit pas à prouver qu’elle décrit correctement le produit.
La question à poser resterait simple : cette nouvelle instruction aide-t-elle la prochaine personne à faire le bon changement ?
Distinguer les habitudes personnelles des choix collectifs
Une préférence de présentation peut convenir à un développeur sans devenir une règle pour tout le projet. À l’inverse, la signification d’un statut concerne chaque personne qui intervient sur l’application.
Nous trierions ces informations selon leur usage : les décisions métier, les repères graphiques et les habitudes individuelles. Pour chaque règle commune, il faudrait pouvoir identifier son contexte et la personne avec qui la faire évoluer.
Ce tri facilite la transmission lorsqu’un collaborateur arrive ou quitte le projet. Il évite aussi de traiter une exception ancienne comme une obligation permanente. La mémoire utile doit accompagner les changements de l’entreprise.
Ce que cela apporte à la durée de vie d’une application
Chez NevoLabs, nous relions cette actualité à la conception d’une application adaptée à ses utilisateurs. Le produit gagne à rester compréhensible lorsque ses écrans et son équipe évoluent.
Un accompagnement dans la durée peut préserver ces repères : ce qui a été décidé, les raisons du choix et les points à revoir lors d’une prochaine étape. Le client garde ainsi une base pour arbitrer les évolutions.
Copilot Memory ouvre une possibilité de transmettre davantage de contexte aux outils de développement. La responsabilité de l’équipe consiste à garder ce contexte lisible, actuel et relié au fonctionnement réel du produit.
Deux fonctions avec des conditions différentes
La disponibilité générale de Memory ne signifie pas que Dreaming est accessible dans toutes les offres. Selon les prérequis de Dreaming, sa préversion exige notamment l’accès à GPT‑6.1 Sol, exclut Copilot Pro et ne prend pas en charge GitHub Enterprise Cloud avec résidence des données. Les politiques de l’organisation et les réglages requis doivent également permettre son usage.
Chaque exécution de Dreaming consomme des crédits IA, y compris lorsqu’elle ne propose aucun changement. Avant un essai, il faut vérifier les prérequis et les coûts dans la documentation, puis choisir un périmètre limité. Nous ne rapportons ici aucun test de performance réalisé par le studio.
Sources et informations produit vérifiées le 2 novembre 2026.