Le problème que GitHub veut résoudre
Les alertes de sécurité se répètent rarement à l’identique. Deux fichiers peuvent présenter la même faiblesse, mais ne pas employer les mêmes fonctions, les mêmes bibliothèques ni les mêmes conventions de validation. Un outil qui propose un correctif sans connaître les habitudes du dépôt risque de produire une modification générique, difficile à intégrer ou incomplète. Copilot Memory a précisément pour objectif de conserver des faits utiles concernant un dépôt : conventions de code, décisions d’architecture, commandes de compilation et autres règles propres au projet. Documentation officielle de Copilot Memory.
Le lien annoncé le 25 septembre est donc logique : quand Agentic Autofix examine une alerte, il peut d’abord consulter les mémoires déjà présentes pour comprendre le contexte. Une fois un correctif créé, il enregistre le schéma de correction comme mémoire. Ce schéma pourra aider à résoudre une autre alerte et informer d’autres fonctions Copilot, dont la revue de code et l’agent cloud. Ce n’est pas l’annonce d’un « modèle de cybersécurité entièrement nouveau » : c’est une intégration entre deux capacités existantes. Changelog GitHub.
Comment fonctionne la boucle de mémoire
L’annonce officielle décrit trois moments. D’abord, lire : Agentic Autofix recherche dans les mémoires existantes celles qui peuvent éclairer l’alerte. Ensuite, corriger : l’agent élabore un correctif dans le contexte du dépôt. Enfin, retenir : le motif de correction est enregistré pour des usages ultérieurs. L’idée est de ne pas recommencer sans contexte à chaque alerte semblable. GitHub précise que les connaissances peuvent être reprises par d’autres fonctionnalités Copilot qui interviennent dans le même dépôt. Annonce du 25 septembre.
La documentation de Copilot Memory distingue les faits propres au dépôt et les préférences propres à un utilisateur. Les faits du dépôt sont liés à des références dans le code. Lorsqu’ils sont réutilisés, Copilot vérifie ces références sur la branche courante afin de limiter l’emploi d’une information devenue obsolète. GitHub indique aussi que ces faits restent circonscrits au dépôt concerné : ils ne sont pas réutilisés pour intervenir dans un autre dépôt. Les propriétaires peuvent les examiner et les supprimer. C’est un point important pour les équipes qui ne veulent pas qu’une ancienne pratique de sécurité circule sans contrôle d’un projet à l’autre.
Ce que la mémoire peut améliorer — et ce qu’elle ne garantit pas
Si un dépôt possède déjà une manière éprouvée de traiter une classe d’alertes, mémoriser ce contexte pourrait aider l’agent à proposer une solution plus cohérente avec le reste du code. Cette possibilité est la promesse du produit ; elle n’équivaut pas à un résultat mesuré sur tous les projets. GitHub n’indique dans son changelog ni le nombre d’alertes résolues avec la mémoire, ni un taux de faux positifs, ni une comparaison avec Agentic Autofix sans mémoire. Il serait donc trompeur d’écrire que la fonction « corrige automatiquement les failles » ou qu’elle rend les correctifs fiables par défaut. Source primaire.
Une mémoire peut aussi entretenir une mauvaise habitude si un schéma de correction est insuffisant, si l’architecture du dépôt change ou si une règle de sécurité évolue. La vérification des références sur la branche courante réduit un type d’obsolescence, mais ne prouve pas que le correctif est sûr dans tous les contextes. La revue de code, les tests adaptés à la faille et l’examen des effets secondaires demeurent nécessaires. Cette appréciation est une analyse éditoriale des risques d’un mécanisme de mémoire ; GitHub ne présente pas lui-même de garantie de sécurité absolue. Documentation des références et de la portée des mémoires.
Disponibilité, activation et contrôle
GitHub dit explicitement que l’intégration fonctionne pour les clients ayant activé Copilot Memory. Les deux fonctions, Agentic Autofix et Copilot Memory, sont en aperçu public et peuvent évoluer. La documentation de Copilot Memory indique une disponibilité de la mémoire sur les offres Copilot payantes, mais l’accès effectif à chaque fonction dépend également des droits et réglages correspondants. Le changelog du 25 septembre ne donne pas de tarif propre à cette liaison, ni de calendrier de déploiement par région. Mieux vaut donc vérifier l’activation dans son organisation que supposer que tout abonné la voit déjà.
Le contrôle des mémoires est central. GitHub indique que les faits de dépôt sont créés en réponse à une activité déclenchée par un utilisateur ayant le droit d’écriture et ayant activé Memory. Les propriétaires du dépôt peuvent les consulter et les effacer. Les préférences utilisateur suivent d’autres règles de visibilité et de suppression. Dans un flux de correction de sécurité, l’équipe devrait examiner quelles mémoires sont retenues, s’assurer qu’un motif enregistré reflète bien une décision validée et supprimer les informations devenues fausses. Documentation officielle.
Le vrai enjeu : faire de l’expérience passée un contexte vérifiable
La nouveauté ne réside pas seulement dans le fait qu’une IA « se souvient ». Elle réside dans la possibilité de réutiliser un historique de décisions de sécurité propre au dépôt, avec des références au code et un contrôle par les responsables du projet. Si cela fonctionne comme annoncé, les corrections ultérieures pourront mieux respecter les conventions locales. La condition reste la même que pour tout correctif proposé par un agent : une personne responsable doit vérifier que la faille est réellement corrigée, que la modification ne casse pas une autre partie du système et que la mémoire créée ne pérennise pas une erreur. L’annonce de GitHub ouvre un usage prometteur ; les résultats réels et leurs limites devront être observés sur des projets concrets. Changelog ; documentation Copilot Memory.
Sources
- GitHub, annonce officielle du 25 septembre 2026.
- GitHub Docs, fonctionnement et portée de Copilot Memory.
État des informations : 26 septembre 2026.