Mizen : une migration V2 que personne n'a remarquée

L'application rassemble le solde et les transactions, la carte physique et sa version numérique, les plafonds de retrait, le justificatif rattaché à un paiement, un volet d'investissement. Chaque écran touche à de l'argent réel. Un défaut ne s'y rattrape pas dans la version suivante : il se compte en appels au support et en confiance perdue.

Pour soutenir sa croissance et gagner en stabilité, Mizen devait passer sur une architecture plus moderne et plus évolutive. Construire la V2 n'était pas le plus dur. Le plus dur était d'y faire passer tout le monde, sans perdre une donnée et sans couper le service une seule minute.

Mizen cherchait un profil capable de tenir les deux bouts : construire la V2 en React Native et Expo, et préparer le transfert des comptes existants. SprintMob a placé un développeur senior, à l'aise avec les migrations d'architecture et habitué aux produits où la donnée financière ne tolère pas l'approximation.

Sur ce type de mission, l'expérience ne sert pas à coder plus vite. Elle sert à voir venir ce qui casse : le cas limite que personne n'avait listé, la donnée qui ne se reprend pas telle quelle, l'utilisateur coincé entre deux versions parce que sa session a expiré au mauvais moment.

Une migration de cette nature tient deux exigences qui tirent en sens contraire. La continuité : l'application reste utilisable pendant que son socle change, parce qu'un compte ne se met pas en pause. La fidélité : chaque compte, chaque carte, chaque transaction se retrouve de l'autre côté, à l'identique.

La V2 a été livrée, puis les utilisateurs y ont été transférés, jusqu'au dernier. Pas de fenêtre de maintenance un dimanche soir, pas de version figée le temps de la reprise, aucun utilisateur laissé sur l'ancienne application en attendant.

Aucun incident critique au lancement. Côté utilisateurs, il ne s'est rien passé : ils ont ouvert l'application, et elle fonctionnait. Rien à réapprendre, rien à signaler, aucune raison d'écrire au support.

Mizen repart d'une base saine, sans dette technique à rembourser avant d'ajouter quoi que ce soit. La prochaine fonctionnalité se discute sur ce qu'elle apporte au produit, pas sur ce qu'elle coûterait à l'ancienne architecture.