Quitter GitHub pour migrer vers Forgejo
(jorijn.com)- Le déclencheur direct du départ de GitHub n’est pas la panne d’avril 2026, mais la question de la propriété du code et des workflows exécutés sur GitHub
- Depuis août 2025, GitHub n’a plus son propre CEO et a été intégré à la division CoreAI de Microsoft ; le code se retrouve donc sous l’organisation IA de Microsoft
- À partir d’avril 2026, Copilot Free, Pro et Pro+ passent à un modèle d’opt-out où les données d’interaction sont utilisées par défaut comme données d’entraînement
- GitHub et Microsoft étant des entreprises américaines, ils relèvent de FISA 702 et du CLOUD Act ; la seule résidence des données dans l’UE ne règle donc pas le problème
- Forgejo v15 LTS tourne sur un unique NUC de code.jorijn.com, avec des runners isolés via KVM, gVisor, des rebuilds hebdomadaires et un filtre d’egress
Pourquoi quitter GitHub : non pas à cause des pannes, mais à cause de la propriété
- La panne d’avril 2026 a été suffisamment grave pour les développeurs, mais la raison centrale de quitter GitHub n’est pas la panne en elle-même ; c’est la propriété du code et des workflows exécutés sur GitHub
- Le 27 avril 2026, le ministère néerlandais de l’Intérieur a lancé en soft launch code.overheid.nl, sa propre instance Forgejo auto-hébergée pour le code source gouvernemental
- Le chef de projet Boris Van Hoytema a expliqué que la plateforme partait de l’exigence selon laquelle les ministères doivent légalement publier leur code source dans un « lieu qu’ils possèdent »
- Forgejo a été préféré à GitLab parce qu’il est entièrement open source et qu’il offre la liberté nécessaire à la souveraineté numérique
- L’hébergement Git par défaut pour le code personnel a également été déplacé vers code.jorijn.com, où Forgejo v15 LTS tourne dans une configuration renforcée sur un unique NUC
- Une partie des dépôts a déjà été migrée et le reste est en attente
- Une fois la migration terminée, les dépôts publics GitHub seront archivés, avec dans chaque archive un pointeur vers le nouvel emplacement
Pannes et charge liée à l’IA
- Le 23 avril 2026, le chemin de code squash-merge de merge queue a silencieusement annulé des commits déjà fusionnés dans 658 dépôts et 2 092 pull requests, après un déploiement incomplet d’un feature flag
- Des entreprises comme Modal et Zipline ont dû restaurer les données manuellement
- Quatre jours plus tard, un cluster Elasticsearch surchargé a interrompu Pull Requests, Issues et Packages pendant plus de 6 heures
- Rien qu’en février 2026, 37 incidents ont été enregistrés, dont une panne de 3 h 40 ayant fait tomber simultanément Actions, Copilot Coding Agent, Code Review, CodeQL, Dependabot et Pages
- Le 1er octobre 2025, une panne de 10 heures des runners macOS s’est produite
- Selon le décompte d’IncidentHub, entre mai 2025 et avril 2026, GitHub a connu 257 incidents et 48 pannes majeures, pour environ 112 heures d’indisponibilité au total
- Dans ses excuses du 28 avril, le CTO de GitHub Vlad Fedorov a indiqué qu’il fallait multiplier la capacité par 30 pour suivre la charge provoquée par la « agentic AI workflow growth » depuis décembre 2025
- Les problèmes de fiabilité sont ainsi interprétés comme une conséquence secondaire de l’expansion des fonctions IA
- GitHub pousse encore plus fortement les fonctionnalités IA au lieu de les ralentir
- The Pragmatic Engineer souligne que GitLab, Bitbucket, Vercel, Linear et Sentry n’ont pas connu la même année
- Eux aussi subissent la pression de la demande des développeurs ; le profil des pannes de GitHub semble donc spécifique à GitHub
Réorganisation de GitHub
- Le 11 août 2025, Thomas Dohmke a quitté son poste de CEO de GitHub, et Microsoft n’a pas nommé de successeur
- GitHub a été absorbé dans la division CoreAI de Microsoft
- CoreAI est l’organisation présentée par Satya Nadella en janvier 2025, avec pour objectif de construire une stack Copilot et IA end-to-end pour les clients 1st-party et 3rd-party
- Les revenus, l’ingénierie et le support de GitHub reportent à la developer division de Microsoft sous Julia Liuson
- Le CPO de GitHub reporte au VP Microsoft AI platform
- La marque demeure, mais le leadership indépendant a disparu
- De 2018 à 2024, l’idée que Microsoft gérait GitHub avec une certaine distance était globalement juste en pratique, mais depuis août 2025, cette hypothèse devient difficile à maintenir
- Pousser du code sur github.com signifie désormais pousser du code vers une entité placée sous l’organisation IA de Microsoft
Changement du paramètre par défaut des données d’entraînement de Copilot
- Le 25 mars 2026, GitHub a annoncé une modification de sa politique de confidentialité applicable à partir du 24 avril
- Les données d’interaction des utilisateurs de Copilot Free, Pro et Pro+, notamment les entrées, sorties, extraits de code et le contexte associé, sont utilisées pour l’entraînement et l’amélioration des modèles d’IA sauf refus explicite de l’utilisateur
- Le changement clé est qu’il s’agit d’un modèle opt-out et non opt-in
- Les utilisateurs de Copilot Free, Pro et Pro+ contribuent à l’entraînement des modèles s’ils ne désactivent pas l’option dans la page des paramètres Copilot
- Il n’existe aucun blocage au niveau du dépôt
- Les administrateurs ne peuvent pas indiquer à GitHub de ne pas entraîner ses modèles sur les interactions issues d’un dépôt donné
- L’opt-out est un réglage par compte utilisateur ; chaque contributeur doit donc choisir lui-même
- En pratique, si un utilisateur de Copilot Free/Pro/Pro+ manipule un dépôt, la base de code peut devenir un matériau d’entraînement, quelle que soit sa licence
- L’exception pour les dépôts privés s’applique aussi de manière étroite
- GitHub affirme ne pas utiliser pour l’entraînement le contenu des dépôts privés « at rest »
- Mais il collecte les « code snippets and interaction context » générés lors de l’usage de Copilot dans ces dépôts privés
- La frontière entre le « code au repos » et les « fragments générés pendant l’édition » reste floue
- Les clients Copilot Business et Copilot Enterprise sont exclus, car ils relèvent de Data Protection Agreements distincts
- Le système revient à dire que si l’on paie suffisamment, les interactions ne deviennent pas des données d’entraînement ; sinon, elles le deviennent
- L’intérêt stratégique de GitHub pour les données d’interaction des utilisateurs n’est désormais plus un élément optionnel, mais un élément structurel
Le risque de juridiction ne se résout pas par l’emplacement des données
- GitHub Inc. et Microsoft Corp. sont des entreprises américaines, et les données qu’elles détiennent relèvent du droit américain, notamment de la section 702 du FISA et du CLOUD Act de 2018
- Ces deux lois peuvent s’appliquer quel que soit l’endroit où les données sont physiquement stockées
- La section 702 a été reconduite pour deux ans en avril 2024, et reste en vigueur via une prolongation de 45 jours signée fin avril 2026
- Elle autorise la collecte par les services de renseignement américains visant des personnes non américaines via des fournisseurs de services de communications électroniques situés aux États-Unis
- Le CLOUD Act peut contraindre les entreprises basées aux États-Unis à remettre des données stockées n’importe où dans le monde
- GitHub a annoncé en octobre 2024 la disponibilité générale de la résidence des données dans l’UE pour Enterprise Cloud
- Cela traite la question de l’emplacement des données, mais ne résout pas le problème de juridiction
- L’exposition au CLOUD Act suit la structure de contrôle de l’entreprise, et non sa localisation géographique
- En juin 2025, lors d’une audition au Sénat français, un avocat de Microsoft a déclaré sous serment qu’il ne pouvait pas garantir que les données françaises stockées dans des datacenters Microsoft en Europe étaient à l’abri d’un accès discret du gouvernement américain
- Tant que le code se trouve sur github.com, il reste dans le champ juridique américain
- La résidence des données dans l’UE peut être rassurante, mais ce n’est pas une solution
Le choix du gouvernement néerlandais avec code.overheid.nl
- Le contexte juridique du choix du gouvernement néerlandais est la politique « Open, tenzij », en vigueur depuis 2020
- Les logiciels développés avec des fonds publics deviennent open source par défaut, sauf si des impératifs de sécurité ou de confidentialité s’y opposent
- Pour s’y conformer, les ministères avaient besoin d’un lieu où publier leur code qu’ils contrôlent réellement
- La Commission européenne exploite depuis septembre 2022 code.europa.eu, basé sur un GitLab auto-hébergé
- L’openCode allemand repose lui aussi sur GitLab
- Le code.gouv.fr français n’est pas une forge autonome, mais un agrégateur qui indexe des dépôts hébergés ailleurs
- Le gouvernement néerlandais a délibérément choisi Forgejo plutôt que GitLab
- Selon l’OSOR, la raison tient au fait que Forgejo est entièrement open source, sans séparation open-core, et offre toutes les libertés nécessaires à l’autonomie numérique
- Van Hoytema ajoute que la feuille de route de Forgejo était « way more aligned » que celle des alternatives
- Le gouvernement néerlandais ne voulait pas simplement une forge souveraine, mais une forge souveraine qui ne se retrouve pas verrouillée derrière les paliers premium d’un éditeur commercial
- Les administrations voient elles aussi la même configuration de problèmes et arrivent à la même décision, ce qui rend le choix de Forgejo difficile à considérer comme marginal
Pourquoi avoir choisi Forgejo
- GitLab a aussi été sérieusement envisagé
- GitLab CE auto-hébergé est une option bien connue, avec un écosystème commercial plus vaste et une interface plus aboutie
-
Licence
- GitLab suit un modèle open core
- Community Edition est sous licence MIT, mais de nombreuses fonctionnalités souhaitées en production se trouvent dans l’édition Enterprise sous licence non libre
- Forgejo suit la logique inverse
- Depuis la v9.0 d’août 2024, le projet a été relicencié, passant de MIT à GPLv3+
- L’objectif explicite est de préserver le copyleft et d’empêcher toute captation commerciale future de la base de code
- Si Forgejo a été forké de Gitea en décembre 2022, c’est aussi parce que Gitea Ltd contrôlait la marque et le domaine sans l’accord de la communauté
- Cette leçon se reflète dans le choix de licence
- GitLab suit un modèle open core
-
Gouvernance
- Forgejo relève de Codeberg e.V.
- Codeberg e.V. est une association à but non lucratif enregistrée à Berlin depuis septembre 2018
- Elle dispose d’un conseil élu par ses membres, d’un budget public et de plus de 300 000 dépôts sur son instance d’hébergement
- Les membres votent chaque année sur le budget
- Le plan 2025 a été approuvé par 88 voix pour, 0 contre et 1 abstention
- Forgejo relève de Codeberg e.V.
-
Releases et maturité
- Forgejo v15.0 LTS est sorti le 16 avril 2026
- C’est la 100e release du projet
- Le support long terme court jusqu’au 15 juillet 2027
- Forgejo Actions a atteint le niveau nécessaire avec la v15
- Avec notamment les ephemeral runners, OpenID Connect et l’extension des reusable workflows
- Depuis le fork, les releases sont régulières et les rapports mensuels soutenus
- Forgejo v15.0 LTS est sorti le 16 avril 2026
-
Les limites de l’écosystème commercial
- L’écosystème commercial de Forgejo existe, mais reste mince
- Le produit commercial le plus propre à ce jour est Codey by VSHN
- Il s’agit d’un Forgejo managé et hébergé en Suisse, lancé chez Servala en mars 2025
- Les tarifs commencent à 19 CHF par mois
- Il n’existe pas d’abonnement de support enterprise façon Red Hat
- Si vous avez besoin d’un support téléphonique 24/7 et d’un éditeur clairement responsable, il faut le construire vous-même ou attendre
La configuration de code.jorijn.com
- code.jorijn.com tourne sur un seul Intel NUC dans un bureau à domicile
- Il dispose de 64 Go de RAM
- Forgejo v15 LTS, Postgres 17 et Traefik tournent dans Docker
- Une machine virtuelle KVM gérée par Incus exécute à côté les runners Forgejo Actions
- Plus encore que le déploiement de Forgejo, de Postgres et du reverse proxy, la décision la plus importante concerne la configuration des runners
Les runners sont la partie la plus risquée
- Sur une forge auto-hébergée, la forge elle-même est la partie facile ; la difficulté réside dans l’environnement qui exécute les tâches CI
- Les runners doivent exécuter chaque jour
npm install,composer install,pip installselon le planning de Renovate- La cible est un lockfile généré dans le dépôt lui-même
- Cela implique l’exécution de lifecycle scripts
- Chaque tâche peut potentiellement exécuter du code non fiable
- Il existe un risque du même type que les récents vers npm et l’attaque de la supply chain sur axios, qui se propagent via des bots de dépendances effectuant une fusion automatique en moins d’une heure
- Le rôle du runner n’est pas d’exécuter du code, mais d’isoler le code en cours d’exécution
- L’idée est de partir du principe qu’une couche de défense unique peut échouer, et de concevoir la suivante pour absorber cet échec
Couches de défense du runner
-
Machine virtuelle KVM persistante
- le runner se trouve dans une VM KVM dédiée, et non dans un conteneur de l’hôte
- l’environnement de travail ne partage pas le noyau de l’hôte
- pour qu’une CVE du noyau Linux à l’intérieur du runner atteigne le NUC, il faut d’abord franchir la frontière KVM
-
Utilisation de gVisor comme runtime Docker par défaut dans la VM
- les conteneurs de tâches s’exécutent sous
runsc runscn’envoie pas directement les appels système au noyau de l’hôte, il les intercepte en espace utilisateur- une évasion de conteneur doit compromettre à la fois gVisor et le KVM autour
- les conteneurs de tâches s’exécutent sous
-
Reconstruction destructrice hebdomadaire
- chaque lundi à 02:00 UTC, la VM entière est supprimée puis recréée à partir d’une nouvelle image de base Ubuntu
- un nouvel enregistrement de runner persistant vers Forgejo est également réémis
- l’image de base est reconstruite le dimanche, de sorte que la nouvelle VM intègre les correctifs apt et noyau de la semaine
- aucun état persistant ne peut survivre plus de 7 jours
-
Filtre de sortie nftables sur le bridge du runner
- le runner peut accéder aux destinations publiques en
:443,:80,:22,:53- cela inclut npm, pypi, ghcr, ainsi que son propre Forgejo accessible via un nom d’hôte public à travers le hairpin NAT
- il ne peut pas accéder à
192.168.0.0/16,10.0.0.0/8,172.16.0.0/12 - une tâche compromise ne peut ni scanner le LAN, ni accéder à l’interface d’administration du routeur, ni aux autres services de l’hôte
- le runner peut accéder aux destinations publiques en
-
Token de runner à portée limitée
- les deux enregistrements de runner persistants sont chacun liés à une portée utilisateur unique et à une portée organisation unique
- l’administration utilise le scope PAT
write:user,write:organization - un token divulgué ne peut pas enregistrer de runner hors de sa portée, ni effectuer des opérations de scope admin
- les couches sont volontairement conçues pour se chevaucher
- chaque couche est une clôture, et leur combinaison crée une frontière en profondeur
- l’isolation KVM, gVisor, la reconstruction hebdomadaire et l’enregistrement de runner lié à une portée sont tous pris en charge nativement par Forgejo et Incus
Ce à quoi j’ai renoncé
-
Découvrabilité et graphe social
- GitHub est l’endroit où les contributeurs cherchent des dépôts
- quelqu’un qui veut envoyer une petite correction à un dépôt public s’attend à travailler sur github.com, pas sur un domaine inconnu
- une fois la migration terminée, le plan est d’archiver chaque dépôt public GitHub et de faire pointer le README vers code.jorijn.com
- le chemin de découverte est préservé
- les gens trouvent toujours le dépôt sur GitHub, voient l’avis d’archivage, puis se déplacent vers le foyer canonique
- ce n’est pas encore terminé, et seuls certains dépôts sont sur code.jorijn.com, les autres sont encore en attente
-
Compatibilité fragile avec l’écosystème GitHub Actions
- Forgejo Actions vise la familiarité, pas la compatibilité
- la plupart des choses fonctionnent, mais certaines non
- les blocs
permissions:au niveau du workflow sont silencieusement ignorés actions/checkout@v6casse les checkouts authentifiés sur les runners non GitHub au début de 2026, d’où un verrouillage sur v5actions/upload-artifact@v4nécessite un fork hébergé par Forgejo- OIDC fonctionne, mais utilise une clé de workflow différente,
enable-openid-connect: true, au lieu depermissions: id-token: writede GitHub - si vos workflows dépendent fortement de fonctionnalités propres à GitHub, la migration n’est pas une affaire d’une soirée, c’est un projet
-
Absence de Dependabot
- Forgejo n’a pas Dependabot
- Renovate s’exécute toutes les 3 heures sur le même runner auto-hébergé
- il remplit le même rôle, mais avec davantage de configuration, et la mise en place a pris une journée
-
Support éditeur 24/7
- GitHub Enterprise fournit un numéro de téléphone et un SLA
- Forgejo fournit un issue tracker et un salon de discussion
- c’est suffisant pour une exploitation par une seule personne, mais peut ne pas l’être pour une organisation de 200 ingénieurs
Cas où cela ne vaut pas la peine de migrer
- si l’équipe n’a absolument ni la volonté ni la capacité d’exploiter de l’infrastructure, mieux vaut ne pas migrer vers un Forgejo auto-hébergé
- Codey, qui est un Forgejo managé, ou Codeberg pour le FOSS, réduisent en grande partie l’écart, mais le coût de migration demeure
- si vous avez investi en profondeur dans des fonctionnalités propres à GitHub comme le marketplace GitHub Apps, Codespaces, Copilot Workspace ou Advanced Security, ce n’est pas un bon choix
- Forgejo est une forge, pas une developer-platform-as-a-service
- si votre base de contributeurs dépend du graphe social de GitHub, la découvrabilité peut compter davantage que la propriété
- vous pouvez rester là où sont les contributeurs, ou accepter la friction et, une fois la migration terminée, archiver les dépôts publics GitHub pour pointer vers le nouvel emplacement, puis réévaluer plus tard
- si vous n’avez pas de réponse opérationnelle crédible pour les runners, il est difficile de migrer
- c’est la partie à traiter avec le plus grand sérieux
- si vous n’êtes pas prêt à réfléchir à l’isolation KVM, à gVisor, à nftables et aux reconstructions hebdomadaires, mieux vaut exécuter les tâches CI sur un hôte de runners managé ou rester sur GitHub
- même le gouvernement néerlandais n’a pas tout migré d’un coup
- code.overheid.nl est une plateforme lancée en douceur pour permettre aux ministères de partager du code open source, pas un remplacement total de tout ce qu’ils utilisent
- la configuration de code.jorijn.com suit la même logique
- Forgejo est l’hôte canonique et GitHub est le miroir ; le miroir pourra être réévalué plus tard
1 commentaires
Commentaires sur Hacker News
On dirait qu’en quittant tous GitHub, tout le monde oublie l’esprit d’origine de git
git a été conçu dès le départ pour être décentralisé, et le problème, c’est que GitHub était plus propre, passait mieux à l’échelle et était mieux géré, si bien que tout l’écosystème d’outils autour de git s’est centralisé sur GitHub
Cela dit, j’aimerais quand même qu’il reste un miroir synchronisé automatiquement sur GitHub. Depuis des années, je vois des projets partir vers de l’auto-hébergement ou des hébergements de niche, puis leur miroir GitHub mourir ou être supprimé, et le projet finit par disparaître avec le temps
git est décentralisé, et GitHub n’est qu’un des endroits où l’on peut héberger du code ; on peut pousser vers plusieurs serveurs distants
Donc je n’y committerai plus jamais de code personnel
Je ne m’intéresse pas non plus aux fonctionnalités sociales comme la découvrabilité, les étoiles ou les issues déversées par des bots IA. Mon état actuel me suffit
Et il faut aussi se rappeler que « Open Source is not about You »
L’aspect le plus important de la plateforme que tout le monde oublie, c’est sa composante sociale, ainsi que le fait qu’elle a créé un dépôt externe persistant et rendu la collaboration entre dépôts extrêmement simple
Le projet utilise des protocoles et standards ouverts pour connecter entre elles des forges auto-hébergées
Très peu de gens l’ont utilisé selon le modèle originel de patchs par e-mail, et la plupart des autres n’ont probablement aucune intention de l’apprendre
En pratique, les gens utilisent git parce que GitHub l’utilise, ou, pour être plus généreux, parce qu’il fonctionne bien lorsqu’il est couplé à un hébergeur centralisé comme GitHub
Ce qui les attire, c’est le modèle où l’on développe le code en local et où l’on discute des issues et des patchs sur un portail web ; la part réellement apportée par git lui-même est faible
Issues, releases, CI, documentation, avis de sécurité, recherche et découvrabilité ont tous tendance, avec le temps, à se retrouver liés à GitHub
Pour un projet open source, je pense qu’il vaut mieux garder l’auto-hébergement comme source de vérité, tout en conservant un miroir GitHub en lecture seule pour que les gens puissent réellement le trouver
Le vrai changement de donne, ce sera un support fédéré complet
C’est pour ça que je fais des dons à Forgejo et Codeberg, et j’encourage tout le monde à leur apporter plus de temps et de ressources pour que l’équipe Forgejo puisse l’implémenter correctement
Un autre bon candidat, c’est Radicle, qui est entièrement décentralisé au-dessus de Git
https://codeberg.org/forgejo-contrib/federation/src/branch/m...
https://liberapay.com/forgejo
https://donate.codeberg.org/
https://radicle.dev/
https://radicle.network/nodes/seed.radicle.dev
J’ai aussi déplacé mon dépôt git sur un NUC auto-hébergé
Je n’ai pas encore mis de frontend HTTP accessible au monde, parce que je n’ai aucune envie de fournir du contenu aux scrapers IA ni de passer mon temps à les bloquer
C’est honteux que des entreprises qui ont profité de l’open source aient autant pollué le secteur
Ça tourne depuis trois ans. Si on le verrouille pour qu’il ne soit accessible que sur le LAN et qu’on ne l’expose pas à Internet, l’expérience est robuste et durable
Les dépôts se mirorent correctement pendant quelques semaines puis s’arrêtent. J’ai mis un token PAT sans expiration, mais il affirme quand même qu’il a expiré, alors que testé ailleurs le token fonctionne très bien
Parfois il n’y a rien dans les logs, et d’autres fois la base de données est verrouillée. Forgejo est le seul à utiliser cette base
Jusqu’ici, je n’ai pas réussi à déterminer si le problème vient de Forgejo, des verrous de base causés par les E/S catastrophiques de la carte SD du Pi, ou simplement du fait que Forgejo n’est pas fiable dans le rôle de miroir
Les hyperscalers propriétaires obtiennent du travail gratuit, puis s’en servent pour construire le monde que nous détestons : filets de surveillance, téléphones sur lesquels on ne peut rien installer librement, attestation des appareils, monoculture de navigateurs sans bloqueurs de pub
Google a fait aimer les licences BSD/MIT aux gens, et il suffit de voir le résultat
Une de leurs tactiques classiques, c’est « maintenant c’est à nous ». Quand un fournisseur crée quelque chose comme Elasticsearch ou Redis, les hyperscalers le récupèrent comme produit propriétaire, empochent tous les bénéfices, et l’auteur initial comme son entreprise se retrouvent à crever de faim
Une autre, c’est « adopter, étendre, éliminer ». Ils prennent des projets open source comme KHTML ou Linux, créent leur propre version, l’inondent sur le marché pour évincer la concurrence, placent leur produit sous les yeux de tout le monde par des moyens anticoncurrentiels, puis une fois la part de marché acquise, ils y ajoutent du pistage et retirent des libertés
L’open source devrait être remplacé par « liberté pour les personnes, paiement pour les entreprises ». Il nous faut du shareware à code source disponible avec de vraies dents face aux hyperscalers
Même les licences de Richard Stallman ne sont pas assez fortes, et je pense que le CC BY-NC-SA est meilleur
L’open source « pur » a été une aide sociale pour les entreprises, et une erreur. On a donné aux géants la corde avec laquelle ils nous pendent
J’aimerais que l’IA lise mon code aussi activement que possible
Dans la section « What I gave up », l’auteur parlait de son graphe social ; avec GitSocial, on peut emporter son graphe social et son historique de collaboration
Cela permet aussi des pull requests inter-forges entre n’importe quels hébergeurs git, le tout sans dépendance à un tiers
C’est pour cela que ces alternatives ont tant de mal à décoller
Quand je lis « le CTO a présenté des excuses publiques et a dit qu’il faudrait multiplier la capacité par 30 pour absorber la charge liée à l’IA », j’espère que GitHub ne commencera pas à faire payer l’usage ordinaire
Mais quand je vois certains vibe coders produire des milliers de commits par jour, je deviens de plus en plus sceptique
Ce serait vraiment dommage de ne plus pouvoir partager du code gratuitement et collaborer
Une personne expérimentée repère en quelques secondes qu’un dépôt souffre de ce genre de problème, donc un système ajusté devrait être possible
La partie délicate, c’est de rédiger des conditions juridiques permettant d’imposer des quotas de vibe
Anthropic le fait déjà sur Claude Code, et GitHub comme GitLab font probablement quelque chose de similaire. Le prix à payer sera la haine des développeurs Twitter et d’une petite partie de Reddit, mais ça semble largement supportable
En parallèle, je suis souvent assez stupéfait de voir sur /r/vibecoding des gens payer 200 dollars par mois d’abonnement pour fabriquer des projets hobby ou des sites jouets
J’ai déjà fait des dépenses idiotes quand je pouvais me les permettre, mais là ça me paraît différent
Peut-être qu’ils paient du sens et un but à raison de 2 400 dollars par an. Si vers la quarantaine on comprend qu’on ne sera ni riche ni célèbre, c’est peut-être un prix supportable comparé aux autres alternatives
J’ai aussi entendu parler de Tangled, un service décentralisé construit sur AT Protocol, un peu comme Bluesky
Il a même des fonctionnalités réellement utiles, comme les pull requests empilées, au point que GitHub a tant traîné pour les implémenter que des entreprises se sont créées pour les ajouter à GitHub
Je me demande si quelqu’un l’a essayé
https://tangled.org/
https://tangled.org/h14h.com/knot
Globalement, la plateforme semble assez prometteuse. La manière dont AtProto sépare le serveur de données personnelles, les relais et l’AppView me paraît être un bon compromis
On peut héberger un dépôt git comme serveur de données headless uniquement, donc pour de l’auto-hébergement c’est presque sans douleur
Comparé à une solution ActivityPub comme Forgejo, cela me convient bien, car ce qui m’importe c’est le contrôle des données, tout en évitant l’ennui d’héberger et de faire monter en charge toute une web app
Depuis la configuration initiale, la seule maintenance a consisté à mettre à jour la version de knot-server puis à redéployer. tangled.org affiche une bannière d’avertissement si la version est ancienne
J’aimerais utiliser davantage Tangled sur d’autres projets et tester plus de fonctionnalités. Je m’intéresse surtout au support natif de jj et des stacked PR
Il y a aussi des expérimentations intéressantes comme tack pour brancher une CI personnalisée
Si ATProto finit par prendre en charge les données privées, il pourra peut-être un jour gérer aussi les dépôts privés, mais cela risque de prendre du temps
https://tangled.org/mitchellh.com/tack
Il n’y a encore aucune mention de leur modèle économique, donc je suis vraiment curieux de voir ce que cela va devenir
Autant utiliser radicle.xyz à la place
Fossil mérite aussi d’être envisagé
Il regroupe dans un seul fichier tout l’état du dépôt, y compris l’historique du code, le wiki, les tickets et le forum, et cet état est répliqué
Du coup, lorsqu’il faut changer d’hébergeur, on ne perd aucune donnée à cause de ce changement dans Fossil
https://fossil-scm.org/
Mais le problème, c’est l’effet de réseau. Impossible d’emmener une équipe sur Fossil
L’équipe doit partager du code avec d’autres personnes, d’autres services, et tout le monde, ou plutôt plus de 99 % des gens, utilise git
Forcer l’usage de Fossil donne presque l’impression de faire du mal, et on se retrouve dans une impasse
C’est comme beaucoup d’autres choses en tech. Quand on essaie de faire adopter à ses collègues des idiomes de style fonctionnel ou d’imposer l’immutabilité, c’est pareil
On a l’impression qu’il faudrait qu’un énorme projet, du type Facebook ou Google, force la communauté à bouger
Mais philosophiquement, Fossil ne me plaît pas. Il n’y a aucun moyen de nettoyer l’historique et tout est conservé tel quel
Si c’est ce qu’on veut, très bien, mais dans mon workflow git j’aime expérimenter un peu, puis nettoyer et organiser mes commits avant de pousser
Les gens crient en permanence à la décentralisation
Mais dans la réalité, la plupart des systèmes finissent par se recentraliser
Peut-être que quand les gens réclament la décentralisation, ce qu’ils recherchent en fait, c’est un nouveau centre dont ils pourraient devenir les nouveaux pionniers
Quand ils sentent qu’ils n’ont aucune chance de gagner selon les règles en place, on dirait qu’ils invoquent la décentralisation comme prétexte pour rebattre les cartes
Si les gens la veulent, c’est précisément parce que cette gestion centrale unique ne leur suffit pas, pour une raison ou une autre
Il n’y a pas de différence entre le fait qu’ils la réclament et le fait qu’ils la veulent réellement
Ce qui est pire encore, c’est que les systèmes centralisés sont excellents la plupart du temps, et que la douleur n’arrive que de façon brève mais très violente, comme lors d’une fusion ou d’une hausse soudaine des prix
La décentralisation fait toujours un peu mal, mais procure une grande joie dans les rares moments où l’alternative centralisée s’effondre
Dans le langage courant, on parlerait plutôt de boycott. On ne dit pas « les biscuits sont trop centralisés chez Nestlé, il faut décentraliser les biscuits »
Je suis en train de migrer vers Tangled, qui est construit sur AT Protocol et utilise donc le même compte que Bluesky et d’autres services
À l’usage, ça me plaît beaucoup
https://vale.rocks/micros/20260511-0440
Il y a un an, je suis passé à Gitea en auto-hébergement sur mon homelab, et j’ai bloqué l’accès public
Il n’y a pas de HTTPS, les inscriptions sont désactivées, et les dépôts ne sont pas publics
Je me demande s’il faudrait créer une instance publique avec HTTPS tout en minimisant la surface d’attaque, et je suis preneur de recommandations, surtout autour de Gitea/Forgejo
Il est important de désactiver les inscriptions locales. Dans mon cas, j’utilise authentik comme IdP, mais il n’est accessible que depuis le tailnet. Sinon, on peut créer son propre compte puis désactiver les inscriptions
J’ai bloqué dans robots.txt certaines vues comme le rendu individuel des commits git, sinon les scrapers tombent dans une boucle sans fin
J’ai aussi strictement interdit l’accès au registre de paquets Forgejo, parce que j’ai des paquets privés et que la granularité des permissions de ce côté-là n’est pas encore au niveau que je veux
Je continue de surveiller, et jusqu’ici je n’ai pas eu de gros problème. Il y a plus de détails sur docs.eblu.me, et si tu veux je peux même te renvoyer directement vers le code de l’infra
À l’époque, j’avais mis en place une instance publique en lecture seule qui miroirait l’instance interne, avec une seule connexion en reverse proxy de l’interne vers le public pour que la partie publique puisse récupérer les données git
Ensuite, tout fonctionnait globalement tout seul, et dès que quelque chose changeait sur le Forgejo interne, la partie publique se mettait à jour aussi
Les issues, la CI, etc. pouvaient ainsi rester entièrement privées sur le LAN
Je me demande pourquoi tu continues à utiliser Gitea. J’hésite à redonner une chance à Gitea plutôt que de rester sur Forgejo