10 min de lecture - Dépôts GitHub inactifs : imposez une analyse avant reprise

Le 1er octobre 2026, GitHub a modifié la façon dont il décide si un dépôt inactif doit recevoir les analyses hebdomadaires de la configuration par défaut et de GitHub Code Quality. L’analyse initiale de validation, celle qui suit un changement de configuration ou celle que déclenche la détection d’un nouveau langage ne suffit plus à faire passer un dépôt dormant pour actif. Le rythme hebdomadaire commence après une analyse déclenchée par un push ou une pull request, selon l’annonce de GitHub.

La documentation actuelle de GitHub considère comme actif, pour cette règle, un dépôt où un push ou une pull request a déclenché une analyse de la configuration par défaut au cours des 180 derniers jours. Le propriétaire d’une organisation peut maintenir une analyse tous les 30 jours pour les dépôts inactifs, sans pouvoir choisir un autre intervalle avec ce réglage. Le guide de configuration par défaut consigne ces deux règles.

Cette évolution mesure l’activité d’analyse, pas le risque ni l’état du cycle de vie. Un artefact issu d’un dépôt silencieux peut encore fonctionner en production, se trouver chez un client ou fournir une bibliothèque partagée. L’équipe doit donc vérifier l’usage métier.

Classez le code dormant, maintenez une analyse récurrente lorsque l’exposition le justifie et exigez un résultat récent avant toute réactivation. Imposer une analyse hebdomadaire à chaque ancien prototype créerait du travail sans régler la responsabilité.

Lisez précisément le changement

La configuration par défaut exécute toujours une première analyse de validation lors de son activation. Avec le nouveau calcul, ce résultat initial ne lance toutefois pas le rythme hebdomadaire. Il en va de même pour une analyse causée uniquement par un changement de configuration ou de langage. Un push ou une pull request doit d’abord déclencher l’analyse. GitHub indique que le changement s’applique dès maintenant à GitHub Enterprise Cloud et sera pris en charge par GitHub Enterprise Server 3.24.

Lors d’un déploiement à grande échelle, la configuration par défaut peut ainsi produire des résultats immédiats sans engager six mois d’analyses hebdomadaires sur du code que personne ne modifie. GitHub veut réduire ces exécutions inattendues.

Elle retire aussi un indicateur rassurant mais incomplet. Un tableau de bord qui affiche la configuration par défaut comme active ne prouve pas, à lui seul, que les analyses planifiées continuent. L’état effectif dépend de l’historique des analyses éligibles et du réglage choisi par l’organisation pour les dépôts inactifs. Consignez les deux.

La configuration avancée suit le workflow présent dans le dépôt. La référence GitHub sur les workflows CodeQL explique qu’un workflow avancé peut combiner des événements push, pull request et planifiés. Une planification ne s’exécute que si le fichier du workflow existe sur la branche par défaut. Identifiez donc le type de configuration avant d’appliquer la règle des 180 jours.

Classez le code dormant selon son usage

La date du dernier commit ne constitue pas un registre de cycle de vie. Commencez par quatre classes opérationnelles et attribuez un responsable à chaque dépôt :

Ne déduisez pas l’état de production de l’activité GitHub. Vérifiez auprès du responsable et dans les dossiers de déploiement si un artefact, une infrastructure ou un plan de reprise dépend encore du dépôt. « Aucun commit récent » ne prouve pas l’absence d’usage.

Les dépôts calmes mais maintenus demandent une attention particulière. Une analyse planifiée peut appliquer de nouvelles requêtes à un code inchangé. Le guide GitHub sur les workflows donne cette raison à la planification : elle peut signaler des vulnérabilités et erreurs découvertes après la dernière modification du code. Si le logiciel reste une version prise en charge, l’absence de nouveaux commits ne supprime pas ce bénéfice.

Le Secure Software Development Framework du NIST recommande de choisir la revue et l’analyse du code selon l’étape du logiciel, de consigner et qualifier les problèmes découverts, puis d’exécuter une analyse automatisée régulière ou continue pour les versions prises en charge. Le NIST ne prescrit aucun réglage GitHub. Il appuie cependant la décision de fond : la fréquence doit suivre le support et le risque, pas uniquement l’âge du dépôt.

Placez un contrôle devant toute reprise

Un dépôt inactif revient souvent sous la pression du calendrier. La première pull request mélange alors reprise métier, mise à niveau des dépendances, restauration de la CI et revue de sécurité. Une correction ordinaire ne suffit pas à porter ces décisions.

Traitez la réactivation comme un événement du cycle de vie. Avant la première livraison, exigez un responsable nommé, l’usage prévu, la branche et l’environnement d’exécution pris en charge, les données et identifiants accessibles, ainsi que la date du dernier déploiement fiable. Marquez les hypothèses impossibles à confirmer. Un ancien prototype ne doit pas retrouver l’accès à la production parce que sa compilation réussit.

Déclenchez ensuite une analyse par le chemin approuvé. Conservez son URL, le commit, la version de l’outil, les langages couverts et la décision sur chaque alerte. Avec la configuration par défaut, un push ou une pull request éligible peut relancer l’analyse ; bloquez la fusion tant que son résultat n’a pas été qualifié. Si la politique exige une analyse avant toute modification, maintenez le rythme mensuel ou utilisez un workflow avancé approuvé.

CodeQL reste un contrôle parmi d’autres. Examinez les dépendances, la provenance de la compilation, les permissions des workflows, les secrets et les identifiants de déploiement avec les outils prévus par votre processus de sécurité. Rétablissez la protection des branches et les revues obligatoires avant de redonner à la chaîne CI/CD un accès à la production. Notre revue des frontières de confiance dans GitHub Actions explique pourquoi un ancien workflow mérite son propre examen lors de la reprise.

Ne laissez pas le premier délai fonctionnel décider quels résultats sont acceptables. Pour chaque problème significatif, le responsable du service et la personne chargée de la sécurité doivent consigner l’une de ces décisions : corriger avant livraison, accepter pendant une durée définie avec un approbateur responsable, ou arrêter la réactivation. Il s’agit de décisions de gouvernance qu’un résultat vert ne peut pas prendre automatiquement.

Rendez la couverture visible à l’échelle du portefeuille

Les réglages dépôt par dépôt deviennent difficiles à interpréter dès que l’organisation possède plus de projets que son équipe de sécurité ne peut en mémoriser. Construisez un inventaire court à partir de champs observables :

• dépôt et responsable désigné ;
• classe de cycle de vie et date de dernière confirmation ;
• artefacts déployés ou distribués qui en dépendent ;
• configuration par défaut ou avancée de l’analyse du code ;
• dernière analyse liée à un push ou une pull request et dernière analyse planifiée ;
• langages couverts, alertes ouvertes et exceptions documentées ;
• état de l’autorisation de reprise.

L’inventaire doit distinguer « configuré » et « exécuté récemment ». Il doit aussi signaler les dépôts dont la configuration ne peut pas analyser le langage principal, dont le workflow ne fonctionne plus ou dont les résultats n’ont aucun responsable. Une licence attribuée et un réglage activé constituent des entrées, pas une preuve de couverture.

Regroupez les exceptions comparables. Une politique documentée peut couvrir des dépôts de formation qui partagent le même cycle de vie. Un service sensible ou un dépôt d’infrastructure dormant demande son propre responsable et ses propres preuves.

Pour les équipes qui testent déjà les résultats assistés par IA, gardez cette expérimentation séparée du socle. Notre cadre de pilote pour GitHub AI Scan explique comment vérifier les résultats de l’outil sans affaiblir les contrôles de fusion existants. Un nouveau détecteur ne corrige ni l’absence de responsable ni une planification invisible.

Vérifiez le réglage sans créer de travail inutile

Rapprochez la liste des dépôts inactifs des registres de services, de versions et d’actifs. Repérez ceux qui soutiennent encore un usage, ainsi que les dépôts actifs sans analyse récente réussie.

Maintenez les analyses mensuelles pour les dépôts calmes lorsqu’un nouveau résultat peut modifier une décision de support ou de déploiement. Réservez le contrôle de reprise au code de référence figé qui ne peut ni fonctionner ni être distribué. Retirez, selon le processus documentaire de l’organisation, les dépôts sans responsable et sans besoin de conservation. La combinaison varie selon le portefeuille, mais chaque exception doit indiquer son décideur et sa date d’expiration.

Testez le contrôle sur un dépôt dormant avant de l’étendre. Confirmez le déclenchement de l’analyse, le blocage de la fusion et la conservation de la preuve. Corrigez tout runner absent, langage non pris en charge ou workflow cassé avant une véritable reprise.

L’approche des services Exceev relie évaluation technique, mise en œuvre et transfert aux équipes lorsque la gouvernance des dépôts révèle un problème de responsabilité plus large.

Sources et limites

Nous avons ouvert et vérifié chaque source ci-dessous le 2 octobre 2026.

• L’annonce GitHub du 1er octobre établit le nouveau calcul de l’activité, le fonctionnement de la validation initiale, le périmètre actuel du produit et le motif annoncé pour la mise à jour.
• Le guide GitHub de la configuration par défaut définit la fenêtre d’activité de 180 jours et le réglage facultatif d’une analyse tous les 30 jours pour les dépôts inactifs.
• La référence GitHub des workflows CodeQL décrit les déclencheurs événementiels et planifiés de la configuration avancée, ainsi que la présence requise du workflow sur la branche par défaut.
• Le NIST SP 800-218, Secure Software Development Framework apporte une recommandation indépendante sur l’analyse adaptée à l’étape du logiciel, la qualification des problèmes et l’analyse régulière ou continue des versions prises en charge.

GitHub fait autorité sur le fonctionnement de son produit ; le NIST ne recommande ni GitHub ni ce modèle d’exploitation. Nous n’avons examiné aucun dépôt, licence, workflow, runner, résultat ou dépendance de production d’un client. GitHub peut modifier son service et sa documentation après la date de revue. L’analyse du code ne peut pas établir qu’un logiciel est exempt de vulnérabilités, et cet article ne constitue ni une certification de sécurité ni un avis juridique.