GitHub Autofix mémorise ses corrections : le contexte devient partagé

Le 25 septembre 2026, GitHub a annoncé dans son journal des changements qu’Agentic Autofix utilise Copilot Memory lorsque cette fonction est activée. Il consulte les mémoires existantes pour traiter une alerte de sécurité, puis enregistre le motif du correctif qu’il produit. Les deux fonctions sont en préversion publique.

Le compte rendu de Labmemo décrit également ce passage du correctif à une mémoire réutilisable par d’autres fonctions Copilot. Pour un dépôt partagé, la nouveauté dépasse donc la correction d’une alerte : un motif appris pendant cette tâche peut fournir du contexte à une revue de code ou à une intervention ultérieure de l’agent cloud. Sa réutilisation dépend toutefois des droits d’accès et d’une vérification contre le code courant.

Ce qu’Agentic Autofix conserve après une correction

La mémoire porte sur un motif de correction propre au dépôt, et non sur la garantie que toutes les alertes semblables seront résolues. Agentic Autofix peut s’appuyer sur des faits déjà mémorisés lorsqu’il prépare un correctif. S’il produit une correction, il en conserve le motif pour qu’une autre tâche puisse retrouver ce contexte.

Copilot Memory accueille aussi d’autres faits liés au projet : conventions de code, décisions d’architecture, commandes de compilation ou règles particulières. Un motif de développement sécurisé issu d’Agentic Autofix rejoint cette connaissance du dépôt. Cela explique pourquoi la mémoire peut intéresser une fonction qui ne traite pas elle-même l’alerte initiale : elle dispose d’une indication sur la manière dont ce projet a été corrigé.

Il faut distinguer ce motif d’une préférence personnelle, par exemple une façon dont un utilisateur souhaite interagir avec Copilot. Les préférences restent liées aux interactions de cette personne, tandis qu’un fait de dépôt est destiné aux utilisateurs autorisés de ce dépôt. Présenter toute mémoire Copilot comme une consigne commune à l’équipe effacerait cette différence de portée.

Comment le motif passe à d’autres fonctions Copilot

Agentic Autofix, Copilot code review, Copilot cloud agent et Copilot CLI figurent parmi les fonctions qui utilisent Copilot Memory. Une connaissance acquise pendant une correction peut donc être retrouvée lors d’une revue de code ou d’une autre tâche menée dans le même dépôt. Le partage concerne le contexte disponible pour ces fonctions ; il ne signifie pas qu’elles reproduiront automatiquement le correctif précédent.

Cette frontière est celle du dépôt. Les faits enregistrés pour une application ne deviennent pas des règles pour les autres dépôts de l’organisation, même si les mêmes personnes y travaillent. À l’intérieur du dépôt concerné, les utilisateurs ayant accès à Copilot Memory peuvent bénéficier des faits conservés, sous réserve que ceux-ci soient pertinents pour leur tâche.

Les fonctions n’emploient pas toutes les mêmes catégories de mémoire. Copilot code review utilise les faits de dépôt, mais pas les préférences personnelles ; Copilot CLI peut appliquer les faits du dépôt et les préférences de la personne qui lance l’opération. Le contexte partagé par Autofix doit donc être compris comme une connaissance attachée au code du projet, et non comme une préférence individuelle transmise à tous les collaborateurs.

Une mémoire doit encore correspondre à la branche courante

La documentation de Copilot Memory indique que les faits de dépôt sont enregistrés avec des références au code, vérifiés contre la branche courante avant utilisation et supprimés après 28 jours sans usage. Le délai peut repartir lorsqu’une entrée est validée et utilisée. Cette validation intervient au moment où Copilot juge un fait pertinent pour une nouvelle tâche.

Une référence à un ancien correctif ne suffit donc pas, à elle seule, à faire appliquer son motif. Si le code qui étayait le fait a changé, Copilot doit vérifier que la branche utilisée le confirme encore. La documentation précise aussi qu’un fait peut provenir d’une demande de modification fermée sans fusion : la vérification contre le code courant reste alors décisive avant toute réutilisation.

Ce contrôle porte sur la validité de la référence au code, pas sur une mesure publiée de la qualité des futurs correctifs. Un motif encore étayé peut fournir du contexte sans garantir que la nouvelle alerte soit identique à la précédente ni que la correction proposée convienne telle quelle. Le gain annoncé est la possibilité de retrouver une connaissance du dépôt, sous condition de validation.

Qui peut alimenter et supprimer la mémoire du dépôt

La création d’un fait de dépôt suppose une action lancée par une personne disposant d’un accès en écriture et ayant activé Copilot Memory. Un utilisateur qui ne peut que lire le dépôt ne crée pas ainsi de nouveaux faits. Une fois stocké, le fait peut en revanche servir aux autres utilisateurs autorisés à employer la mémoire sur ce même dépôt.

L’activation personnelle de Copilot Memory s’applique aux dépôts dans lesquels la personne utilise une fonction Copilot compatible. Sur un abonnement individuel, elle est activée par défaut. Pour un abonnement géré par une organisation ou une entreprise, la politique administrateur doit d’abord l’autoriser ; les utilisateurs peuvent ensuite choisir de se désinscrire. La politique, le choix personnel et les droits d’écriture déterminent donc ensemble qui peut déclencher l’enregistrement de nouveaux faits.

Les propriétaires d’un dépôt peuvent examiner ses faits mémorisés et les supprimer manuellement. Les préférences personnelles suivent un autre circuit : chaque utilisateur peut voir et effacer les siennes ; dans les offres Business et Enterprise, les administrateurs disposent aussi de moyens pour les consulter ou les supprimer. Effacer un fait déjà stocké répond à une question différente de la désactivation de la fonction pour les usages futurs.

Les points à vérifier pour un dépôt sensible

Avant d’autoriser ce partage sur un dépôt sensible, l’équipe peut ramener la décision à des éléments vérifiables :

• Repérer les personnes ayant l’accès en écriture et susceptibles de lancer les fonctions qui créent des faits de dépôt.
• Vérifier la politique Copilot Memory de l’organisation ainsi que le choix d’activation des utilisateurs concernés.
• Examiner les faits déjà enregistrés et les références au code qui les étayent ; supprimer ceux qui sont inappropriés, trompeurs ou dépassés.
• Déterminer qui suivra ces faits lorsque les conventions de sécurité ou la structure du code changeront.

La nouveauté confirmée est un circuit de réutilisation : une correction de sécurité peut laisser un motif que d’autres fonctions Copilot retrouvent dans le même dépôt, après validation contre la branche courante. Les fonctions restent en préversion publique. Les informations publiées sur cette intégration décrivent ce fonctionnement, sans établir un taux d’amélioration des corrections obtenu grâce à la mémoire.

À lire aussi:

• GitHub bloque les secrets à la fusion, mais seulement avec une offre payante
• Suno limite les téléchargements : les morceaux IA deviennent traçables
• Cloudflare laisse l’IA chercher les failles, sans lui confier le correctif