Nouvelle politique de GitHub Copilot sur l'entraînement de l'IA : ce qu'il faut savoir

GitHub a récemment annoncé un changement majeur dans la manière dont les données des utilisateurs de Copilot sont traitées. Depuis le 24 avril 2026, les données d'interaction des utilisateurs de Copilot Free, Pro et Pro+, notamment les données d'entrée et de sortie, les extraits de code et le contexte associé, sont utilisées par défaut pour entraîner des modèles d'IA, sauf si les utilisateurs décident de désactiver manuellement cette option. Cette modification ne concerne pas les clients Copilot Business et Enterprise en vertu des conditions contractuelles existantes.

Pour les organisations des secteurs réglementés, notamment la finance, la santé, la défense et le secteur public, ce changement de politique soulève des questions qui vont au-delà des préférences individuelles des équipes de développement. Ce changement oblige à examiner de plus près une question que les responsables en ingénierie et en sécurité devraient poser à chaque fournisseur d'IA de leur environnement : utilisez-vous notre code pour entraîner vos modèles ?

Chez GitLab, la réponse est non. GitLab n'utilise pas le code de ses clients pour entraîner les modèles d'IA, quel que soit le niveau de service, et les fournisseurs d'IA sont contractuellement tenus de ne pas utiliser les données d'entrée ou de sortie des clients à leurs propres fins. Le Centre pour la transparence de l'IA de GitLab rend cet engagement vérifiable : il centralise la documentation sur les modèles qui alimentent chaque fonctionnalité, le traitement des données, les relations avec les sous-traitants et les durées de conservation. Le Centre pour la transparence de l'IA de GitLab indique également le statut de conformité de chaque fonctionnalité, notamment la confirmation que les fonctionnalités d'IA actuelles de GitLab ne sont pas considérées comme des systèmes à haut risque au sens du règlement européen sur l'IA. Il s'agit d'un standard que le CEO de GitLab, Bill Staples, réaffirme régulièrement et qui se reflète dans la mission de GitLab ainsi que dans son Trust Center.

Ce que ce changement de politique implique concrètement

L'annonce de GitHub précise également que les données pourront être partagées avec les sociétés affiliées de GitHub, dont Microsoft, à des fins de développement de l'IA.

Un changement de politique de cette nature contraint les organisations à réévaluer leur posture en matière de gouvernance de l'IA, à auditer leurs niveaux de licence Copilot et à s'assurer que les contrôles appropriés sont configurés au sein de leurs équipes.

Pourquoi la gouvernance de l'IA est essentielle dans les environnements réglementés

Le code source fait souvent partie des actifs les plus sensibles de la propriété intellectuelle d'une organisation. Il peut contenir des références à des systèmes internes, refléter une logique métier propriétaire ou concerner des flux de données soumis à des politiques strictes de conservation et d'accès. Lorsque ce code transite par un assistant d'IA, les questions relatives à l'utilisation des données d'entraînement, aux relations avec les fournisseurs de modèles et à la résidence des données deviennent des enjeux de conformité.

L'exposition est particulièrement critique pour les établissements de services financiers qui ont investi dans des algorithmes propriétaires, des logiques de détection des fraudes, des modèles de risque de crédit, des règles de souscription et des stratégies de trading. Lorsque les outils d'IA traitent ce code et l'utilisent pour entraîner des modèles au service de concurrents, les pratiques des fournisseurs en matière de données deviennent un enjeu de propriété intellectuelle.

Les institutions financières qui opèrent dans le cadre des directives de supervision de la Réserve fédérale américaine sur la gestion des risques liés aux modèles (SR 11-7) et du règlement européen sur la résilience opérationnelle numérique (DORA) sont tenues de maintenir une supervision documentée et vérifiable des fournisseurs de technologies tiers, notamment en comprenant la façon dont ces fournisseurs traitent les données. Les outils d'IA tiers utilisés dans les workflows de développement entrent de plus en plus dans le périmètre de la supervision des risques liés aux modèles, et les modifications substantielles des pratiques des fournisseurs en matière de données nécessitent une mise à jour de la documentation.

Dans le secteur public, la publication spéciale 800-53 du National Institute of Standards and Technology (NIST 800-53) et la loi américaine Federal Information Security Modernization Act (FISMA) établissent que le code sensible ou classifié ne doit jamais quitter un périmètre contrôlé. Pour les environnements du Département de la Défense américain et des services de renseignement en particulier, la posture par défaut d'un fournisseur en matière de données constitue un enjeu opérationnel. Dans le secteur de la santé, la loi américaine Health Insurance Portability and Accountability Act (HIPAA) régit la façon dont les données liées aux patients sont traitées par des tiers, et les environnements de développement en contact avec des systèmes cliniques entrent de plus en plus dans ce périmètre.

Dans tous ces contextes, le fil conducteur est identique : une politique fournisseur qui modifie les paramètres par défaut d'utilisation des données, exige une désinscription individuelle et offre des protections différentes selon le niveau de compte introduit précisément le type de variable non contrôlée que les équipes de conformité ne peuvent pas se permettre.

Ce dont les secteurs réglementés ont réellement besoin de la part des fournisseurs d'IA

Les organisations réglementées ont largement dépassé le stade du débat sur l'opportunité d'adopter l'IA dans leurs workflows de développement. L'enjeu est désormais de le faire d'une manière qu'elles peuvent défendre auprès des régulateurs, des conseils d'administration et de leurs clients. Cette évolution a fait émerger un ensemble cohérent d'exigences, quel que soit le secteur.

Certitude contractuelle. Les entreprises réglementées ont besoin de savoir avec précision ce qu'il advient de leurs données. Un engagement clair, documenté et inconditionnel est indispensable, et non un accord qui varie selon le plan tarifaire ou qui nécessite une action avant une échéance.

Auditabilité. Les frameworks de gestion des risques liés aux modèles exigent des organisations qu'elles comprennent et valident les systèmes d'IA qu'elles déploient, notamment les données d'entraînement qui sous-tendent ces modèles et les tiers impliqués dans leur développement. Les fournisseurs qui ne peuvent pas répondre à ces questions créent un risque documentaire pour les organisations qui s'appuient sur eux.

Séparation des intérêts du fournisseur. Lorsqu'un fournisseur d'IA entraîne ses modèles sur les données d'utilisation de ses clients, le code et les workflows deviennent des données d'entrée d'un système qui sert également des concurrents. Pour les institutions disposant d'une logique de trading propriétaire, de modèles de souscription ou de systèmes de détection des fraudes, il s'agit d'une véritable exposition en matière de propriété intellectuelle.

La position de GitLab sur la gouvernance des données d'IA

GitLab n'utilise pas le code de ses clients pour entraîner des modèles d'IA. Cet engagement s'applique à tous les niveaux de service, et les fournisseurs d'IA sont contractuellement tenus de ne pas utiliser les données d'entrée ou de sortie associées aux clients de GitLab à leurs propres fins.

Il s'agit d'un choix architectural et d'une politique délibérée, et non d'une fonctionnalité propre à un niveau tarifaire particulier. Comme le souligne l'article de blog de GitLab sur l'indépendance des entreprises, la gouvernance des données est devenue « un facteur de plus en plus critique dans les décisions technologiques des entreprises, en raison d'un ensemble complexe de lois nationales et régionales sur la protection des données et d'une préoccupation croissante concernant le contrôle des données sensibles ».

Par ailleurs, GitLab ne dépend ni d'un cloud ni d'un modèle, et prend en charge les déploiements auto-hébergés, sans être lié commercialement à un seul fournisseur de cloud ou à un grand modèle de langage (LLM). Cette indépendance est déterminante pour les organisations réglementées qui évaluent le risque de concentration des fournisseurs. Le plan de continuité IA documente la façon dont les changements de fournisseurs sont gérés, notamment les modifications substantielles de la façon dont les fournisseurs d'IA traitent les données clients, en réponse directe aux exigences de gouvernance des frameworks tels que DORA.

Le manque de gouvernance que les équipes d'IA doivent combler

La mise à jour de la politique de GitHub rappelle que, pour les organisations des secteurs réglementés, comprendre précisément la façon dont un outil d'IA traite les données est un prérequis à son utilisation. Cela implique de demander aux fournisseurs des réponses claires et documentées : les données sont-elles utilisées pour l'entraînement des modèles ? Qui sont les sous-traitants pour les modèles d'IA ? Que se passe-t-il si un fournisseur modifie ses pratiques en matière de données ? Est-il possible de déployer de façon à ce que l'ensemble du traitement d'IA reste au sein de sa propre infrastructure ? Quelle indemnisation est proposée pour les données de sortie générées par l'IA ?

Les fournisseurs capables de répondre clairement à ces questions et de les documenter de façon vérifiable sont ceux sur lesquels il est possible de s'appuyer. Les fournisseurs qui ne peuvent y répondre accumuleront une dette de conformité à chaque mise à jour de leur politique. Un fournisseur qui peut modifier ses pratiques en matière de données avec un préavis de 30 jours n'est pas un partenariat conçu pour les secteurs réglementés.

Pour en savoir plus sur l'approche de GitLab en matière de gouvernance de l'IA, consultez le Centre pour la transparence de l'IA de GitLab.