GitHub AI Scan : distinguer activation et preuves d’analyse
Une hausse du nombre de dépôts activés facilite le suivi d’adoption. Elle ne prouve pas, à elle seule, qu’une modification critique a été analysée et ses résultats examinés. Une petite équipe doit définir les preuves qui soutiennent chaque constat avant de viser un pourcentage.
Ce qui a changé le 6 octobre
Le journal GitHub du 6 octobre 2026 annonce le statut d’activation d’AI Scan for pull requests dans la vue coverage de Security overview pour les administrateurs d’organisations et d’entreprises. Le résumé compte les dépôts enabled et not enabled, les lignes affichent leur état effectif et le CSV ajoute Code Scanning AI Scan for pull requests.
Les filtres sont code-scanning-ai-scan-pr-scan:enabled et code-scanning-ai-scan-pr-scan:not-enabled. Le gain concerne la visibilité de l’adoption, sans preuve d’une meilleure précision ou vitesse. Cette question diffère aussi de notre précédent article sur l’analyse planifiée des dépôts inactifs.
Ne pas deviner la cause de not enabled
GitHub Docs précise qu’enabled reflète les politiques d’entreprise, la configuration de l’organisation, les prérequis et les exclusions du dépôt. Not enabled peut inclure des dépôts non éligibles ; cette vue ne distingue pas les causes. Toute la liste ne peut donc pas devenir des tâches en retard.
Un inventaire simple peut relever dépôt, responsable, statut, heure du contrôle, politique consultée et motif d’exception. Un motif inconnu reste à vérifier. Une restriction centrale, une inéligibilité et une exclusion volontaire nécessitent des interlocuteurs et des actions différents.
Séparer configuration, analyse et revue
Notre proposition prévoit trois ensembles de preuves : état et périmètre de configuration ; PR, commit et résultats réellement vérifiés ; personne et décision de revue. C’est une proposition de procédure, pas une nouvelle garantie de GitHub. Une valeur enabled ne doit pas valider les trois étapes.
Pour une PR touchant aux paiements, reliez les résultats vérifiables de la modification après avoir contrôlé l’activation. Indiquez si un résultat appelle correction, évaluation d’un faux positif ou enquête complémentaire. Sans résultat trouvé, l’analyse reste non vérifiée. Même sans alerte, documentez le périmètre et ses limites plutôt que de prétendre prouver la sécurité.
Commencer sur un périmètre stable
Choisissez les dépôts actifs d’une équipe et conservez leur export CSV. Quand l’état évolue, contrôlez créations, transferts et archivages avec la configuration. Un dénominateur modifié ne démontre pas une meilleure efficacité. Les motifs non résolus et les responsables suivants sont souvent plus utiles qu’un grand total.
La discussion GitHub Community liée par l’annonce est un canal de retour sur les détections de sécurité par IA. Ses quelques commentaires publics ne mesurent ni satisfaction générale ni adoption. Pour rendre un retour reproductible, précisez les modifications et résultats comparés avant d’évoquer faux positifs ou omissions.
L’activation ne clôt pas tout le travail
Trois nouveaux documents par PR pourraient alourdir la revue. Commencez par réunir les liens vers PR, résultats et tickets existants. Sur quelques modifications importantes, vérifiez qu’une autre personne peut suivre les preuves. L’enjeu est une décision réexaminable, pas un gros volume d’archives.
Aujourd’hui, reliez le motif du statut d’un dépôt important aux preuves d’analyse et de revue d’une modification récente. L’adoption peut être confirmée tandis que l’analyse reste en attente. Les changements de droits ou de prérequis font l’objet d’un examen distinct. La nouvelle vue reste ainsi utile sans exagérer ce qu’elle établit.
Sources et périmètre
Vérifié le 7 octobre 2026. Les sources officielles décrivent le produit ; la liste opérationnelle est notre proposition. Commencez par les liens de preuve d’un dépôt important.