Senior Backend Engineer — Tokyo

Tokyo a un problème d'ingénieurs backend seniors. Pas un problème de talents — la scène tech japonaise en regorge — mais un problème d'alignement. D'un côté, des entreprises FinTech en croissance rapide qui ont besoin de systèmes robustes, scalables, construits avec des stacks modernes. De l'autre, des ingénieurs expérimentés souvent coincés dans des organisations legacy où Go et Kubernetes sont encore des buzzwords, pas des outils quotidiens.

Chez Abbeal Tokyo, on construit des plateformes backend critiques pour des clients FinTech japonais. Pas du conseil PowerPoint. Du code en production qui traite des transactions réelles, avec des SLAs qui ne pardonnent pas. On cherche un Ingénieur Backend Senior capable de rejoindre une équipe bilingue (JLPT N2 minimum) et de prendre ownership sur des systèmes qui comptent.

Cet article détaille ce qu'on attend concrètement, pourquoi cette position existe, et ce que ça implique vraiment de travailler dans une ESN senior en 2025 à Tokyo — sans le bullshit habituel des descriptions de poste.

Pourquoi cette position existe

Nos clients FinTech japonais ont des besoins spécifiques qui ne se résolvent pas avec des solutions prêtes à l'emploi. Ils migrent des systèmes monolithiques Java vieux de 10 ans vers des architectures microservices modernes. Ils lancent de nouveaux produits financiers qui nécessitent des APIs temps réel avec des garanties de cohérence transactionnelle. Ils passent de 100k à 10M d'utilisateurs et découvrent que leur infra ne suit pas.

Le contexte japonais ajoute des contraintes : réglementations financières strictes (FSA), exigences de souveraineté des données, interfaces avec des systèmes bancaires legacy qui communiquent encore en JIS X 0208. On ne peut pas copier-coller une architecture AWS standard et appeler ça du jour.

On cherche quelqu'un qui peut naviguer cette complexité technique ET culturelle. Qui comprend pourquoi un système de paiement doit gérer les idempotency keys différemment selon qu'on traite avec Zengin ou les cartes internationales. Qui sait qu'une migration de base de données sur un service critique ne se fait pas un mardi après-midi sans coordination avec 4 départements différents.

Stack technique : ce qu'on utilise et pourquoi

Go comme langage principal

On a standardisé sur Go pour le backend. Pas par dogme, mais parce qu'après 3 ans de projets FinTech, c'est ce qui marche le mieux pour nos cas d'usage : performance prévisible, déploiement simple (un binaire statique), modèle de concurrence qui gère bien les workloads I/O-bound typiques des APIs financières, outillage mature pour les services distribués.

On s'attend à ce que tu sois à l'aise en Go idiomatique, pas juste capable de traduire du Java. Ça veut dire : comprendre les trade-offs entre channels et mutexes, savoir quand utiliser context.Context pour la cancellation, écrire des tests de table-driven qui ne sont pas une souffrance à maintenir.

Kubernetes en production

Tous nos déploiements passent par Kubernetes. On utilise GKE pour la plupart des clients, parfois EKS quand il y a des contraintes AWS existantes. On s'attend à ce que tu comprennes non seulement comment déployer un pod, mais comment déboguer une fuite mémoire dans un container, configurer des resource limits qui ne tuent pas les perfs, mettre en place des health checks qui détectent vraiment les problèmes.

La réalité : Kubernetes en prod FinTech, c'est 20% de config YAML et 80% de troubleshooting. Comprendre pourquoi un service met 30 secondes à répondre après un rolling update. Investiguer des timeouts intermittents qui apparaissent seulement sous charge. Optimiser des startup times parce qu'un cold start de 2 minutes n'est pas acceptable quand on scale horizontalement.

PostgreSQL et cohérence des données

PostgreSQL reste notre base de données relationnelle de référence. On travaille avec des journaux de transactions qui doivent être ACID-compliant, des schémas qui évoluent sans downtime, des query plans qu'il faut optimiser parce qu'un full table scan sur 50M de lignes casse le SLA.

On s'attend à une vraie compréhension des bases de données, pas juste savoir écrire du SQL basique. Isolation levels et leurs implications. Stratégies d'index (B-tree vs GIN vs BRIN selon les cas). Partitioning pour gérer la croissance. Replication lag et comment ça impacte l'architecture applicative.

Infrastructure as Code avec Pulumi

On utilise Pulumi (TypeScript principalement) pour gérer l'infrastructure. Choix délibéré vs Terraform : on préfère du vrai code avec type checking et tests unitaires plutôt que du HCL. Ça permet de construire des abstractions réutilisables entre projets clients.

T'as pas besoin d'être expert Pulumi — on a des templates et des patterns établis. Mais il faut être à l'aise avec l'approche IaC en général : tout versionné, tout reviewable, tout reproductible.

Le profil qu'on cherche

Senior chez nous, ça ne veut pas dire "X années d'expérience". Ça veut dire capacité à prendre ownership sur un système complet, de l'architecture aux détails d'implémentation. Capacité à débloquer une équipe quand elle est coincée. Capacité à dire non à un choix technique foireux même quand ça vient d'un client.

• Expérience backend substantielle : 5+ ans à construire et maintenir des systèmes en production, idéalement dans des domaines où la fiabilité compte (FinTech, healthtech, commerce électronique haute volumétrie)
• Mindset ownership : tu ne livres pas du code et passes à autre chose. Tu suis en production, tu te réveilles la nuit si ça casse, tu améliores progressivement
• Communication technique claire : capable d'expliquer des trade-offs complexes à des stakeholders non-techniques, en japonais ET en anglais
• Pragmatisme : tu sais quand optimiser et quand livrer du code "assez bon". Tu comprends le contexte business de tes décisions techniques
• Curiosité technique : tu lis des postmortems pour le plaisir, tu testes des nouvelles approches dans des side projects, t'as des opinions argumentées sur les outils

La contrainte langue : pourquoi JLPT N2+

On demande JLPT N2 minimum (ou équivalent démontrable). C'est non négociable. Pourquoi ? Parce que nos clients sont des entreprises japonaises où les décisions se prennent en japonais, où les specs sont écrites en japonais, où les incidents sont rapportés en japonais par des équipes locales.

En interne chez Abbeal, on fonctionne en bilingue — Slack mixe anglais/japonais selon les threads, meetings en japonais pour les clients, en anglais pour les discussions techniques pures. Mais tu ne peux pas être efficace si tu dépends d'un traducteur pour comprendre les requirements ou participer aux retrospectives avec le client.

N2 suffit. On ne demande pas une maîtrise native. Mais il faut être capable de suivre une réunion technique de 60 minutes en japonais, de lire une spec sans Google Translate toutes les 3 lignes, d'écrire un rapport d'incident compréhensible.

Ce que tu feras concrètement

Les premiers 3 mois, tu seras en ramp-up sur un projet client existant. Ça ressemble à :

1. Semaine 1-2 : Setup environnement, code review du codebase existant, pair programming avec les autres seniors pour comprendre l'architecture et les gotchas
2. Semaine 3-6 : Ownership sur des features de complexité moyenne, participation aux rotations on-call (avec backup), premiers meetings clients en observation
3. Semaine 7-12 : Design et implémentation de features complètes, lead technique sur un microservice, participation active aux décisions d'architecture

Après le ramp-up, le quotidien ressemble à ça :

• 40% développement : tu codes encore, régulièrement. On n'est pas une boîte où les seniors ne font que des slides.
• 30% design et architecture : tu mènes les discussions techniques sur les nouvelles features, tu rédiges des RFCs, tu challenges les approches proposées
• 20% interaction client : meetings de spec, démos, discussions de trade-offs, parfois du troubleshooting en temps réel pendant un incident
• 10% ops et amélioration continue : rotation on-call (1 semaine toutes les 4-5 semaines), optimisations de perfs, refactoring de dette technique, amélioration du CI/CD

L'environnement de travail

Remote flexible, présence client occasionnelle

On fonctionne en remote-first à Tokyo. Tu peux travailler de chez toi la majorité du temps. On a un bureau à Shibuya pour les meetings en présentiel quand nécessaire, mais c'est pas obligatoire 5j/7.

Par contre, attends-toi à des déplacements occasionnels chez les clients — typiquement 1-2 fois par mois pour des workshops, des sessions de planning, ou des incidents critiques qui nécessitent d'être sur place. Les clients FinTech japonais apprécient la présence physique aux moments clés.

L'équipe

L'équipe Tokyo compte 12 personnes actuellement : 8 ingénieurs (mix backend, DevOps, frontend), 2 product managers techniques, 2 rôles business/gestion client. Tous bilingues japonais-anglais. Background mixte : japonais ayant travaillé à l'étranger, étrangers installés au Japon depuis longtemps.

Culture d'équipe : pragmatique, direct, anti-processus inutile. On fait des standups quand c'est utile, pas par rituel. On documente les décisions importantes, on ne perd pas 3 heures en réunion pour ce qui peut se résoudre en 20 minutes de pair programming. On challenge les idées, pas les personnes.

CDI ou freelance

On recrute en CDI (正社員) ou en freelance long-terme selon ta préférence. Le CDI offre la stabilité classique + avantages sociaux japonais. Le freelance offre plus de flexibilité et typiquement un taux journalier plus élevé, mais tu gères ta propre structure.

Dans les deux cas, t'es basé à Tokyo avec visa de travail valide (on ne sponsorise pas de visas pour cette position — tu dois déjà avoir le droit de travailler au Japon).

Ce que ça implique de travailler en ESN senior

Abbeal n'est pas une ESN classique. On ne fait pas du body shopping. On ne t'envoie pas solo chez un client pour remplir un siège. On intervient en équipe sur des projets structurants, avec ownership de bout en bout.

Concrètement, ça veut dire :

• Tu travailles avec d'autres ingénieurs Abbeal, pas seul embedded dans une équipe client. On construit ensemble, on se supporte mutuellement.
• T'as ton mot à dire sur les choix techniques. Le client définit les objectifs business, on définit comment les atteindre techniquement. Si un client veut une mauvaise architecture, on le challenge.
• Variété des projets : les missions durent typiquement 6-18 mois. Tu ne restes pas 5 ans sur le même codebase legacy. Tu vois différents domaines FinTech, différentes échelles, différents challenges.
• Pas de bullshit commercial : on ne te demande pas de faire semblant de facturer 10h quand t'en as travaillé 6. On ne gonfle pas artificiellement les estimations. Le client paie pour de la valeur, pas pour du temps.

Le trade-off : t'auras pas l'equity d'une startup, ni le prestige de travailler pour une FAANG, ni le confort d'un produit interne que tu optimises pendant des années. Mais t'auras l'impact sans la politique, la variété sans l'instabilité, et le challenge technique sans la bureaucratie.

Comment postuler (et comment on évalue)

Pas de processus à rallonge. On valorise ton temps autant que le nôtre.

1. Premier contact : envoie CV + lien GitHub/GitLab (ou équivalent montrant du code que t'as écrit). Un court paragraphe sur pourquoi cette position t'intéresse. Pas besoin de lettre de présentation formelle de 2 pages.
2. Screening technique (60 min) : discussion sur ton expérience backend, cas concrets que t'as résolus, deep dive sur un système que t'as construit. On veut comprendre comment tu penses, pas tester ta mémoire des algorithmes.
3. Exercice pratique (take-home ou pair programming) : design d'une API backend pour un cas d'usage FinTech simplifié. On regarde tes choix d'architecture, comment tu gères les edge cases, comment tu testes. Pas de whiteboard coding bullshit.
4. Meeting final avec l'équipe : discussion plus informelle sur la culture, les attentes mutuelles, les questions logistiques. Si tout le monde est aligné, on fait une offre.

Timeline totale : 2-3 semaines de bout en bout, selon les agendas. On ne fait pas traîner les choses pendant 2 mois.

Conclusion : si ça te parle

Cette position existe parce qu'on a des projets concrets, des clients qui ont de vrais problèmes techniques à résoudre, et besoin de quelqu'un de solide pour les adresser. Pas de bullshit, pas de fausses promesses. De l'ingénierie backend sérieuse, dans un contexte FinTech exigeant, avec une équipe qui sait ce qu'elle fait.

Si t'es à Tokyo, que tu veux construire des systèmes qui comptent sans les conneries corporatives habituelles, et que le profil décrit correspond à ton expérience, on devrait discuter. Envoie-nous ton profil via le site Abbeal, section Careers Tokyo, ou contacte directement l'équipe ingénierie si t'as des questions techniques spécifiques avant de postuler.