Un admin active Autofix sur un repo, un développeur clique sur « Generate fix » face à une alerte de dépendance vulnérable, et quinze minutes plus tard une pull request atterrit avec un changement de version, une explication et un score de priorité. C’est la promesse de l’Agentic Autofix, annoncée le 21 octobre 2026 par Laura Jiang sur le blog Azure DevOps. Pas une nouvelle fonctionnalité isolée : une refonte du moteur qui pilotait déjà Copilot Autofix pour GitHub Advanced Security depuis juin, cette fois avec un agent qui va fouiller ton code avant de répondre.
Ce qui change par rapport à l’ancien Autofix
La première version d’Autofix, lancée en juin 2026, générait des correctifs pour un ensemble limité de règles CodeQL. Elle lisait l’alerte, proposait un diff, point final. La version agentique s’appuie sur le moteur du Copilot coding agent : il explore le dépôt pour comprendre le contexte autour de l’alerte, rédige une proposition, puis la relit et l’ajuste avant de te la soumettre. Concrètement, ça veut dire qu’il peut repérer qu’une fonction de validation d’entrée existe déjà ailleurs dans ton code et s’en servir, plutôt que d’inventer son propre patch isolé.
Deuxième changement, plus structurant : Autofix ne se limite plus à CodeQL. Il traite aussi les alertes de code scanning remontées par des outils tiers, et couvre les vulnérabilités de dépendances — ce que l’ancienne version ne faisait pas du tout. Tu peux aussi le guider avec des instructions personnalisées et des « skills » placées dans les emplacements `.github` ou `.agents` de ton repo. Microsoft donne deux exemples concrets dans son billet : pointer l’agent vers un helper de validation d’entrée déjà approuvé par l’équipe, ou lui fournir une skill qui encode la procédure interne de mise à jour de paquets avec ses vérifications de compatibilité.
Dépendances vulnérables : le score EPSS plutôt que le seul CVSS
Sur une alerte de dépendance supportée, tu sélectionnes « Generate fix » et l’agent ouvre une pull request avec le changement proposé et une explication — qui passe ensuite par ta revue de code habituelle, rien n’est mergé automatiquement. Ce qui change vraiment la donne pour trier parmi des dizaines d’alertes, c’est l’affichage du percentile EPSS quand la donnée est disponible : plus le percentile est élevé, plus la probabilité d’exploitation relative de cette CVE est classée haut par rapport aux autres failles connues. Ce n’est pas une probabilité d’attaque en soi, juste un rang — Microsoft le précise explicitement dans son billet, et c’est la bonne nuance à transmettre à ton équipe avant qu’elle ne confonde les deux.
Azure DevOps distingue aussi désormais les dépendances de développement des dépendances d’exécution sur les écosystèmes supportés, via un badge « Development » et un filtre Scope. Le billet suggère une méthode de triage simple et plutôt juste : combiner le filtre Runtime avec une plage de percentile EPSS élevé, puis pondérer avec la sévérité et l’exposition réelle de l’application. Une dépendance de build jamais exposée en prod avec un EPSS élevé reste moins urgente qu’une dépendance runtime avec un EPSS moyen sur un service exposé à Internet — le score seul ne suffit jamais à trancher.
Activer Agentic Autofix sur ton organisation
L’activation se fait en un bouton, au niveau organisation, projet ou dépôt, et couvre à la fois les alertes de dépendances et de code scanning. Une fois l’option activée côté admin, c’est au niveau du dépôt que les alertes individuelles sont sélectionnées pour passer par Autofix. Le déploiement s’étale sur deux à trois semaines selon Microsoft — les organisations déjà dans la preview publique limitée peuvent demander des correctifs dès maintenant sur les alertes supportées, la preview publique générale, elle, commence en novembre 2026.
Le billet ne précise ni les langages exacts couverts pour la génération de fix, ni les noms des outils de code scanning tiers pris en charge, ni les paliers de licence requis — trois détails qu’on attend encore en pratique avant de pouvoir chiffrer sérieusement un déploiement à l’échelle d’une organisation.
Ce que ça coûte vraiment en crédits IA
Générer un correctif consomme des crédits IA. Activer Autofix sur un repo ne déclenche rien tout seul : tant que personne ne clique sur « Generate fix », aucun crédit n’est consommé. Toutes les demandes n’aboutissent pas non plus à un correctif exploitable. Et la responsabilité ne change pas de camp : chaque suggestion générée par l’agent doit être relue, buildée et testée avant merge, exactement comme n’importe quelle PR humaine — Autofix accélère la proposition, pas la revue.
Pour une équipe qui gère déjà des centaines d’alertes de dépendances sans jamais les traiter faute de temps, le calcul reste simple : même avec un taux d’échec non négligeable sur les correctifs générés, chaque PR qui atterrit toute prête vaut mieux qu’une alerte qui dort depuis huit mois. L’outil ne remplace pas un programme de gestion des vulnérabilités, il réduit juste la friction du dernier kilomètre — celui où la plupart des équipes calent, pas par manque de volonté mais par manque de temps.
FAQ
Agentic Autofix remplace-t-il complètement l’ancien Copilot Autofix ?
Oui, c’est une évolution du même produit, pas un outil parallèle. Le nom et le bouton restent « Copilot Autofix », mais le moteur sous-jacent est désormais celui du Copilot coding agent, avec exploration de contexte et relecture avant proposition.
Faut-il GitHub Advanced Security pour en profiter ?
Oui, Agentic Autofix s’appuie sur GitHub Advanced Security for Azure DevOps, qui fournit déjà le code scanning et la détection de dépendances vulnérables sous-jacents.
Un correctif généré peut-il être mergé automatiquement ?
Non. Chaque proposition passe par ta pull request et ton processus de revue habituel — build, tests, relecture humaine du diff complet avant tout merge.
Où signaler un problème ou un retour d’expérience ?
Microsoft indique trois canaux dans son billet : les commentaires du blog, l’email, ou la Azure DevOps Developer Community.
Pour aller plus loin
Si ta vraie bataille porte sur les alertes de code plutôt que de dépendances, l’autre moitié de l’équation Copilot côté Azure Repos — la revue de pull request automatisée — vaut le détour : on l’avait couverte au moment de sa preview publique en septembre. Et si le problème vient plutôt de paquets npm compromis en amont plutôt que de CVE déjà connues dans tes dépendances, le GitHub Package Firewall couvert la semaine dernière attaque le sujet par un autre bout, en amont de la CI plutôt qu’après coup sur une alerte déjà ouverte.
Reste la question du moment : activer Autofix aujourd’hui, en preview, sur un repo critique ? Si ton backlog d’alertes de dépendances dépasse la centaine et que personne n’y touche depuis des mois, oui, ça vaut le test — le pire qui puisse arriver est une PR non mergée. Si ton équipe a déjà un processus de triage qui tourne, attends plutôt la preview générale de novembre pour avoir une image plus claire des langages et outils réellement couverts.
Laisser un commentaire