GitHub et RGPD : guide de conformité 2026

L’essentiel. GitHub (propriété de Microsoft) est un sous-traitant au sens de l’article 28 du RGPD pour vos dépôts privés et vos organisations. Le contrat de référence est le Microsoft Products and Services Data Protection Addendum (DPA), qui couvre GitHub Enterprise. Le vrai risque RGPD de GitHub n’est pas le code lui-même mais ce qui gravite autour : adresses email dans l’historique des commits, données personnelles hardcodées dans des jeux de tests, secrets et clés d’API exposés, journaux de GitHub Actions. La conformité repose sur trois piliers : le DPA Microsoft signé et documenté, une configuration verrouillée (SSO, protection des secrets, dépôts privés par défaut) et une hygiène de développement qui interdit les données personnelles réelles dans le code.

GitHub est la plateforme de référence pour l’hébergement de code source, la collaboration entre développeurs et l’intégration continue. Utilisé par une écrasante majorité d’équipes techniques françaises — startups, éditeurs de logiciels, DSI de grands groupes —, il concentre bien plus que du code : issues, pull requests, revues, journaux d’exécution, discussions. Cette richesse fonctionnelle en fait un traitement de données personnelles que beaucoup d’équipes n’ont jamais qualifié comme tel.

Dans ma pratique de conseil auprès d’éditeurs de logiciels, je constate deux erreurs symétriques. La première : considérer que « GitHub ne contient que du code, donc pas de données personnelles » — ce qui est faux dès qu’on regarde l’historique des commits et les issues. La seconde : traiter GitHub comme un simple outil interne sans contrat de sous-traitance formalisé. Les deux exposent l’organisation. Pour une vue d’ensemble de la conformité des outils SaaS, consultez notre guide RGPD par outil, et pour l’alternative directe, notre analyse de GitLab.

Une question connexe mérite une analyse dédiée : l’usage de l’assistant de génération de code intégré, que nous traitons séparément dans notre article GitHub Copilot et RGPD.

Qualification juridique : GitHub comme sous-traitant

Le statut de sous-traitant au sens de l’article 28

Pour les dépôts et organisations de votre entreprise, GitHub, Inc. (groupe Microsoft) agit en qualité de sous-traitant au sens de l’article 28 du RGPD. Votre organisation est le responsable de traitement : vous décidez quels dépôts créer, quels membres inviter, quelles données y placer. GitHub fournit l’infrastructure et traite ces données selon les instructions contractuelles.

Il faut néanmoins distinguer deux réalités :

• Vos dépôts et organisations : GitHub est sous-traitant, couvert par le DPA Microsoft.
• Le compte personnel d’un développeur (profil public, contributions publiques) : GitHub agit là comme responsable de traitement de ses propres utilisateurs, ce qui relève de la relation entre GitHub et la personne, pas de votre organisation.

Cette distinction compte pour un dépôt public open source : les contributions publiques d’un développeur (nom, email de commit visible) relèvent d’un régime différent de celui de vos dépôts privés d’entreprise.

Les catégories de données personnelles présentes dans GitHub

C’est le point le plus sous-estimé. GitHub concentre des données personnelles à plusieurs endroits :

• Historique des commits : chaque commit est signé par un nom et une adresse email. L’historique complet d’un dépôt expose ainsi les coordonnées de tous les contributeurs, de façon indélébile.
• Issues et pull requests : descriptions, commentaires, mentions de personnes, parfois coordonnées de clients rapportées dans un ticket de bug.
• Données personnelles dans le code : jeux de tests contenant de vrais emails, fichiers de configuration avec des données de production, dumps de bases de données commités par erreur.
• Secrets et identifiants : clés d’API, tokens, identifiants, parfois données personnelles, exposés dans le code ou dans l’historique.
• Journaux de GitHub Actions : les logs d’exécution des workflows CI/CD peuvent contenir des variables d’environnement, des adresses email, des identifiants.
• Profils des membres : noms, emails, appartenance aux équipes, activité.

Le principe de minimisation des données impose de ne jamais utiliser de données personnelles réelles dans le code, les tests ou les jeux de démonstration : des données synthétiques ou anonymisées doivent être la règle.

Analyse du DPA Microsoft

GitHub Enterprise est couvert par le Microsoft Products and Services Data Protection Addendum (DPA), l’un des contrats de sous-traitance les plus complets du marché. Voici les points d’analyse au regard de l’article 28 du RGPD.

Exigence Art. 28 RGPD	Couverture documentée dans le DPA Microsoft
Objet, durée, nature et finalité	Définis dans le DPA et les conditions du service
Types de données et catégories de personnes	Décrits dans le DPA
Instructions documentées du responsable	Traitement sur instructions documentées
Confidentialité du personnel	Engagement de confidentialité du personnel Microsoft
Mesures de sécurité (Art. 32)	Mesures techniques et organisationnelles détaillées
Sous-traitants ultérieurs	Liste publiée + mécanisme de notification
Assistance aux droits des personnes	Engagement d’assistance prévu
Suppression ou restitution en fin de contrat	Suppression après résiliation, export possible
Droit d’audit	Rapports de certification et audits indépendants

Je ne prononce pas de verdict de conformité : le DPA Microsoft décrit des engagements contractuels solides, mais leur portée dépend du plan souscrit (GitHub Enterprise vs comptes gratuits) et de votre configuration. Le DPA Microsoft présente l’avantage d’être unanimement reconnu comme mature et de couvrir l’ensemble des services Microsoft/GitHub sous un contrat unique, ce qui simplifie la gestion contractuelle pour les organisations déjà clientes de Microsoft 365 ou Azure.

Transferts internationaux

Localisation et mécanismes de transfert

GitHub, Inc. et Microsoft Corporation sont des sociétés américaines. Le transfert de données hors UE doit donc être documenté. Selon la documentation consultée en juillet 2026, Microsoft s’appuie sur les clauses contractuelles types (CCT) intégrées au DPA et sur sa certification au cadre de protection des données UE–États-Unis (Data Privacy Framework).

Microsoft propose, à travers son offre « EU Data Boundary », des engagements de localisation des données de certains services dans l’Union européenne. La couverture précise de GitHub Enterprise par ces engagements de résidence évolue et doit être vérifiée dans la documentation contractuelle à jour au moment de votre déploiement — à confirmer selon le plan et la région retenus.

Votre analyse d’impact sur les transferts (TIA) doit évaluer le cadre juridique américain et documenter les mesures supplémentaires : chiffrement, restriction des données personnelles réelles dans le code, gestion des accès.

Sécurité informatique

GitHub, en tant que plateforme dédiée aux développeurs, propose un arsenal de sécurité particulièrement développé.

Certifications et conformité documentées : SOC 1/2/3, ISO/IEC 27001, alignement sur les référentiels Microsoft.

Mesures techniques documentées :

• Chiffrement en transit (TLS) et au repos.
• Authentification renforcée : SSO SAML, MFA obligatoire, SCIM pour le provisionnement.
• Secret scanning : détection automatique des secrets (clés d’API, tokens) commités dans le code, avec alerte et, pour certains fournisseurs, révocation automatique.
• Push protection : blocage du push d’un secret détecté avant qu’il n’atteigne le dépôt.
• Dependabot et analyse de dépendances : détection des vulnérabilités des bibliothèques tierces.
• Code scanning : analyse statique du code à la recherche de failles.
• Journal d’audit de l’organisation (accès, modifications de permissions).

Ces fonctionnalités de sécurité applicative — regroupées sous GitHub Advanced Security — sont un atout majeur pour prévenir la fuite de secrets et de données personnelles, à condition d’être activées.

Configuration recommandée pour la conformité RGPD

1. Souscrire GitHub Enterprise et signer le DPA. Les comptes gratuits n’offrent pas le même socle contractuel et de gouvernance. Acceptez le DPA Microsoft et archivez-en une copie datée.

2. Activer le SSO et le MFA obligatoire. Imposez l’authentification via votre fournisseur d’identité (SSO SAML) et le MFA pour tous les membres de l’organisation.

3. Activer secret scanning et push protection. C’est une mesure de sécurité de premier ordre : elle empêche l’exposition de secrets et de données personnelles dans le code. La push protection bloque le problème avant qu’il ne se produise.

4. Passer les dépôts en privé par défaut. Configurez l’organisation pour que la visibilité par défaut soit privée, et restreignez qui peut créer des dépôts publics.

5. Interdire les données personnelles réelles dans le code. Formalisez cette règle dans votre charte informatique : aucune donnée personnelle de production dans les tests, les jeux de démonstration ou les fixtures. Utilisez des données synthétiques ou anonymisées.

6. Cadrer les emails de commit. Configurez l’usage d’adresses email professionnelles maîtrisées pour les commits, ou l’option de masquage d’email pour les dépôts publics, afin de ne pas exposer les coordonnées personnelles des développeurs.

7. Sécuriser les journaux de GitHub Actions. Évitez d’imprimer des données sensibles dans les logs, utilisez les secrets chiffrés d’Actions pour les identifiants, et limitez la rétention des logs.

8. Documenter le traitement au registre. Inscrivez GitHub dans votre registre des traitements en précisant les catégories de données (contributeurs, contenu des issues, données éventuellement présentes dans le code).

9. Structurer les permissions par équipe. Attribuez les accès aux dépôts via des équipes, en appliquant le moindre privilège. Un prestataire externe ne doit accéder qu’aux dépôts strictement nécessaires.

Erreurs fréquentes et incidents typiques

Le secret ou la donnée personnelle commis dans l’historique

Un développeur commet par erreur un fichier de configuration contenant une clé d’API, un mot de passe de base de données ou un export nominatif. Même supprimé dans un commit ultérieur, le fichier reste dans l’historique Git et demeure accessible. Cet incident peut constituer une violation de données personnelles si le fichier contenait des données personnelles et que le dépôt était exposé. La bonne réaction : révoquer immédiatement le secret, réécrire l’historique si nécessaire, et évaluer l’obligation de notification. Notre modèle de notification à la CNIL sous 72 heures aide à cadrer cette évaluation.

Le dépôt privé rendu public par erreur

Le changement de visibilité d’un dépôt d’un clic peut exposer publiquement du code contenant des données personnelles ou des secrets. Restreignez le droit de rendre un dépôt public à un nombre limité d’administrateurs.

Les emails de contributeurs exposés indéfiniment

L’historique des commits d’un dépôt public expose les adresses email de tous les contributeurs, de façon permanente. Pour les projets open source, la fonction de masquage d’email de GitHub et une politique d’adresses dédiées limitent cette exposition.

GitHub Actions et les logs verbeux

Les workflows CI/CD génèrent des journaux qui capturent parfois des variables d’environnement, des tokens ou des adresses email. Auditez vos workflows pour éviter l’impression de données sensibles et limitez la durée de conservation des logs.

Sur le plan de la gouvernance, tenir à jour l’inventaire des sous-traitants techniques et documenter chaque traitement devient vite ingérable manuellement quand l’entreprise multiplie les plateformes cloud : un logiciel RGPD permet d’industrialiser la cartographie des traitements et le suivi des DPA fournisseurs.

FAQ

GitHub est-il conforme au RGPD ?

GitHub Enterprise fournit les éléments contractuels et techniques d’un usage conforme : DPA Microsoft, certifications SOC et ISO 27001, chiffrement, SSO/MFA, secret scanning, push protection. Je ne formule pas de verdict de conformité : celle-ci dépend du plan souscrit, de votre configuration et de votre hygiène de développement. Une équipe qui commet des données personnelles réelles dans le code ou expose des secrets ne sera pas conforme, quels que soient les engagements de l’éditeur.

GitHub héberge-t-il vraiment des données personnelles si je n’y mets que du code ?

Oui, presque toujours. Même un dépôt « purement technique » contient l’historique des commits, qui expose les noms et adresses email de tous les contributeurs. S’y ajoutent fréquemment des données personnelles dans les issues, les jeux de tests et les journaux. L’affirmation « il n’y a que du code » ne résiste jamais à un examen de l’historique et des tickets.

Faut-il un DPA spécifique pour GitHub ou le DPA Microsoft suffit-il ?

Le Microsoft Products and Services DPA couvre GitHub Enterprise dans le cadre des services Microsoft/GitHub. Il n’est en général pas nécessaire de signer un contrat de sous-traitance distinct : il faut accepter et archiver le DPA Microsoft applicable à votre abonnement, et vérifier qu’il couvre bien votre plan GitHub. Conservez une copie datée du document.

Un secret commis par erreur constitue-t-il une violation de données à notifier ?

Cela dépend du contenu et de l’exposition. Si le fichier commis contenait des données personnelles et que le dépôt était accessible (public ou ouvert à des tiers non autorisés), l’incident peut constituer une violation de données soumise à l’obligation d’évaluation, voire de notification à la CNIL sous 72 heures. Un secret purement technique (clé d’API sans donnée personnelle) exposé sur un dépôt privé relève plutôt de la sécurité que d’une violation notifiable, mais impose la révocation immédiate. Chaque cas doit être évalué individuellement.

Comment répondre à une demande d’effacement sur GitHub ?

C’est techniquement délicat à cause de la nature de Git : une donnée personnelle présente dans l’historique des commits ne disparaît pas par simple suppression dans un commit ultérieur. Il faut réécrire l’historique du dépôt, ce qui a des effets sur toutes les copies clonées. Pour les données présentes dans les issues, les commentaires ou les profils, la suppression est plus simple. Documentez la procédure, distinguez le contenu applicatif de l’historique Git, et prévoyez les cas où la réécriture d’historique est nécessaire.

GitHub Copilot pose-t-il des questions RGPD spécifiques ?

Oui. L’assistant de génération de code traite le contexte de votre code et soulève des questions de confidentialité et de transfert distinctes de l’hébergement de dépôts. Nous les traitons dans un article dédié : GitHub Copilot et RGPD.