GitHub : distinguer validation initiale et analyse hebdomadaire
Des analyses hebdomadaires dans un dépôt dormant peuvent sembler indiquer du développement. Leur diminution ne signifie pas automatiquement une perte de protection.
Le 1er octobre 2026, GitHub a modifié le démarrage des analyses planifiées de code scanning default setup et GitHub Code Quality. Les faits sont distincts des propositions de gestion.
La validation initiale reste
L’activation lance toujours une validation qui produit des résultats. Les analyses hebdomadaires commencent après une analyse déclenchée par push ou pull request. L’historique d’analyse compte, pas l’activité Git antérieure.
Code scanning et Code Quality partagent l’évaluation d’activité. Le changement concerne Enterprise Cloud et est prévu pour Enterprise Server 3.24. GitHub n’exige aucune modification de configuration.
Séparer configuration et analyse
Notre proposition : noter état, dernier déclencheur, commit, heure du résultat et responsable. Une activation seule ne prouve pas un cycle hebdomadaire actif.
Pour une archive avec seule validation initiale, consignez configuration appliquée et validation vérifiée. Ajoutez séparément la preuve d’une analyse push ou pull request. Ce sont des notes d’équipe, pas de nouveaux statuts GitHub.
Moins d’analyses ne signifie pas moins de failles
Ne transformez pas la baisse des exécutions en score de sécurité. Vérifiez pertinence des alertes, traitement et lien avec des services actifs.
Un dépôt dormant peut contenir une source en production. Contrôlez couverture, dépendances et responsabilité sans déduire sa valeur de son activité.
Commencer par une lecture limitée
Comparez un dépôt maintenu et une archive. Lisez configuration et historique pour distinguer validation initiale et analyse par push ou pull request.
Ne créez pas de commits inutiles et ne changez pas de réglages validés pour ce contrôle. Documentez environnement et version en cas d’écart. Le schéma explique la revue ; ce n’est pas une capture produit.