06 Administration & gouvernance
Audit logs, API et choix du bon contrôle
6.9 Audit logs
Définition
Les audit logs permettent de consulter les actions importantes liées à Copilot dans une organisation ou une enterprise.
GitHub indique que l’audit log enterprise peut inclure des changements liés au plan Copilot, aux settings, aux policies, à l’attribution ou perte de licence, ainsi que des activités d’agents sur GitHub. (docs.github.com)
À quoi servent les audit logs ?
Ils servent à répondre à des questions comme :
Qui a activé cette policy ?
Quand cette fonctionnalité a-t-elle été désactivée ?
Qui a reçu une licence Copilot ?
Quel agent a effectué une action ?
Quels changements ont été faits sur le plan Copilot ?Exemples d’événements auditables
Selon le niveau et la configuration, on peut retrouver des événements liés à :
- changement de plan Copilot ;
- modification de policies ;
- attribution de licence ;
- retrait de licence ;
- activité d’agents ;
- modifications de settings.
Exemple scénario
Une entreprise constate que Copilot CLI est soudainement disponible pour tous les développeurs.
Question :
Comment savoir qui a changé la configuration ?Réponse :
Consulter les audit logs.Recherche dans les audit logs
Les audit logs peuvent généralement être filtrés/recherchés par :
- action ;
- utilisateur ;
- date ;
- organisation ;
- type d’événement ;
- catégorie Copilot.
Ce que l’audit log montre, et ce qu’il ne montre pas
L’audit log enregistre les changements du plan Copilot (réglages, policies, seats reçus ou perdus) et l’activité des agents sur GitHub. Il n’enregistre pas les sessions locales des clients : les prompts envoyés à Copilot n’y figurent pas.
Une recherche de base se fait avec le qualificatif action:copilot ; l’activité des agents se filtre avec actor:Copilot. L’audit log est disponible au niveau de l’organisation et de l’enterprise : pour l’enterprise, il se consulte en tant qu’enterprise owner ou avec le rôle personnalisé « Read enterprise audit logs ». Il conserve les événements des 180 derniers jours : pour un historique plus long, on diffuse (stream) l’audit log vers une plateforme SIEM. Il n’est pas utile de retenir les noms d’événements : on retient ce que le journal permet de prouver.
Pourquoi c’est important pour l’examen ?
Parce que les audit logs sont le bon réflexe quand la question mentionne :
investigate
who changed
when changed
trace
compliance
audit
governanceQuestion type examen
Une enterprise owner veut savoir quand une policy Copilot a été modifiée et par qui.
Quelle fonctionnalité doit-elle utiliser ?
Bonne réponse :
Audit logs.6.10 Gestion des subscriptions avec REST API
Définition
GitHub fournit des endpoints REST API pour gérer les subscriptions Copilot.
GitHub indique que l’API REST peut être utilisée pour gérer les subscriptions GitHub Copilot Business ou GitHub Copilot Enterprise pour une organisation. Ces endpoints sont en public preview et peuvent changer. (docs.github.com)
Pourquoi utiliser l’API REST ?
L’API est utile quand tu veux automatiser :
- attribution de licences ;
- retrait de licences ;
- suivi des seats ;
- intégration avec un système RH ;
- intégration avec IAM ;
- onboarding/offboarding ;
- reporting ;
- gouvernance à grande échelle.
Qui peut l’utiliser, et avec quelles limites ?
Seuls les organization owners peuvent gérer les seats d’une organisation par ces endpoints, qui concernent Copilot Business et Copilot Enterprise. Retirer un utilisateur place son seat en attente d’annulation : il perd l’accès à la fin du cycle de facturation, sauf s’il le garde par l’appartenance à une équipe. Ces endpoints sont en public preview et peuvent changer : une automatisation bâtie dessus se maintient. Il n’est pas utile de retenir les adresses ni les formats de réponse.
Exemple scénario
Une entreprise a 2 000 développeurs.
Elle veut :
- donner Copilot aux membres de l’équipe engineering ;
- retirer Copilot quand une personne quitte l’équipe ;
- générer un rapport mensuel d’usage ;
- synchroniser les licences avec un système interne.
Faire ça manuellement serait fragile.
La REST API est plus adaptée.
Exemples conceptuels d’actions API
Selon les endpoints disponibles, l’API peut permettre de :
- lister les utilisateurs ayant une subscription Copilot ;
- attribuer une subscription à un utilisateur ou une équipe ;
- retirer une subscription ;
- consulter l’usage ou les seats ;
- automatiser l’onboarding ;
- automatiser l’offboarding ;
- intégrer Copilot à un processus interne de gouvernance.
À retenir :
REST API = automatisation de la gestion Copilot à grande échelle.Piège d’examen
Question possible :
An organization wants to automatically assign and remove Copilot seats based on an internal HR system.
What should it use?Bonne réponse :
GitHub REST API for Copilot subscriptions.Mauvaise réponse :
Ask each developer to enable or disable Copilot manually.6.11 Cas d’examen : choisir le bon niveau d’administration 🧪
Cette section est importante, car l’examen peut mélanger utilisateur, organisation et enterprise.
Tableau de décision rapide
| Besoin | Mécanisme recommandé |
|---|---|
| Modifier ses préférences locales Copilot | Utilisateur |
| Attribuer des licences aux membres d’une organisation | Organisation |
| Appliquer une policy à plusieurs organisations | Enterprise |
| Activer ou désactiver Copilot CLI pour une équipe | Policy d’organisation, ou d’enterprise si elle impose la valeur |
| Contrôler Copilot Code Review sur des repositories | Policy d’organisation ou d’enterprise, et ruleset pour la revue automatique |
| Savoir qui a changé une policy | Audit logs |
| Automatiser attribution/retrait de licences | REST API |
| Exclure des fichiers sensibles du contexte Copilot | Content exclusions |
| Contrôler les modèles disponibles | Models policy |
| Contrôler IDE vs GitHub.com | Feature policies |
Cas 1 : Fonctionnalité bloquée
Scénario :
Un développeur ne peut pas utiliser Copilot CLI alors qu’il a une licence Copilot.
Bonne réponse :
Vérifier les organization ou enterprise policies.Pourquoi ?
Une licence donne accès à Copilot, mais une policy peut bloquer une fonctionnalité.
Cas 2 : Gouvernance multi-organisations
Scénario :
Une enterprise possède plusieurs organisations GitHub et veut appliquer les mêmes règles Copilot partout.
Bonne réponse :
Configurer les policies au niveau enterprise.Cas 3 : Investigation compliance
Scénario :
Une policy Copilot Code Review a été modifiée sans prévenir l’équipe sécurité.
Bonne réponse :
Consulter les audit logs pour savoir qui a modifié la policy et quand.Cas 4 : Automatisation des seats
Scénario :
Une organisation veut attribuer Copilot automatiquement aux nouveaux développeurs et le retirer lors de l’offboarding.
Bonne réponse :
Utiliser la REST API pour gérer les subscriptions Copilot.Cas 5 : Code Review IA
Scénario :
Une organisation active Copilot Code Review automatiquement sur les PR.
À retenir :
Copilot Code Review aide la review, mais ne remplace pas les reviewers humains, les tests, la CI ou les scans sécurité.À retenir pour le GH-300
- L’audit log dit qui a changé quoi et quand (policies, réglages, seats, activité des agents) : il enquête, il ne bloque rien.
- Il ne contient pas les prompts envoyés localement ; il garde les 180 derniers jours, et au-delà on le diffuse vers un SIEM.
- L’API REST automatise les seats Copilot Business ou Enterprise : réservée aux organization owners, en public preview, donc à maintenir.
- Choisir le bon contrôle : la policy empêche, l’audit log détecte, l’API automatise ; le niveau dépend de la portée voulue.
Pratique : Audit, API ou policy ?
Pour chaque besoin, choisis le mécanisme de gouvernance : une policy (empêcher), l’audit log (enquêter), un SIEM (conserver), un ruleset (cibler des dépôts) ou l’API REST (automatiser les seats). Aucune adresse ni syntaxe n’est demandée.
Chargement de la question…
Questions de la leçon
Chargement de la question…
Pour finir
À retenir
- L’audit log dit qui a changé quoi et quand (policies, réglages, seats, activité des agents) : il enquête, il ne bloque rien.
- Il ne contient pas les prompts envoyés localement ; il garde les 180 derniers jours, et au-delà on le diffuse vers un SIEM.
- L’API REST automatise les seats Copilot Business ou Enterprise : réservée aux organization owners, en public preview, donc à maintenir.
- Choisir le bon contrôle : la policy empêche, l’audit log détecte, l’API automatise ; le niveau dépend de la portée voulue.
Objectifs GH-300
- Audit logs (Use Copilot audit logs)
- Subscriptions API (Use the Copilot subscriptions API)
- Policies d’organisation (Manage Copilot organization policies)
Achèvement
Il reste à faire : , .