Le 24 avril 2026, la politique d'entraînement des modèles de GitHub a changé pour les offres Copilot individuelles. GitHub peut désormais utiliser les interactions issues de Copilot Free, Pro, Pro+ et Max, y compris les entrées, les sorties, les extraits de code et le contexte associé, pour entraîner et améliorer des modèles d'IA, sauf refus de l'utilisateur. Les données de Copilot Business et Enterprise restent protégées par l'accord de protection des données de GitHub. Point essentiel : cela concerne les données d'interaction avec Copilot, pas les dépôts privés qui dorment simplement sur GitHub.
En parallèle, les arguments en faveur d'une migration ont refait surface pour une autre raison : les instances Git auto-hébergées publiques absorbaient un trafic automatisé important. Une discussion Hacker News a rassemblé un ensemble utile de retours d'exploitants sur ce problème : Fin d'une époque pour moi : plus de git auto-hébergé.
Reste donc une question plus utile que « GitHub ou auto-hébergement ? » : quel problème cherchez-vous réellement à résoudre ?
La version courte
Trois réponses. Choisissez celle qui correspond à votre situation.
- A: Refuser et rester. À utiliser quand le changement d'entraînement Copilot est votre seule préoccupation et que GitHub convient encore aux besoins opérationnels de votre équipe. Désactivez le réglage au niveau du compte et passez à autre chose.
- B: Adopter un modèle hybride. Gardez l'open source public sur GitHub pour l'effet de réseau. Déplacez le code privé vers une instance auto-hébergée Forgejo, Gitea ou GitLab CE derrière un VPN ou une liste d'IP autorisées. À utiliser quand la portée publique et le contrôle privé comptent en même temps.
- C: Migrer complètement. Déplacez tout hors de GitHub. À utiliser quand la réglementation, la résidence des données, la gouvernance ou une politique 100 % logiciel libre excluent GitHub et que l'équipe peut assumer le coût d'exploitation.
La plupart des lecteurs sont en position A ou B. La position C se justifie par des exigences plus strictes de gouvernance, de souveraineté ou de valeurs, pas par le seul réglage Copilot.
Ce qui a réellement changé en avril 2026
Le changement technique est mineur. Dans les réglages Copilot, les abonnés individuels peuvent passer « Allow GitHub to use my data for AI model training » sur Disabled. GitHub décrit les éléments concernés comme les interactions avec ses fonctionnalités et services, y compris les entrées, les sorties, les extraits de code et le contexte associé, et non le contenu de dépôts privés qui n'a jamais transité par Copilot.
Copilot Business et Enterprise n'affichent pas ce réglage, car leurs données sont protégées par l'accord de protection des données de GitHub. Pour les offres individuelles, désactiver le réglage répond au problème de la politique d'entraînement ; cela ne règle pas une objection plus large au fait de dépendre d'une politique contrôlée par le fournisseur.
Le changement Copilot peut être le déclencheur sans constituer tout le dossier. Une équipe peut aussi se soucier de la dépendance à la plateforme, de l'identité liée à GitHub, des workflows bâtis autour d'Actions, de la résidence des données, ou de la facilité avec laquelle elle pourra déménager de nouveau plus tard. Ce sont des questions de migration ; le réglage d'entraînement n'est qu'un paramètre.
Cette distinction compte : refuser modifie un réglage d'utilisation des données, tandis que migrer change qui contrôle l'hébergement, l'identité, les intégrations et la politique. La seconde décision coûte bien plus cher à l'exploitation.
Les trois positions expliquées
La décision résumée en trois lignes. Détails plus bas.
| Votre préoccupation | Réponse | Action |
|---|---|---|
| Mes données d'interaction Copilot utilisées pour l'entraînement | Refuser et rester (position A) | Basculez le réglage, puis retournez travailler |
| Du code privé que je ne veux pas chez un fournisseur américain + de l'open source actif que je ne veux pas cacher | Hybride (position B) | Auto-hébergez les dépôts privés derrière un VPN ; gardez l'open source public sur GitHub |
| Souveraineté, secteur réglementé, choix de principe 100 % logiciel libre, indépendance totale vis-à-vis du fournisseur | Migration complète (position C) | Déplacez tout ; budgétez le coût d'exploitation |
Position A : refuser et rester
Si vous êtes développeur solo ou une petite équipe avec des dépôts privés et que votre seule critique porte sur le réglage d'entraînement par défaut, c'est votre réponse. Basculer un réglage : une minute, une fois. L'auto-hébergement : une petite facture de VPS, une stratégie de sauvegarde que vous testez vraiment, des intégrations à reconstruire parce qu'elles présupposaient l'authentification GitHub, et la mise à jour ou la restauration occasionnelle qui tombe au pire moment.
L'auto-hébergement peut quand même en valoir la peine, mais seulement si ce travail récurrent vous apporte quelque chose dont vous avez réellement besoin.
L'objection la plus forte : ce réglage est lui aussi une décision du fournisseur. GitHub est passé, en 2026, de ne pas utiliser ces données d'interaction pour l'entraînement par défaut à les utiliser par défaut, et sa politique peut encore changer.
Si votre préoccupation de fond est « je ne veux jamais qu'un fournisseur américain prenne des décisions unilatérales sur mon code », aucune case à cocher ne règle cela, et la position A est la mauvaise réponse pour vous. Passez directement à la position C.
Mais si votre préoccupation est précisément « je ne veux pas que mes données d'interaction Copilot actuelles servent à l'entraînement » et que vous ferez confiance au réglage de GitHub jusqu'au prochain changement, la position A est la réponse correcte la moins chère. Il n'y a aucune honte à être à la fois économique et juste.
Position B : adopter un modèle hybride
L'hébergement hybride sépare la portée publique du contrôle privé.
Le partage est simple. L'open source public reste sur GitHub : effet de réseau, vivier de contributeurs, Dependabot, écosystème Actions, ce sont des atouts réels. Le code privé part sur une instance auto-hébergée derrière un VPN ou une liste d'IP autorisées, jamais joignable depuis l'internet public.
Si cela fonctionne, c'est une propriété du modèle de menace. Le problème d'entraînement Copilot ne concerne que les données d'interaction Copilot que vous envoyez via GitHub. Le problème de trafic des robots d'IA (section suivante) ne concerne que les instances joignables publiquement. Une configuration hybride privée esquive les deux.
Pour une équipe privée de 2 à 10 personnes, 2 vCPU et 4 GB de RAM constituent un point de départ plus sûr pour Forgejo ou Gitea, avec de la marge en plus si l'indexation de recherche, les paquets ou la CI partagent la machine. Considérez ce dimensionnement comme celui de Forgejo/Gitea, pas celui de GitLab CE : le tutoriel GitLab pour une installation mononœud démarre à 8 vCPU et 7,2 GB de mémoire, avant toute charge de CI.
N'exposez pas l'interface web en clair sur 80 ou 443. Restreignez-la au niveau du pare-feu, du proxy, du VPN ou du réseau maillé. Les runners de CI peuvent servir les deux côtés.
Le choix de la plateforme change davantage l'ensemble des fonctionnalités que le modèle hybride lui-même. Forgejo et Gitea conviennent à une forge privée plus légère ; GitLab CE a plus de sens quand vous avez aussi besoin d'une pile CI/CD et de registre intégrée.
Les sauvegardes sont gérables, mais ne les réduisez pas à un git bundle. La documentation officielle de mise à niveau de Forgejo considère comme sauvegarde fiable un instantané synchronisé, à un instant donné, de tout le stockage utilisé par Forgejo, et, quand ce n'est pas praticable, un dump Forgejo associé à un dump séparé PostgreSQL ou MySQL. Pour Forgejo comme pour Gitea, gardez ensemble dépôts, base de données, configuration, pièces jointes et données LFS, stockez une copie hors du serveur, et testez une restauration.
Le clone local d'un développeur peut récupérer le code, mais pas les tickets, les utilisateurs, les métadonnées des pull requests, les pièces jointes ni tous les objets LFS. Si un fork privé devient public plus tard, poussez-le à ce moment-là vers un miroir GitHub.
Position C : migration complète quand le contrôle est une exigence
La migration complète s'impose le plus clairement quand l'indépendance vis-à-vis du fournisseur est une exigence et non une préférence.
Trois groupes se distinguent : les équipes réglementées soumises à des règles d'audit, de résidence ou de contrôle du fournisseur qui excluent GitHub ; les équipes du secteur public ou européennes dont les exigences de souveraineté relèvent de la politique et non de la préférence ; et les organisations 100 % logiciel libre qui veulent quitter une infrastructure détenue par Microsoft et disposent déjà de personnel capable d'exploiter des services Linux.
Le coût, c'est un petit VPS, de la maintenance continue et la perte d'intégrations. La perte d'intégrations est la partie que l'on oublie. Tout ce qui s'authentifie avec « Sign in with GitHub » reste sur GitHub ou exige un fournisseur d'identité distinct.
Planifiez la migration autour des dépendances, pas seulement des dépôts. Les prévisualisations de pull requests, les Actions tierces, les bots, les webhooks, les registres de paquets et les intégrations « Sign in with GitHub » peuvent exiger de nouveaux identifiants, de nouveaux workflows ou des services de remplacement. Les étoiles et les abonnés ne deviennent pas des enregistrements natifs sur la nouvelle forge : les projets publics abandonnent donc aussi une partie de leur signal de découverte existant.
Faites un essai à blanc avant de changer le dépôt distant de référence : migrez un dépôt représentatif, reconstruisez ses intégrations, testez l'historique des tickets et des pull requests, et documentez le chemin de retour arrière. La comparaison des plateformes vient après cet audit des dépendances.
Pour les équipes qui veulent une gouvernance à but non lucratif sans exploiter de serveur, Codeberg mérite considération.
Astuce sur la souveraineté. Si vous choisissez l'auto-hébergement pour des raisons de résidence des données dans l'UE, l'emplacement du datacenter compte. Des sites comme Francfort ou Amsterdam sont le choix ennuyeux mais correct. Le VPS le moins cher en Virginie n'aide pas votre DPA.
Le coût opérationnel d'un hébergement Git public
L'auto-hébergement public expose une forge au même trafic automatisé que n'importe quelle application accessible depuis internet, sauf que les pages de dépôt comportent des chemins coûteux comme les vues blame, les archives et l'historique des commits. Les rapports qui suivent sont des expériences individuelles d'exploitants, pas des mesures de référence.
Dans la discussion sur le Git auto-hébergé évoquée plus haut, un exploitant a signalé 37 212 377 requêtes contre une instance cgit sur 60 jours, dont plus de 99 % classées comme robots.
Dans la même discussion, kstrauser rapporte avoir fait passer une instance Forgejo d'environ 600 000 requêtes par jour à environ 1 000, mais seulement après avoir ajouté une épreuve JavaScript et cookie par-dessus les protections classiques.
D'autres exploitants ont mentionné fail2ban, des blocages GeoIP, des mises au trou noir au niveau des systèmes autonomes, et le retour des dépôts vers des plateformes hébergées. Ces retours montrent des modes de défaillance possibles ; ce ne sont pas des références de trafic universelles.
La raison technique pour laquelle c'est difficile : une simple limitation de débit par IP peut échouer face à un trafic qui tourne sur des proxys résidentiels. Une flotte de scrapers peut répartir ses requêtes sur assez d'adresses IP pour qu'aucune ne paraisse abusive, alors que le serveur est quand même submergé au total.
Les épreuves JavaScript ou cookie peuvent réduire le scraping peu sophistiqué, mais elles peuvent aussi bloquer les utilisateurs sans JavaScript et perturber Git-over-HTTPS si on les applique à tous les chemins. Le cache CDN aide sur les lectures répétées ; il fait beaucoup moins pour les points d'accès uniques ou coûteux comme les archives, les vues blame et les pages par commit.
Ce qu'une épreuve change, c'est l'économie du problème. Anubis se place devant une forge et oblige un client à passer une épreuve, par exemple un petit calcul de preuve de travail, avant que le serveur ne renvoie la page protégée, ce qui renchérit l'exploration à grande échelle. C'est une mitigation, pas une garantie.
Appliquez les épreuves de navigateur de façon sélective. Gardez SSH disponible pour les opérations Git, et testez Git-over-HTTPS avant de protéger ce chemin : une page d'épreuve renvoyée à un client Git devient un clone en échec, pas une vérification utile.
GitHub absorbe cette catégorie de trafic dans le cadre de son service hébergé. Une instance Forgejo ou cgit publique vous laisse la planification de capacité, les contrôles anti-abus, le cache et la mitigation. Ce transfert opérationnel, et non le coût brut du logiciel, est la partie importante de la décision de migration.
C'est pour cela que le modèle hybride est une option de premier rang, pas un repli. Code privé derrière un VPN : les scrapers ne peuvent pas l'atteindre. Open source public sur GitHub : l'infrastructure anti-abus de GitHub encaisse le trafic des robots.
Si vous voulez malgré tout une forge publique auto-hébergée, prévoyez le budget pour les logs, les contrôles de débit, le cache, la mitigation des robots, la supervision, et un chemin testé pour le trafic Git qui ne dépende pas d'épreuves de navigateur. Traitez la défense contre les scrapers comme une part de l'exploitation normale, pas comme un cas limite.
La question de l'effet de réseau pour les mainteneurs open source
Je m'adresse ici à un lecteur bien précis : vous maintenez un projet open source. Vingt contributeurs, deux cents étoiles et un suivi de tickets actif. Vous envisagez de le sortir de GitHub.
Soyez honnête sur ce que vous échangez : la découvrabilité par les contributeurs, la marque de confiance implicite de github.com, Dependabot, CodeQL, et l'écosystème tiers qui s'articule autour de l'authentification GitHub. Rien de tout cela n'est impossible ailleurs ; tout devient une friction.
La règle empirique que je proposerais : si la valeur de votre projet réside surtout dans le code, l'auto-hébergement est plus facile à justifier.
Le code voyage. Si sa valeur dépend fortement des contributeurs, des tickets, de la visibilité dans les moteurs de recherche et de la confiance liée à github.com, alors partir échange une partie de ce qui fait fonctionner le projet contre ce qui fait du bien au mainteneur. Échange légitime si vos raisons sont assez fortes. Mauvais échange si vous le faites pour prouver quelque chose.
La présentation de la plateforme Codeberg décrit un service basé sur Forgejo, exploité par l'association à but non lucratif Codeberg e.V. Pour les mainteneurs open source, cela signifie une gouvernance communautaire sans la charge de maintenance liée à l'exploitation de la forge soi-même.
Pour les équipes proches de l'open source qui veulent une gouvernance communautaire sans corvée de mise à jour, cela représente un saut opérationnel plus petit que d'exploiter une forge publique. SourceHut suppose un changement de workflow bien plus délibéré et mérite une évaluation à part.
Faites le plus petit changement qui résout le problème
Avant de changer de dépôt distant, écrivez l'exigence en une phrase : arrêter l'entraînement sur les données d'interaction Copilot, séparer l'hébergement public et privé, ou retirer GitHub de l'architecture. Si vous n'arrivez pas à nommer l'exigence, ne migrez pas encore.
Pour une migration, commencez par un dépôt représentatif en pilote. Recensez l'authentification, les Actions, les webhooks, la publication de paquets, les environnements de prévisualisation, l'historique des tickets, les données LFS et les étapes de retour arrière avant de changer le dépôt distant de référence.
Le déploiement Forgejo en un clic est un moyen rapide de mettre en place le côté privé d'un modèle hybride ; une installation manuelle sur n'importe quel Linux VPS fonctionne aussi. Quelle que soit la voie choisie, gardez l'interface web privée, sauvegardez l'état complet de l'application, et testez la restauration avant de déplacer un dépôt critique.
Développez sur un VPS Linux avec accès root, NVMe et la puissance AMD EPYC.
Voir les plans LinuxLe contrôle n'est utile que s'il répond à l'exigence, à un coût d'exploitation que votre équipe peut tenir dans la durée.
Foire aux questions
Faut-il quitter GitHub à cause du changement d'entraînement Copilot ?
Pas automatiquement. Si votre seule préoccupation est l'utilisation des données d'interaction Copilot pour l'entraînement de modèles, désactiver le réglage au niveau du compte est le correctif juste le plus petit. La migration se justifie quand vous avez aussi besoin de contrôles plus stricts sur la résidence des données, la gouvernance, l'indépendance vis-à-vis du fournisseur ou une politique 100 % logiciel libre.
GitHub s'entraîne-t-il sur tous mes dépôts privés ?
Non. Le changement de politique dont il est question ici couvre les données d'interaction Copilot éligibles, y compris les entrées, les sorties, les extraits de code et le contexte associé envoyés via Copilot. Cela ne signifie pas que tout dépôt privé stocké sur GitHub sert automatiquement à l'entraînement de modèles.
L'auto-hébergement de Git est-il toujours plus privé ?
Seulement si vous l'exploitez ainsi. Une forge privée derrière un VPN ou une liste d'IP autorisées peut réduire l'exposition, mais une instance joignable publiquement ajoute des responsabilités de correctifs, de supervision, de mitigation des robots, de contrôle d'accès et de sauvegarde que GitHub absorbe normalement.
Quelle plateforme Git auto-hébergée choisir ?
Choisissez Forgejo ou Gitea si vous voulez une forge privée plus légère. Choisissez GitLab CE quand une CI/CD intégrée et un registre de paquets ou de conteneurs comptent assez pour justifier ses besoins plus élevés en ressources et en maintenance.
Quelle taille de VPS faut-il à Forgejo ou Gitea pour une petite équipe ?
Pour une équipe privée de deux à dix personnes, 2 vCPU et 4 GB de RAM constituent un point de départ plus sûr. Ajoutez de la capacité quand l'indexation de recherche, les paquets, de gros dépôts ou des runners de CI partagent la machine. Dimensionnez GitLab CE à part, car il demande plus de ressources.
Que faut-il tester avant de changer le dépôt distant de référence ?
Faites un pilote sur un dépôt représentatif. Vérifiez l'historique des tickets et des pull requests, l'authentification, les Actions ou les workflows de CI de remplacement, les webhooks, la publication de paquets, les données LFS, les environnements de prévisualisation, les sauvegardes, la restauration et le chemin de retour arrière avant de tout déplacer.
