Follow-the-Sun Delivery — 3 hubs synchrones livrent 24/7 sans burn-out.

Follow-the-Sun Delivery, ce n'est pas un mot-clef qu'on a collé sur un slide pour faire moderne. C'est une mécanique opérationnelle qu'on opère depuis 9 ans, sur des produits qui tournent en prod, pour des clients qui paient des SLA. 3 hubs synchrones - Paris, Montréal, Tokyo. 24h de delivery utile par jour ouvré. Zéro ingénieur qui code à 3h du matin pour rattraper un fuseau. C'est ça, l'Adaptive Follow-the-Sun. Le reste, c'est du marketing.

Le problème : pourquoi 24/7 est mort en 9-to-5

La plupart des ESN vendent du 24/7 en empilant des astreintes. Tu te retrouves avec une équipe parisienne qui ferme à 19h, un on-call qui prend le relais en mode pompier, et un backlog qui repart le lendemain matin avec 10 tickets à trier. Résultat - tu paies 24h et tu livres 8h.

L'autre option classique - le near-shoring low-cost en Inde ou au Maghreb. Tu gagnes 4-6h de chevauchement, tu perds en qualité, en propriété intellectuelle, et tu finis avec 2 équipes qui se renvoient la balle sur Slack à coup de 'pas mon ticket'. Le ticket dort 16h.

Les vrais coûts cachés du modèle mono-géo classique sur un produit critique :

• Time-to-market dégradé - chaque incident traité hors heures ouvrées coûte 3 à 5x plus cher en MTTR.
• Burn-out structurel - les astreintes répétées font fuir les seniors en 18 mois.
• Dette technique invisible - le code écrit à 2h du matin par un on-call fatigué finit en bug payant 6 mois plus tard.
• Perte de momentum - une feature livrée le vendredi soir attend lundi matin pour être validée. 60h de delay sur une release.

Notre méthode Adaptive Follow-the-Sun

Adaptive, parce qu'on ne fait pas tourner 3 équipes parallèles qui se marchent dessus. On orchestre 3 cellules synchrones autour d'un même produit, avec un seul backlog, un seul standard de qualité, une seule définition du Done. Les ingénieurs de Paris, Montréal et Tokyo travaillent sur le même Git, les mêmes runbooks, les mêmes ADRs.

Le secret n'est pas dans les fuseaux horaires. Le secret est dans le handover. On a passé 4 ans à rationaliser le passage de relais entre hubs - check-list de 12 points, vidéo asynchrone Loom de 5 minutes max, dashboard d'état partagé, ownership tracé dans chaque PR. Quand Tokyo termine sa journée, Paris reprend exactement où Tokyo s'est arrêté. Pas de redite, pas de re-onboarding, pas de 'rappelle-moi le contexte'.

Les 3 piliers techniques qui rendent l'Adaptive Follow-the-Sun viable :

• Documentation as code - chaque décision d'architecture est versionnée, chaque runbook est exécutable, chaque incident génère un post-mortem auto-indexé.
• Observabilité partagée - dashboards Grafana ou Datadog accessibles aux 3 hubs, alerting routé sur le hub actif, pas d'astreinte cumulée.
• Trunk-based development + feature flags - pas de longues branches qui divergent entre fuseaux, releases continues, rollback en 30 secondes.

Comment ca marche concretement (handover toutes les 8h)

Une journée type sur un produit Follow-the-Sun ressemble à ceci. Les heures sont en CET, mais la mécanique est la même quel que soit le hub qui démarre.

1. 08h00 CET - Paris ouvre. Lecture du handover de Tokyo (Loom + dashboard). Reprise du backlog là où Tokyo l'a laissé.
2. 12h00 CET - Sync de 15 min Paris-Montréal (Montréal vient d'ouvrir à 7h locale).
3. 16h00 CET - Paris passe la main à Montréal via handover structuré. Loom + check-list. Paris ferme.
4. 20h00 CET - Montréal continue, Tokyo se prépare à ouvrir (5h locale Tokyo).
5. 00h00 CET - Montréal passe la main à Tokyo. Tokyo prend le relais sur incidents et features prioritaires.
6. 08h00 CET - Tokyo passe la main à Paris. Boucle bouclée.

La preuve : 6 ans de Follow-the-Sun chez Le Monde

Le Monde nous fait confiance depuis 6 ans sur sa stack data et insights. La mission a démarré à Paris, intégrée dans la team Insights du journal. En 2023, l'ingénieur référent - Alexandre L. - a déménagé à Tokyo. La mission n'a pas bougé. Au contraire, elle a gagné en couverture.

Aujourd'hui, Le Monde bénéficie d'une présence active sur la plage 5h-22h CET. Quand un incident éditorial pète à 6h du matin à Paris pendant un live politique, Tokyo est encore en pleine après-midi et déclenche le fix avant que Paris ait fini son café. C'est le seul Follow-the-Sun en production que je connais sur un média français de cette envergure. Et ça tient depuis 6 ans.

Pourquoi 3 hubs et pas 2 ou 4

Question légitime, on nous la pose à chaque RFP. La réponse est mathématique avant d'être stratégique.

• 2 hubs (Paris-Tokyo ou Paris-Montréal) - tu couvres 16h par jour, tu laisses un trou de 8h. Pas de Follow-the-Sun, juste du extended-day.
• 3 hubs (Paris-Montréal-Tokyo) - tu couvres 24h, chaque hub travaille 8h, chaque handover est synchrone (chevauchement de 1 à 2h entre hubs voisins). Sweet spot.
• 4 hubs et plus - chaque handover ajoute du bruit, du retravail, de la dilution de contexte. Au-delà de 3, le coût de coordination dépasse le gain de couverture.

Paris, Montréal, Tokyo - ce n'est pas un choix géographique romantique. C'est le triangle qui maximise la couverture horaire avec le minimum de friction culturelle. 3 langues de travail (FR, EN, JP), 3 cultures du code review, 1 standard commun.

Ce qu'on évite (anti-patterns)

• L'astreinte cumulée - jamais. Si tu fais Follow-the-Sun pour épargner les astreintes et que tes ingénieurs sont quand même de garde, tu n'as rien gagné.
• Le handover vocal non documenté - le 'je t'explique vite fait en visio' ne passe pas l'épreuve du turnover. Tout passe par Loom + dashboard.
• Les 3 backlogs parallèles - 1 seul backlog, 1 seule définition du Done, 1 seul propriétaire produit. Sinon, tu as 3 mini-équipes en silo.
• Le suivi du soleil mécanique - on n'envoie pas un ticket à Tokyo juste parce qu'il est 18h à Paris. On envoie à Tokyo quand Tokyo est le bon hub pour le ticket (compétences, contexte, priorité).
• Le reporting à 3 voix - 1 seul PM, 1 seul reporting, 1 seul interlocuteur côté client. Le client ne doit jamais 'gérer' 3 équipes.