Follow-the-sun delivery : vos roadmaps avancent pendant que vous dormez.

Le modèle

Trois hubs synchrones : Paris (CET), Montréal (EST), Tokyo (JST). Chaque ticket suit le soleil — Paris démarre le matin, ferme à 18h en passant la main à Montréal, Montréal ferme à 18h EST en passant la main à Tokyo, Tokyo ferme à 18h JST en repassant la main à Paris. La roadmap avance pendant que vous dormez. Pas de magie : c'est de l'orchestration disciplinée.

• Paris 09h–18h CET → handoff 18h CET (= 12h EST) → Montréal prend
• Montréal 12h–21h EST → handoff 21h EST (= 10h JST J+1) → Tokyo prend
• Tokyo 10h–19h JST → handoff 19h JST (= 11h CET) → Paris reprend
• Overlap structuré 1h en début et fin de chaque hub : la main ne part jamais en l'air

Pourquoi ce n'est pas de l'offshoring

L'offshoring classique vend du jour-homme low-cost en Inde ou aux Philippines avec un PM qui traduit. Le résultat : roadmap qui ralentit (overlap zéro avec la France), qualité qui se dégrade (zéro contexte client), retour de bâton compliance (RGPD, secret bancaire). Le tri-géo Abbeal est l'inverse architectural :

• Hub Tokyo / Montréal / Paris = même TJM senior (pas du low-cost)
• Recrutement local par des ingénieurs (pas des chasseurs RH)
• Overlap quotidien 1h × 2 entre hubs (vs 0 chez l'offshore)
• Ownership de bout-en-bout par hub (vs ticket-pingpong) — 3 squads autonomes
• Conformité européenne native (RGPD, ACPR, SecNumCloud) sur tous les hubs

Comment ça marche concrètement — 5 piliers

1. Handoff écrit, pas oral

Chaque fin de journée, le hub partant écrit un état des lieux : 3 lignes par ticket en cours, blockers identifiés, prochaine action attendue. Pas de réunion de passage — le contexte tient dans un commentaire de ticket lisible en 90 secondes. Le hub entrant lit avant le café.

2. Overlap sacré — 1h × 2 par jour

Les fenêtres d'overlap (Paris 17h-18h ↔ Montréal 11h-12h, Tokyo 18h-19h ↔ Paris 10h-11h) sont sanctuarisées : aucune meeting interne n'y est prise, c'est réservé au handoff actif et aux questions client en synchrone. Si on n'a rien à dire pendant l'overlap, on l'occupe par de la review de PR.

3. Taille de ticket calibrée

Un ticket doit pouvoir être complété ou explicitement passé en overlap. Si un ticket dépasse 2 jours-homme, on le découpe. Pas pour des raisons agiles abstraites — pour que le contexte tienne dans un handoff écrit.

4. Ownership par fuseau

Chaque squad de hub porte la responsabilité technique d'un domaine fonctionnel (ex : Paris = backend payment, Montréal = data ingestion, Tokyo = mobile API). Ça évite le syndrome "qui a touché à quoi" qui détruit l'offshoring.

5. Run complet local par hub

Chaque hub doit pouvoir faire tourner l'environnement complet localement (docker-compose ou équivalent). Pas de dépendance critique sur une stack qui ne tourne qu'à Paris. C'est ce qui fait que Tokyo peut shipper un fix prod à 3h du matin parisien sans réveiller personne.

Cas d'usage : ce qui tourne en prod

Trois exemples concrets, extraits de cases clients déjà déployés :

• FinTech SaaS européenne — ISO 27001 livré en 9 mois (vs 18 estimés) grâce au tri-géo. Audit DevSecOps Paris, automation pipelines Montréal, doc compliance Tokyo. SOC 2 enchaîné dans la foulée.
• Leader e-commerce sport — refonte PWA, +18 % conversion mobile en 6 mois. Frontend Paris, perfs Lighthouse Montréal, A/B testing JP. Lighthouse score 92 sur mobile.
• Industriel japonais robotique — flotte 80 AGV ROS 2, +40 % throughput entrepôt. Stack Rust embarqué Tokyo, Isaac Sim Paris, monitoring Montréal.