GitLab et RGPD : hébergement, pipelines et Duo
GitLab.com, Dedicated ou auto-hébergé : vérifiez les flux Duo, les journaux CI/CD, le DPA et la suppression des données dans Git.
L’analyse RGPD de GitLab commence par le déploiement réellement utilisé, puis par les flux qui en sortent. Un dépôt hébergé sur votre infrastructure peut encore alimenter un service d’IA, un outil de support, un runner externe ou une intégration. L’étiquette « auto-hébergé » ne suffit donc pas à conclure à l’absence de transfert.
Décrire l’architecture dans le dossier RGPD
| Déploiement | Point à vérifier | Preuve à conserver |
|---|---|---|
| GitLab.com | Services hébergés, contrats, sous-traitants et flux internationaux | Version contractuelle et schéma des flux |
| GitLab Dedicated | Régions principales, de reprise et de sauvegarde | Configuration du tenant et périmètre des services annexes |
| GitLab Self-Managed | Hébergeur, administration, runners, sauvegardes et sorties réseau | Inventaire technique et responsabilités d’exploitation |
GitLab Dedicated permet de choisir des régions AWS, y compris pour la reprise et les sauvegardes. La documentation indique que ces choix ne se modifient pas après le provisionnement. Examinez-les avant la création du tenant ; une région principale conforme à votre besoin ne règle pas le sort des copies secondaires.
En Self-Managed, identifiez ce que GitLab reçoit effectivement. Le simple fournisseur d’un logiciel installé localement ne devient pas sous-traitant de tout son contenu par cette seule fourniture ; des services connectés ou une intervention de support peuvent en revanche entraîner des traitements distincts. L’hébergeur et l’infogérant doivent également être qualifiés.
Vérifier le DPA applicable
Le DPA GitLab du 1er mai 2026 prévoit son acceptation avec le Subscription Agreement pour le client qui contracte au nom d’une entreprise. Il distingue notamment les données traitées pour le client et certaines activités relevant d’un rôle indépendant. Sa section 15 prévoit le DPF pour les transferts concernés vers GitLab Inc., et des clauses contractuelles types dans les hypothèses indiquées, notamment lorsqu’il ne s’applique pas ou que le client choisit de ne pas s’y fier.
Conservez la version applicable à votre achat ou renouvellement depuis la page des conditions GitLab. Ne remplacez pas cette vérification par une recherche d’un ancien PDF. Examinez les annexes, les sous-traitants et les modalités d’assistance et d’audit à l’aide du questionnaire fournisseur RGPD.
Pour les transferts hors UE, vérifiez le mécanisme effectivement utilisé et son périmètre. La démarche associée aux clauses contractuelles types ne se confond pas avec celle d’un transfert couvert par une décision d’adéquation applicable.
Duo : examiner chaque fonctionnalité
La documentation de configuration de Duo indique que, par défaut, des modèles de fournisseurs sont utilisés au travers d’une passerelle IA hébergée par GitLab. Des configurations auto-hébergées ou hybrides existent : certaines fonctions peuvent rester locales tandis que d’autres utilisent la passerelle cloud.
Pour chaque fonction activée, relevez le contexte envoyé, la passerelle, le fournisseur de modèle, les journaux et les paramètres de collecte. Vérifiez aussi les connecteurs et outils accessibles à un agent. Un engagement sur l’entraînement des modèles ne prouve ni l’absence de transfert ni l’absence de toute journalisation.
Évitez de joindre des tickets clients complets lorsque quelques éléments techniques suffisent. L’activation d’une fonction d’IA doit correspondre à un usage défini, avec des données autorisées et des utilisateurs informés.
Pipelines : réduire les données avant de masquer les sorties
Un pipeline peut recopier une réponse d’API, une base de test ou un extrait de journal applicatif dans ses propres logs et artefacts. Le DPO et l’équipe technique doivent savoir qui peut lire ces sorties et quand elles disparaissent.
La documentation des variables CI/CD précise que les variables masquées et protégées peuvent être compromises par un script malveillant. La revue du code qui reçoit les secrets reste essentielle. Le masquage réduit certaines fuites accidentelles ; il ne constitue pas une autorisation de lancer n’importe quel pipeline avec des identifiants de production.
Définissez les données de test autorisées, limitez les permissions des runners et évitez les impressions de variables ou de réponses complètes. Contrôlez séparément l’expiration des artefacts et celle des journaux : ce sont des objets différents. La minimisation des données doit être intégrée aux scripts et aux jeux de tests.
Corriger une donnée publiée dans Git
Une suppression dans un nouveau commit laisse les versions antérieures dans l’historique. Avant toute opération technique, identifiez les branches, références, forks, clones, artefacts et miroirs concernés. Si un secret a été exposé, sa révocation ou sa rotation ne doit pas attendre le nettoyage de l’historique.
GitLab documente les limites du nettoyage des dépôts : les clones doivent être traités pour éviter de réintroduire le contenu ; les forks et les références peuvent maintenir des objets accessibles. La méthode dépend de la version et du périmètre. Préparez l’opération avec les responsables du dépôt et vérifiez le résultat, au lieu de promettre un effacement universel par une seule commande.
Une exposition à des personnes non autorisées doit aussi être analysée comme un éventuel incident de données. La notification d’une violation dépend des critères du RGPD ; elle n’est pas automatique pour tout défaut de configuration.
Cas pratique : un artefact conserve ce que le journal masque
Le scénario suivant est entièrement fictif ; il ne décrit pas un essai effectué sur GitLab. L’éditeur Planning Clair prépare une application de réservation. Six salariés développent le produit et une prestataire intervient sur la qualité. L’entreprise utilise une instance Self-Managed chez un hébergeur français, un runner dans cette infrastructure et des postes de développement administrés. Elle veut ouvrir un nouveau projet à cette prestataire sans y copier ses dossiers clients.
L’objectif retenu est de reproduire les erreurs de réservation, pas de retrouver les personnes qui les ont rencontrées. L’équipe reconstruit donc douze réservations fictives : créneau, nombre de places et état de confirmation. Elle n’extrait pas douze lignes de production en remplaçant seulement les noms. Les journaux de connexion et les identifiants des sept intervenants restent, eux, des données personnelles.
La finalité de suivi des modifications et de sécurité est examinée sur l’intérêt légitime : besoin d’attribuer les interventions, accès limité et absence de classement individuel de productivité. L’équipe documente nécessité et mise en balance, puis informe les intervenants. Le choix n’autorise pas une surveillance générale des salariés. Les exigences de finalité, minimisation et base légale viennent des Art. 5(1)(b)(c) et 6(1)(f) du RGPD ; l’information relève de l’Art. 13.
La fiche de projet effectivement remplie
La responsable technique et la référente RGPD arrêtent les décisions suivantes avant l’ouverture. Les durées indiquées sont des choix hypothétiques du projet, à justifier et à adapter ; elles ne constituent pas des délais légaux GitLab.
| Objet | Décision pour Planning Clair | Preuve attendue |
|---|---|---|
| Dépôt et tickets | Code, scénarios reconstruits et descriptions techniques ; aucun export client | Revue du premier dépôt et des pièces jointes |
| Accès | Six salariés et une prestataire nommément autorisés ; projet privé | Liste des membres et contrôle avec un compte non membre |
| Runner | Exécution chez le même hébergeur, sans identifiant permettant de lire la production | Inventaire des accès et environnement de recette |
| Journaux de tâches | Résultat et identifiant du scénario ; pas de réponse complète contenant des coordonnées | Lecture du journal obtenu avec des marqueurs fictifs |
| Artefacts de diagnostic | Rapport réduit aux erreurs techniques, expiration choisie à sept jours | Contenu téléchargé et suppression vérifiée après l’échéance |
| Duo et intégrations | Non activés pour ce projet ; nouvelle analyse avant changement | Configuration relevée et responsable désigné pour toute activation |
| Support | Description du problème et extrait expurgé, transmis par la responsable technique | Vérification de la pièce réellement jointe avant envoi |
| Fin de mission | Retrait des accès de la prestataire, inventaire des copies et sort des moyens d’accès associés | Compte rendu de clôture avec confirmation des opérations |
La conservation de l’historique des contributions fait l’objet d’une décision distincte des sept jours d’artefacts : sa fonction est de comprendre et maintenir le logiciel. Le départ d’une personne n’entraîne donc pas automatiquement l’effacement de chaque attribution de commit. L’entreprise examine le besoin restant, l’information donnée et toute demande de droit, sans assimiler la traçabilité à une conservation illimitée par principe.
Pourquoi la première recette échoue
La responsable lance, dans ce scénario, une recette utilisant uniquement des valeurs fictives reconnaissables. Le journal n’affiche plus le marqueur placé dans le champ courriel : le développeur estime la correction suffisante. Mais le rapport de diagnostic téléchargeable contient encore la réponse complète, y compris ce marqueur. Le script filtre son affichage après avoir écrit le fichier brut. Le rapport reste lisible par la prestataire autorisée au projet.
La responsable refuse l’ouverture aux données de travail et désactive la production de ce rapport. Elle demande une correction à la source : le fichier doit être construit à partir des seuls champs techniques autorisés. Ajouter un masque au journal n’aurait pas corrigé le fichier déjà créé. Les anciens artefacts fictifs sont retirés, puis une nouvelle exécution produit un rapport réduit. La lecture du journal et du fichier téléchargé confirme séparément l’absence des marqueurs exclus.
Le contrôle d’accès complète cette vérification : le compte invité au projet peut consulter ce qui lui est nécessaire, tandis qu’un compte sans autorisation ne peut pas récupérer le rapport. L’équipe examine aussi le retrait de l’accès en fin de mission. L’ouverture est acceptée seulement pour le périmètre décrit dans la fiche, sans connexion à la production ni activation implicite de Duo.
Cette anomalie découverte avec des valeurs fictives n’est pas, par elle-même, une violation de données de clients. Si la même découverte concernait un rapport contenant des données réelles, il faudrait immédiatement établir les données exposées, les personnes ayant pu y accéder, les téléchargements et les copies restantes. L’analyse des Art. 33(1), 33(5) et 34(1) du RGPD se mène alors selon le risque, avec documentation et notifications lorsqu’elles sont requises. La suppression du rapport ne suffit pas à effacer cette question.
Ce qu’il faut retenir
- Qualifiez séparément le déploiement, les services connectés et les acteurs qui accèdent aux données.
- Vérifiez les flux de chaque fonction Duo avant son activation.
- Examinez les journaux et les fichiers produits : filtrer l’un ne nettoie pas l’autre.
- Organisez les copies et l’historique avant de promettre un effacement.
- Conservez une décision de mise en service limitée au projet effectivement vérifié.
FAQ
GitLab auto-hébergé supprime-t-il tous les transferts ?
Non. Il donne la maîtrise du déploiement local, mais Duo, le support, les intégrations et les infrastructures associées peuvent créer d’autres flux. Il faut les inventorier.
Une variable masquée est-elle inaccessible aux développeurs ?
Le masquage ne suffit pas contre un code conçu pour récupérer ou transmettre la valeur. Les accès, les branches protégées et la revue des scripts restent déterminants.
Faut-il supprimer les noms de tous les contributeurs ?
Pas automatiquement. Les identifiants de contribution ont une fonction de traçabilité. Leur base légale, leur visibilité et leur conservation doivent être justifiées ; une demande de droit s’examine selon son objet et les conditions applicables.
Recevez nos analyses pratiques sur la conformité : inscrivez-vous à la newsletter.
Thiébaut Devergranne est docteur en droit et fondateur de donneespersonnelles.fr. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données personnelles.