Développeur Backend Node.js

Refactorisation de l'API Payment V2 : réécriture d'environ 60 % des endpoints pour la nouvelle architecture cible (Bun, Kysely, Vitest), avec documentation pour le front. Certaines routes ont été repensées pour mieux s'intégrer à l'architecture (Pub/Sub, tests) et réduire la complexité héritée de l'existant.

• Passage de TypeORM à Kysely pour monter l'équipe sur un ORM plus bas niveau, mieux adapté aux tests e2e avec accès direct à PostgreSQL ou Redis. Adoption de Bun (choix du lead) : runtime tout-en-un qui limite les dépendances externes tout en améliorant la DX (typage TypeScript, mocking). Liberté sur la stack Docker et le déploiement GCP via Helm, ce qui a permis d'introduire un runtime alternatif sans bloquer sur l'existant Node classique.

• En prod, feedback lead très positif sur mes choix d'architecture, extension de la refacto à d'autres services.

Mise en conformité UK GDPR (droit à l'effacement, aligné sur le cadre européen) : job quotidien planifié via Cloud Scheduler qui lance un pod chargé de vider une subscription Pub/Sub. Chaque message contient l'identifiant d'un utilisateur supprimé et un indicateur de consentement à l'effacement ; lorsque la suppression est demandée, purge des données de paiement présentes dans PostgreSQL et chez Adyen.

• Deux modes de consommation Pub/Sub : j'ai d'abord implémenté le StreamingPull (connexion longue durée) — techniquement fonctionnel, mais le stream reste ouvert après traitement des messages et le pod ne se termine pas, ce qui augmente les coûts et contredit le modèle d'un job batch déclenché par cron. La solution adaptée est la Pull API (pull synchrone) : boucle de requêtes pull par lots, traitement, acquittement, puis arrêt du pod une fois la file vidée.

• En prod, quelques centaines de suppressions par jour ; le job tourne de manière fiable au rythme du cron quotidien.

Découplage du paiement Adyen et de la messagerie in-app : nouvelles routes backend pour initier des demandes de paiement sans passer par le chat, afin que de grands comptes sans accès à la messagerie Checkatrade puissent utiliser le flux de paiement seul. Les deux parcours (chat + paiement direct) coexistent en production. Création et modification de routes, coordination avec le marketing (emails) et le front pour les nouveaux endpoints, et tests backend pour limiter les régressions sur l'existant.

• Travail cross-équipes (Payment, Marketing, front) : l'équipe marketing n'avait pas toujours d'environnement de test pour valider les parcours email, ce qui ralentissait les boucles de validation. Les référents métier ont dû intervenir pour porter et défendre les changements. Changements à aligner entre API, front et templates d'emails ; tests ciblés en prod sur des comptes de test configurés comme des grands comptes, avant ouverture au reste des clients.

• En prod pour des grands comptes gérant plusieurs artisans : clients avec messagerie interne propre ou n'ayant besoin que du paiement et de la visibilité Checkatrade. Mise en production sans régression sur le parcours historique, grâce à une couverture de tests backend avant déploiement.

Support à la développeuse front qui implémentait l'interface de gestion de paiement pour les grands comptes (découplage paiement / messagerie). Specs détaillées dans le code et les tickets, accompagnement au fil de l'eau sur Slack, et pairing ponctuel sur les tests React Testing Library (`testId`).

• Peu de friction globale : quelques ajustements d'endpoints backend et du debugging pour aligner le contrat API avec l'intégration front en cours.

• Endpoints du découplage branchés et livrés côté front pour le parcours grands comptes.