On a migré 4 200 dépôts vers GitHub Enterprise. Voici ce que je referais autrement.
Deux ans après avoir orchestré la migration de 4 200 dépôts vers GitHub Enterprise, voici ce que je retiens.
Ce qu’on a bien fait2
La décision de migrer par vagues de 50 dépôts plutôt qu’en masse a sauvé le projet. Chaque vague nous donnait un cycle de feedback de 48h avant de passer à la suivante.
Automatiser la validation des pipelines CI après chaque migration était non-négociable. Sans ça, on aurait découvert les régressions en production.
Ce qu’on a raté
On a sous-estimé la charge cognitive des équipes. Migrer un repo n’est pas juste un clic : il faut mettre à jour les tokens, reconfigurer les webhooks, former les développeurs aux nouvelles conventions de branche.
Communiquer “quand c’est fait” ne suffit pas. Les équipes ont besoin d’une fenêtre de migration planifiée, pas d’une surprise dans leur backlog un lundi matin.
Le playbook que j’aurais voulu avoir
- Cartographier les dépendances inter-repos avant de migrer. Les pipelines qui tirent des artefacts d’autres repos sont des bombes à retardement.
- Créer un canal Slack dédié par vague, pas un canal global. Les questions sont contextuelles.
- Mesurer la vélocité avant/après. Pas pour justifier la migration — pour détecter les équipes qui ont décroché.
- Prévoir 20% du temps pour les cas limites. Les monorepos, les forks privés, les intégrations tierces legacy.
La migration elle-même est la partie facile. Le vrai travail, c’est d’accompagner les habitudes.