Follow the Sun : le passage de relais qui a permis à Baldur's Gate 3 d'être un succès mondial
Août 2023. Baldur’s Gate 3 sort complet après trois ans d’Early Access. 96/100 sur Metacritic. GOTY aux Game Awards. Au générique : environ 500 personnes, sept studios, trois continents. La question que je me suis toujours posée : comment est-ce qu’on conserve un produit cohérent quand les personnes qui le construisent ne travaillent jamais en même temps ? Quand ils n’ont pas la même culture, les mêmes références ?
Le modèle Follow the Sun a la réputation d’une belle idée qui plante en production. La coordination déraille, les handoffs transmettent du contexte incomplet, les silos horaires remplacent les silos géographiques. Larian Studios en a fait un avantage stratégique leur permettant de livrer un jeu d’une complexité narrative et technique sans précédent. Comment ? En traitant le Follow the Sun non pas comme un problème d’organisation, mais comme une infrastructure de collaboration. C’est ce que je vous propose de décortiquer dans cet article.
En résumé — Follow the Sun ne fonctionne pas simplemennt parce qu’on répartit des équipes sur plusieurs fuseaux horaires. Il fonctionne quand le pipeline technique est solide, la vision claire, et la collaboration totale. Larian l’a appliqué avec succès sur Divinity Original Sin 2, puis sur BG3 à plus grande échelle. PLusieurs leçons peuvent être tirées.
Navigation : Promesse du modèle · La mécanique Larian · Ce qui a tenu · Enjeu DevEx · Leçons terrain · FAQ
Qu’est-ce que le Follow the Sun promet vraiment ?
Le principe est simple : des équipes réparties sur plusieurs fuseaux horaires se passent le travail comme un relais. Une zone géographique termine sa journée et transmet ; une autre reprend là où la première s’est arrêtée. En théorie, cela permet un cycle de production quasi-continu : moins de temps mort, une QA qui tourne pendant que l’autre dort, des itérations plus rapides.
En pratique, la plupart des tentatives plantent au même endroit : elles se concentrent sur les heures, pas sur le flux de connaissance. Le relay horaire ne fonctionne que si l’équipe qui reprend sait exactement où elle en est, ce qui a été décidé, et pourquoi. Sinon, les fuseaux deviennent des silos.
L’échec classique : on ouvre un bureau à l’autre bout du monde, on définit des plages de relay, et on s’étonne à postériorique les handoffs soient inefficaces. La clé est bien en amont : standardiser les pipelines, clarifier les responsabilités, documenter les décisions, partager une vision et une culture commune. C’est là que Larian a réussi un véritable tour de force.
Six studios, trois continents : la mécanique concrète
Larian n’a pas attendu Baldur’s Gate 3 pour penser distribué, mais le développement du jeu a accéléré leur croissance plus rapidement que prévu. En annonçant l’ouverture de nouveaux studios, le studio a explicitement formulé sa stratégie : “Creating Baldur’s Gate 3 is a huge undertaking and we are growing the team to help us follow the sun.” Ce n’est pas une métaphore de croissance ; c’est une décision d’architecture organisationnelle assumée.
La répartition actuelle couvre les trois grandes zones horaires utiles :
- Europe : Ghent (siège), Dublin, Barcelone, Guildford, Warsaw ; soit UTC+1 à UTC+2
- Amérique du Nord : Québec City ; soit UTC-5 à UTC-4
- Asie : Kuala Lumpur ; soit UTC+8
Amplitude de 13 heures entre Québec et KL — à gauche, Ghent et Dublin ouvrent la journée de Barcelone à Warsaw ; à droite, KL passe le relais à l’Europe chaque matin.
Ce n’est pas un Follow the Sun “pur” à trois relais parfaitement espacés. Les studios européens partagent des fuseaux quasi-identiques. L’amplitude réelle vient de KL, 6 à 7 heures en avance sur l’Europe, et de Québec, 5 à 6 heures en retard. En pratique, cela crée deux grandes fenêtres de relay : Europe vers Amérique en fin d’après-midi, et Asie vers Europe le matin. C’est un modèle distribué avec chevauchements partiels ; c’est aussi le cas le plus courant en enterprise, et le plus faisable à mettre en place.
Pour que cette mécanique fonctionne, Larian a investi massivement dans son pipeline. Les outils officiellement mentionnés dans leurs GDC talks incluent Flow Production Tracking (anciennement ShotGrid) pour le suivi de production, Jira pour les tickets, complétés par des bridges et des pipelines internes. Le résultat : assets, tickets, builds, états de validation sont accessibles et transférables sans friction entre tous les studios. Un ticket ouvert le matin à Ghent peut avoir été traité, testé et intégré à Québec avant le lendemain matin en Belgique.
Qu’est-ce qui a rendu ce relay possible ?
La réponse courte : l’organisation n’y est pour presque rien.
Une culture async d’abord. Un Follow the Sun qui dépend de validations en temps réel est condamné ; les fuseaux deviennent un enfer d’indisponibilité. Larian a structuré son travail autour de la documentation, de tickets extrêmement détaillés, et d’un ownership clair sur chaque tâche. Chaque studio peut avancer sans attendre l’accord d’un autre. C’est exactement ce que GitLab documente dans sa culture remote : l’asynchrone n’est pas un palliatif au présentiel, c’est un mode de travail autonome.
Le partage de compétences comme résilience. Sur BG3, les discipline leads — les responsables techniques et créatifs — circulaient entre studios. Pas pour contrôler, mais pour transmettre les standards de décision. Un lead narrative à Dublin devait pouvoir prendre une décision que le lead à Ghent aurait prise de la même façon. Ce n’est pas de la standardisation rigide ; c’est de la résilience : aucun studio n’est l’unique détenteur d’un savoir critique. Dans les équipes enterprise qui souffrent le plus du travail distribué, c’est souvent ce bus factor géographique qui bloque : un expert à Paris, personne à Montréal ne peut décider sans lui.
La vision partagée comme filtre de décision. “Rester fidèle aux règles de Donjons & Dragons” est une directive qui semble simple ; elle est en fait un filtre universel. Face à des centaines de décisions quotidiennes — mécaniques de combat, dialogues, permutations narratives — chaque équipe dispose d’un cadre de référence commun. Cela remplace une quantité phénoménale de micro-validations. En enterprise IT, l’équivalent existe : une vision produit claire, des principes d’architecture documentés, une définition partagée de “prêt pour la production”. Les équipes qui les ont n’attendent pas ; les autres bloquent sur des décisions qui auraient dû être triviales.
Pourquoi FTS est autant un problème DevEx qu’organisationnel
C’est peut-être la leçon la plus directement transposable. Chez Larian, la réussite du relay repose sur la qualité du pipeline technique autant que sur l’organisation humaine. Un asset mal versionné, un build non reproductible, un ticket incomplet : et le studio qui reprend passe ses premières heures à reconstruire du contexte au lieu d’avancer.
En enterprise IT, les mêmes symptômes apparaissent. Les équipes distribuées qui souffrent le plus ne sont pas celles dont l’organisation est mauvaise ; ce sont celles dont la gestion de source est incohérente entre sites, dont les environnements de développement divergent selon les bureaux, dont les pipelines CI/CD ne produisent pas de builds reproductibles.
Une stratégie d’outillage pensée à l’échelle n’est pas un luxe dans un modèle distribué : c’est une condition d’exécution. Les Dev Containers en sont un exemple concret : l’environnement devient un artifact versionné, transmissible, reproductible par n’importe quel studio.
La thèse de Larian, résumée en une ligne : le pipeline technique est une infrastructure de collaboration, pas un problème d’ingénierie isolé.
Ce que l’enterprise IT peut en tirer sans romantiser le jeu vidéo
BG3 n’est pas un modèle universel. Dans un entretien accordé au podcast Silence on Joue, Swen Vincke a évoqué des journées de 17 heures à cheval sur plusieurs fuseaux horaires pour coordonner les studios. Le modèle réduit le crunch sur les équipes d’exécution ; il peut le concentrer sur ceux qui orchestrent. Follow the Sun ne supprime pas la pression de livraison : il la redistribue. Ce n’est pas un mécanisme magique ; c’est un amplificateur : il amplifie ce qui est déjà bon dans une organisation, et il amplifie aussi ce qui est défaillant.
Ce que le modèle offre concrètement, quand les conditions sont réunies :
- Une QA quasi-continue : quand une feature est complète en Europe, une équipe nord-américaine peut la tester pendant la nuit européenne. Sur BG3, avec ses milliers de permutations narratives et d’états de sauvegarde, c’est devenu structurel.
- Une réduction des goulots de dépendance : les bloquages interéquipes se traitent pendant le décalage horaire plutôt qu’en file d’attente.
- Une capitalisation des solutions : un problème résolu à KL le soir arrive documenté à Ghent le matin. Le savoir circule dans les deux sens du relay.
Les trois conditions minimales pour que ça tienne :
- Pipeline tooling solide : versioning, CI/CD, ticketing global, builds reproductibles. Sans ça, le relay transmet des puzzles, pas du travail.
- Ownership sans ambiguïté : chaque tâche a un responsable identifié. Le relay passe le travail, pas la responsabilité.
- Vision partagée et documentée : les décisions doivent pouvoir être prises localement, sans escalade permanente. Cela demande d’avoir pris le temps de documenter les principes, pas seulement les fonctionnalités.
Et un avertissement honnête : ce modèle coûte de l’onboarding permanent. Chaque nouveau studio, chaque nouvelle équipe, doit absorber les standards du pipeline et les principes de vision. C’est une dette qui se paie au démarrage et à chaque changement de périmètre ; elle doit être budgétée explicitement, pas subie.
Sur le même sujet : Stratégie IDE à l’échelle de l’entreprise · Dev Containers et reproductibilité des environnements · Gestion de source et expérience développeur
Questions fréquentes
Follow the Sun est-il réservé aux grandes organisations comme Larian ?
Non. Le principe s’applique dès qu’une organisation a des équipes dans deux fuseaux horaires significativement différents, même à petite échelle. Une équipe de 20 personnes répartie entre Paris et Montréal peut bénéficier d’un relay partiel : 6 heures de décalage suffisent pour qu’un ticket ouvert le matin en France soit traité avant que l’équipe française reprenne le lendemain. Ce qui change à grande échelle, c’est la rigueur requise sur le tooling et la documentation ; les principes restent les mêmes.
Pourquoi la plupart des tentatives de Follow the Sun échouent-elles ?
Parce qu’elles traitent le sujet comme un problème d’organisation RH, pas de flux de connaissance. On répartit les équipes sur des fuseaux, on définit des plages de relay, et on s’étonne que les handoffs soient inefficaces. Le vrai travail est en amont : standardiser les pipelines, clarifier les ownerships, documenter les décisions. Sans ces fondations, les équipes en relay passent leurs premières heures à reconstruire du contexte plutôt qu’à produire.
Qu’est-ce que “partager la vision” veut dire opérationnellement ?
Ce n’est pas un exercice de communication interne. C’est avoir des principes de décision documentés, accessibles à tous, que chaque équipe peut appliquer sans escalade. Chez Larian, “fidèle à D&D” était ce filtre. En enterprise IT, l’équivalent peut être des Architecture Decision Records, un Product Vision Document, ou une définition précise de “prêt pour la production”. Le signe que la vision est vraiment partagée : une équipe à l’autre bout du monde peut trancher une décision non prévue dans les spécifications, et le résultat est cohérent avec ce que le reste de l’organisation aurait choisi.
Quel est le vrai coût du modèle distribué ?
Le coût principal est l’onboarding permanent et la maintenance de la documentation. Dans un modèle distribué, la documentation n’est pas un artifact post-production : c’est une infrastructure active. Chaque décision technique importante doit être écrite pour être transmissible. Cela prend du temps, et ce temps doit être budgété explicitement. Le second coût, souvent sous-estimé : les outils doivent être maintenus à un niveau de fiabilité plus élevé qu’en équipe colocalisée. Un pipeline cassé à 17h à Ghent qui bloque Québec à 11h, c’est une demi-journée perdue.