Les Chemins Libres

Décentralisation, Radicle, alternatives et avenir de Git

Les limites du monde centralisé

Pendant tout ton parcours, tu as utilisé des plateformes comme GitHub, GitLab, Bitbucket. Ces forges sont puissantes, mais elles ont un défaut fondamental : elles sont centralisées.

Le point de défaillance unique

Quand GitHub tombe en panne (et ça arrive) des millions de développeurs dans le monde se retrouvent bloqués. Plus de push, plus de pull, plus de CI/CD. Le travail s'arrête.

C'est ce qu'on appelle un point de défaillance unique (Single Point of Failure). Toute l'infrastructure repose sur un seul endroit. Si cet endroit tombe, tout tombe.

Le contrôle d'entreprise

GitHub appartient à Microsoft depuis 2018. GitLab est une entreprise cotée en bourse. Ces plateformes peuvent :

• Changer leurs conditions d'utilisation du jour au lendemain
• Augmenter leurs prix ou supprimer des fonctionnalités gratuites
• Supprimer des dépôts pour des raisons politiques, juridiques ou commerciales
• Restreindre l'accès à certains pays (sanctions économiques)

Le verrouillage fournisseur

Tu utilises GitHub Actions ? GitHub Pages ? GitHub Packages ? Plus tu utilises de services spécifiques à une plateforme, plus tu es verrouillé. Migrer devient de plus en plus difficile.

L'ironie de Git - un outil distribué utilisé de manière centralisée

Voici quelque chose de fascinant : Git a été conçu pour être distribué. Linus Torvalds l'a créé en 2005 précisément pour éviter de dépendre d'un serveur central (après la rupture avec BitKeeper).

Dans Git, chaque clone est un dépôt complet. Chaque développeur possède l'historique entier. En théorie, il n'y a pas de "serveur principal" - juste des pairs qui synchronisent leurs copies.

Et pourtant, qu'avons-nous fait ? Nous avons recentralisé tout le système autour de GitHub. Le origin est devenu le point de vérité unique. Les Pull Requests n'existent que sur la plateforme. Les issues, les wikis, les CI - tout est sur un serveur central.

Ce que Git permet :          Ce qu'on fait en pratique :

  Alice <-> Bob                  Alice -> GitHub <- Bob
    |         |                            |
  Carol <-> Dave                        Carol
                                           |
  (pair-à-pair)                          Dave

                                 (étoile centralisée)

C'est comme avoir une voiture capable de voler, mais ne l'utiliser que pour se garer.

Radicle - la collaboration pair-à-pair

Radicle est un protocole de collaboration sur le code source qui fonctionne en pair-à-pair (peer-to-peer). Pas de serveur central, pas de compte à créer, pas d'entreprise qui contrôle l'infrastructure.

Comment ça fonctionne

Radicle est construit sur Git. Ce n'est pas un remplacement de Git, c'est une couche de collaboration qui utilise Git comme fondation :

• Pas de serveur central : les dépôts sont partagés directement entre les pairs
• Identité cryptographique : pas de nom d'utilisateur/mot de passe. Tu es identifié par une clé cryptographique (comme SSH, mais pour ton identité)
• Patches au lieu de Pull Requests : les contributions se font via des "patches" proposés, discutés et mergés de pair à pair
• Seeds : des nœuds qui restent en ligne pour améliorer la disponibilité (comme des "semences" qui gardent les données accessibles)

Les commandes de base

# Initialiser un projet Radicle dans un dépôt Git existant
rad init

# Publier ton dépôt sur le réseau
rad push

# Récupérer un projet depuis le réseau
rad clone rad:<identifiant-du-projet>

# Synchroniser avec les pairs
rad sync

# Proposer un patch (équivalent d'une Pull Request)
rad patch create

# Lister les patches en attente
rad patch list

Ce qui change par rapport à GitHub

L'état actuel de Radicle

Soyons honnêtes : Radicle est encore jeune. La communauté est petite mais passionnée. L'interface n'est pas aussi polie que GitHub. Certaines fonctionnalités manquent encore.

Mais l'idée est puissante. Et comme tout mouvement qui commence petit - Linux, Git lui-même, le Web - il suffit parfois d'une communauté déterminée pour changer le monde.

Les autres voies alternatives

Radicle n'est pas la seule alternative. D'autres projets explorent des philosophies différentes :

Forgejo / Gitea - L'auto-hébergement léger

Forgejo (fork communautaire de Gitea) est une forge que tu peux héberger toi-même sur un simple serveur. Interface similaire à GitHub, légère, rapide, et entièrement sous ton contrôle.

• Philosophie : "ton code, ton serveur, tes règles"
• Avantage : compatible avec les workflows GitHub (y compris les Actions via Forgejo Actions)
• Idéal pour : les équipes qui veulent le confort de GitHub sans la dépendance

SourceHut - Le minimalisme radical

SourceHut (sr.ht) est une forge minimaliste créée par Drew DeVault. Pas de JavaScript obligatoire, workflow basé sur les emails (patches par email, comme le noyau Linux).

• Philosophie : "le Web devrait être simple"
• Avantage : rapide, accessible, respectueux de la vie privée
• Idéal pour : les développeurs qui préfèrent la ligne de commande et les emails

Fossil - L'alternative intégrée

Fossil n'est pas basé sur Git - c'est un système de versionnement complètement différent, créé par Richard Hipp (le créateur de SQLite). Il intègre nativement un wiki, un système de tickets, et un forum.

• Philosophie : "un seul outil pour tout"
• Avantage : un seul binaire, tout est intégré, pas besoin de services externes
• Idéal pour : les petits projets qui veulent un outil complet et autonome

Software Heritage - L'archive universelle

Software Heritage est un projet de la fondation INRIA qui archive tout le code source public de l'humanité. Son but n'est pas la collaboration mais la préservation - s'assurer que le code ne disparaît jamais.

L'avenir du versionnement

Le monde du versionnement ne s'arrête pas là où nous sommes. Voici les tendances qui façonnent l'avenir :

L'intelligence artificielle dans le développement

Les outils d'IA transforment déjà la façon dont on écrit et révise le code :

• Assistants de code (Copilot, Claude, etc.) : génération et suggestion de code en temps réel
• Revue automatique : des IA qui analysent les Pull Requests et suggèrent des améliorations
• Résolution de conflits : l'IA pourrait un jour aider à résoudre les conflits de merge complexes
• Génération de tests : créer automatiquement des tests à partir du code

Les dépôts de plus en plus grands

Git évolue pour gérer des projets toujours plus massifs :

• Git LFS (Large File Storage) : stocker les gros fichiers en dehors du dépôt
• Partial clone : cloner un dépôt sans télécharger tout l'historique
• Sparse checkout : ne récupérer que les dossiers dont tu as besoin
• git maintenance : des tâches automatiques d'optimisation pour garder les gros dépôts performants

# Partial clone - ne télécharge les objets que quand nécessaire
git clone --filter=blob:none <url>

# Sparse checkout - ne récupérer que certains dossiers
git sparse-checkout init
git sparse-checkout set src/ docs/

# Maintenance automatique
git maintenance start

Le débat Monorepo vs Polyrepo

Un grand débat agite le monde du développement :

• Monorepo : tout le code de l'entreprise dans un seul dépôt géant (Google, Meta, Microsoft le font)
• Polyrepo : un dépôt par projet/service (la majorité des entreprises)

Chaque approche a ses forces. Le monorepo simplifie le partage de code et les refactorings transversaux. Le polyrepo offre l'indépendance et la simplicité.

GitOps - L'infrastructure pilotée par Git

GitOps est une philosophie où toute l'infrastructure est décrite dans des fichiers versionnés avec Git. Modifier l'infrastructure, c'est faire un commit. Déployer, c'est merger.

• Le dépôt Git devient la source de vérité pour l'infrastructure
• Les déploiements sont automatiques et auditables
• Les rollbacks sont aussi simples qu'un git revert

Rétrospective - Ton parcours complet

Prends un moment pour mesurer le chemin parcouru. Tu es arrivé dans cette Citadelle sans savoir ce qu'était un commit. Regarde où tu en es maintenant.

Arc 1 - Les Fondations du Versionneur

Tu as appris les bases de Git - les fondations sur lesquelles tout repose :

• git init, git add, git commit - créer et enregistrer l'histoire
• git status, git log, git diff - observer et comprendre l'histoire
• git clone - récupérer l'histoire d'un autre
• Le fichier .gitignore - savoir ce qui ne doit pas être archivé

Arc 2 - Les Chemins du Collaborateur

Tu as appris à travailler avec les autres :

• git branch, git switch, git merge - créer et fusionner des branches
• git rebase - réécrire l'histoire proprement
• git remote, git push, git pull - synchroniser avec le monde
• Les Pull Requests et la revue de code - collaborer avec rigueur

Arc 3 - Les Arts Avancés

Tu as maîtrisé les techniques avancées :

• git stash - mettre de côté un travail en cours
• git bisect - traquer un bug dans l'histoire
• git blame - retrouver l'auteur de chaque ligne
• git cherry-pick - cueillir un commit précis
• git tag - marquer les versions importantes
• Les hooks Git - automatiser les vérifications

Arc 4 - Les Forges Automatiques

Tu as découvert l'automatisation :

• L'intégration continue (CI) - tester automatiquement à chaque push
• Le déploiement continu (CD) - déployer automatiquement en production
• GitHub Actions - écrire des workflows d'automatisation
• Les autres forges - GitLab CI, Bitbucket Pipelines, Jenkins

Arc 5 - Au-delà des Guildes

Et maintenant, tu as vu au-delà :

• Les limites de la centralisation
• L'ironie de Git utilisé de manière centralisée
• Radicle et la collaboration pair-à-pair
• Les alternatives et l'avenir du versionnement

Exercice final - Mon parcours

Étape 1 - Créer le dépôt

mkdir mon-parcours
cd mon-parcours
git init -b main

Étape 2 - Écrire ta réflexion

Crée un fichier mon-parcours.txt et écris-y ta réflexion personnelle. Il n'y a pas de format imposé. Voici quelques idées pour t'inspirer :

• Qu'est-ce qui t'a le plus surpris dans Git ?
• Quelle commande ou concept as-tu trouvé le plus difficile ?
• Comment comptes-tu utiliser Git dans tes projets futurs ?
• Qu'est-ce que tu retiens de cette aventure ?

C'est ton texte. Écris ce que tu veux, avec tes mots.

Étape 3 - Commiter avec un message significatif

git add mon-parcours.txt
git commit -m "Mon parcours de Maître Versionneur"

Choisis un message de commit qui a du sens pour toi. C'est ton premier commit en tant que Maître Versionneur - il mérite un beau message.

Étape 4 - Marquer ta version

git tag -a v1.0.0 -m "Ma première version en tant que Maître Versionneur"

Ce tag marque le début de ton nouveau chapitre. La version v1.0.0 - stable, complète, prête.

Étape 5 - Lancer la vérification

Bash (Linux / macOS / Git Bash sur Windows) :

bash verifier.sh

PowerShell (Windows) :

.\verifier.ps1

La cérémonie finale

Récapitulatif des concepts