Automatiser l’hygiène des dépôts GitHub
Automatisez les revues d’accès et l’archivage des dépôts GitHub sans perdre la traçabilité. Découvrez la méthode et ses garde-fous pour votre organisation.
GitHub : automatiser les accès et l'archivage sans perdre le contrôle
Un dépôt GitHub partagé avec des clients, des prestataires ou des partenaires, c'est rarement « juste du code ». Il faut aussi savoir qui a le droit d'y accéder, remettre les permissions à jour quand le projet change, et mettre en archive les dépôts qui ne servent plus. Tant que l'organisation est petite, ces tâches tiennent dans un tableau, ou dans quelques rappels envoyés à temps. Dès que ça grossit, on oublie vite - et ensuite, on a du mal à prouver ce qui a été décidé.
GitHub a présenté Evergreen, une application qui automatise ces opérations pour les organisations partagées. Elle s'appuie sur des briques natives de la plateforme : GitHub Actions, webhooks, issues, propriétés personnalisées et fichiers versionnés. Ce retour d'expérience dépasse le cas de GitHub : l'idée, c'est de transformer une tâche de sécurité « récurrente » en un processus vérifiable, avec des règles explicites et une possibilité de revenir en arrière.
Pourquoi automatiser l'hygiène des dépôts
Dans une organisation où des équipes internes travaillent avec des acteurs externes, l'accès à un dépôt n'est presque jamais une décision « pour toujours ». Un prestataire termine sa mission, une phase d'essai s'arrête, un projet change d'équipe. Si les permissions ne suivent pas ces évolutions, l'organisation conserve des accès dont personne ne sait vraiment pourquoi ils existent.
L'archivage pose un problème du même genre. Les dépôts inactifs s'empilent, les inventaires deviennent plus laborieux et certains artefacts peuvent rester « vivants » alors qu'ils ne devraient plus l'être. Un dépôt inactif n'est pas forcément dangereux. Mais il mérite une décision claire : on le maintient, on le transfère, ou on le met en archive.
Le réflexe classique consiste à demander aux responsables de faire le ménage périodiquement. Sur le papier, ça va. Dans la vraie vie, chacun doit se souvenir de la tâche, retrouver les bons interlocuteurs, relancer ceux qui sont en retard et conserver une preuve de la décision. Sur des centaines (ou des milliers) de dépôts, le processus finit par dépendre trop de la mémoire et de la disponibilité des individus.
La sécurité dépend aussi de la régularité
Une revue annuelle, même « parfaite », peut être moins utile qu'un rythme plus simple, trimestriel, et surtout suivi. Le but n'est pas de multiplier les contrôles : c'est de rendre le contrôle suffisamment léger pour qu'il arrive régulièrement, et suffisamment rigoureux pour que ses résultats soient fiables.
Avec le dispositif présenté par GitHub, les collaborateurs externes sont revus tous les trimestres. Les responsables confirment qui doit conserver un accès ; si personne ne répond dans le délai prévu, l'accès est retiré. Côté archivage, les dépôts sans activité humaine récente sont signalés puis archivés après une période de grâce s'ils restent inactifs.
Le principe est important : ne pas répondre ne doit pas équivaloir à autoriser. Mais si vous appliquez ça sans avertissement ni moyen de corriger une erreur, vous créez une mauvaise expérience - et donc un risque opérationnel. L'automatisation doit donc prévoir un « défaut sûr », tout en laissant un chemin clair pour demander une exception ou corriger un oubli.
Sécuriser sans confondre inactivité et inutilité
« Inactif » n'est pas synonyme de « inutile ». Un dépôt peut être peu modifié tout en restant essentiel : documentation de référence, code utilisé ponctuellement, outil mobilisé dans une procédure de reprise, etc. Avant d'automatiser, il faut définir ce que vous entendez par inactif dans votre contexte : qui peut contester un archivage, et quelles exceptions vous devez prévoir.
Même logique pour les accès. Retirer un accès peut bloquer un travail légitime si le responsable n'a pas vu la demande ou si le propriétaire du dépôt est mal identifié. L'automatisation réduit les oublis, mais elle ne remplace pas une décision humaine éclairée avant l'échéance. Ensuite seulement, la règle s'applique en cas de silence.
Une architecture fondée sur les fonctions natives de GitHub
Evergreen est présenté comme une application GitHub écrite en Go et exécutée dans un conteneur. L'architecture, elle, n'est pas basée sur un tableau de bord complexe ni sur une base de données dédiée. Le système assemble des éléments déjà disponibles dans GitHub : une application, des actions planifiées, des événements webhook, des issues, des propriétés personnalisées et un dépôt de contrôle avec des fichiers versionnés.
Le point fort, c'est que tout reste « dans l'écosystème » : les équipes qui utilisent déjà GitHub peuvent inspecter le fonctionnement sans tout reconstruire autour. Et non, ça ne veut pas dire qu'il n'y a rien à maintenir. Il faut toujours gérer l'application, les permissions, la gestion d'erreurs d'API, les journaux et l'évolution du processus. Le gain vient surtout du fait que l'interface et plusieurs éléments de traçabilité existent déjà.
Un dépôt de contrôle joue le rôle d'horloge et de mémoire
Un dépôt dédié pilote le calendrier et conserve l'état des revues. Quatre workflows planifiés déclenchent des événements vers l'application :
- Le 1er du mois prévu, le système repère les dépôts sans activité humaine récente et ouvre une issue d'avertissement.
- Le 8, il lance la revue des collaborateurs externes et crée une issue de checklist dans chaque dépôt concerné.
- Le 16, il archive les dépôts toujours inactifs après la période de grâce.
- Le 23, il retire les accès non confirmés à la fin de la revue.
Les étapes peuvent aussi être déclenchées manuellement. Le calendrier ne doit pas être un « compte à rebours irréversible » : il sert à organiser le travail, et des garde-fous évitent qu'une exécution manuelle déclenche une révocation avant l'échéance prévue.
Dans ce dépôt de contrôle, Evergreen conserve un fichier JSON par dépôt, dans un répertoire d'état. On y trouve notamment la photo initiale des accès, la date d'ouverture de la revue, l'échéance, la décision prise et les opérations effectuées. Comme tout est versionné dans Git, l'historique devient un journal d'audit : pour comprendre une modification ancienne, on relit l'historique du fichier concerné.
C'est pragmatique si vous avez un volume raisonnable et une équipe à l'aise avec Git. Il y a aussi des limites : il faut protéger les données, gérer les conflits de modification, et limiter strictement l'accès au dépôt de contrôle. L'historique versionné aide à l'audit, mais ne remplace pas une politique de conservation ni une analyse de conformité.
Les issues comme interface d'opération
Quand une revue démarre, Evergreen ouvre une issue dans chaque dépôt concerné. Les personnes qui doivent décider cochent les collaborateurs à conserver, puis ferment l'issue. L'application écoute l'événement de fermeture, lit les cases sélectionnées, enregistre les accès validés et retire les autres. Elle ajoute ensuite un commentaire récapitulant ce qui a changé.
Ce mécanisme évite de demander aux responsables de consulter un tableau de bord qu'ils n'iront peut-être pas regarder. L'action apparaît au bon endroit, avec le contexte du dépôt. L'issue sert aussi à expliquer la demande : date limite, ce qui se passera sans réponse, et comment signaler une erreur.
Attention toutefois : la fermeture d'une issue devient une action « privilégiée ». Evergreen vérifie que la personne qui la ferme est autorisée. Sinon, l'issue est rouverte et une explication est publiée. C'est essentiel : une interface simple ne doit pas permettre à n'importe quel participant de déclencher une action sensible.
Identifier les bons responsables sans tenir un tableur parallèle
Le système s'appuie sur une chaîne de résolution des responsables. Si le dépôt a une propriété personnalisée indiquant un utilisateur ou une équipe propriétaire, Evergreen s'en sert comme référence. Sinon, l'application regarde des auteurs récents d'issues ou de commits et garde ceux qui appartiennent à l'équipe habilitée à traiter les revues.
C'est pratique pour réduire le travail manuel, mais ce n'est pas infaillible : une activité récente ne garantit pas qu'une personne est encore responsable. Pour les dépôts importants (ou sensibles), la propriété explicite reste donc préférable. La détection par activité peut servir de solution de repli, à condition d'accepter qu'elle se trompera parfois.
Pour construire un dispositif similaire, basez-vous sur la documentation des GitHub Apps, des workflows GitHub Actions et des propriétés personnalisées d'une organisation. Autrement dit : assemblez ces composants autour d'un processus, pas juste parce qu'ils existent.
Des revues d'accès et un archivage encadrés
Une automatisation de sécurité ne devient pas fiable parce qu'elle tourne à heure fixe. Elle doit aussi gérer les cas « pas dans le scénario idéal » : échec d'API, issue mal renseignée, absence de réponse, etc.
Le défaut sûr doit être accompagné d'un délai lisible
Dans Evergreen, si une revue d'accès n'a pas de réponse, les accès présents dans la photo initiale sont révoqués. L'idée est simple : éviter de conserver indéfiniment un accès oublié. Pour limiter les surprises, le processus avertit les responsables, indique une échéance précise et envoie un rappel avant l'action.
La formulation de la demande compte. Une issue utile doit permettre de comprendre rapidement :
- quels collaborateurs sont concernés et quels accès sont en jeu ;
- qui doit trancher ;
- quels comptes conserver, et comment les sélectionner ;
- la date limite et la conséquence d'une absence de réponse ;
- comment demander une exception ou corriger une erreur.
Parfois, vous aurez besoin d'une exemption pour un dépôt particulier. Le retour d'expérience mentionne des propriétés personnalisées qui permettent aux propriétaires de l'organisation d'exclure un dépôt d'une revue d'accès ou d'un processus d'archivage. Dans ce cas, l'exemption doit rester visible et documentée : si elle devient une échappatoire sans justification ni propriétaire, elle recrée exactement le problème initial (des règles ignorées « par défaut »).
Échouer de façon fermée, et pouvoir réessayer
Imaginons une revue qui doit retirer cinq accès, mais qu'une erreur temporaire empêche de retirer le cinquième. Marquer l'opération comme « terminée » créerait un écart silencieux entre l'état déclaré et l'état réel. Evergreen adopte une approche plus prudente : la revue reste en attente, l'issue reste ouverte, et le prochain passage tente à nouveau les opérations qui ont échoué.
C'est l'application pratique du « fail closed » ici : l'état final n'est enregistré que quand toutes les révocations attendues ont réussi. Et il faut aussi viser l'idempotence : un nouvel essai ne doit pas produire d'effet indésirable si une partie du traitement a déjà été faite.
Les changements sont consignés dans l'issue. Si une révocation était erronée, le commentaire permet d'identifier les comptes concernés et de rétablir l'accès après vérification. Ce mécanisme ne rend pas les erreurs impossibles, mais il réduit fortement le temps de diagnostic et de remise en état.
Archiver n'est pas supprimer
L'un des garde-fous les plus importants du modèle, c'est le choix de ne jamais supprimer un dépôt. L'archivage rend le dépôt inactif pour les usages courants, tout en conservant son contenu et en permettant une réactivation. En pratique, ça réduit le coût d'une mauvaise classification par rapport à une suppression définitive.
La période d'inactivité doit coller à vos usages. Elle peut s'appuyer sur l'activité humaine, mais vous devez aussi décider si les commits automatisés, les mises à jour de dépendances ou l'activité d'un robot comptent. Sinon, un dépôt peut sembler actif juste parce qu'il reçoit des mises à jour techniques, tout en n'ayant plus de responsable - ou l'inverse.
Avant d'archiver, vérifiez aussi les dépendances opérationnelles : documentation qui pointe vers le dépôt, intégrations, secrets, ou processus de déploiement. L'archivage est réversible, mais il n'est pas sans impact.
Déployer l'automatisation sans créer de nouveaux risques
Une application capable de modifier des accès et l'état de dépôts mérite un déploiement progressif. Et franchement, c'est là que beaucoup de projets dérapent : ils veulent « tout activer » et découvrent ensuite les cas limites.
Le retour d'expérience côté GitHub insiste sur trois conditions : observer avant d'appliquer, préparer les utilisateurs, et concevoir le traitement en respectant les limites de la plateforme.
Commencer par une simulation
Le mode de simulation, ou dry run, doit calculer et journaliser les opérations envisagées sans modifier les accès ni archiver les dépôts. Ce n'est pas juste pour vérifier que ça ne plante pas. C'est pour confronter vos règles à la réalité : collaborateurs inattendus, dépôts sans issues activées, permissions inhabituelles, ou liste de collaborateurs vide.
Une bonne phase de test couvre plusieurs cas : dépôt avec propriétaires connus, dépôt sans activité, dépôt exempté, revue déjà partiellement traitée, et erreur d'API simulée. Pour chaque cas, vérifiez l'état attendu et la possibilité de reprendre le traitement. La simulation doit durer assez longtemps pour couvrir au moins un cycle représentatif, pas juste « quelques minutes sur un repo de test ».
Informer avant que les premières issues apparaissent
Dans une grande organisation, un message envoyé une seule fois ne suffit pas. Tout le monde ne lit pas au même rythme. Il faut donc expliquer le calendrier, les critères d'éligibilité, le format des issues, ce qui arrive en cas d'absence de réponse, et qui contacter si quelque chose semble incohérent.
C'est aussi le moment de valider la gouvernance. Si personne ne sait qui doit répondre pour un dépôt, la première revue ne révélera pas juste un souci technique : elle mettra en évidence un problème de responsabilité. Mieux vaut le rendre visible tout de suite, avec une procédure d'escalade, plutôt que de laisser l'application « deviner » en silence.
Mesurer les erreurs et respecter les limites de débit
Evergreen envoie des journaux structurés vers un outil de supervision. Cette observabilité vous aide à repérer les situations réelles qui n'étaient pas prévues pendant les tests, puis à ajuster les règles avant que ça ne produise des effets trop étendus.
À grande échelle, les limites de débit deviennent une contrainte de conception. Le retour d'expérience mentionne notamment des limites secondaires sur certaines créations de contenu, avec des plafonds de 80 requêtes par minute et 500 par heure pour ce type d'opération. Ces valeurs peuvent évoluer et dépendent du contexte : vérifiez toujours la documentation officielle sur les limites de débit avant de dimensionner.
Le système privilégie l'évitement proactif : traitement par lots, espacement des appels qui créent du contenu, pauses entre lots. Et surtout, il ne traite que les dépôts qui nécessitent réellement une action. Ça vaut mieux qu'un traitement massif suivi d'un ralentissement improvisé après déclenchement d'une limite.
Pour une organisation européenne, ajoutez enfin une vérification de minimisation des données : ne stockez que ce qui est nécessaire à la revue, limitez l'accès au dépôt d'état, et définissez une durée de conservation compatible avec vos obligations internes et le RGPD. Une trace utile à l'audit n'a pas besoin de devenir un stockage indéfini.
Un plan de déploiement pragmatique
Une séquence raisonnable peut ressembler à ceci :
- Choisir un périmètre limité, par exemple quelques équipes volontaires et des dépôts non critiques.
- Définir les règles, les délais, les exemptions et les personnes autorisées à valider une revue.
- Simuler plusieurs cycles, puis examiner les journaux et les cas limites avec les propriétaires des dépôts.
- Activer une seule automatisation à la fois, d'abord les revues ou d'abord l'archivage, pas forcément les deux.
- Suivre les résultats, notamment les échecs, les corrections manuelles, les exceptions et les délais de réponse.
- Élargir progressivement, seulement quand les règles et la reprise après erreur sont maîtrisées.
Oui, ça prend plus de temps qu'un déploiement « tout d'un coup » en une journée. Mais ça coûte généralement moins cher que d'avoir une révocation incorrecte à grande échelle - ou un système contourné parce que personne n'a confiance.
Conclusion : automatiser la routine, pas le jugement
L'intérêt d'Evergreen n'est pas d'automatiser toutes les décisions liées aux dépôts. C'est surtout de rendre les tâches répétitives plus prévisibles : demander une validation, rappeler une échéance, retirer un accès oublié, ou archiver un dépôt après une période définie. Les issues servent d'interface concrète, les fichiers versionnés gardent une trace, et les mécanismes d'erreur évitent de déclarer une opération terminée trop tôt.
Si vous voulez commencer proprement, choisissez d'abord une tâche récurrente et bien cadrée. Définissez la règle de décision, simulez son fonctionnement, et vérifiez qu'une erreur peut être corrigée. Ensuite seulement, élargissez le périmètre. Une automatisation imparfaite mais inspectable, réversible et réellement utilisée vaut mieux qu'un concept complet qui ne quitte jamais le tableau blanc.